Our current DIB implementation is an ugly hack. We need a real DIB implementation, either as a complete GDI engine in Wine or as an X11 extension.
But is it the DIB implementation that is really at fault here or is it the fact that we are adding extra exceptions and can't be sure what the esp will be when they fire, especially since they don't occurr on Windows. The DIB engine does need to know when bitmaps are modified directly by the application if it is to avoid extra work. Another example of a SEH exception is that of the DOS memory initialization (http://www.winehq.org/hypermail/wine-cvs/2005/04/0298.html). It relies now on an access violation to detect when to initalize the DOS and BIOS memory. If ESP was used for something other than the stack on the first access to DOS memory, then we'd experiance the same problem. There may be other examples outside of DIB in the code as well that I'm not aware of.
As far as I can tell, the problem is that we have extra exceptions firing when the application is not expecting them and they would not occurr on Windows. So, the two options are to enforce that Wine never throws exceptions other than those that occurr on windows (and I suspect people in general do not like this restriction for performance reasons) or to fix the exception handler to work in the face of a bad ESP. Perhaps exceptions fired due to wine can use a different stack so that they don't rely on an assumed state of the application?
Some work has been done on a GDI engine in Wine by Transgaming a couple of years ago but it wasn't merged. Then, some weeks ago someone suggested to port the ReactOS GDI engine to Wine.
Yes, I read that. The Transgaming engine that was discussed uses exceptions to detect when the application modifies a DIB, which is the problem we have right now. I don't know how the ReactOS GDI engine does it.
Glenn.