May 2006 - Wine-devel - list.winehq.org

Re: gdi: Add WineGL driver interface and wrapper functions
by Tomas Carnecky 14 May '06

14 May '06

... and here the patch

1 0

Re: Quiet valgrind warnings in init_current_teb
by Mike Hearn 14 May '06

14 May '06

Hmm, are you sure this isn't a bug in Valgrind itself? The code it's warning on is this: inline static void wine_ldt_set_limit( LDT_ENTRY *ent, unsigned int limit ) { if ((ent->HighWord.Bits.Granularity = (limit >= 0x100000))) limit >>= 12; ent->LimitLow = (WORD)limit; ent->HighWord.Bits.LimitHi = (limit >> 16); } but unless I'm reading it wrong this is not testing ent before initialization at all, it's testing limit, assigning to ent, then testing the result of that assignment ... which seems to be valid. Of course, working around bugs in Valgrind may be a useful thing to do for now ... that code is seriously terrifying stuff. And I thought Wine was scary :) thanks -mike

4 4

possible MCI deadlock
by Damjan Jovanovic 14 May '06

14 May '06

I've been looking at bug 3930 (http://bugs.winehq.org/show_bug.cgi?id=3930) where Heroes of might and magic basically hangs on a black screen when sound is enabled (and works when sound is disabled). It happens on all wine versions, the winedbg session below is from wine 0.9.11 and was done during the black screen. Any ideas? What's exception c0000005? Wine-dbg>info process pid threads parent executable (all id:s are in hex) 0000000a 1 00000008 'c:\windows\system32\explorer.exe' 00000008 2 00000000 'C:\Program Files\3DO\Heroes of Might and Magic\HEROES.EXE' Wine-dbg>attach 8 0xffffe410: popl %ebp Wine-dbg>bt all Backtracing for thread 0xc in process 0x8 (C:\Program Files\3DO\Heroes of Might and Magic\HEROES.EXE): Backtrace: =>1 0xffffe410 (0xffffe410) 2 0x7eced300 wodPlayer+0xc0(pmt=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/winmm/winealsa/audio.c:2261] in winealsa (0x7eced300) 3 0x7fc75dc9 THREAD_Start+0x119(ptr=0x7fd4a3e0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/kernel/thread.c:76] in kernel32 (0x7fc75dc9) 4 0x7ffbba86 start_thread+0x236(info=0x7fd4a3f8) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/ntdll/thread.c:357] in ntdll (0x7ffbba86) 5 0xb7ec7380 (0xb7ec7380) 6 0xb7e60c6e __clone+0x5e in libc.so.6 (0xb7e60c6e) Process of pid=0x00000008 has terminated 0xffffe40e: jmp 0xffffe403 Backtracing for thread 0xb in process 0xa (c:\windows\system32\explorer.exe): Backtrace: =>1 0xffffe40e (0xffffe40e) 2 0x7ffb7d52 NTDLL_wait_for_multiple_objects+0x252(count=0x2, handles=0x7fbbf4b0, flags=0x4, timeout=0x0, signal_object=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/ntdll/sync.c:729] in ntdll (0x7ffb7d52) 3 0x7ffb7e57 NtWaitForMultipleObjects+0x67(count=0x2, handles=0x7fbbf4b0, wait_all=0x0, alertable=0x0, timeout=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/ntdll/sync.c:760] in ntdll (0x7ffb7e57) 4 0x7fc5d84e WaitForMultipleObjectsEx+0xae(count=0x2, handles=0x7fbbf600, wait_all=0x0, timeout=0xffffffff, alertable=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/kernel/sync.c:213] in kernel32 (0x7fc5d84e) 5 0x7f774eac X11DRV_MsgWaitForMultipleObjectsEx+0xfc(count=0x1, handles=0x7fbbf768, timeout=0xffffffff, mask=0x4ff, flags=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/x11drv/event.c:312] in winex11 (0x7f774eac) 6 0x7fa10dc1 GetMessageW+0x211(msg=0x7fbbf8f0, hwnd=0x0, first=0x0, last=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/user/message.c:2836] in user32 (0x7fa10dc1) 7 0x7fbd57f5 manage_desktop+0x255(arg=0x7fcf075d) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/programs/explorer/desktop.c:190] in explorer (0x7fbd57f5) 8 0x7fbd5e38 WinMain+0x268(hinstance=0x7fbd0000, previnstance=0x0, cmdline=0x7fcf0755, cmdshow=0x1) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/programs/explorer/explorer.c:139] in explorer (0x7fbd5e38) 9 0x7fbd71a7 main+0xd7(argc=0x2, argv=0x7fcf0450) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/winecrt0/exe_main.c:48] in explorer (0x7fbd71a7) 10 0x7fbd70b9 __wine_spec_exe_entry+0x99(peb=0x7ffdf2c0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/winecrt0/exe_entry.c:37] in explorer (0x7fbd70b9) 11 0x7fc4a0ae start_process+0xee(arg=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/kernel/process.c:845] in kernel32 (0x7fc4a0ae) 12 0xb7ef5587 wine_switch_to_stack+0x17 in libwine.so.1 (0xb7ef5587) Process of pid=0x0000000a has terminated 0xffffe410: popl %ebp Backtracing for thread 0x9 in process 0x8 (C:\Program Files\3DO\Heroes of Might and Magic\HEROES.EXE): Backtrace: Exception c0000005 Wine-dbg> __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: comctl32[1/8]: header: don't check lpItem for NULL in GetItemT
by Vitaliy Margolen 14 May '06

