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

Re: Static control [10/10]: Support the Windows XP mode of the static control
by Filip Navara Jan. 15, 2006

Jan. 15, 2006

Michael Kaufmann wrote: > Changelog: > - Detect if the image of the current process has a manifest. If yes, > enable some Windows XP-specific features (as described in MSDN) > - Destruction of the control window: Destroy bitmaps loaded at control > creation time (removed a resource leak) > - Always stretch bitmaps and icons to the whole client area > - Windows XP mode: Different bitmap background, different icon > background. > - Add some notes This doesn't seem right. User32 shouldn't be checking manifests, I would expect the STATIC control to be subclassed in COMCTL32 and the WinXP functionality implemented there. - Filip

2 2

winehq on osx-intel?
by Bob Hunter Jan. 15, 2006

Jan. 15, 2006

Hello, There are winehq binaries for unix except osx unix, being apple mac os. As Apple shifted to intel cpu, winehq has one more platform to go. The old VirtualPC by connectix was purchased by microsoft, and there are no news about its conversion to the new platform. Further, no one really wants to run an emulation of the windows desktop. Are there any plans to extend winehq to osx, possibly for a fee? I would be happy to pay for a copy. Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Problem with older wgl patch
by Tim Savannah Jan. 15, 2006

Jan. 15, 2006

On the newest wine, trying to start opengl programs such as World of Warcraft yields an error such as this: trace:opengl:wine_glCullFace (1029) trace:opengl:wine_glMatrixMode (5889) trace:opengl:wine_glLoadMatrixf (0x7fbafbb8) trace:opengl:wglMakeCurrent (0x368,0x7fd7b7d0) trace:opengl:create_glxpixmap return 1800054 trace:opengl:wglMakeCurrent make current for dis 0x7c01baf8, drawable 0x1800054, ctx 0x7c1c01d8 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 13 (X_GLXCreateGLXPixmap) Serial number of failed request: 412 Current serial number in output stream: 413 I don't know enough about wgl to offer any suggestions to the problem, other than the source seems to be this patch: http://cvs.winehq.org/cvsweb/wine/dlls/opengl32/wgl.c.diff?r1=1.71&r2=1.72&… Reverting that patch and adding + DWORD type = GetObjectType(hdc); where that patch placed it in the file allows opengl to work again.

4 3

Re: user: Implement scrolling in popup menus
by Phil Krylov Jan. 15, 2006

Jan. 15, 2006

