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

Re: advapi32.dll: Reduce Registry access to MAXIMUM_ALLOWED wherever possible

by Rob Shearman

2009/11/27 Paul Chitescu <paulc(a)voip.null.ro>: > Changelog: > advapi32.dll: Reduce Registry access to MAXIMUM_ALLOWED wherever possible > > Makes read operation succeed on read/only Registry keys. Needs tests to show that this behaviour matches that on Windows. You should be able to achieve this by setting an appropriate security descriptor on the registry key before calling the function you are changing. However, the change to get_special_root_hkey looks fine to me. The rest of your patch isn't easy to review because you haven't generated the diff with the "-p" option. -- Rob Shearman

Nov. 28, 2009

Re: Wine programs - replicating bad design/bugs

by Jerome Leclanche

The issue with notepad is, the search menu is completely different in Windows notepad (AFAIK it's in Edit and there's no search menu). Fair enough for 18622. J. Leclanche / Adys On Sat, Nov 28, 2009 at 6:20 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Jerome Leclanche wrote: >> http://bugs.winehq.org/show_bug.cgi?id=20844 > IMHO this could be done, however this will be a "hidden feature". You can't > add that to the menu - it will break programs that "script" notepad (yes > there are programs like that). > >> ** http://bugs.winehq.org/show_bug.cgi?id=18622 > This error coming from API layer, not regedit. Windows' registry API is > case-insensitive and does not allow that. As well as wineserver handles > registry as case-insensitive. Altering API means breaking programs. > > Vitaliy. > >

Nov. 28, 2009

Re: Corrections for signal handlers

by Markus Elfring

> And don't ask me to actually think about what I'm doing, I am still open for further discussions. > it's too hard to figure out how to print a string and a number without using printf(). This data display (e. g. for the input command and line number) is generally not a problem. But the situation is different in the context of a signal handler because of the limited set of async-signal-safe functions. Regards, Markus

Nov. 28, 2009

Re: Corrections for signal handlers

by Vitaliy Margolen

Don't CC wine-patches. Markus Elfring wrote: >> Original printed more useful information. >> Just dropping it in sake of "correctness" is wrong. >> You'll have to come up with something that prints the same >> or don't touch it. > > I am aware of the desire to get some data for easier program debugging conveniently. > I have got an opposite opinion. I am curious if more software developers would like to care for complete async-signal-safety. > This will not happen at the moment because of conflicting expectations. > I assume that the involved implementation details will be reconsidered some day in the future. So basically you saying: ---------- I don't care what you had in there, and I don't care how useful that information was to you. I care about some highly hypothetical error cases that might never happen in your program but just because theoretically they can happen I'll remove some code that looks wrong. And don't ask me to actually think about what I'm doing, it's too hard to figure out how to print a string and a number without using printf(). So I'll leave that to you to code. ----------- No wonder you receive such a "welcome" from other projects you've tried to "improve" before. Vitaliy.

Nov. 28, 2009

Re: Corrections for signal handlers

by Markus Elfring

> Original printed more useful information. I am aware of the desire to get some data for easier program debugging conveniently. > Just dropping it in sake of "correctness" is wrong. I have got an opposite opinion. I am curious if more software developers would like to care for complete async-signal-safety. > You'll have to come up with something that prints the same This will not happen at the moment because of conflicting expectations. > or don't touch it. I assume that the involved implementation details will be reconsidered some day in the future. Regards, Markus

Nov. 28, 2009

Re: Corrections for signal handlers

by Vitaliy Margolen

Markus Elfring wrote: > Hello, > > Some signal handler implementations are also affected by technical details that are described in an article by Justin Pincar. > https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+… > Your code looks even worse then your arguments for "correct" codding practices. > -static int watchdog; > +static sig_atomic_t watchdog; Don't do this, you've been told to leave it alone. > - fprintf( stderr, "wineserver crashed, please enable coredumps (ulimit -c unlimited) and restart.\n"); > + char const message[] = "wineserver crashed, please enable coredumps (ulimit -c unlimited) and restart.\n"; Should be "static const char" in that exact order. > + > + (void) write(STDERR_FILENO, message, sizeof(message) - 1); What's "(void)" doing here? Yes we do ignore returned states here and in 10000s or other places. Don't do that. > + (void) fsync(STDERR_FILENO); Why do you need sync here? > abort(); > --- a/tools/wmc/wmc.c Wine fix per program please. You'll have to split this into 3 separate patches. > static void segvhandler(int sig) > { > -<----->fprintf(stderr, "\n%s:%d: Oops, segment violation\n", input_name, line_number); > -<----->fflush(stdout); > -<----->fflush(stderr); > + char const message[] = "\nOops, segment violation\n"; Same as above - should be "static const char" in that exact order. > + > + (void) write(STDERR_FILENO, message, sizeof(message) - 1); > + (void) fsync(STDOUT_FILENO); > + (void) fsync(STDERR_FILENO); Remove bogus "(void)". > <----->abort(); > } Original printed more useful information. Just dropping it in sake of "correctness" is wrong. You'll have to come up with something that prints the same or don't touch it. Original used tabs (8-spaces) your patch uses 4-space indentation. Either keep the file's formatting or stick to 4-space indentation but DO NOT mix and match both inside one function. Same applies to tools/wrc/wrc.c Vitaliy.

Nov. 28, 2009

Re: Wine programs - replicating bad design/bugs

by Vitaliy Margolen

