Exception Handling with a "bad" ESP

[Glenn Wurster]

> 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.