Hi, Anything wrong with that patch? (Yes I know that separate arrow bitmaps should be used instead of the scrollbar ones. But I can't draw ;) On Sat, 7 Jan 2006 16:54:15 +0300 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > ChangeLog: > > Added scrolling support to popup menus which don't fit on the desktop. -- Ph.

1 0

Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
by Dan Kegel Jan. 15, 2006

Jan. 15, 2006

The Mozilla ActiveX control download feature is cool and all, but until we repackage the sucker to include MSVCP60.DLL to fix http://bugs.winehq.org/show_bug.cgi?id=4064 it's going to leave a lot of users scratching their heads as to why it keeps asking where its files are. I could have sworn I saw somebody post a note saying they had done said repackaging, but I can't find it now... Can somebody take care of this? It's kind of important. I would, but I'm zooming around getting my CS 130 project going, preparing a couple talks for Scale 4x, chasing after my two year old, and trying to hold down my day job... For the curious, my slids for the cs130 kickoff talk are up at http://kegel.com/wine/sweng/cs130/ I chose "add a feature to riched20.dll " as the basic task the students will be trying to carry out. No idea yet how it'll work out. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 5

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

Jan. 15, 2006

1 0

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

Jan. 15, 2006

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 Jan. 14, 2006

Jan. 14, 2006

>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 Jan. 14, 2006

Jan. 14, 2006

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 Jan. 14, 2006

Jan. 14, 2006

"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 Jan. 14, 2006

Jan. 14, 2006

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 Jan. 14, 2006

Jan. 14, 2006

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 Jan. 14, 2006

Jan. 14, 2006

---------- 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 Jan. 14, 2006

Jan. 14, 2006

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 Jan. 14, 2006

Jan. 14, 2006

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

RFC: pch support
by Steven Edwards Jan. 13, 2006

Jan. 13, 2006

Hi, Alexandre did not like the needed changes required to add support for this but I figured I would throw it out for debate anyway in case anyone else can make him change his mind (duck). The issue is he does not like needing a single header per-program or per dll. After doing some research it seems to me that even MSVC does not support multiple PCH files per project so I don't know how it could be fixed in gcc to do it Microsoft has not figured it out. problem: ccache works great for speeding up compiles but seems to still have issue with some header changes. Also the ReactOS guys really want to add pch support to the Wine dlls that are shared so the job falls to me to sell it to Wine. Solution: Below are the benchmarks from my box and a patch. Simply patch your tree and then ./configure and cd to the regedit folder and do a 'time make','make clean','make pch', and 'time make' if you want to see the speedup on your box. I expect we could get a 2x speedup in fresh compiles of Wine with pch support Regedit compile without pch real 0m5.632s user 0m5.000s sys 0m0.524s Regedit compile with pch real 0m2.797s user 0m2.352s sys 0m0.428s -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

8 12

FAQ outdated in one point
by CS Jan. 13, 2006

Jan. 13, 2006

In the FAQ you write under "2.12. When will Wine be finished?": "Right now we are working on releasing Wine 0.9 our schedule has this release around September 30th 2005." maybe that should be updated or removed altogether so there don't need to be updates to this entry in the future. sorry that I can't do more to contribute :-) clem

2 1

re: richedit's RTF writer writes only 8 kBi
by Dan Kegel Jan. 13, 2006

Jan. 13, 2006

In June '05, Tobias Burnus complained in http://www.winehq.com/hypermail/wine-devel/2005/06/0536.html that there seemed to be an 8kB size limit on rich text output from richedit... but nobody replied to his message. Tobias, did you ever resolve that problem? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Regression in ntdll/virtual.c
by Markus G�mmel Jan. 13, 2006

Jan. 13, 2006

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, so here is the diff result: 37a38 > #include <sys/stat.h> 837a839 > struct stat st; 859a862,866 > if (fstat( fd, &st ) == -1) > { > status = FILE_GetNtStatus(); > goto error; > } 860a868 > if (header_size > st.st_size) goto error; 999c1007,1009 < if (map_file_into_view( view, fd, sec->VirtualAddress, file_size, sec->PointerToRawData, --- > end = sec->PointerToRawData + file_size; > if (sec->PointerToRawData >= st.st_size || end > st.st_size || end < > sec->PointerToRawData || > map_file_into_view( view, fd, sec->VirtualAddress, file_size, > sec->PointerToRawData, The program can be downloaded for free at http://www.astroworld.de/ger/. Simply select "AW2001 v.6.2 (English)" in the first selection box and press "Download Demo". With the new version of aw61eng.exe it stuck somewhere at 22% with an error message like "~TMD61.tmp" is not a Win32 binary". With the old version the setup run ok. Thanks and regards Markus Gömmel m.goemmel(a)compulab.de

1 0

Re: winspool: updated some traces for bug 4268
by Huw D M Davies Jan. 13, 2006

Jan. 13, 2006

