home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / os2 / programm / 4368 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  3.5 KB
  1. Xref: sparky comp.os.os2.programmer:4368 comp.os.os2.apps:5452
  2. Newsgroups: comp.os.os2.programmer,comp.os.os2.apps
  3. Path: sparky!uunet!cs.utexas.edu!uwm.edu!csd4.csd.uwm.edu!tanith
  4. From: tanith@csd4.csd.uwm.edu (Michael D Kretzer)
  5. Subject: Re: Writing Device Drivers for OS/2 2.0
  6. Message-ID: <1992Aug21.174205.25432@uwm.edu>
  7. Originator: tanith@csd4.csd.uwm.edu
  8. Sender: news@uwm.edu (USENET News System)
  9. Reply-To: tanith@csd4.csd.uwm.edu
  10. Organization: University of Wisconsin - Milwaukee
  11. References: <1992Aug21.151852.8673@natinst.com>
  12. Date: Fri, 21 Aug 1992 17:42:05 GMT
  13. Lines: 52
  14.  
  15. From article <1992Aug21.151852.8673@natinst.com>, by ramdas@natinst.com (Malathi Ramdas):
  16. > 
  17. >     I am in the process of writing an instrument control character based devcie
  18. > driver for OS/2 2.0. The device driver architecture under OS/2 2.0 is still
  19. > 16-bit. Does that mean that I need to generate 16-bit device driver code. (ie:
  20. > generate code using a 16-bit compiler and 16-bit linker). Also, what would
  21. > be the address format of the data address in an IOCTL request packet passed by
  22. > the kernel on behalf of an application making a DosDevIOCtl API call to my
  23. > device driver? Would it be in a 16:16 (selector:offset) form or a 0:32 
  24. > address form (flat address)? Would it depend on whether the application is 
  25. > 16-bit or 32-bit? From what I read all 16-bit processes  get tiled
  26. > into a flat virtual address space. I hope to hear that all virtual addresses
  27. > that gets passed to my driver is in a 0:32 bit form.
  28.  
  29. Right now, PDDs (Physical Device Drivers) are 16-bit.  However, object
  30. files must be linked with the new LX linker (i.e. link386) if they are
  31. OS/2 2.0 device drivers and not OS/2 1.x device drivers (although most
  32. 1.x device drivers work just fine under OS/2 2.0).
  33.  
  34. Request packets are passed to the device driver from the operating system
  35. in 16:16 form, regardless of the type of program that made the IOCTL
  36. request.  The request is sent to the operating system first, not the device
  37. driver, and it creates a request packet for the device driver in 16:16 form.
  38.  
  39. Be aware that VDDs (Virtual Device Drivers) which are used for DOS are
  40. 32-bit (just to confuse the issue).
  41.  
  42. >    Is there a 32-bit assembler that goes out with OS/2 2.0. I still have the
  43. > masm assembler that is 16-bit. I have not received anything along with toolkit
  44.  
  45. MASM 6.0 is a 32-bit assembler (when used in conjunction with LINK386).
  46. One of the updates from MASM 5.1 was to include support for the FLAT model.
  47. OS/2 2.0 programming considerations are even mentioned in the manual
  48. explicitly.  (MASM 6.0 will also produce 16-bit executables, of course).
  49. In conjunction with the Toolkit, MASM 6.0 is a full 32-bit/16-bit OS/2 2.0
  50. assembler.
  51.  
  52. I have written several OS/2 2.0 device drivers personally, and have
  53. used MASM 6.0 for all of them.  I typically use a C compiler to write
  54. the bulk of the driver code (Microsoft C 6.0 and IBM CSet/2),however,
  55. and Assembler for time-critical routines and a few miscellaneous other things.
  56.  
  57. I urge you to check out the book 'Writing OS/2 2.0 Device Drivers in C'
  58. by Steven J. Mastrianni.  He shows how a good portion of an OS/2 2.0
  59. device driver can be written in C, thus saving a great deal of time
  60. in the development cycle of your driver.  Also, Mastrianni's book includes
  61. a good number of device driver source code listings that are quite scarce
  62. in other Device Driver books.  None of these books replace IBM's
  63. Physical Device Driver Reference from the Technical Library, though...this
  64. is required reading for anyone considering writing a device driver (it's
  65. just very short on giving practical source code examples).
  66.  
  67.