October 2006 - Wine-devel - list.winehq.org

Failing shlfolder test
by Francois Gouget 31 Oct '06

31 Oct '06

Just for information, a week ago or so, the shlfolder has started failing systematically (on a fresh ~/.wine directory as well as after round of tests): ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfolder.c && touch shlfolder.ok shlfolder.c:366: Test failed: CreateDirectoryA failed! Last error: 000000b7 err:shell:HCR_GetFolderAttributes HCR_GetFolderAttributes should be called for simple PIDL's only! Unfortunately I don't have the exact date because I did not keep a history of my nightly test runs (but I do now). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

2 4

Re: [secur32] Remove test that crashes on Win2k
by James Hawkins 31 Oct '06

31 Oct '06

On 10/30/06, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > makes sure the other tests are run. > > Changelog > Remove test that crashes on Win2k > > Cheers, > > Paul. > > --- > dlls/secur32/tests/schannel.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/secur32/tests/schannel.c b/dlls/secur32/tests/schannel.c > index 23e2a0a..95669fe 100644 > --- a/dlls/secur32/tests/schannel.c > +++ b/dlls/secur32/tests/schannel.c > @@ -140,10 +140,12 @@ static void testAcquireSecurityContext(v > NULL); > ok(st == SEC_E_SECPKG_NOT_FOUND, > "Expected SEC_E_SECPKG_NOT_FOUND, got %08x\n", st); > + /* Crashes on Win2K > st = pAcquireCredentialsHandleA(NULL, unisp_name_a, 0, NULL, NULL, NULL, > NULL, NULL, NULL); > ok(st == SEC_E_NO_CREDENTIALS, "Expected SEC_E_NO_CREDENTIALS, got %08x\n", > st); > + */ Please use #if 0/#endif to comment out pieces of code. -- James Hawkins

3 3

uploading files to the wikie
by James Hawkins 30 Oct '06

30 Oct '06

Hey, Do we have the ability to upload files to our Wiki? -- James Hawkins

2 1

REGRESSION: 0.9.24 crashes on regsvr32 msvbvm60.dll, temporary workaround attached
by a_villacis＠palosanto.com 30 Oct '06

30 Oct '06

Somewhere between 0.9.23 and 0.9.24, a commit introduced a bug in oleaut32 which results in a nasty crash when parsing some MSFT typelibs. Notably, regsvr32 msvbvm60.dll" will crash on this bug, although I experienced it with DBGRID32.OCX too. I have traced the point of the crash to typelib.c:1814 if ( pFuncRec->FKCCIC & 0x2000 ) { (*pptfd)->Entry = SysAllocString((WCHAR*)pFuncRec->OptAttr[2]); } Apparently, 0x2000 as a flag in FKCCIC indicates that pFuncRec->OptAttr[2] is a pointer to some string. If what little understanding I have of typelib loading is correct, these typelibs are read from DLL resources on disk. Therefore, I fail to grasp how they can possibly refer to valid memory locations. I have this attached patch that temporarily plugs the crash, but I don't think the code is right in the first place. Or am I missing some crucial fact about typelib parsing? >From compare with version 1.266: if ( pFuncRec->FKCCIC & 0x2000 ) { (*pptfd)->Entry = (WCHAR*) pFuncRec->OptAttr[2] ; } I would dare to say that it has always been wrong, only now is crashing because the code now attempts to strdup() it with SysAllocString. Alex Villacís Lasso

2 1

Checking, if a program is running under WINE
by Gero Zink 30 Oct '06

30 Oct '06

Hi Is there a short way for my windows application to check, if it is running under WINE or under Windows? This should also run in future; no hack. Thanks Gero -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

2 1

Regression in patch wined3d: Implement D3DSIO_MOVA in ARB backend.
by Mirek 30 Oct '06

30 Oct '06

Hi, i just installed latest version of wine and now 3DMark 2003 and Flatout 2 is not working anymore, i look at the patches commited yesterday and found this patch which is causing this regression. Mirek

5 15

Re: [SM-Spell-Submit] Wine release 0.9.24
by David Kowis 29 Oct '06

29 Oct '06

Alexandre Julliard wrote: > This is release 0.9.24 of Wine, a free implementation of Windows on Unix. > > What's new in this release: > - Support for multiple monitors using Xinerama. W00t! Now if I could get it to build in amd64 :( > - Various MSI fixes and improvements. > - A ton of memory leaks fixed. > - Many common controls fixes. > - Lots of bug fixes. > -- David Kowis Cauldron Component Lead SourceMage GNU/Linux -- www.sourcemage.org Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something. - Robert Heinlein