On Fri, Jan 13, 2006 at 03:51:36PM +0100, Detlef Riekenberg wrote: > Changelog: > > - winspool: updated some traces for bug 4268 > > > -- > By By ... > ... Detlef > diff --git a/dlls/winspool/info.c b/dlls/winspool/info.c > index 9b1771d..a4caa39 100644 > --- a/dlls/winspool/info.c > +++ b/dlls/winspool/info.c > @@ -247,13 +247,16 @@ static BOOL CUPS_LoadPrinters(void) > HKEY hkeyPrinter, hkeyPrinters, hkey; > > cupshandle = wine_dlopen(SONAME_LIBCUPS, RTLD_NOW, NULL, 0); > + TRACE("%p: CUPS loaded (%s)\n", cupshandle, SONAME_LIBCUPS); > if (!cupshandle) > return FALSE; > - TRACE("loaded %s\n", SONAME_LIBCUPS); That's a very confusing TRACE. If wine_dlopen fails then why not print out something like "CUPS not loaded" ? > @@ -439,6 +442,8 @@ PRINTCAP_LoadPrinters(void) { > BOOL had_bash = FALSE; > > f = fopen("/etc/printcap","r"); > + TRACE("%p: using /etc/printcap\n", f); > + > if (!f) > return FALSE; > The same applies to this too. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Linuxtag 2006
by Uwe Bonnes Jan. 13, 2006

Jan. 13, 2006

Hallo, has anybody interest in activly participating in a Wine booth in Linuxtag 2006 (http://www.linuxtag.org/2006/de/home/cfpro.html) in Wiesbaden from May 3 to May 6? Please let me know. Projects should have applied before Feb. 3. 2006. If needed, I can provide a place to sleep here in my flat in Darmstadt. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: advpack: Implement LaunchINFSection on top of DoInfInstall
by James Hawkins Jan. 13, 2006

Jan. 13, 2006

On 1/12/06, Markus Amsler <markus.amsler(a)oribi.org> wrote: > ChangeLog: > Implement LaunchINFSection on top of DoInfInstall > I'm afraid this implementation isn't correct. DoInfInstall calls SetupInstallFromInfSection which only concerns the Install section of an INF file. SetupInstallFromInfSection and consequently DoInfInstall cannot provide enough functionality for LaunchINFSection/Ex. LaunchINFSection/Ex also takes into acount reg and file saves (see Reg/FileSaveRestore), per user sections (see SetPerUserSecValues), registering ocx's, extracting cabinets, and a whole mush of other intricacies. LaunchINFSection/Ex basically combines all the other functions of advpack into a monstrosity of functionality. I'm working my way towards fully implementing LaunchINFSection/Ex, but I've got to finish the lower levels first, so if you'd like to help in this direction, take a look at the stubs I've mentioned in advpack. I appreciate your effort in this implementation, but it will do more harm than good because we'll have to take it out when it comes time to fully implement LaunchINFSection. -- James Hawkins

2 2

Re: advpack: Implement LaunchINFSection on top of DoInfInstall
by Markus Amsler Jan. 13, 2006

Jan. 13, 2006

James, I just saw your advpack patches. Only patch 4 (* Add stubs for the file save/restore functions), Makefile.in gets a merge conflict with mine first 1 (Move inf install functions to install.c ). The rest applies fine (some offset warnings), and builds without warning. Should I rediff against yours or you against mine? Is there a better way to coordinate our efforts? My LaunchINFSectionEx patch seems to improve bug 3636. Markus

1 0

New wannabe developer
by Dan Kegel Jan. 13, 2006

Jan. 13, 2006

Zoe wrote: > Hi, I've got nothing better to do at the moment so I was wondering what > the best way to help move things forwards and contribute back to the > project. :-) Glad to meet you :-) I have a page that might help: http://kegel.com/wine/sweng/ Hope it helps. Let me know if there's anything unclear there. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: Alexandre Julliard : server: Don't round up the header size for image mappings.
by Michael Jung Jan. 13, 2006

Jan. 13, 2006

Hi, On Wednesday 11 January 2006 21:34, Alexandre Julliard wrote: > http://source.winehq.org/git/?p=wine.git;a=commit;h=b54e9e94e98624acde1bb00 > e10c2055dfed9c2d7 > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Wed Jan 11 20:59:26 2006 +0100 > > server: Don't round up the header size for image mappings. This patch prevents certain executables (at least those generated with Borland C++ 5.02) from being loaded. I've attached a small example. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0