- Wine-Devel - list.winehq.org

Possible bug in Wine 20041201
by Ira Krakow Dec. 17, 2004

Dec. 17, 2004

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 Dec. 17, 2004

Dec. 17, 2004

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 Dec. 17, 2004

Dec. 17, 2004

"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 Dec. 17, 2004

Dec. 17, 2004

(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 Dec. 17, 2004

Dec. 17, 2004

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 Dec. 16, 2004

Dec. 16, 2004

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

<<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive
by Robert van Herk Dec. 16, 2004

Dec. 16, 2004

Hi, I had some problems with my mail server, so I send in this patch again. If the previous one did arrive, please ignore this e-mail. ------------------------------------------------------------------------ Changes: Added functionality to browse for a UNIX folder. This is done by making two new funtions in dlls/shell32/brsfolder.c, namely wine_shell_browse_for_UNIX_directoryA wine_shell_browse_for_UNIX_directoryW These functions are exported in shlobj.h. The original code that allowed just for picking a Windows folder, was split up. It was to be found in brsfolder.c, but I split this in: brsfolder.c brsfolder.h brsfolder_windows.c brsfolder_windows.h brsfolder_unix.c brsfolder_unix.h unixTools.c unixTools.h, Otherwise I found the code to be incomprehendible. Furthermore, winecfg now uses the wine_shell_browse_for_UNIX_directoryA to let the user pick a UNIX directory as root for his virtual drive mappings. Regards, Robert van Herk

8 15

Re: Stubs in PE build
by Jon Griffiths Dec. 16, 2004

Dec. 16, 2004

Hi, I had a patch which enabled stub generation for building native dlls last year (http://www.winehq.org/hypermail/wine-patches/2003/07/0176.html) that part was not accepted for the same reasons that are being mentioned in this thread. I would like to point out again that the VC linker will not generate a correct dll unless the ordinal stubs are present. Other native linkers may have the same problem. It seems very silly to me that we can't use M$'s own compiler/linker to build valid dlls (especially since these tools can be downloaded for free these days). M$ defined the dll format we are using, after all. If this is intentional, perhaps we should document it somewhere? Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

3 6

Re: Definition of IMessageFilter in objidl.h
by Dmitry Timoshkov Dec. 16, 2004

Dec. 16, 2004

"Serge S. Spiridonoff" <sss(a)corbina.net> wrote: > Well, I've just noticed the following record in the ChangeLog... > > * include/objidl.h, include/objidl.idl: > Jake Hamby <jhamby(a)anobject.com> > IMessageFilter::HandleInComingCall() should be HandleIncomingCall(). > > Also, http://cvs.winehq.org/patch.py?id=12310 > > So I'm a bit confused now!? Since I'm new to Wine I'd like someone more > experienced to judge this collision. Apparently the patch above is wrong since microsoft headers have it in different case. The patch should be reverted. If you could send a patch which just reverts the above change that would be great. -- Dmitry.

1 0

dlls/gdi/tests/metafile.c warning about test_mf_PatternBrush
by Gerald Pfeifer Dec. 16, 2004

Dec. 16, 2004

The following patch to dlls/gdi/tests/metafile.c revision 1.3 date: 2004/12/09 11:37:59; author: julliard; state: Exp; lines: +236 -0 Walt Ogburn <reuben(a)ugcs.caltech.edu> Added some tests for win-format metafiles. introduces the following warning: metafile.c:381: warning: `test_mf_PatternBrush' defined but not used Should we put #ifdefs around the definition, or enable the following code in the main test function? /* Crashes under wine: */ /* test_mf_PatternBrush(); */ Another option would be not to make this function static. Gerald

5 5