home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / windows / programming / vxd < prev   
Encoding:
Internet Message Format  |  2004-05-05  |  38.6 KB

  1. Path: senator-bedfellow.mit.edu!dreaderd!not-for-mail
  2. Message-ID: <windows/programming/vxd_1083675484@rtfm.mit.edu>
  3. Supersedes: <windows/programming/vxd_1082292761@rtfm.mit.edu>
  4. Expires: 2 Jun 2004 12:58:04 GMT
  5. X-Last-Updated: 1997/08/06
  6. Newsgroups: comp.os.ms-windows.programmer.vxd,comp.answers,news.answers
  7. Subject: comp.os.ms-windows.programmer.vxd Frequently Asked Questions (FAQ)
  8. From: Berlin@vireo.com
  9. Organization: Vireo Software, Inc.
  10. Followup-To: comp.os.ms-windows.programmer.vxd
  11. Approved: news-answers-request@MIT.EDU
  12. Summary: This posting contains Frequently Asked Questions (with answers)
  13.         for the comp.os.ms-windows.programmer.vxd newsgroup.
  14.         This newsgroup is for people writing device drivers (VxDs)
  15.         for Microsoft Windows 3.x and Windows 95.
  16. Originator: faqserv@penguin-lust.MIT.EDU
  17. Date: 04 May 2004 12:59:16 GMT
  18. Lines: 958
  19. NNTP-Posting-Host: penguin-lust.mit.edu
  20. X-Trace: 1083675556 senator-bedfellow.mit.edu 570 18.181.0.29
  21. Xref: senator-bedfellow.mit.edu comp.os.ms-windows.programmer.vxd:32742 comp.answers:57058 news.answers:270863
  22.  
  23. Archive-name: windows/programming/vxd
  24. Posting-Frequency: bimonthly
  25. Last-modified: Aug 6, 1997
  26.  
  27.                         Frequently Asked Questions (FAQ)
  28.                                        for
  29.                         comp.os.ms-windows.programmer.vxd
  30.  
  31. Editor:   Stephen Lewin-Berlin (berlin@vireo.com).
  32. This document is copyright =A9 1995-1997 by Stephen Lewin-Berlin.
  33.  
  34. This document, like most FAQ documents, is a work in progress.  If you have
  35. comments, additional questions, or additional answers, please forward them=
  36.  to
  37. the editor. If you write a good Questions and Answer, it will almost=
  38.  certainly
  39. be included.
  40.  
  41. The FAQ is distributed to the newsgroup every few weeks, but the text is
  42. typically updated every few months. If you are reading this off-line, I
  43. encourage you to check for an updated copy. The most recent copy can be=
  44.  found on
  45. many newsgroup archive sites, and at=
  46.  ftp://ftp.vireo.com/biz/vireo/vxdfaq.txt.
  47.  
  48. There is no permanent archive of the newsgroup.  Recent articles may be=
  49.  located
  50. at http://www.dejanews.com.
  51.  
  52. Contributors:  Raymond Chen, Lee Fisher, Michael Geary,
  53.        Chris Marriott, Raymond Chen, Dan Norton,
  54.        Don Matthews, Karen Hazzah, Stephen Lewin-Berlin, and others.
  55.  
  56. Questions
  57.  Help, I need a driver for ...
  58.  What are the differences between device drivers for Windows 3.1, Windows=
  59.  3.11,
  60.  Windows 95, and Windows NT?
  61.  What is Windows Driver Model (WDM)?
  62.  What is a VxD?
  63.  Can I use Windows as a real-time operating system?
  64.  How do I access physical memory at (e.g. D000:0000) from a Windows 3.1
  65.  application?
  66.  What are the differences between embedded, installable, and conventional
  67.  device drivers?
  68.  I need to write a Windows device driver.  Should it be a DLL or a VxD?
  69.  How do I call an application from a VxD?
  70.  How do I handle interrupts in my VxD?
  71.  How do I access physical memory in my VxD?
  72.  How do I access memory from my application or DLL in my VxD?
  73.  How do I allocate memory from a Win16 application that can be accessed by a
  74.  VxD at interrupt time?
  75.  How do I share memory between a Win32 application and a VxD?
  76.  Give me an overview of Plug and Play
  77.  How do I initiate DMA from a VxD?
  78.  Do I need a Device ID for my VxD?
  79.  Can I write device drivers in C/C++, or must I use assembly language?
  80.  Why do I get linker warnings when I build my VxD?
  81.  Why can=92t I use MSVC 4.1 to build a VxD?
  82.  What commercial products are available to help develop VxDs?
  83.  How do I find someone to write a driver for me?
  84.  What books and magazines are available?
  85.  What on-line resources are available?
  86.  Are there classes in device driver development available?
  87.  Statement of interest
  88. =20
  89. Answers
  90.  
  91.  
  92. Help, I need a driver for ...
  93.      I'm afraid you've asked on the wrong group. This is a newsgroup for
  94.      discussions of device driver programming, not for requesting drivers=
  95.  for
  96.      particular devices. I'm sure you'll get help if you ask on the correct
  97.      newsgroup, which is "comp.os.ms-windows.setup".
  98.  
  99. What are the differences between device drivers for Windows 3.1, Windows=
  100.  3.11,
  101. Windows 95, and Windows NT?
  102.      Windows 3.x and Windows 95 share a common device driver model.  Windows=
  103.  NT
  104.      depends an a completely new, and completely incompatible driver model.
  105.      Let's discuss Windows 3.x and Windows 95 first, then a brief word about
  106.      Windows NT, and finally some discussion about compatibility between NT=
  107.  and
  108.      Windows 3.x/95.
  109.     =20
  110.      There are really two kinds of device drivers for Windows 3.x/95. =
  111.  Virtual
  112.      Device Drivers (VxDs) run as part of the privileged (ring-0) operating
  113.      system. VxDs can be thought of as a DLL for the operating system. =
  114.  Running
  115.      at ring 0, VxDs have complete access to the physical hardware, and can
  116.      access data in the address space of any DOS, Windows, or Protected Mode
  117.      application.  Under Windows 3.x, VxDs are typically given a .386 file
  118.      extension, and are loaded when Windows starts.  Under Windows 95, VxDs=
  119.  are
  120.      given the .VXD file extension, and may be loaded at startup time, or
  121.      dynamically loaded later.
  122.     =20
  123.      Windows 95 uses the same basic architecture for VxDs as Windows 3.x. =
  124.  Thus,
  125.      drivers written for Windows 3.x can be loaded on a Windows 95 system=
  126.  and
  127.      should generally work fine.  However, Windows 95 adds hundreds of new
  128.      services for VxDs, and extends the VxD architecture to allow full=
  129.  dynamic
  130.      loading, pageable code and data, access to the system registry,=
  131.  interfaces
  132.      to Win32 applications, and many other features.  VxDs written for=
  133.  Windows
  134.      95 cannot be loaded on a Windows 3.x system.
  135.     =20
  136.      In addition to VxDs, Windows 3.x/95 supports non-privileged (ring-3)
  137.      Communication and Printer drivers.  These are typically given .DRV file
  138.      extensions.
  139.     =20
  140.      Windows NT uses a new driver architecture, called "Kernel Mode=
  141.  Drivers".
  142.      Refer to the Windows NT DDK for detailed information.  VxDs are not
  143.      compatible with Windows NT.
  144.     =20
  145.      In order to provide compatibility between Windows NT and Windows=
  146.  95/3.x,
  147.      Microsoft provides "Miniport Drivers" for certain kinds of devices.
  148.      Miniports allow driver developers to write a single driver using a pre-
  149.      defined interface that is provided on both Windows NT and Windows=
  150.  95/3.x.
  151.      Microsoft provides Miniport drivers for SCSI, Printer, and Display=
  152.  devices.
  153.  
  154. What is Windows Driver Model (WDM)?
  155.      WDM, or Win32 Driver Model, was announced with much fanfare at the=
  156.  Windows
  157.      Hardware Engineering Conference (WinHEC) in March, 1996. WDM is a=
  158.  standard
  159.      API for device driver development under Windows that will be supported
  160.      across Windows 98 and Windows NT platforms. WDM will be based on the
  161.      Windows NT driver model, with additions to support Plug and Play.=
  162.  Although
  163.      the definition has not been released, Microsoft has said that a future
  164.      release of Windows 95 will support a subset of the Windows NT device=
  165.  driver
  166.      services and architecture.
  167.     =20
  168.      Microsoft will initially support new buses (such as USB and P1394) with=
  169.  WDM
  170.      =93class drivers=94. Support for sound and input devices is also=
  171.  planned
  172.      =93sooner rather than later.=94 No specific commitment has been made=
  173.  regarding
  174.      other classes of devices.
  175.     =20
  176.      It appears that VxDs will continue to be required for many classes of
  177.      drivers (for example, file system drivers for Windows 98) for the
  178.      indefinite future.
  179.  
  180. What is a VxD?
  181.      "VxD" stands for Virtual "something" Device, where 'x' stands for
  182.      "something". Microsoft often names drivers according to this=
  183.  convention,
  184.      thus "VKD" is the Virtual Keyboard Device, and "VPICD" is the Virtual
  185.      Programmable Interrupt Device.  VxDs are loaded into the protected=
  186.  (ring-0)
  187.      operating system address space, and have full access to the system
  188.      hardware.  VxDs can modify page tables directly, install true hardware
  189.      interrupt handlers, and generally wreak unrestricted havoc on the=
  190.  system.
  191.      Of course, just because you *can* doesn=92t suggest that you *should*.
  192.     =20
  193.      VxDs can be used to virtualize physical hardware by intercepting
  194.      application requests to use the hardware and arbitrating between=
  195.  requests
  196.      from different applications. In the more extreme case, VxDs can provide=
  197.  a
  198.      "virtual" device that is not actually present at all, by emulating the
  199.      behavior of a hardware device.  VxDs, by virtue of their privileged=
  200.  access
  201.      to the system, can also be used to implement software monitors,=
  202.  debuggers,
  203.      and to modify the behavior of other software on the system.
  204.     =20
  205.      VxDs under Windows 95 are also used to implement many other components=
  206.  of
  207.      the operating system, including the protected mode file system (IOS and
  208.      IFS), the Virtual Communication Architecture (VCOMM), plug and play
  209.      (Configuration Manager, etc.), and network transport and protocol=
  210.  drivers
  211.      (NDIS).
  212.  
  213. Can I use Windows as a real-time operating system?
  214.      Can you say =93semi-real-time?=94 Microsoft Windows is not designed as=
  215.  a real
  216.      time operating system. In other words, there are no guarantees of real=
  217.  time
  218.      performance. Let me repeat that. There are NO GUARANTEES for real time
  219.      latency under any version of Microsoft Windows. If your application
  220.      requires absolutely guaranteed real-time response, otherwise a plane=
  221.  will
  222.      crash, a nuclear reactor will melt down, or a patient may die, then DO=
  223.  NOT
  224.      use Windows as a platform. On the other hand, if you can design you
  225.      application (hardware/software) to accommodate some delays, you will=
  226.  find
  227.      that in most cases, Windows can provide excellent average latencies.
  228.     =20
  229.      For example, experiments run on a 486/66 system with no other programs
  230.      running suggest that a VxD can handle over 10,000 interrupts per second
  231.      without losing any of them. However, as soon as other software is=
  232.  loaded,
  233.      interrupts begin to be dropped.
  234.     =20
  235.      Windows is an =93open system=94 in the sense that applications and=
  236.  drivers can
  237.      disable interrupts at will. If one device driver disables interrupts=
  238.  for a
  239.      long period of time, no interrupt servicing will be performed. While=
  240.  new
  241.      drivers tend to keep interrupts disabled for very short periods, older
  242.      drivers and applications sometimes poll hardware devices and keep
  243.      interrupts disabled for unpredictable amounts of time.
  244.     =20
  245.      Of course, you can write a driver that disables interrupts and polls=
  246.  YOUR
  247.      hardware. The mouse and keyboard will not respond, and other device=
  248.  driver
  249.      developers will grumble and curse if your driver happens to running on=
  250.  a
  251.      system where THEY want to do real-time-like operations. However, this=
  252.  may
  253.      be an acceptable alternative for in-house projects, or on well=
  254.  controlled
  255.      systems.
  256.     =20
  257.      The only real answer is to test your driver with a wide variety of=
  258.  software
  259.      and hardware installed and gather empirical evidence. If you have the
  260.      luxury to control the design of the hardware, build in buffering to
  261.      accommodate worst-case latency situations.
  262.  
  263. How do I access physical memory at (e.g. D000:0000) from a Windows 3.1
  264. application?
  265.      This is very easy to do.  Here is a sample program that references the=
  266.  VGA
  267.      display buffer at A000:0000.  You can use the same technique, except=
  268.  use
  269.      _D000h instead of _A000h.  KERNEL defines a whole set of these=
  270.  selectors
  271.      for you covering the A000 through F000 range.
  272.        #define STRICT
  273.        #include "windows.h"
  274.       =20
  275.        typedef WORD SELECTOR;
  276.       =20
  277.        // __A000h is an absolute value; by declaring it as a NEAR variable
  278.        // in our data segment we can take its "address" and get the
  279.        // 16-bit absolute value.
  280.       =20
  281.        extern BYTE NEAR CDECL _A000h;     // use _A000H for Borland=
  282.  compilers
  283.       =20
  284.        SELECTOR selVGA =3D (SELECTOR)&_A000h;
  285.       =20
  286.        int PASCAL WinMain (HINSTANCE   hinst,
  287.                                 HINSTANCE   hinstPrev,
  288.                                 LPSTR       lpszCmdLine,
  289.                                 int         cmdShow
  290.                                 )
  291.        {
  292.             WORD FAR * lpVGA =3D MAKELP( selVGA, 0 );
  293.       =20
  294.             // Should put garbage pixels on top left of screen
  295.             lpVGA[0] =3D 0x1234;
  296.             lpVGA[1] =3D 0x5678;
  297.       =20
  298.             return 0;
  299.        }
  300.       =20
  301.  
  302. What are the differences between embedded, installable, and conventional=
  303.  device
  304. drivers?
  305.      All of these terms can be used to describe 16-bit protected-mode DLLs.
  306.     =20
  307.      >    An embedded device driver is a DLL that basically acts as an=
  308.  extension
  309.           of a particular Windows application.  It usually contains an=
  310.  interrupt
  311.           handler, and it exports any set of services the author might=
  312.  choose to
  313.           implement.
  314.     =20
  315.      >    An installable device driver must conform to more rigid=
  316.  guidelines.
  317.           This type of driver can be opened, closed, enabled, disabled, etc.=
  318.  by
  319.           other applications or DLLs.  It contains a DriverProc, which is=
  320.  like
  321.           the WindowProc in a Windows application.  The DriverProc responds=
  322.  to a
  323.           standard set of messages sent by Windows and to custom messages=
  324.  sent
  325.           by applications.  This is the type of driver that can be installed
  326.           using the Control Panel applet.
  327.     =20
  328.      >    A conventional device driver (also sometimes called a "standard"
  329.           device driver) interacts with a hardware device supported by the
  330.           Windows API.  For example, the display, keyboard, and printer are
  331.           considered to be "standard" devices.  These drivers are sometimes
  332.           given a file extension of .DRV, and are usually installable=
  333.  drivers.
  334.           They work with certain pre-defined data structures and provide=
  335.  certain
  336.           pre-defined services.
  337.  
  338. I need to write a Windows device driver.  Should it be a DLL or a VxD?
  339.      This is the kind of question whose answer really depends on your
  340.      application and your objectives.  In general, a VxD is more difficult=
  341.  to
  342.      develop, but yields higher performance when processing interrupts and
  343.      accessing I/O ports.  A VxD can also do things that aren't otherwise
  344.      possible with a DLL.
  345.     =20
  346.      The first step is to determine what it is that your driver must do.  If=
  347.  it
  348.      must support a hardware device, then which of the following system
  349.      resources are required by your hardware?
  350.     =20
  351.           a.)  I/O ports
  352.           b.)  IRQ lines
  353.           c.)  Memory ranges
  354.           d.)  DMA channels
  355.     =20
  356.      If I/O ports are involved, then be aware that there are performance=
  357.  issues
  358.      related to accessing I/O ports from ring 3, as you would in a DLL, as
  359.      compared to accessing them from ring 0 in a VxD.  There is overhead
  360.      associated with accessing I/O ports from ring 3, perhaps as much as=
  361.  100% or
  362.      more (i.e. ring 3 accesses take twice as much time as ring 0 accesses).=
  363.  If
  364.      the port is trapped by another driver, then the overhead to access the=
  365.  port
  366.      will be drastically greater.
  367.     =20
  368.      If IRQ lines are involved, then be aware that there is significantly=
  369.  more
  370.      interrupt latency associated with an ISR running in ring 3 than in a=
  371.  VxD.
  372.     =20
  373.      Access to physical memory can be accomplished with DPMI services in a=
  374.  DLL,
  375.      or VMM services in a VxD.
  376.     =20
  377.      Access to DMA channels from application level should go through VDS
  378.      (Virtual DMA Services).
  379.     =20
  380.      If you need to make your hardware appear to be shared by Windows
  381.      applications and DOS applications running in separate DOS boxes, then=
  382.  you
  383.      need to "virtualize" your hardware with a VxD.  You also need to
  384.      "virtualize" your hardware if you need to mediate access, or resolve
  385.      contention for your device.
  386.     =20
  387.      Note also that VxDs are not supported for Windows NT or OS/2, as those
  388.      operating systems use a different form of device driver.  DLLs should=
  389.  work
  390.      correctly across the platforms.
  391.     =20
  392.  
  393. How do I call an application from a VxD?
  394.      There are several possibilities, depending on what kind of application=
  395.  you
  396.      are calling, and whether the driver is running under Windows 3.x or=
  397.  Windows
  398.      95.
  399.     =20
  400.      Here is a brief outline of some of the options.
  401.     =20
  402.      Windows 3.x
  403.           Use Nested Execution services to call PostMessage to send a=
  404.  message to
  405.      a Windows application.
  406.           Use Nested Execution services to simulate a call or interrupt into=
  407.  a
  408.      V86 or Protected Mode context.
  409.      Windows 95
  410.           Use Nested Execution services to call PostMessage to send a=
  411.  message to
  412.      a Windows application.
  413.           Use Nested Execution services to simulate a call or interrupt into=
  414.  a
  415.      V86 or Protected Mode context.
  416.           Use Shell_Post_Message to post a message to a Windows application.
  417.           Use shell services such as Shell_Call_At_Appy_Time or
  418.      Shell_Post_Message.
  419.           Use Vwin32_QueueUserAPC to initiate a User Asynchronous Procedure
  420.      Call.
  421.  
  422. How do I handle interrupts in my VxD?
  423.     =20
  424.      Use the services provided by the Virtual PIC Device (VPICD) to install=
  425.  an
  426.      ISR for your hardware device.  This involves creating a data structure=
  427.  in
  428.      the locked data segment of your VxD of type VPICD_IRQ_Descriptor.  In=
  429.  it,
  430.      you specify the IRQ number and the address of your ISR, among other=
  431.  things.
  432.      You then register your ISR by calling VPICD_Virtualize_IRQ.  This=
  433.  returns
  434.      an IRQ Handle, which you should save for future reference.
  435.     =20
  436.      Later, when an interrupt occurs, your ISR will be entered with minimal
  437.      latency.  The ISR must be in a locked code segment.  The IRQ Handle=
  438.  that
  439.      uniquely identifies this interrupt will be in EAX upon entry.  You=
  440.  should
  441.      call VPICD_Phys_EOI at the end of your ISR.  Just before returning from
  442.      your ISR, clear the carry flag if you successfully processed the=
  443.  interrupt.
  444.      If the IRQ is sharable, you can pass the IRQ on to the next handler in=
  445.  the
  446.      chain by setting the carry flag.  Return from the ISR with a RET
  447.      instruction, not IRET.
  448.     =20
  449.      Upon entry to the VID_Hw_Int_Proc (your ISR), interrupts are masked at=
  450.  the
  451.      PIC for that particular interrupt, and an EOI has already been sent to=
  452.  the
  453.      PIC for that same interrupt.  The call to VPICD_Phys_EOI at the end of=
  454.  the
  455.      ISR doesn't actually send an EOI to the physical PIC, as the name=
  456.  implies,
  457.      but rather simply unmasks the interrupt at the PIC. The EOI was=
  458.  actually
  459.      sent to the PIC before entering VID_Hw_Int_Proc.  The name of the
  460.      VPICD_Phys_EOI service is misleading.
  461.     =20
  462.      Check out the useful services provided by VPICD.
  463.  
  464. How do I access physical memory in my VxD?
  465.     =20
  466.      You should first convert the physical address to a linear address with=
  467.  the
  468.      _MapPhysToLinear service.  If you need to pass the address to an
  469.      application, you can convert the linear address to either a=
  470.  protected-mode
  471.      address in (selector):(offset) form or a V86-mode address in
  472.      (segment):(offset) form with the Map_Lin_To_VM_Addr service.
  473.  
  474. How do I access memory from my application or DLL in my VxD?
  475.     =20
  476.      You should convert the protected-mode address to a linear address with=
  477.  the
  478.      Map_Flat service.  Do not depend on the address remaining valid
  479.      indefinitely unless you have locked the linear address with the=
  480.  GlobalFix
  481.      API.
  482.  
  483. How do I allocate memory from a Win16 application that can be accessed by a=
  484.  VxD
  485. at interrupt time?
  486.      In order to allocate memory that is safe to access froma VxD at=
  487.  interrupt
  488.      time, you must perform several steps.
  489.           GlobalAlloc()  Allocate a block of memory.
  490.           GlobalLock()   Keep the segment in memory.
  491.           GlobalFix()    Prevent the segment from moving in linear memory.
  492.           GlobalPageLock()    Prevent the memory from being swapped to disk.
  493.      Then, pass the segment:offset address of the memory block to the VxD.=
  494.  The
  495.      VxD can use the MapFlat service to translate the memory address to a=
  496.  linear
  497.      address for use by the ISR.
  498.     =20
  499.  
  500. How do I share memory between a Win32 application and a VxD?
  501.      Under Windows 95, VxDs and Win32 applications share the same linear=
  502.  address
  503.      space. Therefore, you can allocate memory in a VxD and pass the linear
  504.      address to a Win32 application directly.  The address space of an
  505.      application includes both private and shared regions. If a VxD needs to
  506.      access memory allocated in a Win32 application, the memory must be in a
  507.      shared (global) region, or the VxD must be running in thread context=
  508.  from
  509.      which the memory was originally allocated. Use the=
  510.  Schedule_Thread_Event
  511.      service to change contexts if necessary.
  512.     =20
  513.      If a VxD needs to access application memory at interrupt time, the=
  514.  memory
  515.      must be page locked. There are no Win32 services for page locking=
  516.  memory,
  517.      but the VxD may lock the pages. Use the VMM service  _LinPageLock,=
  518.  setting
  519.      the last parameter (flags) to PAGEMAPGLOBAL. The service returns an=
  520.  address
  521.      for the specified page that may is usable from any memory context. Use
  522.      _LinPageUnLock to unlock the memory.
  523.  
  524. Give me an overview of Plug and Play
  525.     =20
  526.      If you write a VxD for a device in Win95, you must provide a Device
  527.      Information  file (.INF) that tells Win95 how to install the VxD and =
  528.  how
  529.      to configure the device. Information about INF files can be found  in=
  530.  the
  531.      Win95 DDK.
  532.     =20
  533.      If you're writing a Win95 VxD for a PCI, PCMCIA or PNPISA device, you
  534.      should also add Plug and Play support to your VxD. All that means is=
  535.  that
  536.      your VxD uses Configuration Manager (a VxD) services to find out which
  537.      system resources (I/O addr, IRQ, etc.) have been assigned to the=
  538.  device,
  539.      as opposed to obtaining this info from an INI file or hardcoding it.
  540.     =20
  541.      To add this required Plug and Play functionality, your VxD must handle=
  542.  the
  543.      PNP_New_DevNode message sent by the Config Mgr. In response to this
  544.      message,  you should register yourself as the device driver by calling
  545.      CM_RegisterDeviceDriver. When calling this function, you pass the CM a
  546.      callback function. The CM will call you back later when your resources=
  547.  have
  548.      been assigned, passing you a function code. When your callback =
  549.  function is
  550.      called with the CONFIG_START function code, call the function
  551.      CM_GetAllocLogConf to find out which resources have been assigned to=
  552.  your
  553.      device. This call fills in a CM_CONFIG structure, which has a field for
  554.      I/O address, IRQ, etc.
  555.     =20
  556.      Some types of VxDs, including SCSI MiniPort Drivers, Network Drivers=
  557.  and
  558.      VCOMM Port Drivers, may need to use a different method of obtaining=
  559.  config
  560.      info. These types are different because in each case another VxD is=
  561.  acting
  562.      as Device Loader, and it's the Device Loader that actually interacts=
  563.  with
  564.      the CM, not the driver VxD. These drivers may need to use configuration
  565.      services  provided by the Device Loader (IOS, Ndis wrapper or VCOMM)
  566.      instead  of interacting with the CM directly.
  567.     =20
  568.      The Configuration Manager will never send your VxD a PNP_New_DevNode
  569.      message  until the appropriate registry entries are made. The best way=
  570.  to
  571.      get the  registry entries is not by hand, but with an INF file. Win95=
  572.  will
  573.      prompt  you for an INF file the first time it sees your device. For
  574.      PCI,PCMCIA and  ISAPNP devices, this should automatically happen the=
  575.  first
  576.      time you  physically install the device. For other devices, you may=
  577.  have to
  578.      run the  Add New Hardware wizard from the Device Manager application.=
  579.  Win95
  580.      will  use the INF file you supply to make registry entries. INF files=
  581.  are
  582.      documented in the Win95 DDK.
  583.  
  584. How do I initiate DMA from a VxD?
  585.     =20
  586.      The following information applies to both Windows 3.x and Windows 95,
  587.      unless  otherwise noted. It assumes some knowledge of DMA operations=
  588.  under
  589.      DOS,  describing only differences under Windows.
  590.     =20
  591.      A Windows driver for a DMA device can be implemented as a Ring 3 driver=
  592.  DLL
  593.      or as a VxD. A VxD will offer much better performance, because Ring 3=
  594.  DMA
  595.      generally results in double buffering.
  596.     =20
  597.      To set up a DMA transfer in a DLL, program the the system DMA=
  598.  controller
  599.      registers using normal I/O instructions, setting up the DMA mode,=
  600.  count,
  601.      address, etc. Use GlobalDosAlloc to allocate the DMA buffer. All other
  602.      methods result in a linear address above 2 GB, larger than the 24-bit
  603.      controller can address. GlobalDosAlloc returns a segment value and a
  604.      selector value. Uses the segment value as you would under DOS to=
  605.  calculate
  606.      a physical address -- shift left by 4. Program this value into the
  607.      controller's base address register, just like under DOS.
  608.     =20
  609.      So it's easy to do DMA from a DLL. But there's a cost to performance.=
  610.  The
  611.      VDMAD intercepts all I/O reads and writes to the DMA controller,=
  612.  writing
  613.      the  data to its own virtual registers but not to the actual registers.
  614.      When the  DLL unmasks the controller, the VDMAD gets ready to start the=
  615.  DMA
  616.      operation.  VDMAD looks at the value written to the base address=
  617.  register.
  618.      Treating this  as a linear address, it determines if the pages are
  619.      physically contiguous.  Only random chance would make them contiguous,
  620.      because a Windows app or  DLL cannot specify contiguous when=
  621.  allocating. If
  622.      they're not (and they  won't be), the VDMAD writes into the actual
  623.      controller register the physical  address of another buffer instead --=
  624.  one
  625.      allocated as contigous by VDMAD.  If transfer is from memory, VDMAD=
  626.  copies
  627.      data from original buffer to its  buffer. VDMAD programs the controller
  628.      with the remaining virtual register  values, and the transfer begins.=
  629.  If
  630.      the transfer is to memory, VDMAD copies  from its buffer to the=
  631.  original
  632.      buffer when the transfer is complete. All  this is transparent to DOS=
  633.  or
  634.      Windows application that performed the transfer.  But the buffer copy
  635.      required to insure DMA buffer physical contiguity may  slow down the
  636.      transfer considerably.
  637.     =20
  638.      To do DMA in a VxD, allocate the DMA buffer with PageAllocate, using=
  639.  the
  640.      PageUseAlign and PageContig flag bits, and pType of PG_VM. Under=
  641.  Win3.x,
  642.      these flags are valid only during initialization. Under Win95, the=
  643.  flags
  644.      are  valid at any time. Do not program the system DMA controller=
  645.  directly,
  646.      use  VDMAD services. Call VDMAD_Virtualize_Channel once before the=
  647.  first
  648.      transfer  to reserve the channel. For every transfer, call
  649.      VDMAD_Lock_DMA_Region  to page-lock the buffer and get it's physical
  650.      address; VDMAD_Set_Region_Info  to program the controller with physical
  651.      address; VDMAD_Set_Phys_State to  program the controller's mode; and=
  652.  last
  653.      VDMAD_Phys_Unmask_Channel to unmask  the channel. The VDMAD Lock and=
  654.  Unlock
  655.      services cannot be called in a ISR,  schedule an event handler instead=
  656.  if
  657.      necessary.
  658.  
  659. Do I need a Device ID for my VxD?
  660.     =20
  661.      Most developers will not need a device ID. To communicate with a VxD=
  662.  from a
  663.      Win32 application, use the Device IOCTL call. To obtain the VxD entry=
  664.  point
  665.      from a 16-bit application running under Windows 95 given the device=
  666.  name (1-
  667.      8 characters) without needing an ID number, do this:
  668.     =20
  669.            AX =3D 1684h (Get VxD entry point)
  670.            BX =3D 0000h (UNDEFINED_DEVICE_ID)
  671.            ES:DI -> 8-character space-padded case-sensitive buffer with the=
  672.  VxD
  673.      name.
  674.            Int 2Fh
  675.     =20
  676.      This will return ES:DI =3D callback address if successful, or 0 on=
  677.  error.
  678.      For example, if your device is called "MYDEV", you could write
  679.     =20
  680.      MyDevName db 'MYDEV   ' ; 8 characters space-padded case-sensitive
  681.           mov ax, 1684h
  682.           mov bx, 0
  683.           push ds
  684.           pop es
  685.           mov di, offset MyDevName
  686.           int 2fh
  687.           mov ax, es
  688.           or ax, di
  689.           jz error
  690.           mov word ptr EntryPoint[0], di
  691.           mov word ptr EntryPoint[2], es
  692.     =20
  693.      If your driver provides services to be called by other VxDs, you may=
  694.  want a
  695.      unique device ID. Send email to vxdid@microsoft.com and an application=
  696.  for
  697.      a device ID will be automatically sent to you.
  698.  
  699. Can I write device drivers in C/C++, or must I use assembly language?
  700.     =20
  701.      VxDs are 32-bit programs.  You may use a 32-bit C/C++ compiler, but you
  702.      must be careful about segmentation, calling conventions, and run time
  703.      library routines that require initialization.  Many of the interfaces
  704.      provided by the Virtual Machine Manager have register-based calling
  705.      conventions.
  706.     =20
  707.      Vireo Software sells a toolkit that allows you to use C or C++ to write
  708.      VxDs.  See below.
  709.  
  710. Why do I get linker warnings when I build my VxD?
  711.      The Microsoft linker will generate many warnings when linking VxDs. =
  712.  The
  713.      warning messages refer to =93mismatched segment attributes=94.  These=
  714.  errors
  715.      are normal (sorry about that) and can be ignored.  The most recent=
  716.  linker
  717.      includes a /IGNORE switch that you can use to at least suppress the
  718.      messages.
  719.  
  720. Why can=92t I use MSVC 4.1 to build a VxD?
  721.      There is a bug in Microsoft Visual C/C++ version 4.1 that prevents two=
  722.  key
  723.      macros (VxDjmp and VxDCall) from working correctly. The problem does=
  724.  not
  725.      appear in MSVC 4.0 or 4.2. A fix is available from Vireo Software.
  726.  
  727. What commercial products are available to help develop VxDs?
  728.     =20
  729.           Microsoft Developer Network   (Microsoft)
  730.           Soft-ICE            (Nu-Mega Technologies)
  731.           VtoolsD             (Vireo Software)
  732.           VxBuild              (Tetradyne)
  733.     =20
  734.           Microsoft Developer Network
  735.           Summary:    The Microsoft Developer Network is available in=
  736.  several
  737.                  versions. The basic version consists of a CD containing
  738.                  product documentation and publications. Options include
  739.                  subscriptions for quarterly updates, and SDK/DDK packages.=
  740.  In
  741.                  order to receive the DDK, you must (1) subscribe to the
  742.                  "professional" edition or higher, and (2) request the DDK
  743.                  specifically.  Although there is no additional charge for=
  744.  the
  745.                  DDK, it is only shipped to customers who specifically=
  746.  request it.
  747.  
  748.           Contact:    Microsoft Developer Network
  749.                  PO Box 10296, Des Moines, IA  50336
  750.                  (800) 759-5474 or (206) 936-8661
  751.     =20
  752.           SoftICE/W
  753.           Summary:    Soft-ICE/W is a full-screen character-mode debugger=
  754.  that
  755.                  can be used to debug VxDs and applications. Soft-ICE/W can
  756.                  debug VxDs at the instruction level, or display ASM, C, or=
  757.  C++
  758.                  source code.
  759.           Contact:    NuMega Technologies, Inc.
  760.                  PO Box 7780, Nashua, NH  03060
  761.                  (603) 889-2386
  762.                  fax: (603) 889-1135
  763.                  mailto:info@numega.com
  764.                  http://www.numega.com
  765.          =20
  766.           VtoolsD for Windows 95
  767.           Summary:    VtoolsD for Windows 95 allows developers to build VxDs
  768.                  for Windows 95, including registry, plug and play, file=
  769.  system
  770.                  drivers, Win32 application interfaces, and much more.=
  771.  VtoolsD
  772.                  for Windows 95 includes Microsoft=92s WDEB386 debugger and=
  773.  the
  774.                  Windows 95 debug kernel along with over 40 sample VxDs.
  775.           Contact:    Vireo Software
  776.                  21 Half Moon Hill, Acton, MA  01720
  777.                  (508) 264-9200
  778.                  fax: (508) 264-9205
  779.                  mailto:info@vireo.com
  780.                  http://www.vireo.com
  781.     =20
  782.           VtoolsD for Windows 3.1
  783.           Summary:    VtoolsD is a toolkit that allows developers to build=
  784.  VxDs
  785.                  in C or C++ using the Microsoft 32-bit C/C++ compiler.=
  786.  VtoolsD
  787.                  includes a visual-programming VxD code generator, ANSI C=
  788.  run-
  789.                  time libraries, VMM/VxD service libraries, examples, and a=
  790.  VxD
  791.                  Class Library.  Compatible with Microsoft and Borland C/C++
  792.                  compilers.
  793.           Contact:    Vireo Software
  794.                  21 Half Moon Hill, Acton, MA  01720
  795.                  (508) 264-9200
  796.                  fax: (508) 264-9205
  797.                  mailto:info@vireo.com
  798.                  http://www.vireo.com
  799.          =20
  800.           VxBuild
  801.           Summary:    Wrappers to build VxDs in C.
  802.           Contact:    Tetradyne Software Inc.
  803.                  2542 S. Bascom Ave, Suite #206
  804.                  Campbell, CA 95008
  805.                  (408) 377-6367
  806.                  fax: (408) 377-6258
  807.                  sales@tetradyne.com
  808.                  http://www.tetradyne.com
  809.  
  810. How do I find someone to write a driver for me?
  811.      Vireo Software maintains a list of consultants and contract programmers=
  812.  who
  813.      specialize in device driver software. Follow links from Vireo=92s home=
  814.  page
  815.      at http://www.vireo.com/consult.htm
  816.  
  817. What books and magazines are available?
  818.      Magazines
  819.           There are no magazines devoted strictly to device driver=
  820.  programming.
  821.           The following publications have published articles about device=
  822.  driver
  823.           technology at one time or another. Someday, I may have time to=
  824.  collect
  825.           references to specific articles.
  826.          =20
  827.           Microsoft Systems Journal
  828.           Dr. Dobb=92s Journal
  829.           Windows Developer=92s Journal
  830.           Windows Tech Journal
  831.     =20
  832.     =20
  833.      Books specifically about device drivers:
  834.     =20
  835.           Title:     Inside the Windows 95 File System
  836.           Author:    Stan Mitchell
  837.           Publisher: O'Reilly & Associates
  838.           ISBN:      1-56592-200-X
  839.           Price:     $32.95
  840.     =20
  841.           Title:    Systems Programming for Windows 95
  842.           Author:   Walter Oney
  843.           Publisher:     Microsoft Press
  844.           ISBN:     1-55615-949-8
  845.           Price:    $39.95
  846.     =20
  847.           Title:    Writing Windows VxDs and Device Drivers (2nd  edition)
  848.           Author:   Karen Hazzah
  849.           Publisher:     R&D Publications
  850.           ISBN:     0-87930-438-3
  851.           Price:    $49.95
  852.          =20
  853.           Title:    Writing Windows Virtual Device Drivers
  854.           Author:   David Thielen and Bryan Woodruff
  855.           Publisher:     Addison Wesley
  856.           ISBN:     0-201-62706-X (may be replaced by:)
  857.           ISBN:     0-201-48921-X
  858.           Price:    $39.95
  859.     =20
  860.           Title:    Writing Windows Device Drivers
  861.           Author:   Daniel Norton
  862.           Publisher:     Addison Wesley
  863.           ISBN:     0-201-57795-X
  864.           Price:    $29.95
  865.     =20
  866.      Other books useful to device driver developers:
  867.     =20
  868.           Title:    Undocumented DOS (2nd Edition)
  869.           Author:   Andrew Schulman et al
  870.           Publisher:     Addison-Wesley
  871.           ISBN:     0-201-63287-X
  872.           Price:    $44.95
  873.     =20
  874.           Title:    DOS Internals
  875.           Author:   Geoff Chappell
  876.           Publisher:     Addison-Wesley
  877.           ISBN:     0-201-60835-9
  878.           Price:    $39.95
  879.     =20
  880.           Title:    Unauthorized Windows 95 Resource Kit
  881.           Author:   Andrew Schulman
  882.           Publisher:     IDG Books
  883.           ISBN:     1-56884-305-4 (with disk)
  884.           ISBN:     1-56884-169-8 (no disk)
  885.           Price:    $39.95
  886.     =20
  887.     =20
  888.  
  889. What on-line resources are available?
  890.     =20
  891.      Internet news groups
  892.           news:comp.os.ms-windows.programmer.vxd
  893.           news:microsoft.public.win32.programmers.kernel
  894.     =20
  895.      World Wide Web sites
  896.           http://www.vireo.com
  897.                Vireo Software (VtoolsD) home page
  898.           http://www.albany.net/~danorton/ddk
  899.                Dan Norton=92s DDK resource page
  900.           http://www.microsoft.com
  901.                Microsoft home page
  902.           http://www.ora.com/windows
  903.                O=92Reilly Associates home page
  904.           http://www.numega.com
  905.                Nu-Mega Technologies (Soft-ICE) home page
  906.           http://www.microsoft.com/windows/thirdparty/hardware
  907.                Windows Hardware Technical Information for IHVs and OEMs
  908.           http://www.teleport.com/~usb
  909.                Universal Serial Bus Home Page
  910.           http://www.tiac.net/users/waltoney
  911.                DDK annotations
  912.               =20
  913.      Mailing lists
  914.           DDK-L ($15.00 fee)
  915.             This list is for discussion of Microsoft Windows Driver
  916.             Development, including VxDs, printer drivers, and Windows NT=
  917.  kernel
  918.             mode drivers. To join, send "subscribe DDK-L first_name=
  919.  last_name"
  920.             in the body of a message to LISTSERV@PEACH.EASE.LSOFT.COM.  The
  921.             list is free for the first 30 days.  After that, the fee is $15
  922.             annually.  The up-to-the-minute archives are publicly available
  923.             without charge at:
  924.                 http://www.albany.net/~danorton/ddk/ddk-l/index.shtml
  925.           VCOMM  (Free)
  926.             This is for discussion of VCOMM port driver development. To=
  927.  join,
  928.             send a  message to vcomm@cdsnet.net
  929.              with the text "subscribe vcomm" in the body of the message. A
  930.        VCOMM FAQ is also available.
  931.           DDK (free)
  932.             This list is for discussion of Microsoft Windows Driver
  933.             Development, including VxDs, printer drivers, and Windows NT=
  934.  kernel
  935.             mode drivers. To join, send "SUBSCRIBE DDK" in the body of a
  936.             message to Majordomo@cfn.ist.utl.pt
  937.     =20
  938.      Internet FTP sites
  939.           ftp://ftp.microsoft.com/Developr/drg/developer-info/devinfo.zip
  940.                This file contains a list of developer resources available=
  941.  from
  942.           Microsoft; it is not driver specific.
  943.           ftp://ftp.microsoft.com/Developr/MSDN
  944.           ftp://ftp.microsoft.com/Developr/DRG/MSDN-Info
  945.                These directories contain additional information about=
  946.  Microsoft
  947.           Developer Network.
  948.           ftp://ftp.ora.com/pub/examples/windows/win95.update/schulman.html
  949.          =
  950.  ftp://ftp.microsoft.com\developr\drg\winsock\ms-extensions\vxdtdi.zip
  951.                Documents how to access the TCP/IP stack
  952.  
  953. Are there classes in device driver development available?
  954.     =20
  955.      Walter Oney  Software
  956.           Walter Oney offers training classes in VxD development.
  957.           Walter Oney Software
  958.           4 Longfellow Place
  959.           Boston, MA  02114
  960.           800.737.9876
  961.           fax: 617 227 5760
  962.           WaltOney@oneysoft.com
  963.     =20
  964.  
  965. Statement of interest
  966.     =20
  967.      The editor works for Vireo Software, Inc. and is one of the authors of=
  968.  the
  969.      VtoolsD VxD toolkit mentioned in this document.
  970.     =20
  971.      -- Steve Lewin-Berlin
  972.           Berlin@vireo.com
  973.           Vireo Software
  974.           "The Device Driver Tools Company"
  975.  
  976.  
  977.   Stephen Lewin-Berlin                  mailto:berlin@vireo.com
  978.   Vireo Software                        http://www.vireo.com
  979.   "The Device Driver Tools Company"
  980.  
  981.