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 exec
Hello,
> Alexandre's address separartion patch conflicts with Ulrichs patch for
> exceptions on the large stack.
> Ulrich, do you still want to do some modifications to that patch or is
> there any other reason not to submit it?
Not really ... I've just sent an adapted version to wine-patches
Hallo Alexandre, Ulrich
Alexandre's address separartion patch conflicts with Ulrichs patch for
exceptions on the large stack.
Ulrich, do you still want to do some modifications to that patch or is
there any other reason not to submit it?
Bye
Uwe Bonnes[EMAIL PROTECTED]
Free So
Ulrich Weigand wrote:
>
> Eric Pouech wrote:
>
> > well, for some winelib applications I don't think so.
>
> 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
Eric Pouech wrote:
> well, for some winelib applications I don't think so.
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. Eve
Uwe Bonnes wrote:
> My other wish is that __TRY __EXCEPT was handled on the big stack too.
> In my source tree the failing function (XCopyArea) is surrounded
> by a __TRY clause and the corresponding __EXCEPT is not yet
> entered. The debugger in entered via XSetErrorHandler -> error_handler
>
Ulrich Weigand writes:
>
> Ok, the problem is that it goes up the exception chain and finds frames
> that were posted while still on the old stack :-/ I don't think that
> unwinding exceptions across stacks is a good idea; what about the following
> patch that simply catches all exceptions befo
Ulrich Weigand wrote:
>
> Uwe Bonnes wrote:
>
> > I reversed Eric's patch and applied yours and now my crashing example
> > shows:
> >
> > fixme:dc:GetDCEx new hrgnClip[] smashes the previous[43b2]
> > fixme:x11drv:error_handler BON:Xerror code 9
> > Xlib: unexpected async reply (sequence 0x
Uwe Bonnes wrote:
> I reversed Eric's patch and applied yours and now my crashing example
> shows:
>
> fixme:dc:GetDCEx new hrgnClip[] smashes the previous[43b2]
> fixme:x11drv:error_handler BON:Xerror code 9
> Xlib: unexpected async reply (sequence 0x6c64)!
> fixme:seh:EXC_RtlRaiseExceptio
Ulrich Weigand writes:
>
> Eric Pouech wrote:
>
> > as posted by Uwe, exceptions were not properly handled when one
> > exception frame was located on the large stack.
> > this patch solves it (as tested by Uwe).
>
> Hmmm. This collides with a change I was working on :-/ Anyway, wouldn't
> it
Eric Pouech wrote:
> as posted by Uwe, exceptions were not properly handled when one
> exception frame was located on the large stack.
> this patch solves it (as tested by Uwe).
Hmmm. This collides with a change I was working on :-/ Anyway, wouldn't
it be simpler if CALL_LARGE_STACK would jus
Ulrich Weigand wrote:
>
> Eric Pouech wrote:
>
> > as posted by Uwe, exceptions were not properly handled when one
> > exception frame was located on the large stack.
> > this patch solves it (as tested by Uwe).
>
> Hmmm. This collides with a change I was working on :-/ Anyway, wouldn't
> it
12 matches
Mail list logo
