May 2003 - Wine-Devel - list.winehq.org

Re: ntdll/kernel32: #25
by Alexandre Julliard May 20, 2003

May 20, 2003

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > - access to PROCESS_PARAMETERS from kernel32: currently this is done > by exporting a function pointer from ntdll, but this is not a good > solution IMO. Should we better: 1/ create a real PEB and store it at > its real offset. 2/ store the pointer to PROCESS_PARAMETER in the PDB > (even if it doesn't exist in PDB but in PEB) at an unused offset (I > don't think it's really doable to merge PDB and PEB, or we'll have to > trash PDB.exit_code) PDB and PEB are really the same thing, so they definitely have to be merged. -- Alexandre Julliard julliard(a)winehq.com

2 2

DSound bug in 'DuplicateSoundBuffer'
by Lionel Ulmer May 20, 2003

May 20, 2003

Hi all, One of my test application (which now starts to run with my latest D3D work) fails now due to a bug in DSound. Basically, I have this : trace:dsound:IDirectSoundImpl_DuplicateSoundBuffer (0x4040aa80,0x4861fad0,0x4199cf58) fixme:dsound:IDirectSoundImpl_DuplicateSoundBuffer need to duplicate 3D buffer trace:dsound:IDirectSoundBufferImpl_AddRef (0x4861fad0) ref was 2, thread is 0009 trace:dsound:IDirectSoundImpl_DuplicateSoundBuffer buffer count is now 4 trace:dsound:IDirectSoundBufferImpl_SetVolume (0x40463080,0) And, of course, it crashes as the 'DuplicateSoundBuffer' code sets this : (*ippdsb)->ds3db = NULL; /* FIXME? */ Now I could try to fix this, but well, DSound is not really the same than the last time I looked at it, so I will surely do this the wrong way. Otherwise, I may give it a shot, but do not complain later that it's not the way it should have been done :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

Re: [D3D] Some execute buffers rewrites + misc fixes
by Lionel Ulmer May 20, 2003

May 20, 2003

Some comments on 'small' parts... I will have to commit the patch on my tree to try to understand the resulting code to understand it better :-) > + if ( IsEqualGUID( &IID_IDirectDrawSurface, riid ) || > + IsEqualGUID( &IID_IDirectDrawSurface2, riid ) || > + IsEqualGUID( &IID_IDirectDrawSurface3, riid ) ) { > + IDirectDrawSurface7_AddRef(ICOM_INTERFACE(This->surface, IDirectDrawSurface7)); > + *obp = ICOM_INTERFACE(This->surface, IDirectDrawSurface3); > + TRACE(" Return IDirectDrawSurface3 interface %p\n", *obp); > + return S_OK; > + } > + if ( IsEqualGUID( &IID_IDirectDrawSurface3, riid ) || > + IsEqualGUID( &IID_IDirectDrawSurface7, riid ) ) { > + IDirectDrawSurface7_AddRef(ICOM_INTERFACE(This->surface, IDirectDrawSurface7)); > + *obp = ICOM_INTERFACE(This->surface, IDirectDrawSurface7); > + TRACE(" Return IDirectDrawSurface7 interface %p\n", *obp); > + return S_OK; > + } Well, it's a bit strange to have 'IID_IDirectDrawSurface3' twice, no :-) ? > /* We only support the BLT with DEPTH_FILL for now */ > - if (This->ddraw_owner->d3d != NULL) { > + if ((dwFlags & DDBLT_DEPTHFILL) && This->ddraw_owner->d3d != NULL) { > if (This->ddraw_owner->d3d->current_device != NULL) { > This->ddraw_owner->d3d->current_device->clear(This->ddraw_owner->d3d->current_device, > 0, NULL, /* Clear the whole screen */ Did you add this check here because some game were actually doing a 'normal' blit on the ZBuffer ? What happens in this case ? Moreover, you could also add here (which I forgot to do in my patch), support for the 'dst locking rectangle' in case an application tries to clear only part of the buffer (see example in the Blt overide function in d3ddevice/mesa.c for the 'Colorfill' case). Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Linking errors when crosscompiling tests
by Hans Leidekker May 20, 2003

May 20, 2003

