x11drv, ntdll separation

[David Fraser]

David Hammerton wrote:

>Hi,
>
>I wrote some documentation a while back on this when we (TransGaming) 
>submitted our dibengine to rewind/winehq.
>
>You can read the docu at:
>http://www.winehq.com/hypermail/wine-devel/2002/09/0680.html
>
Hi

Thanks very much, this was very clear and I understand it now...

>Basically its beacuse a DIBSection is like a mixture of a DIB and a HBITMAP, 
>in that it has properties of both: The app can write directly to the pixel 
>data while also being able to perform GDI operations on it, which we do 
>through X. Because of the way X works we therefor have to have two copies of 
>the DIBSection hanging around, and be able to sync them when required (eg, if 
>the most 'up to date' version is in X, we need to know when the app tries to 
>write to / read from the DIB so as we can sync them).
>
Seems to make sense except that I still have one question: the MSDN docs 
seem to indicate that you need to call GDIFlush() before performing any 
drawing operations to the bitmap yourself (at least for Windows NT). 
Would it be possible to keep a list of DIBSections and flush them all in 
GDIFlush, or is this not adequate?

>And really - the best way to get rid of it is to finish the DIB engine :)
>  
>
OK, that makes sense now that I understand what it does :-)

David

>David
>
>On Sat, 22 Feb 2003 22:36, David Fraser wrote:
>  
>
>>Hi
>>
>>I was wanting to do some work on x11drv dll separation.
>>The last remaining dll separation between x11drv and ntdll is
>>VIRTUAL_SetFaultHandler.
>>This is called from X11DRV_DIB_CreateDIBSection, where it tries to set
>>the fault handler to X11DRV_DIB_FaultHandler, with addr=dm.dmBits and
>>arg=res.
>>
>> From reading the code it seems that this is done because it is not
>>known whether the calling app requires read or write access to the data
>>in bmp.  If the app then tries to read or write and doesn't have the
>>appropriate access, this will generate an exception which will then
>>raise the X11DRV_DIB_FaultHandler which would then set the appropriate
>>access, in a way that ensures data gets handled correctly.
>>
>>I presume I'm misunderstanding this, because looking at MSDN for
>>CreateDIBSection, it says:
>>The CreateDIBSection function creates a device-independent bitmap (DIB)
>>that applications can write to directly.
>>and further down...
>>Windows NT: You need to guarantee that the GDI subsystem has completed
>>any drawing to a bitmap created by CreateDIBSection before you draw to
>>the bitmap yourself. Access to the bitmap must be synchronized. Do this
>>by calling the GdiFlush function.
>>
>>So it would seem apps could always be given read-write access to this
>>bitmap.
>>
>>Why is the special fault handler needed? What is the best way to
>>approach getting rid of it?
>>
>>David
>>    
>>