Hi,
Since about mid-December, I've had an issue running Quicken 2000 Deluxe using
the CVS version of wine. The symptom is that *sometimes* (I hate that word
when trying to debug!) the program crashes when printing a partial page of
checks (landscape, centered, 1 or 2 checks on the page, not 3). When it
happens (mostly when I'm trying to print real checks, not when I'm trying to
debug the problem - argh!), it always happens after Quicken asks if the
bottom tear-off part of the page of checks is still attached, and I click the
Yes button.
The actual error that I get is an X error, stating that X has run out of
resources. The reason for that is that it's trying to create a bitmap with
dimensions 1,075,900,608 by 1,082,644,840. Of course it's gonna run out of
resources!
Running it with --debugmsg, I see that this size is being passed to either
CreateBitmap() or CreateCompatibleBitmap() in several places. I have added
TRACE() statements before every call to either of these two functions that I
can find in the wine source, displaying the values. Unfortunately, I don't
see my trace statements in the log (created by redirecting wine's output with
--debugmsg +all,-snoop,-win32,-heap) before the "bad values". (I DO see the
statements for other calls, as well as those I put within CreateBitmap, so
they are getting compiled, etc., correctly...)
I have spent a few days - on several occasions - trying to debug this, but I
keep running into a brick wall.
Before I go much further here, I gotta say that besides other debugging of
wine that I've done in the past, I know little to nothing about the Windows
API, or the internals of wine. I can't call myself a C expert, either. (I
have been a computer consultant for 20+ years - just on other platforms - so
I consider myself competant in general debugging and various languages.
Picking up C, so far, hasn't been that big of a deal. But I certainly don't
know many of the nuances!)
That said, here are the questions that I'm hoping someone can help me with so
I can continue the debugging process:
1) I'd LOVE to use --debugmsg +snoop, but when I do this, the text box Quicken
displays (within the Print Checks dialog) for the user to enter the first
check number to print does not get displayed, and the program gives an
"invalid check number" error, and I never get to the point that the program
crashes. So, as an alternative to tracking down and trying to fix this
debugging bug (which I really don't have the expertise [or, frankly, desire]
to do in a reasonable amount of time), I was wondering if there was a data
structure available that I could use in relay.c that would get me the CALLING
procedure name, so that I could add the DPRINTF statements to show who called
CreateBitmap / CreateCompatibleBitmap with the "bad values". Any help - as
specific as possible - would be greatly appreciated... (Trying to follow all
of the calls and returns gets pretty confusing pretty fast!) Or, if anyone
has a clue on why +snoop would cause the textbox problem...
2) Now, for my lack of C knowledge: When adding the TRACE() statements, I
found several places where the width and height parameters being passed to
CreateBitmap and/or CreateCompatibleBitmap and/or CreateDIBitmap were not
INT. For example (approximate line numbers in [])
dlls/conctl32/animate.c[224], listview.c[4051], trackbar.c[799],
treeview.c[4004], objects/dib.c[183], and metafile.c[1037] all pass LONG's,
and dib.c[825] passes width as a DWORD, and height as an int. (This seems to
be a potential issue relating to the function DIB_GetBitmapInfo, as the width
an height fields of the data structures passed in as *header are LONG, except
if *header is of type BITMAPCOREHEADER, where it's WORD, but they are being
passed back to DWORD and int pointers.) Does the C compiler do an implicit
conversion of these data types to INT (correctly), or is the fact that
parameters are too big suspect in causing my problem? Can I just assign a
LONG (and DWORD) to an INT (i.e., iWidth = lWidth) to do the conversion?
Hopefully, these are simple enough questions for someone with the knowledge to
answer and get me back on track to solving this issue. Any and all help will
be greatly appreciated!
Thanks,
Carl
P.S., I think my next step is going to restore my wine source tree from my
November (October?) backup, and make sure the issue is in fact something
that's changed in wine, and not some configuration change that's happened.
(Althought I'm not certain of the timing, in the same time frame, I've
attempted to install IE6, installed TaxCut 2003 (which required IE6 dlls, and
seems to run, BTW. I haven't done my taxes yet, though...), and played with
fonts some.