Jerome Leclanche wrote: > http://bugs.winehq.org/show_bug.cgi?id=20844 IMHO this could be done, however this will be a "hidden feature". You can't add that to the menu - it will break programs that "script" notepad (yes there are programs like that). > ** http://bugs.winehq.org/show_bug.cgi?id=18622 This error coming from API layer, not regedit. Windows' registry API is case-insensitive and does not allow that. As well as wineserver handles registry as case-insensitive. Altering API means breaking programs. Vitaliy.

Nov. 28, 2009

re: Corrections for signal handlers

by Dan Kegel

I'm not sure this change does what you think: - fflush(stdout); ... + (void) fsync(STDOUT_FILENO); The real problem with your change is that *we don't care* whether the output of wineserver is garbled, because it is low priority debugging information, and I've never seen it garbled in practice. In short, it's not worth the time reviewing the patch. So while we appreciate your effort to improve the correctness of Wine's code, we would prefer it if you chose a more useful target. Also, Wine's patch review system is reputation-based. Your best avenue for getting pedantic corrections accepted is to get some pragmatic improvements accepted first. You might then be able to use some of your earned karma points on your favorite bikeshed problem. - Dan

Nov. 28, 2009

Re: Whitespace cleanups

by Jerome Leclanche

I was just working on shell32/shlview.c: ShellView_OnNotify. There is so much mixing between tabs, spaces, different indent levels, trailing whitespace and what not that the code is properly unreadable. git-blame is one thing, but when it goes as far as almost preventing a developer to make changes... J. Leclanche / Adys On Fri, Nov 27, 2009 at 7:27 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Nov 26, 2009, at 10:15 AM, Francois Gouget wrote: > >> On Wed, 25 Nov 2009, Ken Thomases wrote: >> [...] >>> >>> One important reason to avoid whitespace-only changes is it makes >>> git-blame essentially useless for finding the real source of >>> functional changes >> >> Such changes don't make git-blame useless. They just make it a bit >> harder to use. >> >> Let's say your 'git-blame dlls/mshtml/tests/dom.c' leads you to commit >> 1e4412d7 which, by looking at it, you decide is a false positive. Then >> you do: >> >> $ git cat-file -p 1e4412d7 >> tree ea3b2e117b383ade8afc7cc9bf534c48faf891c7 >> parent 44f520a5b6f2bd6ec6da8793177711e57bda9c72 >> author Francois Gouget <fgouget(a)free.fr> 1258539107 +0100 >> committer Alexandre Julliard <julliard(a)winehq.org> 1258553736 +0100 >> >> mshtml/tests: Add a trailing '\n' to ok() calls. >> >> Then you run git-blame again: >> >> git blame 44f520a5 dlls/mshtml/tests/dom.c >> >> And continue the analysis until you find the right culprit. > > Um, it's just easier to add a caret ('^') to the commit ID. > > git blame 1e4412d7^ dlls/mshtml/tests/dom.c > > I'm well aware of this technique, but if it doesn't make git-blame useless, > it makes it a hell of a lot less useful, especially if whitespace-only > changes become non-rare. I wasn't aware of and haven't tried Kai's > suggestion of using the -w switch. > > -Ken > > > >

Nov. 28, 2009

Wine programs - replicating bad design/bugs

by Jerome Leclanche

Ok, posting here to get a broader feedback on the issue. Recently, another bug* was closed about an enhancement to a wine program - a minor feature not present on Windows. This is an issue I've seen brought up before, and which I've brought up myself**. As far as the win32 api goes, I can totally agree on dysfunctions that need to be replicated. However I find this unnecessary for the wine programs (notepad, wordpad, regedit, any or more). The idea behind bug 20844 was to have a better integration with the desktop, where Shift-F3 is a common keybind for "Search previous...". The only problem with this kind of mindset is "where should we stop with new features?". IMHO, the issue behind the two bugs linked below is only a matter of better integration, better design. I can also understand how some developers' goal is to close bugs, sometimes disregarding the fact there is a problem to deal with before then. * http://bugs.winehq.org/show_bug.cgi?id=20844 ** http://bugs.winehq.org/show_bug.cgi?id=18622 J. Leclanche PS. In bug 18622, I'm not talking about a case-insensitive registry, but for the key being actually renamed.

Nov. 28, 2009

Re: dlls/kernel32/path.c: Fix return values for UNC pathnames in GetLongPathNameW

by Paul Vriens

On 11/24/2009 02:41 PM, Alexandre Hardy wrote: > The MSDN: > http://msdn.microsoft.com/en-us/library/aa364980(VS.85).aspx > states that GetLongPathNameW returns the length of the string > required to hold the pathname if the buffer is too small to hold > the path. In the case where the buffer is too small, the filename > should not be stored in the buffer. > > This ensures that the buffer is not written to (for UNC pathnames) > if the buffer is not large enought to store the path. > > Kind regards > Alexandre > Hi Alexandre, Patches should go to wine-patches unless your asking for some guidance or comments. This one should also be accompanied with some tests. -- Cheers, Paul.

Nov. 28, 2009

Re: New winetricks 20091125: new verbs ie7, alsa, fbo, pbuffer, ...

by Louis Lenders

Dan Kegel <dank <at> kegel.com> writes: > > Pie's in the oven, time for another winetricks release. > Could it be possible to "fix" mdac as well? Because of wine now having a more or less stubbed oledb32.dll, apps that need mdac don't run properly anymore. Simple solution is to set oledb32 to native, before the mdac installer is started, (and leave it to native afterwards) Could that be added to winetricks?

Nov. 27, 2009

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control

by Nikolay Sivov

