Hello,
I’m currently developing an Unidriver V3-based printer driver for a rather old monochrome paper ticket printer to get it working under Windows 10 64 bit. I need to inject some additional symbols into the raster data to mark scan line ends and empty lines. Therefore I took the OEMUNI sample from the MS OEM Printer Customization Plug-in Samples as a development base. The printer is physically connected to a virtual serial port realized by an FTDI USB-to-serial adapter, but attached to “FILE:” output for now.
My user-defined GPD printer description works as expected but misses some capabilities due to command limitations which is the reason why I need the rendering DLL. From the debugger I can see that the initialization of the plug-in seems to be fine, my IPrintOemUni2 interface implementation is queried by the Unidriver, its methods like EnableDriver(), EnablePDEV(), GetInfo(), GetImplementedMethod() etc. are called, a DDI hook table with OEMStartPage(), OEMSendPage() among many others (to see what is called by the Unidriver) are passed to the caller.
But these hooks are never called during printing. As far as I understand at least the OEMStartPage() hook should be called. Because it is a monochrome printer, OEMSendPage() should also be called. But the only OEM function that gets called actually is OEMGetGlyphMode() which passes everything back to the Unidriver. This shows that the basic initialization stuff seems to work.
To make things even worse, the implemented IPrintOemUni interface members like FilterGraphics() or ImageProcessing() never get called even if they are announced as implemented in IPrintOemUni::GetImplementedMethod() which is called by the parent.
To verify that this behavior is not specific to my driver I isolated the OEMUNI sample from the MS OEM sample package, made a Win10Debug target build and installed it on the same test system with Windows 10 Pro 21H2. Same problems as above, only OEMGetGlyphMode() is called from the hooks, and no optional, but implemented interface members are called. I also installed the driver on a second test system with the same Windows version and got the same result.
The build environment is VS2019 16.11.19 with SDK 10.0.22000.0, WDK 10.0.21381.1000, platform toolset used for the DLL is WindowsApplicationForDrivers10.0.
I know that Unidriver V3 is a rather outdated printer framework but still supported and well documented.
Many thanks for any feedback on this,
Rainer