Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!eris!korn From: korn@eris (Peter "Arrgh" Korn) Newsgroups: comp.sys.mac Subject: Re: Multi-launch under Appleshare [was Re: What's the best NETWORK?] Message-ID: <3284@pasteur.Berkeley.Edu> Date: 11 May 88 21:54:00 GMT References: <1814@uhccux.UUCP> <1815@uhccux.UUCP> <2229@polyslo.UUCP> <1072@aucs.UUCP> <3191@pasteur.Berkeley.Edu> <1076@aucs.UUCP> Sender: news@pasteur.Berkeley.Edu Reply-To: korn@eris.UUCP (Peter "Arrgh" Korn) Organization: What, me organized??? Lines: 79 In <1076@aucs.UUCP>, paul@aucs.UUCP (Paul Steele) said: >In article <3191@pasteur.Berkeley.Edu> korn@eris.UUCP (That's me) writes: > >>I haven't used MacJANET, but I would be curious as to what happens when >>... The day after posting this, I got a chance to play with MacJANET a little. Cleared things up a bit... >...[comments about MacJANET and software list of apps. that are known > to work]... >Hypercard doesn't work under MacJANET if loaded from a read-only volume, >which is well know for Hypercard. MacJANET works in generally the same fashion that the old Paradise hard drives used: You use a MacJANET utility to partion the hard drive on your server into a MacJANET section, and a 'normal' section. Within the MacJANET section you then allocate fixed size partitions. Users can mount these fixed size partitions (no idea what the limit on # of vols. is), and get at what's on them. In your typical student environment, most partitions will be locked, or read-only. As far as I could tell, MacJANET doesn't do any magic when it comes to apps. that want to modify themselves, or want to write to the directory they are in. They simply cannot. So if, for instance, Macfoo, a word procesing program of yester-year, decided it *needed* to create a temporary file in the same directory that it is running from or die, it will die. Very few programs do this anymore. Most, in fact, will create temporary scratch files wherever they can. If they can't do so in the directory they are launched from, they'll try the boot volume, or the blessed system folder (typically local, should always be writable). HyperCard, in fact, works quite well with MacJANET (and not just version 1.2, which has some neat nifty new features for dealing with read-only media). The trick is to put the Home stack on a writable volume, preferable your local floppy (if we are assuming a typical student environment). The HyperCard application itself can reside on a locked volume -- it doesn't modify itself. However, unless you are using version 1.2, all of the stacks that you access must be writable. An excellent way to test if a program that you want to run will work on a MacJANET locked volume is to go up to a 2 floppy system, put an unlocked boot disk into one drive, and a locked non-boot disk with the application you wish to test into the other drive. If you can run the application without problems in this configuration, you should have no problems running it from a locked server volume. >We like MacJANET because it provides a pretty secure environment for our >software. In the next version due shortly it will also limit the number >of copies of a program in use, allowing us to buy fewer copies and restrict >the usage. More magic I'll have to see before I believe... By the way, all of the above statements reguarding run-ability of applications applies equally well to AppleShare volumes. If you were to set up a system with an AppleShare server, you could easily make a folder 'read-only' (which, in AppleShare terminology is called 'no make changes privilege') to students, and all software that runs from locked local disks should work without problems from that AppleShare folder. If that software has the 'shared' (often known as the 'cached') bit set, it should multi-launch without problems from a 'read-only' folder. However, software which attempts to *first* write temporary files to the same folder that they're launched from will *not* multi-launch well from folders that are 'write-enabled' unless their temporary file names are unique. That is to say, if Macfoo is launched from two different workstations from a folder that is 'write-enabled', and it creates a temporary filename 'temp.file' from both workstations in that folder, we're going to get the workstation's work clobbered. Hope I haven't hopelessly confused people with a less than perfect explanation.... Peter -- Peter "Arrgh" Korn korn@ucbvax.Berkeley.EDU {decvax,dual,hplabs,sdcsvax,ulysses}!ucbvax!korn