The Windows 95 LPT enumerator (LPTENUM.VXD) does not call VCOMM to detect LPT devices; instead, it writes directly to the port. When called to enumerate devices attached to an LPT port, the enumerator calls ACQUIRE_RESOURCE with ACQUIRE_NO_STEAL, so that it does not inadvertently interfere with another program using the port.
Unlike the COM enumerator, LPTENUM calls RELEASE_RESOURCE when it is done checking a port, because it cannot detect a device attach or device detach operation.
Windows 95 LPT driver (LPT.VXD) calls ACQUIRE_RESOURCE with ACQUIRE_STEAL. This service will steal ports owned by VMs, if stealing has been allowed by the user in Control Panel.
When LPT.VXD receives a RESOURCE_STEAL_REQUEST notification, it saves the state of the LPT or ECP port and returns TRUE. If the state cannot be saved at the current time, LPT.VXD returns FALSE.
After its port is stolen, LPT.VXD periodically attempts to steal back the port by calling STEAL_RESOURCE. This enables it to cooperate with periodic access by the VM for dongles, and so on.
The MS-DOS print spooler, which redirects print jobs sent by applications using Interrupt 17h or Interrupt 21h, is not required to manage contention, because it does not call VCOMM or write to LPT ports. It routes print jobs to the Windows 95 print spooler, which contends for the port using the Win32 communications API.
Dongle access should be made using a VxD in Windows 95. A dongle VxD calls ACQUIRE_RESOURCE with ACQUIRE_STEAL. If this call fails, the dongle VxD can try again later or return failure to its client. A dongle VxD accessing a port only causes a warning message if the user has set VPD to "warn" in the Control Panel. While it owns a port, the dongle VxD should fail RESOURCE_STEAL_REQUEST calls.
A dongle VxD should call RELEASE_RESOURCE as soon as it is done accessing the dongle. That is, it should not hold the acquire handle for the duration of its client application and release to RESOURCE_STEAL_REQUEST calls during idle periods. The reason for this is to enable more than two VxD clients to share a port. For example, imagine a system with the following devices installed: LPT1, dongle, Xircom adapter, and printer. The Xircom adapter and LPT.VXD could not share LPT1 while the dongle VxD is holding an acquire handle, because there can only be one current owner and one waiting owner at a time per resource (not including VMs).
Layered block device drivers for devices attached to LPT ports should behave as dongle VxDs, as described in "Dongles." That is, the drivers only acquire the port for as long as necessary to complete a read/write operation to the device.
Tape backup applications should access devices using a VxD in Windows 95, and behave as dongle VxDs, as described in "Dongles." That is, applications only acquire the port for as long as necessary to complete a read/write operation to the device.
NDIS drivers for parallel port network adapters behave as dongle VxDs. That is, they call ACQUIRE_RESOURCE with ACQUIRE_STEAL, and RELEASE_RESOURCE as soon as they are done accessing the adapter.
The role of VCD is to manage contention for COM ports by VMs. It behaves identically to VPD, as described earlier.