Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!newstop!texsun!convex!rosenkra
From: rosenkra@convex.com (William Rosencranz)
Newsgroups: comp.sys.atari.st
Subject: Re: Standardized disk layout/folder names
Message-ID: <1991Mar21.100227.13538@convex.com>
Date: 21 Mar 91 10:02:27 GMT
References: <2232@lee.SEAS.UCLA.EDU>
Sender: news@convex.com (news access account)
Organization: Convex Computer Corporation, Richardson, Tx.
Lines: 98
Nntp-Posting-Host: convex1.convex.com

In article <2232@lee.SEAS.UCLA.EDU> plinio@crowe.seas.ucla.edu (Plinio Barbeito/) writes:
>Again, as long as we're on the subject of standards, how do people
>feel about having some sort of disk layout standard, like Unix has
>(i.e. the binaries are kept in /bin, system database files are kept in
>/etc, user files are kept in /usr, manuals for programs are kept in
>/usr/man, and so on).

no problem here. i would hazard a guess that most cmdline shell users
do this already.

>Installation scripts or programs could be distributed for each program 
>that would automatically take care of unpacking, putting the binary,
>the manual file and help file(s) in standardized directories, adding a
>line to the desktop.inf so that double clicking a data file starts the
>application, and...(do you want to add anything?)

if you supply source (or even binaries) there is generally a makefile
present. of course that assumes the installer has make and knows how
to use it. make can very easily put things in the right place with
relatively simple changes in the makefile, generally only 1 or 2 macros.

just posted to comp.sources.unix is the purdue install system. i have
not really looked at it yet, but it could probably be adapted for this
use. think of this sort of program, universally accepted, as analogous
to the patch program for updating source files.

a well written README should be all you need, but that can often
be asking too much. in all fairness, constantly changing stuff like
gnu c can be a pain to document well. it is a catch-22 that this is
just the sort of thing you DO want to document because of its
complexity. on the other hand, a while ago i harped on TeX because
of its rather limited installation instructions. and TeX is a VERY
complicated system, even for otherwise expert users. in the last few
weeks i saw numerous requests for help here in installing TeX.

>For bigger GEM applications, some of these require an obnoxious 
>/itsfatname folder to be present.  We may have no choice but to continue
>this trend.  I would prefer to put these folders in c:/gembin myself, or
>under something like c:/wordproc or c:/apps.  The day might come when a
>novice user could install software on his hard disk by simply double
>clicking on the standardly named install.prg (or install.sh, or whatever), 
>not having to know anything about GEM other than how to open "things" on 
>the desktop.

i can propose another alternative: for those capable of running a binary
patch editor, building in patch space in internal path strings is easy:

	char *path = "C:\\GEMPROG\\SUBDIR\\FILE.DAT\0                     ";

then you can just hack in a new location (or better yet, provide a simple
tool to do it for the user.

another thing might be to provide a configuration file (a la the DECKTOP.INF)
though you then have more or less the same problem: where to put theses
suckers. it usually ends up in root directory. i prefer the patch space
scheme, even for code which i have src for. it takes 10 seconds to patch
an executable which might take minutes or more to recompile.

[ suggested locations for things deleted ]

you have the technical stuff nicely squared away. however, you are probably
reaching only a tiny fraction of people writing code in this forum. i doubt
that this sort of thing can be standardized, with the possible exception
of unix-like environments which have a well defined model. however, i like
your ideas and may adopt some of them personally, since things seem well
organized. good luck in your martyrdom :-(

>Well, post up what y'all think.  Look out -- if this gets far enough
>maybe Atari will include some of our ideas for this on its new TT 
>disks, or even ask official developers to abide by it.  It will 
>be worth it even if it gets them to think in that direction.

i doubt atari would take a stand on this sort of thing. and they probably
should not (or can not, at this point). it is really up to s/w vendors
to set this sort of standard, mostly by brute force (i.e. having your
program running on more systems than a competing configuration/product).
where atari would take a stand is with the TT's support of unix. and they
mostly do that by default (since unix defines the bulk of where to put
things by tradition).

don't get me wrong: i would love to see things standardized. fortunately,
the cmdline faction here has a direction (more or less) defined by unix.
the desktop faction is, has always been, and probably always will be on
their own in this regard. there is no real GUI standard like there is in
the mac world or even the PC/windows world, i suppose. there is no what
i would consider "look and feel" standard for gem applications, IMHO.
just the physical appearance of the window borders is not enough to
constitute look and feel, regardless of what apple's lawyers might say
to the contary :-). maybe that might be a more laudible goal for which
to aspire...

good luck. above all, keep thinking!

-bill
rosenkra@convex.com
--
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
Convex Computer Corp.      |ARPA: rosenkra%c1yankee@convex.com