December 2004 - Wine-devel - list.winehq.org

RE: Incoming Msg
by Rklazes 17 Dec '04

17 Dec '04

1 0

Re: Document
by M.hearn 17 Dec '04

17 Dec '04

1 0

MFC app and WineLib
by Serge S. Spiridonoff 17 Dec '04

17 Dec '04

Hi, When porting an MFC app to Linux using WineLib is it really necessary to recompile the MFC DLL from source? Can I take MFC42.dll from Windows and use it "as is" with an application compiled with WineLib? Thanks, Serge

3 4

Re: [dplobby.h] Define DirectPlayLobbyCreate with respect unicode
by Vincent Béron 17 Dec '04

17 Dec '04

Le ven 17/12/2004 à 11:20, Peter Berg Larsen a écrit : > > There might be a better way but I dont know it. > > Changelog: > Defines DirectPlayLobbyCreate to be either the W or A version depending > on the UNICODE. Needed for warzone 2100. > > Peter > > diff -u -r wine-20041201-org/include/dplobby.h wine-20041201/include/dplobby.h > --- wine-20041201-org/include/dplobby.h 2004-10-05 06:38:15.000000000 +0200 > +++ wine-20041201/include/dplobby.h 2004-12-12 11:45:00.000000000 +0100 > @@ -342,7 +342,11 @@ > > } DPAPPLICATIONDESC, *LPDPAPPLICATIONDESC; > > - > +#ifdef UNICODE > +# define DirectPlayLobbyCreate DirectPlayLobbyCreateW > +#else > +# define DirectPlayLobbyCreate DirectPlayLobbyCreateA > +#endif > > extern HRESULT WINAPI DirectPlayLobbyCreateW(LPGUID, LPDIRECTPLAYLOBBY*, IUnknown*, LPVOID, DWORD ); > extern HRESULT WINAPI DirectPlayLobbyCreateA(LPGUID, LPDIRECTPLAYLOBBYA*, IUnknown*, LPVOID, DWORD ); Use #define DirectPlayLobbyCreate WINELIB_NAME_AW(DirectPlayLobbyCreate) after the W and A declarations. That's the standard way in Wine of doing it. Vincent

1 0

Possible bug in Wine 20041201
by Ira Krakow 17 Dec '04

17 Dec '04

I did a fresh install of Wine from the Winehq CVS repository. I got the following message during the install: fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 1.0, please report!! I checked bugzilla and didn't see that this bug is tracked. So I'm following instructions, and reporting it. The Wine version is 20041201. My computer is a Dell Dimension 4100 Pentium 3. I'm running Fedora Core 2. Is this a bug? If so, is there a patch for it? Should this be tracked? Ira Krakow ikrakow_1999(a)yahoo.com

2 3

Problems unveiled by the last version.c patch
by pvriens＠xs4all.nl 17 Dec '04

17 Dec '04

Hi, just started with a fresh wine install from CVS. I've tried to install vc6redistsetup_enu.exe and was not able to select a directory via the browse dialog. Some regression testing and debugging showed: before patch http://cvs.winehq.org/patch.py?id=14894 : trace:shell:BrsFolderDlgProc hwnd=0x1002e msg=0082 0x00000000 0x00000000 trace:shell:SHGetPathFromIDListAW (pidl=0x63f4f5b8,0x100b720) trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:shell:SHGetPathFromIDListA (pidl=0x63f4f5b8,0x100b720) -------- pidl=0x63f4f5b8 [0x63f4f5b8] size=0020 type=1f attr=0x00000000 name="{20d04fe0-3aea-1069-a2d8-08002b30309d}" ((null),(null)) [0x63f4f5cc] size=0025 type=23 attr=0x00000000 name="F:\" ("F:\\",(null)) [0x63f4f5e5] size=0020 type=31 attr=0x00000010 name="temp" ("temp","") trace:pidl:_ILIsValue (0x63f4f5b8) trace:pidl:_ILIsFolder (0x63f4f5b8) trace:pidl:_ILGetGUIDPointer 0x63f4f5b8 trace:pidl:_ILGetGUIDPointer pdata->type 0x001f trace:pidl:_ILIsMyComputer (0x63f4f5b8) trace:pidl:ILGetNext 0x63f4f5b8 trace:pidl:ILGetNext -- 0x63f4f5cc trace:pidl:_ILIsSpecialFolder (0x63f4f5cc) trace:pidl:ILGetNext 0x63f4f5cc trace:pidl:ILGetNext -- 0x63f4f5e5 trace:shell:PathAddBackslashA ("F:\\") trace:pidl:_ILIsSpecialFolder (0x63f4f5e5) trace:pidl:ILGetNext 0x63f4f5e5 trace:pidl:ILGetNext -- 0x63f4f5f9 trace:shell:SHELL_GetPathFromIDListA -- F:\temp, 0x00000000 after the patch : trace:shell:BrsFolderDlgProc hwnd=0x1002e msg=0082 0x00000000 0x00000000 trace:shell:SHGetPathFromIDListAW (pidl=0x77e2dbe8,0x100b720) trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:shell:SHGetPathFromIDListW (pidl=0x77e2dbe8,0x3f0472b4) -------- pidl=0x77e2dbe8 [0x77e2dbe8] size=0020 type=1f attr=0x00000000 name="{20d04fe0-3aea-1069-a2d8-08002b30309d}" ((null),(null)) [0x77e2dbfc] size=0025 type=23 attr=0x00000000 name="F:\" ("F:\\",(null)) [0x77e2dc15] size=0020 type=31 attr=0x00000010 name="temp" ("temp","") trace:pidl:_ILIsValue (0x77e2dbe8) trace:pidl:_ILIsFolder (0x77e2dbe8) trace:pidl:_ILGetGUIDPointer 0x77e2dbe8 trace:pidl:_ILGetGUIDPointer pdata->type 0x001f trace:pidl:_ILIsMyComputer (0x77e2dbe8) trace:pidl:ILGetNext 0x77e2dbe8 trace:pidl:ILGetNext -- 0x77e2dbfc trace:pidl:_ILIsSpecialFolder (0x77e2dbfc) trace:pidl:ILGetNext 0x77e2dbfc trace:pidl:ILGetNext -- 0x77e2dc15 trace:shell:PathAddBackslashW (L"F:\\") trace:pidl:_ILIsSpecialFolder (0x77e2dc15) trace:pidl:ILGetNext 0x77e2dc15 trace:pidl:ILGetNext -- 0x77e2dc29 trace:shell:SHELL_GetPathFromIDListW -- L"F:\\temp", 0x00000000 trace:shell:SHGetPathFromIDListW -- L"F:\\temp", 0x00000000 The main difference (apart from the A/W) is that SHGetPathFromIDListW returns an extra backslash compared to the A-counterpart. Any idea where to look next ? Cheers, Paul.

