Eric Pouech wrote:
Sorry for the late reply ...
> > Why should this be different for WineLib apps? IMO the large stack
> > is something completely internal to Wine, and should not interact
> > in any way with the application's (whether Win32 or WineLib) exception
> > handling. Everything executed on the large stack is an internal helper
> > routine of Wine, which should not throw any user-visible exception ...
> for emulated programs, I almost agree with you
> but some winelib apps may wish to introspect what's going. first reason
> might be to bypass an internal wine bug; Your proposal where ExitProcess
> is called on such an occasion really sounds too drastic to me
Well, I'm not convinced ;-) Re-throwing the exception seems to serve
no very useful purpose to me, at least for these reasons:
- The caller will have locked the X11 critical section, and throwing
the exception will bypass the unlocking; instant deadlock ...
The same applies to the large-stack use recursion count etc.
- If there is really a routine executed on the large stack that *can*
throw exceptions that are at least somewhat expected (e.g. because
the routines accesses pointers passed in from outside that might
be bad, or because the X11 error handler might thrown an exception
etc.), then *that routine* should set up an additional __TRY block
to handle the exception in a reasonable way.
- If a WineLib app triggers a Wine bug, please fix Wine, don't introduce
workarounds in the app ;-)
I've submitted the patch to wine-patches now; that version does terminate
the process for now if any exception reaches the stack switch boundary.
If you really need a different behaviour, feel free to change it ... :-)
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
