guilford@rpics.UUCP (04/15/87)
I have had an idea that I've been kicking around for a while, and before I do any serious work on it, I was wondering if its been done before, or if there are reasons why it wouldn't be a good idea. I was thinking that a large part of binaries tends to be large chunks of library code such as printf and its associated luggage. I was thinking that it may not be too bad of idea to make most of these large "add-ons" into a real amiga-style library, and then have all programs share it. I can see very little reason for the simple "hello" program from K&R to take up lots and lots of space, specially when most of the code in the binary is in every other binary on the disk. I can see four possible problems with this idea. One is that some of these routines are non-re-entrant and so can't be made into a standard C library. If this is so, then the whole idea is down the tube. A second problem would be that it would be a non-standard deviation. If one tried to port this code to a system which did not have the "extra" library installed, it would not run. There is also the problem that the startup code would have to link into the library and possibly load it from disk. This might slow things down (although it shouldn't after the first one). Then there is also that calls to these subroutines would be indirect and thus a little slower. The advantages to this is that object code size would be reduced, as would link time. Instead of linking with printf and then linking all of the routines printf needs, all one would have to do is link with a stub for printf. So, I am left with three basic questions. Has this been done before? Are there problems that I have not thought of? Is the general opinion that the disadvantages outweight the advantanges? --Jim Guilford (guilford@csv.rpi.edu)
ali@rocky.UUCP (04/15/87)
In article <1108@rpics.RPI.EDU> guilford@rpics.RPI.EDU (Jim Guilford) writes: > I was thinking that a large part of binaries tends to be large chunks of >library code such as printf and its associated luggage. I was thinking that >it may not be too bad of idea to make most of these large "add-ons" into a >real amiga-style library, and then have all programs share it. I can see >very little reason for the simple "hello" program from K&R to take up lots >and lots of space, specially when most of the code in the binary is in every >other binary on the disk. I was thinking along the same lines. I'm working on a Lisp compiler (a class project) for the Dec-20, and I was wondering how difficult it would be to port it to the Amiga. Then I started thinking along the lines of creating a "lisp.library," which would have all of the Lisp stuff and allow you to run Lisp "executables" without the use of the interpreted Lisp environment. Also, last night, at the Stanford Amiga Project meeting, we had one of the developers of JForth talk to us about JForth, and he mentioned that currently the only way to get stand-alone programs (ie, independent of the Forth environment) was to do a "save," which essentially dumps the whole environment into an executable file, resulting in huge executables. [Note: I am not saying anything against JForth here. We played with it a bit last night, and I was very pleased with the product. Creation of stand-along executables from interpreted languages is usually either impossible, or you get huge executables, like in this case, or you end up doing what AmigaBasic does --- You click on the icon for a Basic program, and the Basic is started up in which your program is run.] In any case, Amiga libraries are wonderful things and I would love to see them used as you describe --- Ie, to store a lot of the stuff that normally would get linked in with your code. In fact, if you think about it, most of us probably run at least 3 or 4 C programs concurrently (say a clock, a load average program, emacs, system monitor, hanoi, etc...), so a library would result in a lot of savings. Hmm, I seem to remember reading that Absoft Fortran already does this... Is this true? To get around the problem of creating truly stand alone products (ie, ones you could execute without the library), you probably would still need the option of linking in the code with your program. I haven't answered any of your questions about whether this is possible or not for C, but I am excited about the idea and hope it works... I will think further about the application of the idea in creating Lisp executables. Ali Ozer, ali@rocky.stanford.edu
hadeishi@husc7.HARVARD.EDU (Mitsuharu Hadeishi) (04/16/87)
In <235@rocky.STANFORD.EDU> ali@rocky.STANFORD.EDU (Ali Ozer) writes: >In article <1108@rpics.RPI.EDU> guilford@rpics.RPI.EDU (Jim Guilford) writes: >> I was thinking that a large part of binaries tends to be large chunks of >>library code such as printf and its associated luggage. I was thinking that >>it may not be too bad of idea to make most of these large "add-ons" into a >>real amiga-style library, and then have all programs share it. I can see >>very little reason for the simple "hello" program from K&R to take up lots >>and lots of space, specially when most of the code in the binary is in every >>other binary on the disk. > . . . >To get around the problem of creating truly stand alone products (ie, >ones you could execute without the library), you probably would still >need the option of linking in the code with your program. Something that should be remembered is that all library code MUST be reentrant, so multiple tasks can use it at once. I think most procedures can be written to be reentrant--- you have to allocate all your memory on the stack (or use AllocMem()). Also, data structures have to be carefully thought out, since library routines obviously cannot access global variables in your program. Anyway, as far as installing or copying large applications: clearly, if you were distributing a truly commercial application, you could simply include the library on the startup disk for that application. Many large applications require not only separate library files, but also collections of data files which are required for the application to run properly. One of the weaknesses of Workbench is that it is difficult for a Workbench user to have control over the system-configuration; i.e., the l:, devs:, and other system directories are hidden from the user, and the user has NO WAY to access them without either copying the WHOLE disk or using the CLI. I feel this makes Workbench useless as a stand-alone environment. What should be done is the Workbench should have a way to attach system files to icons; that is, if you copy the icon, you also copy the appropriate system files along with the icon. If the target disk does not contain the appropriate target directories, then the support files are not copied (or, alternatively, the target directories are CREATED and the support files are then copied. This method, I think, is better, since it prevents the naive user from copying an application to a blank disk, then copying it onto a hard disk or another Workbench disk and saying "huh? why doesn't it wurk now?"). This goes not only for device drivers, libraries, and the like, but ALSO arbitrary support directories. The application developer could simply set some sort of flag in the ToolTypes field that the Workbench would be obliged to scan, and then the Workbench would copy those files that are "attached" to the icon, as well as the file itself. Data files, libraries, support directories, and the like would all be copied. The developer would specify one of three modes for EACH file or directory: destructive copy (copy file(s) without checking to see if there already is a file there to be copied over, this would be the default), non-destructive copy (only copy the support file(s) if there is no support file there already, this would be a frequent option), and copy and append copy (copy the support file and append to another named file; this mode would be used to copy devs/Mountlist entries, for example.) (Copy and append copy might be separated into two options, copy, and also append; for devs/Mountlist entries, the developer would have to be sure to copy both the device's own private entry as well as append it to a named file. The append option would probably operate in default mode by appending ONLY if the file to append to exists; otherwise do nothing. This way spurious devs/Mountlist files won't be created.) The icon may not even have an associated primary file; it might simply be the image that refers to several system files that are associated with each other, and the image could reside ANYWHERE on the target disk. In this case, the image could be linked to, say, a device driver and a devs/Mountlist entry, and stored in the "System" drawer or something (or maybe the "Devices" drawer, who knows.) File specification convention will be as follows: you can specify the "attached" files in one of three forms: I) "datadirectory/filename" or "datadirectory" II) ":devs/pipe.device" or ":l/vdk-handler" or just ":directory" III) "devs:pipe.device" or "s:attached-scriptfile" I) means: copy this file or directory into a SUBDIRECTORY of the drawer the icon is being copied into. If the directory has a drawer icon associated with it, copy the drawer icon also, automatically. This mode would be used to copy data directories attached to the application icon, which do not necessarily have to reside in the topmost directory of the disk being copied onto. II) or III) means: copy this file or directory into the TOPMOST DIRECTORY of the target device, regardless of where the icon is actually being copied to. Thus, if the icon is attached to a device driver, the device driver will be copied into the topmost directory of the (presumably Workbench) target disk. If the target directories do not exist, create them. Same comments about drawer icons (i.e., copy the drawer icon if the directory has them, otherwise do not.) Oh yes, and deleting an icon would have to include deleting the attached files and directories as well. Note: this implies that an application that relies on the existence of a particular shared library would have TWO icons (at most): one icon for the executable, and one icon for the support files and libraries. Thus the user could delete the application without deleting the libraries, which might be used by other applications (such as another copy of the application on a hard disk or in a RAMdisk.) This scheme I think solves ALL of the weaknesses associated with the Workbench from a functional standpoint, (NOT from a performance standpoint, as we all know :-). ) With this scheme, a developer can make installation of software on a hard disk trivial for the naive user; s/he need only copy one or two icons, which any idiot can do. The specification involves little or no overhead save a few lines of extra Workbench code; although the above spec seems complicated, I'm sure it could be implemented with only a few lines of code, since it mostly involves testing for the existence of files and directories and either copying or not copying (and searching the ToolTypes fields, which just involves some icon.library calls.) The append option would cause Mountlist files to grow, of course, but that can't be helped; A Mountlist icon could be created so the user to reset the Mountlist to a pristine state if s/he chose to. A new directory, called Support or something, would be created that held icons pertaining to standard system libraries and functions. Thus, a single icon would have all of the standard devices and handlers in it, another icon might have all of the standard printers (perhaps one icon per printer, though this would take up some disk space.) Finally, special applications would have one icon for their support files, and so on. The Workbench user would now have almost the same control over his/her environment that the CLI user does, and all in the same Intuitive format! I think this is the way to do it, folks, and I hope you guys implement it in 1.3 so we can all enjoy it. Personally, I think operating system design is of TANTAMOUNT importance to a computer's perceived image and usability. Certainly having good applications helps, must improving the OS means improving EVERY application, since all applications can immediately take advantage of new OS improvements, and all users can immediately reap benefits. Extending and generalizing the iconic interface as above would go far, I think, to making the Amiga a truly user-friendly machine; right now, the Amiga is still a hacker's machine. What I described above does not make it TOTALLY obvious what to do to install a program on a hard disk, but it at least makes it POSSIBLE to do so for the naive user, and the naive user can also add all sorts of goodies to his/her system (vd0: device drivers, etc.) without having to know ANYTHING about the CLI, and so on. Actually, one more thing has to be added: a way for the Workbench user to MOUNT a device; this could be a simple application (I could write it easily) that would search devs:Mountlist and present the user with a requester that listed the possible devices that could be mounted. In fact, this thing could also be used to edit a mountlist, i.e., a Delete Device function, that would simply delete the Mountlist entry. Umm! Better stop before my mind explodes. -Mitsu
hadeishi@husc7.HARVARD.EDU (Mitsuharu Hadeishi) (04/16/87)
Oh, yeah, and I forgot: the Mount Device application would modify a file, call it s:workbench-startup, that would be executed before a LoadWb. -Mitsu
daveh@cbmvax.cbm.UUCP (Dave Haynie) (04/16/87)
in article <235@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) says: > In article <1108@rpics.RPI.EDU> guilford@rpics.RPI.EDU (Jim Guilford) writes: >> I was thinking that a large part of binaries tends to be large chunks of >>library code such as printf and its associated luggage. I was thinking that >>it may not be too bad of idea to make most of these large "add-ons" into a >>real amiga-style library, and then have all programs share it. > I was thinking along the same lines. I'm working on a Lisp compiler (a class > project) for the Dec-20, and I was wondering how difficult it would be to > port it to the Amiga. Then I started thinking along the lines of > creating a "lisp.library," which would have all of the Lisp stuff and > allow you to run Lisp "executables" without the use of the interpreted Lisp > environment. > > Ali Ozer, ali@rocky.stanford.edu Maybe great minds really do think alike :-). It seems many moons ago I was involved in a lengthy discussion about just this on Compuserve. Someone was even able to produce a very preliminary version of a c.library, which was limited and a little buggy, but worked otherwise. The hardest part (once you master the linking bits to create a proper library, something I haven't really tried yet myself) seems to be insuring that everything in library functions is allocated on a per-call basis (I guess dynamic allocation passed via calls or maybe stack allocation would work OK) or a single, global value attached to the library base structure for that particular library. On a similar note, I've been very gradually bringing up a LISP environment, which is currently a very remote decendent of a thing I've been fiddling around with since I started in on a DEC-20 (in Pascal) back in school. I considered the idea of a lisp.library, not so much to make a stand-alone LISP interpreter that much better, but because a reasonable LISP-like language can function as a general purpose macro language for many different applications. Some Emacs (Gosling's, GNU) have imbedded LISPish languages used for extending the basic command set, as do various other tools like some CAD packages. Most LISP implementations count on a global symbol table, but since everything's in this table, a simple descriptor could be passed to a general lisp library, allowing the actual functions to be independently accessable. All global information could exist as LISP objects in the individual environments; all the functions might need is a bit of stack space for local variables. I really haven't had time to follow up this idea that far, but I've been interested in it, and its good to hear others thinking the same things. -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The A2000 Guy" BIX : hazy "That's all she wrote" -J. Strapp
cmcmanis@sun.uucp (Chuck McManis) (04/17/87)
Mitsu brought up some interesting points about being able to install your
package from the Workbench environment. I think it needs reiterating that
those of you who wish to sell to the 'masses' be prepared to support the
workbench with all its faults and features since thats what a lot of
people will be using. On the other tentacle, he also described an
incredibly complex scheme for attaching files to icons etc. Wouldn't
it be *much* simpler to use a program like the one in the Fish library
that runs a batch file when it's icon is selected. The Amiga command
file is pretty powerful, and Ed can be used as a stream editor. So
between the two of them just about any transmogrofying of the system
can be done under program control. Call it something like 'Install on
Harddisk' and the user will get the picture. Certainly, seems like
something that can be done today with zero changes to the system.
--
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.jesup@steinmetz.steinmetz.UUCP (Randell Jesup) (04/20/87)
[Re: the idea to have lists of libraries and other system files attached
for copying in WB, etc]
Great Idea! I've been looking for something like this since 1.1!
Concerning deletion: Have another qualifier for deletion, like WBNODELETE,
which implies that if the icon is deleted, the subfile (or directory)
should not be deleted.
I see something like this in the ToolTypes for the Icon:
WBFILE=application
(Defaults to copy, delete)
WBFILE=:fonts/geneva|WBNODELETE|WBQUERY
WBFILE=:libs/icon.library|WBNODELETE|WBNOOVERWRITE
WBFILE=mydatafile
WBFILE=mydir
WBFILE=otherapplication|WBICON
(WBICON means copy all the files associated with 'otherapplication' : if
it has no .info file, just copy that one file)
WBFILE=:devs/mymountfile|WBAPPEND=:devs/mountlist
(WBAPPEND copies the file and also appends to the given file: otherwise you
couldn't copy it again.)
Of course, these names are just ramblings.
Also, there should be a workbench option to show all files without .icon
files using a default icon. This would add the last thing required to make
the WB interface truely usefull.
Commodore: PLEASE consider something like this for 1.3!!!! PLEASE!
Randell Jesup
jesup@steinmetz.uucp
jesup@ge-crd.arpaspencer@eris.BERKELEY.EDU (Randy Spencer) (04/21/87)
>In <235@rocky.STANFORD.EDU> ali@rocky.STANFORD.EDU (Ali Ozer) writes: > One of the weaknesses of Workbench is that it is difficult for >a Workbench user to have control over the system-configuration; i.e., >the l:, devs:, and other system directories are hidden from the user, >and the user has NO WAY to access them without either copying the WHOLE >disk or using the CLI. I feel this makes Workbench useless as a >stand-alone environment. What should be done is the Workbench should have >a way to attach system files to icons... [ ...goes on to list the specifications for workbench that would track the system files for the user... ] > -Mitsu I don't know that I am totally interested in icons for system files. We don't require that the Mac people get icons on their files. What we need is our own "Font/DA Mover". This would be quite like DirUtil. But it would know something about the system structure. If you want to move printer drivers you click on that option and it opens "devs:printers" for you. Of course, just like the Mac, you could close that and point the program to another directory. The most important thing that this program could do is to (as an option) only display the differences between the two selected directories. You could then select as many files as you wanted from one directory and copy them to the other without waiting for the files already there to copy also. Play with "Font/DA Mover", you'll see what I mean. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)284-4740 I N F I N I T Y BBS: (415)283-5469 Now working for |||||||||||::::... . . BUD-LINX But in no way |||||||||||||||::::.. .. . Officially representing ||||||||||||:::::... .. ....ucbvax!mica!spencer s o f t w a r e spencer@mica.berkeley.edu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-