Hi, When I run a 'make crosstest' using MingW I get errors like these: /usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:289: undefined reference to `IID_IUnknown' safearray.cross.o(.text+0x1814):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:290: undefined reference to `IID_IUnknown' What's happening is that this test references symbols that reside in wine_uuid, which is added to the library search path for the regular Wine build, but left out in the crosscompile build. For good reasons, because wine_uuid is built as a Unix archive, not as an import library, which is what MingW needs. So I created an import library from the Unix archive: nm libwine_uuid.a | egrep -v "^$" | egrep -v "^*.o:$" | cut -d" " -f 3 \ >> wine_uuid.def i386-mingw32-dlltool -l wine_uuid.lib -d ./wine_uuid.def And I had a working executable. But this obviously is not the way Wine does it. Wine generates .def files from .spec files. To use Wine's build system I had to create a new dll -- uuid -- and copy the sources over from libs/uuid. This gave me a Wine generated import library. Next I added uuid as an import library to the Makefile for the oleaut32 test and removed wine_uuid from EXTRALIBS. Did this solve my problem? No it didn't. Because, as it turns out, winebuild does not support importing non-function entry points, such as IID_IUnknown. After googling around a bit I have to conclude that this is quite a fundamental problem. If I understand it correctly, it's because in this case PE style linking can not be emulated using the ELF linker. Then I decided to bypass linking and go with LoadLibraryA and GetProcAddress, which are already used in the tests to find the functions to be tested. This finally gave me a uniform build system for regular and crosscompiled tests. My question is, is this acceptable for integration into Wine? The consequence would be that, to be consistent, all parts of Wine that are now linked with wine_uuid would need to be converted. Or is such consistency maybe considered less important than getting crosscompiled tests going? -Hans

3 4

wine and VC++ MFC classes
by Thomas Erdmann May 20, 2003

May 20, 2003

Hello list, i use a new wine from may 2003 on SuSE8.0 and want to run a self written Visual C++ Program with MFC. There is a "CMonthCalCtrl" used, which displayes a calendar und allowes to choose a day. This Control doesn't work, the Selection by Mouse is not possible. As i started it by "wine prog" in a shell, i can see the wine output, but there isn't any warning or error. What can i do to fix the Problem ? THX Thomas

2 1

Re: Agent/Wine/Mandrake 9.1 problem
by Rein Klazes May 20, 2003

May 20, 2003

Gentlemen, I am trying to help Alex Heney who reported problems in agent newsgroup running Agent on his Manrdake 9.1 system. Wine is compiled with the --with-nptl configuration switch enabled, but we still get what looks like thread lock-ups. Both with wine-20030408 and 20030508 Agent frequently freezes when doing online tasks. Here is an example: | 0012:Call kernel32.CreateThread(00000000,00002000,00573144,421db238,00000000,407120c0) ret=005731f3 | 0014:Starting thread (entryproc=0x573144) thread with id 14 is started. It performs a few simple tasks: | 0014:Call kernel32.SetFilePointer(000000bc,00000020,42a4271c,00000000) ret=0043eb2f | 0014:Ret kernel32.SetFilePointer() retval=00000020 ret=0043eb2f | 0014:Call kernel32.SetLastError(00000000) ret=0043ed82 | 0014:Ret kernel32.SetLastError() retval=00000000 ret=0043ed82 | 0014:Call kernel32.ReadFile(000000bc,421d7af8,00000020,42a42718,00000000) ret=0043ed97 | 0014:Ret kernel32.ReadFile() retval=00000001 ret=0043ed97 does something on inherited file handles. | 0014:Call kernel32.GetPrivateProfileIntA(005d5b53 "Purging",005d5b5b "PurgeOnNewHeaders",00000001,41a60d48 "C:\\Program Files\\agent\\DATA\\AGENT.INI") ret=00577677 | 0014:Ret kernel32.GetPrivateProfileIntA() retval=00000001 ret=00577677 reads a flag from its ini file. | 0014:Call kernel32.VirtualQuery(427e0000,42a426d0,0000001c) ret=00588d5e | 0014:Ret kernel32.VirtualQuery() retval=0000001c ret=00588d5e | 0014:Call kernel32.VirtualQuery(427e0000,42a426c8,0000001c) ret=00588d5e | 0014:Ret kernel32.VirtualQuery() retval=0000001c ret=00588d5e | 0014:Call kernel32.VirtualFree(427e0000,00010000,00004000) ret=00588bd7 | 0014:Ret kernel32.VirtualFree() retval=00000001 ret=00588bd7 | 0014:Call kernel32.VirtualFree(427e0000,00000000,00008000) ret=00588be8 | 0014:Ret kernel32.VirtualFree() retval=00000001 ret=00588be8 does some virtual queries. | 0014:Call user32.PostMessageA(00040023,00000411,421d1000,00000000) ret=0046c56d | 0014:Call kernel32.GetTickCount() ret=408865f9 | 0014:Ret kernel32.GetTickCount() retval=004f7151 ret=408865f9 | 0014:Ret user32.PostMessageA() retval=00000001 ret=0046c56d post a message to the main window. | 0014:Call kernel32.ExitThread(00000000) ret=0057326c And it is done, after some unloading call from this thread the log stops and no other threads resume. On my (non nptl) system I do see a "Ret CreateThread" from the calling thread long before the subthread exits. For completeness: Alex reported this to happen only when he connects to his local newsserver on "localhost", not when using that of his ISP. I cannot find anything suspicious about this in the relaylog, so it is probably a timing issue. Any suggestions how to debug this? Full +relay,+winsock log on http://www.xs4all.nl/~rklazes/temp/agent.log.bz2 Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 2

Building wine as shared objects for mono
by Mike Hearn May 20, 2003

