🚀 go-pugleaf

In article <4897@wehi.dn.mu.oz> BAXTER_A@wehi.dn.mu.oz writes:
>QUESTION 1:
> Is it possible to mount a device (has a handler, but no *.device in 
> devs:) with C code. [?]

Answer : Yes. (ok so I'm being a smart ass) Remember that there are two 
concepts here that you may be confusing. A *device* generally has a 1:1 
correspondence with a resource such as one or more floppy drives, a *handler*
can have a many to one correspondence such as a file system or port handler.
Now the Mount command, generally mounts a "handler" and part of that 
function includes telling the handler what device it should be handling.
Of course some handlers like "SPEAK:" don't need to know the device because
there is only one that they will talk to, namely narrator.device. 

Anyway, all this is just setup, no one really cares until the Handler gets
a startup packet and actually has to go out looking for the device. It will
do an OpenDevice() on the device usually and if it *isn't* already in the
device list that Exec maintains, Exec will try to read it off disk from 
the DEVS: drawer. The easiest way to get a driver installed in memory
without a *.device file, it to put it into the Expansion drawer on sys:
with an icon that has the appropriate tool types set. (See the 
expansion.library stuff in the RKM for more info) 

> I am currently using Execute("c:failat >Nil: <Nil:\n c:mount >Nil:  <Nil: 
> Plt:",0,0); but this has some problems (see below) so I was wondering if there
> is some other way that I've overlooked.

I presume you have a handler that is defined by the mount entry for PLT:,
if so you can use AddDosNode/MakeDosNode in the expansion.library directly.
Generally the mount command parses the parameters in the mountlist and
builds the structure to pass to MakeDosNode but you can just create it 
yourself if you already know the information. If you also want to make
your device code visible you could use the exec call AddDevice() which
will take your properly initialized device node and add it to the system
list so that your handler can find it.

>QUESTION 2:
>Could someone please send be example code to replace _main() in Lattice
>so that it doesn't open the window on Workbench, but does set up a process to
>reply to messages. 

I get the sense that this question is really "Since my answer to #1 needs
Execute(), I need the answer to this one."  Clearly if you use the 
subroutines to accomplish the mount then you don't need Execute and question
2 becomes moot. In either event you might look at the Commodore startup
code in the new RKMs it is available on a Fish Disk as well.

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
"If it didn't have bones in it, it wouldn't be crunchy now would it?!"