A83: RE: A82: Re: Fw: Proposed open operating system/gui/shell (CalcOS-8


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

A83: RE: A82: Re: Fw: Proposed open operating system/gui/shell (CalcOS-82,83,85,86)



Libraries certainly do make programs smaller, and save space, but are a 
hassle for the user. I think they should be implemented ONLY if the shell 
handles them as follows:
* If a program is executed and not all libraries are on the calculator, a 
list would be displayed showing what libraries are necessary.
* Whenever the shell is executed, it would do a library check, and delete 
any libraries that were on the calculator but not required by any programs. 
(It would confirm that the user wanted to delete those libraries.) This 
way, the user could delete several programs, and not worry about deleting 
the libraries. The shell would take care of it.
* Different versions of a library would have different variable names, so a 
user would not have to worry about overwriting newer versions of a library 
with older versions when sending a program and its libraries to the 
calculator. When the shell is run, it would check for multiple versions of 
the same library on the calculator, and delete every version of a given 
library except the newest.
* All libraries would have "lib" as the first three characters of their 
name, so they would all be listed together in variable menus.

Here is an example of how this could work. Let's say there are two games 
that use grayscale graphics. There are two versions of the grayscale 
graphics library, 1.0 and 2.0. The first game needs version 1.0 or later, 
but the other game needs version 2.0 or later. The user sends both games to 
the calculator, as well as both versions of the grayscale library. The two 
grayscale library names are libgray1 and libgray2. The user runs the shell. 
The shell does a library check, and deletes libgray1. The user runs the 
first game, that needs the grayscale library 1.0 or later. The program has, 
in its list of required libraries, "gray" for the library ID, and 1 for the 
version. The shell finds "libgray2" has an ID of "gray", and a version of 
2, so it is compatible. The program is run. The user then runs the second 
game, which has, in its list of required libraries, "gray" for the library 
ID, and 2 for the version. The shell checks and finds that "libgray2" is 
compatible, and the program is run. Now, if the author of the grayscale 
library wanted to make a third version that was not backward compatible, 
the author could name it "libgray3", but would have to give it a different 
ID, such as "gray3", and start the version numbering over again at 1.

Does this idea sound feasible? This method could be used for all the 
calculators. (On the 83 and 86, with no shell, a library checker program 
could be used instead, which the user would run after deleting ASM 
programs.)
________________

Jeff Tyrrill
http://tyrrill-ticalc.home.ml.org/
http://ti-files.home.ml.org/


-----Original Message-----
From:	owner-assembly-82@lists.ticalc.org  On Behalf Of Dines Justesen
Sent:	Friday, October 17, 1997 5:16 AM
To:	assembly-82@lists.ticalc.org
Subject:	Re: A82: Re: Fw: Proposed open operating system/gui/shell 
(CalcOS-82,83,85,86)

>>I understand the pain of having 10 different library .82ps on your calc.
>How
>>about this: put the functions INSIDE the .82p of the shell (Example:
>ash.82p has
>>INSIDE of IT the point_on/off routines). That way, there is only one file
>on the
>>calculator, but the most common functions are inside that file. How about
>it?
>That would defeat the purpose.  Then, you would have a bunch of routines
>that programs don't use.  What if the routines were stored differently?  I
>don't really see what the problem with the libraries is?  Just the number
of
>prgm variables on the calculator???

I would not mind having the extra variable on my calc, but as i have 
written
before it has been tested an "normal" users of the shell does not like to
have all those vars on the calc.

It would be possible to include the libs in the shell variable without
defeating the prupose of libraries. That would however require that you
installed the libs in the shell before using them, and you would need a
program to uninstall the lib again when you did not want them. This would 
be
a bit more complicated than normal suport of libs, it would take up more
space, and it would not solve the problems mentioned with libs.

Dines