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

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

by Paul Chitescu

On Monday 30 November 2009 05:51:35 pm Alexandre Julliard wrote: > Paul Chitescu <paulc(a)voip.null.ro> writes: > > > @@ -569,11 +569,11 @@ DWORD svcctl_ChangeServiceConfigW( > > new_entry.config.lpDisplayName = strdupW(lpDisplayName); > > } > > > > - *service->service_entry = new_entry; > > - save_service_config(service->service_entry); > > + err = save_service_config(&new_entry); > > + if (ERROR_SUCCESS == err) *service->service_entry = new_entry; > > service_unlock(service->service_entry); > > This can't work, the strings have been freed already. > > -- > Alexandre Julliard > julliard(a)winehq.org Oh, I see it now. This means that currently the old strings are leaked if the new strings provided are NULL. I'll write a replacement that will free the all the strings of either old entry or new entry at the end (depending if save_service_config succeeds or not).

Nov. 30, 2009

today's git broke winetricks gecko :-(

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

Jacek Caban wrote: >You should understand, that we don't want users to have problems due to >*lack* of Gecko. Fair enough. > Instead you just said that >you pollute winetest results with your bad configuration. Are you being rude or what? I've not been polluting anything. I've -- quite simply -- used for years a (seemingly) perfectly reasonable and supported[*] configuration, namely a Wine without Gecko. Austin English too has provided "ae-nogecko" test data for ages. [*] "you can avoid problems" in WineGecko is not at all the same as "It is highly recommended that you install Gecko in order to avoid mysterious failures even with applications that do not seem to have anything to do at all with HTML. That's not how Windows works." Well, as I said earlier, my next Mac testdata will use Gecko. I'd appreciate if the WineGecko page could be augmented with a recommendation about how to add Gecko to an existing .wine. I'm used to rm .wine/.update-timestamp wine winecfg Is that fine? 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: > @@ -569,11 +569,11 @@ DWORD svcctl_ChangeServiceConfigW( > new_entry.config.lpDisplayName = strdupW(lpDisplayName); > } > > - *service->service_entry = new_entry; > - save_service_config(service->service_entry); > + err = save_service_config(&new_entry); > + if (ERROR_SUCCESS == err) *service->service_entry = new_entry; > service_unlock(service->service_entry); This can't work, the strings have been freed already. -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2009

Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > In the filesystem we use as backend for Registry all we can tell is if we can > write to it or not so in the end one bit is all that's relevant (except if > it's completely unreadable when wine should abort). > > No matter what an user does it cannot change that. We don't want a wine > service running as root trying to replicate Windows access rights on the > native system, do we? Yes, the right approach to multiuser is to have wineserver and system processes run as root, and normal processes run as different users. -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2009

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

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

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 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. 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. One issue remains in Intrepid: Because Timidity was not modified for PulseAudio[*], it grabs the ALSA device when it starts, causing all subsequent PA clients to loose access to sound. So it is still advisable to issue "pactl exit" to let Wine (and Timidity) share ALSA well. Regards, Jörg Höhle [*] or because PA was badly integrated? Why should every sound using package be modified when something like PA jumps into a distribution?!?

Nov. 30, 2009

Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)

by Paul Chitescu

On Monday 30 November 2009 05:16:34 pm Paul Chitescu wrote: > On Monday 30 November 2009 04:02:03 pm you wrote: > > Paul Chitescu <paulc(a)voip.null.ro> writes: > > > > > Changelog: > > > wineserver: Added support for read/only Registry, similar to > > > unprivileged users > > > > > > Rationale: > > > This is a first step towards implementing shared wine prefixes > with > > > most users being unprivileged and a single Administrator (power user, > etc.) > > > capable of installing programs. > > > > I don't think it's a step in the right direction. What you need is > > proper access control with security descriptors, like we have for other > > objects. A single read-only bit cannot be extended to support this. > > > > -- > > Alexandre Julliard > > julliard(a)winehq.org > > > In the filesystem we use as backend for Registry all we can tell is if we can > write to it or not so in the end one bit is all that's relevant (except if > it's completely unreadable when wine should abort). > > No matter what an user does it cannot change that. We don't want a wine > service running as root trying to replicate Windows access rights on the > native system, do we? > > ACLs would require at least some mapping between wine users and native system > users. And anyway, even SYSTEM or NT AUTHORITY would be unable to write to > Registry if it's read only so that one bit should suffice. > > > Paul I should add that we can emulate the behavior of a non-admin user by including it in the Administrators group only if it can open for writing HKLM\Software or similar. This will make programs happier even if they still can't write to the Registry.

Nov. 30, 2009

Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)

by Paul Chitescu

