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

Re: Relax test requirements to accomodate fuzz of msacm

by Robert Reif

Jeremy White wrote: > > So the only fix I can imagine would be to not use msacm > to perform these conversions and have a parallel set of converters > do this in an aligned fashion. I just tried msacm.drv from a windows 95 CD and it didn't work. I also tried msacm32.drv from xp and it also doesn't work. I ran winedump on msacm32.drv from xp and it imports msacm32.dll. I will try and get msacm32.drv working so we can see what windows really does.

Feb. 26, 2005

Crash in Polar Precision Performance Software

by Ron Jensen

Hello, This trace is from Polar's Precision Performance Software http://www.codeweavers.com/site/compatibility/browse/name?app_id=681 running on CVS wine. This crash happens with CVS wine, and wine I compiled from http://ftp.codeweavers.com/pub/crossover/office/source/office-src-4.1.0.tgz It does not happen with the precompiled binaries in CXOffice's Loki installer. Can someone give me a clue as to were to start looking to fix this? Thanks. /*******/ wineuser$wine 'C:\Program Files\Polar\Polar 32.exe' fixme:gdi:Escape16 unknown/unsupported 16-bit escape c03 (56,0x403815de,0x40381626 fixme:gdi:Escape16 unknown/unsupported 16-bit escape c03 (56,0x403815de,0x40381626 wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0xa84c73e0 in 32-bit code (0x00415809). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:00415809 ESP:4069e63c EBP:4069e6c4 EFLAGS:00010282( - 00 - RIS1) EAX:00000000 EBX:4082f8d4 ECX:a84c73e0 EDX:000004e7 ESI:4069f3f0 EDI:00020040 Stack dump: 0x4069e63c: 00414e23 4069f3f0 000004e7 00020040 0x4069e64c: 4069f3f0 4069e6c4 4082f8d4 004144c9 0x4069e65c: 00020040 4069f3f0 000004e7 0052c3ec 0x4069e66c: 00020040 00000638 00020040 000000a0 0x4069e67c: 00020040 408517a8 4069e6c4 4082f8d4 0x4069e68c: 403d6a28 403d6980 00000000 4007aa04 Backtrace: =>1 0x00415809 in polar 32 (+0x15809) (0x4069e6c4) 2 0x407ae6c0 WINPROC_CallWndProc+0x70(msg=0x4e, wParam=0x0, lParam=0x4069edf0) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:419] in user32 (0x4069e700) 3 0x407b393e CallWindowProcA+0xfe(func=0x408517a8, hwnd=0x20040, msg=0x4e, wParam=0x0, lParam=0x4069edf0) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:2940] in user32 (0x4069e72c) 4 0x4078ff36 DefDlgProcA(hwnd=0x20040, msg=0x4e, wParam=0x0, lParam=0x4069edf0) [/home/wineuser/src/wine/dlls/user/../../windows/defdlg.c:453] in user32 (0x4069e75c) 5 0x407ae277 WINPROC_wrapper+0x17 in user32 (0x4069e780) 6 0x407ae6c0 WINPROC_CallWndProc+0x70(msg=0x4e, wParam=0x0, lParam=0x4069edf0) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:419] in user32 (0x4069e7bc) 7 0x407b3be4 CallWindowProcW+0x184(func=0x4085145a, hwnd=0x20040, msg=0x4e, wParam=0x0, lParam=0x4069edf0) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:3053] in user32 (0x4069eca0) 8 0x407e1d13 call_window_proc+0xc3(wparam=0x0, lparam=0x4069edf0, unicode=0x1, same_thread=0x1) [/home/wineuser/src/wine/dlls/user/message.c:1475] in user32 (0x4069ed00) 9 0x407e1eef SendMessageTimeoutW+0x14f(hwnd=0x20040, msg=0x4e, wparam=0x0, lparam=0x4069edf0, flags=0x0, timeout=0xffffffff, res_ptr=0x4069ed80) [/home/wineuser/src/wine/dlls/user/message.c:1989] in user32 (0x4069ed5c) 10 0x407e1f35 SendMessageW(hwnd=0x20040, msg=0x4e, wparam=0x0, lparam=0x4069edf0) [/home/wineuser/src/wine/dlls/user/message.c:2070] in user32 (0x4069ed88) 11 0x406eee3b PROPSHEET_SetCurSel(skipdir=0x1, hpage=0x403e2cd0) [/home/wineuser/src/wine/dlls/comctl32/propsheet.c:2102] in comctl32 (0x4069ee0c) 12 0x406f26c4 PROPSHEET_DialogProc(hwnd=0x4002e, uMsg=0x110, wParam=0x0, lParam=0x403e2328) [/home/wineuser/src/wine/dlls/comctl32/propsheet.c:3379] in comctl32 (0x4069f3f0) 13 0x407ae277 WINPROC_wrapper in user32 (0x4069f414) 14 0x407ae6c0 WINPROC_CallWndProc(msg=0x110, wParam=0x0, lParam=0x403e2328) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:419] in user32 (0x4069f450) 15 0x407b393e CallWindowProcA+0xfe(func=0x40851794, hwnd=0x4002e, msg=0x110, wParam=0x0, lParam=0x403e2328) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:2940] in user32 (0x4069f47c) 16 0x4078ff36 DefDlgProcA(hwnd=0x4002e, msg=0x110, wParam=0x0, lParam=0x403e2328) [/home/wineuser/src/wine/dlls/user/../../windows/defdlg.c:453] in user32 (0x4069f4ac) 17 0x407ae277 WINPROC_wrapper+0x17 in user32 (0x4069f4d0) 18 0x407ae6c0 WINPROC_CallWndProc+0x70(msg=0x110, wParam=0x0, lParam=0x403e2328) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:419] in user32 (0x4069f50c) 19 0x407b3be4 CallWindowProcW+0x184(func=0x4085145a, hwnd=0x4002e, msg=0x110, wParam=0x0, lParam=0x403e2328) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:3053] in user32 (0x4069f9f0) 20 0x407e1d13 call_window_proc+0xc3(wparam=0x0, lparam=0x403e2328, unicode=0x1, same_thread=0x1) [/home/wineuser/src/wine/dlls/user/message.c:1475] in user32 (0x4069fa50) 21 0x407e1eef SendMessageTimeoutW+0x14f(hwnd=0x4002e, msg=0x110, wparam=0x0, lparam=0x403e2328, flags=0x0, timeout=0xffffffff, res_ptr=0x4069fad0) [/home/wineuser/src/wine/dlls/user/message.c:1989] in user32 (0x4069faac) 22 0x407e1f35 SendMessageW(hwnd=0x4002e, msg=0x110, wparam=0x0, lparam=0x403e2328) [/home/wineuser/src/wine/dlls/user/message.c:2070] in user32 (0x4069fad8) 23 0x4079427e DIALOG_CreateIndirect(owner=0x1004e, dlgProc=0x406f1780, param=0x403e2328, unicode=0x0, modal=0x1) [/home/wineuser/src/wine/dlls/user/../../windows/dialog.c:667] in user32 (0x4069fbe4) 24 0x407946d9 DialogBoxIndirectParamAorW+0x39(hInstance=0x400000, template=0x403e17a8, owner=0x1004e, dlgProc=0x406f1780, param=0x403e2328, flags=0x2) [/home/wineuser/src/wine/dlls/user/../../windows/dialog.c:841] in user32 (0x4069fc08) 25 0x4079476b DialogBoxIndirectParamA(hInstance=0x400000, template=0x403e17a8, owner=0x1004e, dlgProc=0x406f1780, param=0x403e2328) [/home/wineuser/src/wine/dlls/user/../../windows/dialog.c:852] in user32 (0x4069fc2c) 26 0x406edb53 PROPSHEET_CreateDialog [/home/wineuser/src/wine/dlls/comctl32/propsheet.c:729] in comctl32 (0x4069fc5c) 27 0x406f0961 PropertySheetA+0x2d1(lppsh=0x4069fca4) [/home/wineuser/src/wine/dlls/comctl32/propsheet.c:2794] in comctl32 (0x4069fc80) 28 0x00414354 in polar 32 (+0x14354) (0x00000111) 29 0x00000000 (0x00000000) 0x00415809: cmpl %edx,0x0(%ecx) Wine-dbg>quit WineDbg terminated on pid 0x8

