Re: A86: Libraries and Loaders

[Prev][Next][Index][Thread]

Re: A86: Libraries and Loaders

On Wed, 6 Aug 1997, B. Nagel wrote:

> The more I think about it, libraries should have only one function.  For
> fonts, each font would be its own library and if a library had more than
> one font, the same function would be used.  You said earlier:

Maybe I didn't explain that very well.  The fonts would not be functions.
They would be pure data, and it might make sense to keep more than one in 
a library.  I think we would be limiting our libraries too much to
restrict them to one entry point.

Just because I can't come up with a good example now doesn't mean someone
won't need the feature in the future! =:p

> This kind of sprite function is slower.  Games that need speed will use
> libs with only one function.

I can show you two routines that must be in the same library to work
properly.  One is a fast Bresenham line function, and one is SetDrawMode
function that modifies the inner loop of the line function.  It makes no 
sense to separate these two.  Besides that, in order to separate them, we
would have to alter our specification to allow libraries to import
functions from other libraries, which is messy, and probably a Bad Thing.

There are other examples, too, both of functions that should be
contained together, and of functions and data that should be
contained together.


> > If the loader automatically loads everything from A86Prog on, then there
> > would be space wasted by the import table.
> > Additionally, knowing the length of the code segment would put a check on
> > write-back (so that the import table is not overwritten, for example).
> 
> true, but, its
> another reason why libs with more than function really complicates
> things.

Why is that?


> Its already bad enough that there will be different shells that are
> bound to have some incompatabilites.  Come on, separating the loader
> from the shell only makes things worse.  We'll have this shell that
> needs that loader which cant be used by another shell which needs its
> own loader, which might sometimes work with the first shell.

Ack!  That's not the way it works!
This is the very problem that a standard solves.  Everyone and his brother
wants to make a shell, and they all want their programs to have titles,
icons, and use libraries.  With a standard program and library format, and
a standard interface to the loader ("A86()"), everyone CAN make a shell,
each with a completely different look, and different features like
password protection and APD, and they will all work with each other's
programs because they will all use A86() to run the programs.  (Is that
explanation clear?)

Complete separation of shell from loader is a high priority.  It will
ensure that any shell can use the loader in the way specified in the
standard, so every shell will be able to load all the programs that follow
the standard. (The really neat part is that the shells could be run with
A86(shell) and therefore use libraries, too.)

How many people do you know who evaluate software based mostly on its
appearance?  There are a lot of them out there, and they all have a
different idea of what is good in a shell (and, for that matter, a
calculator web page... but that's another topic).

The shell is the user interface.  The kernel (in our case, the loader),
is the internal part that manages the whole stinking mess of libraries.
Most people could care less HOW the programs are run.  They just want to
access their games in a way that appeals to them.  Integration of the
shell and kernel is a VERY BAD THING.  It is what will cause people to go
off on tangents and start making up "standards" left-and-right.
Separation of the shell and kernel will allow people to create custom user
interfaces without resorting to creating a different "standard."

I could go on and on about this... but I won't... for now.  Muahahaha! :)


> I kinda agree with you and I kinda dont, this part will need some
> thinking.

When you think, consider the following:

1) What will the code to load a program (or library) look like?
2) What will the code to write back part of a program look like?
   (Notice I said "part!")
3) What havoc would future changes to the standard wreak?


> BTW, I got AShell to relocate single function libs onto the ends of
> progs and it worked on the first try!

That's always impressive.  Last month my boss demo'ed a joystick he 
invented without first testing the code he put in the ROM.  It was
foolish of him, but fortunately there was only one minor bug and the
client company decided they would buy the design.

Wow, it's late!  Alarm clocks are ringing in Sweden.

--------
Dan Eble (mailto:eble@cis.ohio-state.edu)
         (http://www.cis.ohio-state.edu/~eble)
Follow-Ups: References: