The "real" DIB, used for GDI calls, is stored on X side but the DIB surface, used for direct access, is stored on Wine side and we need to keep them in sync by catching reads / writes to the DIB surface.
We need to get rid of that seperation - either the DIB should be stored fully on X side (which would require to add some features to X) or fully on Wine side (by implementing a GDI renderer in Wine).
What about other instances where Wine generates an exception and Windows does not? Rewriting GDI may be able to solve the exception handler for this case, but really the problem is any exception being generated when ESP does not point exactly to the top of the stack.
As an example. What if I wanted to access BIOS memory and so I did something like the following in an application:
mov 0x12345678, [esp - 4] mov [BIOSMEM], eax mov eax, [esp - 8] sub esp, 8 call somefunc add esp, 8
Correct me if I'm wrong, but the current code does not initialize BIOS memory unless the program requests it. In this case, the exception is going to be raised on the 2nd instruction, causing [esp - 4] to be overwritten with information related to the exception. That's not really what we want.
So, regardless of whether or not GDI uses exceptions to track accesses, other areas of the code use exceptions in a similar manor to detect when an application tries to access memory. They may also use exceptions for other things that I'm not aware of (Perhaps floating point errors?).
GDI is a very good example of the problem of throwing an exception where the application never intended one to be thrown. If ESP is bad we clobber something. GDI, however, is not the only example. If we fix it so that GDI does not throw exceptions, then we have to fix it so that we only throw exceptions when windows throws exceptions. Nothing more, nothing less - otherwise we have the issue of potentially having a bad ESP and clobbering something. The issue of never throwing an exception unless Windows would have is a larger problem and involves more than just GDI code. We can't enforce ESP usage on windows programs, so we have to come to terms with the fact that they may not use the ESP register as we would like.
That is what I am trying to get at. I know that GDI is far from optimal, but there are areas of code other than GDI in which the interaction between ESP and exceptions generated within Wine could pose a problem.
More comments?
Glenn.