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

[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. 30, 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. 30, 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