Ilya Shpigor wrote: > +static INT > +DATETIME_GetText (DATETIME_INFO *infoPtr, INT count, LPWSTR dst) > +{ > + WCHAR buf[80]; > + int i; > + > + if(!count) return 0; > + > + dst[0] = 0; > + for (i = 0; i < infoPtr->nrFields; i++) > + { > + DATETIME_ReturnTxt(infoPtr, i, buf, sizeof(buf)/sizeof(buf[0])); > + if ((strlenW(dst) + strlenW(buf)) <= count) > + strcatW(dst, buf); > + else break; > + } > + return strlenW(dst); > +} > 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. > @@ -674,6 +675,10 @@ static void test_wm_set_get_text(void) > ret = SendMessage(hWnd, WM_GETTEXT, sizeof(buff), (LPARAM)buff); > ok(strcmp(buff, a_str) != 0, "Expected text not to change, got %s\n", buff); > > + GetSystemTime(&stime); > + sprintf(time, "%d.%d.%d", stime.wDay, stime.wMonth, stime.wYear); > + ok(!strcmp(buff, time), "Expected %s, got %s\n", time, buff); > + > DestroyWindow(hWnd); > } > Test is definitely wrong. You can't expect DD.MMMM.YYYY pattern here, it's locale dependent.

Nov. 27, 2009

windows shutdown process

by Vincent Povirk

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. -- Vincent Povirk

Nov. 27, 2009

Re: Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by Austin English

On Fri, Nov 27, 2009 at 8:42 AM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Nikolay Sivov wrote: >> James McKenzie wrote: >>> All >>> >>> Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost >>> methods to avoid using window handle directly caused the tooltips popups >>> to stop functioning in e-Sword. >>> >>> Has this been corrected in later Wine releases? I am at wine-1.1.14 >>> with integrating the EM_FORMATRANGE patch. >>> >>> Thank you. >>> >>> James McKenzie >>> >> Did you file a bug report got that? >> >> > Nikolay: > > I don't want to file a bug report if it is already fixed. I'll continue > to work forward and see if the bug still exists. If it does, the report > goes in. You should check that yourself in git before e-mailing everyone in wine-devel about it... -- -Austin

Nov. 27, 2009

Re: Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by Michael Stefaniuc

James, James McKenzie wrote: > Nikolay Sivov wrote: >> James McKenzie wrote: >>> Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost >>> methods to avoid using window handle directly caused the tooltips popups >>> to stop functioning in e-Sword. >>> >>> Has this been corrected in later Wine releases? I am at wine-1.1.14 >>> with integrating the EM_FORMATRANGE patch. >>> >>> Thank you. >>> >>> James McKenzie >>> >> Did you file a bug report got that? >> >> > Nikolay: > > I don't want to file a bug report if it is already fixed. I'll continue > to work forward and see if the bug still exists. If it does, the report > goes in. wine-1.1.14 is pretty old. There are 109 commits since then that touch riched20; see the output of the below command for the details: git log wine-1.1.14..origin dlls/riched20/ bye michael

Nov. 27, 2009

Re: Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by James McKenzie

Nikolay Sivov wrote: > James McKenzie wrote: >> All >> >> Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost >> methods to avoid using window handle directly caused the tooltips popups >> to stop functioning in e-Sword. >> >> Has this been corrected in later Wine releases? I am at wine-1.1.14 >> with integrating the EM_FORMATRANGE patch. >> >> Thank you. >> >> James McKenzie >> > Did you file a bug report got that? > > Nikolay: I don't want to file a bug report if it is already fixed. I'll continue to work forward and see if the bug still exists. If it does, the report goes in. James McKenzie

Nov. 27, 2009

Re: Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by Nikolay Sivov

James McKenzie wrote: > All > > Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost > methods to avoid using window handle directly caused the tooltips popups > to stop functioning in e-Sword. > > Has this been corrected in later Wine releases? I am at wine-1.1.14 > with integrating the EM_FORMATRANGE patch. > > Thank you. > > James McKenzie > Did you file a bug report got that?

Nov. 27, 2009

Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by James McKenzie

All Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost methods to avoid using window handle directly caused the tooltips popups to stop functioning in e-Sword. Has this been corrected in later Wine releases? I am at wine-1.1.14 with integrating the EM_FORMATRANGE patch. Thank you. James McKenzie

Nov. 27, 2009

Re: [4/4] ntdll: partially support HEAP_DISABLE_COALESCE_ON_FREE, allows us to detect use-after-free

by Dan Kegel

Don't apply this one yet, just found a problem with it. On Tue, Nov 24, 2009 at 6:20 PM, Dan Kegel <dank(a)kegel.com> wrote: > This adds something like support for > HEAP_DISABLE_COALESCE_ON_FREE. > If the GlobalFlags registry entry has the > 200000 bit set, freed blocks are set > aside for a while rather than immediately > being released for reuse. This allows > us to poison them and check for use-after-free > or double-free errors, and report them as heap corruption. > > If you're running Valgrind, you get an immediate error > and stack trace for any of these heap corruption events, > which was the motivation for the patch series. > But the patches are useful even without valgrind. > > The number of blocks kept out of circulation is > 5000 by default, but can be set via an environment > variable. It ought to have a limit on number of bytes, > too, but this seemed enough for the moment. >

Nov. 27, 2009

Re: Whitespace cleanups

by Ken Thomases

On Nov 26, 2009, at 10:15 AM, Francois Gouget wrote: > On Wed, 25 Nov 2009, Ken Thomases wrote: > [...] >> One important reason to avoid whitespace-only changes is it makes >> git-blame essentially useless for finding the real source of >> functional changes. > > Such changes don't make git-blame useless. They just make it a bit > harder to use. > > Let's say your 'git-blame dlls/mshtml/tests/dom.c' leads you to commit > 1e4412d7 which, by looking at it, you decide is a false positive. Then > you do: > > $ git cat-file -p 1e4412d7 > tree ea3b2e117b383ade8afc7cc9bf534c48faf891c7 > parent 44f520a5b6f2bd6ec6da8793177711e57bda9c72 > author Francois Gouget <fgouget(a)free.fr> 1258539107 +0100 > committer Alexandre Julliard <julliard(a)winehq.org> 1258553736 +0100 > > mshtml/tests: Add a trailing '\n' to ok() calls. > > Then you run git-blame again: > > git blame 44f520a5 dlls/mshtml/tests/dom.c > > And continue the analysis until you find the right culprit. Um, it's just easier to add a caret ('^') to the commit ID. git blame 1e4412d7^ dlls/mshtml/tests/dom.c I'm well aware of this technique, but if it doesn't make git-blame useless, it makes it a hell of a lot less useful, especially if whitespace-only changes become non-rare. I wasn't aware of and haven't tried Kai's suggestion of using the -w switch. -Ken

Nov. 27, 2009

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

by Ken Thomases

On Nov 26, 2009, at 12:31 AM, Vitaliy Margolen wrote: > Ken Thomases wrote: >> Setting LC_ALL would achieve that, plus override the various other >> locale >> categories. Set LANG is the wrong approach, in my opinion. > > However this is not the way Wine works on all other platforms. Sure it is, if you consider the user preferences to be setting the LC_* variables. On Linux, if the LC_* variables are set, then setting LANG does nothing. LANG is, always and everywhere, a fallback, not an override. This is true for how Wine works on Linux and Mac OS X and everywhere else. I see no inconsistency. On Nov 26, 2009, at 12:58 AM, Dmitry Timoshkov wrote: > "Ken Thomases" <ken(a)codeweavers.com> wrote: > >> 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. > > In the most cases what user wants is not just change the UI language > (which setting the LC_MESSAGES does) but also change the locale (i.e. > input/output code page), that's where LANG should be used. No, that's where setting LC_ALL should be used. > LC_MESSAGES hack adds more confusion IMO than really helps. Except that the vast, vast majority of Mac users will never touch (or even think about) the LANG or LC_* variables. For them, the current code does the right thing, even for the case where their preferred language is set to something other than their formats region. Letting LANG override their system settings would produce incorrect results for those users and force them to think about and use LANG or LC_ALL where they otherwise wouldn't. I see no upside at all to changing LANG into an override where that's not how it functions in any other context. Regards, Ken

Nov. 27, 2009

Re: New valgrind results, this time with overrun checks and lots of new errors.

by Dan Kegel

On Fri, Nov 20, 2009 at 9:02 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Dan Kegel wrote: >> http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-comctl32_tab.txt >> http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-comctl32_tab.txt >> show a more inscrutable error: >> Invalid write of size 4 >> at TAB_SetCurSel (tab.c:255) >> by TAB_WindowProc (tab.c:3367) >>... > This shouldn't be a case for today git - see commit > 3371ba9f73367572693589905ed57af87b747b54. > > And thanks a lot for these test results, I'm waiting for automated daily > runs a lot... Here's the next run: http://kegel.com/wine/valgrind/logs/2009-11-26-06.08/vg-comctl32_header.txt Conditional jump or move depends on uninitialised value(s) at winetest_vok (test.h:306) by winetest_ok (test.h:331) by test_hds_nosizing (header.c:1303) by func_header (header.c:1869) by run_test (test.h:535) by main (test.h:585) Uninitialised value was created by a stack allocation at test_hds_nosizing (header.c:1261) Conditional jump or move depends on uninitialised value(s) at HEADER_IsItemFixed (header.c:226) by HEADER_InternalHitTest (header.c:674) by HEADER_HitTest (header.c:1292) by HEADER_WindowProc (header.c:2065) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_CallProcAtoW (winproc.c:1023) by CallWindowProcA (winproc.c:2299) by header_subclass_proc (header.c:415) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_call_window (winproc.c:2223) by call_window_proc (message.c:1635) by send_message (message.c:2482) by SendMessageA (message.c:2627) by test_hds_nosizing (header.c:1328) by func_header (header.c:1869) by run_test (test.h:535) by main (test.h:585) Uninitialised value was created by a stack allocation at test_hds_nosizing (header.c:1261)

Nov. 26, 2009

Re: Garmin watches and USB

by Stefan Leichter

Am Tuesday 24 November 2009 22:38:53 schrieb Chris Teague: > > I'm trying to figure out exactly what the installer is looking for to > see if the dongle is present. I get a "You must connect your USB ANT > Stick.." message in a dialogbox, and a Retry button. I thought it was > checking for the presence of a new COM port or maybe something in the > Windows device tree? > I think your problem is here: 001c:Call setupapi.SetupDiGetClassDevsW(00488150,00000000,00000000,00000012) ret=00401ef5 001c:Call advapi32.RegOpenKeyExW(80000002,7d92a160 L"System\\CurrentControlSet\\Control\\DeviceClasses",00000000,00020019,0033ef18) ret=7d906628 001c:Ret advapi32.RegOpenKeyExW() retval=00000002 ret=7d906628 001c:Ret setupapi.SetupDiGetClassDevsW() retval=00196458 ret=00401ef5 001c:Call setupapi.SetupDiEnumDeviceInterfaces(00196458,00000000,00488150,00000000,0033f29c) ret=00401f16 001c:Ret setupapi.SetupDiEnumDeviceInterfaces() retval=00000000 ret=00401f16 0

Nov. 26, 2009

Re: kernel32.dll: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible

by Charles Davis

Maarten Lankhorst wrote: > Paul Chitescu schreef: >> Changelog: >> kernel32.dll: Reduce Registry access to KEY_READ or >> MAXIMUM_ALLOWED wherever possible >> >> In many places reading the Registry is enough to work even when write >> access is denied. >> > Your patches cannot be applied with -Np1, consider using git for sending > patches, rather than diffing them :) > > Uhh... he doesn't use git. He made a big deal about this when I told him to upgrade after his .cvsignore patch didn't get in. Chip

Nov. 26, 2009

Re: kernel32.dll: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible

by Maarten Lankhorst

Paul Chitescu schreef: > Changelog: > kernel32.dll: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever > possible > > In many places reading the Registry is enough to work even when write access > is denied. > Your patches cannot be applied with -Np1, consider using git for sending patches, rather than diffing them :)

Nov. 26, 2009

Re: [PATCH] server: Add primitive support for setting and getting the security descriptor of files based on their Unix permissions.

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4 Oct 2007, Rob Shearman submitted the patch "server: Add primitive support for setting and getting the security descriptor of files based on their Unix permissions.", which calculated the owner permissions solely based on the grant/deny permissions for the owner's SID. On 17 Oct 2007, in bug #10067, "Daniel" reported a bug about FAT32 support being broken in 0.9.47 (which included the above patch) On 21 Oct 2007, Rob Shearman submitted the patch "server: Fix file_set_sd to handle NULL DACLs.", which added support for setting permissions from NULL ACLs. On 21 Nov 2007, Rob Shearman submitted the patch "server: Add primitive support for setting and getting the security descriptor of files based on their Unix permissions.", which added the world permissions to the owner permissions. On 10 Mar 2009, in bug #17672, Nathan Lineback reported a bug about wine incorrectly setting permissions when installing Oracle DB. On 17 Mar 2009, in bug #17776, Richard Hendrikse reported a bug about FAT32 support being broken. On 5 Aug 2009, in bug #19588, Ken Sharp reported that wine was setting the wrong permissions in some cases. On 10 Nov 2009, in bug #20643, Marshall Davis reported that wine was removing owner permissions when World of Warcraft was giving only the users group permission to access the World of Warcraft directory. On 17 Nov 2009, I posted an initial patch here to take the permissions of the groups the user is a member of when calculating the UNIX mode. Rob Shearman replied: > While I agree that there is a problem that needs to be fixed, I'm not > sure this is the right approach. I think you need to take a step back > and consider the meanings of the different SIDs in a token by default > and how they map wine running inside the Unix permissions model. Later on 17 Nov 2009, I revised the patch to only look at the user's groups if the user was the owner of the file. If permissions should be revoked from a user when (1) they are the owner of the file, (2) they are not a trustee in the file's security descriptor, and (3) they are removed from all groups in the file's security descriptor, then there needs to be some other way of storing the owner of the file and the security descriptor in the filesystem (such as POSIX ACLs), and the owner in the security descriptor cannot be the UNIX owner of the file, as the UNIX owner permissions cannot be overridden by POSIX ACLs. In the meantime, the owner of the file cannot access the file when they are not a trustee in the security descriptor, even if token_access_check says they should be able to access the file. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksO/KUACgkQTHDAI68NsunTzwCfVdptQ8sFkFr42r2KOJjvbE2p U7YAoIGowA5ncsgts+p+twCxNDrEedKd =knqg -----END PGP SIGNATURE-----

Nov. 26, 2009

Re: Ctrl/Shift don't autorepeat

by Nikolay Sivov

F Capela wrote: > On Thursday 26 November 2009 11:27:24 am Nikolay Sivov wrote: > >> Dmitry Timoshkov wrote: >> >>> "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: >>> >>> >>>> I've noticed some problems with keyboard input while testing my >>>> favorite Listview control code. >>>> The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they >>>> don't trigger autorepeat. >>>> >>>> Is it a known input processing problem? >>>> >>> http://bugs.winehq.org/show_bug.cgi?id=18296 ? >>> >> Actually, no. I don't have unneeded keyups, the problem is that function >> keys don't autorepeat while letter keys >> do it properly. >> > > Have you tested to see if those keys are auto-repeating under linux (i.e., try to run xev and see if they are repeating)? AFAIK they don't usually autorepeat in Linux, and Wine does not simulate autorepeating; if it's not autorepeating under Linux, it will not autorepeat in Wine. > You're right. There's no autorepeat running my system, so Wine is ok here. Thanks for your answer. No questions. > > Fábio Oliveira Schmidt Capela > darkwalker_(a)yahoo.com >

Nov. 26, 2009

Re: Ctrl/Shift don't autorepeat

by F Capela

On Thursday 26 November 2009 11:27:24 am Nikolay Sivov wrote: > Dmitry Timoshkov wrote: > > "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > > > >> I've noticed some problems with keyboard input while testing my > >> favorite Listview control code. > >> The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they > >> don't trigger autorepeat. > >> > >> Is it a known input processing problem? > > > > http://bugs.winehq.org/show_bug.cgi?id=18296 ? > Actually, no. I don't have unneeded keyups, the problem is that function > keys don't autorepeat while letter keys > do it properly. Have you tested to see if those keys are auto-repeating under linux (i.e., try to run xev and see if they are repeating)? AFAIK they don't usually autorepeat in Linux, and Wine does not simulate autorepeating; if it's not autorepeating under Linux, it will not autorepeat in Wine. Fábio Oliveira Schmidt Capela darkwalker_(a)yahoo.com

Nov. 26, 2009

Re: Whitespace cleanups

by Francois Gouget

