Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!husc7!hadeishi
From: hadeishi@husc7.HARVARD.EDU (Mitsuharu Hadeishi)
Newsgroups: comp.sys.amiga
Subject: Re: Getting smaller binaries
Message-ID: <1679@husc6.UUCP>
Date: Thu, 16-Apr-87 12:50:27 EST
Article-I.D.: husc6.1679
Posted: Thu Apr 16 12:50:27 1987
Date-Received: Sun, 19-Apr-87 06:10:51 EST
References: <1108@rpics.RPI.EDU> <235@rocky.STANFORD.EDU>
Sender: news@husc6.UUCP
Reply-To: hadeishi@husc7.UUCP (Mitsuharu Hadeishi)
Distribution: world
Organization: Harvard Univ. Science Center
Lines: 145
Summary: A way to distribute libraries

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