|This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
Because peripheral devices are exposed to applications as special files when you create a stream interface driver, you provide the implementation of such a file. Therefore, consider whether it is practical, based on the capabilities of the device that your driver serves, to enable multiple applications to have simultaneous access to the special file. That is, consider whether your driver can have multiple open file handles on its device. A stream interface driver can implement either single access or multiple access by using the hOpenContextparameter that Windows CE passes to all file I/O functions.
To enable multiple access, each call to the XXX_Openfunction should return a different value for hOpenContext. The device driver must track which return values from XXX_Openare in use. Subsequent calls by Windows CE to XXX_Close, XXX_Read, XXX_Write, XXX_Seek, and XXX_IOControlpass these values back to the device driver, enabling the driver to identify which internal data structures to manipulate.
To enforce single access, only the first call to XXX_Openshould return a valid hOpenContextvalue. As long as this value remains valid, which is until Windows CE calls XXX_Closefor the value, subsequent calls to XXX_Openshould return NULL to the calling application to indicate failure.
Note that the Windows CE implementation of the Telephony API (TAPI) requires that serial port devices support multiple access. OEMs who are using any of Microsoft's serial port MDD implementations gain this functionality automatically. OEMs who write their own serial port MDD layers, or who opt to implement monolithic serial port drivers, must implement multiple access for themselves in order to support TAPI.
Last updated on Tuesday, July 13, 2004