On Wed, 25 Nov 2009, Ken Thomases wrote: [...] > One important reason to avoid whitespace-only changes is it makes > git-blame essentially useless for finding the real source of > functional changes. Such changes don't make git-blame useless. They just make it a bit harder to use. Let's say your 'git-blame dlls/mshtml/tests/dom.c' leads you to commit 1e4412d7 which, by looking at it, you decide is a false positive. Then you do: $ git cat-file -p 1e4412d7 tree ea3b2e117b383ade8afc7cc9bf534c48faf891c7 parent 44f520a5b6f2bd6ec6da8793177711e57bda9c72 author Francois Gouget <fgouget(a)free.fr> 1258539107 +0100 committer Alexandre Julliard <julliard(a)winehq.org> 1258553736 +0100 mshtml/tests: Add a trailing '\n' to ok() calls. Then you run git-blame again: git blame 44f520a5 dlls/mshtml/tests/dom.c And continue the analysis until you find the right culprit. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Nov. 26, 2009

Re: Ctrl/Shift don't autorepeat

by Nikolay Sivov

Paul Chitescu wrote: > On Thursday 26 November 2009 11:27:24 am Nikolay Sivov wrote: > >> Dmitry Timoshkov wrote: >> >>> "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: >>> >>> >>>> I've noticed some problems with keyboard input while testing my >>>> favorite Listview control code. >>>> The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they >>>> don't trigger autorepeat. >>>> >>>> Is it a known input processing problem? >>>> >>> http://bugs.winehq.org/show_bug.cgi?id=18296 ? >>> >> Actually, no. I don't have unneeded keyups, the problem is that function >> keys don't autorepeat while letter keys >> do it properly. >> > > Are you using an USB keyboard? Can you experiment on a computer with PS/2 > keyboard? > > I ask because USB HID doesn't provide autorepeat, that is emulated in kernel. > Besides, modifier keys (there can be maximum 8 of them) are treated > differently by HID keyboard spec. > I'm using PS/2 through vmware running Lenny.

Nov. 26, 2009

Re: Ctrl/Shift don't autorepeat

by Paul Chitescu

On Thursday 26 November 2009 11:27:24 am Nikolay Sivov wrote: > Dmitry Timoshkov wrote: > > "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > > > >> I've noticed some problems with keyboard input while testing my > >> favorite Listview control code. > >> The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they > >> don't trigger autorepeat. > >> > >> Is it a known input processing problem? > > > > http://bugs.winehq.org/show_bug.cgi?id=18296 ? > Actually, no. I don't have unneeded keyups, the problem is that function > keys don't autorepeat while letter keys > do it properly. Are you using an USB keyboard? Can you experiment on a computer with PS/2 keyboard? I ask because USB HID doesn't provide autorepeat, that is emulated in kernel. Besides, modifier keys (there can be maximum 8 of them) are treated differently by HID keyboard spec.

Nov. 26, 2009

Re: Ctrl/Shift don't autorepeat

by Nikolay Sivov

Dmitry Timoshkov wrote: > "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > >> I've noticed some problems with keyboard input while testing my >> favorite Listview control code. >> The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they >> don't trigger autorepeat. >> >> Is it a known input processing problem? > > http://bugs.winehq.org/show_bug.cgi?id=18296 ? Actually, no. I don't have unneeded keyups, the problem is that function keys don't autorepeat while letter keys do it properly.

Nov. 26, 2009

Re: Ctrl/Shift don't autorepeat

by Dmitry Timoshkov

"Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > I've noticed some problems with keyboard input while testing my favorite > Listview control code. > The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they > don't trigger autorepeat. > > Is it a known input processing problem? http://bugs.winehq.org/show_bug.cgi?id=18296 ? -- Dmitry.

Nov. 26, 2009

Ctrl/Shift don't autorepeat

by Nikolay Sivov

Hi, guys. I've noticed some problems with keyboard input while testing my favorite Listview control code. The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they don't trigger autorepeat. Is it a known input processing problem? P.S. Alt key is different cause it generates WM_SYSKEYDOWN which isn't supported by control yet.

Nov. 26, 2009

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

by Dmitry Timoshkov

"Ken Thomases" <ken(a)codeweavers.com> wrote: > 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. In the most cases what user wants is not just change the UI language (which setting the LC_MESSAGES does) but also change the locale (i.e. input/output code page), that's where LANG should be used. LC_MESSAGES hack adds more confusion IMO than really helps. -- Dmitry.

Nov. 26, 2009

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

by Vitaliy Margolen

Ken Thomases wrote: > Setting LC_ALL would achieve that, plus override the various other locale > categories. Set LANG is the wrong approach, in my opinion. However this is not the way Wine works on all other platforms. Keeping everything in sync is more appropriate here. Or modify global Wine behavior. Vitaliy.

Nov. 26, 2009

New winetricks 20091125: new verbs ie7, alsa, fbo, pbuffer, ...

by Dan Kegel

Pie's in the oven, time for another winetricks release. Changes in this version: Add experimental dotnet35 verb Add IE7 verb. Based on a patch by Hans Leidekker. Add verbs alsa, audioio, coreaudio, esound, jack, nas, oss to override sound driver Add verbs backbuffer, fbo, pbuffer for setting offscreen rendering buffer Don't crash winecfg if native comctl32 is used Fix gecko to work with wine-1.1.33. Make vc2003toolkit and psdk2003 verbs run on windows On cleanup, remove $WINETRICKS_TMP, not just the files in it Sorted command menu Update Firefox to 3.5.5 Update mpc to latest version, move the exe to Program Files and add it to %PATH% Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Thanks to Austin English, Erik Inge Bolsoe, and Hans Leidekker. This message posted in gmail (basic mode) in ie7 in wine.

Nov. 25, 2009

Re: My script for doing testing

by Steven Edwards

On Wed, Nov 25, 2009 at 5:48 PM, Austin English <austinenglish(a)gmail.com> wrote: > Sure, that would be an option if the system has e-mail configured, but > since I use webmail, I went with the 'sit and wait' method. For other > projects that script would obviously need a different strategy (though > I don't other projects are running winetest.exe daily ;-)). Having the private vncserver or Xnest session is more important than the polling method. You should be able to turn your script in to a proper service without much trouble, the following psudo-init script is a snippet of the serivce I wrote. start() { echo -n $"winecis spam" /usr/bin/vncserver -geometry 1152x900 -depth 16 :$DISPLAY >> /var/log/vncserver.log 2>&1 doaustinswinecismagic RETVAL=$? echo [ $RETVAL = 0 ] return $RETVAL } stop() {..} restart() {..} etc,etc... -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Nov. 25, 2009

Re: My script for doing testing

by Nicolas Le Cam

2009/11/25 Austin English <austinenglish(a)gmail.com>: > On Wed, Nov 25, 2009 at 4:45 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: >> On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote: >>> On Wed, Nov 25, 2009 at 12:08 PM, Austin English >>> <austinenglish(a)gmail.com> wrote: >>> > The other neat thing is that it will run git fetch in a loop every 30 >>> > minutes (again, overridable), so that you can run it in the morning >>> > while waiting for AJ to commit. Once commits are made to the git >>> > master branch (but not stable), the script will kick into motion. >>> >>> It would be nice to dummy email account subscribed to the commit >>> messages that it could poll to trigger the checkout, build, test >>> cycle. >>> >>> To make a Continuous Integration Service around it it should run as a >>> background process under another user out of init in a Xnest/VNC >>> session. I am thinking something like a winecis user which would run >>> these scripts, fetch and the Xnest session as a service we could call >>> winecis. >>> >>> I did something similar recently for a stupid java service that had to >>> have an interactive gui. >> >> As AJ is pushing just once a day you can also run your fetch script >> once a day... Perhaps triggered by a commit mail. > > Sure, that would be an option if the system has e-mail configured, but > since I use webmail, I went with the 'sit and wait' method. For other > projects that script would obviously need a different strategy (though > I don't other projects are running winetest.exe daily ;-)). > > -- > -Austin > > > You could watch http://test.winehq.org/builds/ to see if there is any update (a push is followed by a test build). -- Nicolas Le Cam

Nov. 25, 2009

Re: My script for doing testing

by Austin English

On Wed, Nov 25, 2009 at 4:45 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote: >> On Wed, Nov 25, 2009 at 12:08 PM, Austin English >> <austinenglish(a)gmail.com> wrote: >> > The other neat thing is that it will run git fetch in a loop every 30 >> > minutes (again, overridable), so that you can run it in the morning >> > while waiting for AJ to commit. Once commits are made to the git >> > master branch (but not stable), the script will kick into motion. >> >> It would be nice to dummy email account subscribed to the commit >> messages that it could poll to trigger the checkout, build, test >> cycle. >> >> To make a Continuous Integration Service around it it should run as a >> background process under another user out of init in a Xnest/VNC >> session. I am thinking something like a winecis user which would run >> these scripts, fetch and the Xnest session as a service we could call >> winecis. >> >> I did something similar recently for a stupid java service that had to >> have an interactive gui. > > As AJ is pushing just once a day you can also run your fetch script > once a day... Perhaps triggered by a commit mail. Sure, that would be an option if the system has e-mail configured, but since I use webmail, I went with the 'sit and wait' method. For other projects that script would obviously need a different strategy (though I don't other projects are running winetest.exe daily ;-)). -- -Austin

Nov. 25, 2009

Re: My script for doing testing

by Marcus Meissner

On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote: > On Wed, Nov 25, 2009 at 12:08 PM, Austin English > <austinenglish(a)gmail.com> wrote: > > The other neat thing is that it will run git fetch in a loop every 30 > > minutes (again, overridable), so that you can run it in the morning > > while waiting for AJ to commit. Once commits are made to the git > > master branch (but not stable), the script will kick into motion. > > It would be nice to dummy email account subscribed to the commit > messages that it could poll to trigger the checkout, build, test > cycle. > > To make a Continuous Integration Service around it it should run as a > background process under another user out of init in a Xnest/VNC > session. I am thinking something like a winecis user which would run > these scripts, fetch and the Xnest session as a service we could call > winecis. > > I did something similar recently for a stupid java service that had to > have an interactive gui. As AJ is pushing just once a day you can also run your fetch script once a day... Perhaps triggered by a commit mail. Ciao, Marcus

Nov. 25, 2009

Re: My script for doing testing

by Avery Pennarun

On Wed, Nov 25, 2009 at 5:24 PM, Steven Edwards <winehacker(a)gmail.com> wrote: >> To make a Continuous Integration Service around it it should run as a >> background process under another user out of init in a Xnest/VNC >> session. I am thinking something like a winecis user which would run >> these scripts, fetch and the Xnest session as a service we could call >> winecis. >> >> I did something similar recently for a stupid java service that had to >> have an interactive gui. > > Thinking about it a bit more, I guess the email thing is kind of > redundant since git can poll more often. I guess it really depends on > how many build agents you want to have hanging out hammering git. To > you want them to hammer git or hammer your mail server? Checking git every few minutes for new revisions costs basically zero, in the event that there are no new revisions. BTW, gitbuilder can do this sort of thing for you. It also provides an rss feed of build results. Avery

Nov. 25, 2009

Re: My script for doing testing

by Steven Edwards

On Wed, Nov 25, 2009 at 5:21 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > It would be nice to dummy email account subscribed to the commit > messages that it could poll to trigger the checkout, build, test > cycle. > > To make a Continuous Integration Service around it it should run as a > background process under another user out of init in a Xnest/VNC > session. I am thinking something like a winecis user which would run > these scripts, fetch and the Xnest session as a service we could call > winecis. > > I did something similar recently for a stupid java service that had to > have an interactive gui. Thinking about it a bit more, I guess the email thing is kind of redundant since git can poll more often. I guess it really depends on how many build agents you want to have hanging out hammering git. To you want them to hammer git or hammer your mail server? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Nov. 25, 2009

Re: My script for doing testing

by Steven Edwards

On Wed, Nov 25, 2009 at 12:08 PM, Austin English <austinenglish(a)gmail.com> wrote: > The other neat thing is that it will run git fetch in a loop every 30 > minutes (again, overridable), so that you can run it in the morning > while waiting for AJ to commit. Once commits are made to the git > master branch (but not stable), the script will kick into motion. It would be nice to dummy email account subscribed to the commit messages that it could poll to trigger the checkout, build, test cycle. To make a Continuous Integration Service around it it should run as a background process under another user out of init in a Xnest/VNC session. I am thinking something like a winecis user which would run these scripts, fetch and the Xnest session as a service we could call winecis. I did something similar recently for a stupid java service that had to have an interactive gui. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Nov. 25, 2009

Re: openal32: Add alBufferSubDataEXT

by Chris Robinson

I'm not sure it's very appropriate to add this yet, since the extension isn't finalized. Until it's finalized, there could be changes that modify the API calls (I don't expect changes, but it's best to err on the side of caution, I think). The alBufferDataStatic patch is fine, though.

Nov. 25, 2009

Re: Whitespace cleanups

by Kai Blin

On Wednesday 25 November 2009 19:02:08 Ken Thomases wrote: > On Nov 25, 2009, at 11:13 AM, Nate Gallaher wrote: > > Ken Thomases wrote: > >> One important reason to avoid whitespace-only changes is it makes > >> git-blame essentially useless for finding the real source of functional > >> changes. > > > > But is that really important? git-bisect would put you on the other side > > of any whitespace changes, and a prudent bug-hunter should be referring > > to the commit logs anyway. > > Who says git-blame is only useful on occasions when it makes sense to > git-bisect? Or that one is hunting bugs. > > I often use git-blame precisely to figure out which commit log I need to be > looking at to understand why the code is the way it is. I see something in > the code which is done in a way I don't understand/expect. I git-blame to > see what commit introduced the code in that form. I get a commit ID. I > look up the commit to see what it contained, what the log message was, what > commits were around it, etc. There _is_ a -w option to git-blame that ignores whitespace, though. Adding two characters (possibly via an alias) is a small price to pay for non-braindead formatting imho. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Nov. 25, 2009

Re: Fixing the kernel32:actctx tests on Vista+

by Jacek Caban

Paul Vriens wrote: > On 11/25/2009 05:39 PM, Jacek Caban wrote: >> Hi Paul, >> >> Paul Vriens wrote: >>> Hi Jacek, >>> >>> You are the original author of these tests. Is there any reason the >>> "test3.manifest" name is reused? >>> >>> The tests currently crash (intermittently on some) on Vista+ and with >>> the attached patch things seem to get better. I'm just renaming one of >>> the manifest files so there are no duplicates in these tests. >> >> I don't remember much about these tests, but looking at the code I don't >> see any reason to reuse the name, so your patch looks good for me. > > Well, it was 2007 ;) > > Btw. another patch (see attached patch2) works as well and is > basically the same thing that Ge did back in September to these same > tests. > > So both work fine. Any favors for one over the other? Both seem good for me. I think that a new file name is slightly better, because it feels safer than cheating cache mechanisms. Jacek

Nov. 25, 2009

Re: Fixing the kernel32:actctx tests on Vista+

by Paul Vriens

On 11/25/2009 05:39 PM, Jacek Caban wrote: > Hi Paul, > > Paul Vriens wrote: >> Hi Jacek, >> >> You are the original author of these tests. Is there any reason the >> "test3.manifest" name is reused? >> >> The tests currently crash (intermittently on some) on Vista+ and with >> the attached patch things seem to get better. I'm just renaming one of >> the manifest files so there are no duplicates in these tests. > > I don't remember much about these tests, but looking at the code I don't > see any reason to reuse the name, so your patch looks good for me. Well, it was 2007 ;) Btw. another patch (see attached patch2) works as well and is basically the same thing that Ge did back in September to these same tests. So both work fine. Any favors for one over the other? -- Cheers, Paul.

Nov. 25, 2009

Re: Whitespace cleanups

by Ken Thomases

On Nov 25, 2009, at 11:13 AM, Nate Gallaher wrote: > Ken Thomases wrote: >> One important reason to avoid whitespace-only changes is it makes git-blame essentially useless for finding the real source of functional changes. >> > > But is that really important? git-bisect would put you on the other side of any whitespace changes, and a prudent bug-hunter should be referring to the commit logs anyway. Who says git-blame is only useful on occasions when it makes sense to git-bisect? Or that one is hunting bugs. I often use git-blame precisely to figure out which commit log I need to be looking at to understand why the code is the way it is. I see something in the code which is done in a way I don't understand/expect. I git-blame to see what commit introduced the code in that form. I get a commit ID. I look up the commit to see what it contained, what the log message was, what commits were around it, etc. How would git-bisect be helpful in that case? > There should be a path to eventual codebase sanity, no matter how slow. I think you're going to be disappointed. :-/ -Ken

Nov. 25, 2009