DOS-handler completion with AmigaOS4.1Final

A forum for general AmigaOS 4.x support questions that are not platform-specific
User avatar
Posts: 42
Joined: Sat Aug 11, 2012 10:17 am

Re: DOS-handler completion with AmigaOS4.1Final

Post by gdridi »

polluks wrote: Sun Sep 12, 2021 8:30 pm For DOS basics I still recommend the Guru Book
Thank you, already got mine 1999 English edition.

Don’t think it’s cover, because we need to go cover on the code console, shell code for ‘*’ or CONSOLE: !

The pointer was nice.

User avatar
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 199
Joined: Mon Aug 15, 2011 9:20 am
Location: Brisbane, QLD. Australia.

Re: DOS-handler completion with AmigaOS4.1Final

Post by colinw »

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 best,

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.

Additional reading;
) 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
User avatar
Posts: 42
Joined: Sat Aug 11, 2012 10:17 am

Re: DOS-handler completion with AmigaOS4.1Final

Post by gdridi »

…DOS takes care of starting up the handlers for you.

This happens automatically when something accesses the device name in the doslist.
Specifically when something calls the IDOS->GetDeviceProc[Flags] function.

I hope this helps.
Yes, it’s clear.

Thereafter, the meaning of DosNode->dn_Task is to allow the creation of a new process each time "the device name in the doslist is accessed". As you said above.

Code: Select all

*	Null : Causes a new process to be created on next reference

DosNode->dn_Task = Null;

But, when
I use the cat program, like

Code: Select all

cat <ACON: >ACON:
is ok.

But the standard AmigaDOS:

Code: Select all

copy ACON: to ACON:
creating me a lot more six (6) handlers ?

Is it bug ? Or simply internal beginnings of job commands. Afterwards this is only visible with DosNode = Null and type or copy commands.


Code: Select all

type * to ACON:
it’s ok but not

Code: Select all

type ACON: to ACON:

Code: Select all

type ACON: to *
In general, it seems that the type and copy commands are accessing the doslist too much when DosNode = Null only and my own ACON-handler. And as a consequence the dos-handler code is entered too much too, for nothing just leaving handlers opened…

Eventually, after probing action done when starting, I get out of these internal beginnings preventative access to test if I ‘m _in_ a stream input(ACTION_OPENXXX) opened. If no quit properly this handler-process.

Now, I can use my ACON-handler with type and copy AmigaDOS commands. Yeah !

This sound weird but it works,

The best,
Post Reply