March 2010 - Wine-Devel - list.winehq.org

Re: [3/4] d3d9: Remove the double unlock test
by Henri Verbeet March 17, 2010

March 17, 2010

On 17 March 2010 11:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Windows 7 returns a different value than the test expects, and since its a todo_wine it seems no game depends on it. > http://bugs.winehq.org/show_bug.cgi?id=19862 depends on that.

1 0

Re: [1/4] d3d9: Remove old debug messages from the tests
by Henri Verbeet March 17, 2010

March 17, 2010

On 17 March 2010 11:22, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Adding a Sleep() instead isn't much of an improvement.

1 0

Re[2]: shell32/tests: add tests for the parser of SHELLEXECUTEINFO.lpFile [try 7]
by Ilya Basin March 17, 2010

March 17, 2010

There's a block of code in dlls/shell32/shlexec.c http://source.winehq.org/git/wine.git/?a=blob;f=dlls/shell32/shlexec.c;h=a8… It specially handles lpFile with '"' or containing spaces. Does anyone know a real situation when you need this handling? If I disable this block: /* separate out command line arguments from executable file name */ if (0 && !*sei_tmp.lpParameters && !appKnownSingular) { my tests succeed, but there may be others, that I'm currently trying to find.

1 0

Re: mmdevapi: Implement IMMDeviceEnumerator::GetDevice. patch
by Maarten Lankhorst March 17, 2010

March 17, 2010

Hoi Joris, On 16-03-10 21:31, Joris Huizer wrote: > Hello, Maarten Lankhorst, > > I was browsing through the recent patches in git, I noticed some possible issue in this code: > > + for (i = 0; i< MMDevice_count; ++i) > + { > + WCHAR *str; > + dev = (IMMDevice*)MMDevice_head[i]; > + IMMDevice_GetId(dev,&str); > + > + if (str&& !lstrcmpW(str, name)) > + { > + CoTaskMemFree(str); > + break; > + } > + CoTaskMemFree(str); > + } > + if (dev) > + { > + IUnknown_AddRef(dev); > + *device = dev; > + return S_OK; > + } > > I'm not sure whether this can happen, but in case the name isn't found at all, this will assign the last device in the MMDevice_head[] array (as far as I can see?) > In case this is an issue, a simple fix would be, to make the check look like this instead: > You're right, it's a bug. But don't worry about fixing it, at the moment it's not an issue, since nobody is creating a device, unless you create the registry keys for it manually. I have a real fix, where I'm starting to implement IMMDevice by populating it with the results from OpenAL library, but I'm waiting with implementing mmdevapi until the next wine release is out. There will likely be some fallout from merging that code. :) Please CC wine-devel in the future Cheers, Maarten

1 0

Re: [PATCH 2/2] cmd: Adds shlwapi library to cmd.exe's Makefile.in
by Dan Kegel March 17, 2010

March 17, 2010

Each patch in a series must compile and pass all tests, so if you need shlwapi for patch 1, then you have to include it in patch 1 (and then you just have one patch, not a series).

1 0

Re: On cygwin, these programs fails because they lack __wargv definition. So adding -mno-cygwin flag tell winegcc to link them with msvcrt instead of libc
by Alexandre Julliard March 16, 2010

March 16, 2010

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > --- > programs/cmd/Makefile.in | 2 +- > programs/dxdiag/Makefile.in | 2 +- > programs/explorer/Makefile.in | 2 +- > programs/extrac32/Makefile.in | 2 +- > programs/mshta/Makefile.in | 2 +- > programs/reg/Makefile.in | 2 +- > programs/start/Makefile.in | 2 +- > programs/svchost/Makefile.in | 2 +- > programs/termsv/Makefile.in | 2 +- > programs/uninstaller/Makefile.in | 2 +- > programs/winebrowser/Makefile.in | 2 +- > programs/winedevice/Makefile.in | 2 +- > programs/winepath/Makefile.in | 2 +- > 13 files changed, 13 insertions(+), 13 deletions(-) These apps don't link to msvcrt on purpose. If things are broken on cygwin that needs to be handled in winegcc, you shouldn't have to touch the makefiles. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 04/16] [DbgHelp]: made the ELF mapping code easier to use
by Alexandre Julliard March 16, 2010

March 16, 2010

Eric Pouech <eric.pouech(a)orange.fr> writes: > - now exporting the file mapping facility to the debug info loader which need it > - allow to mark a section as to be kept (after debug info loading has been done) This breaks the non-ELF builds. -- Alexandre Julliard julliard(a)winehq.org

2 2

DirectX 2D?
by Dan Kegel March 16, 2010

March 16, 2010

I looked at the ie9 preview. You have to set the windows version to 7, but then it needs ie8 and "directx 2d" installed. I've added a win7 verb to winetricks, and would accept an ie8 verb patch if someone sent it, but I suspect DirectX 2D might be a tough nut to crack.

5 4

Re: winhttp/url.c: Fix of invalid behaviour of WinHttpCrackUrl
by Paul Vriens March 16, 2010

March 16, 2010

On 03/15/2010 10:56 PM, Maciej Borsz wrote: > Fix of invalid behaviour of WinHttpCrackUrl when in url is '@'. > > For example: > WinHttpCrackUrl(L"http://example.net/path?var1=example(a)example.com&var2=x&var3=y > <http://example.net/path?var1=example(a)example.com&var2=x&var3=y>", NULL, > NULL, sth) > > returned: > scheme(L"http") host(L"example.com <http://example.com>&var2=x&var3=y") > port(80) path(L"") extra(L"") > > instead of: > scheme(L"http") host(L"example.net <http://example.net>") port(80) > path(L"/path/") extra(L"?var1=example(a)example.com > <mailto:example(a)example.com>&var2=x&var3=y") > Hi Maciej, Could you add a test for this to our testsuite? You could use winetestbot (https://winetestbot.geldorp.nl/index.pl) to verify the behavior on several Windows flavors if needed. -- Cheers, Paul.

2 1

The shlwapi:istream tests and Microsoft Security Essentials
by Paul Vriens March 16, 2010

March 16, 2010

Hi, I was wondering why I (out of all those boxes) had several failures for these tests on some of my XP and Vista boxes. Turns out that you get these failures when MSE is active. I just ran the tests on a clean XP-SP3 box (up-to-date) and no failures. Installing MSE (and downloading the latest signatures) is enough to show a multitude of test failures. Turning 'real time monitoring' off or excluding the test executable makes the tests succeed again. Most of the failures are of the E_ACCESSDENIED nature btw. Does this make sense? If the test failures are valid, should I change the tests to cope with this? -- Cheers, Paul.

2 4