From: pshuprs@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.sys.hp48
Subject: Shared library proposal
Date: 14 Oct 92 01:35:20 GMT
Organization: Georgia Institute of Technology


=================SHLIB48 Manifesto=====================
(wow. that sounds grand, doesn't it?)
 
   Hello, all!  This message will be a long one, but I think it's
worth it.  While it's about software not for the faint of heart,
even the rank novice should read it. Please, read on.
(If you really want a sneak peek at the surprise ending, I've got
two words for you: "Shared libraries").
 
   I've been amazed and greatly benefitted by the spirit and
quality of the HP48 free/shareware floating by on the net.  It
seems that everyone who owns an HP48 has contributed in some way: 
math packages, databases, real-world utilities, timers, and my
favorite: painstakingly discovered undocumented things that make
your machine go ping.  Having bought my HP48 about a year ago, I
came into an overwhelming wealth of products (3 goodies disks
full!) that has grown exponentially.
 
   That very wealth has worked two ways to create my idea (wade
through all this, please; I'm getting there :-). First of all, I
feel I owe a great debt to, well, everyone.  Secondly, and most
importantly, there is far too much software and not enough RAM.
Although I have yet to fill up my recently-bought 128K card, the
days of 32K are still fresh to me.
 
   Lutz Vieweg attacked the problem by writing what he called the
Redundancy Fighter; his idea was the HP48 incarnation of the one
fundamental principle of compression: repeated patterns need not
take up space.  Instead, only keep one copy in RAM, and merely
refer to it elsewhere.
   My approach to the problem of RAM cram has many added
advantages over Lutz's--at least for storing programs--but I'll
need the support of HP48 users AND developers.  (In the course of
writing this document I have put a great deal more thought into
it, and it's much more than a RAM-saver now!)
 
   So here it is:  I will begin writing a shared library for the
HP48 in about three weeks' time (when I get my new computer).
What is a shared library?  Well, a shared library is very much
like your calculator's ROM; more obvious parallels are James
Donnelly's toolkit and Flavio Casetta's SmartROM.  These are all
collections of commands designed not to be programs in
themselves, but to be subroutines available to any program
running on the HP48.  The implications aren't immediately
staggering, but think:
 
   You're writing a program that needs to display a list of items
from which the user can select one choice.  You could write
several Kbytes of mini-GUI or use the Browser functions in
Donnelly's toolkit (or use the tricks disclosed recently to
access the built-in HP48 catalog functions).  
   That's no big deal. You're an adventurous programmer, so you
write the 4K browser yourself as a subroutine inside your main
program (we'll call the program X).  Later in life, you decide
that you need another program that displays a different set of
lists (we'll call this program Y), so you copy the code from old
program X into Y, and everything is fine.
    Except that you've got 8K of list browser code in memory when
4K was all you needed.
 
   It is this replication of code that I am trying to prevent.
 
   Being a smart programmer, you realize your mistake and put
your browser code into a library called BROWSER.LIB and have
programs X and Y both call the same function in BROWSER.  So
you've saved yourself 4K.
 
   This is the basic concept of shared libraries.  Now let me
explain why you should support me and MY library.
 
   Another programmer writes some superwhizbang program you
absolutely CANNOT do without.  His program does some vital thing
that (of course) displays some lists and lets the user choose
items from them.  His programs, A and B, are designed much the
same way yours are; they both call his data browser code which he
wisely put into a library called LISTBROWSE.LIB (which we'll say
is 4K long).
 
   Now you're back where you were before: You have 8K of list
browser programs when only 4 is needed.
 
   Both of the programmers need to use some standard library that
everyone has.  Hopefully, this will be MY shared library.
 
=================================================================
 
That was the intro.  This is my proposal:
 
   My library, tentatively dubbed SHLIB48, will be a collection
of frequently used routines chosen by the HP48 community. 
SHLIB48 will be written with the constraints of the unexpanded
HP48S(X) in mind (as well as those with 256K of expansion RAM). 
An end-user will have the ability to easily remove portions of
the shared library that (s)he doesn't need.  Although the full
library might reach 64Kbytes in size, an end-user could remove
all but the 3Kbytes of code he needs for his programs and run
them WITH NO LOSS IN COMPATIBILITY.  
   Applications will be able to determine which routines of
SHLIB48 are present, and modify themselves accordingly.  For
example, a communications program that uses SHLIB48 might offer
the Xmodem download protocol using a SHLIB48 routine, but would
still run if user A had removed the Xmodem routine from his
SHLIB48.  If he stubbornly chose the Xmodem download option from
the communication program's menu, it would simply beep and tell
him "Xmodem shlib routine not present," and continue
telecommunicating.  The implementation of this would look like
this:
 
 
   IF     122 SHASSERT 
   THEN   122 SHRUN
   ELSE   "Xmodem shlib routine not present" 1 DISP 
   END
 
(where 122 is the hypothetical entry number for the Xmodem
protocol in SHLIB48, and SHASSERT and SHRPL are two proposed core
commands--the few commands guaranteed to be in SHLIB48).
 
   If this telecommunications program absolutely needed some
SHLIB48 command--say, fast machine language display routines--
then it could test for the presence of that command at startup:
 
IF
  { 10 11 12 }
  SHASSERT
  NOT
THEN
  "Missing SHLIB commands."
  DOERR
END
 
(where 10, 11, and 12 are the entry numbers of the hypothetical
SHLIB48 fast machine language DISP, REVERSE, and SCROLL commands)
 
If the user's customized SHLIB48 was missing the necessary
commands, the program would simply stop running.  Very clean,
VERY SAFE.
 
   I would provide programs running on the HP48 and other
platforms (executables for MSDOS, C source for the rest) that
facilitate the editing of SHLIB48.
 
   Another feature I will provide is a mechanism that allows the
user to choose between large, powerful routines or smaller, less
powerful ones with total transparency to the application. This
will be allowed by rigid specifications for the entry and exit
conditions of all SHLIB48 commands.
   For example, one of the SHLIB48 commands will be an EDIT
command. When a program calls the EDIT command to allow the user
to edit, it will leave a string on the stack and expect an edited
string upon exit (there will probably be other parameters, but
this is only an example :-).  While the user may choose to keep
Lutz Vieweg's excellent QED editor in memory (at a cost of
10Kbytes), he may prefer to use the HP48's built-in editor and
save that precious 10Kbytes.  His program will not know or even
be able to detect the difference, because the generic EDIT
command will act as a black box: string in, string out.
  He could even write his own editor and use the SHLIB48
customizer to add it in!
   
   Another VERY salient issue is that of ROM compatibility: how
can you depend upon some program that uses a hundred
unHPsupported SYSEVALS if a new, incompatible version F ROM comes
out?  Well, there could be two SHLIB48's, one for versions A-E of
the HP48 and one for future versions (when they come out).  So
if/when version F comes out, the inevitable ROM changes would be
hidden from all your software because of SHLIB48.  Heck, let's be
crazy and suppose that HP adds some superwhizbang ROM routines
that programs start to use (say, an internal Fast Fourier
Transform).  Well, the DSP48 program you want to use on your
version D needs this new version F routine. No problem!  DSP48's
author would kindly write his program to use SHLIB48, and when
the need arose, someone could write an FFT function for the
versions previous to F.
   So, to make myself clear, the SHLIB48 for version F HP's would
support all the commands of the version A-E SHLIB48s, but add new
ones.  The A-E SHLIB48s would then change to support the
(carefully chosen) new commands.  The difference between them
would be that the version F would use extremely short native ROM
calls, while the version A-E SHLIB48 would have the actual code. 
Either way, both the user and the program are happy.  Think of it
as a version F emulator, or a ROM upgrade.
   The best solution, of course, would be to buy a version F
(if/when it appears).  Unfortunately, the user base can't really
do that.  Hence SHLIB48.
 
 
MORE TECHNICAL GUNK:
   Those of you who might develop for SHLIB48 are probably
wondering about the fun stuff lurking below its hypothetical
sweet smile.  This is the part that gets gooey.
   I originally (er, a few hours ago) conceived of SHLIB48 as a
purely machine language library; that is, a library of commands
that could be accessed by simple calls from within an actual
machine language program.
   I understand the implications (and technical problems) of a
machine language library that could be pushed around by Garbage
collection and user manipulation in general, but with well-
planned runtime startup code for each program that uses SHLIB48
(__main, so to speak) and a clever macro package, I know it will
work.  Certain conditions will be necessary, of course. (Read
this as "limitations.")  I've written several programs that
needed a quick way to shove characters onto the screen while
inside a ML loop (i.e. they cannot return to RPL and use
DISPROWx)...
   The first static SHLIB48 object (XLIB xxx 000) will be a
Library Data object which contains a jump table.  This expandable
jump table will hold offsets within the SHLIB48 library to
machine language entry points, or NULL offsets for
unimplemented/removed commands.  Certain of these would also be
static and unremovable, such as the routine to test for the
presence of a SHLIB48 command.
   This idea quickly expanded to include RPL-callable words.
These would be implemented with the XXXX SHRUN mechanism
mentioned far above, and with XLIBs.  The main drawback to XLIBs
would be that only a very few XLIBs would be guaranteed to be in
every SHLIB48.  The main advantage of XLIBs is compactness and
speed.  Ah, well, I have a million ideas.  I can't state them all
here.   
 
================================================================
====================== NEARING THE END =========================
================================================================
 
   I hope you have been impressed with the feature list so far. I
plan to further refine this idea for the next three weeks or so
(so far I've spent about 2 hours thinking about it, so I might be
missing some important points).  I would be delighted if several
willing and knowledgeable volunteers would step forward to form a
committee with me for the design and standardization of SHLIB48. 
You'd be insuring that you get what you need, so please think
about it.
 
   Let me stress that this is not intended to be a replacement
for Donnelly's toolkit, Flavio Casetta's SmartROM, or any other
commercial package.  While I have not used these, I am impressed
with the features they offer.  SHLIB48 would, in fact, encourage
the use of these (and any other libraries) by providing a
consistent interface to them, while allowing the end-user who
can't afford to buy every library and card (or doesn't have any
ports left) to find alternate solutions while using the same
software.  I respect the work of any who have contributed to the
HP48 community, and do not wish to circumvent them.
 
   As I near the end of this behemoth of a post, let me say one
or two more things.  First off, shared libraries WORK.  In my
opinion, there are nothing but advantages to using them.  Two
environments that I have used with great satisfaction use shared
libraries -- the Commodore Amiga and a PCompatible running a
wonderful freeware UNIX clone (Linux).  I have nothing but praise
for them both (well...close enough).
 
   I NEED YOUR FEEDBACK!  I need every one of you, from the
novice to the power user--especially the Great Names of the HP48-
-to suggest and contribute.  What do you need?  What do you have
that I should put in?  What do you feel you could write?
PLEASE PLEASE PLEASE help me to provide this service to you.
 
Oh, yeah, it will all be FREE. That's very important.  The freest
of freeware.  Individual authors will retain any copyrights they
feel necessary...I'm looking at the GNU public license.  It seems
to work well enough for Linux.  However, any suggestions by
shareware or commercial authors will be considered (i.e. this
could be a great way to show evaluation versions of your
software).
 
   I will read and answer ALL replies by mail and this newsgroup.
My Internet addresses are:
 
   pshuprs@prism.gatech.edu   -and-   gt8134b@prism.gatech.edu
 
(I prefer the first for now, but I might lose it after this
quarter.  The one on the right will last me for four more years!)
 
 
Robert Sanders
 

-- 
Robert Sanders 
Georgia Institute of Technology
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!pshuprs
Internet: pshuprs@prism.gatech.edu     OR  gt8134b@prism.gatech.edu
From: akcs.joehorn@hpcvbbs.cv.hp.com (Joseph K. Horn)
Date: Wed, 7 Oct 1992 07:40:07 GMT
Subject: Re: Annex BBS
Message-ID: <2ad28cd3.1809.2comp.sys.hp48.1@hpcvbbs.cv.hp.com>