September 2004 - Wine-devel

Re: Shell32: Reimplement SHGetFolder functions
by Alexandre Julliard 15 Sep '04

15 Sep '04

Juan Lang <juan_lang(a)yahoo.com> writes: > +static void loadShell32(void) > +{ > + if (hShell32) > + { > + if (pMalloc) > + { > + pMalloc->lpVtbl->Release(pMalloc); > + pMalloc = NULL; > + } > + /* until it's really unloaded: */ > + while (FreeLibrary(hShell32)) > + ; I'm not sure what you are trying to do here, but this causes an infinite loop on XP (and it probably should under Wine too, since the test binary imports shell32). Also some tests fail on XP: shellpath.c:433: Test failed: SHGetFolderPath returned 0x00000000, expected 0x80070002 shellpath.c:438: Test failed: SHGetFolderLocation returned 0x00000000, expected E_FAIL shellpath.c:442: Test failed: SHGetSpecialFolderPath succeeded, expected failure shellpath.c:447: Test failed: SHGetFolderLocation returned 0x00000000, expected E_FAIL -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: msvcrt: fill _chsize, _dup, _dup2
by Andreas Mohr 15 Sep '04

15 Sep '04

Hi, On Wed, Sep 15, 2004 at 06:53:28AM +0000, JustFillBug wrote: > > Use the POSIX peer. I don't think this is correct (and if it was, then it would have been done that way already, I guess). I'm not too familiar with our msvcrt, but it looks like these functions should definitely be implemented by means of our msvcrt's file handle management: msvcrt_alloc_fd(), msvcrt_alloc_fp() and many other related functions. Reason being that if you simply dup() an fd, that this properly registered source fd (in msvcrt, that is), would end up with a cloned fd that is NOT being properly registered on the msvcrt side. To make it more obvious: _close() uses msvcrt_fdtoh(), which would most likely fail for an msvcrt-foreign fd. Would be cool if you could implement it the correct way, though. Thanks, Andreas Mohr

1 0

DirectX compatability testing -- RFC results for running a specific program
by Belxjander Serechai 15 Sep '04

15 Sep '04

Ive got a small (can be transported on floppy disk) program that has a major and drastic result effect when run on a "pure" Wine only installation against both Xfree86 4.4.0 + Xorg 6.7.0, "Oh My Goddess - Smash The Bugs" ... I am curious as to anyone else Acquiring and testing this program against another installation. Im honestly not sure whether it is specifically my own setup or some interaction problem as it does a full X system deadlock and I have no response even when attempting to ssh into my own linux system I no longer have an active second machine to SSH from. I would like to confirm whether X alone or whether there is a full kernel level runtime deadlock occuring P.S. have to thank the person who gave such an eloquient reason to ignore trying to debug/test/ find those sections of the Wine "DirectX" implimentation needing work... since I wasn't interested in using the Windows release "DirectX" components for anything more than a compatability test suite to start with... Anyone else wanting to jump in feet first without asking questions? Thanks in advance, Jeremy Sutherland

2 2

Current cvs brokeness...
by James Pellow 15 Sep '04

15 Sep '04

Hi List, Just downloaded the most recent cvs, and noticed it can't run the Office 2000 installer. I haven't tried anything else, but it looks like a general msi failure. I can't spend any time on this (shouldn't be playing with it at the office anyway...) but here is the output: fixme:font:WineEngRemoveFontResourceEx :stub fixme:font:WineEngRemoveFontResourceEx :stub fixme:msi:MsiEnableLogA 00000516 "c:\\windows\\temp\\Office 2000 Professional Setup (0002)_MsiExec.txt" 00000000 fixme:msi:MsiInstallProductW L"/I" L"" fixme:msi:MSI_OpenDatabaseW open failed r = 80004005! Installation of /I () failed. Is the msi system brocken right now? I also noticed that the common file dialog seems to be returning garbage. Try selecting a file in progman-file-execute-browse for example. Just FYI... -- ***************************** James A. Pellow, President Alent Design Solutions www.alentdesignsolutions.com (509) 526-0682 *****************************

3 3

Cryptographic functions
by Alexander Yaworsky 15 Sep '04

15 Sep '04

Hello there is some secret crypto API in 2k and xp. Not so long ago i played with native rsaenh.dll under wine and found that it requires md5 and sha functions exported by advapi32.dll. I don't know where this API really should be. Latest platform SDK is very cryptic itself. Just in case here is a patch. IMHO it worths to be submitted but i'm not sure. Index: dlls/advapi32/advapi32.spec =================================================================== RCS file: /home/wine/wine/dlls/advapi32/advapi32.spec,v retrieving revision 1.55 diff -u -r1.55 advapi32.spec --- dlls/advapi32/advapi32.spec 14 Sep 2004 19:25:35 -0000 1.55 +++ dlls/advapi32/advapi32.spec 15 Sep 2004 11:56:04 -0000 @@ -1,3 +1,6 @@ +@ stub A_SHAInit +@ stub A_SHAUpdate +@ stub A_SHAFinal @ stdcall AbortSystemShutdownA(ptr) @ stdcall AbortSystemShutdownW(ptr) @ stdcall AccessCheck(ptr long long ptr ptr ptr ptr ptr) @@ -169,6 +172,9 @@ @ stdcall MakeAbsoluteSD(ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr) @ stdcall MakeSelfRelativeSD(ptr ptr ptr) @ stub MapGenericMask +@ stub MD5Init +@ stub MD5Update +@ stub MD5Final @ stdcall NotifyBootConfigStatus(long) @ stdcall NotifyChangeEventLog (long long) @ stub ObjectCloseAuditAlarmA

1 0

Re: Shell32: fix DllGetVersion for newer callers
by Robert Shearman 15 Sep '04

15 Sep '04

Juan Lang wrote: >A bit better than my last version, load the version >resource from the file for DllGetVersion, and update >the version of the file to produce the same output as >before. > >ChangeLog: add support for DLLVERSIONINFO2 in >DllGetVersion, and get version info from file > >--Juan > > ... >--- dlls/shell32/Makefile.in 11 Aug 2004 23:59:07 -0000 1.84 >+++ dlls/shell32/Makefile.in 14 Sep 2004 17:16:37 -0000 >@@ -4,7 +4,7 @@ > SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = shell32.dll >-IMPORTS = shlwapi comctl32 user32 gdi32 advapi32 kernel32 >+IMPORTS = shlwapi comctl32 user32 gdi32 advapi32 kernel32 version > DELAYIMPORTS = ole32 > EXTRALIBS = -luuid $(LIBUNICODE) > This is *really* ugly. Create a header file with just the version numbers defined and import it from the resource file and the file that implements the DllGetVersion function and problem solved. Rob

2 2

IUnknown_Release_Proxy leading to exception
by James Hawkins 15 Sep '04

15 Sep '04

This is the final debug output when I run ICQ: wine: Unhandled exception (thread 0023), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405fbab0,1) - no error checking or testing yet WineDbg starting on pid 0x24 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x40ab8695). In 32 bit mode. q0x40ab8695 IUnknown_Release_Proxy [/home/truiken/wine/dlls/rpcrt4/cproxy.c:330] in rpcrt4: movl 0x0(%eax),%edx 330 return IUnknown_Release(This->pUnkOuter); 330 return IUnknown_Release(This->pUnkOuter); Wine-dbg>l syntax error Wine-dbg>list 330 return IUnknown_Release(This->pUnkOuter); 331 #endif 332 } 333 in reading the comments, the interface refcounting is commented out and object refcounting is what is being used. i added a refCount variable to cproxy.c and did refCount++ and refCount-- in IUnknown_Release_Proxy and IUnknown_AddRef_Proxy with additional trace statements that show the value of refCount. right before the exception, a trace shows refCount to be -1. This is the log of trace+relay,ole: 045:Call kernel32.InterlockedDecrement(41277154) ret=00405614 0045:Ret kernel32.InterlockedDecrement() retval=0000000b ret=00405614 0045:Call kernel32.InterlockedDecrement(00637d80) ret=0040561b 0045:Ret kernel32.InterlockedDecrement() retval=00000042 ret=0040561b trace:ole:ObjectStubless (0x4311b3c4)->(5)([4 bytes]) ret=143db323 fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x2476aa98,pFormat = ^0x2476a626,...): stub 0045:Call rpcrt4.IUnknown_Release_Proxy(4311b3c4) ret=00484779 trace:ole:IUnknown_Release_Proxy refCount: -1 trace:ole:IUnknown_Release_Proxy (0x4311b3c0)->Release() MIBDBCovnert 0045:Call kernel32.UnhandledExceptionFilter(406cdd6c) ret=4090f2b8 Any thoughts? -- James Hawkins