5 6

Re: Advapi32/service.c fix
by Dmitry Timoshkov 17 Dec '04

17 Dec '04

"Ivan Leo Puoti" <puoti(a)inwind.it> wrote: > - if( strcmpiW( lpDatabaseName, SERVICES_ACTIVE_DATABASEW ) == 0 ) > + if( (strcmpiW(lpDatabaseName, SERVICES_ACTIVE_DATABASEW)==0) || (lpDatabaseName[0]==(INT)NULL)) It's much simpler to use either !lpDatabaseName[0] or lpDatabaseName[0] == 0 instead of several levels of casting. -- Dmitry.

1 0

Build problems with GL_VERSION_1_2
by Bill Medland 17 Dec '04

17 Dec '04

(Jason?) Currently (after many weeks without concentrating) wine doesn't build; it fails in dlls/wined3d/drawprim.c line 594 with GL_TEXTURE0 undefined. That's because of the definition of GL_MULTITEXCOORD... in wined3d_private.h for the non-GL_VERSION_1_3 case. I can see a linguistically obvious fix that gets me thorugh the compilation but since I haven't the faintest idea about d3d and GL I don't know if it is correct, so I won't submit it. -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

2 2

Hang in usr1_handler (ptrace issue?)
by Mike Hearn 16 Dec '04

16 Dec '04

Hi, Lately I've been seeing hangs of this form: Backtrace: =>1 0x4df8e7a2 (0x659ffb54) 2 0x5246f507 NTDLL_wait_for_multiple_objects+0x387(count=0x0, handles=0x0, flags=0x8, timeout=0x659ffd10) [/source/wine/dlls/ntdll/sync.c:683] in ntdll (0x659ffcf8) 3 0x5246da88 usr1_handler+0x38(__signal=0xa, __context=0x33) [/source/wine/dlls/ntdll/signal_i386.c:1159] in ntdll (0x659ffd1c) 4 0x100238a8 (0x65bfc6cc) 5 0x5246f507 NTDLL_wait_for_multiple_objects+0x387(count=0x1, handles=0x65bfc8bc, flags=0x4, timeout=0x0) [/source/wine/dlls/ntdll/sync.c:683] in ntdll (0x65bfc870) 6 0x5246f5df NtWaitForMultipleObjects+0x4b(count=0x1, handles=0x65bfc8bc, wait_all=0x0, alertable=0x0, timeout=0x0) [/source/wine/dlls/ntdll/sync.c:713] in ntdll (0x65bfc898) 7 0x1894e4b3 WaitForMultipleObjectsEx+0xa3(count=0x1, handles=0x65bfc9f0, wait_all=0x0, timeout=0xffffffff, alertable=0x0) [/source/wine/dlls/kernel/sync.c:180] in kernel32 (0x65bfc9c8) in other words, whilst waiting on some server object it was suspended. I am running the FC3 kernel "2.6.9-1.681_FC3". Is this what the previously discussed ptrace change would look like? If so I may need to ask Red Hat to do an errata or something. I saw that in 2.6.10-rc3 another ptrace change went in, so it may be that it's now fixed. thanks -mike

4 5

Re: PATCH: dlls/oleaut32/tests/vartype.c
by Robert Shearman 16 Dec '04

16 Dec '04

Marcus Meissner wrote: >Hi, > >This fixes the currently last gcc4 problem. > >I had to split up MSVC / non-MSVC cases since glibc/sprintf >and msvcrt/sprintf disagree on how to print out 64bit integers. > > If you don't use the macro then you can use wine_dbgstr_longlong and not have to worry about compiler differences. Rob

1 0