w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) (11/24/89)
In article <128072@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >Now it seems a wee bit silly to have >a resident icon, but I thought "Why not?" Can we make a workbench accessible >user interface to the list of Resident programs? Any ideas on what it >should look like? Generally resident programs are for the CLI environment >and don't know about WB parameter passing, would it help to have some sort >of notification on the resident command ? I was thinking that if you dragged >a tool icon out of it's disk drawer window and onto the backdrop that should >make it resident. Then you could just click on it and go. Comments? Ideas? I like that idea, Chuck! But how about an explicit resident device? Maybe call it res:. It would work like any other ram drive device, but it would store things in a "residented" way in RAM, such that you can execute them in place. And to get icons, you just click on the res: device and up pops a window with all your residented programs in it. Drag an icon from df0: to res: and you have just res'ed your program! If your program was a pure executable, you'd only get one copy in memory at a time. If it was anything but a pure executable, the res: device would act like any other ram drive. Or, you could access it from the CLI (or your favourite shell). Just cd to res:, do a directory to find your program and execute it. I don't know much about the way things are residented. I suppose it is pre-LoadSeg-ed code that gets a new data segment for each invocation. We'd need a l:ResidentFile-Handler file system, and a residenting RAM device. Second (sort of related) topic: A friend (Hi Stephan!) and I were talking about CrossDos and the Format program. The code to format a disk is in the Format program itself. This means that you can't format PC floppies (or any other file system format) other than the Amiga's two using the Format program. It would be nice if you could. Would it not be more object oriented, then, to include the format code *with* the file system handler code? How about a new ACTION_FORMAT DOS-packet which will tell a handler to format the medium the way that only it knows best. This way, the format program becomes a simple "send DOS-packet" program that could format any installable file system. Heck, put a call in dos.library to do it. Along the same lines, since the handler also knows the logical layout of the medium, it should be the one doing the validation, shouldn't it? An ACTION_VALIDATE packet should be in order. Then, the Unix fsck program mentioned earlier would become like Format: a simple, small, and above all, flexible utility. Yes? No? Maybe? Edwin "I think I'll stop time traveling to explore the other great mystery of the Universe: women." - Doc in Back to the Future II
root@ccave.UUCP (Juergen Hermann) (11/30/89)
In article <9142@microsoft.UUCP> w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) writes: >Along the same lines, since the handler also knows the logical layout of >the medium, it should be the one doing the validation, shouldn't it? An >ACTION_VALIDATE packet should be in order. Then, the Unix fsck program Well, we have this already, and it's called ACTION_INHIBIT(FALSE). However, we don't have ACTION_FORMAT and I think it's a good idea to have that. -- // Juergen Hermann root@ccave.smurf.ira.uka.de \X/ 75 Karlsruhe 1, FRG Fido: 2:241/2.1212@FidoNet
rodd@dasys1.UUCP (Rod Dorman) (12/01/89)
In article <9142@microsoft.UUCP> w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) writes: > ... The code to format a disk is in the Format program itself. > ... >Would it not be more object oriented, then, to include the format code >*with* the file system handler code? Two thoughts come to mind on this subject: 1) This will inflate the size of the handler for an action that for things like hard disks will seldom be used. 2) How will the format program be "enhanced" to recognize additional file system selection keywords beyond FFS and NOFFS (e.g. MSDOS40 for 40-tracks or MSDOS80 for 80-tracks) or should that be determined strictly by mountlist entries? -- Rod -- Rod Dorman rodd@dasys1.uucp Big Electric Cat Public Unix ...!cmcl2!dasys1!rodd "The ships hung in the sky in much the same way that bricks don't"
w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) (12/05/89)
In article <11330@dasys1.UUCP> rodd@dasys1.UUCP (Rod Dorman) writes: >In article <9142@microsoft.UUCP> w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) writes: >> ... The code to format a disk is in the Format program itself. >> ... >>Would it not be more object oriented, then, to include the format code >>*with* the file system handler code? >Two thoughts come to mind on this subject: >1) This will inflate the size of the handler for an action that for >things like hard disks will seldom be used. You could easily have the handler LoadSeg() an "l:FFS-Validator" or an "l:MSDOS-Validator" when it needs it and remove it later. Then, it wouldn't be hanging around in memory when it isn't used, and still be called from the handler. To install a file system in this scenario, you copy l:new-handler, l:new-validator, devs:new.device (if necessary), and put something in your mountlist. And format will work with it. >2) How will the format program be "enhanced" to recognize additional >file system selection keywords beyond FFS and NOFFS (e.g. MSDOS40 for >40-tracks or MSDOS80 for 80-tracks) or should that be determined >strictly by mountlist entries? Yes, I think so. One mountlist entry, one virtual device (and justice for all ;-). You can specify 40 or 80 tracks with the Low and HighCylinder parameters in the mountlist. Or you can specify "options" by having a different device name (ms40: vs. ms80:). Conman, for example, acts differently went you mount it as pip: or as something else. Someone (I think it was Dave Haynie) said that FFS and NOFFS are going away in 1.4 anyways, since the file system can be determined from the device name. Edwin