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

Re: msi [1/2]: Disable a test until the cabinet files are correctly built

by James Hawkins

On 10/26/06, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > We get a popup in Windows too because we don't build the cabs. > > Changelog: > * Disable a test until the cabinet files are correctly built. > Ignore these two patches. I'm going to send a better implementation of the error dialog that respects the UI level so we won't have to change the tests. -- James Hawkins

Oct. 26, 2006

Re: Use <windows.h> and "wine/test.h" in test cases for better portabiliy.

by Francois Gouget

On Thu, 26 Oct 2006, Detlef Riekenberg wrote: [...] > What do you think about adding something like that? > > #ifndef A_CONST_FROM_THE_NEWEST_HEADER > #error To build this code, an updated SDK from MS is needed. > #endif If we put it only in the tests that really need the latest headers, and we can test for exactly what we need, then we could do something like that. Another alternative would be to use the #ifndef to disable the relevant sections of code. But I'm not sure it's worth it. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...

Oct. 26, 2006

Re: Use <windows.h> and "wine/test.h" in test cases for better portabiliy.

by Detlef Riekenberg

On Do, 2006-10-26 at 17:05 +0200, Francois Gouget wrote: > Also note that it's important to use the very latest SDK headers when > compiling the Wine tests. A number of them won't compile with the stock > VC6 headers. It seems, that you are familar with SDK / VC6. Waht do you think about adding something like that? #ifndef A_CONST_FROM_THE_NEWEST_HEADER #error To build this code, an updated SDK from MS is needed. #endif Possible reaction from Joe User: "failed to compile -> there code is buggy" against "They told me, that an update is needed. Great Code." -- By by ... Detlef

Oct. 26, 2006

Re: Use <windows.h> and "wine/test.h" in test cases for better portabiliy.

by Francois Gouget

On Thu, 26 Oct 2006, Mike McCormack wrote: > > Francois Gouget wrote: > > > Including each header manually surely is not normal practice on Windows, but > > the nice thing is that it lets us detect bugs in our header dependencies. If > > we just include windows.h we will completely miss those and thus reduces the > > value of the test. > > These tests don't compile in MSVC 6 without this fix. Precisely. And this is very useful information! The right fix is to: * fix the Wine headers so these tests fail to compile with Wine exactly the same way they fail to compile with the Windows headers. This is the only way to make sure this problem won't come back later. * then add the missing include directives or fix their order so the tests compile both with the Windows headers and the Wine ones. I have started to look at why some of these tests were not compiling on Windows and this is how I stumbled on the COM_NO_WINDOWS_H issue which has side-tracked me a bit. I know of issues in, at least, advpub.h and objbase.h. I hope to get back to them soon, but there's certainly room for someone else to fix them in the meantime. Also note that it's important to use the very latest SDK headers when compiling the Wine tests. A number of them won't compile with the stock VC6 headers. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

Oct. 26, 2006

Re: Tracking memory allocation

by Robert Shearman

Jeff L wrote: > Robert Shearman wrote: > >> Jeff L wrote: >> >>> It seems that this would not be a unique problem in wine, is there a >>> standard way to handle memory tracking so that if memory is freed, >>> at a later time we can check to see if the pointer is still valid? >> >> >> It sounds like you could benefit from using the handle table >> functions in ntdll. >> > Looks promising. There don't appear to be examples of how to use the > functions. I assume that I declare memory to be of type > RTL_HANDLE_TABLE and call RtlInitializeHandleTable to initialise it. > Then there is a call to RtlpAllocateSomeHandles to get the space for > the handles. After this RtlAllocateHandle gets a handle off the free > list and RtlFreeHandle to release the handle. > > How do you access the memory pointed to by the handle? I was thinking > that I would need to stash the address I am managing into the handle. > It looks like I can do that with the RTL_HANDLE pointer retuned by > RtlAllocateHandle but from then on it does not look like I can get the > address of the handle as RtlIsValidHandle etc do not return it. Yes, it does. You can look at dlls/ntdll/tests/rtl.c to see how the functions can be used. > If I run out of handles, how do I reallocate the table or add to it? You can't. It is intended to be a fixed size table. > Are the functions thread safe if I anchor the handletable off a static > variable in the dll? I am going to need a persistent table for the > life of the dll. Hence it has the potential to be used by multiple > threads. No. You need to protect the accessing of the handle table and handles with a critical section. -- Rob Shearman

