Exception Handling with a "bad" ESP

[Glenn Wurster]

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