November 2009 - Wine-Devel - list.winehq.org

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.

by Bruno Haible

Hi, As the author of the support for GNU gettext in MacOS X [1], I can explain the relation between the POSIX notion of locale and the MacOS X user preferences. POSIX:2008 [2] says: "All implementations shall define a locale as the default locale, to be invoked when no environment variables are set, or set to the empty string. This default locale can be the POSIX locale or any other implementation- defined locale. Some implementations may provide facilities for local installation administrators to set the default locale, customizing it for each location. POSIX.1-2008 does not require such a facility." This means that a POSIX compliant program has to do the following steps in order to determine the locale for a certain category of settings. 1) Inspect the LC_ALL environment variable. If it is set and non-empty, use its value. 2) Otherwise: Inspect the LC_xxxx environment variable that matches the specific category. If it is set and non-empty, use its value. 3) Otherwise: Inspect the LANG environment variable. If it is set and non-empty, use its value. 4) Otherwise: Use the default locale. On MacOS X systems, this means to use user preferences that can be retrieved using the CFLocaleCopyCurrent, CFPreferencesCopyAppValue functions. Note that these settings are similar but not entirely equal to Unix (glibc) conventions (e.g. "zh-Hans" vs. "zh_CN"), therefore some mapping of names has to be done. This algorithm is used in all programs that rely on GNU gettext and works perfectly fine: - By default, no LANG or LC_* environment variable is set, hence the programs obey the user settings. - For users of Terminal.app, who set these environment variables, the programs obey the environment variables. Ken Thomases wrote: > Mac OS X's Language & Text (formerly known as International) settings in > System Preferences don't quite map exactly to Unix LANG or LC_* environment > variables, which are a poor intermediary for mapping to Windows settings. I agree that if you want to map from MacOS X locale names from CF* functions to Win32 locale names, you may want to do so without going through Unix (glibc) conventional names. > One problem with trusting the LANG variable is that its UNIX semantics are > as a fallback for the LC_* variables, not an override. Given that the user > has selected a language and formats in System Preferences, that's like > setting all of the various LC_* variables, so LANG should be ignored. No. If a program ignores LANG while it is set, it is not POSIX compliant, and a user will wonder why it behaves differently than all the POSIX compliant programs on his system. > Allowing LANG to override the user's preference settings would make Wine > behave badly when run from Terminal.app if the user's preferred language > and formats don't match (e.g. Japanese language, U.S. formats). 1. This is a rare case: Normally users run Terminal.app without setting LANG. 2. If they do set LANG, POSIX requires the program to obey LANG. > If Wine were to rely on LANG, then all users with mismatched language and > formats who launch it from Terminal would not get their preferred language. This would be compliant with POSIX, and with what GNU gettext does for years. No one ever complained about it. > If you as a user want to override the language that Wine displays, you can > set LC_MESSAGES in your environment rather than LANG. Setting LC_ALL would > achieve that, plus override the various other locale categories. Set LANG > is the wrong approach, in my opinion. According to POSIX, if a user sets LC_ALL=foo it is equivalent to unset LC_ALL; LC_CTYPE=foo LC_MESSAGES=foo LC_NUMERIC=foo LC_TIME=foo ... and equivalent to unset LC_ALL LC_CTYPE LC_MESSAGES LC_NUMERIC LC_TIME ...; LANG=foo Every program should treat these three ways to set the locale in the same way. If Wine was to behave differently in the second case than in the third case (by ignoring the LANG setting in the third case, as you propose), it would be buggy. Bruno [1] http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-runtime/… [2] http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html

Nov. 30, 2009

