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

Re: [3/5] imagehlp: Implement ImageAddCertificate
by Alexandre Julliard 01 Dec '09

01 Dec '09

Owen Rudge <orudge(a)codeweavers.com> writes: > + sd = &nt_hdr.OptionalHeader.DataDirectory[IMAGE_FILE_SECURITY_DIRECTORY]; > + > + sd->Size = dwSize; > + sd->VirtualAddress = dwOfs; > + > + TRACE("size = %x addr = %x\n", sd->Size, sd->VirtualAddress); > + > + /* write the header back again */ > + count = SetFilePointer(handle, dos_hdr.e_lfanew, NULL, FILE_BEGIN); > + > + if (count == INVALID_SET_FILE_POINTER) > + return FALSE; > + > + count = 0; > + > + r = WriteFile(handle, &nt_hdr, sizeof nt_hdr, &count, NULL); The virtual address is not necessarily the same as the disk offset. Also you should check the various header sizes and magic numbers. The existing code is broken in that respect too, but as long as it was only reading it wasn't a big problem. Once we start modifying the file it needs to be much more robust. -- Alexandre Julliard julliard(a)winehq.org

2 1

Introducing WineTestBot
by Greg Geldorp 01 Dec '09

01 Dec '09

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.

5 6

Re: [PATCH] mshtml: check for NULL return from allocations
by Jacek Caban 01 Dec '09

01 Dec '09

Hi Marcus, Marcus Meissner wrote: > Hi, > > Coverity thinks we miss NULL checks and yes, we do. > Added some. > > (...) > > - wstrbuf_init(&buf); > + if (!wstrbuf_init(&buf)) > + return E_OUTOFMEMORY; > range_to_string(This, &buf); > - if(buf.buf) > - *p = SysAllocString(buf.buf); > + *p = SysAllocString(buf.buf); > wstrbuf_finish(&buf); > > TRACE("ret %s\n", debugstr_w(*p)); > + if (!*p) > + return E_OUTOFMEMORY; > return S_OK; > } This check is not meant to check allocation failure, but to check if range_to_string set it to NULL. We even have a tests for this. More error handling is a good thing to do, but this check should remain unchanged. Thanks, Jacek

1 0

Re: [PATCH 2/2] jscript: Added lastIndex tests.
by Paul Vriens 01 Dec '09

01 Dec '09

On 11/30/2009 09:12 PM, Jacek Caban wrote: > --- > dlls/jscript/tests/regexp.js | 66 > ++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 66 insertions(+), 0 deletions(-) > > Hi Jacek, This one introduces test failures on Vista+ : http://test.winehq.org/data/tests/jscript:run.html Could you have a look? -- Cheers, Paul.

2 3

work underway: Dependency on openal incoming
by Maarten Lankhorst 01 Dec '09

01 Dec '09

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

3 5

Re: dlls/kernel32/path.c: Fix return values for UNC pathnames in GetLongPathNameW
by Alexandre Hardy 01 Dec '09

01 Dec '09

Thanks Paul, Right! Tried to implement it too fast! Other parts of the test code dereference the function pointer and I took my lead from there without checking properly. As far as the length goes, I don't really know much about UNC pathnames, so I'm not sure what exactly the result should be. I will need to read up to find an example that I can guarantee the length of. Kind regards Alexandre On Tue, Dec 1, 2009 at 12:52 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > On 12/01/2009 08:44 AM, Alexandre Hardy wrote: >> >> + length = (*pGetLongPathNameW)(unc_path,NULL,0); > > Why the brackets around *pGetLongPathNameW? > >> + ok(length>0,"GetLongPathNameA: Failed on UNC Pathname >> (length=%d)\n",length); > > You called the W-function so the ok text needs to be adjusted. You also know > the length so why not check explicitly? > > -- > Cheers, > > Paul. > -- -------------------------------------------------- Alexandre Hardy http://www.ahardy.za.net -- -------------------------------------------------- Alexandre Hardy http://www.ahardy.za.net

1 0

Re: dlls/kernel32/path.c: Fix return values for UNC pathnames in GetLongPathNameW
by Paul Vriens 01 Dec '09

01 Dec '09

On 12/01/2009 08:44 AM, Alexandre Hardy wrote: > + length = (*pGetLongPathNameW)(unc_path,NULL,0); Why the brackets around *pGetLongPathNameW? > + ok(length>0,"GetLongPathNameA: Failed on UNC Pathname (length=%d)\n",length); You called the W-function so the ok text needs to be adjusted. You also know the length so why not check explicitly? -- Cheers, Paul.

1 1

Re: [PATCH 4/5] dsound: Add support for OpenAL IDirectSoundCaptureBuffer
by Chris Robinson 01 Dec '09

01 Dec '09

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

2 1

File owner permissions
by Ben Peddell 01 Dec '09

01 Dec '09

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

1 0

dual platform win32/linux malware
by Dan Kegel 01 Dec '09

01 Dec '09

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

2 1