14 May '06

Saturday, May 13, 2006, 1:07:54 PM, Mikolaj Zalewski wrote: > These patches implements the callback header items and should fix e.g. > bug #4344 > Changelog: don't check lpItem for NULL in GetItemT - lpItem can't be NULL You will need to split this patch into two. Checking for NULL has nothing to do with callback. Also I'm not sure why are you removing NULL check? Any explanations, tests? Vitaliy Margolen

2 1

Google Earth installer
by Robert Lunnon 14 May '06

14 May '06

I have an issue with Google Earth Installer generating an exception early in the install. Looks like it has a problem dereferencing a pointer returned by LoadResource. Anyone looking into this at all ? 1 000c:Call window proc 405fa1 (hwnd=10024,msg=WM_INITDIALOG,wp=00000000,lp=7fd5fa98) 2 000c:Call user32.SetTimer(00010024,000003e9,0000012c,00000000) ret=004060e7 2 000c:Ret user32.SetTimer() retval=000003e9 ret=004060e7 2 000c:Call kernel32.GetLastError() ret=00401c6c 1 000c:Ret kernel32.GetLastError() retval=00000000 ret=00401c6c 2 000c:Call ntdll.RtlAllocateHeap(7ef50000,00000000,00000001) ret=0040ceb8 1 000c:Ret ntdll.RtlAllocateHeap() retval=7ef50148 ret=0040ceb8 2 000c:Call kernel32.SetLastError(00000000) ret=00401c98 1 000c:Ret kernel32.SetLastError() retval=00000000 ret=00401c98 2 000c:Call kernel32.FindResourceExA(00400000,00000006,00000901,00000009) ret=0040a03e 3 000c:Call ntdll.LdrFindResource_U(00400000,7ef3cc80,00000003,7ef3cc7c) ret=7fded3782 2 000c:Ret ntdll.LdrFindResource_U() retval=c0000204 ret=7fded378 3 000c:Call ntdll.RtlNtStatusToDosError(c0000204) ret=7fded38c 2 000c:Ret ntdll.RtlNtStatusToDosError() retval=00000717 ret=7fded38c 1 000c:Ret kernel32.FindResourceExA() retval=00000000 ret=0040a03e 2 000c:Call kernel32.FindResourceExA(00400000,00000006,00000901,00000409) ret=0040a055 3 000c:Call ntdll.LdrFindResource_U(00400000,7ef3cc80,00000003,7ef3cc7c) ret=7fded378 2 000c:Ret ntdll.LdrFindResource_U() retval=00000000 ret=7fded378 1 000c:Ret kernel32.FindResourceExA() retval=00416440 ret=0040a055 2 000c:Call kernel32.LoadResource(00400000,00416440) ret=0040a071 3 000c:Call ntdll.LdrAccessResource(00400000,00416440,7ef3ccec,00000000) ret=7fdee7a6 2 000c:Ret ntdll.LdrAccessResource() retval=00000000 ret=7fdee7a6 1 000c:Ret kernel32.LoadResource() retval=0041a8f4 ret=0040a071 Handling exception at EIP 40a0aa accessing 41a936 000c:Call ntdll.RtlEnterCriticalSection(7f36b2e0) ret=7f312065 000c:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=7f312065 000c:Call ntdll.RtlLeaveCriticalSection(7f36b2e0) ret=7f3120c3 000c:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7f3120c3 000c:Call ntdll.NtCurrentTeb() ret=7fdb17cd 000c:Ret ntdll.NtCurrentTeb() retval=7ef40000 ret=7fdb17cd 000c:Call ntdll.NtCreateEvent(7ef3c820,001f0003,7ef3c824,00000001,00000000) ret=7fdb168a 000c:Ret ntdll.NtCreateEvent() retval=00000000 ret=7fdb168a wine: Unhandled page fault on read access to 0x0041a936 at address 40a0aa (thread 000c), starting debugger...

