guido@cwi.nl (Guido van Rossum) (06/24/88)
In article <4812@husc6.harvard.edu> singer@endor.UUCP (Rich Siegel) writes: >and furthermore, the compilers save configuration settings in themselves, >subject to a user command. Yes. I hate this. Apple has long declared that applications should not modify themselves to set options etc., but use a "profile" file instead, and exactly for this reason (shared volumes). It's probably too late with 3.0 out and everything, but I think that options should be stored in the project files, especially options that change the syntax of the language or affect properties of the generated code. -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@piring.cwi.nl or mcvax!piring!guido or guido%piring.cwi.nl@uunet.uu.net
Michael_mkahl_Kahl@cup.portal.com (06/27/88)
>>and furthermore, the compilers save configuration settings in themselves, >>subject to a user command. >Yes. I hate this. Apple has long declared that applications should not >modify themselves to set options etc., but use a "profile" file instead, >and exactly for this reason (shared volumes). It's probably too late >with 3.0 out and everything, but I think that options should be stored >in the project files, especially options that change the syntax of the >language or affect properties of the generated code. 3.0 does indeed store all options on a per-project basis. It also retains the ability to store default options -- these are the options that will be assigned to newly created projects. Default options continue to be stored in the application itself, not in a separate "profile" file. It is all very well that Apple has "declared" that we should be shareable, but the fact is we don't *want* to be shared. We'd prefer that each user purchase a separate copy. -- Michael Kahl, Symantec
thomas@uvabick.UUCP (Thomas Fruin) (06/30/88)
Michael Kahl writes: > We'd prefer that each user purchase a separate copy. Still, there are many occasions where people want to save _disk_ space, and are not trying to save money by cheating vendors out of legitimate earnings for their products. Right now I'm working on a floppy-only Macintosh Plus (most of the machines on the AppleTalk net here are) and an AppleShare server is a real help. If programs don't run from the server, they simply won't be bought. In the meantime I've been playing around with MPW, and think I've found a way to keep even more files on the server as opposed to your own floppy disks (if you have a hard disk this is obviously not of interest to you). You _can_ put the MPW Shell on the server, but you have to be aware of some potential problems. These problems are not serious though, and may make it worth your while. The MPW Shell and some of its command files will need modification, as follows: 1. Change the Startup file to get the UserStartup file from your own System Folder instead of the Shell directory, by changing the last line to: Execute "{SystemFolder}UserStartup" 2. Move the UserStartup file to your System Folder. 3. You will also want to have your own copy of the WorkSheet. This causes the first (minor) problem. The name of the Worksheet file is stored as one of the strings in resource STR# 128 in the shell. By changing this name to the full pathname of a file in the System Folder of your startup disk, you can tell MPW Shell to look there. Please note that _everyone_ on the net using the MPW Shell will now have to give their startup disk the same name. 4. There's another entry in the STR# 128 resource, called MPW.Scratch. Also change this to the full pathname of a file in the System Folder of your startup disk. 5. Now move the Worksheet to your System Folder (MPW.Scratch is created by the shell on the fly). 6. Modify the Suspend and Resume command files (in the shell direc- tory) to use the temporary file in the System Folder of your startup disk instead of the shell directory. This means changing lines such as: End > "{ShellDirectory}SuspendState" to End > "{SystemFolder}SuspendState" 7. The last problem is only a BEWARE, and not something I could work around: during input/output redirection, the shell creates the temporary file MPW.Pipe (this name is hardcoded somewhere in CODE segment 2). I could not change the directory this file gets created in by using FEdit ... So if two or more people use pipes at the same time, at least one of them will get an error that the file MPW.Pipe is busy. Luckily the file is _only_ busy during that time, and not during the whole invocation of the MPW Shell. So it's not as bad as it sounds. As long as you're editing or running a simple Make, even the shell will multitask. 8. The final step is to make MPW Shell 'locked' and 'cached' (in ResEdit 1.2d1). As usual, cached still means shared. You might run into one or two command files that need a little modi- fication, but the above setup should work quite well. Of course they recommended way is to keep the MPW Shell and its command files on a separate disk altogether, but as long as you are aware of the limi- tations, this solution saves even more space. -- Thomas Fruin fruin@hlerul5.BITNET University of Leiden thomas@uvabick.UUCP University of Amsterdam dibs@well.UUCP hol0066.AppleLink 2:512/114.FidoNet The Netherlands