Problem with Quicken crashing: Help, please!

[Carl Sopchak]

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.