The first MCI message a driver receives is MCI_OPEN_DRIVER. For this message, DriverProc parameters are set as follows:
dwDriverID
The driver ID value specified as the DriverProc return value for the DRV_OPEN message.
hDriver
The driver’s handle.
uMsg
lParam1
Flags. (See MCI_OPEN in Win32 SDK.)
lParam2
Pointer to an MCI_OPEN_PARMS structure.
An application specifies the contents of lParam1 and lParam2 when it sends an MCI_OPEN command.
For a compound device, the driver should test the MCI_OPEN_ELEMENT flag. If set, it indicates that a pointer to an element pathname is available in the lpstrElementName member of MCI_OPEN_PARMS.
Drivers for compound devices sometimes receive MCI_OPEN_DRIVER messages with the MCI_OPEN_ELEMENT flag cleared. This situation can occur if the application opens the device only for the purpose of querying the device with an MCI_GETDEVCAPS or MCI_INFO command. Therefore, drivers for compound devices must allow the MCI_OPEN_DRIVER command to succeed if it is received without an element name, but they must provide a failure return for any command that requires an element, if the element name is missing.
The MCI_OPEN_ELEMENT_ID flag indicates that the lpstrElementName member of MCI_OPEN_PARMS contains a DWORD value instead of a string pointer. This allows you to define an element specifier as being something other than a file pathname. Use of this flag is not recommended.
Drivers can ignore the MCI_OPEN_TYPE, MCI_OPEN_TYPE_ID, and MCI_OPEN_ALIAS flags. These are handled within winmm.dll.
Drivers that support sharing a device must test the MCI_OPEN_SHAREABLE flag.
The driver can also perform instance-specific operations for the device or element being opened, such as storing instance-specific information.
When handling the MCI_NOTIFY flag with the MCI_OPEN_DRIVER command, a driver should return to the application only after it verifies that the open operation will probably succeed. For example, suppose that opening a device element requires reading a large file from a CD-ROM. Before returning to the application, the driver should confirm that the file is accessible and that enough memory can be allocated to load it. This avoids providing a successful (zero) return value to DriverProc, only to later have to deliver an MM_MCINOTIFY message with a status of MCI_NOTIFY_FAILURE.