home *** CD-ROM | disk | FTP | other *** search
/ Fish 'n' More 1 / FishNMoreVol1.bin / more / code_examples / device / device.arc / DOSDEV.DOC < prev    next >
Text File  |  1987-10-23  |  4KB  |  110 lines
  1.  
  2.  
  3.     DOS device driver example for   AZTEC C
  4.  
  5.     By Matthew Dillon    ...  for all those people out there (including me!)
  6.     who have been struggling with DOS devices.    Placed in PUBLIC DOMAIN.
  7.  
  8.     Documentation is sorely lacking... even the RKM examples are sorely
  9.     lacking.  What programmers need is a working example ... as full an
  10.     implementation as possible to figure out all the little DOS quirks that
  11.     the manuals don't tell you about... Little things like when the driver
  12.     stores a string in a structure it must be in BCPL 'length first'
  13.     format.  There are literally hundreds of these babies!
  14.  
  15. REQUIREMENTS:
  16.  
  17.     -Aztec C compiler
  18.  
  19.     -A precompiled symbol table of all sub-directory include's (*/*.H). i.e.
  20.      one which does NOT include top level stuff like <stdio.h>.  Remember to
  21.      compile with the +L option when generating the symbol table.
  22.  
  23.      The LARGE data and code model will be used... It makes life *much*
  24.      easier.  This will NOT effect performance as there are very few global
  25.      elements anyway.
  26.  
  27.     *Alternately, no requirements if you just want to look at the source.
  28.  
  29. MOUNTLIST:
  30.  
  31.     You will want to change this to a more permanent file path, obviously,
  32.     though to run the example you might as well leave the driver in RAM:
  33.  
  34. THE EXAMPLE:
  35.  
  36.     How 'bout a RAM disk?  RAM disks use most DOS packet types...  Since my
  37.     RAM disk is not meant for normal usage, There will be a lot of minor
  38.     items I will leave unimplimented:
  39.  
  40.     -Date stamps are not kept up.  In fact, they are garbage.
  41.  
  42.     -I don't check out-of-memory conditions (remember! This is ONLY an
  43.      example!)
  44.  
  45.     -The driver EXIT's if no files exist and no references exist.
  46.      This allows you to FLUSH (make flush), which should remove all
  47.      knowlege of the driver allowing you to make source changes,
  48.      recompile, and re-reference without changing the name or
  49.      rebooting.  Normally, disk-like devices are permanent fixtures.
  50.  
  51.     -The ARCHIVE protection bit is not supported
  52.  
  53.     All packet types normally associated with a RAM disk are supported,
  54.     Most especially LOCKS, which *many* people have not been able to figure
  55.     out in the past.
  56.  
  57.  
  58. DEBUGGING:
  59.  
  60.     Since this is an example, FULL Debugging has been implemented.  Since
  61.     the DOS device driver cannot make DOS library calls itself (confusion
  62.     on the message port), CreatProc() is used to create a secondary process
  63.     which will do actual printing of the debugger messages.  The messages
  64.     are then sent to the debug process via a dedicated message port.
  65.  
  66.     Since Debugging causes a huge efficiency decrease, and since you are
  67.     going to want to fool around with the device, you can turn off debug
  68.     error message output by:
  69.  
  70.     CD test:
  71.     type debugoff    (will get an error, but debugging will be turned
  72.             off)
  73.  
  74.     alternately, 'type debugon' will turn it back on.
  75.  
  76.     The debugging code itself is a good example.
  77.  
  78. DOS:
  79.     Remember that most addresses are passed as BPTR's, and most strings are
  80.     passed as BPTR's to a BSTR (length in byte 0, string in bytes 1..N, no
  81.     'end' bytes).  The exceptions are obvious by looking at the code (at
  82.     least of the packet types supported).
  83.  
  84. DOS PECULARITIES NOT ADDRESSED:
  85.  
  86.     Newcli assumes it can open the file '*' on whatever device you specify
  87.     for the control terminal to get a duplicate stream.  This is how it
  88.     gets around CON-like devices which like to create separate processes
  89.     for each invocation.
  90.  
  91.     ACTION_DISK_INFO, when sent to a CONSOLE device, will return the window
  92.     associated with the console as follows:
  93.  
  94.         id_VolumeNode   =    console window
  95.         id_InUse        =    console IO blvock
  96.  
  97.  
  98.     There are probably many more.
  99.  
  100.  
  101.                     Matthew Dillon
  102.  
  103.                     ARPA: dillon@ucbvax.berkeley.edu
  104.                     UUCP: ..!ihnp4!ucbvax!dillon
  105.                     SNAIL:    Matthew Dillon
  106.                         891 Regal Rd.
  107.                         Berkeley, Ca. 94708
  108.  
  109.  
  110.