The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
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,
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!|
|Kernel Debugging||16-20 October 2023||Live, Online|
|Developing Minifilters||13-17 November 2023||Live, Online|
|Internals & Software Drivers||4-8 Dec 2023||Live, Online|
|Writing WDF Drivers||10-14 July 2023||Live, Online|