January 2009 - Wine-devel - list.winehq.org

AppDB: Rating / Patching
by Björn Krombholz 07 Jan '09

07 Jan '09

Hi, I started a discussion inside AppDB about the in my eyes "strange" Gold rating of Fallout 3 (it's actually just an example, other entries suffer the same problems). I know there was a discussion about the rating on this list last month, but as far as I could see my particular issue wasn't covered and I only just subscribed. So here goes a new thread. The appdb thread [1] is included below (prevent OT-cleanup deletion inside appdb). I don't expect anyone to read it completely, but I didn't want to repeat every argument again either. ;) The basic point is: Fallout 3 (a game) only works with a small -- but nevertheless -- patch, otherwise it will crash, no matter what dll-overrides/settings/3rd-party apps. >From how I understand the wording in [2], an app that requires a patch to run, can't get a gold rating. In fact, if there is no way to get it working in a vanilla wine release, then there is no other option than "Garbage" IMO. The various arguments for that assumption (possible breaking of other apps run by the same wine installation, regression tracking, etc.) are in the quote below. The maintainer tried to convince me that a gold rating is valid, because Fallout 3 works great with the patch applied. Well obviously he failed, and the discussion went away from Fallout in particular to a more general interpretation of [2]. I'm neither saying I'm right and he's wrong, nor the other way around. IMO both interpretation can be valid, depending on how you read "some DLL overrides, other settings or third party software." My suggestion now would be: * Clarify the wording on what "other settings" really means (my interpretation is mainly registry modifications with winecfg and/or regedit). * Add an explicit statement about patched wine versions. Something like: - Any application that requires a patched wine to run MUST NOT be rated higher than "Garbage" (or whatever rating was intended for this situation). [1] http://appdb.winehq.org/objectManager.php?sClass=version&iId=14322#Comment-… [2] http://appdb.winehq.org/help/?sTopic=maintainer_ratings Björn ==== Copy from AppDB discussion [1] below ==== Björn Krombholz on Monday January 5th 2009, 10:10: Hi, I don't understand the recent ratings. I've played the game a lot under Windows and with various versions of wine, using all kinds of different tweaks and settings the game itself and wine offer. It runs pretty well and it's become even better (meaning faster) since 1.11 (no evidence, could be caused by a driver update as well). Nevertheless, as far as I can see, noone has ever managed to get past menu + the loading screen without at least applying the D3D patch attached to [1], that allows setting the VideoDescription and VideoDriver in the registry. For flawless mouse interaction, you also need the mouse hack from [2]. Considering these 2 as a fact (please correct me, if there actually is a way to run it without patches), how can it ever be rated higher than "Garbage"? My understanding of the ratings are, that they offer a quick hint on what you are able to run (nearly) without problems, while the discussion and howto sections deal with "broken" stuff and tell a user, how he might be able to run an app/game despite the garbage state. [1] http://bugs.winehq.org/show_bug.cgi?id=15839 [2] http://bugs.winehq.org/show_bug.cgi?id=6971 ----- RE: Rating / Patching by Tymoteusz Paul on Monday January 5th 2009, 10:20 Let me explain you how ranking system works, because you seem to have it confused. As expalined in http://appdb.winehq.org/help/?sTopic=maintainer_ratings gold/silver rating is ok as long as you can use it for it's purpose. All you have to do is override couple dlls and settings and then the game is working pretty much flawlessy. Garbage rating would be then if it was impossible to play the game. Ratings as is provide good info about the game, if you see that its rated as gold - then you are safe to buy it for linux playig, it may take some work to get it work but it will work and will be playable. Only rating that fits your description "hint on what you are able to run (nearly) without problems" fits platinum rating, which this game didn't get so far. Hope this will be more clear for you now. ----- RE: Rating / Patching by Björn Krombholz on Monday January 5th 2009, 14:08 I was referring to this help text as well, although I read it differently. ;) In any vanilla/clean release version of wine, Fallout 3 won't run. You get the menu, can change settings, but when you start the game to play ("purpose it was designed") it crashes, even "with some DLL overrides, other settings or third party software" you install in wine. => Garbage rating. Let's imagine the small driver patch in bug 15839 was applied to the development tree and so released with 1.1.13. The game would become playable with one major "issue". No matter what settings you change/etc. the mouse is either always stuck in the middle of the screen or it gets stuck at the screen edges (bug 9671). => Bronze rating for wine >= 1.1.13. Maybe even Silver, as it might work very well with a different kind of controller like a gamepad. Now the mouse bug gets fixed in 1.1.x. Suddenly all you need to do is to override some (actually just one) dlls and tweak some settings to make it enjoyable. => Silver (in case you consider Live functionality an important part of the program) or Gold rating. Eventually someone adds the d3dx9_38.dll to wine and the DeviceDriver + DeviceDescription settings will be automatically detected by wine. That means the game works flawlessly without touching any wine setting. => Platinum rating. IMO this makes sense, otherwise a version 1.1.x gold app, wouldn't be downgradable in its rating for 1.1.x+1 (in case version x+1 introduced a regression that breaks this app); because all you had to do to make it work again is unapply the faulty patch. In addition to that, users wouldn't be encouraged to file a bug report if there is source-patch that upgrades it to gold anyway. Anyway, I don't care much about which interpretation should be used, I just want it to be more consistent. As you can see in the reports history Fallout 3 people rated in both ways. E.g., the newest one voting gold, because it works great after patching according to the HOWTO; http://appdb.winehq.org/objectManager.php?sClass=version&iId=14322&iTesting… rating "Garbage" because "Mouse is borked and gameplay is impossible without patches. Which would be the best way to ask for a more indisputable explanation on the help page? Filing a bug report against appdb or using the "Email Us" link at the right, or ...? ----- RE: Rating / Patching by Radosław Ciechowski on Monday January 5th 2009, 15:15 Gold is for apps that "Works flawlessly with DLL overrides, third party software or other settings" so if Fallout 3 is working without bugs after applaying patches, dll-s and other settings it should be rated Gold. If there was no way to get it working or there were lots of bugs after all tweaks, then it could be rated Garbage. If game works flawlessly then no matter how mamy things you have to do, it can be rated Gold which makes sense for me. There is no sense in rating apps Garbage when they can work flawlessly ! Also there is already rating system which we are using ( http://appdb.winehq.org/help/?sTopic=maintainer_ratings ) and changing it now wouldnt be a good idea. ----- RE: Rating / Patching by Björn Krombholz on Monday January 5th 2009, 15:55 > Gold is for apps that "Works flawlessly with DLL overrides, third party software or other settings" < Indeed, that's what I'm saying. But applying a patch to the wine source and recompiling it -- which effectively makes it some _different_ version than the _release_ version you are supposed to rate -- is neither of those 3. - "DLL override": installing a custom DLL into $WINEPREFIX and adding the override) - "third party software": installing additional software into $WINEPREFIX that is needed and expected by the app you want to run - "other settings": tweak the wine registry and similar configuration None of these change the wine version, any such change would still be a "wine 1.1.x", while patches like the mouse patch might even break other software even if those are installed in a different $WINEPREFIX, because the binary changed and it's behaviour is different from the official release. You can't say "A is running well on wine 1.1.x", if in fact it is running well on wine 1.1.x+patch, while it actually breaks on wine 1.1.x. And yes, as I already said, there is a help page for the rating system. I don't ask to change, but to clarify it, as at the moment people are rating differently depending on their interpretation. This has become OT on this page - I will try to move it to the -devel list. :)

