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

Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
by Filip Navara 15 Jan '06

15 Jan '06

1 0

Re: winetest: Only test d3d9 if it is being built.
by H. Verbeet 15 Jan '06

15 Jan '06

On 23/12/05, Yuval Fledel <yuvalfl(a)gmail.com> wrote: > winetest: Only test d3d9 if it is being built. > > -- Yuval Fledel > > diff --git a/programs/winetest/Makefile.in b/programs/winetest/Makefile.in > index 4208b94..8602f66 100644 > --- a/programs/winetest/Makefile.in > +++ b/programs/winetest/Makefile.in > @@ -19,14 +19,15 @@ RC_BINSRC = winetest.rc > RC_BINARIES = wine.ico > > XFILES = ddraw_test.exe$(DLLEXT) > +OPENGLFILES = d3d9_test.exe$(DLLEXT) > > TESTBINS = \ > @XFILES@ \ > + @OPENGLFILES@ \ > advpack_test.exe$(DLLEXT) \ > advapi32_test.exe$(DLLEXT) \ > comctl32_test.exe$(DLLEXT) \ > crypt32_test.exe$(DLLEXT) \ > - d3d9_test.exe$(DLLEXT) \ > dinput_test.exe$(DLLEXT) \ > dsound_test.exe$(DLLEXT) \ > gdi32_test.exe$(DLLEXT) \ Would this prevent the tests from getting built on Windows?

1 0

re: Regression in ntdll/virtual.c
by Dan Kegel 14 Jan '06

14 Jan '06

>I mentioned that the setup program of AstroWorld will not work any longer >since a few days. Regression testing resulted in the change of >ntdll/virtual.c between 3.1.06 and 4.1.06. I didn't find any related entry >in wine.patches... Ah, but did you look in the archives of the wine-cvs mailing list? A little google search for the longest line of that change turned up: http://www.winehq.org/pipermail/wine-cvs/2006-January/020072.html - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

IWineD3DSurface::GetDC
by Stefan Dösinger 14 Jan '06

14 Jan '06