1 0

Re: comctl32[2/8]: header: don't send HDN_GETDISPINFO during HDM_SET/INSERTITEM
by James Hawkins 13 May '06

13 May '06

On 5/13/06, Mikołaj Zalewski <mikolaj(a)zalewski.pl> wrote: > Changelog: don't send HDN_GETDISPINFO during HDM_SET/INSERTITEM - > Windows doesn't do it. > This is a good candidate for a test case. -- James Hawkins

1 0

Re: gdi: create driver interface for opengl implementation and add wrapper functions.
by Tomas Carnecky 13 May '06

13 May '06

Tomas Carnecky wrote: > This patch adds an WineGL interface to the GDI driver and creates > wrapper functions for them. If the wgl function takes a HDC, the wrapper > extract the PHYSDEV and prepends it to the driver-function argument > list. This way we have direct access to the PHYSDEV in x11drv and don't > need to use ExtEscape(). I've run into some problems with this. opengl32.dll exports only the basic wgl functions, if an application wants to use functions which are provided by various extensions, it has to use wglGetProcAddress(). I moved all extensions to x11drv and wglGetProcAddress() returns the pointer to those functions. The problem is that those functions are called directly by the application and not through the wrapper and thus don't have access to PHYSDEV like the basic wgl functions. We could make wrapper functions for each extension, but that would require changing the driver function table every time we add a new extension. I took another path and added a new GDI function 'wineGetDCPrivate(HDC)' that returns the PHYSDEV for the given DC. This way I can have all function prototypes the same for wgl?? in opengl32, WineGLWrapper_wgl?? in GDI and the WineGL_wgl?? implementation in x11drv. In the implementation in x11drv I get the PHYSDEV when required using the new GDI function and have direct access to it, no need to use ExtEscape(). In addition to the basic wgl?? functions the GDI driver has to expose two gl?? functions, glGetString() (for GL_EXTENSIONS to be able to report all supported WGL extensions) and glGetIntegerv() (because GL_DEPTH_BITS and GL_ALPHA_BITS don't have the same meaning on windows and X11). Also, once the x11drv side is stable, opengl32.spec can be changed like this: @ stdcall wglGetCurrentDC() gdi32.WineGLWrapper_wglGetCurrentDC And all but three functions can be deleted from wgl.c (and wgl_ext.c) can be removed completely). Those three functions are: o wglGetProcAddress(): first scan OpenGL functions, if not found fall back to WineGLWrapper_wglGetProcAddress() to let x11drv return the pointer to the wgl function. o glGetString: use glGetString and WineGLWrapper_glGetString() to build the extension string. o glGetIntegerv(): let x11drv return the proper values if the app is requesting GL_DEPTH_BITS or GL_ALPHA_BITS. tom

