Printer driver punting to GDI

I have a monolithic printer driver. In testing a bug fix, I decided
that sometimes, DrvBitBlt should call EngBitBlt (i.e., let GDI do the
work for me). I find that this causes GDI to call me right back at
DrvCopyBits, which is what I expected. What I don’t expect is that it
calls me back with the source and destination SURFOBJs reversed. That’s
right, in the call to DrvCopyBits, the source SURFOBJ is my device’s
surface and the destination is the source bitmap from the application.

My implementation of DrvCopyBits notices this, and rejects the call
(returns FALSE).

GDI almost immediately calls me right back with the 2 parameters
switched to the original. The strange thing is that the addresses are
the same in both calls (i.e., the destination address is the same both
times; except that the first time it points to the application bitmap
and the second time it points to my device surface).

Anyone care to explain what’s going on here? Is this expected? If so,
why?

Thanks in advance,
ScottR

Well, it’s been a while, but this is how I remember it:

You didn’t say what the ROP code was, but I’d expect this behavior if the ROP utilizes the destination bits in some fashion. It would want the bits off your surface first, in order to do the simulation correctly. Since you refused that request, it probably set them all to the background color, did the simulation, and sent them back to you.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Robins, Scott
Sent: Tuesday, January 23, 2007 8:34 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Printer driver punting to GDI

I have a monolithic printer driver. In testing a bug fix, I decided
that sometimes, DrvBitBlt should call EngBitBlt (i.e., let GDI do the
work for me). I find that this causes GDI to call me right back at
DrvCopyBits, which is what I expected. What I don’t expect is that it
calls me back with the source and destination SURFOBJs reversed. That’s
right, in the call to DrvCopyBits, the source SURFOBJ is my device’s
surface and the destination is the source bitmap from the application.

My implementation of DrvCopyBits notices this, and rejects the call
(returns FALSE).

GDI almost immediately calls me right back with the 2 parameters
switched to the original. The strange thing is that the addresses are
the same in both calls (i.e., the destination address is the same both
times; except that the first time it points to the application bitmap
and the second time it points to my device surface).

Anyone care to explain what’s going on here? Is this expected? If so,
why?

Thanks in advance,
ScottR


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Makes sense,
Thanks Bob.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Tuesday, January 23, 2007 11:45 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Printer driver punting to GDI

Well, it’s been a while, but this is how I remember it:

You didn’t say what the ROP code was, but I’d expect this behavior if
the ROP utilizes the destination bits in some fashion. It would want
the bits off your surface first, in order to do the simulation
correctly. Since you refused that request, it probably set them all to
the background color, did the simulation, and sent them back to you.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Robins, Scott
Sent: Tuesday, January 23, 2007 8:34 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Printer driver punting to GDI

I have a monolithic printer driver. In testing a bug fix, I decided
that sometimes, DrvBitBlt should call EngBitBlt (i.e., let GDI do the
work for me). I find that this causes GDI to call me right back at
DrvCopyBits, which is what I expected. What I don’t expect is that it
calls me back with the source and destination SURFOBJs reversed. That’s
right, in the call to DrvCopyBits, the source SURFOBJ is my device’s
surface and the destination is the source bitmap from the application.

My implementation of DrvCopyBits notices this, and rejects the call
(returns FALSE).

GDI almost immediately calls me right back with the 2 parameters
switched to the original. The strange thing is that the addresses are
the same in both calls (i.e., the destination address is the same both
times; except that the first time it points to the application bitmap
and the second time it points to my device surface).

Anyone care to explain what’s going on here? Is this expected? If so,
why?

Thanks in advance,
ScottR


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer