Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!ucla-cs!ucla-seas!crowe!plinio From: plinio@crowe.seas.ucla.edu (Plinio Barbeito) Newsgroups: comp.sys.atari.st Subject: Re: Standardized disk layout/folder names Message-ID: <2248@lee.SEAS.UCLA.EDU> Date: 22 Mar 91 17:45:10 GMT References: <2232@lee.SEAS.UCLA.EDU> <1991Mar21.100227.13538@convex.com> Sender: news@SEAS.UCLA.EDU Organization: SEASnet, University of California, Los Angeles Lines: 74 In article <1991Mar21.100227.13538@convex.com> rosenkra@convex.com (William Rosencranz) writes: >In article <2232@lee.SEAS.UCLA.EDU> plinio@crowe.seas.ucla.edu (Plinio Barbeito/) writes: >>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. The problem is that I don't want users to have to know anything more than how to double-click something to get started. Expecting them to have make, or to know how to use it is too much of an assumption. In more detail: the user buys a disk or downloads a file. He double-clicks on that file. It unpacks itself into the right directories on the fixed disk and (optionally) starts up the application (ideally, for security reasons, access is restricted to the application as to which directories it can write to). This is done in a *standard* way so that once the user has installed one application, he feels confident that he can install any product. The application puts an icon on the desktop so that the user can start it up in the future (without actually having to know where it is stored). To take it a step further, dropping the icon in the trash starts a deinstallation -- more than just the binary is deleted, an attempt is made to delete the files the application installed. This way, the user only has to be familiar with the aspects of the program that are important to him, not what support files have to be in what directory and so on. >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. If it isn't too huge, it may be worth looking into, thanks for the suggestion. >a well written README should be all you need, but that can often[...] The problem with README files is that you then have to figure out where to store them, and unless you have a folder on your hard disk for every little program you use (eek!) this gets to be a maintenance problem. >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. I think you've missed the point. To make the ST truly user-friendly, the user shouldn't have to worry about any of this. ... >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, I didn't intend to _set_ a standard, just to open it up for discussion. Thanks for your compliments anyway... >good luck. above all, keep thinking! Uh, that will require a major effort on my part, but I'll try. ;-) plin -- ----- ---- --- -- ------ ---- --- -- - - - plinio@seas.ucla.edu This page intentionally left blank so that it could contradict itself.