From: rock@lakes.trenton.sc.us (Rockerboy)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Going to the metal
Date: Sun, 10 Jan 93 13:44:46 EST
Reply-To: rock@lakes.trenton.sc.us (Rockerboy)
Organization: Lakes Public Access

aa302@Freenet.carleton.ca (Russell McOrmond) writes:

>   You missed the point - Library IMPLEMENTATION diversity is a good thing,
> but interfacing diversity is destructive.  The requestor libraries
> are a good example.  There are usefull libraries which patch in and
> replace asl.library, and then there are IMHO useless libraries that
> require that the application use a different interface in order to get this
> different environment.

What is your point?  Of course there will be uselss versions, just as 
there are countless other uselss things.  That still doesn't make the 
useful versions unworkable.

>   If you can't see the obvious magnitude in difference between
> functionality diversity and interfacing diversity, go back to grade 2
> programming.

How arrogant of you to assume that you have any business telling me what 
is and is not right?  Who died and made you programming guru?  I'd 
suggest you go back to kindergarten, or first grade, or wherevere, in 
your country, they teach children a _truly_ important concept:  manners.
The 'magnitude of difference' is indeed obvious.  You are, hoever, 
conveniently ignoring the fact that there would be useful versions as 
well as useless ones.

>   The code that these compilers generate all run on the same computer -
> if you are proposing different implementations with a standard
> interface, then we agree - Otherwise what you are suggesting is nothing
> bug destructive.

That is _precisely_ what I am proposing, you silly goose!  
Hardware.libraries to allow pseudo hardware registers, with machine 
specific versions to interpret standard commands and tailor it to 
specific hardware!  It might not be substantially faster than using the 
OS, but there would be a pronounced flattening of the learning curve for 
it.  Now where, pray tell, is the harm in that?

>   The point of a .library is to provide a common interface to 
> multiple implementations of some code.  When there is a
> 1-1 ratio of application and library compatability, the whole purpose
> of writing the library is nullified and the .library code should just
> have been put into the application itself.

You cannot prevent people from implementing their custom version of a 
standard library, but, as I have tried to point out, such implementations 
would have little impact.  If they were different, people would likely 
react negatively.  We're not discussing something like a requester, where 
you say, 'Oh, that's neat', but rather a library that will have no visual 
factor.  It would simply be a simplified OS, on designed in a chip 
oriented manner, and with certain commands such as SuspendOS() and 
RestoreOS().  Ideally, said library would posess duplicated of several 
other library functions, so that, by using one, simple library, game 
designers can power down the system, access disks, allocate memory, and 
then bring the system back up when he's done.  Coupled with routines to 
access hardwrae registers oin a low a manner possible, this would be a 
most effective compromise from game designers.  Why is it that some 
people feel that need to kick and scream so hard against it?  Perhaps, as 
I suspect, you simply feel that games and demos have no value, and should 
not be allowed to exist?