3 2

wine / dlls / itss / itss.c -> ICOM_THIS() macro is defined where ?
by Belxjander Serechai 15 Sep '04

15 Sep '04

I have currently for the last several days been attempting to update my local installation of wine and found that I get blocked by this... Apparently where this macro is used causes errors, is this a possible regression or something was missed at somepoint? Thanks in advance, Jeremy

2 1

include/wine/port.h and socklen_t breakage
by Gerald Pfeifer 15 Sep '04

15 Sep '04

The following change to include/wine/port.h revision 1.58 date: 2004/09/03 18:30:28; author: julliard; state: Exp; lines: +3 -0 Added configure check for socklen_t. +#ifndef HAVE_SOCKLEN_T +typedef unsigned int socklen_t; +#endif causes the following build failure on an old version of FreeBSD 5.1, and probably other systems as well. gmake[1]: Entering directory `/home/gerald/wine/loader' /usr/bin/gcc -c -I. -I. -I../include -I../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o kthread.o kthread.c In file included from kthread.c:41: /usr/include/sys/socket.h:77: error: redefinition of `socklen_t' ../include/wine/port.h:65: error: `socklen_t' previously declared here gmake[1]: *** [kthread.o] Error 1 The issue here is that socklen_t is defined in /usr/include/sys/socket.h, but ac_include_default in the configure script does not contain this dir. Which means that HAVE_SOCKLEN_T will be undefined, but once you include /usr/include/sys/socket.h, you'll get the conflict with our port.h. Gerald