Re: [PATCH] [Server]: when getting the status of an exception, ensure the debugger continue information is not erased when releasing objects

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > what happens is something like: > process P being debugged by D > - while processing a debug event (fetched in P, P calls > ntdll(a)send_debug_event, and waits for the debugger to process the > event) > - D gets the event, and the user asks for quit in D. D sends back to > wineserver a DBG_CONTINUE response to the event > - D then dies before P runs again > - P then calls server(a)get_exception_status, where when getting the > status from the debugger, (which should be DBG_CONTINUE, and it is > before releasing the debug event). but while releasing the debug > event, someone clears the status, and we get 0 from the > get_exception_status event > > I didn't check in details which clear_error() is to blame in server, > but close_thread_desktop (from a cursory look) could be to blame That one probably shouldn't clear the error, but I don't see how you'd get there by releasing an event. Do you have a backtrace? -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2009

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.

by Gert van den Berg

On Mon, Nov 30, 2009 at 22:01, Ken Thomases <ken(a)codeweavers.com> wrote: > On Nov 30, 2009, at 4:35 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: >> 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?? > POSIX specs: http://www.opengroup.org/onlinepubs/007908799/xbd/envvar.html#tag_002_002 Short version: Order of checking: LC_ALL LC_whatever LANG Not sure how Wine's registry integration is implemented... I would think that the most compatible (with the host *nix environment) way would be: Check saved locale variable values, if none was changed from last run, use current registry settings. If any was changed in a way that would affect behavior, rerun relevant parts below logic. (e.g. do not rerun if LC_ALL stayed the same, since that override EVERYTHING). If variable affecting locale code was not changed, change only the relevant settings. If LC_ALL is defined, set locale code from that, else set it from LANG default to Windows default locale. Fill in defaults for locale. If LC_ALL was not used above, go through LC_whatever and overwrite settings in registry according to that. This leaves settings at defaults (preferably Windows defaults) for language if only $LANG is set. It uses the Unix settings if they are set, for consistency with the host OS and allow the settings to be changed as for Unix apps. Saving the values and comparing it, also allows the user to change the settings, and not loose it each time Wine starts. On my OS X 10.6, (Set to English, South African currency / numbers (Which is actually correctly uses a decimal comma, unlike Ubuntu / Windows)) LC_ALL is blank, LANG is blank LC_CTYPE is UTF-8 (affecting toupper, etc according to POSIX page), all others are "C". Following above logic, this would result in US English settings everywhere. (Not sure if Apple might be modifying the behavior of localized output functions to match settings, even if C is set, need to test). ( http://images.apple.com/macosx/technology/docs/L416017A_UNIX_TB_FF.pdf might help if OS X specific overwrites are needed. IMHO, it should try replicating the OS X preferences (setting each registry setting according to (potentially custom) settings in OS X after setting locale code according to language and country), with a way to overwrite. (LC_ALL would by my preferred method, since it has the highest precedence in POSIX). This should then result in the following locale logic: Saved Wine settings (if nothing changed) > LC_ALL > OS specific > LC_* > LANG > C. As far as I can tell, this should result in a configuration that mimics the host OS, unless specifically overwritten. Some settings might not be easy to map to the Wine version, and if no setting Wine setting exist, a warning should be printed (e.g. if Windows uses locale code rather than a separate setting for something POSIX has a separate variable, a warning should be printed if the POSIX settings would result in different behavior than configurable from Windows) In addition, if any settings exist in Wine that can not by set by LC_whatever, it should be easy to edit the Wine value from Winecfg / Wine control panel. (If an OS specific method allows it to be overwritten, it may be left out on those OSes) Gert

Nov. 30, 2009

Re: [PATCH] [Server]: when getting the status of an exception, ensure the debugger continue information is not erased when releasing objects

by Eric Pouech

Alexandre Julliard a écrit : > Eric Pouech <eric.pouech(a)orange.fr> writes: > > >> diff --git a/server/debugger.c b/server/debugger.c >> index 795a24a..4458a3b 100644 >> --- a/server/debugger.c >> +++ b/server/debugger.c >> @@ -677,6 +677,8 @@ DECL_HANDLER(get_exception_status) >> if ((event = (struct debug_event *)get_handle_obj( current->process, req->handle, >> 0, &debug_event_ops ))) >> { >> + NTSTATUS status = STATUS_PENDING; >> + >> close_handle( current->process, req->handle ); >> if (event->state == EVENT_CONTINUED) >> { >> @@ -686,10 +688,10 @@ DECL_HANDLER(get_exception_status) >> set_reply_data( &event->context, size ); >> current->context = NULL; >> } >> - set_error( event->status ); >> + status = event->status; >> } >> - else set_error( STATUS_PENDING ); >> release_object( event ); >> + set_error( status ); >> > > Releasing an object should never change the error code. Where do you see > that happening? > > what happens is something like: process P being debugged by D - while processing a debug event (fetched in P, P calls ntdll(a)send_debug_event, and waits for the debugger to process the event) - D gets the event, and the user asks for quit in D. D sends back to wineserver a DBG_CONTINUE response to the event - D then dies before P runs again - P then calls server(a)get_exception_status, where when getting the status from the debugger, (which should be DBG_CONTINUE, and it is before releasing the debug event). but while releasing the debug event, someone clears the status, and we get 0 from the get_exception_status event I didn't check in details which clear_error() is to blame in server, but close_thread_desktop (from a cursory look) could be to blame A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Nov. 30, 2009

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.

by Ken Thomases

On Nov 30, 2009, at 4:35 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > 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. That logic is exactly backwards, in my opinion. Terminal.app is setting LANG as a backstop. It's a fallback, not an override. It's what should be used by programs which aren't Mac-aware. The fact that Terminal sets LANG by default suggests that we shouldn't use it as an override, because it can't express the full range of user preferences as specified in System Preferences. It will therefore produce results in Wine different from what the user has chosen for their system. We specifically want to require that the user specify a variable _not_ set by Terminal by default if they want to override the settings in System Preferences. > 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?? glibc is one implementation of the C standard libraries. Mac OS X does not use glibc, but provides its own implementation of the C libraries in libSystem. It follows the same general precedence rules for these environment variables, though. For example, see the locale(1) man page. > 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. One should set the LC_* variable or variables that make sense for what one is trying to achieve. If one wants all categories of locale information to be overridden, one should set LC_ALL. If one only wants to change the language of displayed messages, one should set LC_MESSAGES. > 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. You say you see no override and then you say LANG should override the desktop settings. That's exactly the override that I'm talking about and recommending against. LANG should not override the desktop settings. It should not override anything, ever, anywhere. It should be a fallback when nothing else has been specified. I deem the settings in System Preferences to be roughly on par, in terms of precedence and user intention, as setting the individual LC_* variables (other than LC_ALL). If a Wine user wishes to override the System Preferences settings, they should set the appropriate LC_* variables or possibly LC_ALL to override them all. >> 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. The problem is that it produces results counter to what the user said they prefer in a number of cases. One case is where the user language differs from the region. Another is if the region is customized (i.e. it's not one of the presets). > 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. Any program targeting Mac OS X should strive to do the right Mac-specific thing, not some generic Unix thing. That most don't is no excuse for Wine not to. > 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. You're right that it does not, but we disagree about which direction it should go. I think that Wine should not set LANG if it's unset. I think it should set each of the LC_xyz variables based on the System Preferences settings, if it is not set. As I've said repeatedly, I consider the System Preferences settings as analogous to LC_xyz in intent. Therefore I think they should be treated analogously in precedence. (Actually, I don't think that Wine should use any of these environment variables, because they don't properly transmit the full range of settings possible in System Preferences. I think that Wine should directly translate the System Preferences settings into the proper behavior as far as a Windows program would see. For example, System Preferences offers many languages and regions for which there are no /usr/share/locale definition files. And, as already mentioned, the user may customize the formats in ways which can't be expressed via LANG/LC_*. If we went this route, we would still have to figure out some good way to allow for a temporary override.) >> (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)? We (CodeWeavers) get reports from users who have a different preferred language set from the formats region. Different users have different reasons for setting things that way. Some may be traveling. Others have business reasons for it (they speak/write one language, but need to work with numbers and dates formatted for some other region where they do business). Etc. It doesn't much matter why they might be set that way. What matters is that Wine should behave according to their expressed preferences. > Terminal.app sets LANG to US which you believe is wrong? It's at least insufficient for us to rely on. As I say, the LANG/LC_* variables are insufficient, alone or in combination, to transmit the user's preferences. > 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). It should be "obeyed" only as a fallback if no other information were available. That is its defined role. Other (indeed, better) information is, in fact, available. That better information should be used in preference to LANG. If you wish to override the System Preferences settings, use LC_ALL. That's what Linux users should be using, too. Because if a Linux user has LC_* variables set in their everyday, default environment but wants to test Wine as though in another locale, then setting LANG is insufficient. Setting LANG to get Wine to behave differently is just wrong. -Ken

Nov. 30, 2009

RE: Introducing WineTestBot

by Greg Geldorp

Hi Jörg > >So the next step will be to allow you > >to upload the git diff instead of a Windows executable. > > Step 3.5 suggestion: split that in two steps, allow us to > upload the patch and download the .exe. > > >so it's probably not all that useful to > >run sound and DirectDraw tests on them. > > Then we can take the .exe to machines with sound and DD/DX > to complete the impact analysis. Great suggestion, thanks. I'll make that a part of step 2 :-). Greg.

Nov. 30, 2009

Re: [PATCH 1/3] ole32: Add test for CoLockObjectExternal with fLastUnlockReleases as FALSE.

by Paul Vriens

On 11/23/2009 04:07 PM, Rob Shearman wrote: > --- > dlls/ole32/tests/marshal.c | 38 +++++++++++++++++++++++++++++++++++++- > 1 files changed, 37 insertions(+), 1 deletions(-) > > Tested on XP. > Hi Rob, http://test.winehq.org/data/tests/ole32:marshal.html doesn't look too healthy. Not sure if this is the actual one as there were a few that touched marshal.c. Could you have a look? -- Cheers, Paul.

Nov. 30, 2009

Introducing WineTestBot

by Joerg-Cyril.Hoehle＠t-systems.com

Greg, Congratulations, that's a great service. >I know that programmers like to be as lazy as possible. >So the next step will be to allow you >to upload the git diff instead of a Windows executable. The next most wanted improvement! Step 3.5 suggestion: split that in two steps, allow us to upload the patch and download the .exe. >so it's probably not all that useful to >run sound and DirectDraw tests on them. Then we can take the .exe to machines with sound and DD/DX to complete the impact analysis. Regards, Jörg Höhle.

Nov. 30, 2009

Re: services.exe: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible (try 2)

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > Oh, I see it now. > > This means that currently the old strings are leaked if the new strings > provided are NULL. No, they remain unchanged in that case. -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2009

Re: Fedora users, please test mci patch about time-out/hanging machine

by Michael Stefaniuc

Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Michael, >>> So the cause of random mci time-out on test.winehq may as >> well lay elsewhere. >> Like in PulseAudio? That may well be. PA in F11 made sound be more >> broken in Wine. > Is that your own experience or other people's reports? My own from running winetest.exe; some of the dsound tests are failing now which they didn't with F10. But according to Maarten the sound in Wine is to be blamed for that. > My experience with PA in Ubuntu Intrepid -- it's not the newest Ubuntu > at all -- is that it has been stable for several month now, to a point > where I regularly forget to run "pactl exit" to stop it every time I > log into Gnome as I did half a year ago. I don't have high requirements on sound, only youtube and xine/mplayer and those just work. That's what squelched my desire to remove PA. > Lastly, Wine has performed equally well in a PA, ALSA or OSS setting AFAICT. > It's long ago that PA caused known bugs such as stuttering (in Hardy and > Intrepid); they must have been fixed by a combination of changes in > Wine and perhaps Ubuntu updates(?). > Of course, YMMV. Well, I don't use Wine ;) bye michael

Nov. 30, 2009