February 2004 - Wine-Devel - list.winehq.org

Problem with Quicken crashing: Help, please!
by Carl Sopchak Feb. 8, 2004

Feb. 8, 2004

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.

1 0

Re: shell32 patch 12
by Mike McCormack Feb. 8, 2004

Feb. 8, 2004

This patch broke the installation of IE6. When running the command below during installation of IE6, a pathname is scribbled over the stack... C:\windows\inf\unregmp2.exe /Shortcuts /IE5 /RegExts Any ideas why? Mike Martin Fuchs wrote: > This patch is based on work of Ge van Geldorp <ge(a)gse.nl> and me. > > Changelog: > reimplementation of SHGetPathFromIDListA/W() using the new helper > functions SHELL_GetPathFromIDListA/W(). The new implementation avoids to > use IShellFolder::GetDisplayNameOf(), so that it behaves like the following: > > - return the absolute file system path, not relative to the dekstop > - return FALSE as error code if the path can not converted in a valid file system path > - don't return virtual CLSID paths > > Note: > The two helper functions will we called from other places in following patches, so they > are declared in the header file.

2 2

manpage slimmed down?
by cedric Feb. 8, 2004

Feb. 8, 2004

Hi, recently i upgraded from 20031118 to 20040121. I noticed a lot of bugfixes and speed increases. Thanks! However, i don't like the new man.1 page as much as i did the one from 20031118. The section about what debug channels wine has is gone. This was nice info to have under 'man wine'. Why is it removed? Regards, cedric P.S. Sorry for posting a complaint as my very first post to this list. -- No microsoft products were used for this e-mail

4 4

IE6 Security Controls/URLMon;msimtf (nhl 2004)
by Abdul-Haseeb Ahmad Feb. 7, 2004

Feb. 7, 2004

Okay when i use IE6 (installed by mike's script) any webpage that uses an activex control says my security settings are too high, even if i lower them (both custom settings and the slider have no effect), or even if i make the site a trusted website... now i believe this might be what be causing problems with NHL2004 because i get a script error 80040154 (which doesnt let me go in game) when i go to the game setup screen(rest of the game is flawless other than DXImageTransform filters not functioning), which is caused by a missing CLSID entry.. so i checked out the errors I was getting and urlmon.dll wasn't registered and neither was msimtf... now the thing that nhl was trying to call was the security manager which is part of urlmon.dll.. when i registered urlmon, it would crash the game, and i can't get msimtf to register because of problems it has with advapi32/user32 implementations... Im not sure what msimtf does, but i have a hunch that clearing the urlmon issue might solve my problems.. anyone have an idea of what i can do to solve this issue? Theres also an error: fixme:system:SystemParametersInfoA Unknown action: 8198 I have a feeling this is harmless though...

2 4

Are bugzilla patches getting in?
by Leonardo Quijano Vincenzi Feb. 7, 2004

Feb. 7, 2004

Hello everybody. I'm new to the developers list. I have a question about patches in bugzilla. Do developers usually read the bug reports to check for patches? Or is it better to send them directly to wine-patches? I'm talking about the following (minor) bugs, just in case: http://bugs.winehq.org/show_bug.cgi?id=1980 http://bugs.winehq.org/show_bug.cgi?id=1981 Thanks in advance. -- Leonardo Quijano Vincenzi <lquijano(a)hotpop.com>

4 5

Update: starcraft runs faster from debugger!
by cedric Feb. 7, 2004

Feb. 7, 2004

crossposted to wine-dev, and wine-users Hi, I've done some more tests, and i found that when i run winedbg starcraft and wine starcraft and then again winedbg starcraft etc. It works, but always following this pattern: <boot my box> winedbg starcraft :all runs perfectly wine starcraft: all video choppy winedbg starcraft :all runs perfectly winedbg starcraft: all video choppy wine starcraft all video choppy winedbg starcraft: :all runs perfectly Looks like winedbg leaves some things in a bad state, and running wine seems to solve the problems. However, after each run of winedbg i have 4 more of these: 1797 pts/0 00:00:01 wine-kthread <defunct> And after about 4 or 5 times trying the wine trick doesn't work anymore, Whatever i do the game starts choppy. I don't know how to trace a program while it's running from the debugger, winededbg --debugmsg +x11drv <prog> doesn't seem to work. How is the corrrect startline? The trace from wine shows that DGA is disabled (even with /dev/mem set at 777) Can somebody confirm this pattern of events? you need ,wine-20040121 (haven't tried other versions) and starcraft retail or starcraft shareware to reproduce this. The shareware version of starcraft should be available at: www.blizzard.com Regards, cedric -- No microsoft products were used for this e-mail

2 1

programs/winedbg/elf.c breaks non-Linux platforms
by Gerald Pfeifer Feb. 7, 2004

Feb. 7, 2004