1 0

Re: [Wine] Wine + serial port basically hangs system
by Uwe Bonnes 13 May '06

13 May '06

Hallo, this is a thread from wine-users. I think further discussion of this issue is better done on wine-devel. In short, Dan Armbrust notices some application (heavy weather.exe) accessing the serial port causing a high system load. As the application uses WaitCommEvent, I fear that my implementation of WaitCommEvent is inappropriate. In my last posting, I ask Dan to count the calls to WaitcommEvent by counting the number of lines containing WaitCommEvent in a relay log. His results are: >>>>> "Dan" == Dan Armbrust <daniel.armbrust.list(a)gmail.com> writes: Dan> I let the app run for about 2 minutes, at the standard priority - Dan> basically until the system was about ready to take a dive :) Dan> Data was coming in to the program and being displayed before I Dan> killed it. Dan> The count on WaitCommEvent was 15051 - so I guess we would have Dan> 7526 calls to WaitCommEvent in < 2 minutes. It probably took the Dan> first 30 seconds just to get the app up and running, so that was Dan> maybe 90 seconds of actually accessing the serial port. As Dan's machine is not a "big iron one", I guess these about 7500 thread creation/termination in about 90 seconds could explain the high system load. In the moment, my implementation of WaitCommEvent creates a thread in the context of the running program for every call. Any ideas how to do it better? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 6

Re: rpcrt4: Fix some conditional includes
by Huw Davies 12 May '06

12 May '06

> -#ifdef HAVE_SYS_TYPES > #include <sys/types.h> > -#endif There is a HAVE_SYS_TYPES_H though. However since HAVE_SYS_TYPES isn't defined, couldn't you remove the #include too? Huw. -- Huw Davies huw(a)codeweavers.com

3 4

AW: thanks for wine
by Roland Kaeser 12 May '06

12 May '06

Hello I started CorelDraw with the given WINEDEBUG options but there is no chance to get success with this options. It took me more than 2 hours just to start Corel and generated about 1.5GB of log output. Even moving the mouse generated more than 5000 lines of debug output. So I removed the +relay option. And here is the generated debug output which is already a lot of text. (See the attachement). I hope this is enough information to find where there bug exactly comes. Many thanks for the efforts. Roland Kaeser >----- Ursprüngliche Mail ---- >Von: Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> >An: Roland Kaeser <roli8200(a)yahoo.de> >CC: wine-devel(a)winehq.org >Gesendet: Freitag, den 12. Mai 2006, 14:18:00 Uhr >Betreff: Re: thanks for wine >On Fri, May 12, 2006 at 06:20:13AM +0000, Roland Kaeser wrote: >> >The only major issues that I'm aware of are coping and pasting OLE embedded >> >objects. That should be taken care of when Rob is finished his COM work. >> >> >IMO 633, 2382 and 5061 are not really copy and paste bugs. They are caused >> >by problems translating from windows data formats to linux data formats and >> >vice versa. >> >> As far as I know, all "complex" objects in the windows clipboard, such as formatted text, images etc. is stored as rtf-object. >> BTW: There is also a bug #3611 which was marked as dublicate of #633 but its not the exact reason. >> >> I recognized that the copy and paste bug #3611 works on some systems. I may have to do with some X11 library/KDE Lib versions. etc. Is there a kind of WINEDEBUG option to track what happens when copy/paste in application? >> On the other side I saw a lot of applications by which the copy/paste does not work. It seems to be a much bigger issue than assumed. >> >I agree, they are different bugs. I don't have Corel Draw 9 so if you can >send me a +relay,+clipboard,+tid trace I can take a look. >/Ulrich

1 0