Re: A83: Menus & ZMENULIB
[Prev][Next][Index][Thread]
Re: A83: Menus & ZMENULIB
I agree with Linus on libraries for shell-independent programs, especially
since I stole the idea from my vast array of ancient programming books. The
term library was founded not too very long ago, however, because the old
name is "shared files." Well, my guess is that the change came about
between 1974 and 1975 since I have a book from 1974 that refers to them as
"shared files" and a book from 1975 that refers to them as "libraries." hehe
They all agree that libraries are meant to conserve space while allowing
programs to use code that is optimized for speed though.
Anyway, here's why there will always be compatibility problems: as long as
computers exist, I will write for a particular system/os/shell that I like
and others will do likewise. So what? Deal with it.
And lastly, when I say I would have changed the library format, I meant
from:
.db "ZLIB",0,0,0,0,lib1,vec1
to:
.db "ZLIB",0,lib1,vec1
That and the way I wrote ZLib (which isn't terribly excessive anyway...).
So you waste 3 bytes every time you use ZLib; I bet you waste more looking
up that long name ZMENULIB in the vat.
Joe Wingbermuehle
http://www.usmo.com/~joewing/
-----Original Message-----
From: Linus Akesson <lairfight@softhome.net>
To: assembly-83@lists.ticalc.org <assembly-83@lists.ticalc.org>
Date: Sunday, October 04, 1998 6:03 AM
Subject: Re: A83: Menus & ZMENULIB
>
>Library, n.: A separate file containing program code meant to be shared
among
>several applications.
>I know that the word library is often used to refer to a sos library, but
>would you believe me if a said that the computer term "library" was founded
>somewhat before sos was written? =)
>
>You say that using only sos will cut back on compatibility problems. My
reply
>is that not using any shell at all would extinguish compatibility problems.
>
>And I don't like the way libraries are handled in sos, I mean, even Joe has
>admitted that he wouldn't have used that method if he'd written sos now.
>
>Linus
>
>On 04-Oct-98, Jkhum98@aol.com wrote:
>
>>In a message dated 10/03/98 6:04:03 PM, lairfight@softhome.net writes:
>
>>>ZMENULIB is a 395 bytes big file, containing ready-to-use menu code.
>>>It is NOT a sos library. Instead, you have to look the program up, and
>>>jump to the beginning of it. This way, it can be used by
shell-independent
>>>programs (AND sos programs of course).
>
>>Hey Linus, nice job on this, but I think its kind of contradictory to make
>>this shell-independent, and call it a _Library_ at the same time... =P I
>>personally think that SOS should progress as the main shell (I think other
>>people besides Me and Joe use this shell), and this shell is more useful
than
>>Ashell or running programs from the OS, because of the obvious reason of
>>Library Usage... Although, you have a point that any of these methods of
>>running programs should be able to use your routine, but why not create a
SOS
>>library for it, and then people just start coding for SOS... =P I know I
>>shouldn't be bias to anything but SOS, and that it shouldn't monopolize
the
>>shell usage, but having One shell would cut back on compatibility problems
>and
>>competition, for example, look at the shell wars or the 85 and 86 (the 82
>>also, but Ash 3.1 will soon resolve that) and think of how Plusshell and
>>DoorsOS Compatibility for the 89 at this time are causing conflicts... Is
it
>>really Morally wrong to have a Specific shell for a calculator and
eliminate
>>competition? Its not competition for money but more like programmer and
shell
>>popularity (y'all know it is), but it would make the Users of all the
calcs
>>(Including the Calculator-Adept Programmers, and the "Calculator Impaired"
>>people at school who depend on us for games) it would make everything a
>little
>>bit easier to focus on one Shell... Whew, a lot of Preaching in there, did
>>that have "ticalc.org News Article" potential, since it was a whole lot of
>>crap...? Well anyways, I'm sure Ill get a lot of negative opposition on
this,
>>Bring It On! =P
>>--Jason K.
>
>
Follow-Ups: