Re: Mac OS X/Intel port
On 1/22/06, Chris Campbell <[EMAIL PROTECTED]> wrote: > Hi, >I just recently downloaded the CVS of WINE and tried to build it > on an Apple Intel machine. I ran into some problems during the build > and fixed them. I then got to the server and the build quit on > context_i386.c. There is nothing in that file that handles darwin/ > Mac OS X. It looks like the ptrace functionality (GETREGS, etc) that > is used on Linux and FreeBSD is not present in the xnu kernel... >I would like to get WINE working on x86 OS X. Can anyone tell me > who is working on this? I would like to help with this effort. > Alexandre Julliard <[EMAIL PROTECTED]>. -- James Hawkins
Mac OS X/Intel port
Hi, I just recently downloaded the CVS of WINE and tried to build it on an Apple Intel machine. I ran into some problems during the build and fixed them. I then got to the server and the build quit on context_i386.c. There is nothing in that file that handles darwin/ Mac OS X. It looks like the ptrace functionality (GETREGS, etc) that is used on Linux and FreeBSD is not present in the xnu kernel... I would like to get WINE working on x86 OS X. Can anyone tell me who is working on this? I would like to help with this effort. Chris
Re: Dreamcom Kubik SMS crash
Pavel Troller wrote: Hi, all the wine developers, thanks for wine, it's going to be really powerful now! However, even the most recent CVS update from yesterday still fails to run a small SMS sending program called Kubik SMS from DreamCom. This program can be freely downloaded: http://ww.dreamcom.cz/dream556.zip Program now installs smoothly, including Mozilla ActiveX Control (thanks for using the repackaged ReactOS version). However, after trying to run the program, the following crash appears: Looks like some shdocvw functionality is missing in Wine, as I installed IE6 and then ran DreamCom.exe and it worked. Maybe Jacek's work on Mozilla embedding will help. Mike
Dreamcom Kubik SMS crash
Hi, all the wine developers, thanks for wine, it's going to be really powerful now! However, even the most recent CVS update from yesterday still fails to run a small SMS sending program called Kubik SMS from DreamCom. This program can be freely downloaded: http://ww.dreamcom.cz/dream556.zip Program now installs smoothly, including Mozilla ActiveX Control (thanks for using the repackaged ReactOS version). However, after trying to run the program, the following crash appears: [EMAIL PROTECTED]:/opt/samba-dir/DreamCom$ wine DreamCom.exe fixme:ole:CoResumeClassObjects stub fixme:wininet:InternetGetConnectedState always returning LAN connection. wine: Unhandled exception 0x0eedfade at address 0x:0x7b83f040 (thread 0009), starting debugger... WineDbg starting on pid 0x8 First chance exception: 0xc025 in 32-bit code (0x7bc2cf30). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7bc2cf30 ESP:7fc6f400 EBP:7fc6f458 EFLAGS:00200282( - 00 - -IS1) EAX:7fc6f400 EBX:7bc70134 ECX:7fc6f470 EDX:c025 ESI:7fc6f7d0 EDI:7fc6f464 Stack dump: 0x7fc6f400: c025 0001 7fc6f7d0 7fc6f454 0x7fc6f410: 0002 7b82 7fc6f4e8 0x7fc6f420: 7bc36cdd 7fc6f438 0001 7fc6f51c 0x7fc6f430: 7bc2d2e0 0001 7bc70134 0002 0x7fc6f440: 7b82 7fc6f4e8 7fc6f424 7bc2ceea 0x7fc6f450: 7bc2cee0 7fc6f7d0 7fc6f7bc 7bc557f3 Backtrace: =>1 0x7bc2cf30 __regs_RtlRaiseException+0x50 in ntdll (0x7bc2cf30) 2 0x7bc557f3 in ntdll (+0x457f3) (0x7bc557f3) 3 0x7bc2cf3a RtlRaiseException+0x6 in ntdll (0x7bc2cf3a) 4 0x004b694e in dreamcom (+0xb694e) (0x004b694e) 5 0x004b6981 in dreamcom (+0xb6981) (0x004b6981) 6 0x005dc0e1 in dreamcom (+0x1dc0e1) (0x005dc0e1) 7 0x005e2ee1 in dreamcom (+0x1e2ee1) (0x005e2ee1) 8 0x004241a8 in dreamcom (+0x241a8) (0x004241a8) 9 0x004243d6 in dreamcom (+0x243d6) (0x004243d6) 10 0x00424622 in dreamcom (+0x24622) (0x00424622) 11 0x00424590 in dreamcom (+0x24590) (0x00424590) 12 0x00428ce6 in dreamcom (+0x28ce6) (0x00428ce6) 13 0x00424441 in dreamcom (+0x24441) (0x00424441) 14 0x00424622 in dreamcom (+0x24622) (0x00424622) 15 0x00424561 in dreamcom (+0x24561) (0x00424561) 16 0x00428ce6 in dreamcom (+0x28ce6) (0x00428ce6) 17 0x004704fa in dreamcom (+0x704fa) (0x004704fa) 18 0x00425350 in dreamcom (+0x25350) (0x00425350) 19 0x00422af3 in dreamcom (+0x22af3) (0x00422af3) 20 0x0041ed1c in dreamcom (+0x1ed1c) (0x0041ed1c) 21 0x0041eea6 in dreamcom (+0x1eea6) (0x0041eea6) 22 0x0041ef37 in dreamcom (+0x1ef37) (0x0041ef37) 23 0x0046fe9e in dreamcom (+0x6fe9e) (0x0046fe9e) 24 0x00477580 in dreamcom (+0x77580) (0x00477580) 25 0x0060c15c in dreamcom (+0x20c15c) (0x0060c15c) 26 0x0060acc3 in dreamcom (+0x20acc3) (0x0060acc3) 27 0x006525c0 in dreamcom (+0x2525c0) (0x006525c0) 28 0x7b866426 in kernel32 (+0x46426) (0x7b866426) 29 0x20004c07 wine_switch_to_stack+0x17 in libwine.so.1 (0x20004c07) 0x7bc2cf30 __regs_RtlRaiseException+0x50 in ntdll: jmp 0x7bc2cf0a __regs_RtlRaiseException+0x2a in ntdll Modules: Module Address Debug info Name (120 modules) PE 0x0040-0073 Export dreamcom PE 0x1000-10006000 Deferredmozctlx ELF 0x2000-2001a000 Export libwine.so.1 ELF 0x2001a000-2002b000 Deferredlibpthread.so.0 ELF 0x2002b000-20121000 Deferredlibwine_unicode.so.1 ELF 0x20121000-20143000 Deferredlibm.so.6 ELF 0x20143000-201ce000 Deferredoleaut32 \-PE 0x2016-201ce000 \ oleaut32 ELF 0x201ce000-201ed000 Deferredcabinet \-PE 0x201d-201ed000 \ cabinet ELF 0x201ed000-2020a000 Deferredmpr \-PE 0x201f-2020a000 \ mpr ELF 0x2020a000-2021e000 Deferredlz32 \-PE 0x2021-2021e000 \ lz32 ELF 0x2021e000-2029c000 Deferredwinmm \-PE 0x2023-2029c000 \ winmm ELF 0x2029c000-2030c000 Deferredlibfreetype.so.6 ELF 0x2030c000-20385000 Deferredwinex11 \-PE 0x2032-20385000 \ winex11 ELF 0x20385000-2038e000 Deferredlibsm.so.6 ELF 0x2038e000-203a5000 Deferredlibice.so.6 ELF 0x203a5000-203ab000 Deferredlibxxf86dga.so.1 ELF 0x203ab000-203b1000 Deferredlibxxf86vm.so.1 ELF 0x203b1000-203b9000 Deferredlibxrender.so.1 ELF 0x203b9000-203bd000 Deferredlibxrandr.so ELF 0x203bd000-203c Deferrediso8859-2.so ELF 0x203c-203ec000 Deferredlibssl.so.0.9.6 ELF 0x203ec000-20403000 Deferredmsacm \-PE 0x203f-20403000 \ msacm ELF 0x20403000-20442000 Deferredriched20 \-PE 0x2041-20442000 \ riched20 PE 0x2045-204af000 Deferredxpcom ELF
Re: [wcmd] Make start a built-in command
On 1/21/06, Daniel R. Kegel <[EMAIL PROTECTED]> wrote:
> ...
> + wsprintf(new_cmd, "%s %s", externalstart, command);
> + WCMD_output("Running ");
> + WCMD_output(new_cmd);
> + WCMD_output("\n");
> + WCMD_run_program (new_cmd);
> + LocalFree ((HANDLE)new_cmd);
Er, without those WCMD_output debug statements, of course. Sorry 'bout that.
Annoyingly, fixing this reminded me of what a pile of stinking doo
our wcmd (and my start.exe) are. Hopefully I'll forget again soon :-)
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Golden apps?
On 1/21/06, Dan Kegel <[EMAIL PROTECTED]> wrote: > I'm trying to get a list of 'gold' apps from the appdb, > but it doesn't have a way to search like that, > so I filed http://bugs.winehq.org/show_bug.cgi?id=4365 > > In the meantime, what apps work *really well* with Wine > at the moment? Firefox 1.5 seems to be in good shape. > I'm looking for apps that will demo well for my talk at SCALE in two weeks. > If you looking for games, I maintain the AppDB entries for Diablo 2 and Warcraft 3. I've finally rated both gold now that all the critical features of the games work with the current wine releases. And they run stable with only a few steps. They look great. Although the movies don't play right in Warcraft 3, as there are crashing bugs with quartz, so I've done all that I have done all along: removed the movies folder. Then the game doesn't even use quartz. I don't consider this a critical issue since this recommendation is given to windows users too when the game movies don't work for them. I'll have to try to debug it when I have a day off of school. Diablo 2 does still run in D3D mode if you hack the gamma function to DD_OK. Everything else there is ok. Jesse
Re: Threading performance
On Sat, 2006-01-21 at 17:37 -0600, Evil wrote: > Hi all, > > I was just playing around with the Video Stress Test in CounterStrike: > Source, and noted a lot of odd stuttering. The demo would run for about > 15 seconds at 13fps, then completely freeze up for about 15 seconds. > Then, it would start running again... only to freeze/unfreeze every 15 > seconds or so. Is this sound stuttering you're talking about? If so, I've been noticing it too since about 2 months ago. I think it has to do with DirectSound. If you run Steam in a terminal with debug messages turned off, you'll probably see a message that says something like this (taken from memory here): "This soundcard's driver does not support direct access. The (slower) DirectSound HEL mode will be used instead." > > Just for fun, I reniced all the wine processes down to +15. The result: > the demo runs completely smooth (well, at 13fps... but that's on > account of my low system specs) from start to finish. Cool tip. Never thought of it. I'll try that. Thanks! :) > > I did some searching and noticed a similar report last year: > http://www.winehq.com/hypermail/wine-devel/2004/08/0306.html Yep, similar symptoms rear their heads from time to time with HL2 and related games (including CS:S) There's bug 3665 that deals with something a lot like what you're describing, with the HL2 intro video: http://bugs.winehq.org/show_bug.cgi?id=3665 > > I wasn't having this problem last year, but I've updated so many things > in the last month (like moving from KDE3.4 to KDE3.5, and updating WINE > from CVS), so I'm afraid I can't pinpoint the exact cause right now. > > Does anyone know of another, more permanent, workaround rather than > re-nicing after starting WINE? Is there anything I can do/test that > might help the developers if this is a real threading issue? You might want to try and get some traces (+dsound would probably be a good start; I suppose someone more experienced could give some others to try) Regards, James > > -J > > AMD AthlonXP 2000+ > ATI 9600XT w/128MB > 1GB System RAM > Mandriva 2006.0, updated to KDE3.5 > >
StartServiceCtrlDispatcher/
Hallo,
jtagserver.exe from the Altera Quartus suite hangs in a call to
ConnectNamedPipe (as a result of a call to StartServiceCtrlDispatcherA())
Anybody an idea what is going wrong?
Appended a +relay,+snoop,+ntdll,+file,+server,+advapi log from the point
where the main process is started.
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
0009:Starting process L"C:\\altera\\quartus51\\bin\\jtagserver.exe"
(entryproc=0x41a49a)
0009:Call msvcrt.__set_app_type(0001) ret=0041a4cc
0009:Ret msvcrt.__set_app_type() retval=7fa6f018 ret=0041a4cc
0009:Call msvcrt.__p__fmode() ret=0041a4e1
0009:Ret msvcrt.__p__fmode() retval=7fa6efe8 ret=0041a4e1
0009:Call msvcrt.__p__commode() ret=0041a4ef
0009:Ret msvcrt.__p__commode() retval=7fa6eff0 ret=0041a4ef
0009:Call msvcrt._controlfp(0001,0003) ret=0041a5dd
0009:Ret msvcrt._controlfp() retval=0009001f ret=0041a5dd
0009:Call msvcrt._initterm(00420020,00420024) ret=0041a531
0009:Ret msvcrt._initterm() retval= ret=0041a531
0009:Call msvcrt.__getmainargs(7fb9feec,7fb9fedc,7fb9fee8,,7fb9fee0)
ret=0041a555
0009:Ret msvcrt.__getmainargs() retval= ret=0041a555
0009:Call msvcrt._initterm(0042,0042001c) ret=0041a564
0009:Call msvcrt._onexit(00402740) ret=0041a202
0009:Call kernel32.InitializeCriticalSection(7fa6e9d0) ret=7fa3b76e
0009:Call ntdll.RtlInitializeCriticalSection(7fa6e9d0) ret=7fc6007c
0009:Ret ntdll.RtlInitializeCriticalSection() retval= ret=7fc6007c
0009:Ret kernel32.InitializeCriticalSection() retval= ret=7fa3b76e
0009:Call ntdll.RtlAllocateHeap(7fce,0008,0080) ret=7fa3a5fe
0009:Ret ntdll.RtlAllocateHeap() retval=7fcfe888 ret=7fa3a5fe
0009:Ret msvcrt._onexit() retval=00402740 ret=0041a202
0009:Call msvcrt._onexit(0040875c) ret=0041a202
0009:Ret msvcrt._onexit() retval=0040875c ret=0041a202
0009:Call msvcrt._onexit(00409850) ret=0041a202
0009:Ret msvcrt._onexit() retval=00409850 ret=0041a202
0009:Call msvcrt._onexit(0040988b) ret=0041a202
0009:Ret msvcrt._onexit() retval=0040988b ret=0041a202
0009:Call msvcrt._onexit(004166b3) ret=0041a202
0009:Ret msvcrt._onexit() retval=004166b3 ret=0041a202
0009:Ret msvcrt._initterm() retval= ret=0041a564
0009:Call msvcrt.__p___initenv() ret=0041a56a
0009:Ret msvcrt.__p___initenv() retval=7fa5a614 ret=0041a56a
0009:Call kernel32.GetVersionExA(7fb9fdec) ret=00414a0b
0009:Call ntdll.RtlGetVersion(7fb9fc24) ret=7fc6cf3d
0009:Ret ntdll.RtlGetVersion() retval= ret=7fc6cf3d
0009:Ret kernel32.GetVersionExA() retval=0001 ret=00414a0b
0009:Call advapi32.StartServiceCtrlDispatcherA(00420078) ret=00413a3e
trace:advapi:StartServiceCtrlDispatcherA 0x420078
0009:Call kernel32.MultiByteToWideChar(,,00420088 "Altera JTAG
Server",,,) ret=7f99ad13
0009:Ret kernel32.MultiByteToWideChar() retval=0013 ret=7f99ad13
0009:Call ntdll.RtlAllocateHeap(7fce,0008,005e) ret=7f99ad2f
0009:Ret ntdll.RtlAllocateHeap() retval=7fcfe910 ret=7f99ad2f
0009:Call kernel32.MultiByteToWideChar(,,00420088 "Altera JTAG
Server",,7fcfe944,0013) ret=7f99ad48
0009:Ret kernel32.MultiByteToWideChar() retval=0013 ret=7f99ad48
trace:advapi:service_run_threads starting 1 pipe listener threads
0009:Call ntdll.RtlAllocateHeap(7fce,,0004) ret=7f99ab83
0009:Ret ntdll.RtlAllocateHeap() retval=7fcfe630 ret=7f99ab83
0009:Call
kernel32.CreateThread(,,7f99c9a0,7fcfe910,,)
ret=7f99abb8
0009:Call ntdll.RtlAllocateHeap(7fce,,0008) ret=7fc6740b
0009:Ret ntdll.RtlAllocateHeap() retval=7fcfe3a8 ret=7fc6740b
0009:Call
ntdll.RtlCreateUserThread(,,0001,,,,7fc672e0,7fcfe3a8,7fb9fc78,7fb9fc6c)
ret=7fc67451
0009: *fd* 9 <- 30
0009: new_thread( access=001f03ff, attributes=, suspend=1, request_fd=9
)
0009: new_thread() = 0 { tid=000a, handle=0x44 }
0009:Ret ntdll.RtlCreateUserThread() retval= ret=7fc67451
0009:Call ntdll.NtResumeThread(0044,7fb9fc74) ret=7fc674b5
0009: resume_thread( handle=0x44 )
0009: resume_thread() = 0 { count=1 }
0009:Ret ntdll.NtResumeThread() retval= ret=7fc674b5
0009:Ret kernel32.CreateThread() retval=0044 ret=7f99abb8
0009:Call
kernel32.WaitForMultipleObjectsEx(0001,7fcfe630,0001,,)
ret=7f99ac24
0009:Call
ntdll.NtWaitForMultipleObjects(0001,7fb9fba0,0001,,)
ret=7fc604d9
0009: select( flags=5, cookie=0x7fb9fa54, signal=(nil), timeout=0,
handles={0x44} )
0009: select() = PENDING
000a: *fd* 11 <- 31
000a: *fd* 13 <- 32
000a: init_thread( unix_pid=3608, unix_tid=3615, teb=0xb7f6,
peb=0x7ffdf6e0, entry=0x7fc672e0, ldt_copy=0xb7f71860, reply_fd=11, wait_fd=13,
debug_level=1 )
000a: init_thread() = 0 { pid=0008, tid=000a, info_size=0,
server_start=11378851
Threading performance
Hi all, I was just playing around with the Video Stress Test in CounterStrike: Source, and noted a lot of odd stuttering. The demo would run for about 15 seconds at 13fps, then completely freeze up for about 15 seconds. Then, it would start running again... only to freeze/unfreeze every 15 seconds or so. Just for fun, I reniced all the wine processes down to +15. The result: the demo runs completely smooth (well, at 13fps... but that's on account of my low system specs) from start to finish. I did some searching and noticed a similar report last year: http://www.winehq.com/hypermail/wine-devel/2004/08/0306.html I wasn't having this problem last year, but I've updated so many things in the last month (like moving from KDE3.4 to KDE3.5, and updating WINE from CVS), so I'm afraid I can't pinpoint the exact cause right now. Does anyone know of another, more permanent, workaround rather than re-nicing after starting WINE? Is there anything I can do/test that might help the developers if this is a real threading issue? -J AMD AthlonXP 2000+ ATI 9600XT w/128MB 1GB System RAM Mandriva 2006.0, updated to KDE3.5
Re: bug in atof
Uwe Bonnes elektron.ikp.physik.tu-darmstadt.de> writes: > > > "Peter" == Peter Beutner gmx.net> writes: > > Peter> Uwe Bonnes schrieb: > >>> "Peter" == Peter Beutner gmx.net> writes: > >> > Peter> Which means that '7.8912654773d210' is the same as > Peter> '7.8912654773e210'. > >> Running the test with native msvcrt doesn't give me 7.8912654773e210 > >> neither... > The test linked libc atof and not msvcrt atof. I don't know if this is a > bug in our headers or something else. I will post a corrected patch for the > test suite ... Hi, looks like bug 4337 wasn't really related to the bug in the simple test app i submitted (Hey , i'm just a poor debugging noob :) ). Bug 4337 is already fixed by a patch from Julliard (thx) ) Should i file a bug report for the bug in the simple test app (ripped from from msdn) or is it a known problem?
Re: Golden apps?
On 1/21/06, Dan Kegel <[EMAIL PROTECTED]> wrote: > It'd be cool if > OpenOffice 2.0.1 isn't (http://bugs.winehq.org/show_bug.cgi?id=4366). gaah. somehow gmail sent when I hit tab. I meant to say It'd be cool if OpenOffice 2.0.1 worked, but it doesn't even start (http://bugs.winehq.org/show_bug.cgi?id=4366). Y'know, OpenOffice has some good regression tests. It'd be great if OOo worked on Wine, 'cause then we could run those regression tests nightly; that would probably help identify new wine problems early. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Golden apps?
I'm trying to get a list of 'gold' apps from the appdb, but it doesn't have a way to search like that, so I filed http://bugs.winehq.org/show_bug.cgi?id=4365 In the meantime, what apps work *really well* with Wine at the moment? Firefox 1.5 seems to be in good shape. I'm looking for apps that will demo well for my talk at SCALE in two weeks. It'd be cool if OpenOffice 2.0.1 isn't (http://bugs.winehq.org/show_bug.cgi?id=4366). -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Compile failure [dlls/dinput/joustick.c:177 ... _dfDIJoystick]
On Fri, Jan 20, 2006 at 08:54:07PM -0500, Morten Welinder wrote: > Hi there, > > on a more-or-less default SuSE 9.3 system I have been getting this > error for a while. > > Ideas? Did you run "make clean" in between? My build for 9.3 went fine, but I start from vanilla state everytime. Ciao, Marcus
Re: winedbg symbols completely screwed
Eric Pouech wrote: Christer Palm wrote: The thing is that I can't see that this is the case here. I have: [EMAIL PROTECTED] ~]$ find ~/.wine/drive_c/ -name "MFC*" -o -name "mfc*" from one of your previous posts: wine: Unhandled page fault on read access to 0x003c at address 0x5f4056dd (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x003c in 32-bit code (0x5f4056dd). In 32 bit mode. fixme:dbghelp:sffip_cb NIY on 'E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb' fixme:dbghelp:sffip_cb NIY on 'C:\hager\Semiolog\Apps\MFC42.PDB' fixme:dbghelp_msc:codeview_parse_type_table Not adding parameters' types to function signature fixme:dbghelp_msc:codeview_parse_type_table Unsupported type-id leaf a fixme:dbghelp_msc:dump : 06 00 0a 00 01 00 50 f1 ..P. fixme:dbghelp_msc:codeview_get_type Returning NULL symt for type-id 1053 Ah, I suppose you mean the 'E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb' line. There is no such file. In fact, I don't even have a drive mapping for E:. I've been assuming that winedbg is getting this bogus path from the executable (perhaps the location of MFC42.PDB when MFC42 was originally compiled or something). I ran the ChkMatch tool from www.debuginfo.com to verify that the PDB and DLL really match, and it also confirms that the bogus E: path really comes from MFC42.DLL. This doesn't rule out the (rather unlikely, I would say) possibility that the PDB is corrupt in some other way, of course. Perhaps someone can mail me a "known good" pair of MFC42.DLL/PDB files? [EMAIL PROTECTED] tmp]$ wine ChkMatch.exe -c /home/palm/.wine/drive_c/windows/system/MFC42.DLL /home/palm/.wine/drive_c/hager/Semiolog/Apps/MFC42.PDB ChkMatch - version 1.0 Copyright (C) 2004 Oleg Starodumov http://www.debuginfo.com/ Executable: /home/palm/.wine/drive_c/windows/system/MFC42.DLL Debug info file: /home/palm/.wine/drive_c/hager/Semiolog/Apps/MFC42.PDB Executable: TimeDateStamp: 35889e42 Debug info: 2 ( CodeView ) TimeStamp: 35887c4e Characteristics: 0 MajorVer: 0 MinorVer: 0 Size: 55 RVA: FileOffset: 000f3000 CodeView format: NB10 Signature: 35889e42 Age: 2 PDB File: E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb Debug info: 10 ( Unknown ) TimeStamp: Characteristics: 0 MajorVer: 0 MinorVer: 0 Size: 0 RVA: FileOffset: Debug info: Unknown. Debug information file: Format: PDB 2.00 Signature: 35889e42 Age: 2 Result: Matched Regards, -- Christer Palm
Compile failure [dlls/dinput/joustick.c:177 ... _dfDIJoystick]
Hi there, on a more-or-less default SuSE 9.3 system I have been getting this error for a while. Ideas? M. make[3]: Entering directory `/home/welinder/wine/dlls/dinput/tests' ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole joystick.o \ keyboard.o mouse.o testlist.o -o dinput_test.exe.so -L../../../libs/port -lwi\ ne_port -L../../../dlls -L../../../dlls/dinput -L../../../dlls/ole32 -L../../..\ /dlls/version -L../../../dlls/user32 -L../../../dlls/kernel32 -L../../../libs -\ ldinput -lole32 -lversion -luser32 -lkernel32 -ldxguid -luuid -ldxerr8 joystick.o(.text+0x666): In function `EnumJoysticks': /home/welinder/wine/dlls/dinput/tests/joystick.c:177: undefined reference to `c\ _dfDIJoystick' joystick.o(.text+0x6b0):/home/welinder/wine/dlls/dinput/tests/joystick.c:181: u\ ndefined reference to `c_dfDIJoystick2' collect2: ld returned 1 exit status winegcc: gcc failed. make[3]: *** [dinput_test.exe.so] Error 2 make[3]: Leaving directory `/home/welinder/wine/dlls/dinput/tests'
Re: bug in atof
Hello, Peter Beutner schrieb: > It doesn't parse 'd' or 'D' as exponent. > Seems to be a "MS-only extension" to the standard :p I would guess this comes from Fortran. Real values are printed with "e", those with double precision printed with "d". And as one usually uses double precision in Fortran, one ends up with several data files with "d" instead of "e" as exponent. Tobias PS: I think it is a stupid idea, but as - an excuse - Fortran is quite old (and even worked with punched cards).
Re: bug in atof
> "Peter" == Peter Beutner <[EMAIL PROTECTED]> writes: Peter> Uwe Bonnes schrieb: >>> "Peter" == Peter Beutner <[EMAIL PROTECTED]> writes: >> Peter> Which means that '7.8912654773d210' is the same as Peter> '7.8912654773e210'. >> Running the test with native msvcrt doesn't give me 7.8912654773e210 >> neither... The test linked libc atof and not msvcrt atof. I don't know if this is a bug in our headers or something else. I will post a corrected patch for the test suite ... -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: bug in atof
Uwe Bonnes schrieb: >> "Peter" == Peter Beutner <[EMAIL PROTECTED]> writes: > > > Peter> Which means that '7.8912654773d210' is the same as > Peter> '7.8912654773e210'. > > Running the test with native msvcrt doesn't give me 7.8912654773e210 > neither... Using the test that Louis posted in his first email ... [EMAIL PROTECTED] ~/coding $ /opt/xmingw/bin/i386-mingw32msvc-gcc -o test_atof.exe test_atof.c [EMAIL PROTECTED] ~/coding $ WINEDLLOVERRIDES=msvcrt=b wine test_atof.exe atof test: " -2309.12E-15"; float: -2.309120e-12 atof test: "7.8912654773d210"; float: 7.891265e+00 atoi test: " -9885 pigs"; integer: -9885 atol test: "98854 dollars"; long: 98854 [EMAIL PROTECTED] ~/coding $ WINEDLLOVERRIDES=msvcrt=n wine test_atof.exe atof test: " -2309.12E-15"; float: -2.309120e-012 atof test: "7.8912654773d210"; float: 7.891265e+210 atoi test: " -9885 pigs"; integer: -9885 atol test: "98854 dollars"; long: 98854 So it works here as expected. > > Peter> But on linux we have(quoted from 'man strtod'): - A decimal > Peter> number consists of a nonempty sequence of decimal digits pos- > Peter> sibly containing a radix character (decimal point, locale > Peter> dependent, usually ``.''), optionally followed by a decimal > Peter> exponent. A decimal exponent consists of an ``E'' or ``e'', > Peter> followed by an optional plus or minus sign, followed by a > Peter> non-empty sequence of decimal digits, and indicates > Peter> multiplication by a power of 10. > > Peter> It doesn't parse 'd' or 'D' as exponent. Seems to be a "MS-only > Peter> extension" to the standard :p > > Could you please check '7.8912654773d210' gives the expected result on > windows? Hmm don't have any installed windows around here atm.But isn't it enough that the native msvcrt gives the expected result?
Re: bug in atof
> "Peter" == Peter Beutner <[EMAIL PROTECTED]> writes: Peter> Which means that '7.8912654773d210' is the same as Peter> '7.8912654773e210'. Running the test with native msvcrt doesn't give me 7.8912654773e210 neither... Peter> But on linux we have(quoted from 'man strtod'): - A decimal Peter> number consists of a nonempty sequence of decimal digits pos- Peter> sibly containing a radix character (decimal point, locale Peter> dependent, usually ``.''), optionally followed by a decimal Peter> exponent. A decimal exponent consists of an ``E'' or ``e'', Peter> followed by an optional plus or minus sign, followed by a Peter> non-empty sequence of decimal digits, and indicates Peter> multiplication by a power of 10. Peter> It doesn't parse 'd' or 'D' as exponent. Seems to be a "MS-only Peter> extension" to the standard :p Could you please check '7.8912654773d210' gives the expected result on windows? Peter> [1] Peter> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_atof.2c_.atoi.2c_._atoi64.2c_.atol.asp -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: bug in atof
Uwe Bonnes schrieb:
>> "Louis" == Louis Lenders <[EMAIL PROTECTED]> writes:
>
> Louis> Hi, i filed a bug ( bug 4337) and looks like there's a bug in
> Louis> atof. Is there a difference between linux' atof and msvcrt's one?
> Louis> Even following simple program (from msdn) yields wrong results:
> Louis> // crt_atof.c #include #include
>
> Louis> int main( void ) { char *s; double x; int i; long l;
>
> Louis>s = " -2309.12E-15"; /* Test of atof */ x = atof( s ); printf(
> Louis> "atof test: \"%s\"; float: %e\n", s, x );
>
> Louis>s = "7.8912654773d210"; /* Test of atof */ x = atof( s );
> Louis> printf( "atof test: \"%s\"; float: %e\n", s, x );
>
> Louis>s = " -9885 pigs"; /* Test of atoi */ i = atoi( s ); printf(
> Louis> "atoi test: \"%s\"; integer: %d\n", s, i );
>
> Louis>s = "98854 dollars"; /* Test of atol */ l = atol( s ); printf(
> Louis> "atol test: \"%s\"; long: %ld\n", s, l ); } the exponent value in
> Louis> float x are wrong. Thanks
>
>
> Not atof() is the cause of your bug, but printf().
> I entered your sample into the test suite to show the correct behaviour of
> wine's implementation of atof. The printf() test has already a todo for the
> incorrect exponent output.
quoted from msdn[1]:
---
The string argument to atof and _wtof has the following form:
[whitespace] [sign] [digits] [.digits] [ {d | D | e | E }[sign]digits
---
Which means that '7.8912654773d210' is the same as '7.8912654773e210'.
But on linux we have(quoted from 'man strtod'):
-
A decimal number consists of a nonempty sequence of decimal digits pos-
sibly containing a radix character (decimal point, locale dependent,
usually ``.''), optionally followed by a decimal exponent. A decimal
exponent consists of an ``E'' or ``e'', followed by an optional plus or
minus sign, followed by a non-empty sequence of decimal digits, and
indicates multiplication by a power of 10.
It doesn't parse 'd' or 'D' as exponent.
Seems to be a "MS-only extension" to the standard :p
[1]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_atof.2c_.atoi.2c_._atoi64.2c_.atol.asp
Re: bug in atof
> "Louis" == Louis Lenders <[EMAIL PROTECTED]> writes:
Louis> Hi, i filed a bug ( bug 4337) and looks like there's a bug in
Louis> atof. Is there a difference between linux' atof and msvcrt's one?
Louis> Even following simple program (from msdn) yields wrong results:
Louis> // crt_atof.c #include #include
Louis> int main( void ) { char *s; double x; int i; long l;
Louis>s = " -2309.12E-15"; /* Test of atof */ x = atof( s ); printf(
Louis> "atof test: \"%s\"; float: %e\n", s, x );
Louis>s = "7.8912654773d210"; /* Test of atof */ x = atof( s );
Louis> printf( "atof test: \"%s\"; float: %e\n", s, x );
Louis>s = " -9885 pigs"; /* Test of atoi */ i = atoi( s ); printf(
Louis> "atoi test: \"%s\"; integer: %d\n", s, i );
Louis>s = "98854 dollars"; /* Test of atol */ l = atol( s ); printf(
Louis> "atol test: \"%s\"; long: %ld\n", s, l ); } the exponent value in
Louis> float x are wrong. Thanks
Not atof() is the cause of your bug, but printf().
I entered your sample into the test suite to show the correct behaviour of
wine's implementation of atof. The printf() test has already a todo for the
incorrect exponent output.
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: Valgrind and wine (was: re: Bug 4289: Debugging and dissasembly)
I compiled valgrind 3.1.0 with the above patch applied. I ran Icewind Dale II with valgrind '--trace-children=yes wine IWD2.exe'. It goes on for a short while outputting various errors until it freezes. It locks and I have to reboot the machine. I've tried to output it to a log as well, but the file is empty once I've rebooted, (perhaps the stream doesn't get flushed or whatever). regarding IWD2: It may well be that this exhausts your memory, which in most cases brings the machine down to its knee regarding the simple wine run: - the ld related errors are strange. I'm using ld-2.3.4 which doesn't show them. Likely a bug in ld-2.3.5 :-/ - the last errors are expected from vg 3.10 (I have the fixes if someone is interested, both for VG and some enhancements to wine) and BTW, don't expect yet SEH in wine to work with vg A+ -- Eric Pouech
Re: Valgrind and wine (was: re: Bug 4289: Debugging and dissasembly)
On 1/14/06, James Trotter <[EMAIL PROTECTED]> wrote: On 1/14/06, Robert Shearman < [EMAIL PROTECTED] > wrote: Dan Kegel wrote:>Rob wrote:This very much looks like a use-after-free bug. The first two>>instructions are probably a COM *_Release call. Judging by the fact that>>this is a regression I would also guess that it is a Wine object. >>This sounds like a job for valgrind!>>But, er, does valgrind still work with wine? Rob said it did in March:> http://www.winehq.com/hypermail/wine-devel/2005/03/0397.html>It was too hard for one guy back in July:> http://www.winehq.com/hypermail/wine-devel/2005/07/0401.html >but that was probably because he didn't see Rob's message from March.>Maybe we need to put better instructions on how to use>Valgrind with Wine on winehq.org... or, dare I suggest it,>bundle valgrind with Wine so anybody could easily use it >be setting WINEDEBUG=+valgrind or something like that...>Valgrind 3.1.0 works with Wine with no Wine modifications needed.However, one patch to valgrind is required to generate meaningfulbacktraces and I've attached it to this message - I guess I should report this to the valgrind developers.--Rob Shearman I was really just considering using valgrind! I already have it installed, but I wasn't sure it would work very nicely, though. I was afraid there would be too much pointless output to wade through, but I'll try it tomorrow sometime. Cheers, James Well, it took a little longer than I thought it might. I compiled valgrind 3.1.0 with the above patch applied. I ran Icewind Dale II with valgrind '--trace-children=yes wine IWD2.exe'. It goes on for a short while outputting various errors until it freezes. It locks and I have to reboot the machine. I've tried to output it to a log as well, but the file is empty once I've rebooted, (perhaps the stream doesn't get flushed or whatever). This didn't prove particularly useful... Any suggestions? In case anyone is interested running 'valgrind --trace-children=yes wine' produces the following output: ==7379== Memcheck, a memory error detector. ==7379== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==7379== Using LibVEX rev 1471, a library for dynamic binary translation. ==7379== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==7379== Using valgrind-3.1.0, a dynamic binary instrumentation framework. ==7379== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==7379== For more details, rerun with: -v ==7379== ==7379== My PID = 7379, parent PID = 7342. Prog and args are: ==7379== /home/james/development/wine/regression_testing/cvs/wine/loader/wine-preloader ==7379== /home/james/development/wine/regression_testing/cvs/wine/loader/wine-pthread ==7379== ==7379== Warning: set address range perms: large range 535756800, a 0, v 0 ==7379== Warning: set address range perms: large range 1031864320, a 0, v 0 ==7379== Warning: set address range perms: large range 1031864320, a 1, v 1 ==7379== Warning: set address range perms: large range 515899392, a 0, v 0 ==7379== Warning: set address range perms: large range 515964928, a 0, v 0 ==7379== Warning: set address range perms: large range 515964928, a 1, v 1 ==7379== Warning: set address range perms: large range 257949696, a 0, v 0 ==7379== Warning: set address range perms: large range 258015232, a 0, v 0 ==7379== Warning: set address range perms: large range 258015232, a 1, v 1 ==7379== Warning: set address range perms: large range 128974848, a 0, v 0 ==7379== Warning: set address range perms: large range 128974848, a 1, v 1 ==7379== Warning: set address range perms: large range 129040384, a 0, v 0 ==7379== Warning: set address range perms: large range 549322752, a 0, v 0 ==7379== Warning: set address range perms: large range 549322752, a 1, v 1 ==7379== Warning: set address range perms: large range 274661376, a 0, v 0 ==7379== Warning: set address range perms: large range 274661376, a 1, v 1 ==7379== Warning: set address range perms: large range 137297920, a 0, v 0 ==7379== Warning: set address range perms: large range 137297920, a 1, v 1 ==7379== Invalid read of size 4 ==7379== at 0x20010CA8: (within /lib/ld-2.3.5.so) ==7379== by 0x2000624D: (within /lib/ld-2.3.5.so) ==7379== by 0x20152A75: (within /lib/tls/i686/cmov/libc-2.3.5.so) ==7379== by 0x2000B105: (within /lib/ld-2.3.5.so) ==7379== by 0x20153737: _dl_open (in /lib/tls/i686/cmov/libc-2.3.5.so) ==7379== by 0x20185CE7: (within /lib/tls/i686/cmov/libdl-2.3.5.so) ==7379== by 0x2000B105: (within /lib/ld-2.3.5.so) ==7379== by 0x201862EA: (within /lib/tls/i686/cmov/libdl-2.3.5.so) ==7379== by 0x20185D40: dlopen (in /lib/tls/i686/cmov/libdl-2.3.5.so) ==7379== by 0x200229F9: wine_dlopen (loader.c:588) ==7379== by 0x20022CEF: wine_init (loader.c:550) ==7379== by 0x7BF0103F: main (main.c:45) ==7379== Address 0x2018935C is 76 bytes inside a block of size 79 alloc'd ==7379== at 0x2001B45A: malloc (vg_replace_malloc.c:149) ==7379==
bug in atof
Hi, i filed a bug ( bug 4337) and looks like there's a
bug in atof. Is there a difference between linux' atof
and msvcrt's one? Even following simple program (from
msdn) yields wrong results:
// crt_atof.c
#include
#include
int main( void )
{
char *s; double x; int i; long l;
s = " -2309.12E-15";/* Test of atof */
x = atof( s );
printf( "atof test: \"%s\"; float: %e\n", s, x );
s = "7.8912654773d210"; /* Test of atof */
x = atof( s );
printf( "atof test: \"%s\"; float: %e\n", s, x );
s = " -9885 pigs"; /* Test of atoi */
i = atoi( s );
printf( "atoi test: \"%s\"; integer: %d\n", s, i );
s = "98854 dollars"; /* Test of atol */
l = atol( s );
printf( "atol test: \"%s\"; long: %ld\n", s, l );
}
the exponent value in float x are wrong. Thanks
___
To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre. http://uk.security.yahoo.com
Re: winedbg symbols completely screwed
Christer Palm wrote: Eric Pouech wrote: Christer Palm wrote: Continuing my debugging efforts, I decided to look some more at the strange symbols I got in the backtrace. Indeed, it seems like winedbg completely screws up the MFC42 symbols. For example, by disassembling from the load address of MFC42 I was able to identify the CString::FreeData() function at 0x5f402125, but winedbg tells me it's 0x5f445900. Is this a known problem? yes, when you have several versions of MFC42.PDB like you seem to do (we don't lookup up for the right one yet) A+ The thing is that I can't see that this is the case here. I have: [EMAIL PROTECTED] ~]$ find ~/.wine/drive_c/ -name "MFC*" -o -name "mfc*" from one of your previous posts: wine: Unhandled page fault on read access to 0x003c at address 0x5f4056dd (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x003c in 32-bit code (0x5f4056dd). In 32 bit mode. fixme:dbghelp:sffip_cb NIY on 'E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb' fixme:dbghelp:sffip_cb NIY on 'C:\hager\Semiolog\Apps\MFC42.PDB' fixme:dbghelp_msc:codeview_parse_type_table Not adding parameters' types to function signature fixme:dbghelp_msc:codeview_parse_type_table Unsupported type-id leaf a fixme:dbghelp_msc:dump : 06 00 0a 00 01 00 50 f1 ..P. fixme:dbghelp_msc:codeview_get_type Returning NULL symt for type-id 1053 also, we don't check (yet) CRC when loading PDB, which may also be the issue. A+ -- Eric Pouech
