Re: A86: Libraries and Loaders


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

Re: A86: Libraries and Loaders



Well, I really think the one function library is a good idea, but
unfortunatly, its cooler to say "libraries" than "external functions" so
some one will eventually end up making a loader that does libraries and
single function libs would become obsolete.

> > 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?)

Yeah, and some people will end up making their own loaders ("A86()"),
this is really messy.  When you separate the loader it makes it easier
for a programmer to have programs loaded the way he wants without
writing a shell.

> 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.)

Ditto to what I said above.
 
> 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).

Ditto to what I said above.
 
> 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."

Its the other way around, people will also make their own "kernals"
 
> I could go on and on about this... but I won't... for now.  Muahahaha! :)

Its a bad idea to separate them, you gotta think into the future,
someone will eventually make up a more advanced loader that won't be
"standard"
 
> 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.

I wont release it until decisions of standards are final.

Bill


Follow-Ups: References: