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

Re: Wine performance improvement
by 임은지 09 Dec '09

09 Dec '09

Dan Kegel wrote: > > > Interesting! Clearly a long ways off from production-ready, but > it's fun to see somebody trying this. > > A few notes: > > Please clean up the patch a bit to remove lines like this: > +//FIXME("handle : %ld \n", handle); > and extra files like > dlls/ws2_32/tests/test.sh > > Please avoid hand-editing > include/wine/server_protocol.h > The start of the file even says: > * This file is automatically generated; DO NO EDIT! > * Edit server/protocol.def instead and re-run tools/make_requests > > Please switch to plain text for future posts. It's very > hard to read in the archive; see > http://www.winehq.org/pipermail/wine-devel/2009-December/080394.html > > Please identify the author(s) of the new code for copyright purposes, > and ensure they agree to licensing their code under the LGPL (for Wine) > and GPL (for Linux kernel). > > I'm sure other people will have more to say. > Thank you for your comments. I will cleanup the patch as you suggested and send it.

3 2

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
by Ken Thomases 09 Dec '09

09 Dec '09

The call to setenv() has 0 (false) as its third parameter, so that LANG is not overwritten. -Ken On Nov 23, 2009, at 9:12 AM, Charles Davis wrote: > --- > dlls/kernel32/locale.c | 53 > +++++++++++++++++++++++++---------------------- > 1 files changed, 28 insertions(+), 25 deletions(-) > > > > diff --git a/dlls/kernel32/locale.c b/dlls/kernel32/locale.c > index fb9b517..d9ea8eb 100644 > --- a/dlls/kernel32/locale.c > +++ b/dlls/kernel32/locale.c > @@ -2925,32 +2925,35 @@ void LOCALE_Init(void) > UINT ansi_cp = 1252, oem_cp = 437, mac_cp = 10000, unix_cp; > > #ifdef __APPLE__ > - /* MacOS doesn't set the locale environment variables so we have to do it ourselves */ > - CFArrayRef preferred_locales, all_locales; > CFStringRef user_language_string_ref = NULL; > - char user_locale[50]; > - char* p; > - > - CFLocaleRef user_locale_ref = CFLocaleCopyCurrent(); > - CFStringRef user_locale_string_ref = CFLocaleGetIdentifier( user_locale_ref ); > - > - CFStringGetCString( user_locale_string_ref, user_locale, sizeof(user_locale), kCFStringEncodingUTF8 ); > - CFRelease( user_locale_ref ); > - /* Strip modifiers because setlocale() can't parse them. */ > - if ((p = strchr( user_locale, '@' ))) *p = 0; > - if (!strchr( user_locale, '.' )) strcat( user_locale, ".UTF-8" ); > - unix_cp = CP_UTF8; /* default to utf-8 even if we don't get a valid locale */ > - setenv( "LANG", user_locale, 0 ); > - TRACE( "setting locale to '%s'\n", user_locale ); > - > - /* We still want to set the retrieve the preferred language as chosen in > - System Preferences.app, because it can differ from CFLocaleCopyCurrent(). > - */ > - all_locales = CFLocaleCopyAvailableLocaleIdentifiers(); > - preferred_locales = CFBundleCopyLocalizationsForPreferences( all_locales, NULL ); > - if (preferred_locales && CFArrayGetCount( preferred_locales )) > - user_language_string_ref = CFArrayGetValueAtIndex( preferred_locales, 0 ); > - CFRelease( all_locales ); > + if (!getenv( "LANG" )) > + { > + /* MacOS doesn't set the locale environment variables so we have to do it ourselves */ > + CFArrayRef preferred_locales, all_locales; > + char user_locale[50]; > + char* p; > + > + CFLocaleRef user_locale_ref = CFLocaleCopyCurrent(); > + CFStringRef user_locale_string_ref = CFLocaleGetIdentifier( user_locale_ref ); > + > + CFStringGetCString( user_locale_string_ref, user_locale, sizeof(user_locale), kCFStringEncodingUTF8 ); > + CFRelease( user_locale_ref ); > + /* Strip modifiers because setlocale() can't parse them. */ > + if ((p = strchr( user_locale, '@' ))) *p = 0; > + if (!strchr( user_locale, '.' )) strcat( user_locale, ".UTF-8" ); > + unix_cp = CP_UTF8; /* default to utf-8 even if we don't get a valid locale */ > + setenv( "LANG", user_locale, 0 ); > + TRACE( "setting locale to '%s'\n", user_locale ); > + > + /* We still want to set the retrieve the preferred language as chosen in > + System Preferences.app, because it can differ from CFLocaleCopyCurrent(). > + */ > + all_locales = CFLocaleCopyAvailableLocaleIdentifiers(); > + preferred_locales = CFBundleCopyLocalizationsForPreferences( all_locales, NULL ); > + if (preferred_locales && CFArrayGetCount( preferred_locales )) > + user_language_string_ref = CFArrayGetValueAtIndex( preferred_locales, 0 ); > + CFRelease( all_locales ); > + } > #endif /* __APPLE__ */ > > setlocale( LC_ALL, "" ); > > >

7 19

Regression on Tuesday Dec 8
by Susan Cragin 09 Dec '09

09 Dec '09

I was installing Dragon NaturallySpeaking on Tuesday with git and noticed that it was very slow to load. In addition, the "automatic" registration doesn't work as well as it used to. The link to the Scansoft site, to generate the code, does not work. Regression test? Sigh.

1 0

Re: [1/5] ole32: Change the base IStorage filename to a pointer type.
by Paul Vriens 09 Dec '09

09 Dec '09

On 12/07/2009 10:17 PM, Vincent Povirk wrote: > + /* Stat always returns the full path, even for files opened with a relative path. */ > + GetCurrentDirectoryW(MAX_PATH, prev_dir); > + > + GetTempPathW(MAX_PATH, temp); > + > + SetCurrentDirectoryW(temp); > + > + GetFullPathNameW(filename, MAX_PATH, full_path,&rel_path); > + > + r = StgCreateDocfile( rel_path, STGM_CREATE | STGM_SHARE_EXCLUSIVE | > + STGM_READWRITE |STGM_TRANSACTED, 0,&stg); Hi Vincent, These tests currently crash on Win9x/WinME due . I rewrote that test to just use A-functions but there are loads of lstrcmpW tests that of course always fail on Win9x (not implemented). Do you think it's worthwhile changing these tests to cope with Win9x/WinMe? -- Cheers, Paul.

2 2

Re: libs/wine: don't try to read() a directory
by Alexandre Julliard 09 Dec '09

09 Dec '09

Dan Kegel <dank(a)kegel.com> writes: > Fixes http://bugs.winehq.org/show_bug.cgi?id=20942 Introducing an fd leak to fix a Valgrind warning is not much of an improvement ;-) -- Alexandre Julliard julliard(a)winehq.org

2 1

[PATCH] kernel32: Respect the LANG environment variable on Mac OS.
by Joerg-Cyril.Hoehle＠t-systems.com 09 Dec '09

09 Dec '09

Hi, perhaps I should contribute to this thread given that I indirectly triggered it via bug #20377. IMHO Wine, due to its sandbox nature, needs a way to switch language/locale independently on the desktop settings. Much like gcompris allows to choose a language other than the desktop's. No discussion, the default should be the desktop setting. So here, and in bug #20377, the issue is not the default setting. The issue is how to depart from the default. Now use LANG or LC_xyz to switch? The MacOS Terminal.app (as of 10.5.8) sets/shows very few environment variables. LANG is among them, none of LC_xyz is. Therefore I argue that LANG= is the canonical and reasonable choice for a local override on MacOS. It has the additional benefit of being + what Linux users are typically told to use (quick Google survey); + what the Wine Wiki recommends in http://wiki.winehq.org/TestingLanguages What's the relationship between LC_xyz and LANG? The official answer for programs using glibc is: "the library will test the environment variables LC_ALL, LC_CTYPE, and LANG in that order" But is glibc actually used on MacOS?? The Unicode FAQ says http://www.cl.cam.ac.uk/~mgk25/unicode.html "The LANG environment variable is used to set the default locale for all categories, but the LC_* variables can be used to override individual categories." So I don't understand the isolated recommendation of using LC_MESSAGES in this thread. My use-case is how to mimick a French, or Dutch, or Turkish, or any Asian MS-Windows environment, without switching my desktop to any of these (the "sandbox" idea again). LC_MESSAGES is not enough AFAIK. Ken Thomases writes: >I see no upside at all to changing LANG into an override where that's >not how it functions in any other context. I see no override involved here. On my Mac OSX 10.5.8 which is pretty much a base install, no LC_xyz is set. Therefore LANG does not override any LC_xyz setting. All I ask about LANG is that it overrides the desktop settings. If any LC_xyz were set, I expect them to take priority over LANG, like is documented and quoted above for glib and has been done for years in Linux. >Terminal (at least, recent versions) has a setting in its preferences >to set the locale environment variables in shells it creates. However, >it really only sets LANG according to the Region selected on the Formats >tab. It does not set individual LC_* variables. It completely ignores >the user's preferred language. I fail to see the problem. Only LANG is set, no LC_xyz therefore all UNIX apps launched within Terminal.app (or at least the glibc-based ones) should give a consistent answer, dictated by the LC_xyz/LANG defaulting rules. Should the next Apple update have Terminal.app set LC_xyz instead of LANG, I'd expect wine to obey them, because they take precedence over LANG. So actually, my wish is that Wine follows the LC_ALL/LC_xyz/LANG defaulting rules. Currently it does not. (I still need to check back on the Mac whether Wine follows LC_xyz). >(e.g. Japanese language, U.S. formats) Ken, is the use-case that you have in mind a Japanese user traveling to the U.S. (Jap. language, U.S. region/format)? Terminal.app sets LANG to US which you believe is wrong? My issue is not whether Terminal.app is broken or not. My issue is that if LANG is set, it should be obeyed, so the user gets consistent results (from a UNIX environment point of view). Regards, Jörg Höhle

4 5

Re: [PATCH 1/7] dsound: Implement DSPROPERTY_WaveDeviceMappingA on top of *W
by Alexandre Julliard 09 Dec '09

09 Dec '09

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > + data.DataFlow = ppd->DataFlow; > + len = strlen(ppd->DeviceName)+1; > + data.DeviceName = HeapAlloc(GetProcessHeap(), 0, len); > + if (!data.DeviceName) > + return E_OUTOFMEMORY; > + MultiByteToWideChar(CP_ACP, 0, ppd->DeviceName, -1, data.DeviceName, len ); The W length handling is broken. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 1/2] dsound: Only initialize 1 guid for capture and renderer
by Alexandre Julliard 09 Dec '09

09 Dec '09

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > @@ -355,8 +357,8 @@ HRESULT WINAPI DirectSoundEnumerateW( > if (devs > 0) { > if (GetDeviceID(&DSDEVID_DefaultPlayback, &guid) == DS_OK) { > static const WCHAR empty[] = { 0 }; > - for (wod = 0; wod < devs; ++wod) { > - if (IsEqualGUID( &guid, &DSOUND_renderer_guids[wod] ) ) { > + wod = guid.Data4[7]; > + if (wod < devs) { { Now that's an interesting indentation style... -- Alexandre Julliard julliard(a)winehq.org

2 1

Cruft left behind by tests
by Greg Geldorp 09 Dec '09

09 Dec '09

Hi Dmitry, During WineConf we briefly discussed files/registry keys left behind by running winetest.exe on Windows machines. I promised to look at that and then promptly forgot about it. Anyway, this is the list of files that get left behind when running the tests on a WinXP machine: C:\CustomMsi (hidden directory, empty) %Local AppData%\DCBC2A71-70D8-4DAN-EHR8-E0D61DEA3FDF.ini (new file, not really a .ini file, contains binary data) %SystemRoot%\Debug\UserMode\userenv.log (updated) %SystemRoot%\inf\test.PNF (new) %SystemRoot%\Installer\3a964.msi (plus 4 other .msi files) %SystemSystem%\d3d8caps.dat (new) %SystemSystem%\d3d9caps.dat (new) %SystemSystem%\test.PNF (new) %SystemSystem%\CatRoot\{C689AABA-8E78-11D0-8C47-00C04FC295EE}\TimeStamp (plus 2 other GUID-named directories below CatRoot) IE Cookies and History files get updated, some files get added to the IE cache And the registry keys: HKCU\Software\Microsoft\ActiveMovie\devenum\{083863F1-70DE-11D0-BD40-00A0C911CE86}\{8DE0E022-0111-43BA-9227-175BA62326EC} HKCU\Software\Microsoft\ActiveMovie\devenum\{4EFE2452-168A-11D1-BC76-00C04FB9453B}\Default MidiOut Device HKCU\Software\Microsoft\ActiveMovie\devenum\{E0F158E1-CB04-11D0-BD4E-00A0C911CE86}\Default DirectSound Device HKCU\Software\Microsoft\Direct3D\MostRecentApplication HKCU\Software\Microsoft\DirectInput\MostRecentApplication HKCU\Software\Microsoft\Installer\Products\D37A124635D9F784DAFD3ACC0AC92055 HKCU\Software\Microsoft\Multimedia\msacm.imaadpcm HKCU\Software\Microsoft\Multimedia\msacm.msgsm610 HKCU\Software\Microsoft\Multimedia\ActiveMovie HKCU\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Cached HKCU\Software\Microsoft\Windows Script\Settings HKCU\Software\Wine HKCR\Applications\shell32_test.exe HKCR\CLSID\{178fc163-f585-4e24-9c13-4bb7faf80646} HKCR\Installer\Products\D37A124635D9F784DAFD3ACC0AC92055 HKCR\Interface\{8CC497C0-A1DF-11CE-8098-00AA0047BE5D} HKCR\Interface\{8CC497C1-A1DF-11CE-8098-00AA0047BE5D} HKCR\Interface\{8CC497C2-A1DF-11CE-8098-00AA0047BE5D} HKCR\Interface\{8CC497C3-A1DF-11CE-8098-00AA0047BE5D} HKCR\Interface\{8CC497C4-A1DF-11CE-8098-00AA0047BE5D} HKCR\Interface\{8CC497C5-A1DF-11CE-8098-00AA0047BE5D} HKCR\TestScript HKCR\TypeLib\{00020430-0000-0000-C000-000000000046}\1.0\FLAGS HKCR\TypeLib\{8CC497C9-A1DF-11CE-8098-00AA0047BE5D} HKCR\Wine.Test HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllIsMyFileType HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 1\CertDllOpenStoreProv HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 1\CertDllOpenStoreProv\DEFAULT HKLM\SOFTWARE\Microsoft\Direct3D\MostRecentApplication HKLM\SOFTWARE\Microsoft\DirectDraw\MostRecentApplication HKLM\SOFTWARE\Microsoft\DownloadManager HKLM\SOFTWARE\Microsoft\ESENT\Process\iphlpapi_test HKLM\SOFTWARE\Microsoft\RFC1156Agent HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Managed\S-1-5-21-606747145-1604221776-839522115-1003\Installer\Products\D37A124635D9F784DAFD3ACC0AC92055 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\803D6B87EA8012A4EAA3ED9844C59F21 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21-606747145-1604221776-839522115-1003\Products\C589F146D32331C48B665A7F3C562E47 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MCD HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ICM\RegisteredProfiles HKLM\SYSTEM\LastKnownGoodRecovery\LastGood HKLM\SYSTEM\CurrentControlSet\Control\Session Manager HKLM\SYSTEM\CurrentControlSet\Control\StillImage\Debug\wiadss.dll HKLM\SYSTEM\CurrentControlSet\Enum\USB\BOGUS HKLM\SYSTEM\CurrentControlSet\Services\BITS HKLM\SYSTEM\CurrentControlSet\Services\TestService HKU\.DEFAULT\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Ge.

2 2

Re: wineserver: Use existing file permissions as base for applying ACLs, change mapping logic
by Alexandre Julliard 09 Dec '09

09 Dec '09

Paul Chitescu <paulc(a)voip.null.ro> writes: > Changelog: > wineserver: Use existing file permissions as base for applying ACLs, change > mapping logic. > > ACLs are applied over existing permissions. An ACCESS_ALLOWED_ACE by itself > will never reduce permissions. This doesn't make sense to me. A security descriptor with ACCESS_ALLOWED entries can still result in permissions being reduced. -- Alexandre Julliard julliard(a)winehq.org

1 0