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: