Introducing WineTestBot
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.
Re: Introducing WineTestBot
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.
Re: [1/3] WineD3D: Infrastructure to render swapchains to a FBO
2009/11/30 Stefan Dösinger ste...@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?
Re: [1/3] WineD3D: Infrastructure to render swapchains to a FBO
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.
Re: Introducing WineTestBot
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 ggeld...@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.
Re: [1/3] WineD3D: Infrastructure to render swapchains to a FBO
2009/11/30 Stefan Dösinger stefandoesin...@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.
[PATCH] kernel32: Respect the LANG environment variable on Mac OS.
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
RE: Introducing WineTestBot
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. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
joerg-cyril.hoe...@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.
Re: [PATCH] [Server]: when getting the status of an exception, ensure the debugger continue information is not erased when releasing objects
Eric Pouech eric.pou...@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
julli...@winehq.org
Re: mciqtz32: Fix open/close omissions.
On 11/30/2009 01:47 PM, joerg-cyril.hoe...@t-systems.com wrote: Regards, Jörg Höhle Hi Jörg, You're mixing tabs and spaces here. -- Cheers, Paul.
Re: mciavi: Simplify play loop.
On 11/30/2009 01:51 PM, joerg-cyril.hoe...@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.
Re: wine.inf: Remove obsolete and duplicate entries.
On 11/30/2009 02:08 PM, joerg-cyril.hoe...@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.
Re: Implement a stub for PrintWindow in user32
Luke Benstead kaz...@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.
Re: mciqtz32: Fix open/close omissions.
You need to provide more information why is this change required, and what is the problem you are trying to fix. -- Dmitry.
Re: comctl32: Implementation the WM_GETTEXT processing of datetime control
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.
Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)
Paul Chitescu pa...@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 julli...@winehq.org
Re: comctl32: Implementation the WM_GETTEXT processing of datetime control
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.
Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)
On Monday 30 November 2009 04:02:03 pm you wrote: Paul Chitescu pa...@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 julli...@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
Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)
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 pa...@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 julli...@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.
Fedora users, please test mci patch about time-out/hanging machine
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?!?
Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)
Paul Chitescu pa...@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 julli...@winehq.org
Re: services.exe: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible (try 2)
Paul Chitescu pa...@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 julli...@winehq.org
today's git broke winetricks gecko :-(
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.
Re: services.exe: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible (try 2)
On Monday 30 November 2009 05:51:35 pm Alexandre Julliard wrote: Paul Chitescu pa...@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 julli...@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).
Re: Fedora users, please test mci patch about time-out/hanging machine
joerg-cyril.hoe...@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
Re: comctl32: Implementation the WM_GETTEXT processing of datetime control
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.
Re: comctl32: Implementation the WM_GETTEXT processing of datetime control
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.
Re: services.exe: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible (try 2)
Paul Chitescu pa...@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 julli...@winehq.org
Introducing WineTestBot
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.
Re: [PATCH 1/3] ole32: Add test for CoLockObjectExternal with fLastUnlockReleases as FALSE.
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.
RE: Introducing WineTestBot
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.
Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
On Nov 30, 2009, at 4:35 AM, joerg-cyril.hoe...@t-systems.com joerg-cyril.hoe...@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.
Re: [PATCH] [Server]: when getting the status of an exception, ensure the debugger continue information is not erased when releasing objects
Alexandre Julliard a écrit :
Eric Pouech eric.pou...@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
nt...@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 ser...@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)
Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
On Mon, Nov 30, 2009 at 22:01, Ken Thomases k...@codeweavers.com wrote: On Nov 30, 2009, at 4:35 AM, joerg-cyril.hoe...@t-systems.com joerg-cyril.hoe...@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
Re: [PATCH] [Server]: when getting the status of an exception, ensure the debugger continue information is not erased when releasing objects
Eric Pouech eric.pou...@orange.fr writes: what happens is something like: process P being debugged by D - while processing a debug event (fetched in P, P calls nt...@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 ser...@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 julli...@winehq.org
work underway: Dependency on openal incoming
Hi all, This message is mostly aimed towards package maintainers, since one of the discussions at wineconf last year was that package maintainers would like to hear in advance about changing dependencies. Wine's DirectSound implementation will, in the next release or the release after that, rely on OpenAL, the recommended library for linux or bsd's is openal-soft, and preferably a recent version, as old versions might miss certain experimental extensions that dsound will need. Mac users shouldn't need an external openal library, since it has its own openal implementation. Without openal at compile-time, dsound will still build, but report no sound devices found. Some games or other applications may refuse to run if no dsound devices are found, so its recommended that you build with openal. If openal is compiled in, but missing at runtime, dsound.dll will refuse to load, which probably means most games will not run either. Cheers, Maarten
Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
On Nov 30, 2009, at 5:31 PM, Bruno Haible wrote: 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_ 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. By this logic, virtual no end-user program on any given Mac is compliant. Gettext and POSIX-compliance is one thing. The user-desired behavior for Mac programs is another. 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. It is Terminal.app itself which is setting LANG for all shells it creates, by default. The user is most likely oblivious to this fact. 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. It's not about mapping from MacOS X locale names (whatever you mean by that) that's the problem. It's the fact that no name or simple string properly represents the full range of settings available in System Preferences. 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. I would venture to say that the number of Mac users who will wonder that is vanishingly small. Just about the only thing that will get a Mac user wondering is if the behavior of programs deviates from the settings in System Preferences. I would further venture that the number of POSIX compliant programs on the system with which the user has any familiarity is negligible. By your definition (which I don't question), no Mac applications are compliant. 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. This is not a rare case. It's the default case. It will be nearly 100% of the time. Users do not set LANG; Terminal.app does! 2. If they do set LANG, POSIX requires the program to obey LANG. And Wine is applying for POSIX certification? News to me. 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. Very, very few Mac users use any program which uses gettext. 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. Buggy in a sense which completely ignores user expectation. That's not the sense in which I'd use that word. The vast majority of users of Wine on the Mac will expect what I've proposed and be surprised
Re: RFC: EM_FORMATRANGE Patch for Wine-1.1.33
Dan Kegel wrote: 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. Point taken. I still would like to know where to break this up. I know that the removal of the todo_wine should be separate from the main patch body. BTW, besides the three apps mentioned in http://bugs.winehq.org/show_bug.cgi?id=6254, what apps depend on this? I don't know. I had several apps that did not run under wine-1.1.6 but do under wine-1.1.7. I'm looking at this as well as the mismatched size of the Print Preview for Wordpad/Wordpad.exe. James McKenzie
dual platform win32/linux malware
The apocalypse approaches: http://ask.slashdot.org/article.pl?sid=09/12/01/0025213 Perhaps this will drive people towards using totally locked down systems...
Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
Ken Thomases wrote: On Nov 30, 2009, at 5:31 PM, Bruno Haible wrote: 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_ 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. By this logic, virtual no end-user program on any given Mac is compliant. Gettext and POSIX-compliance is one thing. The user-desired behavior for Mac programs is another. 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. It is Terminal.app itself which is setting LANG for all shells it creates, by default. The user is most likely oblivious to this fact. The idea behind most of the MacIntosh 'magic' is that the user is deliberately oblivous to this. I just ran the set command in a terminal.app session, of which I have several running right now, and it was set to en_US.utf8, which is what I expect because the 'American' flag is displayed in the top information bar (also called the 'Apple' bar.) Gert may want to run the set command in a terminal session and given what was said, the LANG setting should be en_ZA.utf8, which is what I expect for South African English. The Wine project could use this as a default with the Mac, which is not POSIX compliant. James McKenzie
Re: [PATCH 4/5] dsound: Add support for OpenAL IDirectSoundCaptureBuffer
Hi.
On Monday 30 November 2009 1:56:20 pm Maarten Lankhorst wrote:
+if (This-playing)
+{
+pos2 = This-format-nSamplesPerSec / 100;
+pos2 *= This-format-nBlockAlign;
+pos2 += pos1;
+if (!This-looping pos2 This-buf_size)
+pos2 = 0;
+else
+pos2 %= This-buf_size;
+}
Does non-looping capture let the write position get to This-buf_size? It
looks like a position of This-buf_size should set the position to 0 too, if
This-buf_size+1 would.
+if (format-wFormatTag == WAVE_FORMAT_EXTENSIBLE)
+{
+WAVEFORMATEXTENSIBLE *wfe = (WAVEFORMATEXTENSIBLE*)format;
+if (!IsEqualGUID(wfe-SubFormat,
KSDATAFORMAT_SUBTYPE_IEEE_FLOAT))
+return DSERR_BADFORMAT;
+else if (format-cbSize sizeof(WAVEFORMATEXTENSIBLE)-
sizeof(WAVEFORMATEX))
+return DSERR_INVALIDPARAM;
+else if (format-cbSize sizeof(WAVEFORMATEXTENSIBLE)-
sizeof(WAVEFORMATEX)
+ format-cbSize != sizeof(WAVEFORMATEXTENSIBLE))
+return DSERR_CONTROLUNAVAIL;
+}
You should probably check the cbSize before accessing the extended
information, otherwise it may indicate that there isn't enough space for the
extended information. Also, is it necessary to reject formats with a higher
cbSize than needed (IIRC, Wine's tests showed some Windows versions allowed
it)?
+buf_format = alGetEnumValue(fmt_str);
Unfortunately, you can't call this function when a context is not set (it'll
probably work on some systems, but technically shouldn't). And setting a
context makes no sense for capture. Setting buf_format directly to the enum in
the switches should be all you need to do.. just make sure to initialize it to
0 so the check won't use it uninitialized.
+This-dev = alcCaptureOpenDevice(This-parent-device,
This-format-nSamplesPerSec, buf_format, This-buf_size);
Note that the buffer size given to OpenAL is in sample frames, not bytes. It's
not a direct problem here, per se, but it may be an issue if a large size is
requested (ie, where n samples would work, but n*2 or n*4 won't).
Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
On Nov 30, 2009, at 9:34 PM, James McKenzie wrote: 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. It is Terminal.app itself which is setting LANG for all shells it creates, by default. The user is most likely oblivious to this fact. The idea behind most of the MacIntosh 'magic' is that the user is deliberately oblivous to this. I agree that Wine (well, anything) should meet the user's expectations without the user having to even be aware of their expectations. Unfortunately, respecting LANG does not lead to this... I just ran the set command in a terminal.app session, of which I have several running right now, and it was set to en_US.utf8, which is what I expect because the 'American' flag is displayed in the top information bar (also called the 'Apple' bar.) Gert may want to run the set command in a terminal session and given what was said, the LANG setting should be en_ZA.utf8, which is what I expect for South African English. First, the language and formats have nothing to do with the keyboard layout (the U.S. flag in the input menu). But, more importantly for this discussion, the fact that LANG will be appropriate for you and probably Gert does not mean it will be appropriate often enough for Wine to rely on. As I have said, there are many ways in which users configure their language and formats settings that will not be properly reflected in LANG (and, indeed, cannot be). The Wine project could use this as a default with the Mac, which is not POSIX compliant. You are suggesting using a proxy for the real thing rather than the real thing. If we want to maintain the magic, Wine should just use the settings from System Preferences directly (via CFLocale, CFNumberFormatter, and CFDateFormatter), with an optional way to override them for those rare users who want Wine's behavior to deviate from the system's. LANG doesn't help maintain the magic. It's a hindrance. Regards, Ken
Re: dual platform win32/linux malware
On Mon, Nov 30, 2009 at 8:53 PM, Dan Kegel d...@kegel.com wrote: The apocalypse approaches: http://ask.slashdot.org/article.pl?sid=09/12/01/0025213 Perhaps this will drive people towards using totally locked down systems... Or just cause more insanity
Re: Introducing WineTestBot
On Mon, Nov 30, 2009 at 3:21 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: 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. Seconded! On a slightly related note, would it be possible to add a 16-bit display VM? I finally got around to testing wine on a 16-bit display again, and several things have regressed. It would be good to test the testsuite on windows in that configuration to see what happens. -- -Austin
File owner permissions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What do you think is the best course of action for setting the owner permissions on a file: 1. Base the file owner permissions on the DACL permissions of the groups the file owner is a member of? (My patch or similar) 2. Change the file owner permissions only if they are listed in the DACL? (Paul Chitescu's patch or similar) 3. Allow the file owner read/write/traverse access (u+rwX) to their own files by default? (similar to #2) 4. Bypass the file-owner-permissions-cannot-be-overridden issue by having a third-party trustee (like SYSTEM) own and have full access to the files. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksUuqAACgkQTHDAI68NsunuQACePqDXjcfvvDXhoEI0rH4WB5Ri 3+YAnjqioPVg9li+Axbo3vUMueqn9phd =pNiD -END PGP SIGNATURE-
