Which SDK version number to find start.c ?
Thereeafter, what the meaning of DosNode->dn_Task ?
Would you like to explain ?
It is to AmigaDOS to close these extra handler copies?
The start.c prototype is shown in include/dos/startup.h
It is the initial entry function that DOS starts all commands and processes from,
in the form of a C-language subroutine, this includes DOS handlers and filesystems.
Returning from the _start() function is how to end a DOS process. (or a program)
For programs using the CLIB startup, it handles the _start() entrypoint and your
code will instead begin execution at main().
The devicenode->dn_Task is now called devicenode->dn_Port since V49+ or there abouts,
as all the "_task" references that were NOT actual pointers to tasks or processes,
these were changed decade/s ago, to reflect the actual use of these fields, such as;
dn_Task, dol_Task, pr_ConsoleTask, fl_Task, and others that can be found in
the include/dos/obsolete.h include file. The names are now xxx_Port as they
all contain pointers to a message port. The dos/obsolete.h files should only
be included for ancient source code compatibility, otherwise use the new names.
AmigaDOS handlers (and filesystems) are started by DOS when the devicenode in the
doslist is referenced by any of the DOS functions that accept a string descriptor.
After DOS starts the handler process, it sends an ACTION_STARTUP dospacket to it,
this provides the handler process startup information and acts as a handshake or
syncronising mechanism for DOS.
The DOS handler can exit in a few ways, one way is to be sent an ACTION_SHUTDOWN
dospacket, (eg; like from the c:dismount command).
The next is on a startup error such as being unable to allocate something.
Finally, a deliberate exit strategy, this last one is nomally performed and dependant
on the type of handler being used.
For example; a filesystem handler will initialise devicenode->dn_Port to the packet
(or vector) port when it starts up from the ACTION_STARTUP packet, it will stay running
and waiting for packets to be sent to it, it will generally remain running until it is
dismounted, all acccesses to the volume/device name will be sent by DOS to the message
port that was set in devicenode->dn_Port.
DosPacket handlers will only process requests sequentially, Vector-port based
filesystems can process multiple calls concurrently like an amiga library API,
as well as handle DosPacket requests too.
When a filesystem handler dismounts, the handler process itself sets dn_Port to NULL
on the way out, this tells DOS to start a new handler process on the next access from
anything, from any DOS calls that take a string based descriptor.
The CON: device is different from normal DOS handler processes, in that it automatically
exits when the filehandle that was Open()'ed is finally Close()'ed.
When DOS starts up a CON: handler process, (when someone calls Open("con:///") )
the basic proceedure is the same as any other handler, but in this case, when the handler
is started and sent the ACTION_STARTUP dospacket, it NEVER initialises devicenode->dn_Port,
it stays NULL instead of setting it to a common shared handler message port for everyone.
This has the effect that EVERY TIME someone calls with a Open("con:///") specification,
DOS will start a new and PRIVATE handler process instance, just for that filehandle.
If someone else did it again, you would have two handler processes running, each one is
PRIVATE for the filehandle that was opened.
The handler process itself exits when the filehandle is closed.
Take a look at the process list and open some CLI windows, you will see a CON handler
process for each one, and they exit when you do an "endcli".
I hope this helps you get what is going on.
) Read the ACTION_STARTUP in dos.dospacket.doc
) Read the introductory document at the beginning of dos.dospacket.doc
) Run the FSVPTool included in the SDK, it will create a skeleton filesystem and give
some insights on how they should look. Ignore the vector-port specific stuff for
your handler and look at the packet handler code specifically and exit methodology.
) Read the DOS GetdeviceProcFlags() function autodoc in dos.doc