Hi all,
We disabled the PDBs processing in our tree a couple of months ago
because we could not debug, and I am investigating a little more on the
reasons behind that.. I am not an expert with debugger concepts, so I
thought that you could give me some feedback...
The assert at the
David Lassonde wrote:
The assert at the beginning of the DEBUG_CopyFieldlist function fails.
The types are DT_STRUCT and DT_POINTER.
Hmm. This should not happen ... Either there is a bug in the Wine code,
or that .PDB file contains unexpected constructs. Would it be possible
to send me
The licensing isn't a problem, since WINE is under a BSDish license, and soon to
switch to
the X11 license. What's much more questionable is how we can mix WINE code with QT
code:
can windows handled by WINE co-exist in the same process as QT's windows?
If not, we have two possible
Ulrich Weigand wrote:
len = (sym-generic.len + 3) ~3;
len += ptr.c[16] + 1;
increment = (len + 3) ~3;
As Eric already pointed out, this must certainly be interpreted as
*unsigned* char. You won't see this bug unless your app contains
symbols with length =128 characters ;-)
David Lassonde wrote:
Incredible as it sounds, we have symbols that take up to 245 characters
(and surely some of 256).. So I only casted the ptr.c[16] to (unsigned char)
ptr.c[16]. It goes through perfectly now, but I'm wondering if it really is
the length of the symbol name? I put a
On Fri, 24 Mar 2000, Oleg Noskov wrote:
here at Corel we already have pretty much the same functionality you're
discussing here already developed and shipping since Corel Linux 1.0.
Here's what we do in brief:
- we have a constantly running server process (called netserv) which does
