Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!microsoft!w-edwinh
From: w-edwinh@microsoft.UUCP (Edwin Hoogerbeets)
Newsgroups: comp.sys.amiga
Subject: Resident device (was Re: Hooks and ladders)
Keywords: Spam
Message-ID: <9142@microsoft.UUCP>
Date: 23 Nov 89 20:05:41 GMT
References: <4299@nigel.udel.EDU> <128072@sun.Eng.Sun.COM>
Reply-To: w-edwinh@microsoft.UUCP (Edwin Hoogerbeets)
Organization: Microsoft Corp., Redmond WA
Lines: 60

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