If your pen device is one of those supported by the pen Unidriver, you can adapt the virtual pen driver simply be making changes to a header file, DEFINES.H. For instructions on how to do this and a list of the pen devices supported by the pen Unidriver, see the section "Creating a Custom OEM Driver" in About the Pen Device Driver.
If your pen device is not compatible with one of the pen devices supported by the pen Unidriver, you will have to change some of the source code in the virtual pen driver DDK directory and remake the virtual pen driver. The virtual pen driver source code is in the directory \PEN\SAMPLES\VPEND. The source files OEMs will want to work on are identified in the following table:
OEM Source File | Description |
OEMAPI.C | OEM message handling. |
OEMHWINT.C | OEM hardware interrupt servicing. |
INITUTIL.C | Initializes the DRV_PENINFO and _HARDWAREINFO structures by reading values from the Windows 95 registry. |
MISCUTIL.C | Miscellaneous OEM hardware-specific code. Hardware specific code is also found in the source modules named for specific devices, such as CONCERTO.C. |
One reason for changing code in INITUTIL.C is to solving communications port conflicts between the pen driver and other Windows 95 applications is a design issue. The pen driver uses a communications port (COM1, COM2, COM3, or COM4) to receiver pen packets from the digitizer. If another Windows application, such as a communications application, hooks the IRQ associated with the COM port the digitizer is using, either pen packets will stop flowing from the digitizer to the pen driver or when the communications application sends output to the communications device the same bytes will also be sent to the pen driver, and the bytes are not formatted as pen packets.
The sample virtual pen driver uses a VCD_Acquire_Port system function call to mitigate the port contention problem. This informs Windows 95 that a VxD has taken control of a particular COM port. Then, if a communications application tries to use the COM port with a standard Windows 95 API function call, the system will not allow the application to use the port that has been acquired by the virtual pen driver. Digitizers are not Plug and Play devices under Windows 95, so they cannot participate in dynamic reallocation of the COM port when it is requested by another application.
There is a problem with the VCD_Acquire_Port solution to the COM port contention problem: if an application does not use standard Windows 95 APIs to request the COM port, the system will display a modal dialog "Cannot write to COMx" every time the application attempts to write to the port, which interferes with the user's ability to get a lot of work done. When you write the virtual pen driver for your device, you may want to design a different way of handling the communications port contention issue. If you are using the sample driver source code as a starting point for your driver, this means that you will have to replace any uses of the VCD_Acquire_Port function call in the source module INITUTIL.C.