2 1

Re: WGL: add extension checking
by Roderick Colenbrander 29 Oct '06

29 Oct '06

Hi, Today I talked to Stefan and he was worried that adding the WGL extensions to opengl_ext.c would cause unneeded overhead. Though WGL extensions aren't called very frequently. Second the 'glXGetProcAddress' protection isn't needed for WGL extensions as I'm already doing something similar for it in winex11.drv already. I will post an updated version of this patch without the WGL extension in opengl_ext.c soon. Note that my other WGL patch (the one which adjust wglMakeContextCurrentARB) should apply fine, it doesn't depend on this patch. Roderick > Hi, > > This is an updated version of the previous patch. I forgot to attach the > changes to the make_opengl script which created the opengl_ext / opengl_norm > source code. > > Regards, > Roderick Colenbrander > > > > Hi, > > > > This is a part of a patch which I sent before which rewrote our > > wglGetProcAddress code and extension loading code. This patch only > contains the new > > extension loading code. > > > > Before all OpenGL extensions were loaded using glXGetProcAddress. The > > returned function pointers were stored in a table. The function > > wglGetProcAddress then returned a wrapper extension function which > called the stored > > function pointer. > > > > The issue is that glXGetProcAddress isn't guaranteed to return NULL when > > an extension isn't found. This patch makes our extension loading code > more > > reliable by checking whether the extension required by the function is > > really available before calling the display driver to look up a > function. > > > > This change required some small changes to the make_opengl32 script > which > > generates all opengl wrapping code. The table with GL extensions has > been > > extended with an extension name field and WGL extensions have been added > to > > it aswell. Before there was a 'glx_name' field aswell which was used for > an > > Nvidia specific GL extension which added the WGL functions > > wglAllocateMemoryNV / wglFreeMemoryNV. These functions will soon be > handled added to > > winex11.drv as extensions, we won't directly look up the GLX functions > from > > opengl32.dll anymore. > > > > Regards, > > Roderick Colenbrander > > > -- > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! > Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

Re: dbghelp: Cast-qual warnings fix (1 of 2)
by Michael [Plouj] Ploujnikov 28 Oct '06

28 Oct '06

On 10/28/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Changelog: > dbghelp: Cast-qual warnings fix. > > diff -urN a/dlls/dbghelp/path.c b/dlls/dbghelp/path.c > --- a/dlls/dbghelp/path.c 2006-07-13 16:13:33.000000000 +0100 > +++ b/dlls/dbghelp/path.c 2006-10-28 16:06:46.000000000 +0100 > @@ -349,6 +349,7 @@ > struct process* pcs = process_find_by_handle(hProcess); > char tmp[MAX_PATH]; > char* ptr; > + char* buf; > const char* filename; > const char* searchPath = inSearchPath; > > @@ -360,7 +361,6 @@ > if (!searchPath) > { > unsigned len = WideCharToMultiByte(CP_ACP, 0, pcs->search_path, -1, NULL, 0, NULL, NULL); > - char* buf; > > searchPath = buf = HeapAlloc(GetProcessHeap(), 0, len); >From first observation the above line seems to be missing a + before it. > if (!searchPath) return FALSE; > @@ -382,7 +382,7 @@ > { > strcpy(buffer, full_path); > if (searchPath != inSearchPath) > - HeapFree(GetProcessHeap(), 0, (char*)searchPath); > + HeapFree(GetProcessHeap(), 0, buf); > return TRUE; > } > > @@ -404,11 +404,11 @@ > { > strcpy(buffer, tmp); > if (searchPath != inSearchPath) > - HeapFree(GetProcessHeap(), 0, (char*)searchPath); > + HeapFree(GetProcessHeap(), 0, buf); > return TRUE; > } > } > if (searchPath != inSearchPath) > - HeapFree(GetProcessHeap(), 0, (char*)searchPath); > + HeapFree(GetProcessHeap(), 0, buf); > return FALSE; > } > > > -- () ASCII Ribbon Campaign /\ - against HTML mail & vCards

1 1

Re: wined3d: Respect ARB_VERTEX_BUFFER_OBJECT in loadVertexData.
by Stefan Dösinger 28 Oct '06

28 Oct '06

> - GLint curVBO = -1; > + GLint curVBO = GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT) ? -1 : 0; Strange, I thought I sent a patch like that already and it was committed :-/

2 3