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

Re: work underway: Dependency on openal incoming

by Maarten Lankhorst

Hello Alexandre, Alexandre Julliard schreef: > Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > > >> 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. >> > > Openal missing at compile time or at runtime should be handled the same > way, i.e. by reporting no sound devices. It doesn't make sense to have > two different failure modes. > Mac OSX can only link directly to openal with -framework OpenAL, so dynamic linking is impossible. As a result dsound will fail to load if libopenal is missing. I don't think there is a better way to handle this without ugliness, I'm confident that all distributions are shipping a version of openal these days, even the 64-bits ones. Cheers, Maarten

Dec. 1, 2009

Re: work underway: Dependency on openal incoming

by Alexandre Julliard

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > 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. Openal missing at compile time or at runtime should be handled the same way, i.e. by reporting no sound devices. It doesn't make sense to have two different failure modes. -- Alexandre Julliard julliard(a)winehq.org

Dec. 1, 2009

Re: [PATCH 4/5] dsound: Add support for OpenAL IDirectSoundCaptureBuffer

by Maarten Lankhorst

Hi Chris, Chris Robinson schreef: > 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. > It's handled properly with the modulus. >> + 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)? > Woops, mild oversight there. cbSize is allowed to be sizeof(WAVEFORMATEXTENSIBLE)-sizeof(WAVEFORMATEX), or sizeof(WAVEFORMATEXTENSIBLE) (sloppy programming), but the error checking is a lot stricter compared to WAVEFORMATEX, so this is correct. >> + 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. > Theoretically you're right. I'll send an updated version. >> + 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) For bigger buffers we should probably just request up to a 500 ms buffer top, but I suppose there's no harm in wasting some extra space, as long as it's not excessive. I'll call it with buf_size / nBlockAlign for now, if an application requests a huge buffer and the code breaks, I will revisit this again. :) Cheers, Maarten.

Dec. 1, 2009

File owner permissions

by Ben Peddell

-----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-----

Dec. 1, 2009

Re: Introducing WineTestBot

by Austin English

On Mon, Nov 30, 2009 at 3:21 AM, Paul Vriens <paul.vriens.wine(a)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

Dec. 1, 2009

Re: dual platform win32/linux malware

by Sir Gallantmon

On Mon, Nov 30, 2009 at 8:53 PM, Dan Kegel <dank(a)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....

Dec. 1, 2009

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

by Ken Thomases

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

Dec. 1, 2009

Re: [PATCH 4/5] dsound: Add support for OpenAL IDirectSoundCaptureBuffer

by Chris Robinson

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).

Dec. 1, 2009

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

by James McKenzie

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_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. >> > > 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

Dec. 1, 2009

dual platform win32/linux malware

by Dan Kegel

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

Dec. 1, 2009