home *** CD-ROM | disk | FTP | other *** search
/ Amiga Elysian Archive / AmigaElysianArchive.iso / newc_dev / null.lzh / null.doc < prev    next >
Text File  |  1989-11-04  |  4KB  |  96 lines
  1. ***************************************************************************
  2. *
  3. *    null.doc    20 Nov 88    Gunnar Nordmark
  4. *
  5. ***************************************************************************
  6.  
  7. What is null:?
  8.  
  9. Tt's a new animal that you will be glad to put in your private ZOO,
  10. (also known as the L: directory).
  11.  
  12. "Oh no, not another silly handler!" you cry, but read on!
  13.  
  14. In the very good article by Matt Dillon, AMIGALINE#D1, that I've included
  15. in this distribution, the problem is fully explained.
  16. I suggests that you take a look at the file amigaline-D1 before reading
  17. further.
  18.  
  19. As Matt explains, the NIL: device is not a "real" device. In fact it is no
  20. device at all in the physical sense. It is just an Amiga-DOS convention
  21. that says: If you have a process-identifier for a device, and that identifier
  22. is just a null pointer, then that "identifier" referrs to the NIL: device.
  23.  
  24. Did you get that? I'm not surprised if you didn't, because it *is* strange.
  25.  
  26. I'll try to explain:
  27. Every normal dos-device is a process that have an own private message-port
  28. that is used as a comunication link between AmigaDOS and the device.
  29. Since you must know the address of the message port of a device in order
  30. to comunicate with it, it is a natural decision that that address also is
  31. used as the identifier of the device.
  32.  
  33. AmigaDOS has a function called DeviceProc() that finds the address for you.
  34. If you say  port=DeviceProc("RAM:")  you get the address of the message prot
  35. of the RAM: device.
  36.  
  37. Now the strange part:
  38. If you try  port=DeviceProc("NIL:")  and then sends packets to that port
  39. you'll crash the machine instantly.
  40. Why? 
  41. Because NIL: has *no* message-port at all.
  42. When you have a NULL-pointer as identifier for a handler, the identifier
  43. referrs to the NIL: device.
  44.  
  45. The *only* reason I can think of for this lack of generality, is efficiency.
  46. You save time, becase you don't have to comunicate with a device.
  47. You save memory, because you don't have to start a new process named NIL:.
  48.  
  49. But unfortunately this has a lot of drawbacks. Most of them are deadly.
  50. The reason is that AmigaDOS does *not* allways check for the NIL: oddity.
  51. Sometimes it thinks that the NULL-pointer (the NIL: identifier) is a
  52. valid message port and merilly sends messages to it. Poof!
  53.  
  54. The solution is a new dos-device called "null:".
  55. This is a real dos-device that has has its own message port. It just doesn't
  56. do anything useful. It behaves exactly as NIL: i.e. you can write to it,
  57. and read from it (then you get EOF).
  58.  
  59. The great thing about null: is that you can say
  60.  
  61.         extern APTR DeviceProc();
  62.         proc->pr_ConsoleTask = DeviceProc("null:");
  63.  
  64. and you'll be able to close the console. (see amigaline-D1)
  65.  
  66. Any process can open null: as many times as it like.
  67. And it doesn't matter if you say
  68.         Open("null:" MODE_OLDFILE);
  69.         Open("null:*" MODE_NEWFILE);
  70.         Open("null:@#$@!!" MODE_OLDFILE);
  71.         Open("null:foo.bar" MODE_OLDFILE);
  72. everything works.
  73.  
  74. To install null: just append the included mountlist to DEVS:MountList
  75. Copy null-handler to your L: directory and say  Mount null:
  76.  
  77. I have used it for half a year now with no problems at all. I have a
  78. written my own version of AmiCron that uses null: as pr_ConsoleTask.
  79. That means I now have a cron-deamon that doesn't requires a window
  80. to run!
  81.  
  82. I wan't to thank Steve Drew who wrote the aux-handler that was posted
  83. to the net last year. I've "stolen" all the code from that handler. :-)
  84. I hope you don't mind Steve.
  85.  
  86.   - Gunnar
  87.  
  88.   Gunnar Nordmark
  89.   Nora strand 5
  90.   S-182 34 DANDERYD
  91.   SWEDEN
  92.  
  93.   gno@stacken.kth.se
  94.   stacken.kth.se!gno@uunet.uu.net  (if the above doesn't work)
  95.   gno@SESTAK.BITNET
  96.