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/
folks, can some one please explain to me in plain English how to use the SURFOBJ->hsurf handle - that is, it is apparently a handle to either a DIBSECTION, a BITMAP if a GDI managed surface or it's a HANDLE to my device managed surface if I chose for my driver to tell UniDrv to create a device-managed surface in DriverDMS. Got it - I'm fairly confident on that subject. But I get lost as follows.
Assuming GID Managed surface
a. Is it a GDI kernel based HANDLE where I can retrieve BITMAP or DIBSECTION through GetObject? (doesn't work).
b. I tried to determine the type of HANDLE with GetObjectType (doesn't work - returns 0).
c. Tried casting to HBITMAP. (doesn't work).
Assuming Device-managed surface
a. So DriverDMS creates a device-managed surface and returns the handle to it in SURFOBJ->hsurf. But doesn't allocate space for it. What good is the handle then? Is it a place holder rather then a useful handle?
How exactly does one get at what GDI rendered on the surface in either scenario (device managed or gdi managed)?
I understand, it may depend on the method that I am within (unidrv printer rendering plug-in). It may depend on the hooking functions and/or HOOK_-flags that I set. I think I tried every combination under the sun and still I can't hear the music through the noise. I am very grateful in advance to anyone that can help me hear the lovely music.
Questions restated simply -
1) How to access to the rendered bitmap (rendered by GDI) on a GDI managed surface through ((target)SURFOBJ)->hsurf no matter the IPrintOEMUni(x):: or the Hooked Function I want to access it from.
2) What good is the SURFOBJ->hsurf handle to a device managed surface if DriverDMS encapsulates the surface creation process and doesn't allow my driver to associate the hsurf handle to some object that my driver creates. Ben didn't you read the well written detailed, error free documentation that in no way contradicts itself and makes no assumptions? Ah... No! I haven't seen this animal at the WDK zoo. In this case what exactly is hsurf pointing too? Wait! don't say it's a device managed surface because that assumes that the device driver had something to do with creating it. Perhaps in the old days before IPrintOEMUni(x) when one called EngAssociateSurface...
I sincerely appreciate a nudge or a kick in the ankle to put me back in alignment with the universe.
|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!|
|Developing Minifilters||24 May 2021||Live, Online|
|Writing WDF Drivers||14 June 2021||Live, Online|
|Internals & Software Drivers||27 September 2021||Live, Online|
|Kernel Debugging||15 November 2021||Live, Online|