Hello, I am trying to implement the GetDC method for wine d3d surfaces, as it is used by much d3d7 apps to load the textures. I took the code from ddraw/surface_dib.c and modified it, but I am stuck with a heap corruption. Basically, what I am doing is: 1) Lock the surface 2) Create a DIB section with DIB_CreateDIBSection. Use the currentDesc. {Width / Height} as the dimension and bytesPerPixel * 8 for the bitcount. The memory for the DC is the pBits returned from LockRect() 3) Create a DC, and attach it to the dib section 4) Set the palette, if necessary. In ReleaseDC I release the DC, destroy the DIB section and unlock the surface. Looks nice so far, but it doesn't work. I get a heap corruption eighter when using the DC or when deleting it. An example winedbg output: err:d3d_surface:IWineD3DSurfaceImpl_GetDC (0x7fd8fb08)->(0x7fbafd94): This does not work yet trace:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x7fd8fb08) : rect@(nil) flags(00000000), output lockedRect(a)0x7fbaf4a8, memory@(nil) trace:d3d_surface:IWineD3DSurfaceImpl_LockRect Locked Rect (0x7fd8fb78) = l 0, t 0, r 640, b 480 trace:d3d_surface:IWineD3DSurfaceImpl_LockRect Locking non-power 2 texture trace:d3d_surface:IWineD3DSurfaceImpl_LockRect locking an ordinarary surface trace:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x7fd8fb08) Locking rect trace:d3d_surface:IWineD3DSurfaceImpl_AddDirtyRect (0x7fd8fb08) : Dirty?1, Rect:(0,0,640,480) trace:d3d_surface:IWineD3DSurfaceImpl_GetContainer (0x7fd8fb08) : Relaying to queryInterface 0x7fbaf3fc (nil) trace:d3d_surface:IWineD3DSurfaceImpl_GetContainer (0x7fd8fb08) : Relaying to queryInterface 0x7fbaf454 0xb7effbda trace:d3d_surface:IWineD3DSurfaceImpl_LockRect Surface is standalone, no need to dirty the container trace:d3d_surface:IWineD3DSurfaceImpl_LockRect returning memory(a)0x7dfa0020, pitch(4096) dirtyfied(1) trace:d3d_surface:IWineD3DSurfaceImpl_GetDC Creating dip section 640x480x32. memory at 0x7dfa0020 is 2097152 bytes of size trace:d3d_surface:IWineD3DSurfaceImpl_GetDC returning 0x278 trace:d3d_surface:IWineD3DSurfaceImpl_ReleaseDC (0x7fd8fb08)->(0x278) trace:d3d_surface:IWineD3DSurfaceImpl_ReleaseDC Selecting the object DC First chance exception: page fault on read access to 0x7dfa0000 in 32-bit code (0x7ff99374). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7ff99374 ESP:7fbaf714 EBP:7fbaf718 EFLAGS:00010206( - 00 - RIP1) EAX:7fce0000 EBX:7ffd5540 ECX:7e5c0250 EDX:7dfa0000 ESI:7e5c0248 EDI:7fce0040 Stack dump: 0x7fbaf714: 00000030 7fbaf754 7ff99c0b 7fce0000 0x7fbaf724: 7e5c0248 7f712cd0 00000000 00004f4c 0x7fbaf734: 7ff99294 7fd8fee8 7e5c0248 7ff8dffa 0x7fbaf744: 7f6edf2b 7ffd5540 00000030 00000030 0x7fbaf754: 7fbaf798 7ff9a954 7fce0000 00000030 0x7fbaf764: 7fbaf788 7f70253b 0000027c 00004f4c Backtrace: =>1 0x7ff99374 HEAP_FindSubHeap+0x14(heap=0x7fce0000, ptr=0x7e5c0248) [heap.c:375] in ntdll (0x7ff99374) 2 0x7ff99c0b HEAP_FindFreeBlock+0x7b(heap=0x7fce0000, size=0x30, ppSubHeap=0x7fbaf788) [/usr/src/wine-wined3d/dlls/ntdll/heap.c:390] in ntdll (0x7ff99c0b) 3 0x7ff9a954 RtlAllocateHeap(heap=0x7fce0000, flags=0x2, size=0x30) [/usr/src/wine-wined3d/dlls/ntdll/heap.c:1163] in ntdll (0x7ff9a954) q 4 0x7f263905 X11DRV_GetRegionData+0x55(hrgn=0x27c, hdc_lptodp=0x0) [/usr/src/wine-wined3d/dlls/x11drv/../../include/winbase.h:2250] in winex11 (0x7f263905) 5 0x7f263aa6 X11DRV_SetDeviceClipping+0x56(physDev=0x7fd8fe68, vis_rgn=0x280, clip_rgn=0x0) [/usr/src/wine-wined3d/dlls/x11drv/clipping.c:118] in winex11 (0x7f263aa6) 6 0x7f6c6a1e CLIPPING_UpdateGCRegion+0xae(dc=0x7e1a0028) [clipping.c:80] in gdi32 (0x7f6c6a1e) 7 0x7f6c84fa DC_InitDC+0x9a(dc=0x7e1a0028) [/usr/src/wine-wined3d/dlls/gdi/dc.c:205] in gdi32 (0x7f6c84fa) 8 0x7f6c5c06 BITMAP_SelectObject(handle=0x6c, obj=0x7fce5d20, hdc=0x278) [/usr/src/wine-wined3d/dlls/gdi/bitmap.c:568] in gdi32 (0x7f6c5c06) 9 0x7f6eea05 SelectObject(hdc=0x278, hObj=0x6c) [/usr/src/wine-wined3d/dlls/gdi/gdiobj.c:1164] in gdi32 (0x7f6eea05) 10 0x7f5ecd10 IWineD3DSurfaceImpl_ReleaseDC+0x50(iface=0x7fd8fb08, hDC=0x278) [/usr/src/wine-wined3d/dlls/wined3d/surface.c:1068] in wined3d (0x7f5ecd10) q 11 0x7fa7e0e8 IDirectDrawSurfaceImpl_ReleaseDC+0x38(iface=0x7fd8fa48, hdc=0x278) [/usr/src/wine-wined3d/dlls/ddraw/surface.c:472] in ddraw (0x7fa7e0e8) 12 0x7fbd5fe6 main in ddrawex (0x7fbd5fe6) 13 0x7fbd63a7 __wine_spec_exe_entry(peb=0x7ffdf540) [exe_entry.c:37] in ddrawex (0x7fbd63a7) 14 0x7fc490a0 start_process(arg=0x0) [/usr/src/wine-wined3d/dlls/kernel/process.c:1027] in kernel32 (0x7fc490a0) 15 0xb7f020fb wine_switch_to_stack+0x17 in libwine.so.1 (0xb7f020fb) 0x7ff99374 HEAP_FindSubHeap+0x14 [heap.c:375] in ntdll: movl 0x0(%edx),%ecx Unable to open file 'heap.c' Wine-dbg> I am lost here, can someone help me? Can this code work at all? I've attached my copy of dlls/wined3d/surface.c, so you can see the code(Watch out, it won't compile as such in the CVS tree). The dib member of WineD3DSurface is taken from ddraw: typedef struct wineD3DSurface_DIB { HBITMAP DIBsection; void* bitmap_data; HGDIOBJ holdbitmap; BOOL client_memory; DWORD d3d_data[4]; /* room for Direct3D driver data */ } wineD3DSurface_DIB; Stefan

1 0

Re: x11drv: Allow WM to manage more windows.
by Dmitry Timoshkov 14 Jan '06

14 Jan '06

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote: > @@ -67,6 +67,8 @@ static const char visual_id_prop[] = > inline static BOOL is_window_managed( HWND hwnd ) > { > DWORD style, ex_style; > + char class_name[7]; > + static const char menu_class[] = "#32768"; > + /* menu windows are not managed */ > + if (GetClassNameA(hwnd, class_name, sizeof(class_name)) && > + !memcmp(class_name, menu_class, sizeof(menu_class))) > + return FALSE; This won't work for subclassed or custom (OfficeXP like) menus. -- Dmitry.

2 1

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX
by Aric Cyr 14 Jan '06

14 Jan '06

Hi all, Just wanted to chime in with a status update on my porting of wined3d to WGL. Basically, I am in the debug phase, and at this point most bugs have been ironed out. That is, for dx9 stuff. I soon ran into problems/regressions with dx8 or lower (including ddraw!). So I ended up repeating the (almost) exactly same work for d3d8 and ddraw... not a pretty sight, and a pain to debug them all. As a result this conversion has become a fairly large and invasive change affecting all versions of directx... [I can't wait for all these to be completely ported to wined3d]. For testing d3d8 I've been using 3DMark2001SE and some DirectX tutorial/demo apps. For d3d9 I use World of Warcraft (hehe) and more tutorial/demo apps. I forget what I used for d3d7 though... I'll have to double check that. Most of the problems I've come across were GLXContext related... namely due to a problem in wine's wgl which causes an app to think there is a current context, when infact there isn't. (See wglGetCurrentContext in wgl.c, and see what happens when there is no glX context, especially between calls to wglCreateContext and wglMakeCurrent). Another change I made which I'm not sure about and would like feedback for, is to change wgl's process_attach to use wgl functions instead of glX functions. The reason for this is so that the GLXContext that is created will be properly added to the context list so it can be used for other purposes. This should reduce the number of GL contexts by one for all d3d and (behaved) opengl apps. I'm currently in the process of cleaning everything up and then I will post a patch on my site for people to download. Due to the scope of the changes, I really hope that people can help me test this sucker... once that's done I'll chop up the patch into logical pieces and submit them. That's all for now! - Aric P.S. If anyone wants, they can edit http://winehq.org/site/fun_projects and put me down for the "wined3d use wgl" project.

6 10

Valgrind and wine (was: re: Bug 4289: Debugging and dissasembly)
by Dan Kegel 14 Jan '06

14 Jan '06

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... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Fwd: Bug 4289: Debugging and dissasembly
by James Trotter 14 Jan '06

14 Jan '06

---------- Forwarded message ---------- From: James Trotter <james.trotter(a)gmail.com> Date: Jan 14, 2006 3:22 PM Subject: Re: Bug 4289: Debugging and dissasembly To: Eric Pouech <eric.pouech(a)wanadoo.fr> On 1/14/06, Eric Pouech <eric.pouech(a)wanadoo.fr> wrote: > > James Trotter wrote: > > Hi! > > > > A few days ago I filed this bug: > http://bugs.winehq.org/show_bug.cgi?id=4289 > > > > Alexandre commented that there most likely was some stack corruption, > > and that I should try and disassemble a few instructions before the > > crash and look for API calls. > > > > Now, I haven't used gdb or winedbg that much before, and I'm a bit > > uncertain what to do. I understand that using the disassemble > > [<addr>][,<addr>] command, the debugger will disassemble that address > > space. Given the stack trace as in the bug report, which addresses, > > exactly, should I disassemble? > before 0x007ab8f1 > A+ > > > -- > Eric Pouech > > Sure, but how much before 0x007ab8f1? For instance, Is this helpful? WineDbg starting on pid 0xa In 32 bit mode. 0x7fcfba16 start_process+0xb6 [/home/james/development/wine/regression_testing/2005-07-18/wine/dlls/kernel/process.c:996] in kernel32: pushl %edi 996 ExitProcess( entry( peb ) ); Wine-dbg>cont First chance exception: page fault on read access to 0x20202020 in 32-bit code (0x007ab8f1). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:007ab8f1 ESP:7facaba4 EBP:00000000 EFLAGS:00210246( - 00 -RIZP1) EAX:20202020 EBX:00000001 ECX:7facb450 EDX:00000000 ESI:7facb328 EDI:7beb4460 Stack dump: 0x7facaba4: 20202020 00002711 00000000 7facb328 0x7facabb4: 7facabe0 007aaf30 7facb218 7facaf60 0x7facabc4: 00000000 00002711 40c38800 7facb328 0x7facabd4: 7facac90 0084566a 00000007 7fd0e900 0x7facabe4: 0078e3ca 00000000 7facaf60 00400000 0x7facabf4: 7fd39206 7facaf60 00000000 7fd39206 0200: sel=1007 base=b7f81000 limit=00001f97 32-bit rw- Backtrace: =>1 0x007ab8f1 in iwd2 (+0x3ab8f1) (0x00000000) 0x007ab8f1: movl 0x0(%eax),%ecx Wine-dbg>disassemble 0x007ab800, 0x007ab8f1 0x007ab800: addb %bh,0x0(%ebx) 0x007ab802: int $0x74 0x007ab804: pop %ss 0x007ab805: cmpl %ebx,0x390(%ecx) 0x007ab80b: jz 0x007ab81c 0x007ab80d: addl $0x394,%ecx 0x007ab813: pushl %ecx 0x007ab814: call *%edi 0x007ab816: movl 0x008cf6d8,%ecx 0x007ab81c: movl 0x13c(%esi),%eax 0x007ab822: cmpl %ebp,%eax 0x007ab824: jz 0x007ab838 0x007ab826: movl 0x0(%eax),%ecx 0x007ab828: pushl %eax 0x007ab829: call *0x8(%ecx) 0x007ab82c: movl %ebp,0x13c(%esi) 0x007ab832: movl 0x008cf6d8,%ecx 0x007ab838: cmpl %ebp,%ecx 0x007ab83a: jz 0x007ab84d 0x007ab83c: cmpl %ebx,0x390(%ecx) 0x007ab842: jz 0x007ab84d 0x007ab844: addl $0x394,%ecx 0x007ab84a: pushl %ecx 0x007ab84b: call *%edi 0x007ab84d: leal 0x128(%esi),%ecx 0x007ab853: call 0x007c22d0 0x007ab858: movl %ebp,0x140(%esi) 0x007ab85e: movl 0x008cf6d8,%eax 0x007ab863: cmpl %ebp,%eax 0x007ab865: jz 0x007ab87b 0x007ab867: cmpl %ebx,0x390(%eax) 0x007ab86d: jz 0x007ab87b 0x007ab86f: addl $916,%eax 0x007ab874: pushl %eax 0x007ab875: call *0x8472c8 -> 0x7beb4180 RtlLeaveCriticalSection [/home/james/development/wine/regression_testing/2005-07-18/wine/dlls/ntdll/critsection.c:407] in ntdll 0x007ab87b: cmpl %ebp,0x90(%esi) 0x007ab881: jz 0x007ab8a4 0x007ab883: leal 0x84(%esi),%edi 0x007ab889: movl %edi,%ecx 0x007ab88b: call 0x007fbe77 0x007ab890: cmpl %ebp,%eax 0x007ab892: jz 0x007ab89c 0x007ab894: movl 0x0(%eax),%edx 0x007ab896: pushl %ebx 0x007ab897: movl %eax,%ecx 0x007ab899: call *0x4(%edx) 0x007ab89c: cmpl %ebp,0x90(%esi) 0x007ab8a2: jnz 0x007ab889 0x007ab8a4: cmpl %ebp,0xac(%esi) 0x007ab8aa: jz 0x007ab8d8 0x007ab8ac: leal 0xa0(%esi),%ebx 0x007ab8b2: movl %ebx,%ecx 0x007ab8b4: call 0x007fbe77 0x007ab8b9: movl %eax,%edi 0x007ab8bb: movl 0x58(%edi),%eax 0x007ab8be: cmpl %ebp,%eax 0x007ab8c0: jz 0x007ab8cb 0x007ab8c2: movl 0x0(%eax),%ecx 0x007ab8c4: pushl %eax 0x007ab8c5: call *0x8(%ecx) 0x007ab8c8: movl %ebp,0x58(%edi) 0x007ab8cb: cmpl %ebp,0xac(%esi) 0x007ab8d1: jnz 0x007ab8b2 0x007ab8d3: movl $0x1,%ebx 0x007ab8d8: cmpl %ebp,0x4(%esi) 0x007ab8db: jz 0x007ab8f9 0x007ab8dd: movl 0x8(%esi),%eax 0x007ab8e0: cmpl %ebp,%eax 0x007ab8e2: jz 0x007ab8ed 0x007ab8e4: movl 0x0(%eax),%edx 0x007ab8e6: pushl %eax 0x007ab8e7: call *0x8(%edx) 0x007ab8ea: movl %ebp,0x8(%esi) 0x007ab8ed: movl 0x4(%esi),%eax 0x007ab8f0: pushl %eax 0x007ab8f1: movl 0x0(%eax),%ecx Wine-dbg> Thanks, James

2 3

Re: RFC: implementation of driver functionality in msacm (RESEND)
by Alex Villacís Lasso 14 Jan '06

14 Jan '06

Eric Pouech wrote: > Alex Villacís Lasso wrote: > >> Eric Pouech wrote: >> >>>> * Implementation of broadcasts to notification windows on driver >>>> add/remove, enabling/disabling, and priority changes >>> >>> >>> >>> - MSDN seems to state that differed notification is actually a >>> counter, not a simple boolean (whereas enable/disable is a boolean) >> >> >> >> I have just read the MSDN web page, and I see no remark that suggests >> that deferred notification should behave as a counter instead of a >> simple on/off flag. Or maybe I am reading the page incorrectly... > > well... > ACM_DRIVERPRIORITYF_END Calling task wants to reenable change > notification broadcasts. An application must call acmDriverPriority > with ACM_DRIVERPRIORITYF_END for each successful call with the > ACM_DRIVERPRIORITYF_BEGIN flag. Note that hadid must be NULL, > dwPriority must be zero, and only the ACM_DRIVERPRIORITYF_END flag can > be set. > ... then I need new glasses :-) >> >>>> * Fix for implementation quirks of acmDriverMessage() in order to >>>> allow native codecs to display configuration dialogs >>> >>> >>> >>> this seems rather hackish. did you actually tested this on Windows ? >>> Moreover, the size bits look especially suspicious. Where did you >>> get the 16 value from ? >> >> >> >> I tested the native msacm32.dll from Windows 98 SE on Wine, and it >> reported a 16-byte struct size to the winemp3 codec. > > how do you know it's a 16 byte struct? there's nothing in the passed > information that tells you it's 16 bytes AFAICS Yes, there is: (begin MSDN quote) DRV_CONFIGURE Directs the installable driver to display its configuration dialog box and let the user specify new settings for the given installable driver instance. *Parameters* /dwDriverId/ Identifier of the installable driver. This is the same value previously returned by the driver from the *DRV_OPEN* <http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_drv_open.asp> message. /hdrvr/ Handle of the installable driver instance. /lParam1/ Handle of the parent window. This window is used as the parent window for the configuration dialog box. /lParam2/ Address of a *DRVCONFIGINFO* <http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_drvconfiginfo_s…> structure or NULL. If the structure is given, it contains the names of the registry key and value associated with the driver. DRVCONFIGINFO Contains the registry key and value names associated with the installable driver. |typedef struct tagDRVCONFIGINFO { DWORD dwDCISize; LPCWSTR lpszDCISectionName; LPCWSTR lpszDCIAliasName; } DRVCONFIGINFO; | *Members* *dwDCISize* Size of the structure, in bytes. *lpszDCISectionName* Address of a null-terminated, wide-character string specifying the name of the registry key associated with the driver. *lpszDCIAliasName* Address of a null-terminated, wide-character string specifying the name of the registry value associated with the driver. (end MSDN quote) I examined the DRVCONFIGINFO structure prepared by native msacm32.dll to codecs, in particular the dwDCISize field. Even when the sum of all fields in the structure declaration yields 12 bytes, dwDCISize holds a value of 16 when supplied by native msacm32.dll. So, I used the same value in order to mimic native as close as possible. Alex Villacís Lasso

2 1

Bug 4289: Debugging and dissasembly
by James Trotter 14 Jan '06

14 Jan '06

Hi! A few days ago I filed this bug: http://bugs.winehq.org/show_bug.cgi?id=4289 Alexandre commented that there most likely was some stack corruption, and that I should try and disassemble a few instructions before the crash and look for API calls. Now, I haven't used gdb or winedbg that much before, and I'm a bit uncertain what to do. I understand that using the disassemble [<addr>][,<addr>] command, the debugger will disassemble that address space. Given the stack trace as in the bug report, which addresses, exactly, should I disassemble? Thanks, James

1 0