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 the VCD_Acquire_Port function call, which is in the source module INITUTIL.C in the Windows 95 DDK directory \DDK\PEN\SAMPLES\VPEND.