Feb. 26, 2005

Re: MSVCRT: Generating relay stubs for libc forwards/varargs

by Uwe Bonnes

>>>>> "Jon" == Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: Jon> Hi Uwe, >> I think it would be helpfull, if we could generate debug stubs for >> these functions. Can anybody help? Jon> If you have the SDK headers, winedump in spec mode can generate Jon> this for you. For the varargs and libc-forwarded function in msvcrt, I think all that we need is already in out spec file. So no need for the MS SDK. -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Feb. 26, 2005

Re: MSVCRT: Generating relay stubs for libc forwards/varargs

by Jon Griffiths

Hi Uwe, >I think it would be helpfull, if we could generate debug stubs for >these functions. Can anybody help? If you have the SDK headers, winedump in spec mode can generate this for you. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250

Feb. 26, 2005

Re: Problem using winelib to compile Std Lib strings

by Jon Griffiths

Hi Rob, >I get a few errors like the following: >error: ::div has not been declared >error: ::ldiv has not been declared div and ldiv may or may not be included in the std namespace. Try changing the calls to either remove the scope resolution from their calls or adding std before it. >And tons about /usr/include/pthread.h like the following: >error: uintptr_t does not name a type >error: caddr_t has not been declared You may need to rebuild your gcc supplied headers, check out: http://supportforum.sun.com/sunos/index.php?t=msg&th=2097&start=0&rid=0 for details. If you need/needed to make any fixes to Wine to get it working under Solaris, please consider sending any changes to wine-patches or documenting the process (AFAIK not many ppl are using Wine under solaris). Hope this helps, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

