Certain MMIO functions operate on a specific IOProc type. There are two types of I/O procedures: file format and storage system. A file format IOProc operates on the contents of a file, and calls other MMIO services when required. In contrast, a storage system IOProc operates on the storage presentation of the media object, and calls base operating system services.
To indicate an I/O procedure type during initialization, set the ulIOProcType
field in the MMFORMATINFO structure to either MMIO_IOPROC_FILEFORMAT
for file format IOProcs or MMIO_IOPROC_STORAGESYSTEM for storage system
IOProcs. You should also have a resource file, which specifies the NLS
name used to describe the I/O procedure. You must bind the RC file to the
DLL if the I/O procedure is to be used in multiple countries. The IOProc
needs to handle the GETFORMATINFO and GETFORMATNAME messages to provide
the above information.
File Format I/O Procedure
A file format IOProc should support all MMIO system messages (with the exception of RIFF compound file messages). It should also handle any user-defined messages created by the application. For example, a file format IOProc needs to support the MMIOM_GETFORMATINFO message, because the MMIO Manager internally issues this message to an IOProc when it is being installed. If the MMIOM_GETFORMATINFO message is not supported, a blank MMFORMATINFO structure is placed on the MMIO internal IOProc table for that specific IOProc, except for the FOURCC.
In addition, system messages should be supported by a default message handler, which reports back to MMIO that the message is unsupported. This message handler should attempt to pass any message it cannot support to a subsequent child IOProc. For example, a message is passed from a file format IOProc to a storage system IOProc as shown in the following example.
default:
{
/*
* Declare Local Variables.
*/
PMMFILESTATUS pVidInfo;
LONG lRC;
/************************************************************
* Check for valid MMIOINFO block.
************************************************************/
if (!pmmioinfo)
return (MMIO_ERROR);
/************************************************************
* Set up our working variable MMFILESTATUS.
************************************************************/
pVidInfo = (PMMFILESTATUS) pmmioinfo->pExtraInfoStruct;
if (pVidInfo != NULL && pVidInfo->hmmioSS)
{
lRC = mmioSendMessage (pVidInfo->hmmioSS,
usMsg,
lParam1,
lParam2);
if (!lRC)
pmmioinfo->ulErrorRet = mmioGetLastError (pVidInfo->hmmioSS);
return (lRC);
}
else
{
if (pmmioinfo != NULL)
pmmioinfo->ulErrorRet = MMIOERR_UNSUPPORTED_MESSAGE;
return (MMIOERR_UNSUPPORTED_MESSAGE);
}
} /* end case of Default */
If you write a custom IOProc that supports translation, the following messages need to consider the translate flags:
A storage system IOProc typically handles a subset of the system-defined messages that operate on the storage system. For example, the DOS and MEM IOProcs handle the following messages:
A message specific to the storage system IOProc, such as extended attributes of a file, would pass through the default handler of the file format IOProc to the storage system IOProc for processing.
Note: The RIFF compound file (CF) IOProc installed with OS/2 multimedia only supports MMIOM_IDENTIFYFILE, MMIOM_GETFORMATINFO, and MMIOM_GETFORMATNAME. The compound file (CF) IOProc does not need to support additional MMIO messages because the bundle ( BND) IOProc performs the direct file I/O operations. These two IOProcs can be viewed as one logical compound file IOProc.