***************************************************************************
*
*	null.doc	20 Nov 88	Gunnar Nordmark
*
***************************************************************************

What is null:?

Tt's a new animal that you will be glad to put in your private ZOO,
(also known as the L: directory).

"Oh no, not another silly handler!" you cry, but read on!

In the very good article by Matt Dillon, AMIGALINE#D1, that I've included
in this distribution, the problem is fully explained.
I suggests that you take a look at the file amigaline-D1 before reading
further.

As Matt explains, the NIL: device is not a "real" device. In fact it is no
device at all in the physical sense. It is just an Amiga-DOS convention
that says: If you have a process-identifier for a device, and that identifier
is just a null pointer, then that "identifier" referrs to the NIL: device.

Did you get that? I'm not surprised if you didn't, because it *is* strange.

I'll try to explain:
Every normal dos-device is a process that have an own private message-port
that is used as a comunication link between AmigaDOS and the device.
Since you must know the address of the message port of a device in order
to comunicate with it, it is a natural decision that that address also is
used as the identifier of the device.

AmigaDOS has a function called DeviceProc() that finds the address for you.
If you say  port=DeviceProc("RAM:")  you get the address of the message prot
of the RAM: device.

Now the strange part:
If you try  port=DeviceProc("NIL:")  and then sends packets to that port
you'll crash the machine instantly.
Why? 
Because NIL: has *no* message-port at all.
When you have a NULL-pointer as identifier for a handler, the identifier
referrs to the NIL: device.

The *only* reason I can think of for this lack of generality, is efficiency.
You save time, becase you don't have to comunicate with a device.
You save memory, because you don't have to start a new process named NIL:.

But unfortunately this has a lot of drawbacks. Most of them are deadly.
The reason is that AmigaDOS does *not* allways check for the NIL: oddity.
Sometimes it thinks that the NULL-pointer (the NIL: identifier) is a
valid message port and merilly sends messages to it. Poof!

The solution is a new dos-device called "null:".
This is a real dos-device that has has its own message port. It just doesn't
do anything useful. It behaves exactly as NIL: i.e. you can write to it,
and read from it (then you get EOF).

The great thing about null: is that you can say

		extern APTR DeviceProc();
		proc->pr_ConsoleTask = DeviceProc("null:");

and you'll be able to close the console. (see amigaline-D1)

Any process can open null: as many times as it like.
And it doesn't matter if you say
		Open("null:" MODE_OLDFILE);
		Open("null:*" MODE_NEWFILE);
		Open("null:@#$@!!" MODE_OLDFILE);
		Open("null:foo.bar" MODE_OLDFILE);
everything works.

To install null: just append the included mountlist to DEVS:MountList
Copy null-handler to your L: directory and say  Mount null:
Note: If you use OS2.1 or higher, simply copy the contents of the
devs/dosdrivers directory to your devs:dosdrivers directory.

I have used it for half a year now with no problems at all. I have a
written my own version of AmiCron that uses null: as pr_ConsoleTask.
That means I now have a cron-deamon that doesn't requires a window
to run!

I wan't to thank Steve Drew who wrote the aux-handler that was posted
to the net last year. I've "stolen" all the code from that handler. :-)
I hope you don't mind Steve.

  - Gunnar

  Gunnar Nordmark
  Nora strand 5
  S-182 34 DANDERYD
  SWEDEN

  gno@stacken.kth.se
  stacken.kth.se!gno@uunet.uu.net  (if the above doesn't work)
  gno@SESTAK.BITNET