Hi, I'm afraid the following patch which added programs/winedbg/elf.c date: 2004/02/03 00:14:12; author: julliard; state: Exp; Eric Pouech <pouech-eric(a)wanadoo.fr> - now detecting Dwarf debug information in ELF modules (but don't load it) - separated module management (pe.c, elf.c) from debug information management (stabs.c, msc.c) - worked around new wine-pthread and wine-kthread loaders (no longer use "wine" as default loader) - better convergence of gdb-proxy and winedbg for ELF handling - fixed ELF link-map walking - now using all loaded shared libs - (with the help of Robert Shearman) - added a bit of const correctness breaks building Wine on non-Linux platforms. For example, on FreeBSD 4.9 I'm seeing: elf.c: In function `DEBUG_ProcessElfFile': elf.c:344: error: `DT_NUM' undeclared (first use in this function) elf.c:344: error: (Each undeclared identifier is reported only once elf.c:344: error: for each function it appears in.) elf.c:344: error: `DT_PROCNUM' undeclared (first use in this function) elf.c:344: error: `DT_EXTRANUM' undeclared (first use in this function) elf.c:345: error: `DT_LOOS' undeclared (first use in this function) elf.c:345: error: `DT_HIOS' undeclared (first use in this function) elf.c:346: error: `DT_LOPROC' undeclared (first use in this function) elf.c:346: error: `DT_HIPROC' undeclared (first use in this function) Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

3 4

Wineboot should process RunOnceEx Entries
by Geoffrey Antos Feb. 7, 2004

Feb. 7, 2004

I saw early postings about RunOnceEx in this mailing list circa January 2003, however the problems they presented were never fixed. Some programs come with simple INF installers because people can cheaply create an INF file, and use a free Setup.exe bootstrap file that reads the name of an INF file from Setup.ini or something similar. These programs do not have any way of processing RunOnceEx themselves. In the distant past before I had converted to Linux and wine, I used to deal with such programs quite a bit; RunOnceEx was Microsoft's way of allowing simple installers to register files, especially if a reboot and wininit was necessary to overwrite files. The basic structure of the registry format is: [Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\Number] "Number"="program.exe arguments" "Number"="c:\\somepath\\somedll.dll|SomeExportedFunction" Number is nothing more than a number. All commands are processed in sequential order, first by key, then by value. If there is no pipe symbol in the line ('|'), the data of the value is executed as a program, with all following tokens passed on as arguments. However, if the pipe symbol is included, the portion to the left is treated as a DLL, and calls the exported function of the name to the right of the symbol. Once all values in a key are processed, the key is deleted, and the process starts with the next key. There is one subkey that has a special meaning: All keys/values in [Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\Setup] are not processed at boot-up. Rather, they are read by the program runonce.exe, not included in wine. It is through this key that one gets the annoying "Updating Windows" box in the upper left corner of the screen, listing tasks being performed. I believe Powertoys for Windows 98 utilized this feature, but I do not remember how. However, these days RunOnceEx still has one important feature: Some people, like me, have programs that fail to load objects because the OS version is not set to XP. When the OS is set to xp, the install-ie6 script does not automatically process the RunOnceEx keys, failling to register all of the DLL's, including the Crypto support needed for programs such as Steam. As such, for IE6 alone, users have to process 50+ lines by hand, in something that SHOULD be processed at bootup, via wineboot.

3 3

Update: starcraft runs faster from debugger!
by cedric Feb. 7, 2004

Feb. 7, 2004

crossposted to wine-dev, and wine-users Hi, I've done some more tests, and i found that when i run winedbg starcraft and wine starcraft and then again winedbg starcraft etc. It works, but always following this pattern: <boot my box> winedbg starcraft :all runs perfectly wine starcraft: all video choppy winedbg starcraft :all runs perfectly winedbg starcraft: all video choppy wine starcraft all video choppy winedbg starcraft: :all runs perfectly Looks like winedbg leaves some things in a bad state, and running wine seems to solve the problems. However, after each run of winedbg i have 4 more of these: 1797 pts/0 00:00:01 wine-kthread <defunct> And after about 4 or 5 times trying the wine trick doesn't work anymore, Whatever i do the game starts choppy. I don't know how to trace a program while it's running from the debugger, winededbg --debugmsg +x11drv <prog> doesn't seem to work. How is the corrrect startline? The trace from wine shows that DGA is disabled (even with /dev/mem set at 777) Can somebody confirm this pattern of events? you need ,wine-20040121 (haven't tried other versions) and starcraft retail or starcraft shareware to reproduce this. The shareware version of starcraft should be available at: www.blizzard.com Regards, cedric -- No microsoft products were used for this e-mail

1 0

Re: PATCH: virtual fixes for native mode
by Juan Lang Feb. 7, 2004

Feb. 7, 2004

Hi Uwe, in NT the native (system call) interface is through ntdll. There are a number of subsystems implemented on top of that: the win32 subsystem, the posix subsystem, and the OS/2 subsystem. It's possible however to write an app that just uses ntdll; this is a "native" NT app. This page has a pretty good explanation: http://www.sysinternals.com/ntw2k/info/native.shtml --Juan __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 1