I'm a bit confused. Clearly SEH *is* implemented in Wine, at least to
some extent, as you can watch exceptions being thrown and caught again
in the traces. I remember some threads talking about how it couldn't be
implemented, but, I've seen __TRY/__EXCEPT code in the Wine source.
What am I
On August 28, 2003 07:36 am, Mike Hearn wrote:
I'm a bit confused. Clearly SEH *is* implemented in Wine, at least to
some extent, as you can watch exceptions being thrown and caught again
in the traces. I remember some threads talking about how it couldn't be
implemented, but, I've seen __TRY
On Wednesday 27 August 2003 03:04 pm, Alexandre Julliard wrote:
flyker [EMAIL PROTECTED] writes:
using Winelib i can write
__TRY {
...
}
__EXCEPT( ??? )
{
...
}
what can i use how EXCEPTION_EXECUTE_HANDLER ?
In general you need to create a function that
I believe structured exception handling is not implemented in Wine (it
requires support from gcc first).
On Wed, 2003-08-27 at 11:50, flyker wrote:
Using MSVC i can write
__try {
...
}
__except( EXCEPTION_EXECUTE_HANDLER )
{
...
}
using Winelib i can write
__TRY {
--- Mike Hearn [EMAIL PROTECTED] wrote:
I believe structured exception handling is not implemented in Wine (it
requires support from gcc first).
There is a patch to give basic SEH support to gcc that has been developed for Mingw.
The ReactOS
Project is also looking in to ways to implement SEH
I use __TRY __EXCEPT defined in wine/exception.h
but i get error: undefined reference to
`__wine_exception_handler(__EXCEPTION_RECORD*, __EXCEPTION_FRAME*,
_CONTEXT86*, void*)'
what library support this ?
On Monday 18 August 2003 07:04 am, flyker wrote:
I use __TRY __EXCEPT defined in wine/exception.h
but i get error: undefined reference to
`__wine_exception_handler(__EXCEPTION_RECORD*, __EXCEPTION_FRAME*,
_CONTEXT86*, void*)'
what library support this ?
That's in ntdll.
--
gmt
The
Jon Griffiths [EMAIL PROTECTED] writes:
+dlls/msvcrt/cppexcept.c
strip dump code when NO_TRACE_MSGS is defined
The compiler should optimize this out, and even if it doesn't that's
no big deal. It certainly doesn't justify adding #ifdefs.
--
Alexandre Julliard
[EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le Samedi 15 Mars 2003 01:29, Tony Lambregts a écrit :
This completes the first stage of DPRINTF-TRACE. There are still a lot of
files that use DPRINTF. The following is a list of the files I where I did
not replace DPRINTF with TRACE along
Eric Pouech wrote:
programs/wineconsole uses WINE_DPRINTF.
this can safely be replaced by multiple WINE_TRACE calls
A+
Change Log: Convert WINE_DPRINTF calls to WINE_TRACE
Files Changed: programs/wineconsole/wineconsole.c
--
Tony Lambregts
Index: wineconsole.c
Hi,
but i can't without use of DPRINTF ...
but if you have a better solution ?
I suggest creating functions to print your types into a string, and
then dump the created string. Then, if no trace is defined, make
those functions macros that compile to nothing.
Cheers,
Jon
=
Don't wait
programs/wineconsole uses WINE_DPRINTF.
this can safely be replaced by multiple WINE_TRACE calls
A+
--
Eric Pouech
LICENSE: LGPL
If you compile the following code with Visual C++ using the
/MD option (so
that it uses msvcrt.dll)
class CExceptionClass
{
public:
CExceptionClass() {number=0;}
long number;
};
void doSomething()
{
try {
throw CExceptionClass();
} catch(...) {
Patrik Stridvall [EMAIL PROTECTED] wrote:
[1] All tests currenly doesn't compile quite yet, but the
infrastructure is in place. I haven't had much time to look at
it yet. Help would be nice...
Patrik, what kind of help do you need regarding this issue?
I'll gladly help when I have time.
--
Patrik Stridvall [EMAIL PROTECTED] wrote:
[1] All tests currenly doesn't compile quite yet, but the
infrastructure is in place. I haven't had much time to look at
it yet. Help would be nice...
Patrik, what kind of help do you need regarding this issue?
I'll gladly help when I have
Hi
I still try to find the reason for the exception in my app while loading an
ocx. But I don't seem to make much progress. Here is a new trace:
08153fd8:Call kernel32.lstrlenA(40791300 ) ret=5f587c81
08153fd8:Ret kernel32.lstrlenA() retval= ret=5f587c81
08153fd8:Call
, there are
exceptions that the application itself catches.
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
%40tourist.gnt.netoutput=gplain
It seems the borland compiler (the one used in the viewer) does not turn off
floating point exceptions by default while the Microsoft compiler does.
Aparently the opengl library is known to cause floating point exceptions so
when you put the two together bad things happened
have the same floating point errors here.
It looks like Microsoft
fixed this incompatibility by wrapping a call to turn off floating point
exceptions and then restore the previous mask around each opengl call. Do I
understand the problem correctly? Does this sound like a resonable fix
No I don't have 'proof'. It was just a guess (and probably a bad one). Maybe
Microsoft changed their opengl.dll to not produce the exceptions, or maybe in
the DLL they know where the exceptions will be so they wrap only those
specific portions in the mask/unmask pair. It doesn't look like
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
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
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
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 be simpler
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 be simpler
in it is added debug output.
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 before
hanging there.
Those debugmsg with BON in it is added debug output.
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
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
-
28 matches
Mail list logo