On Monday 30 November 2009 04:02:03 pm you wrote: > Paul Chitescu <paulc(a)voip.null.ro> writes: > > > Changelog: > > wineserver: Added support for read/only Registry, similar to > > unprivileged users > > > > Rationale: > > This is a first step towards implementing shared wine prefixes with > > most users being unprivileged and a single Administrator (power user, etc.) > > capable of installing programs. > > I don't think it's a step in the right direction. What you need is > proper access control with security descriptors, like we have for other > objects. A single read-only bit cannot be extended to support this. > > -- > Alexandre Julliard > julliard(a)winehq.org In the filesystem we use as backend for Registry all we can tell is if we can write to it or not so in the end one bit is all that's relevant (except if it's completely unreadable when wine should abort). No matter what an user does it cannot change that. We don't want a wine service running as root trying to replicate Windows access rights on the native system, do we? ACLs would require at least some mapping between wine users and native system users. And anyway, even SYSTEM or NT AUTHORITY would be unable to write to Registry if it's read only so that one bit should suffice. Paul

Nov. 30, 2009

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control

by Nikolay Sivov

Ilya Shpigor wrote: >> Or course you can, format a string every time contents change and store >> it with SetWindowText(). WM_GETTEXT >> will work through default procedure (I've done it that way for IPAddress >> control). >> > > This is good idea, but SetWindowText just send the WM_SETTEXT message. Your > patch "comctl32/datetime: Block WM_SETTEXT message" don't allow to do it. > Ah, forgot about it, sorry. Now I think your way is good enough, maybe WM_SETTEXT is still forwarded to default procedure and WM_GETTEXT not, I don't know. >> Anyway GetWindowText should work, and Wine's implementation uses >> WM_GETTEXT only for same process windows, >> so you shouldn't override default handling for this message. >> > > This possible to test: is the datetime window procedure process WM_GETTEXT? > This message must be send to control directly and be processed through > CallWindowProc with DefWindowProc parameter. Is this test give right results? > It's possible but such test will tell nothing, WM_GETTEXT definitely works for this control class and returns current content. Blocked WM_SETTEXT makes me think that WM_GETTEXT is overridden as you've done. To test that you could subclass control, catch WM_GETTEXT in subclass proc and forward it to default procedure directly bypassing control handling. If it returns nothing or some creation time passed text then your patch is ok. All of that comes to be extra testing not related to directly visible control behavior, treat this as additional checks.

Nov. 30, 2009

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control

by Ilya Shpigor

> Or course you can, format a string every time contents change and store > it with SetWindowText(). WM_GETTEXT > will work through default procedure (I've done it that way for IPAddress > control). This is good idea, but SetWindowText just send the WM_SETTEXT message. Your patch "comctl32/datetime: Block WM_SETTEXT message" don't allow to do it. > Anyway GetWindowText should work, and Wine's implementation uses > WM_GETTEXT only for same process windows, > so you shouldn't override default handling for this message. This possible to test: is the datetime window procedure process WM_GETTEXT? This message must be send to control directly and be processed through CallWindowProc with DefWindowProc parameter. Is this test give right results? > P.S. Also don't forget comments regarding tests part. The second try of test have been send. -- Best regards, Ilya Shpigor.

Nov. 30, 2009

Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > Changelog: > wineserver: Added support for read/only Registry, similar to > unprivileged users > > Rationale: > This is a first step towards implementing shared wine prefixes with > most users being unprivileged and a single Administrator (power user, etc.) > capable of installing programs. I don't think it's a step in the right direction. What you need is proper access control with security descriptors, like we have for other objects. A single read-only bit cannot be extended to support this. -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2009

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control

by Nikolay Sivov

Ilya Shpigor wrote: > > GetWindowText work with the server side text buffer. Are you offer to use it? > I don't sure that control text and this kind of window text are same things. > Hmm, I'm not sure. Looks like setting text always goes to server call, maybe it's the same thing (synced somewhere?)... Anyway GetWindowText should work, and Wine's implementation uses WM_GETTEXT only for same process windows, so you shouldn't override default handling for this message. > Datetime control have own interpretation of data in the self text buffers. > Using window text will need some synchronization when this data change. Can I > do it? > Or course you can, format a string every time contents change and store it with SetWindowText(). WM_GETTEXT will work through default procedure (I've done it that way for IPAddress control). P.S. Also don't forget comments regarding tests part. Thanks.

Nov. 30, 2009

Re: mciqtz32: Fix open/close omissions.

by Dmitry Timoshkov

You need to provide more information why is this change required, and what is the problem you are trying to fix. -- Dmitry.

Nov. 30, 2009

Re: Implement a stub for PrintWindow in user32

by Dmitry Timoshkov

"Luke Benstead" <kazade(a)gmail.com> wrote: > +/************************************************************************ > + * PrintWindow (USER32.@) > + * > + */ > +BOOL WINAPI PrintWindow(HWND hwnd, HDC hdcBlt, UINT nFlags) > +{ > + return TRUE; > +} If this is a stub, it should not return TRUE, should print a FIXME, and probably set an appropriate last error. Besides, MSDN has a nice hint how to implement this API properly. -- Dmitry.

Nov. 30, 2009

Re: wine.inf: Remove obsolete and duplicate entries.

by Paul Vriens

On 11/30/2009 02:08 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Dear reviewers, > > Vitaliy Margolen wrote in the discussion of bug #20693: >> Those entries shouldn't be in the wine.inf in the first place >> (as Alexandre already said). If anything they should be removed >>from there to lessen the confusion. > > Here is a patch to remove those entries. Note that > I'm not familiar enough with the printing system or MS-Windows' > expected vital entries to judge whether the entries should be present > as default fallbacks on systems compiled without cups, > or which have no printer, > or because some apps on MS-Windows crash if they are not present > even when there's no printer > or whatever reason. I just trust your word. > > All I can see is that these entries about [HKLM\HARDWARE] do not make > it into system.reg on my Linux machine even though they are present in > wine.inf, I suppose because the dynamic device detection code > (hal/dbus) removes them (with no printer nor cups-dev installed). > > Regards, > Jörg Höhle > Hi Jörg, This was already (partly) done in commit d19e2ada9ce2d52d8b09e984fe5b12803bf6d4ca. -- Cheers, Paul.

Nov. 30, 2009

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control

by Ilya Shpigor

Hi, Thanks for reply. > I don't think it's a right way. You probably should use window text > instead updating it on every change, > see how GetWindowText is implemented. GetWindowText work with the server side text buffer. Are you offer to use it? I don't sure that control text and this kind of window text are same things. Datetime control have own interpretation of data in the self text buffers. Using window text will need some synchronization when this data change. Can I do it? -- Best regards, Ilya Shpigor.

Nov. 30, 2009

Re: mciavi: Simplify play loop.

by Paul Vriens

On 11/30/2009 01:51 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > in the future, MCIAVI will hopefully be able to drive the loop > with either audio or video turned on or off individually > (setaudio/setvideo off), like native (e.g. mciavi can play > the audio tracks only). > Here's a first step towards unification. > > Regards, > Jörg Höhle > Tabs and space mixtures here as well. -- Cheers, Paul.

Nov. 30, 2009

Re: mciqtz32: Fix open/close omissions.

by Paul Vriens

On 11/30/2009 01:47 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Regards, > Jörg Höhle > Hi Jörg, You're mixing tabs and spaces here. -- Cheers, Paul.

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: > 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? -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2009

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

by Dmitry Timoshkov

<Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > perhaps I should contribute to this thread given that I > indirectly triggered it via bug #20377. > > IMHO Wine, due to its sandbox nature ... There is no such a nature of Wine. -- Dmitry.

Nov. 30, 2009

RE: Introducing WineTestBot

by Greg Geldorp

Hi Andrew, > From: Andrew Fenn > > This sounds great, one question though. Is there a way to contribute > to your cloud so that members of the community could grow your windows > vm testing army? Interesting idea, it's not something I considered when designing this. The bot currently depends on a VMware specific API. That API, VIX, supports VMware vSphere (ESX), VMware Workstation and VMware Server. I believe Workstation can be controlled only locally, but vSphere and Server are network-capable. So it wouldn't be a big deal to add support for remote vSphere and Server VMs (btw, Server is free as in beer). Other VMs like VirtualBox would take more work to support. If anyone is serious about contributing VMs please contact me and we'll see how to integrate them. Ge.

Nov. 30, 2009

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

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

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

Nov. 30, 2009

Re: [1/3] WineD3D: Infrastructure to render swapchains to a FBO

by Henri Verbeet

2009/11/30 Stefan Dösinger <stefandoesinger(a)gmx.at>: >> I think this will break color_fill_fbo > I'll investigate that, but I think if it did it would break the d3d9 tests if I force rendering to the FBO - which I did for testing. > I'm not sure we have a lot of tests for color fill. I actually have that somewhere on my todo list, but it's way down.

Nov. 30, 2009

Re: Introducing WineTestBot

by Andrew Fenn

This sounds great, one question though. Is there a way to contribute to your cloud so that members of the community could grow your windows vm testing army? On Mon, Nov 30, 2009 at 4:05 PM, Greg Geldorp <ggeldorp(a)vmware.com> wrote: > Or, for those who like to be buzzword compliant, the Wine Testing Cloud > Service. > > Inspired by all the talk about testing during WineConf 2009, I set out to fill > a gap in Wine testing. Most of the Wine developers don't have access to a > battery of Windows machines to run the tests they write/modify on. As a result, > there are quite a few regressions in the tests themselves. The WineTestBot > provides a whole bunch of Windows machines, ready to accept and run your > modified tests. In its current state you can submit Windows executables (most > likely cross-compiled on a Linux box) to the bot, which will run it in VMs of > your choice. > > So, how does this work in practice? First, go to > https://winetestbot.geldorp.nl and click on "Register" to register an account. > Once your account is approved (you'll receive a notification via email) you > can log in. After log in, the menu in the sidebar changes to include an item > "Submit job". This allows you to upload an .exe from your local system to the > bot. You can pick the VMs (Windows versions) you want to run the test on. From > the "Home" page you can see the status of your job, by clicking on the job id > you get a bit more info about the progress. Once the test is completed, the > stdout generated by the test is retrieved from each VM and made available via > that web page. > > The tests are run on VMware ESX VMs, so it's probably not all that useful to > run sound and DirectDraw tests on them. Also, no Win9x VMs are available. > I haven't set up 64-bit VMs yet, but those should be easy to add. Before each > test run, the VMs are reset to a clean snapshot, so no cruft from old tests > will be left around. Your test shouldn't take more than 5 minutes, which is > more than the WineTest framework allows anyway. > > For each Windows version, there is a "base" VM and there can be additional > VMs too. The idea is that the base VM is running the most up-to-date and > most often used variation of that Windows version, so running your test on > the base VMs should give you a good indication on how the test behaves. > Additionally, you can run your tests on the other variations too. So, for > example for XP the base VM is XP Professional SP3, but there are additional > VMs like SP2, Media Center Edition, and a non-English version available too. > Obviously, even when you use all available VMs you'll cover a very small > subset of all possible configurations (most notably you won't test on a > single physical system) so please do check http://test.winehq.org after your > patch has been accepted to see if you introduced failures on other machines. > > The plan for the future is to extend this a bit. Speaking from my own > experience, I know that programmers like to be as lazy as possible. Which > means that having to cross-compile your test before you can send it off to the > bot will be seen as a bit of a hurdle. So the next step will be to allow you > to upload the git diff instead of a Windows executable. The bot will apply > your diff to a git tree and take care of creating the cross-compiled Windows > executable, which it will then run on the Windows VMs. Step 3 will be to have > the bot watch wine-patches for anything that might impact the tests and do the > apply diff/cross-compile/run thing automatically. Obviously I'll be looking at > Dan's patch watcher for this 3rd step. > > Security is a concern, but perhaps more for me than for you :-). I have > to trust you not to abuse this system. If you want to do something naughty > please do it on your own machine. There are some safeguards in the system, > like the timeout. In general, you should not expect any privacy, I do have > access to the consoles of the VMs and firewall logs. If you want to use this > system for something else than Wine tests, please talk to me first. > > I'd like to thank Paul Vriens who acted as beta tester and made some valuable > suggestions. I welcome feedback so if you have any ideas on how to improve > this thing further please let me know. > > Ge. > > > >

Nov. 30, 2009

Re: [1/3] WineD3D: Infrastructure to render swapchains to a FBO

by Stefan Dösinger

> I think this will break color_fill_fbo I'll investigate that, but I think if it did it would break the d3d9 tests if I force rendering to the FBO - which I did for testing. > Out of curiosity, what would the performance impact be of always > rendering to FBO? I only tested it on my macs so far, because I've written this mainly to work around blitting bugs: The performance depends on what the app is doing. I tested it with the d3d8 SDK samples, where the drawing effort is pretty small, and the present() call probably the biggest single call. Apps which do not render offscreen have a ~10% performance hit. Apps which render offscreen and need the depth blit gain about 10% performance. That said, I think OSX always renders to a FBO behind our back, so other drivers might show different behavior.

Nov. 30, 2009

Re: [1/3] WineD3D: Infrastructure to render swapchains to a FBO

by Henri Verbeet

2009/11/30 Stefan Dösinger <stefan(a)codeweavers.com>: > I think this will break color_fill_fbo(). My general feeling is that I'm seeing to much variants of "if (swapchain->render_to_fbo)". Also, I think this patch has parts that can be separated like e.g. the surface_init_sysmem() bit. Out of curiosity, what would the performance impact be of always rendering to FBO?

Nov. 30, 2009

Re: Introducing WineTestBot

by Paul Vriens

On 11/30/2009 10:05 AM, Greg Geldorp wrote: > Or, for those who like to be buzzword compliant, the Wine Testing Cloud > Service. > > Inspired by all the talk about testing during WineConf 2009, I set out to fill > a gap in Wine testing. Most of the Wine developers don't have access to a > battery of Windows machines to run the tests they write/modify on. As a result, > there are quite a few regressions in the tests themselves. The WineTestBot > provides a whole bunch of Windows machines, ready to accept and run your > modified tests. In its current state you can submit Windows executables (most > likely cross-compiled on a Linux box) to the bot, which will run it in VMs of > your choice. > > So, how does this work in practice? First, go to > https://winetestbot.geldorp.nl and click on "Register" to register an account. > Once your account is approved (you'll receive a notification via email) you > can log in. After log in, the menu in the sidebar changes to include an item > "Submit job". This allows you to upload an .exe from your local system to the > bot. You can pick the VMs (Windows versions) you want to run the test on. From > the "Home" page you can see the status of your job, by clicking on the job id > you get a bit more info about the progress. Once the test is completed, the > stdout generated by the test is retrieved from each VM and made available via > that web page. > > The tests are run on VMware ESX VMs, so it's probably not all that useful to > run sound and DirectDraw tests on them. Also, no Win9x VMs are available. > I haven't set up 64-bit VMs yet, but those should be easy to add. Before each > test run, the VMs are reset to a clean snapshot, so no cruft from old tests > will be left around. Your test shouldn't take more than 5 minutes, which is > more than the WineTest framework allows anyway. > > For each Windows version, there is a "base" VM and there can be additional > VMs too. The idea is that the base VM is running the most up-to-date and > most often used variation of that Windows version, so running your test on > the base VMs should give you a good indication on how the test behaves. > Additionally, you can run your tests on the other variations too. So, for > example for XP the base VM is XP Professional SP3, but there are additional > VMs like SP2, Media Center Edition, and a non-English version available too. > Obviously, even when you use all available VMs you'll cover a very small > subset of all possible configurations (most notably you won't test on a > single physical system) so please do check http://test.winehq.org after your > patch has been accepted to see if you introduced failures on other machines. > > The plan for the future is to extend this a bit. Speaking from my own > experience, I know that programmers like to be as lazy as possible. Which > means that having to cross-compile your test before you can send it off to the > bot will be seen as a bit of a hurdle. So the next step will be to allow you > to upload the git diff instead of a Windows executable. The bot will apply > your diff to a git tree and take care of creating the cross-compiled Windows > executable, which it will then run on the Windows VMs. Step 3 will be to have > the bot watch wine-patches for anything that might impact the tests and do the > apply diff/cross-compile/run thing automatically. Obviously I'll be looking at > Dan's patch watcher for this 3rd step. > > Security is a concern, but perhaps more for me than for you :-). I have > to trust you not to abuse this system. If you want to do something naughty > please do it on your own machine. There are some safeguards in the system, > like the timeout. In general, you should not expect any privacy, I do have > access to the consoles of the VMs and firewall logs. If you want to use this > system for something else than Wine tests, please talk to me first. > > I'd like to thank Paul Vriens who acted as beta tester and made some valuable > suggestions. I welcome feedback so if you have any ideas on how to improve > this thing further please let me know. > > Ge. > > > Let me be the first to thank Ge for this awesome piece of work. -- Cheers, Paul.

Nov. 30, 2009

Introducing WineTestBot

by Greg Geldorp

Or, for those who like to be buzzword compliant, the Wine Testing Cloud Service. Inspired by all the talk about testing during WineConf 2009, I set out to fill a gap in Wine testing. Most of the Wine developers don't have access to a battery of Windows machines to run the tests they write/modify on. As a result, there are quite a few regressions in the tests themselves. The WineTestBot provides a whole bunch of Windows machines, ready to accept and run your modified tests. In its current state you can submit Windows executables (most likely cross-compiled on a Linux box) to the bot, which will run it in VMs of your choice. So, how does this work in practice? First, go to https://winetestbot.geldorp.nl and click on "Register" to register an account. Once your account is approved (you'll receive a notification via email) you can log in. After log in, the menu in the sidebar changes to include an item "Submit job". This allows you to upload an .exe from your local system to the bot. You can pick the VMs (Windows versions) you want to run the test on. From the "Home" page you can see the status of your job, by clicking on the job id you get a bit more info about the progress. Once the test is completed, the stdout generated by the test is retrieved from each VM and made available via that web page. The tests are run on VMware ESX VMs, so it's probably not all that useful to run sound and DirectDraw tests on them. Also, no Win9x VMs are available. I haven't set up 64-bit VMs yet, but those should be easy to add. Before each test run, the VMs are reset to a clean snapshot, so no cruft from old tests will be left around. Your test shouldn't take more than 5 minutes, which is more than the WineTest framework allows anyway. For each Windows version, there is a "base" VM and there can be additional VMs too. The idea is that the base VM is running the most up-to-date and most often used variation of that Windows version, so running your test on the base VMs should give you a good indication on how the test behaves. Additionally, you can run your tests on the other variations too. So, for example for XP the base VM is XP Professional SP3, but there are additional VMs like SP2, Media Center Edition, and a non-English version available too. Obviously, even when you use all available VMs you'll cover a very small subset of all possible configurations (most notably you won't test on a single physical system) so please do check http://test.winehq.org after your patch has been accepted to see if you introduced failures on other machines. The plan for the future is to extend this a bit. Speaking from my own experience, I know that programmers like to be as lazy as possible. Which means that having to cross-compile your test before you can send it off to the bot will be seen as a bit of a hurdle. So the next step will be to allow you to upload the git diff instead of a Windows executable. The bot will apply your diff to a git tree and take care of creating the cross-compiled Windows executable, which it will then run on the Windows VMs. Step 3 will be to have the bot watch wine-patches for anything that might impact the tests and do the apply diff/cross-compile/run thing automatically. Obviously I'll be looking at Dan's patch watcher for this 3rd step. Security is a concern, but perhaps more for me than for you :-). I have to trust you not to abuse this system. If you want to do something naughty please do it on your own machine. There are some safeguards in the system, like the timeout. In general, you should not expect any privacy, I do have access to the consoles of the VMs and firewall logs. If you want to use this system for something else than Wine tests, please talk to me first. I'd like to thank Paul Vriens who acted as beta tester and made some valuable suggestions. I welcome feedback so if you have any ideas on how to improve this thing further please let me know. Ge.

Nov. 30, 2009

Re: winetest + pbuffer + nvidia 190.18 drivers = X crash

by Austin English

On Sun, Nov 29, 2009 at 5:45 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > 2009/11/20 Austin English <austinenglish(a)gmail.com>: >> Been happening for a few days...not sure what triggered it, but when >> coming back from work I see my login screen, which explains the lack >> of 64-bit tests/appinstall results. I don't know if any of the D3D >> guys could take a look, but I'd appreciate it... >> > What does your Xorg log look like? Doesn't seem to want to crash now...strange. I'll keep an eye on it and if it happens again I'll get the log. -- -Austin

Nov. 29, 2009

re: RFC: EM_FORMATRANGE Patch for Wine-1.1.33

by Dan Kegel

I can't do a deep review, but I did see that you have some commented out code, and IIRC AJ doesn't like that. Better to remove it than comment it out. BTW, besides the three apps mentioned in http://bugs.winehq.org/show_bug.cgi?id=6254, what apps depend on this? - Dan

Nov. 29, 2009

Re: gdi32 : Correction of bug 20850 Write buffer overflow in WidenPath()

by Laurent

On Sun, Nov 29, 2009 at 2:24 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Sun, Nov 29, 2009 at 12:10 AM, Laurent <laurent(a)vromman.org> wrote: >> Yes, it would be. The fact is that makes a zero byte size HeapAlloc. >> I'm not really sure how and why it is supposed to work in this case, > > It works fine, HeapReAlloc handles it ok, too. > On Windows, it actually returns a heap block. > (On Posix, it can return null, but realloc still works > either way.) > Thank you for the precision. Let apply your patch in this case. It's not necessary that I reproduce the same with the name on it as the only difference. > Really, one would probably prefer to reduce the number of > reallocs by allocating extra entries initially (say, four) > and then doubling each time that wasn't enough, but > for now let's go with the simplest possible change that > will make your code correct. > - Dan > Laurent

Nov. 29, 2009

RFC: EM_FORMATRANGE Patch for Wine-1.1.33

by James McKenzie

All: Time to beat on this patch again and make it better. I've also attached it to bug 6254. Please make comments constructive. I would like to get assistance where to break this down so that it will be 'easier to swallow' pieces as this is one huge patch that AJ has rejected before. James McKenzie

Nov. 29, 2009

Re: windows shutdown process

by Vincent Povirk

On Sun, Nov 29, 2009 at 1:21 AM, Ben Peddell <klightspeed(a)netspace.net.au> wrote: > <stuff> So the behavior I'm seeing matches other versions of Windows and is documented. Excellent. Thanks. -- Vincent Povirk

Nov. 29, 2009

Re: gdi32 : Correction of bug 20850 Write buffer overflow in WidenPath()

by Dan Kegel

On Sun, Nov 29, 2009 at 12:10 AM, Laurent <laurent(a)vromman.org> wrote: > Yes, it would be. The fact is that makes a zero byte size HeapAlloc. > I'm not really sure how and why it is supposed to work in this case, It works fine, HeapReAlloc handles it ok, too. On Windows, it actually returns a heap block. (On Posix, it can return null, but realloc still works either way.) Really, one would probably prefer to reduce the number of reallocs by allocating extra entries initially (say, four) and then doubling each time that wasn't enough, but for now let's go with the simplest possible change that will make your code correct. - Dan

Nov. 29, 2009

Re: winetest + pbuffer + nvidia 190.18 drivers = X crash

by Henri Verbeet

2009/11/20 Austin English <austinenglish(a)gmail.com>: > Been happening for a few days...not sure what triggered it, but when > coming back from work I see my login screen, which explains the lack > of 64-bit tests/appinstall results. I don't know if any of the D3D > guys could take a look, but I'd appreciate it... > What does your Xorg log look like?

Nov. 29, 2009

Re: gdi32 : Correction of bug 20850 Write buffer overflow in WidenPath()

by Nikolay Sivov

Laurent wrote: > On Sun, Nov 29, 2009 at 2:32 AM, Dan Kegel <dank(a)kegel.com> wrote: > >> On Sat, Nov 28, 2009 at 5:04 PM, Laurent Vromman <laurent(a)vromman.org> wrote: >> >>> - pStrokes = HeapAlloc(GetProcessHeap(), 0, numStrokes * >>> sizeof(GdiPath*)); >>> - pStrokes[0] = HeapAlloc(GetProcessHeap(), 0, sizeof(GdiPath)); >>> - PATH_InitGdiPath(pStrokes[0]); >>> - pStrokes[0]->pFlags = HeapAlloc(GetProcessHeap(), 0, >>> pPath->numEntriesUsed * sizeof(INT)); >>> - pStrokes[0]->pPoints = HeapAlloc(GetProcessHeap(), 0, >>> pPath->numEntriesUsed * sizeof(POINT)); >>> - pStrokes[0]->numEntriesUsed = 0; >>> + pStrokes = NULL; >>> >> ... >> >> Wait, wouldn't it be simpler to keep the initial alloc, as in the attachment? >> > > Yes, it would be. The fact is that makes a zero byte size HeapAlloc. > I'm not really sure how and why it is supposed to work in this case, > so I prefered to removed it. MSDN didn't help me to understand what is > a pointer to a zero byte size memory area, and how HeapReAlloc is > supposed to react then. > > If you say it's ok, you're solution is way better. > > pStrokes = HeapAlloc(GetProcessHeap(), 0, numStrokes * > sizeof(GdiPath*)); can even be replaced by pStrokes = > HeapAlloc(GetProcessHeap(), 0, 0); I think it will be optimized automatically to that, but call it such way is confusing, if it's necessary to allocate a zero sized area to make next HeapReAlloc() succeed let's specify it explicitly. > It's useless to call sizeof if > numStrokes is 0. > It's not a call, it's compile time calculated. > If you are ok with all that, I can make a new patch based on your proposal. > > >> - Dan >> >> > > Laurent >

Nov. 29, 2009

Re: gdi32 : Correction of bug 20850 Write buffer overflow in WidenPath()

by Laurent

On Sun, Nov 29, 2009 at 2:32 AM, Dan Kegel <dank(a)kegel.com> wrote: > On Sat, Nov 28, 2009 at 5:04 PM, Laurent Vromman <laurent(a)vromman.org> wrote: >> - pStrokes = HeapAlloc(GetProcessHeap(), 0, numStrokes * >> sizeof(GdiPath*)); >> - pStrokes[0] = HeapAlloc(GetProcessHeap(), 0, sizeof(GdiPath)); >> - PATH_InitGdiPath(pStrokes[0]); >> - pStrokes[0]->pFlags = HeapAlloc(GetProcessHeap(), 0, >> pPath->numEntriesUsed * sizeof(INT)); >> - pStrokes[0]->pPoints = HeapAlloc(GetProcessHeap(), 0, >> pPath->numEntriesUsed * sizeof(POINT)); >> - pStrokes[0]->numEntriesUsed = 0; >> + pStrokes = NULL; > ... > > Wait, wouldn't it be simpler to keep the initial alloc, as in the attachment? Yes, it would be. The fact is that makes a zero byte size HeapAlloc. I'm not really sure how and why it is supposed to work in this case, so I prefered to removed it. MSDN didn't help me to understand what is a pointer to a zero byte size memory area, and how HeapReAlloc is supposed to react then. If you say it's ok, you're solution is way better. pStrokes = HeapAlloc(GetProcessHeap(), 0, numStrokes * sizeof(GdiPath*)); can even be replaced by pStrokes = HeapAlloc(GetProcessHeap(), 0, 0); It's useless to call sizeof if numStrokes is 0. If you are ok with all that, I can make a new patch based on your proposal. > - Dan > Laurent

Nov. 29, 2009

Re: windows shutdown process

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vincent Povirk wrote: > In order to find the correct fix for bug 18753, I've been examining > the shutdown process on Windows. I have written a program that logs > the messages sent to it, and I've run it on Windows 7. What I found > was that a shutdown produces the following sequence of events: > * We get a 0x3b message. DefWindowProc sends a WM_QUERYENDSESSION > message. We return 1, allowing the session to end. > * We get another 0x3b message, which leads to a WM_ENDSESSION. > * Nothing else happens, but for some reason the program exits. > > I added a trace after the message loop returns to see if the program > gets a WM_QUIT. It doesn't. > > Apparently, my test program was killed. > > I tried changing the window proc so that it loops infinitely when it > gets WM_ENDSESSION. Windows 7 sees this as "blocking shutdown". > (Naturally, it responds the same way if I return 0 from > WM_QUERYENDSESSION.) > > This leads me to believe that Windows 7, when shutting down, > immediately kills any process that returns from a WM_ENDSESSION > message. > > Does that seem sane? > > I've posted my test program (source code and .exe file) at > http://madewokherd.nfshost.com/msgtest.zip, and I'd like to hear if > other Windows versions behave the same way Windows 7 does. > OS | Terminated on return from WM_ENDSESSION or 0x3B Windows Vista | yes Windows XP | yes Windows 98 | yes None of these returned from GetMessage, and no atexit handlers were called. Windows 98 did not send the 0x3B message, but terminated the program after the message handler returned from WM_ENDSESSION. Windows 98 doing this says Windows NT 4.0 would have done this. I don't have Windows NT 3.1 to test with, but I think it would have done the same. Some references: <http://blogs.msdn.com/michen/archive/2008/04/04/Application-termination-whe…> <http://blogs.msdn.com/oldnewthing/archive/2008/04/21/8413175.aspx> Basically, Windows calls TerminateProcess on the process when all of its window message loop threads have returned from the WM_ENDSESSION (or wrapping 0x3B) message. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksSIOEACgkQTHDAI68NsukZ3QCfT8oy2uDhQ3whp7nNWjXDEaic vk4AnReQXvbmzl8AG9r1K5Coj7CRtUem =v3ge -----END PGP SIGNATURE-----

Nov. 29, 2009

Re: gdi32 : Correction of bug 20850 Write buffer overflow in WidenPath()

by Dan Kegel

On Sat, Nov 28, 2009 at 5:04 PM, Laurent Vromman <laurent(a)vromman.org> wrote: > - pStrokes = HeapAlloc(GetProcessHeap(), 0, numStrokes * > sizeof(GdiPath*)); > - pStrokes[0] = HeapAlloc(GetProcessHeap(), 0, sizeof(GdiPath)); > - PATH_InitGdiPath(pStrokes[0]); > - pStrokes[0]->pFlags = HeapAlloc(GetProcessHeap(), 0, > pPath->numEntriesUsed * sizeof(INT)); > - pStrokes[0]->pPoints = HeapAlloc(GetProcessHeap(), 0, > pPath->numEntriesUsed * sizeof(POINT)); > - pStrokes[0]->numEntriesUsed = 0; > + pStrokes = NULL; ... Wait, wouldn't it be simpler to keep the initial alloc, as in the attachment? - Dan

Nov. 28, 2009

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

by Rob Shearman

2009/11/27 Paul Chitescu <paulc(a)voip.null.ro>: > --- ./dlls/kernel32/locale.c.orig 2009-11-02 05:45:10.000000000 +0200 > +++ ./dlls/kernel32/locale.c 2009-11-26 19:35:39.000000000 +0200 > @@ -3017,7 +3017,7 @@ > RtlInitUnicodeString( &keyName, szKeyName ); > InitializeObjectAttributes(&attr, &keyName, 0, hRootKey, NULL); > > - if (NtOpenKey( &hkey, KEY_ALL_ACCESS, &attr ) != STATUS_SUCCESS) > + if (NtOpenKey( &hkey, MAXIMUM_ALLOWED, &attr ) != STATUS_SUCCESS) > hkey = 0; > > return hkey; This is ugly. The function should be changed to allow the required access rights to be specified. -- Rob Shearman

Nov. 28, 2009

Re: services.exe: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible

by Rob Shearman

2009/11/27 Paul Chitescu <paulc(a)voip.null.ro>: > @@ -376,7 +376,7 @@ > InitializeCriticalSection(&(*db)->cs); > > err = RegCreateKeyExW(HKEY_LOCAL_MACHINE, SZ_SERVICES_KEY, 0, NULL, > - REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, > + REG_OPTION_NON_VOLATILE, MAXIMUM_ALLOWED, NULL, > &(*db)->root_key, NULL); > if (err != ERROR_SUCCESS) > HeapFree(GetProcessHeap(), 0, *db); I'm not happy with this change because the code was written with the assumption that data it will always have permission to write data back to keys under root_key. The return value from save_service_config isn't always checked and thus this could lead to silent data loss. In any event, the use of MAXIMUM_ALLOWED should not be encouraged where at all possible [1] and instead the code should try the most permissions it needs and fall back to less as appropriate. > @@ -417,7 +417,7 @@ > break; > > WINE_TRACE("Loading service %s\n", wine_dbgstr_w(szName)); > - err = RegOpenKeyExW(db->root_key, szName, 0, KEY_READ | KEY_WRITE, &hServiceKey); > + err = RegOpenKeyExW(db->root_key, szName, 0, KEY_READ, &hServiceKey); > if (err == ERROR_SUCCESS) > { > err = load_service_config(hServiceKey, entry); This change is fine since hServiceKey is only every used with operations that require KEY_READ at the most. -- Rob Shearman [1] http://blogs.msdn.com/larryosterman/archive/2004/09/14/229658.aspx

Nov. 28, 2009