8 12

Re: PR 16828 dlls/ntdll/serial.c clear IEXTEN when clearing ICANON
by Austin English 06 Jan '09

06 Jan '09

On Tue, Jan 6, 2009 at 12:49 PM, G. Paul Ziemba <p-wine-bugs(a)ziemba.us> wrote: > FreeBSD fix for Nirvis CDJ application, PR 16828 > > > --- dlls/ntdll/serial.c.orig 2008-12-20 06:55:38.000000000 -0800 > +++ dlls/ntdll/serial.c 2009-01-05 21:35:47.000000000 -0800 > @@ -648,7 +648,9 @@ > port.c_cflag &= ~(HUPCL); > port.c_cflag |= CLOCAL | CREAD; > > - port.c_lflag &= ~(ICANON|ECHO|ISIG); > + // on FreeBSD, turning off ICANON does not disable IEXTEN, > + // so we must turn it off explicitly. No harm done on Linux. > + port.c_lflag &= ~(ICANON|ECHO|ISIG|IEXTEN); > port.c_lflag |= NOFLSH; > > bytesize = slc->WordLength; > > > -- > G. Paul Ziemba > FreeBSD unix: > 10:46AM up 12 days, 21:25, 10 users, load averages: 0.21, 0.29, 0.23 > > > Again, no C++ comments. -- -Austin

