August 2016 - Wine-Devel - list.winehq.org

Re: kernel32: Stub CAL_RETURN_GENITIVE_NAMES flag.

by Nikolay Sivov

On 29.08.2016 22:24, David Keijser wrote: > This stops GetCalendarInfoW from reporting unknown caltype when it's > really a case of unsupported flags. > > Signed-off-by: David Keijser <keijser(a)gmail.com> > --- > dlls/kernel32/time.c | 4 +++- > include/winnls.h | 7 ++++--- > 2 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/dlls/kernel32/time.c b/dlls/kernel32/time.c > index b7a7918..e1fd107 100644 > --- a/dlls/kernel32/time.c > +++ b/dlls/kernel32/time.c > @@ -860,6 +860,8 @@ int WINAPI GetCalendarInfoW(LCID Locale, CALID Calendar, CALTYPE CalType, > FIXME("flag CAL_NOUSEROVERRIDE used, not fully implemented\n"); > if (CalType & CAL_USE_CP_ACP) > FIXME("flag CAL_USE_CP_ACP used, not fully implemented\n"); > + if (CalType & CAL_RETURN_GENITIVE_NAMES) > + FIXME("flag CAL_RETURN_GENITIVE_NAMES used, not fully implemented\n"); Hi, David. LOCALE_RETURN_GENITIVE_NAMES itself is implemented, you should pass it to GetLocaleInfo instead of stripping it from caltype. P.S. anyone working on translations please take another look at SMONTHNAME* constants for your language, to make sure genitive forms are there, if applicable. > > if (CalType & CAL_RETURN_NUMBER) { > if (!lpValue) > @@ -878,7 +880,7 @@ int WINAPI GetCalendarInfoW(LCID Locale, CALID Calendar, CALTYPE CalType, > > /* FIXME: No verification is made yet wrt Locale > * for the CALTYPES not requiring GetLocaleInfoA */ > - switch (CalType & ~(CAL_NOUSEROVERRIDE|CAL_RETURN_NUMBER|CAL_USE_CP_ACP)) { > + switch (CalType & ~(CAL_NOUSEROVERRIDE|CAL_RETURN_NUMBER|CAL_USE_CP_ACP|CAL_RETURN_GENITIVE_NAMES)) { > case CAL_ICALINTVALUE: > if (CalType & CAL_RETURN_NUMBER) > return GetLocaleInfoW(Locale, LOCALE_RETURN_NUMBER | LOCALE_ICALENDARTYPE, > diff --git a/include/winnls.h b/include/winnls.h > index 1a7baaf..3d950f6 100644 > --- a/include/winnls.h > +++ b/include/winnls.h > @@ -471,9 +471,10 @@ static const WCHAR LOCALE_NAME_SYSTEM_DEFAULT[] = {'!','s','y','s','-','d','e',' > #define MAX_DEFAULTCHAR 2 > > /* Defines for calendar handling */ > -#define CAL_NOUSEROVERRIDE LOCALE_NOUSEROVERRIDE > -#define CAL_USE_CP_ACP LOCALE_USE_CP_ACP > -#define CAL_RETURN_NUMBER LOCALE_RETURN_NUMBER > +#define CAL_NOUSEROVERRIDE LOCALE_NOUSEROVERRIDE > +#define CAL_USE_CP_ACP LOCALE_USE_CP_ACP > +#define CAL_RETURN_NUMBER LOCALE_RETURN_NUMBER > +#define CAL_RETURN_GENITIVE_NAMES LOCALE_RETURN_GENITIVE_NAMES > > #define CAL_ICALINTVALUE 0x01 > #define CAL_SCALNAME 0x02 >

Aug. 30, 2016

Re: Experimental gcc optimization for 64-bit wine

by Daniel Santos

On 08/29/2016 05:09 AM, André Hentschel wrote: > Am 29.08.2016 um 05:18 schrieb Daniel Santos: >> It's probably also worth mentioning that the ideal long-term solution is to find ways eliminate the register save/restores through various means-- static analysis, better evaluation of branch costs, and other optimizations in Wine its self. For example, there are many WINAPI functions who's only sysv call is to wine_dbg_log() via a TRACE(). Just marking this function as __attribute__((__cold__)) should reduce the number of unneeded register save/restores in the function's main path by a great amount. (I haven't actually tested it yet.) > For others searching for the meaning of this attribute: > >> cold >> The cold attribute on functions is used to inform the compiler that the function is unlikely to be executed. The function is optimized for size rather than speed and on many targets it is placed into a special subsection of the text section so all cold functions appear close together, improving code locality of non-cold parts of program. The paths leading to calls of cold functions within code are marked as unlikely by the branch prediction mechanism. It is thus useful to mark functions used to handle unlikely conditions, such as perror, as cold to improve optimization of hot functions that do call marked functions in rare occasions. >> >> When profile feedback is available, via -fprofile-use, cold functions are automatically detected and this attribute is ignored. > It would be interesting to see some numbers on this, and what it acutally does with the assembler output. I'm leaving for a few days in a couple of hours, otherwise I'd test it Tomorrow I'm leaving for a few weeks, so my project have to wait. However, did a very small test of marking wine_dbg_log() __cold__ on 4.9.3 to no effect as it had already optimized it correctly. I suppose that I could be mistaken about this having stared at so many RTL dumps & assembly when working on a modified gcc, but I think it's still worth examining.

