Re: winedbg hanging
On Sat, Feb 26, 2005 at 09:00:04PM +, Alex Woods wrote: > as 64-bit? I'm pretty sure I'm either being dense, or something is > happening that I'm not aware of. Could someone point out which, please? It was a bit of both. There is a dbghelp.dll in the apps directory. I'm off to wallow in shame. Later ;) -- Alex
Re: vartest.c - major pain in the build process
Jakob Eriksson wrote: Also, that won't stop people from running winetest on linux, I'll bet $5 winetest.exe downloads from WRT will keep showing up. Yes. But should something that's useless for the majority of users and developers be enabled by default ? Looks like significant cost with little benefit. That said, maybe winetest should not build by default. That doesn't sound like a lot of fun. Sounds like a good idea. And, by the way, a configure switch to disable all the DirectX modules would be nice too. One doesn't need DirectX to run business software. Or to work on a non-multimedia control like RichEdit20 ;) Or, maybe, a switch to skip building particular DLLs. Krzysztof
winedbg hanging
Hello, When I try to run winedbg with the --gdb option, it simply hangs. I've tracked this down to dbg_get_debuggee_info returning false and then everything falling through to a wait(NULL). The callback that is getting passed SymEnumerateModules doesn't seem to be getting called at all. I've put traces into the SymEnumerateModules but they aren't spitting anything out. Here is the function getting called though: 0035:CALL dbghelp.SymEnumerateModules((0x558b,0002,0040): returning 558c5de8) ret=55b1f6be 0035:RET dbghelp.SymEnumerateModules(003c,55b1f590,55c3f4b0) retval=0001 ret=55b1f6be0 I'm not I believe that it is getting called, at least not the one in dbghelp/module.c. I've stuck an exit at the top of it, and it doesn't. I've noticed a SymEnumerateModules64 that is just a stub, and that's made me suspicious because I'm running a multilib compiled wine on an x86_64 platform. Also, could that be a problem, since gdb is compiled as 64-bit? I'm pretty sure I'm either being dense, or something is happening that I'm not aware of. Could someone point out which, please? ;) Cheers. -- Alex
Re: MSVCRT: Generating relay stubs for libc forwards/varargs
> 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. If you want to write the tracing code by hand, yes. If you have the headers winedump will generate the TRACE() statements for you as well. Cheers, Jon = "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250
Re: vartest.c - major pain in the build process
Mike Hearn wrote: 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 Actually there may be some value in running winetest on Linux. [*] Also, that won't stop people from running winetest on linux, I'll bet $5 winetest.exe downloads from WRT will keep showing up. * - We not only get statistics of how the Windows API works. We also get coverage of how well Wine is implemented in the wild, with different versions of Linux. too long, on my machine attempting to compile winetest actually crushes it totally. It descends into swap hell and never seems to re-emerge. That said, maybe winetest should not build by default. That doesn't sound like a lot of fun. regards, Jakob
Re: MSVCRT: Generating relay stubs for libc forwards/varargs
Uwe Bonnes <[EMAIL PROTECTED]> writes: > in msvcrt a lot of functions are of type vararg (e.g. printf) or are > forwards into the Linux libc (e.g. strstr) and so leave no trace in a +relay > log. This makes it harder to debug. The forwards into libc show up in relay just fine, they are not different from other functions. The varargs one can't since we have no idea how much stack to copy, but what you can do is add some traces in the function itself. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Relax test requirements to accomodate fuzz of msacm
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.
Crash in Polar Precision Performance Software
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: EBX:4082f8d4 ECX:a84c73e0 EDX:04e7 ESI:4069f3f0 EDI:00020040 Stack dump: 0x4069e63c: 00414e23 4069f3f0 04e7 00020040 0x4069e64c: 4069f3f0 4069e6c4 4082f8d4 004144c9 0x4069e65c: 00020040 4069f3f0 04e7 0052c3ec 0x4069e66c: 00020040 0638 00020040 00a0 0x4069e67c: 00020040 408517a8 4069e6c4 4082f8d4 0x4069e68c: 403d6a28 403d6980 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=0x, 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=0x, 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=0x4
Re: MSVCRT: Generating relay stubs for libc forwards/varargs
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 [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250
Re: MSVCRT: Generating relay stubs for libc forwards/varargs
> "Jon" == Jon Griffiths <[EMAIL PROTECTED]> 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[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Problem using winelib to compile Std Lib strings
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 [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250
Re: Relax test requirements to accomodate fuzz of msacm
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.
Re: New uninstaller
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. signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: vartest.c - major pain in the build process
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
Re: vartest.c - major pain in the build process
On Sat, Feb 26, 2005 at 10:32:11PM +0800, Dmitry Timoshkov wrote: > "Krzysztof Foltman" <[EMAIL PROTECTED]> 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
Re: vartest.c - major pain in the build process
"Krzysztof Foltman" <[EMAIL PROTECTED]> 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.
Re: Relax test requirements to accomodate fuzz of msacm
Robert Reif wrote: Jeremy White wrote: Robert has persuaded me that msacm on Windows does make 'fuzzy' conversions; an 8,000 byte buffer is up sampled to a 47,992 byte buffer instead of the logical (and correct seeming) 48,000 byte buffer. This means that when we go to get the position after playing the answer comes up as 47992 instead of 48,000, which causes a winmm test failure. The real fix is to fix the wave mapper to do another conversion when the previous one is incomplete. We will have to do this anyway if we ever try to support non PCM formats. I don't think that is right; the conversion is not incomplete. In the specific example of 8000 into 48000 (a 6 to 1 ratio), rather than the first source byte going into the first six dest bytes, instead the first source byte goes into the first four destination bytes, and then the second source byte goes into the next six, and so on. That leaves you with an uneven use of the dest buffer, and hence the left over bytes. So the conversion is, in fact, complete, it's just for some odd reason not aligned on the initial buffer. I wrote a patch in the wavemapper to 'fill' such unaligned conversions, but then when I read it I realized it was a wrong change. 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. 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. Hence, in my humble opinion, this patch remains correct; I believe that Wine does exactly what Windows would do if it faced the same limited hardware functionality. Further, I don't see any benefit in leaving these tests broken; the reason to do that would be to spur additional development, and I do not think that any further Wine changes are appropriate. Cheers, Jeremy
Re: New uninstaller
Le samedi 26 fÃvrier 2005 Ã 09:49 +0900, Mike McCormack a Ãcrit : [...] > Cool. Some comments: > > The dialog box procedure should not handle WM_PAINT or WM_CLOSE, so just > delete those cases from the switch statement. > Ok I did it, but the listbox should be updated when the user ask to uninstall someting OR the user changes the filter string ? How can I do that using only WM_INITDIALOG ? > Don't send WM_SETFONT messages to the controls in the dialog. Let the > dialog template define what the dialog looks like. I removed it. > > Your WM_INITDIALOG handler should fill the listbox, not WM_PAINT. > See my first question. > You can remove the "No items selected" message if uninstall is clicked > without a listbox element select. That's just going to annoy people, > and it's not internationalized. I removed it. Internationalizaton will come after everything is alright. Thanks. P.S. Ivan Leo Puti I don't know if it'll be better to use WinMain. Using WinMain will make me to parse the command line manually isn't it ? uninstaller2.tar.gz Description: application/compressed-tar signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
vartest.c - major pain in the build process
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. Krzysztof
Re: Relax test requirements to accomodate fuzz of msacm
Jeremy White wrote: Robert has persuaded me that msacm on Windows does make 'fuzzy' conversions; an 8,000 byte buffer is up sampled to a 47,992 byte buffer instead of the logical (and correct seeming) 48,000 byte buffer. This means that when we go to get the position after playing the answer comes up as 47992 instead of 48,000, which causes a winmm test failure. The real fix is to fix the wave mapper to do another conversion when the previous one is incomplete. We will have to do this anyway if we ever try to support non PCM formats.
Re: USER32: GetScrollBarInfo
В сообщении от 26 Февраль 2005 01:42 Alexandre Julliard написал(a):
> Vitaly Lipatov <[EMAIL PROTECTED]> writes:
> > +static BOOL SCROLL_GetScrollBarInfo(HWND hwnd, LONG idObject,
> > LPSCROLLBARINFO psbi) +{
> > +RECT rect;
> > +INT arrowSize, thumbSize, thumbPos, nBar, vertical;
> > +FIXME("check me");
>
> This doesn't sound very encouraging...
I have not time for write full test this function, but I have the
implementation. If anyone will use it, he will can check for correctly.
P.S.
Or we can remove this line with FIXME :)
--
Vitaly Lipatov, ALT Linux Team
Russia, Saint-Petersburg, www.etersoft.ru