Oct. 26, 2006

Re: Tracking memory allocation

by Jeff L

Robert Shearman wrote: > Jeff L wrote: > >> It seems that this would not be a unique problem in wine, is there a >> standard way to handle memory tracking so that if memory is freed, at >> a later time we can check to see if the pointer is still valid? > > > It sounds like you could benefit from using the handle table functions > in ntdll. > Looks promising. There don't appear to be examples of how to use the functions. I assume that I declare memory to be of type RTL_HANDLE_TABLE and call RtlInitializeHandleTable to initialise it. Then there is a call to RtlpAllocateSomeHandles to get the space for the handles. After this RtlAllocateHandle gets a handle off the free list and RtlFreeHandle to release the handle. How do you access the memory pointed to by the handle? I was thinking that I would need to stash the address I am managing into the handle. It looks like I can do that with the RTL_HANDLE pointer retuned by RtlAllocateHandle but from then on it does not look like I can get the address of the handle as RtlIsValidHandle etc do not return it. If I run out of handles, how do I reallocate the table or add to it? Are the functions thread safe if I anchor the handletable off a static variable in the dll? I am going to need a persistent table for the life of the dll. Hence it has the potential to be used by multiple threads. Jeff Latimer

Oct. 26, 2006

Re: Use <windows.h> and "wine/test.h" in test cases for better portabiliy.

by Mike McCormack

Francois Gouget wrote: > Including each header manually surely is not normal practice on Windows, > but the nice thing is that it lets us detect bugs in our header > dependencies. If we just include windows.h we will completely miss those > and thus reduces the value of the test. These tests don't compile in MSVC 6 without this fix. Mike

Oct. 26, 2006

Re: Use <windows.h> and "wine/test.h" in test cases for better portabiliy.

by Francois Gouget

I think this patch should not be applied. Including each header manually surely is not normal practice on Windows, but the nice thing is that it lets us detect bugs in our header dependencies. If we just include windows.h we will completely miss those and thus reduces the value of the test. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

Oct. 26, 2006

Re: WGL: wglGetProcAddress

by Roderick Colenbrander

> Hi Roderick, > > > This patch reimplements opengl32's wglGetProcAddress. The endresult is > > a more reliable function which doesn't directly call X functions. > > I have tested this patch against current GIT and still i dont get any of > my games running. one thing i tried - as i assumed maybe there is a > circular dependency - was commenting out the call of > > dlls/opengl32/wgl.c - void internal_glGetIntegerv: > wine_wgl.p_wglGetIntegerv(pname, params); There's no circular dependency. The function internal_glGetIntegerv uses a function wglGetIntegerv from the display driver. The display driver in the end uses glGetIntegerv but it doesn't link against opengl32. > > and then at least racer [1] seem to work. yet the folloing games crash > quite in the beginning. > > - IL2 Sturmovik/Pacific Fighters > - NASCAR 2003 (GTP Mod) > - Grand Prix Legends > - Operation Hellfile (Wintersonne) Demo [2] > > I have applied your patch and did a make clean to have not to bother > with ignored dependencies and did after the make install a removal of > the opengl32.dll in the win-dir and a wineprefixcreate. have i missed > anything? i tested against nvidia drivers 87XX and 9626 and d3d apps and > native opengl apps are running fine. Could you also try some other demos like Warcraft3 it is one of the demos I tested. Regards, Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Oct. 26, 2006

Re: comctl32: Eliminate an unneeded variable.

by Alexandre Julliard

Mike McCormack <mike(a)codeweavers.com> writes: > @@ -2560,7 +2560,7 @@ ImageList_SetImageCount (HIMAGELIST himl > { > HDC hdcBitmap; > HBITMAP hbmNewBitmap; > - INT nNewCount, nCopyCount; > + INT nCopyCount; It seems to me the variable is needed to ensure that the bitmap and count remain in sync if allocating the new bitmap fails. -- Alexandre Julliard julliard(a)winehq.org

Oct. 26, 2006