2 2

Re: PR 16592: dlls/kernel32/volume.c
by Austin English 06 Jan '09

06 Jan '09

On Tue, Jan 6, 2009 at 12:25 PM, G. Paul Ziemba <p-wine-bugs(a)ziemba.us> wrote: > Fix for PR 16592, GetVolumeInformationW() handling of unusual "root" > parameter. > > > --- dlls/kernel32/volume.c.orig 2008-12-05 08:57:45.000000000 -0800 > +++ dlls/kernel32/volume.c 2008-12-22 00:15:51.000000000 -0800 > @@ -518,7 +518,7 @@ > HANDLE handle; > enum fs_type type = FS_UNKNOWN; > > - if (!root) > + if (!root || (root && root[0] == '\\' && root[1] == ':')) > { > WCHAR path[MAX_PATH]; > GetCurrentDirectoryW( MAX_PATH, path ); > > > > --- dlls/kernel32/tests/volume.c.orig 2008-12-05 08:57:45.000000000 -0800 > +++ dlls/kernel32/tests/volume.c 2009-01-06 09:52:19.000000000 -0800 > @@ -29,6 +29,9 @@ > static BOOL (WINAPI *pFindVolumeClose)(HANDLE); > static UINT (WINAPI *pGetLogicalDriveStringsA)(UINT,LPSTR); > static UINT (WINAPI *pGetLogicalDriveStringsW)(UINT,LPWSTR); > +static BOOL (WINAPI *pGetVolumeInformationW)(LPCWSTR,LPWSTR,DWORD, > + DWORD*,DWORD*,DWORD*,LPWSTR,DWORD); > +static BOOL (WINAPI *pSetCurrentDirectoryA)(LPCSTR); > > /* ############################### */ > > @@ -216,6 +219,48 @@ > HeapFree(GetProcessHeap(), 0, buf); > } > > +static void test_GetVolumeInformationW(void) > +{ > + // > + // Check handling of root == "\\:" > + // http://bugs.winehq.org/show_bug.cgi?id=16592 > + // > + > + BOOL rc; > + WCHAR root[] = {'\\',':',0}; > + > + if (!pGetVolumeInformationW) { > + win_skip("GetVolumeInformationW not available\n"); > + return; > + } > + > + if (!pSetCurrentDirectoryA) { > + win_skip("SetCurrentDirectoryA not available\n"); > + return; > + } > + > + // > + // set current directory because GetVolumeInformationW refers > + // to it in this test case > + // > + rc = pSetCurrentDirectoryA("C:\\"); > + > + ok(rc, "SetCurrentDirectoryA(\"C:\\\\\") failed\n"); > + > + rc = pGetVolumeInformationW( > + root, // Root > + NULL, // pLabel > + 0, // LabelLen > + NULL, // pSerial > + NULL, // pFilenameLen > + NULL, // pFlags > + NULL, // pFsname > + 0 // FsnameLen > + ); > + > + ok(rc, "GetVolumeInformationW doesn't handle root == \"\\\\:\" case\n"); > +} > + > START_TEST(volume) > { > hdll = GetModuleHandleA("kernel32.dll"); > @@ -226,6 +271,8 @@ > pFindVolumeClose = (void *) GetProcAddress(hdll, "FindVolumeClose"); > pGetLogicalDriveStringsA = (void *) GetProcAddress(hdll, "GetLogicalDriveStringsA"); > pGetLogicalDriveStringsW = (void *) GetProcAddress(hdll, "GetLogicalDriveStringsW"); > + pGetVolumeInformationW = (void *) GetProcAddress(hdll, "GetVolumeInformationW"); > + pSetCurrentDirectoryA = (void *) GetProcAddress(hdll, "SetCurrentDirectoryA"); > > test_query_dos_deviceA(); > test_FindFirstVolume(); > @@ -233,4 +280,5 @@ > test_GetVolumeNameForVolumeMountPointW(); > test_GetLogicalDriveStringsA(); > test_GetLogicalDriveStringsW(); > + test_GetVolumeInformationW(); > } > > -- > G. Paul Ziemba > FreeBSD unix: > 10:11AM up 12 days, 20:50, 10 users, load averages: 0.16, 0.18, 0.19 > > > Please, no C++ comments in wine, use standard C /* comments */ instead. -- -Austin

1 0

Packagers: consider not packaging wine-1.1.12, or cherrypicking fixes
by Dan Kegel 06 Jan '09

06 Jan '09

wine-1.1.12 has a couple regressions in it: http://bugs.winehq.org/show_bug.cgi?id=16754 http://bugs.winehq.org/show_bug.cgi?id=16732 http://bugs.winehq.org/show_bug.cgi?id=16708 Please consider either cherrypicking the fixes, or skipping wine-1.1.12.

3 2

Re: wined3d: Fix a memory leak in compile_state_table()
by Rico Schüller 06 Jan '09

06 Jan '09

Allan Tong schrieb: > Wrong pointer was being passed to HeapFree. > > - Allan > > Why did you remove these two lines? Was this your intention? - dev_multistate_funcs[cur[i].state][0] = multistate_funcs[cur[i].state][0]; - dev_multistate_funcs[cur[i].state][1] = multistate_funcs[cur[i].state][1]; Cheers Rico

3 2

Re: [shell32/tests 1/2] ILFree() is only exported by ordinal on Win9x
by Rob Shearman 06 Jan '09

06 Jan '09

2009/1/6 Paul Vriens <paul.vriens.wine(a)gmail.com>: > Hi, > > For some reason this only shows up when I use my own cross compiled tests. > > Changelog > ILFree() is only exported by ordinal on Win9x ILFree is exported using -noname in Wine, so it should be imported by ordinal. You need to investigate further as to why it isn't working for you. I suggest to start by running "winedump dump -j import shell32_crosstest.exe". -- Rob Shearman

3 3

Unused function in winhttp
by Francois Gouget 06 Jan '09

06 Jan '09

Hi, In the following commit you added the netconn_set_timeout() function to net.c. However today it is unused. Is there any plan to use it? Is it still relevant? commit 266c4b2c046b334ca44cdc1826c4434625dcb29f Author: Hans Leidekker <hans(a)codeweavers.com> Date: Tue Aug 26 11:03:19 2008 +0200 winhttp: Add networking infrastructure. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

2 1

Updated wine64 page
by Dan Kegel 06 Jan '09

06 Jan '09

I updated http://wiki.winehq.org/Wine64 to no longer recommend pulling from Maarten's tree, since doing so made the instructions more complex, and the main tree does just about as good at passing conformance tests (maybe modulo a hang or two). - Dan

1 0

Re: wow32: add -noname property to WOWGetDescriptor spec
by Alistair Leslie-Hughes 06 Jan '09

06 Jan '09

Hi, > diff --git a/dlls/wow32/wow32.spec b/dlls/wow32/wow32.spec > index 227120b..4d2d6d1 100644 > --- a/dlls/wow32/wow32.spec > +++ b/dlls/wow32/wow32.spec > @@ -1,5 +1,5 @@ > # ordinal exports > -1 stdcall WOWGetDescriptor(long long) > +1 stdcall -nonanme WOWGetDescriptor(long long) spelling mistake. Best Regards Alistair Leslie-Hughes _________________________________________________________________ Net yourself a bargain. Find great deals on eBay. http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Frover%2Eebay%2Ecom%2Frover%…

1 0

Re: oleaut32: Only dump the EMF if tracing fixmes for the ole channel.
by Vincent Povirk 05 Jan '09

05 Jan '09

> + if (FIXME_ON(ole)) > + { > + FIXME("Unknown magic %04x, %d read bytes:\n",magic,xread); > + hr=E_FAIL; This changes the behavior of the call based on what debug channels are enabled. I don't think you want to do that.

1 0