May 20, 2003

Hi, OpenLink Software just announced their patches to Wine to allow mono to Wine directly, rather than by building a winelib wrapper. You can find some info and the patch here: http://www.openlinksw.com/mono/ Warning - the patch is large (~75k) and has lots of #ifdef MONOs and such, but interesting nonetheless, regardless of how big a hack it is. It'd be interesting for Alexandre to review this sometime and evaluate how much would be required to make this mergable (assuming it is). This goes back to our discussion earlier about what would be required for Wine to be dlopen()able for other projects to use it. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Re: Bugzilla Upgraded
by Dan Kegel May 20, 2003

May 20, 2003

Sylvain Petreolle wrote: > - Login is mandatory otherwise you cant read bugs. > Its too bad, you cant see if a bug already exists before openeing an > account nor follow a link to a bug. I think it's ok to require login to read bugs. This is the only effective defence against rampaging robots. I recently created a web page about how to triage OpenOffice.org bugs (http://www.kegel.com/openoffice/) and even though I stuck <meta name="robots" content="nofollow"> in the head, I think spambots are hammering the openoffice issuezilla server and make the current slowdowns worse. Plus there's the matter of all those email addresses. Requiring login helps shield the email addresses in bugzilla from spambots. So hip hip hooray for the upgrade from this developer, restrictive access and all. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

9 23

OGL: cubemaps
by Robert Lunnon May 20, 2003

May 20, 2003

Compiling the latest CVS wine gives the following compile time error due to use of cubemapping under Solaris. I suggest perhaps a configure test for the OGL version prior to enabling this code since this obviously Isn't supported for Mesa 3.2 and utah glx. (No Can't use DRI, not (yet) supported under Solaris) cubetexture.c:125: `GL_TEXTURE_CUBE_MAP_POSITIVE_X_ARB' undeclared here (not in a function) cubetexture.c:125: initializer element is not constant cubetexture.c:125: (near initialization for `cube_targets[0]') cubetexture.c:126: `GL_TEXTURE_CUBE_MAP_NEGATIVE_X_ARB' undeclared here (not in a function) cubetexture.c:126: initializer element is not constant cubetexture.c:126: (near initialization for `cube_targets[1]') cubetexture.c:127: `GL_TEXTURE_CUBE_MAP_POSITIVE_Y_ARB' undeclared here (not in a function) cubetexture.c:127: initializer element is not constant cubetexture.c:127: (near initialization for `cube_targets[2]') cubetexture.c:128: `GL_TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB' undeclared here (not in a function) cubetexture.c:128: initializer element is not constant cubetexture.c:128: (near initialization for `cube_targets[3]') cubetexture.c:129: `GL_TEXTURE_CUBE_MAP_POSITIVE_Z_ARB' undeclared here (not in a function) cubetexture.c:129: initializer element is not constant cubetexture.c:129: (near initialization for `cube_targets[4]') cubetexture.c:132: `GL_TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB' undeclared here (not in a function) cubetexture.c:132: initializer element is not constant cubetexture.c:132: (near initialization for `cube_targets[5]') cubetexture.c: In function `IDirect3DCubeTexture8Impl_PreLoad': cubetexture.c:144: `GL_TEXTURE_CUBE_MAP_ARB' undeclared (first use in this function)

1 0

Re: Fixes some debug messages
by Dimitrie O. Paun May 20, 2003

May 20, 2003

On May 19, 2003 06:06 pm, Lozano, Carlos A. wrote: > * Avoid print a no init buffer. What about this instead: Index: dlls/x11drv/xvidmode.c =================================================================== RCS file: /var/cvs/wine/dlls/x11drv/xvidmode.c,v retrieving revision 1.18 diff -u -r1.18 xvidmode.c --- dlls/x11drv/xvidmode.c 22 Apr 2003 00:15:48 -0000 1.18 +++ dlls/x11drv/xvidmode.c 20 May 2003 12:21:47 -0000 @@ -461,7 +461,7 @@ static const char * _CDS_flags(DWORD fields) { BOOL first = TRUE; - char buf[128]; + char buf[128] = ""; char *p = buf; _X_FIELD(CDS,UPDATEREGISTRY);_X_FIELD(CDS,TEST);_X_FIELD(CDS,FULLSCREEN); _X_FIELD(CDS,GLOBAL);_X_FIELD(CDS,SET_PRIMARY);_X_FIELD(CDS,RESET); @@ -471,7 +471,7 @@ static const char * _DM_fields(DWORD fields) { BOOL first = TRUE; - char buf[128]; + char buf[128] = ""; char *p = buf; _X_FIELD(DM,BITSPERPEL);_X_FIELD(DM,PELSWIDTH);_X_FIELD(DM,PELSHEIGHT); _X_FIELD(DM,DISPLAYFLAGS);_X_FIELD(DM,DISPLAYFREQUENCY);_X_FIELD(DM,POSITION); -- Dimi.

1 0