 Important: |
|---|
| 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. |
What does Windows CE DirectSound audio driver look like from a driver writer's point of view? It is a standard Windows CE DLL that implements the DllGetClassObjectentry point as follows:
DllGetClassObject
Retrieves the class object from a DLL.
STDAPI DllGetClassObject( REFCLSID rclsid, //CLSID for the class object REFIID riid, //Reference to the identifier of the interface // that communicates with the class object LPVOID * ppv//Address of output variable that receives the // interface pointer requested in riid);
This resembles the standard entry point that COM servers implement. The DLL could be written in any language that supports the creation of vtables. In other words, while C++ might be most natural, as with COM objects in general, it could also be written in C or some other language.
The driver DLL will be loaded by the system into the process space in which DSOUNDS.DLL is running – namely the DEVICE.EXE process space.
Through the DllGetClassObjectentry point to the DLL, the DirectSound system will attempt to create a driver object implementing the IDsDriverinterface. Using this interface, DirectSound will attempt to create IDsDriverBufferobjects.
The driver writer should allow for re-entrancy on the interfaces the driver exposes. DirectSound will not serialize calls to the driver and many threads may be simultaneously making calls to DirectSound that will be passed through to the driver.
Last updated on Tuesday, July 13, 2004