1 0

Directx9
by Ann and Jason Edmeades 15 Sep '04

15 Sep '04

Hello, I've spoken with the wine-d3d people and noone is currently doing anything on directx9 support. Originally Raphael was trying to merge things into a new library, wined3d, using an interface which ddraw could also use. This has not happened, and as we stand there is no progress being made. Now, I know nothing about d3d9 support - I have started to see what would be the easiest way to implement this, and have come up with a couple of options, and am after some advice.... 1. (My preference) d3d8 and d3d9 are very similar in lots of respects. I would like to move all the GL code into the wined3d library, effectively factorizing d3d8 and d3d9. However, this would mean extra function call overhead for dx8 and I really dont know how common they will be. Obviously d3d8 will change during such a transition 2. I could implement d3d9 from scratch. This would have the advantage of being a standalone library and wont affect d3d8, but a disadvantage of having to fix anything twice, and probably they will get out of sync really quickly. Also, d3d8 still has parts missing, and I'd prefer a single implementation if possible. If we did this, wined3d could be deleted and a huge code duplication would be required (or 3.... Do nothing, and see if anyone else takes up the gauntlet.) Now, I am not a 3d graphics programmer - I learnt d3d8 as I implemented it (for wine) out of interest to see how things were done. I am happy to try to do the same for d3d9, and would prefer approach (1). I have a few concerns though - Mostly I havent done enough research to know if its possible, and I may end up having a shared library with 2 implementations anyway... I havent found any major stumbling block yet, but I havent researched it far enough either. My other concern is if I start doing it and have to give up due to work or other pressures, I could leave a half migrated setup. I assume its relavitevly easy with cvs to back out changes if this occurs, and I hope it wont, but it is a concern. I'd appreciate thoughts before I start (especially Lionels, AJ's etc) - I'm only just getting back into wine programming again hence my interest. Jason

9 16