Aug. 29, 2016

Re: [PATCH 5/5] ddraw/tests: Extend TransformVertices invalid data tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25440 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

Aug. 29, 2016

Re: [PATCH 3/5] ddraw: Fix offscreen flag handling in TransformVertices.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25439 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

Aug. 29, 2016

Re: [PATCH 2/5] ddraw: Copy extra vertex data in viewport::TransformVertices.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25438 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

Aug. 29, 2016

Re: [PATCH 1/5] ddraw/tests: Move IDirect3DViewport::TransformVertices tests to ddraw1.c.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25437 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit d3d) === d3d.c:2051: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2235: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2382: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

Aug. 29, 2016

Re: [v2 2/2] winejoystick.drv: Disable joysticks via wine registry on Mac

by Ken Thomases

Hi, On Aug 29, 2016, at 6:03 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > +static void char_device_name_length(IOHIDDeviceRef device, char *name, int max_length) > +{ > + CFStringRef str = copy_device_name(device); > + CFIndex len = CFStringGetLength(str); > + > + if (name) > + name[0] = 0; > + > + if (max_length >= len) > + { > + CFStringGetCString(str,name,max_length,kCFStringEncodingASCII); > + CFRelease(str); > + } > + else > + { > + CFStringRef substr = CFStringCreateWithSubstring(kCFAllocatorDefault, str, CFRangeMake(0, max_length)); > + CFRelease(str); > + CFStringGetCString(substr,name,max_length,kCFStringEncodingASCII); > + CFRelease(substr); > + } > +} I realize you based this function on code from DInput. Unfortunately, that code is pretty badly broken. CFStringGetLength() returns the length of the string in UTF-16 code units, which is basically the same as WCHARs. It's not meaningful to compare that to a buffer size that's in ASCII chars. Using ASCII is wrong, too. If the name has any non-ASCII characters in it, the conversion will just fail. Second, it's potentially unnecessarily restrictive. Your device_disabled_registry() function, by virtue of using the "A" variant RegQueryValueEx(), uses the ANSI code page, not ASCII. The ANSI code page could maybe handle more names than ASCII would. You could get a wide string and then use WideCharToMultiByte() to convert it to CP_ACP, but since you control all of the relevant code, it's just better to work with wide strings throughout. Change your device_disabled_registry() and get_config_key() functions to accept a wide string. Then, you can safely use CFStringGetLength() and CFStringGetCharacters() to acquire the WCHAR-based wide string from the CFString. You can just cast a WCHAR* to a UniChar*. -Ken

Aug. 29, 2016

Re: [v2 1/2] winejoystick.drv: Add functionality to disable joystick via registry

by Ken Thomases

On Aug 29, 2016, at 6:03 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > + get_app_key(&hkey, &appkey); > + > + /* Joystick settings are in the 'joysticks' subkey */ > + if (appkey) > + { > + if (RegOpenKeyA(appkey, joystick_key, &temp)) temp = 0; > + RegCloseKey(appkey); > + appkey = temp; > + } > + if (hkey) > + { > + if (RegOpenKeyA(hkey, joystick_key, &temp)) temp = 0; > + RegCloseKey(hkey); > + hkey = temp; > + } It seems the appending of the Joysticks subkey should be done in get_app_key(). -Ken

Aug. 29, 2016

Re: rpcrt4/tests: Don't load GetUserNameEx dynamically.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25430 Your paranoid android. === w864 (32 bit rpc) === rpc.c:815: Test failed: GUID does not appear to contain a MAC address: {9d7329b2-6dfd-11e6-be78-e71666c2e04a} === w864 (64 bit rpc) === rpc.c:815: Test failed: GUID does not appear to contain a MAC address: {cfff88a2-6dfd-11e6-be78-e71666c2e04a} === w8 (32 bit server) === server.c:1010: Test failed: get_ranged_enum() returned 2000814083 instead of RE3 === w864 (32 bit server) === server.c:1010: Test failed: get_ranged_enum() returned 2009071619 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 2009071619 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 2009071619 instead of RE3 === w864 (64 bit server) === server.c:1010: Test failed: get_ranged_enum() returned 4390915 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 117440515 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 4390915 instead of RE3 === w1064 (64 bit server) === server.c:1010: Test failed: get_ranged_enum() returned 6356995 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 6029315 instead of RE3

Aug. 29, 2016

Re: d3drm/tests: Fix crash when surface can't be created

by Henri Verbeet

On 28 August 2016 at 16:49, André Hentschel <nerv(a)dawncrow.de> wrote: > Should fix crashes like: > https://test.winehq.org/data/a83d5d3b83042d2305de0595c0d03e4e7bf1e29e/xp_wx… > Does this happen on any setups that aren't using "VirtualBox Graphics Adapter" as display driver? I don't think failing the test or skipping is ultimately much more useful than crashing here, but if it's just about skipping cleanly I'd rather just blacklist the driver in a way similar to ddraw_is_warp() in the ddraw tests.

Aug. 29, 2016