limonce@pilot.njin.net (Tom Limoncelli) (12/13/88)
Wait a minute! I really like the s:Startup-Assigns idea but maybe
we're going about this the wrong way.
We need a way to allow software to be executed from any location while
it's current working directory is another place and it has to be able
to access aux. files in yet some other place. The only other
requirement that I can think of is the need to be able to install
.devices and .libraries and -handlers. In other words, let's define
what needs to be done then design a solution. Startup-Assigns is nice
but isn't their more to life than ASSIGNs? ASSIGNs need to be changed
when things get moved and if a person multitasks a program one
S:Startup-Assign can't do all the ASSIGN MYAPP: ""'s required, can it?
Why can't someone that has solved the above problems post their code,
C-A can endorse it, and everyone can use it. :-)
If I was a new user, I think the most obvious thing to want to do is
to run the application from whereever I copy it. If the docs said
that a certain file Drawer had to be in the same directory I would be
happy copying it along. Aux. files could go in that subdirectory
(called AppFiles for example).
Now it's easy to find aux files; they're in the directory the program
came from plus a directory (where_they_came_from/BringMeAlong/*).
Maybe .devices and -handlers can go there too and be launched from
there also? (or is that real difficult?). Does C-A specify a
"proper" way to do things like that? Maybe they should :-). If they
aren't there the app can check for DEVS: or L:. Now the experienced
users can copy the .devices, etc to the DEVS: directory, etc.
Now the only problem is how to the projects find their tools.
TOOLS=ToolName:ToolNameProgram is the common way to do this. Maybe
the first time an application is run it should check for an ASSIGN
called ToolName: and if it doesn't exist it or if it is wrong the
application can add it to S:System-Assigns. Now, when a user
moves/installs an application they just have to run it once without a
project to have it autoinstall.
Is there something inherently wrong with this? It sounds good to me.
(famous last words!)
The other method that I thought of was to not re-invent the wheel and
find out what Mac users do. I've never heard of this kind of
discussion with Mac users. (and if their OS does something "extra" to
help out maybe this could be in 1.4?) :-)
-Tom
--
Tom Limoncelli Drew University Madison NJ 201-408-5389
tlimonce@drunivac.Bitnet limonce@pilot.njin.net
"Fences make good neighbors" -Frost "I want an MMU" -Me
Standard disclaimer? No, we're still on the dpANS disclaimer.jms@antares.UUCP (joe smith) (12/14/88)
In article <Dec.13.01.59.36.1988.22589@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >Now the only problem is how to the projects find their tools. >TOOLS=ToolName:ToolNameProgram is the common way to do this. [stuff deleted] >The other method that I thought of was to not re-invent the wheel and >find out what Mac users do. I've never heard of this kind of >discussion with Mac users. (and if their OS does something "extra" to >help out maybe this could be in 1.4?) :-) > Tom Limoncelli Drew University Madison NJ 201-408-5389 I have heard nasty things when the Macintosh DeskTop file fills up. Exceed 228k and you're dead (or something to that effect). As I understand it, each tool is registered with Apple to get a unique 4-byte ID. Whenever a tools is moved, its new location is written in the DeskTop, overwritting any previous entry with that ID. When a project icon is selected, the Finder looks at the 4-byte ID, grunges thru the DeskTop, and launches the tool. I don't know how it handles having version 2a of a program in one directory and version 2b in another. I don't know if it cares if a program is copied from the hard disk to a floppy (I'd hate to see it remember the copy on the floppy and forget the hard disk. There was some discussion on this subject here about 5 months ago - the consensus was "let's not do it the Mac way". I'm sure some Mac techie will provide more reasons pro and con. -- +----------------------------------------------------------------------------+ | TYMNET:JMS@F29 CA:"POPJ P," UUCP:{ames|pyramid}oliveb!tymix!antares!jms | | INTERNET:(Real Soon Now) Amiga Hacker PHONE:Joe Smith @ (408)922-6220 | +----------------------------------------------------------------------------+
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (12/16/88)
The problem I see in this discussion of s:Startup-Assigns is I don't
want the assignments hanging around indefinitely. For one thing, another
application might use the same logical device name. So when I start an
application that requires assignments I execute a little script file that
does the assignments. For the Lattice C compiler, for example, I execute
StartLC. StartLC does several assigns (assign LC: Lattice_C_5.0.1/C,
assign QUAD: RAM:, assign INCLUDE: Lattice_C_5.0.2:lib, etc.) When I'm
through with that application I execute another script file called EndLC
which deletes those logical device assignments (assign LC:, assign
INCLUDE:, assign QUAD:, etc.). That restores my environment to its
pre-StartLC condition. Now that I have IconX in WB1.3 I can execute those
files from the Workbench.
Of course, the foregoing doesn't solve the problem of how to oopy an
application to your hard disk and have the assign statements in the script
files changed automatically. But I guess you could write a script file
that would copy all the application's files to a directory name specified
as a parameter. Then it could write a StartApplication script file using
that same directory.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...codas!usfvax2!jc3b21!fgd3
...uunet!pdn!jc3b21!fgd3dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/18/88)
: The problem I see in this discussion of s:Startup-Assigns is I don't :want the assignments hanging around indefinitely. For one thing, another :application might use the same logical device name. So when I start an Well, assigns don't really take up *that* much memory. Apart from the problem you mentioned of duplication of names by different applications, which will be a very minor problem, there really is no reason not to have them all assign'd at startup. If you rez assign actual execution of even several dozen will be fast. I myself have 50 custom assigns in mine. : Of course, the foregoing doesn't solve the problem of how to oopy an :application to your hard disk and have the assign statements in the script :files changed automatically. But I guess you could write a script file :that would copy all the application's files to a directory name specified :as a parameter. Then it could write a StartApplication script file using :that same directory. You would need a standard install program, or the install program that comes with the application, which would *modify* the assigns if they already exist in s:startup-assigns, or *add* them if they do not already exist. This is extremely trivial to write, and all the user would have to do is click on an 'install' icon. Or, even better, you could build it into the application ... it simply checks to see if the executable is where the assign says it is and if not, re-install the assigns. -Matt