Re: Unscientific test: wine is 0 for 3 on under $20 top sellers
Dan Kegel wrote: > I ordered about fifteen titles from Amazon and Half.com > that were under $20 and were on the top 100 sales list. > The first three came today, and sadly, wine from git fails > to install one, and fails to run the other two: > > http://bugs.winehq.org/show_bug.cgi?id=6526 > Typing Instructor for Kids 2 fails to install I could not find an entry in the AppDB for this application. > > http://bugs.winehq.org/show_bug.cgi?id=6527 > Zoombinis Logical Journey version 2 aborts on startup There is an entry for version 1 of this game and it looks like it has the same problem http://appdb.winehq.org/appview.php?iVersionId=5048 http://bugs.winehq.org/show_bug.cgi?id=5403 > > http://bugs.winehq.org/show_bug.cgi?id=6528 > Crazy Machines aborts silently on startup > This one might be in the AppDB but it is unclear which version you tested.[2] It looks like it runs (if it is installed in windows) but the "Mouse always Recentered" bug makes it unplayable. http://appdb.winehq.org/appview.php?iVersionId=4468 http://appdb.winehq.org/appview.php?iVersionId=4473 http://appdb.winehq.org/appview.php?iVersionId=4479 CC:ing the maintainer of these apps... > I guess we have our work cut out for us still... > - Dan > If you won't create an AppDB entry for the other two applications at least tell me what distribution you are using so I can create entries. -- Tony Lambregts
Re: Unscientific test: wine is 0 for 3 on under $20 top sellers
Troy Rollo wrote: > On Thursday 26 October 2006 14:20, Dan Kegel wrote: >> http://bugs.winehq.org/show_bug.cgi?id=6526 >> Typing Instructor for Kids 2 fails to install >> >> http://bugs.winehq.org/show_bug.cgi?id=6527 >> Zoombinis Logical Journey version 2 aborts on startup >> >> http://bugs.winehq.org/show_bug.cgi?id=6528 >> Crazy Machines aborts silently on startup > > Kids games are hugely problematic in Wine - offhand I can't think of one that > has worked. Even if they install they often won't run. Even if they run they > often won't display correctly, or will have input problems. Speaking as a parent, that's a horrid tragedy! Actually, I've done the same sort of survey, but only with my kids games. Historically, Wine has been quite bad, but it's getting better. Lately, for example, the Humongous games have kicked over towards mostly working, and the Knowledge Adventure ones are pretty good. (Of course, that could just be that my kids are outgrowing those, so our copies are really old versions now :-( ). Hopefully once we nail copy protection, Wine can really start to support some games. Cheers, Jeremy
Truetype fonts installed by Wine
I noticed wine-0.9.23 builds 5 fonts, but the only one that gets installed is marlett. Why aren't the other fonts getting installed? Did someone just forget to add them to the makefile?
Re: msi [1/2]: Disable a test until the cabinet files are correctly built
On 10/26/06, James Hawkins <[EMAIL PROTECTED]> 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
Re: Unscientific test: wine is 0 for 3 on under $20 top sellers
On Thursday 26 October 2006 14:20, Dan Kegel wrote: > http://bugs.winehq.org/show_bug.cgi?id=6526 > Typing Instructor for Kids 2 fails to install > > http://bugs.winehq.org/show_bug.cgi?id=6527 > Zoombinis Logical Journey version 2 aborts on startup > > http://bugs.winehq.org/show_bug.cgi?id=6528 > Crazy Machines aborts silently on startup Kids games are hugely problematic in Wine - offhand I can't think of one that has worked. Even if they install they often won't run. Even if they run they often won't display correctly, or will have input problems. -- Troy Rollo - [EMAIL PROTECTED]
Re: Use and "wine/test.h" in test cases for better portabiliy.
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 <[EMAIL PROTECTED]> http://fgouget.free.fr/ La terre est une bêta...
Re: Use and "wine/test.h" in test cases for better portabiliy.
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
Re: Use and "wine/test.h" in test cases for better portabiliy.
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 <[EMAIL PROTECTED]> 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.
Re: Tracking memory allocation
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
Re: Tracking memory allocation
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
Re: Use and "wine/test.h" in test cases for better portabiliy.
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
Re: Use and "wine/test.h" in test cases for better portabiliy.
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 <[EMAIL PROTECTED]> http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95
Re: WGL: wglGetProcAddress
> 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
Re: comctl32: Eliminate an unneeded variable.
Mike McCormack <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
Re: msi: Implement handling for the ErrorDialog and use it to change media
"James Hawkins" <[EMAIL PROTECTED]> writes: > This fixes bug 3236. http://bugs.winehq.org/show_bug.cgi?id=3236 > > Changelog: > * Implement handling for the ErrorDialog and use it to change media. This displays a message box when running the install.c test, which will prevent the tests from running unattended. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH 5/5] quartzdrv: Implement MsgWaitForMultipleObjectsEx and initial Carbon event handling.
Pierre d'Herbemont <[EMAIL PROTECTED]> writes:
> +DWORD remaining_timeout = timeout;
> +DWORD acceptable_timeout;
> +
> +/* We can't remain too long without a carbon call,
> + or the application seems to hang for the user */
> +do {
> +if(remaining_timeout > 50 || remaining_timeout == INFINITE)
> +acceptable_timeout = 50;
> +else
> +acceptable_timeout = remaining_timeout;
> +
> +ret = WaitForMultipleObjectsEx( count, handles, flags &
> MWMO_WAITALL,
> +acceptable_timeout, flags &
> MWMO_ALERTABLE );
I don't think polling is an acceptable way to wait for events. You
really need to get a file descriptor or some other handle that you can
wait on.
--
Alexandre Julliard
[EMAIL PROTECTED]