Feb. 26, 2005

Re: Relax test requirements to accomodate fuzz of msacm

by Robert Reif

Jeremy White wrote: > > So the only fix I can imagine would be to not use msacm > to perform these conversions and have a parallel set of converters > do this in an aligned fashion. This would probably be the best way for wine. Keep the existing wave mapper code and just add a better converter specifically for this case. Msacm uses the absolute worst possible algorithm that will get the job done so keeping it for compatibility and adding a better one for the wave mapper is a reasonable solution. > > But, again, I wonder if Windows doesn't have this exact same > behavior but we can never find it because all Windows hardware > drivers claim direct support for all of the winmm formats, > so Windows never does a software conversion. > Windows 2000 and xp sound systems have a software mixer called kmixer which will convert any and all application output to the format supported by the hardware. Because of this, some newer systems only support 48kHz 16 bit stereo in hardware and rely on kmixer to do the conversions. This is also why the cooperative level settings in direct sound are no longer needed because kmixer lets the application think it has exclusive access to the sound card and that it supports the requested format. In windows 9x an application has direct and exclusive access to the sound card. Thats the reason for the cooperative levels in direct sound. The wave api gives you the option of using formats only supported by the hardware or using the wave mapper to do the format conversions in software for you. I don't have access to a win9x machine to verify this but my guess is that either mascm is not used for PCM conversions or that it does something extra to deal with it's limitations. The tests pass on windows so fudging the tests to work around a bug in wine is not the best solution to the problem.

Feb. 26, 2005

Re: vartest.c - major pain in the build process

by Mike Hearn

On Sat, 26 Feb 2005 15:56:56 +0100, Marcus Meissner wrote: > well, 25 minutes for a single file and 25 minutes for the rest of the tree? :) It doesn't take 25 minutes here, how much memory do you have? It takes more like 5, which is still excessive :( I disable winetest in my tree entirely, and have done for a long time. It should be disabled in CVS as well, nobody should be building winetest on Linux, it just encourages people to submit useless results by saying "oooh I wonder what happens if I do this". Worse this isn't just about it taking too long, on my machine attempting to compile winetest actually crushes it totally. It descends into swap hell and never seems to re-emerge. I don't think having to hack the build system to avoid a full system hang is really a good thing, even if it is the kernels fault. thanks -mike

Feb. 26, 2005

Re: New uninstaller

by Jonathan Ernst

Le samedi 26 février 2005 à 12:09 +0800, Dmitry Timoshkov a écrit : [...] > > 3) Stringtables > > a)Is there a way to load localized strings without having to guess > > beforehand the size of the string in each language ? > > b)Is there a way to not call LoadString for each string ? > > c)Where is the best place to load every string of a stringtable ? in > > main(), just before calling DialogBox() ? > > It's better to void using string tables, since now you have converted > code to use dialog box instead. How can I do it for messageboxes ? Is there a way to define them in the resource files or do I have to make a dialog instead of messageboxes ? Thanks everyone for your comments, I'll send an updated version soon.

Feb. 26, 2005

Re: vartest.c - major pain in the build process

by Marcus Meissner

On Sat, Feb 26, 2005 at 10:32:11PM +0800, Dmitry Timoshkov wrote: > "Krzysztof Foltman" <kfoltman(a)portal.onet.pl> wrote: > > > Is there any reason for gcc 3.3.1 to spend several minutes on compiling > > dlls/oleaut32/tests/vartest.c ? > > > > I guess it can be explained by optimization stage going nuts on > > compiling long functions with many branches (contained in the macros), > > but there must be a way to speed this up. > > > > It's barely tolerable now, and upgrading gcc is not an option for everyone. > > Well, I'd argue that compilation time of full Wine tree is much longer > than that single test. If you compile from source it's your choice. > > I wonder why you don't complain about programs/winetest linking times. > > Even more drastic route to go is to go and complain to gcc people, > that's certainly not a Wine fault. well, 25 minutes for a single file and 25 minutes for the rest of the tree? :) gcc4 fares better for this test already. I personally change dlls/oleaut32/tests/Makefile to use -O1 after reconfigure. Ciao, Marcus

Feb. 26, 2005

Re: vartest.c - major pain in the build process

by Dmitry Timoshkov

"Krzysztof Foltman" <kfoltman(a)portal.onet.pl> wrote: > Is there any reason for gcc 3.3.1 to spend several minutes on compiling > dlls/oleaut32/tests/vartest.c ? > > I guess it can be explained by optimization stage going nuts on > compiling long functions with many branches (contained in the macros), > but there must be a way to speed this up. > > It's barely tolerable now, and upgrading gcc is not an option for everyone. Well, I'd argue that compilation time of full Wine tree is much longer than that single test. If you compile from source it's your choice. I wonder why you don't complain about programs/winetest linking times. Even more drastic route to go is to go and complain to gcc people, that's certainly not a Wine fault. -- Dmitry.

Feb. 26, 2005