July 2015 - Wine-Devel - list.winehq.org

Processing flags before files in regsvr32
by Hugh McMaster July 15, 2015

July 15, 2015

After investigating bug 38870 [1], I came up with some possible solutions to this problem. 1. Duplicate argv. 2. Copy the filename argument into a dynamically allocated array. 3. Copy the filename's iteration number (the 'n' of argv[n]) into a dynamically allocated array. 4. Use NULL pointers after processing to determine whether an argument is a flag or a filename. Of these answers, option four is the lightest and easiest to implement. It is also efficient. The idea is to assign argv[i] = NULL after we have processed an argument that is a flag. So, I'm proposing something like this pseudo-code (there is an actual diff below): for (i = 1; i < argc; i++) { if (is a flag) { do something; argv[i] = NULL; } } for (i = 1; i < argc; i++) { if (argv[i]) /* only filenames are valid */ do something; } diff --git a/programs/regsvr32/regsvr32.c b/programs/regsvr32/regsvr32.c index 449124f..ef895e0 100644 --- a/programs/regsvr32/regsvr32.c +++ b/programs/regsvr32/regsvr32.c @@ -270,8 +270,13 @@ int wmain(int argc, WCHAR* argv[]) output_write(STRING_USAGE); return 1; } + argv[i] = NULL; } - else + } + + for (i = 1; i < argc; i++) + { + if (argv[i]) { WCHAR *DllName = argv[i]; int res = 0; The proposed changes work correctly, both with a test DLL and also MediaInfo program from the bug. Any comments and suggestions are welcome. [1] https://bugs.winehq.org/show_bug.cgi?id=38870

2 2

Re: [4/7] msvcirt: Implement ios static locking (resend)
by Piotr Caban July 15, 2015

July 15, 2015

On 07/13/15 21:39, Iván Matellanes wrote: > > +/* ?x_lockc(a)ios@@0U_CRT_CRITICAL_SECTION@@A */ > +CRITICAL_SECTION ios_static_lock; > /* ?unsetf(a)ios@@QAEJJ(a)Z */ > @@ -1322,6 +1327,12 @@ static void init_io(void *base) > init_streambuf_rtti(base); > init_ios_rtti(base); > #endif > + InitializeCriticalSection(&ios_static_lock); > +} > + > +static void free_io(void) > +{ > + DeleteCriticalSection(&ios_static_lock); > } Please initialize the critical section statically (e.g. MSVCRT_file_cs is initialized that way in dlls/msvcrt/file.c). Thanks, Piotr

1 0

Re: [1/2] gdi32: EnumFontFamilies should enumerate substituted fonts when directly asked for.
by Alexandre Julliard July 15, 2015

July 15, 2015

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > I.e. EnumFontFamilies(NULL) won't enumerate substituted fonts, but > EnumFontFamilies("MS Shell Dlg") will do. > > Part1 of the fix for bug 19289. It breaks the tests here: ../../../tools/runtest -q -P wine -T ../../.. -M gdiplus.dll -p gdiplus_test.exe.so font && touch font.ok font.c:756: Test failed: wrong face name MS Shell Dlg font.c:767: Test failed: wrong face name MS Shell Dlg -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: dwrite: Fix transform matrix usage for pixel snapping
by Marvin July 14, 2015

July 14, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15314 Your paranoid android. === wvistau64 (64 bit layout) === layout.c:3395: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 === w2008s64 (64 bit layout) === layout.c:3395: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859

1 0

Re: msxml3: Handle NULL parameter in IXMLDOMElement::get_ownerDocument().
by Nikolay Sivov July 14, 2015

July 14, 2015

On 14.07.2015 15:09, Zhenbo Li wrote: > --- > dlls/msxml3/element.c | 2 ++ > dlls/msxml3/tests/domdoc.c | 3 +++ > 2 files changed, 5 insertions(+) > In principle this is most likely fine, but I'd really prefer to have similar test for all node types that support this method, so we can move a check directly to node_get_owner_doc(). For those additional tests it would be better to add a new test function called test_get_ownerDocument(). Next step would be to make this test run on all document versions (3, 4 and 6), but that should be a separate patch, and I'm not asking you to work on it.

1 0

Re: [1/2] windowscodecs/tests: Add some tests for loading truncated GIF images.
by Vincent Povirk July 13, 2015

July 13, 2015

Series looks good to me, but I'm not sure what you're trying to pull by putting an obviously correct fix in a patch labeled "tests".

2 1

Re: gdiplus: Move the burden of supporting GIF encoding to the WIC backend.
by Vincent Povirk July 13, 2015

July 13, 2015

I don't have a strong opinion on this, but committing this before we have support in WIC seems a bit sideways? What we were doing before was broken, but this just makes it broken in a different way. Before, we weren't reporting all formats native does, but now we're reporting formats we can't encode. So, this is just going to break or fix applications at random?

2 1

Re: windowscodecs: Add support for 8bpp grayscale TIFF with 8bpp alpha.
by Vincent Povirk July 13, 2015

July 13, 2015

Looks good to me, thanks.

1 0

Re: [PATCH 4/5] wined3d: Don't run check_filter() on core contexts.
by Henri Verbeet July 13, 2015

July 13, 2015

On 10 July 2015 at 00:06, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > The code uses glBegin() / glEnd() and other APIs removed from core > profile. > --- > In theory we could fix check_filter() to work on core profile but it > doesn't seem to be useful there. I probably agree about the limited usefulness of check_filter() on core profiles, but at the same time it seems that most of the functionality needed to make it work there would be needed for other capability tests anyway.

3 3

Re: (resend 2)[2/5]hidclass.sys: Implement a report ring buffer
by Henri Verbeet July 13, 2015

July 13, 2015

On 10 July 2015 at 21:39, Aric Stewart <aric(a)codeweavers.com> wrote: > +typedef struct __ReportRingBuffer Did you borrow this from somewhere? Identifiers starting with double underscore are reserved. (And using a single underscore instead isn't much better.) The naming is also inconsistent with the existing code. And I have to say that goes for much of the rest of the series as well. There seems to be no consistent style from one patch to the next, and sometimes within the same structure. (E.g. __WINE_ELEMENT, __WINE_HID_REPORT, etc.) And of course most of this patch is unused code until patch 5/5 when RingBuffer_Create() is actually called. > +struct __ReportRingBuffer* RingBuffer_Create(UINT buffer_size) > +{ > + ReportRingBuffer *ring; > + ring = HeapAlloc(GetProcessHeap(), 0, sizeof(*ring)); > + if (!ring) > + return NULL; > + ring->start = ring->end = 0; > + ring->size = 32; > + ring->buffer_size = buffer_size; > + ring->pointer_alloc = 5; > + ring->pointers = HeapAlloc(GetProcessHeap(), 0, sizeof(int) * 5); > + memset(ring->pointers, 0xff, sizeof(int) * 5); > + ring->buffer = HeapAlloc(GetProcessHeap(), 0, buffer_size * ring->size); > + InitializeCriticalSection(&ring->lock); > + ring->lock.DebugInfo->Spare[0] = (DWORD_PTR)(__FILE__ ": RingBuffer.lock"); > + return ring; > +} Why handle allocation failure for "ring", but not for "ring->pointers" and "ring->buffer"? Why did you pick "5" for the initial size of "ring->pointers"? Seems like an odd choice. > +VOID RingBuffer_Destroy(struct __ReportRingBuffer *ring) Why use "VOID"? Are you concerned "void" may not be available? > + if (size < 2 || size > 256 || size == ring->size) > + return; What's special about 2 and 256? And if this does nothing, why would you ever call the function like that? > + new_buffer = HeapAlloc(GetProcessHeap(), 0, ring->buffer_size * size); > + HeapFree(GetProcessHeap(), 0, ring->buffer); > + ring->buffer = new_buffer; Why bother with "new_buffer" if you're not going to handle failures?

2 2

Re: [PATCH 2/5] rpcrt4: Set CorrDespIncrement to the size of the (non-range) /robust payload.
by Dmitry Timoshkov July 13, 2015

July 13, 2015

Huw Davies <huw(a)codeweavers.com> wrote: > +static void test_NdrCorrelationInitialize(void) > +{ > + MIDL_STUB_MESSAGE stub_msg; > + BYTE buf[256]; > + > + memset( &stub_msg, 0, sizeof(stub_msg) ); > + memset( buf, 0, sizeof(buf) ); > + > + NdrCorrelationInitialize( &stub_msg, buf, sizeof(buf), 0 ); > + ok( stub_msg.CorrDespIncrement == 2 || > + broken(stub_msg.CorrDespIncrement == 0), /* <= Win 2003 */ > + "got %d\n", stub_msg.CorrDespIncrement ); > + > + stub_msg.CorrDespIncrement = 1; > + NdrCorrelationInitialize( &stub_msg, buf, sizeof(buf), 0 ); > + ok( stub_msg.CorrDespIncrement == 1, "got %d\n", stub_msg.CorrDespIncrement ); > +} Probably having memset() calls before both tests would make it more convincing. -- Dmitry.

2 1

Re: (resend 2)[1/5]hidclass.sys: Implement helper IoCallMinidriver
by Henri Verbeet July 13, 2015

July 13, 2015

On 10 July 2015 at 21:39, Aric Stewart <aric(a)codeweavers.com> wrote: > +NTSTATUS IoCallMinidriver(ULONG code, DEVICE_OBJECT *device, VOID *in_buff, ULONG in_size, VOID *out_buff, ULONG out_size) DECLSPEC_HIDDEN; This is unused until patch 3/5. It also seems like a really bad idea to name internal helper functions like Windows functions. > + if (out_size) > + { > + buffer = HeapAlloc(GetProcessHeap(), 0, out_size); > + memcpy(buffer, out_buff, out_size); > + } Either out_buff and out_size are really badly named, or this is really suspicious.

2 1

Re: [1/2] gdi32: EnumFontFamilies should enumerate substituted fonts when directly asked for.
by Marvin July 13, 2015

July 13, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15259 Your paranoid android. === w2000pro (32 bit font) === font.c:4054: Test failed: Times New Roman Baltic should be enumerated font.c:4056: Test failed: Times New Roman Baltic should be enumerated === wvistau64 (32 bit font) === The test timed out === wvistau64 (64 bit font) === The test timed out

1 0

Re: d3drm: Add stubs for IDirect3DRMDevice methods.
by Stefan Dösinger July 13, 2015

July 13, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, You aren't returning the version 1 interface from QueryInterface. Am 2015-07-11 um 14:40 schrieb Aaryaman Vasishta: > if (IsEqualGUID(riid, &IID_IDirect3DRMDevice3)) > *out = (IUnknown*)&object->IDirect3DRMDevice3_iface; > - else > + else if (IsEqualGUID(riid, &IID_IDirect3DRMDevice2)) > *out = (IUnknown*)&object->IDirect3DRMDevice2_iface; > + else > + *out = (IUnknown*)&object->IDirect3DRMDevice_iface; You can call QueryInterface instead of doing GUID checks like this. Just initialize ref = 0, then call QI and you'll return a ref = 1 device. Another option, if you like this better, is to always return e.g. a IDirect3DRMDevice3 from Direct3DRMDevice_create, remove the riid parameter and do the QueryInterface in the caller. In this case init the refcount to 1 and call device3_Release in the caller after calling QI to obtain the right interface. The first 3 patches look good to me. I'll ack them tomorrow. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVok1NAAoJEN0/YqbEcdMwlFcQAJUgHXSjnseG9zIMJuKwiOoU K0IeSIAODnpT/+Mqc307owC7WBnKhTu4XLmZA1F7NxTxqdIcH85BsYx/LdLSeipq Y9KnTOg6dD00bNrujqyoZ5RmFI/pA+BXwhNXrwfbFg+RLr21ecQTpfRuDn3ENmPM VjWPHsfd4QIRqd+0Qo4LHAAS4UDmMm/avLdN+Gh5AOsDvOQYWW6reaerxYz6k61h rlkZwu1gLsSFTsA/PGz4W3nacVZkfcH8JourB80CJ/+bdPj1DfVImCpa2sx/WQ3g KMzwmR4MnS0n8/F2wGsqx/VMIKQ3zBblWVy4ZkZaMao6wA5IOoISSFXWrQlfUZrS GU5sRGwyVlaYK8qCzBOn3TdHhrrNLpg5hHkCqpN2JM1IgNYVaMevjZ+ISJhvaKXO GlQKwxOdB0M/SRWIPQ2261eQG/31lGEYm9ocu7i4USmNkaVZZCKlBt6wqsbmj6hF 7J2eU2KtfUoJwRozZRPaEdcKa0Xdp9AfrOrq4wilvEpIuUBI2leVVpOBQrbDD1c6 Z7/z8I1hmIw8ZPNl9NIIx7IyRrtnV3GBFG8rmWfRkHMMmIlZKqnC7+Yzgj5UF7Ai vr89VCzoAGj1Du/Xr8x5vmciLAdoRVNNTqV6QTPYqOgOQkodyls8RxH/IwM1sH/6 ZHUuK1kI7/vyX2WkYPi1 =1vdj -----END PGP SIGNATURE-----

3 3

Looking at Bugzilla Bug 38665 - Toontown Rewritten Launcher under Wine/FreeBSD gives "ValueError: Empty certificate data"
by Neel Chauhan July 12, 2015

July 12, 2015

Hi, Can you please look at the Wine Bugzilla Bug 38665. The URL is: https://bugs.winehq.org/show_bug.cgi?id=38665 Thanks, Neel Chauhan

1 0

Re: (resend)[1/5]hidclass.sys: Implement helper IoCallMinidriver
by Dmitry Timoshkov July 10, 2015

July 10, 2015

Aric Stewart <aric(a)codeweavers.com> wrote: > +HRESULT IoCallMinidriver(ULONG code, PDEVICE_OBJECT device, PVOID in_buff, ULONG in_size, PVOID out_buff, ULONG out_size) What 'HRESULT' is supposed to represent in the kernel space? (Especially when actually an NTSTATUS is being returned). That applies to all patches in the series. Also it would be nice to get rid of all LPJUNK style types used all over the place. -- Dmitry.

3 2

Re: [PATCH 5/5] wined3d: Don't install fog compatibility wrappers in core profile contexts.
by Stefan Dösinger July 10, 2015

July 10, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-07-10 um 00:06 schrieb Matteo Bruni: > - if (!gl_info->supported[EXT_FOG_COORD]) > + if (!gl_info->supported[EXT_FOG_COORD] && gl_info->supported[WINED3D_GL_LEGACY_CONTEXT]) Shouldn't that depend on the chosen vertex pipeline implementation rather than the context type? I don't think we need those wrappers in legacy contexts if we're using GLSL for vertex processing. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVn66UAAoJEN0/YqbEcdMwwaMP/1NL3D/IB/tP6Ch1CH/SkwLc LVHe5/NZNTJNXCAj3EH+8yKvDZig3aC3yNemO+KZhu+UKdK4iOeoJeHGAxyu1Fa+ d4Vh8aMyG8QFfKDIiaRG8/qxL18HwBBVnp0KtAq2eOB8847XdL0sXGPW0SHiDaWZ 57oE3W85Ym1hfdn6RhRx0QGMFsLlil5d9vd6IF8yAXluItNNH+SDxdVmBwg2IfrA hpH6f5GcEtqG4VZd8ete6DwgEqEQDtvqdlRlcf/HTUSu8RF0Kr+y0SC00Q1NUfEb /QHboR9Vc1Uwca8MZqm9PgsT9aeZgHv5f7K79AewFUnHqj7ZckGM9ptHuPS2pWzM ChHNghvP22LCnhndKl71WJqFTCobGfjNwmD3+ffedBmu7UNLfl2hKSbQCpr3cCCa NDxKlUATuZWKpqJfGrcMbt10grgGolZfbGM99/ngQdeILZc7uwHXveGQJYlerrCz s89ey8dQydozL/sh9QCllcUI58DVE0DOx7rYlvI4/mZMD1+E131JAdIiqDWQYnS5 EVViK+uBXYWTGlTOg1btU9TK0gpzcBSCu3WEfV+BnjhZdR18jQfOzYD1hvy8c36A wBalWpvI6Iqbe/5f32MniyBFaJA2CCaqqZgd5sVx3Y0Y7mhfMk/kgC0vdc9h4tgh N77kUu44pDmGazZwxmjM =6Cds -----END PGP SIGNATURE-----

2 1

Re: msi/tests: Avoid test failures on win2k3.
by Marvin July 10, 2015

July 10, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15219 Your paranoid android. === wvistau64 (32 bit install) === The test timed out === w7u (32 bit install) === Failure running script in VM: timed out waiting for the child process

1 0

Re: crossover programs missing from source code
by Theodore Dubois July 10, 2015

July 10, 2015

I'm not really interested in the source code, I just want to know what the programs do. And yes, I forgot about ntoskrnl, the only dll with an exe extension. I generated that list using ls, grep, and diff, and didn't look over it that carefully. ~Theodore On Jul 05, 2015, at 10:09 AM, Ben Klein <shacklein(a)gmail.com> wrote: In particular, all the cx* programs are Crossover-specific and should not appear in upstream wine at any point. On 6 July 2015 at 02:07, Vincent Povirk <madewokherd(a)gmail.com> wrote: The LGPL doesn't require us to publish the source code of individual .exe.so or .dll.so binaries if we're not basing them on LGPL code. I haven't checked the whole list, but most of these are programs CodeWeavers developed internally and thus controls the copyright on, and they mostly exist for integration with other components of CrossOver. That doesn't mean we can't or shouldn't publish the code, just that we probably haven't considered it. At the very least, I think we want to publish the source code of anything that exists for Windows compatibility. Note that ntoskrnl.exe is actually in the dlls/ directory of the Wine source tree, and it should be there in the CrossOver/Wine source code as well.

3 3

Re: Adding RID_TYPEHID RawInput support to user32
by Aric Stewart July 10, 2015

July 10, 2015

On 7/6/15 10:53 AM, Nathan Schulte wrote: > On 07/06/2015 07:40 AM, Aric Stewart wrote: >> Hello there, Sorry for the delay I was away on vacation until today. >> >> Yes, RawInput support should go through hid.dll. That is actually part of the reason I am doing the hid work the ways I am doing it. I want to be able to fully and correctly support RawInput as well as dinput, xinput and winmm joysticks. >> >> For wine work, you can have all the user32 stuff using the hid.dll HidD_ and HidP_ functions as they can be considered user land work. If you find there are HidD_ or HidP_ function you need that are not implemented, then that can be done. >> >> Right now the hid.dll work has gotten in but I am just starting to get the underlying hid minidriver work in place. Without the minidriver work hid.dll will not do much. > > I found your recent discussion from April ("Wine Joysticks, seeking a plan"), as well as reviewed your current work to hid.dll. I've been learning about the stack as I go along, but it seems documented enough to get a grasp of. These are the minidrivers you're talking about? > > https://msdn.microsoft.com/en-us/library/windows/hardware/jj131707(v=vs.85)… > > You're thinking of creating one per platform/API (on the hosting side: Linux/evdev, (Unix/Linux?) X11, Unix/Mac *), or mirroring MS's setup? I'm not sure how the loading of those libraries works (I did see the HidRegisterMinidriver routine though), so maybe the question is inaccurate. So the next round of patches have been submitted so you can see my hidclass and minidriver work. The goal is to have all the system native minidriver be in the winehidminidriver.sys so that it can be independent from the graphics driver. Wine's hidclass.sys can handle multiple minidrivers in one service, so we should not need independent minidrivers for every platform. Which should be handy. > > On 07/06/2015 07:40 AM, Aric Stewart wrote: >> Yes all the user32 work will need to be done. >> >> Xinput is on my goal list also. Xinput should also be a client of hid.dll > > Sounds good. I'll try to help where I can. It sounds like I need to become more familiar with the system before I'm really useful. There are 3 places I can really use help. 1) Review patches: I always love good reviews on my patches. Leads to stronger code. 2) Above hid.dll: This is doing the development work on RawInput, Xinput, Dinput and such to become clients of the user level hid.dll functions to access joysticks and gamepads. This should mostly be learning the respective APIs and hooking them into HID. RawInput is probably the easiest as it does not do much with the HID reports other than just pass them on. 3) Linux minidrivers: I have implemented the OS/X minidriver because that is what I am most familiar with. There is work to implement the linux and linuxinput minidrivers. This is for someone familiar with or wants to become familiar with the lower level linux interfaces. -aric

3 7

wine CPU usage and CreateWaitableTimer
by andrea July 9, 2015

July 9, 2015

Hi, I'm trying to understand why AppleWin uses 100% CPU when running in wine vs ~1% in Windows. my case is wine 1.7.43 vs Windows 7 https://appdb.winehq.org/objectManager.php?sClass=version&iId=29403 https://bugs.winehq.org/show_bug.cgi?id=34945 basically 97% time is spent in a WaitForSingleObject on a semaphore signalled by a DirectSound IReferenceClock via AdvisePeriodic. The timer period is set to 1 millisecond. I have tried an other Windows call to create the timer: CreateWaitableTimer The latter uses about 50% CPU, so it is much better, but still not very good. This is true even on a simple app that does nothing other than waiting for this timer all the time. Does anybody know 1) is this normal? should these waits be almost free like they are in Windows? 2) what is the best implemented timer in wine that can be used for a periodic event (~1ms)? Thanks

3 10

Re: [5/7] ntdll: Implement RtlDecompressFragment.
by Matteo Bruni July 9, 2015

July 9, 2015

Hi, a bunch of nitpicks which you can take or ignore: 2015-07-09 3:07 GMT+02:00 Sebastian Lackner <sebastian(a)fds-team.de>: > Based on a patch by Michael Müller. > > For https://bugs.winehq.org/show_bug.cgi?id=37449 > > --- > dlls/ntdll/ntdll.spec | 2 > dlls/ntdll/rtl.c | 214 ++++++++++++++++++++++++++++++++++-- > dlls/ntdll/tests/rtl.c | 3 > dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 > 4 files changed, 210 insertions(+), 11 deletions(-) > > diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec > index 75dc647..ca3561d 100644 > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -513,7 +513,7 @@ > @ stdcall RtlDecodePointer(ptr) > # @ stub RtlDecodeSystemPointer > @ stdcall RtlDecompressBuffer(long ptr long ptr long ptr) > -@ stub RtlDecompressFragment > +@ stdcall RtlDecompressFragment(long ptr long ptr long long ptr ptr) > @ stub RtlDefaultNpAcl > @ stub RtlDelete > @ stdcall RtlDeleteAce(ptr long) > diff --git a/dlls/ntdll/rtl.c b/dlls/ntdll/rtl.c > index d9e448a..9a196d2 100644 > --- a/dlls/ntdll/rtl.c > +++ b/dlls/ntdll/rtl.c > @@ -1309,17 +1309,219 @@ NTSTATUS WINAPI RtlCompressBuffer(USHORT format, PUCHAR uncompressed, ULONG unco > } > } > > +/* decompress a single LZNT1 chunk */ > +static PUCHAR lznt1_decompress_chunk(UCHAR *dst, ULONG dst_size, UCHAR *src, ULONG src_size) PUCHAR -> UCHAR * > +{ > + UCHAR *src_cur = src, *src_end = src + src_size; > + UCHAR *dst_cur = dst, *dst_end = dst + dst_size; > + ULONG displacement_bits, length_bits; > + ULONG code_displacement, code_length; > + WORD flags, code; > + > + while (src_cur < src_end && dst_cur < dst_end) > + { > + flags = 0x8000 | *src_cur++; > + while ((flags & 0xFF00) && src_cur < src_end) It looks like we're mostly using lowercase in hex literals. > + { > + if (flags & 1) > + { > + /* backwards reference */ > + if (src_cur + sizeof(WORD) > src_end) > + return NULL; > + > + code = *(WORD *)src_cur; > + src_cur += sizeof(WORD); > + > + /* find length / displacement bits */ > + for (displacement_bits = 12; displacement_bits > 4; displacement_bits--) > + if ((1 << (displacement_bits - 1)) < dst_cur - dst) break; > + > + length_bits = 16 - displacement_bits; > + code_length = (code & ((1 << length_bits) - 1)) + 3; > + code_displacement = (code >> length_bits) + 1; > + > + if (dst_cur < dst + code_displacement) > + return NULL; > + > + /* copy bytes of chunk - we can't use memcpy() > + * since source and dest can be overlapping */ I would also mention that you can't use memmove() either because you actually want to copy any overlapping byte over and over again, as necessary. > + while (code_length--) > + { > + if (dst_cur >= dst_end) return dst_cur; > + *dst_cur = *(dst_cur - code_displacement); > + dst_cur++; > + } > + } > + else > + { > + /* uncompressed data */ > + if (dst_cur >= dst_end) return dst_cur; > + *dst_cur++ = *src_cur++; > + } > + flags >>= 1; > + } > + } > + > + return dst_cur; > +} > + > +/* decompress data encoded with LZNT1 */ > +static NTSTATUS lznt1_decompress(UCHAR *dst, ULONG dst_size, UCHAR *src, ULONG src_size, > + ULONG offset, ULONG *final_size, UCHAR *workspace) > +{ > + UCHAR *src_cur = src, *src_end = src + src_size; > + UCHAR *dst_cur = dst, *dst_end = dst + dst_size; > + ULONG chunk_size, block_size; > + WORD chunk_header; > + UCHAR *ptr; > + > + if (src_cur + sizeof(WCHAR) > src_end) > + return STATUS_BAD_COMPRESSION_BUFFER; > + > + /* skip over chunks which have a distance >= 0x1000 to the destination offset */ > + while (offset >= 0x1000 && src_cur + sizeof(WCHAR) <= src_end) > + { > + chunk_header = *(WORD *)src_cur; > + src_cur += sizeof(WCHAR); Why this mixing of WORD and WCHAR? They do match in practice but still... > + if (!chunk_header) goto out; > + chunk_size = (chunk_header & 0xFFF) + 1; > + > + if (src_cur + chunk_size > src_end) > + return STATUS_BAD_COMPRESSION_BUFFER; > + > + src_cur += chunk_size; > + offset -= 0x1000; > + } > + > + /* check if a chunk is included partially */ > + if (offset && src_cur + sizeof(WCHAR) <= src_end) > + { > + chunk_header = *(WORD *)src_cur; > + src_cur += sizeof(WCHAR); > + if (!chunk_header) goto out; > + chunk_size = (chunk_header & 0xFFF) + 1; > + > + if (src_cur + chunk_size > src_end) > + return STATUS_BAD_COMPRESSION_BUFFER; > + > + if (dst_cur >= dst_end) > + goto out; > + > + if (chunk_header & 0x8000) > + { > + /* compressed chunk */ > + if (!workspace) return STATUS_ACCESS_VIOLATION; > + ptr = lznt1_decompress_chunk(workspace, 0x1000, src_cur, chunk_size); I guess in theory you could avoid decompressing the whole chunk if you need less than the whole chunk to be decompressed. It's not strictly required though so if doing that makes the code too convoluted then ignore it. > + if (!ptr) return STATUS_BAD_COMPRESSION_BUFFER; > + if (ptr - workspace > offset) > + { > + block_size = min((ptr - workspace) - offset, dst_end - dst_cur); > + memcpy(dst_cur, workspace + offset, block_size); > + dst_cur += block_size; > + } > + } > + else > + { > + /* uncompressed chunk */ > + if (chunk_size > offset) > + { > + block_size = min(chunk_size - offset, dst_end - dst_cur); > + memcpy(dst_cur, src_cur + offset, block_size); > + dst_cur += block_size; > + } > + } > + > + src_cur += chunk_size; > + } > + > + /* remaining blocks */ > + while (src_cur + sizeof(WCHAR) <= src_end) > + { > + chunk_header = *(WORD *)src_cur; > + src_cur += sizeof(WCHAR); > + if (!chunk_header) goto out; > + chunk_size = (chunk_header & 0xFFF) + 1; > + > + if (src_cur + chunk_size > src_end) > + return STATUS_BAD_COMPRESSION_BUFFER; > + > + /* fill space with padding */ > + block_size = ((dst_cur - dst) + offset) & 0xFFF; > + if (block_size) > + { > + block_size = 0x1000 - block_size; > + if (dst_cur + block_size >= dst_end) > + goto out; > + memset(dst_cur, 0, block_size); > + dst_cur += block_size; > + } I'm probably dense but I don't follow this padding part. Don't you still need to memset to 0 the "remaining part" even if dst_end <= dst_cur + block_size (obviously stopping at dst_end) and then proceed to decompress the chunk? Unless you're not supposed to decompress the last chunk in that case? > + > + if (dst_cur >= dst_end) > + goto out; > + > + if (chunk_header & 0x8000) > + { > + /* compressed chunk */ > + dst_cur = lznt1_decompress_chunk(dst_cur, dst_end - dst_cur, src_cur, chunk_size); > + if (!dst_cur) return STATUS_BAD_COMPRESSION_BUFFER; > + } > + else > + { > + /* uncompressed chunk */ > + block_size = min(chunk_size, dst_end - dst_cur); > + memcpy(dst_cur, src_cur, block_size); > + dst_cur += block_size; > + } > + > + src_cur += chunk_size; > + } > + > +out: > + if (final_size) > + *final_size = dst_cur - dst; > + > + return STATUS_SUCCESS; > + > +} > + > +/****************************************************************************** > + * RtlDecompressFragment [NTDLL.@] > + */ > +NTSTATUS RtlDecompressFragment(USHORT format, PUCHAR uncompressed, ULONG uncompressed_size, > + PUCHAR compressed, ULONG compressed_size, ULONG offset, > + PULONG final_size, PVOID workspace) > +{ > + TRACE("0x%04x, %p, %u, %p, %u, %u, %p, %p\n", format, uncompressed, > + uncompressed_size, compressed, compressed_size, offset, final_size, workspace); > + > + switch (format & ~COMPRESSION_ENGINE_MAXIMUM) > + { > + case COMPRESSION_FORMAT_LZNT1: > + return lznt1_decompress(uncompressed, uncompressed_size, compressed, > + compressed_size, offset, final_size, workspace); > + > + case COMPRESSION_FORMAT_NONE: > + case COMPRESSION_FORMAT_DEFAULT: > + return STATUS_INVALID_PARAMETER; > + > + default: > + FIXME("format %u not implemented\n", format); > + return STATUS_UNSUPPORTED_COMPRESSION; > + } > +} > + > + > /****************************************************************************** > * RtlDecompressBuffer [NTDLL.@] > */ > -NTSTATUS WINAPI RtlDecompressBuffer(USHORT CompressionFormat, PUCHAR UncompressedBuffer, > - ULONG UncompressedBufferSize, PUCHAR CompressedBuffer, > - ULONG CompressedBufferSize, PULONG FinalUncompressedSize) > +NTSTATUS WINAPI RtlDecompressBuffer(USHORT format, PUCHAR uncompressed, ULONG uncompressed_size, > + PUCHAR compressed, ULONG compressed_size, PULONG final_size) > { > - FIXME("0x%04x, %p, %u, %p, %u, %p :stub\n", CompressionFormat, UncompressedBuffer, UncompressedBufferSize, > - CompressedBuffer, CompressedBufferSize, FinalUncompressedSize); > + TRACE("0x%04x, %p, %u, %p, %u, %p\n", format, uncompressed, > + uncompressed_size, compressed, compressed_size, final_size); > > - return STATUS_NOT_IMPLEMENTED; > + return RtlDecompressFragment(format, uncompressed, uncompressed_size, > + compressed, compressed_size, 0, final_size, NULL); > } > > /*********************************************************************** > diff --git a/dlls/ntdll/tests/rtl.c b/dlls/ntdll/tests/rtl.c > index c6a7023..99fd413 100644 > --- a/dlls/ntdll/tests/rtl.c > +++ b/dlls/ntdll/tests/rtl.c > @@ -1663,11 +1663,8 @@ static void test_RtlCompressBuffer(void) > memset(buf2, 0x11, sizeof(buf2)); > status = pRtlDecompressBuffer(COMPRESSION_FORMAT_LZNT1, buf2, sizeof(buf2), > buf1, buf_size, &final_size); > - todo_wine > ok(status == STATUS_SUCCESS, "got wrong status 0x%08x\n", status); > - todo_wine > ok(final_size == sizeof(test_buffer), "got wrong final_size %u\n", final_size); > - todo_wine > ok(!memcmp(buf2, test_buffer, sizeof(test_buffer)), "got wrong decoded data\n"); > ok(buf2[sizeof(test_buffer)] == 0x11, "too many bytes written\n"); > > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > index 11d1c62..0bb7d04 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > +++ b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > @@ -977,7 +977,7 @@ > @ stub RtlCustomCPToUnicodeN > @ stdcall RtlDecompressBuffer(long ptr long ptr long ptr) ntdll.RtlDecompressBuffer > @ stub RtlDecompressChunks > -@ stub RtlDecompressFragment > +@ stdcall RtlDecompressFragment(long ptr long ptr long long ptr ptr) ntdll.RtlDecompressFragment > @ stub RtlDelete > @ stdcall RtlDeleteAce(ptr long) ntdll.RtlDeleteAce > @ stdcall RtlDeleteAtomFromAtomTable(ptr long) ntdll.RtlDeleteAtomFromAtomTable > -- > 2.4.5 > >

2 1

Re: gdiplus: GdipConvertToEmfPlus parameter succ is optional
by Nikolay Sivov July 9, 2015

July 9, 2015

Please add a test for this.

1 0

Re: libwine: Add support for tcc
by Alexandre Julliard July 8, 2015

July 8, 2015

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -67,7 +67,7 @@ void DECLSPEC_NORETURN wine_switch_to_stack( void (*func)(void *), void *arg, vo > * Switch to the specified stack to call the function and return. > */ > > -#if defined(__i386__) && defined(__GNUC__) > +#if defined(__i386__) && (defined(__GNUC__) || defined(__TINYC__)) Are you planning to do this everywhere __GNUC__ is used? If so, this needs a better approach. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [7/7] msvcirt: Implement ios::unsetf
by Marvin July 8, 2015

July 8, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15160 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [6/7] msvcirt: Implement ios::setf
by Marvin July 8, 2015

July 8, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15159 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [5/7] msvcirt: Implement ios::flags
by Marvin July 8, 2015

July 8, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15158 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [4/7] msvcirt: Implement ios static locking (try 2)
by Marvin July 8, 2015

July 8, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15157 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [3/7] msvcirt: Implement ios stream locking (try 2)
by Marvin July 8, 2015

July 8, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15156 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [2/7] msvcirt: Implement ios object locking (try 2)
by Marvin July 8, 2015

July 8, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15155 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [1/7] msvcirt: Implement ios locking control (try 2)
by Marvin July 8, 2015

July 8, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15154 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [1/4] msvcirt: Implement ios locking control
by Piotr Caban July 8, 2015

July 8, 2015

Hi Iván, On 07/07/15 21:00, Iván Matellanes wrote: > + /* locking */ > + ios_obj.do_lock = 1; > + p_ios_clrlock(&ios_obj); > + ok(ios_obj.do_lock == 1, "expected 1 got %d\n", ios_obj.do_lock); > + ios_obj.do_lock = 0; > + p_ios_clrlock(&ios_obj); > + ok(ios_obj.do_lock == 1, "expected 1 got %d\n", ios_obj.do_lock); > + p_ios_setlock(&ios_obj); > + ok(ios_obj.do_lock == 0, "expected 0 got %d\n", ios_obj.do_lock); > + ios_obj.do_lock = -1; > + p_ios_setlock(&ios_obj); > + ok(ios_obj.do_lock == -2, "expected -2 got %d\n", ios_obj.do_lock); Please add a test that shows what happens with this->sb->do_lock value when ios_setlock and ios_clrlock are called (it should also be updated). Thanks, Piotr

2 1

Re: [2/2] server: Add fallback to desktop keystate in get_key_state wineserver call.
by Marvin July 8, 2015

July 8, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15142 Your paranoid android. === wvistau64 (64 bit input) === input.c:731: Test failed: 0 (a4/0): 10 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): 11 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a0 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a2 from 01 -> 00 unexpected

1 0

Re: [PATCH 4/5] wined3d: Add a setting for the maximum OpenGL version to use.
by Henri Verbeet July 8, 2015

July 8, 2015

On 6 July 2015 at 22:20, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > if (context_debug_output_enabled(gl_info)) > + ctx_flags = WGL_CONTEXT_DEBUG_BIT_ARB; > + ctx_attribs[ctx_attrib_idx++] = WGL_CONTEXT_MAJOR_VERSION_ARB; > + ctx_attribs[ctx_attrib_idx++] = gl_info->selected_gl_version >> 16; > + ctx_attribs[ctx_attrib_idx++] = WGL_CONTEXT_MINOR_VERSION_ARB; > + ctx_attribs[ctx_attrib_idx++] = gl_info->selected_gl_version & 0xffff; > + if (gl_info->selected_gl_version >= MAKEDWORD_VERSION(3, 2)) > + ctx_flags |= WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB; > + if (ctx_flags) > { > ctx_attribs[ctx_attrib_idx++] = WGL_CONTEXT_FLAGS_ARB; > - ctx_attribs[ctx_attrib_idx++] = WGL_CONTEXT_DEBUG_BIT_ARB; > + ctx_attribs[ctx_attrib_idx++] = ctx_flags; > } > ctx_attribs[ctx_attrib_idx] = 0; > > if (!(ctx = gl_info->p_wglCreateContextAttribsARB(hdc, share_ctx, ctx_attribs))) > { > - ERR("Failed to create a WGL context.\n"); > - context_release(ret); > - goto out; > + if (ctx_flags & WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB) > + { > + ctx_attribs[ctx_attrib_idx - 1] &= ~WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB; > + if (!(ctx = gl_info->p_wglCreateContextAttribsARB(hdc, share_ctx, ctx_attribs))) > + { > + ERR("Failed to create a WGL context.\n"); > + context_release(ret); > + goto out; > + } > + } > } > } I think this is starting to become complex enough that we'd probably benefit from a helper function to be able to share some of this with wined3d_adapter_init(). > + glGetIntegerv(GL_CONTEXT_PROFILE_MASK, &context_profile); > + if (glGetError() != GL_NO_ERROR) > + context_profile = 0; Should this perhaps just check for gl_info->p_wglCreateContextAttribsARB instead of eating errors? > + for (i = 0; i < ARRAY_SIZE(supported_gl_versions); ++i) > + { > + if (supported_gl_versions[i] <= wined3d_settings.max_gl_version) > + { > + if (supported_gl_versions[i] != wined3d_settings.max_gl_version) > + ERR_(winediag)("Requested GL version %u.%u which is unsupported, trying version %u.%u instead.\n", > + wined3d_settings.max_gl_version >> 16, wined3d_settings.max_gl_version & 0xffff, > + supported_gl_versions[i] >> 16, supported_gl_versions[i] & 0xffff); > + break; > + } > + } > + if (i == ARRAY_SIZE(supported_gl_versions)) > + { > + ERR_(winediag)("Requested invalid GL version %u.%u.\n", > + wined3d_settings.max_gl_version >> 16, wined3d_settings.max_gl_version & 0xffff); > + i = ARRAY_SIZE(supported_gl_versions) - 1; > + } This is a bit different than what I had in mind. I think max_gl_version should just be a maximum, and e.g. specifying 4.4 should just result in 3.2 at the moment. I think the winediag message should just happen if the registry setting is set, regardless of its actual value. (Except possibly if it's equal to the default value.) I.e. we also want to know if someone sets e.g. 3.2 while the default is currently 1.0 when reporting a bug. > + if (!get_config_key(hkey, appkey, "MaxGLVersion", buffer, size)) > + { > + unsigned int major, minor; > + > + if (sscanf(buffer, "%u.%u", &major, &minor) == 2) > + wined3d_settings.max_gl_version = MAKEDWORD_VERSION(major, minor); > + else > + ERR_(winediag)("Couldn't parse the requested maximum OpenGL version.\n"); > + } I'd make this a DWORD, if nothing else for consistency with MaxShaderModelVS etc. Perhaps "MaxVersionGL" would also more consistent for the naming, I'm not sure.

2 6

Re: [1/2] user32/tests: Add tests for calling GetKeyState from thread without message queue.
by Sebastian Lackner July 8, 2015

July 8, 2015

On 08.07.2015 13:31, Sebastian Lackner wrote: > For https://bugs.winehq.org/show_bug.cgi?id=27238 > > The test is marked as broken on VMs > Win2003, but manually testing confirms > that it still works the same way on Windows 7. There must be a difference > between simulated keyboard input and real keyboard input. > > NOTE: SendInput doesn't make a difference. > > --- > dlls/user32/tests/input.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 65 insertions(+) > The test failures on wvistau64 are not caused by my patch. Seems to be "just another random issue". ;) All tests passed on a second attempt: https://newtestbot.winehq.org/JobDetails.pl?Key=15143

1 0

Re: [1/2] user32/tests: Add tests for calling GetKeyState from thread without message queue.
by Marvin July 8, 2015

July 8, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15141 Your paranoid android. === wvistau64 (32 bit input) === input.c:731: Test failed: 0 (a4/0): 10 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): 11 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a0 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a2 from 01 -> 00 unexpected

1 0

Re: [PATCH 3/4] wined3d: Clip blits from / to the front buffer to the GL drawable.
by Henri Verbeet July 8, 2015

July 8, 2015

On 6 July 2015 at 23:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > -void surface_translate_drawable_coords(const struct wined3d_surface *surface, HWND window, RECT *rect) > +BOOL surface_clip_drawable_coords(const struct wined3d_surface *surface, HWND window, > + RECT *screen_rect, RECT *other) Can we please call these "src_rect" and "dst_rect" instead of "screen_rect" and "other"? It probably wouldn't hurt to mention "blt" somewhere in the function name either. > + ClientToScreen(window, &offset); ... > - ScreenToClient(window, &offset); > - OffsetRect(rect, offset.x, offset.y); > + /* Finally, translate the screen coordinate rectangle to client coordinates. */ > + OffsetRect(screen_rect, -offset.x, -offset.y); That change seems pretty pointless. > +BOOL wined3d_clip_blit(const RECT *clip_rect, RECT *clipped, RECT *other) "src_rect", "dst_rect".

2 2

Re: kernel32/tests: Attempt to avoid timeouts by increasing the baud rate.
by Marvin July 8, 2015

July 8, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15126 Your paranoid android. === w2000pro (32 bit comm) === comm.c:1552: test_AbortWaitCts timeout 500 handle 00000368 comm.c:1519: Changing CommMask on the fly for handle 00000368 after timeout 500 === w2008s64 (32 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:882: Test failed: WaitCommEvent error 0 comm.c:883: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: WaitCommEvent for EV_TXEMPTY took 1500 ms (timeout 1500) comm.c:888: Test failed: WaitCommEvent used 1500 ms for waiting comm.c:1552: test_AbortWaitCts timeout 500 handle 000000BC comm.c:1519: Changing CommMask on the fly for handle 000000BC after timeout 500

2 1

#include <hidclass.h>
by Aric Stewart July 8, 2015

July 8, 2015

Hi, So when my patch for include/ddk/hidport.h got included Alexandre add this line to the top: #include <hidclass.h> The problem is that my hidclass.sys work stopped building for me. In file included from ../../../wine-git/dlls/hidclass.sys/hid.h:27: ../../../wine-git/include/ddk/hidport.h:22:10: error: 'hidclass.h' file not found with <angled> include; use "quotes" instead #include <hidclass.h> ^~~~~~~~~~~~ "hidclass.h" 1 error generated. Is this a problem with my build setup or something else? hidclass.h is located in include/ddk/hidclass.h thanks, -aric

2 1

Re: [PATCH 1/5] wined3d: Use the correct texture coordinates in swapchain_blit() in the non-glBlitFramebuffer, NP2 case.
by Henri Verbeet July 7, 2015

July 7, 2015

On 6 July 2015 at 22:20, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/swapchain.c b/dlls/wined3d/swapchain.c > index 146f5d6..141abc2 100644 > --- a/dlls/wined3d/swapchain.c > +++ b/dlls/wined3d/swapchain.c > @@ -280,21 +280,21 @@ HRESULT CDECL wined3d_swapchain_get_gamma_ramp(const struct wined3d_swapchain *s > > /* A GL context is provided by the caller */ > static void swapchain_blit(const struct wined3d_swapchain *swapchain, > - struct wined3d_context *context, const RECT *src_rect, const RECT *dst_rect) > + struct wined3d_context *context, unsigned int src_w, unsigned int src_h, > + const RECT *src_rect, const RECT *dst_rect) > { > struct wined3d_surface *backbuffer = surface_from_resource( > wined3d_texture_get_sub_resource(swapchain->back_buffers[0], 0)); > - UINT src_w = src_rect->right - src_rect->left; > - UINT src_h = src_rect->bottom - src_rect->top; > GLenum gl_filter; > const struct wined3d_gl_info *gl_info = context->gl_info; > RECT win_rect; > UINT win_h; > > - TRACE("swapchain %p, context %p, src_rect %s, dst_rect %s.\n", > - swapchain, context, wine_dbgstr_rect(src_rect), wine_dbgstr_rect(dst_rect)); > + TRACE("swapchain %p, context %p, src_w %u, src_h %u, src_rect %s, dst_rect %s.\n", > + swapchain, context, src_w, src_h, wine_dbgstr_rect(src_rect), wine_dbgstr_rect(dst_rect)); > > - if (src_w == dst_rect->right - dst_rect->left && src_h == dst_rect->bottom - dst_rect->top) > + if (src_rect->right - src_rect->left == dst_rect->right - dst_rect->left > + && src_rect->bottom - src_rect->top == dst_rect->bottom - dst_rect->top) > gl_filter = GL_NEAREST; > else > gl_filter = GL_LINEAR; > @@ -528,7 +528,7 @@ static void swapchain_gl_present(struct wined3d_swapchain *swapchain, const RECT > if (swapchain->desc.swap_effect == WINED3D_SWAP_EFFECT_FLIP && !once++) > FIXME("WINED3D_SWAP_EFFECT_FLIP not implemented.\n"); > > - swapchain_blit(swapchain, context, &src_rect, &dst_rect); > + swapchain_blit(swapchain, context, back_buffer->pow2Width, back_buffer->pow2Height, &src_rect, &dst_rect); > } > > if (swapchain->num_contexts > 1) I may be missing something subtle here, but wouldn't it be better to just replace src_w/wrc_h with backbuffer->pow2Width/backbuffer->powe2Height in the "if (backbuffer->container->flags & WINED3D_TEXTURE_NORMALIZED_COORDS)" block that scales the texture coordinates?

3 3

Re: [PATCH 4/4] wined3d: Always use screen-sized frontbuffers.
by Henri Verbeet July 7, 2015

July 7, 2015

On 6 July 2015 at 23:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > --- > dlls/wined3d/device.c | 6 +++--- > dlls/wined3d/surface.c | 22 +++++++++++++++++----- > dlls/wined3d/swapchain.c | 27 +++++++++++++-------------- > 3 files changed, 33 insertions(+), 22 deletions(-) > Why would we want that?

2 1

Re: [PATCH 5/5] wined3d: Use GLSL 1.50 on core contexts.
by Henri Verbeet July 7, 2015

July 7, 2015

On 6 July 2015 at 22:20, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > static const char *shader_glsl_get_version(const struct wined3d_gl_info *gl_info, > const struct wined3d_shader_version *version) > { > - if (gl_info->glsl_version >= MAKEDWORD_VERSION(1, 30) && version->major >= 4) > + if (!gl_info->supported[WINED3D_GL_LEGACY_CONTEXT]) > + return "#version 150"; > + else if (gl_info->glsl_version >= MAKEDWORD_VERSION(1, 30) && version && version->major >= 4) > return "#version 130"; > else > return "#version 120"; Is GLSL 1.20 unavailable in core contexts? I only glanced over the spec, but didn't immediately see anything that explicitly makes earlier versions unavailable. What's a bit unfortunate about this is that drivers may decide to use different floating point rules (in particular wrt. multiplications by zero) depending on the GLSL version. IIRC at least r600g considered doing that at some point, although I'd have to check if that's currently the case.

2 1

Re: [PATCH 2/2] mshtml: Add IHTMLXMLHttpRequest::send() method implementation. (try 2)
by Marvin July 7, 2015

July 7, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15123 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/4] d3d8/tests: Add a windowed GetFrontBufferData test.
by Henri Verbeet July 7, 2015

July 7, 2015

On 6 July 2015 at 23:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +/* Locks a given surface and returns the color at (x,y). It's the caller's > + * responsibility to only pass in lockable surfaces and valid x,y coordinates */ > +static DWORD get_pixel_color_from_surface(IDirect3DSurface8 *surface, UINT x, UINT y) In ddraw this is called get_surface_color(), the equivalent d3d10core function is called get_texture_color().

1 0

odbccp32: Implement SQLGetPrivateProfileString (try 7)
by Hugh McMaster July 7, 2015

July 7, 2015

On Tuesday, 7 July 2015, 10:31 pm UTC+10, Nikolay Sivov wrote: >On 07.07.2015 11:15, Alistair Leslie-Hughes wrote: > >> + retval = heap_alloc(cbRetBuffer*sizeof(WCHAR)); >> + >> + ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); > >cbRetBuffer is A-buffer length, you're still using it as W-buffer length. Unless I'm reading MSDN [1] incorrectly, this should work. cbRetBuffer is the size, in characters, of RetBuffer (i.e. the A-buffer). retval is the W-buffer. Its allocated byte size is double that of RetBuffer, but its size, in characters, is still the same.

2 2

Re: odbccp32: Implement SQLGetPrivateProfileString (try 7)
by Nikolay Sivov July 7, 2015

July 7, 2015

On 07.07.2015 11:15, Alistair Leslie-Hughes wrote: > + retval = heap_alloc(cbRetBuffer*sizeof(WCHAR)); > + > + ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); cbRetBuffer is A-buffer length, you're still using it as W-buffer length.

1 0

Re: msscript.ocx: Added IDispatch functions implementation.
by Dmitry Timoshkov July 7, 2015

July 7, 2015

Hi Jacek, Jacek Caban <jacek(a)codeweavers.com> wrote: > + case DLL_PROCESS_DETACH: > + release_typelib(); > + break; There should be a check to avoid freeing resources on process termination to avoid possible deadlocks. -- Dmitry.

1 0

Re: shell32/tests: Try harder to close Open With window
by Marvin July 7, 2015

July 7, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15086 Your paranoid android. === w2000pro (32 bit shlexec) === shlexec.c:2449: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2449: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2449: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2449: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2449: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2449: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 === wxppro (32 bit shlexec) === shlexec.c:1224: Test failed: expected 1 args, got 4 === w2003std (32 bit shlexec) === shlexec.c:1224: Test failed: expected 1 args, got 4

2 1

Re: [PATCH 2/4] d3d8/tests: Add a windowed GetFrontBufferData test.
by Marvin July 7, 2015

July 7, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15097 Your paranoid android. === w8 (32 bit visual) === visual.c:7637: Test failed: Got color 0xfffff913. visual.c:7639: Test failed: Got color 0xfffff913. visual.c:7641: Test failed: Got color 0xfffff913. visual.c:7643: Test failed: Got color 0xfffff913. visual.c:7646: Test failed: Got color 0xfffffa13. visual.c:7648: Test failed: Got color 0xfffffa13. visual.c:7650: Test failed: Got color 0xfffffa13. visual.c:7652: Test failed: Got color 0xfffefa13. visual.c:7655: Test failed: Got color 0xfffff913. visual.c:7657: Test failed: Got color 0xfffff913. visual.c:7659: Test failed: Got color 0xfffff913. visual.c:7661: Test failed: Got color 0xfffff913. visual.c:7664: Test failed: Got color 0xfffffa13. visual.c:7666: Test failed: Got color 0xfffef913. visual.c:7668: Test failed: Got color 0xfffffa13. visual.c:7670: Test failed: Got color 0xfffef913.

1 0

Re: [PATCH 1/4] d3d9/tests: Add a windowed GetFrontBufferData test.
by Marvin July 7, 2015

July 7, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15096 Your paranoid android. === w8 (32 bit visual) === visual.c:19339: Test failed: Got color 0xff7170fb. visual.c:19341: Test failed: Got color 0xff7170fb. visual.c:19343: Test failed: Got color 0xff7170fb. visual.c:19345: Test failed: Got color 0xff7170fb. visual.c:19348: Test failed: Got color 0xff71fefb. visual.c:19350: Test failed: Got color 0xff71fefb. visual.c:19352: Test failed: Got color 0xff71fefb. visual.c:19354: Test failed: Got color 0xff71fefb. visual.c:19357: Test failed: Got color 0xff7f70fb. visual.c:19359: Test failed: Got color 0xff7f70fb. visual.c:19361: Test failed: Got color 0xffff70fb. visual.c:19363: Test failed: Got color 0xffff70fb. visual.c:19366: Test failed: Got color 0xff86fefb. visual.c:19368: Test failed: Got color 0xff85fefb. visual.c:19370: Test failed: Got color 0xfffffe90. visual.c:19372: Test failed: Got color 0xfffffe90.

1 0

Re: [1/2] ole32: Add a storage test using a custom ILockBytes.
by Marvin July 7, 2015

July 7, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15093 Your paranoid android. === w7u (32 bit storage32) === Failure running script in VM: timed out waiting for the child process

1 0

Re: [PATCH 3/8] winex11.drv: implement DoDragDrop on top of XDND
by Ken Thomases July 6, 2015

July 6, 2015

On Jul 4, 2015, at 8:36 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > Implements DoDragDrop on top of XDND. While some of DoDragDrop() and > supporting functions are copied from ole32, they were modified to be > non-blocking and event-driven. > > The clipboard is patched to allow searching its clipboard formats for > X11 atoms, export data in X11 format, and forward selection requests > for the XdndSelection selection to XDND. > > We support XDND version 3 to 5 (although we still need XdndProxy > support for version 4). XdndPosition messages are rate-limited to at > most 1 unreplied message and at least every 50 milliseconds apart, so > that we don't flood slow X11 clients like the spec warns. In set_XdndTypeList() and X11DRV_XDND_SelectionRequest(), you use FIXMEs for most unsupported format properties, but just a TRACE for dwAspect != DVASPECT_CONTENT. Is there a reason for that? > + * When we ask for feedback from the drop source, sometimes it will > + * do all the necessary work and sometimes it will not handle it > + * when that's the case, we must display the standard drag and drop > + * cursors. Copy-pasted typo. There should be a period after "handle it" and we should capitalize "when that's the case". (Or change to "When it doesn't handle it" to be clearer.) > + /* > + * All the return valued will stop the operation except the S_OK > + * return value. > + */ Copy-pasted typo: "return valued" should be "return values". > + /* > + * When keyboard messages are sent to windows on this thread, we > + * want to ignore notify the drop source that the state changed. > + * in the case of the Escape key, we also notify the drop source > + * we give it a special meaning. > + */ Copy-pasted typo: "ignore notify". I'm not sure if the fix is to just drop "ignore" or to expand the sentence to explain that we swallow key events except to notify the drop source about the Escape key. -Ken

1 0

Re: [PATCH 2/8] ole32/user32/winemac.drv/winex11.drv: try using native drag and drop if possible
by Ken Thomases July 6, 2015

July 6, 2015

Hi, > On Jul 4, 2015, at 8:36 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > If possible, try using the drag and drop implemented by the native > windowing system instead of the one implemented by our ole32. This > patch just provides the framework, the next patch actually implements > all drag and drop over XDND. Thanks for doing this redesign. For this patch, is it necessary to add the driver entry point to the user drivers (winemac, winex11)? Since the null driver already returns E_NOTIMPL, it would seem the user drivers don't need to provide an entry point that just does the same thing. Is there a reason there's no loaderdrv_DoDragDrop()? Is it not possible for DoDragDrop() to be called before the driver has been loaded? -Ken

1 0

Re: [PATCH 1/2] shell32/tests: Win XP splits the args if there are spaces in the path.
by Marvin July 6, 2015

July 6, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15076 Your paranoid android. === w2000pro (32 bit shlexec) === shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1545: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1577: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1545: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1577: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\wtD96A.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\wtD96A.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2115: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\wtD96A.tmp" Exec") succeeded: rc=42

2 1

Re: [2/10]hidclass.sys: add hidclass.sys
by Henri Verbeet July 6, 2015

July 6, 2015

I didn't really look at the rest of the series, but here are a few things that caught my eye. On 6 July 2015 at 17:46, Aric Stewart <aric(a)codeweavers.com> wrote: > +struct list minidriver_list = LIST_INIT(minidriver_list); You don't seem to access this outside of main.c anywhere in this series, and it seems somewhat unlikely that you'll ever have to. Shouldn't this just be static? > +static VOID WINAPI UnloadDriver(DRIVER_OBJECT *driver) "void" > + TRACE("Driver Unload\n"); > + LIST_FOR_EACH_ENTRY_SAFE(md, next, &minidriver_list, minidriver, entry) > + { > + if (md->minidriver.DriverObject == driver) > + { > + if (md->DriverUnload) > + md->DriverUnload(md->minidriver.DriverObject); > + list_remove(&md->entry); > + break; > + } > + } > +} Did you intend to use find_minidriver() here? > +minidriver* find_minidriver(DRIVER_OBJECT* driver) > +{ > + minidriver *md; > + LIST_FOR_EACH_ENTRY(md, &minidriver_list, minidriver, entry) > + { > + if (md->minidriver.DriverObject == driver) > + return md; > + } > + return NULL; > +} As the code currently is this isn't actually used until patch 10/10. You could potentially use it from UnloadDriver() as mentioned above, but it should still initially be static in that case. Your '*' placement is inconsistent. > +NTSTATUS WINAPI HidRegisterMinidriver(PHID_MINIDRIVER_REGISTRATION registration) "HID_MINIDRIVER_REGISTRATION *registration" > +BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpv) > +{ > + switch(fdwReason) > + { > + case DLL_PROCESS_ATTACH: > + DisableThreadLibraryCalls(hInstDLL); > + break; > + } > + return TRUE; > +} As long as you don't do anything special in here, you don't need an explicit DllMain(). (But if you did, "void *" instead of LPVOID, and parameter naming.) > +/* These are from hidport.h but are only used here anyway */ > +typedef struct _HID_MINIDRIVER_REGISTRATION { The brace placement is inconsistent with the rest of the code. > + ULONG Revision; > + PDRIVER_OBJECT DriverObject; > + PUNICODE_STRING RegistryPath; "UNICODE_STRING *RegistryPath;" > + ULONG DeviceExtensionSize; > + BOOLEAN DevicesArePolled; > + UCHAR Reserved[3]; > +} HID_MINIDRIVER_REGISTRATION, *PHID_MINIDRIVER_REGISTRATION; If this is really only used inside hidclass.sys, you shouldn't need the PHID_MINIDRIVER_REGISTRATION typedef. > +NTSTATUS WINAPI HidRegisterMinidriver(PHID_MINIDRIVER_REGISTRATION MinidriverRegistration); The whitespace is odd here. Also, "HID_MINIDRIVER_REGISTRATION *registration". > +typedef struct _minidriver > +{ > + struct list entry; > + > + HID_MINIDRIVER_REGISTRATION minidriver; > + > + PDRIVER_UNLOAD DriverUnload; > +} minidriver; I suppose it's somewhat up to personal style, but you don't need a typedef for this. Aside from saving you from typing "struct" a few times it only obfuscates the code. I suspect some of the imports and includes aren't actually used until later in the series, but I didn't explicitly check that.

1 0

Re: [PATCH 2/2] shell32/tests: Win 2k doesn't cope with spaces in the path.
by Marvin July 6, 2015

July 6, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15077 Your paranoid android. === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1545: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1577: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1545: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1577: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\wtDFB4.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\wtDFB4.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2115: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\wtDFB4.tmp" Exec") succeeded: rc=42

1 0

Wine Gecko 2.40-beta1
by Jacek Caban July 6, 2015

July 6, 2015

Hi all, It's time for another Wine Gecko update. I uploaded new builds to SourceForge. The new version is updated to use upcoming Firefox 40 engine and brings a few Wine-specific fixes. It also adds support for building with MSVC, contributed by Austin. If you want to test it, just build Wine with the attached patch. Wine will download Gecko for you. All feedback is appreciated. Thanks, Jacek

1 0

Re: [PATCH 2/3]: msvcp110: Add tr2_sys__Rename implementation and test.(try 3)
by Piotr Caban July 6, 2015

July 6, 2015

On 07/05/15 20:49, YongHao Hu wrote: > + if(!strcmp(old_path, new_path) || MoveFileExA(old_path, new_path, MOVEFILE_COPY_ALLOWED)) The comparison of paths doesn't look right. Why have you added it? Cheers, Piotr

2 1

Adding RID_TYPEHID RawInput support to user32
by Nathan Schulte July 6, 2015

July 6, 2015

(Apologies if double posting; I wasn't sub'd the first time and it wasn't in the archives.) I'm working to extend Wine's RawInput implementation to support gamepads/controllers (and possibly joysticks, or any non-keyboard/mouse HID device). I found this on the wine-patches list: Vincas Miliūnas wrote: > A comment about going beyond mouse/keyboard for raw input:Other > devices then mouse&keyboard produce undocumented blobs of bytes;to > interpret them, functions from the hid.dll are used. Currently > theyare unimplemented stubs in WINE as well as not the problem I am > solving.There is a recent article about this subject - Using the Raw > Input APIto Process Joystick Input > -http://www.codeproject.com/KB/game/RawInputJoystick.aspx Does this imply then, that if one was to add support for "raw" rawinput (RIM_TYPEHID device type) it could be used in conjunction with a native hid.dll and software that required RIM_TYPEHID input (for e.g. game controllers in games) would start working? Nathan Schulte (me; original post) wrote: > Also, could one create an adaptation from some joystick input libraries > (evdev/x11,rawhid) and make it conform to the API in the CodeProject > example, making modifications similar to Henri Verbeet's for mouse and > keyboard and have built-in support for this? > > (Henri Verbeet's rawinput contributions: > http://source.winehq.org/git/wine.git/?a=search&st=commit&s=rawinput) > > I see that Wine already has support for joysticks in some other > fashion (the gamepad I'm working with shows up in the `wine control` > Game Controller testing interface), and I bet it's a good idea to > leverage that adaptation (those adaptations...) than to start adding > my own. > > Any direction here would be appreciated. I think I understand the > separation between the wineserver (mainly server/queue.c) and the > dlls (dlls/user32/*), but I see that there are other "dlls" that > don't use (or don't appear to use, given my probably incorrect > understanding) wineserver for their adaptation, and instead talk > directly with the Linux libs to do their work (I'm assuming). It looks like what I was was seeing was "Wine drivers," (winejoystick.drv, for winmm's joystick bits, and DirectInput's joystick bits). Should I follow that route, or should I plumb this through wineserver, like the rawinput keyboard and mouse? Why are those plumbed through wineserver? Are they shared resources, and if so, why doesn't that matter for winmm and DirectInput? I'm thinking this should be fairly easy to get working, by enumerating the rawhid devices and just piping the data through. I'm not sure how well the native hid.dll will work though; can anyone comment? Any help is welcome, as it means my patches are more likely to make it upstream and benefit others. I'm wondering if there's an architecture diagram/doc somewhere to help me understand how the system works. Thanks, -- Nate

3 3

crossover programs missing from source code
by Theodore Dubois July 5, 2015

July 5, 2015

The following programs in Crossover are absent from the source code download: assocscan autorun ctfmon cxcplinfo cxdummy cxinstallfonts cxmanip cxmklnk cxnative cxwget ddhelp extract findfast icwconn1 imjpmig maildoff mdm mosearch netscape ntoskrnl pstores qttask reboot sendwndcmd winewrapper Can I get an explanation for each of these? ~Theodore

4 3

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger July 5, 2015

July 5, 2015

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

Re: [4/7] ntdll/tests: Add basic tests for threadpool wait objects.
by Marvin July 5, 2015

July 5, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=15039 Your paranoid android. === w7u (32 bit threadpool) === threadpool.c:734: Test failed: WaitForSingleObject returned 258

2 1

Re: ole32: Accept STG_E_UNIMPLEMENTEDFUNCTION when ILockBytes implementation doesn't support locking.
by Nikolay Sivov July 4, 2015

July 4, 2015

On 03.07.2015 10:27, Dmitry Timoshkov wrote: > Some custom implementations return it instead of STG_E_INVALIDFUNCTION. > --- > dlls/ole32/storage32.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ole32/storage32.c b/dlls/ole32/storage32.c > index 220e17e..aa53758 100644 > --- a/dlls/ole32/storage32.c > +++ b/dlls/ole32/storage32.c > @@ -5015,7 +5015,7 @@ static HRESULT StorageImpl_GrabLocks(StorageImpl *This, DWORD openFlags) > hr = StorageImpl_LockRegionSync(This, offset, cb, LOCK_ONLYONCE); > > /* If the ILockBytes doesn't support locking that's ok. */ > - if (hr == STG_E_INVALIDFUNCTION) return S_OK; > + if (hr == STG_E_INVALIDFUNCTION || hr == STG_E_UNIMPLEMENTEDFUNCTION) return S_OK; > else if (FAILED(hr)) return hr; > > hr = S_OK; > It looks like StorageImpl_LockRegionSync should be fixed instead to filter some error codes. Could you add a test with external ILockBytes implementation that does that?

3 7

Re: [PATCH 5/6]: msvcp110: Add tr2_sys__Lstat implementation and test.(resend)
by Piotr Caban July 4, 2015

July 4, 2015

On 07/03/15 06:00, YongHaoHu wrote: > +/* ?_Lstat(a)sys@tr2(a)std@@YA?AW4file_type(a)123@PBDAAH(a)Z */ > +/* ?_Lstat(a)sys@tr2(a)std@@YA?AW4file_type(a)123@PEBDAEAH(a)Z */ > +file_type tr2_sys__Lstat(char const* path, int *err_code) > +{ > + DWORD attr; > + TRACE("(%s %p)\n", debugstr_a(path), err_code); > + if(!path) { > + *err_code = ERROR_INVALID_PARAMETER; > + return status_unknown; > + } > + > + attr = GetFileAttributesA(path); > + if(attr == INVALID_FILE_ATTRIBUTES) > + return stat_set_error(err_code); > + if(attr & FILE_ATTRIBUTE_REPARSE_POINT) > + FIXME("reparse point is not supported yet\n"); > + > + *err_code = ERROR_SUCCESS; > + return (attr & FILE_ATTRIBUTE_DIRECTORY)?directory_file:regular_file; > +} What's the reason for not calling tr2_sys__Stat function here? Thanks, Piotr

2 3

Adding RID_TYPEHID RawInput support to user32
by Nathan Schulte July 3, 2015

July 3, 2015

I'm working to extend Wine's RawInput implementation to support gamepads/controllers (and possibly joysticks, or any non-keyboard/mouse HID device). I found this on the wine-patches list: Vincas Miliūnas wrote: > A comment about going beyond mouse/keyboard for raw input:> Other devices then mouse&keyboard produce undocumented blobs of bytes;> to interpret them, functions from the hid.dll are used. Currently they> are unimplemented stubs in WINE as well as not the problem I am solving.> There is a recent article about this subject - Using the Raw Input API> to Process Joystick Input -> http://www.codeproject.com/KB/game/RawInputJoystick.aspx Does this imply then, that if one was to add support for "raw" rawinput (RIM_TYPEHID device type) it could be used in conjunction with a native hid.dll and software that required RIM_TYPEHID input (for e.g. game controllers in games) would start working? Also, could one create an adaptation from some joystick input libraries (evdev/x11) and make it conform to the API in the CodeProject example, making modifications similar to Henri Verbeet's and have built-in support for this? (Henri Verbeet's rawinput contributions: http://source.winehq.org/git/wine.git/?a=search&st=commit&s=rawinput) I see that Wine already has support for joysticks in some other fashion (the gamepad I'm working with shows up in the `wine control` Game Controller testing interface), and I bet it's a good idea to leverage that adaptation (those adaptations...) than to start adding my own. Any direction here would be appreciated. I think I understand the separation between the wineserver (mainly server/queue.c) and the dlls (dlls/user32/*), but I see that there are other "dlls" that don't use (or don't appear to use, given my probably incorrect understanding) wineserver for their adaptation, and instead talk directly with the Linux libs to do their work (I'm assuming). Any help is welcome, as it means my patches are more likely to make it upstream and benefit others. I'm wondering if there's an architecture diagram/doc somewhere to help me understand how the system works. Thanks, -- Nate

1 0

Re: [PATCH 1/2] d3drm: Add stubs for IDirect3DRMDevice methods.
by Stefan Dösinger July 3, 2015

July 3, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-07-01 um 01:03 schrieb Aaryaman Vasishta: > +static ULONG WINAPI d3drm_device1_AddRef(IDirect3DRMDevice *iface) > +{ > + struct d3drm_device *device = impl_from_IDirect3DRMDevice(iface); > + ULONG refcount = InterlockedIncrement(&device->ref); > + > + TRACE("%p increasing refcount to %u.\n", iface, refcount); > + > + return refcount; > +} > + > +static ULONG WINAPI d3drm_device1_Release(IDirect3DRMDevice *iface) > +{ > + struct d3drm_device *device = impl_from_IDirect3DRMDevice(iface); > + > + return IDirect3DRMDevice2_Release(&device->IDirect3DRMDevice2_iface); > +} Why are you forwarding Release to d3drmdevice2 but not Addref? I think we should look again at moving the IUnknown methods to Device3, so we don't thunk to the middle child and stay consistent with the other methods. Please send an extra patch before this one that migrates the code to device3. I remember we already looked at this. If this failed in some spectacular way please remind me :-) . Is there a logic behind which method forwards to device3 and which just returns E_NOTIMPL? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVk+jzAAoJEN0/YqbEcdMwL/MP/jmYjvhWcVOosMP2FyKVaezA c4SqCONBE+xPvhmC97IfPXZ8wJQUjH0tt5CjZN2JZTY0yw50bEM4JHDfC1pPjF3O IX4qKllp0UeAeNCNKu64a8rxYT2kLRwLp7zs+GO7YygwimKy9DAMxUCW5+IP4DiB bsO1wTcSWlCHQ8c4ikUou6aIY/npJ+UqVS8DNGl5m1cLw6oUdzZMvcurSooH2LUv 1oq4XC1DQe/wx3Ob826xY8w/2v6CM0JDAgAT1dGqxIWDS5DNzsKj9P8oKEso/C8c thpZdsIvgQLEkfmKgN6wRh9h03aAMVHbXoSmGVihaapSspF7299DYrDyoiQvYxEq k+SgAMqHAtAzfXkQto9n0f8FjiLEJzbFu9WMoKLJmjdk7hpH8CXPsoioA/o8xNDA 8dB9LxITlJuK5oEUczGhdrnN144Ml8AkZbs+DBcvTdHvaOaY7urL2sZ6/QuvGtAY IGGeUnPW2VBMGpg1YlSn9OmziBibrjKOVtXHVmbwYQhZhXOcfzgMT+QBBV2eQ/pQ 0tmDnUk93+ungNnc4slfLZo+uZ8/8kvPRMv8fYPcQjkcXOIRCobup4bqx3vrQVWT zOx05HKBDQihZAxZuHynFaNqA5E1QbhbPac0BsOSLk8r4zSKx58BgNLBYWz51oe6 NN959TJY84womG8/lfFc =jkwG -----END PGP SIGNATURE-----

2 1

Re: [2/2] shell32/tests: Destroy shell view windows.
by Nikolay Sivov July 3, 2015

July 3, 2015

On 02.07.2015 13:36, Thomas Faber wrote: > When calling IShellView::CreateViewWindow, the window itself takes > references to the shell view and related objects (e.g. for a drop > target). This means just calling IShellView::Release is not enough to > properly clean up, the window needs to be destroyed as well. > Could you please also add a test that shows window is still being alive after IShellView was released? It could be a separate patch.

2 1

Re: [PATCH 4/6]: msvcp110: Add tr2_sys__Stat implementation and test.(try 2)
by Piotr Caban July 3, 2015

July 3, 2015

On 07/03/15 05:59, YongHaoHu wrote: > +static file_type stat_set_error(int *err_code) > +{ > + file_type ret; > + > + switch(GetLastError()) { > + case ERROR_FILE_NOT_FOUND: > + case ERROR_BAD_NETPATH: > + case ERROR_INVALID_NAME: > + case ERROR_BAD_PATHNAME: > + case ERROR_PATH_NOT_FOUND: > + ret = file_not_found; > + *err_code = ERROR_SUCCESS; > + break; > + case ERROR_SUCCESS: > + ret = regular_file; > + *err_code = ERROR_SUCCESS; > + break; Why are you handling ERROR_SUCCESS here? stat_set_error function is only called in case of error. Are you planning to reuse this function somewhere else? If not it might be part of tr2_sys__Stat function. Thanks, Piotr

1 0

Re: [PATCH 2/6]: msvcp110: Add tr2_sys__Rename implementation and test. (try 2)
by Piotr Caban July 3, 2015

July 3, 2015

On 07/03/15 05:56, YongHaoHu wrote: > + if(MoveFileExA(old_path, new_path, MOVEFILE_REPLACE_EXISTING|MOVEFILE_COPY_ALLOWED)) According to my testing MOVEFILE_REPLACE_EXISTING flag should not be used here. Thanks, Piotr

1 0

Re: [PATCH 1/6]: msvcp110: Add tr2_sys__Copy_file implementation and test.(try 2)
by YongHaoHu July 3, 2015

July 3, 2015

Hi, all. Found a mistake of tr2_sys__Copy_file, please ignore this patch. Thank you. On 15/7/3 上午11:55, YongHaoHu wrote: > try2 : > Add is_todo in test. > Delete useless SetLastError. > > --- > dlls/msvcp110/msvcp110.spec | 4 +-- > dlls/msvcp120/msvcp120.spec | 4 +-- > dlls/msvcp120/tests/msvcp120.c | 59 > +++++++++++++++++++++++++++++++++++++ > dlls/msvcp120_app/msvcp120_app.spec | 4 +-- > dlls/msvcp90/ios.c | 10 +++++++ > 5 files changed, 75 insertions(+), 6 deletions(-) > >

1 0

Re: [6/12] ntdll/tests: Add tests for threadpool timer merging.
by Sebastian Lackner July 3, 2015

July 3, 2015

On 03.07.2015 01:59, Sebastian Lackner wrote: > --- > dlls/ntdll/tests/threadpool.c | 117 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 117 insertions(+) > The test failure on Windows 7 seems to be random, it worked fine on a second run (and also on several test runs before): https://newtestbot.winehq.org/JobDetails.pl?Key=14968 If it occurs too often in practice we can increase the timeouts, but for now I think it should be fine. BTW: Forgot to mention, the Sleeps() in this patch are necessary because there is no way to do any other kind of synchronization with the Windows internal timer queue thread.

1 0

Re: [6/12] ntdll/tests: Add tests for threadpool timer merging.
by Marvin July 3, 2015

July 3, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=14965 Your paranoid android. === w7u (32 bit threadpool) === threadpool.c:856: Test failed: WaitForSingleObject returned 258 threadpool.c:897: Test failed: expected that ticks are nonzero threadpool.c:899: Test failed: expected that timers are merged

1 0

Re: [PATCH 2/4] wined3d: Implement vertex blending in glsl_vertex_pipe.
by Stefan Dösinger July 2, 2015

July 2, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I like this patchset. I can't find anything wrong in it, but Matteo knows the fixed function pipeline replacement better than I do, so I'll wait for his comments. I tested it with various DirectX SDK samples (bend from dx7, SkinnedMesh and VertexBlend from dx8). It works very well, but I noticed a lighting oddity in SkinnedMesh. The lighting differs slightly between your code ("D3D non-indexed" option) and the test program's vertex shader or d3dx9's software vertex blending ("D3D indexed (VS)" / "Software Skinning"). This difference cannot be seen on Windows. I have attached screenshots. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVlPPNAAoJEN0/YqbEcdMwUcIP/jwJsie6/93Ui3RQTqjT8oOP q0ips3E83dHpi0ceL8xXujr0pyO1x7cVuUX+hZ7Tf08bZu86FpieKZkTYZxRKbKj V5+x/bVlWGM+ogB06E7tHx2oM8tBFlh10wwh9M/QnitjtzCM+E3WKfE01W5NsRRL csUMxE1mBHvnp08Me2CZyzgtVWwQuTWH6IMUtmqQPfOmmOgzIoofjjRowjhZovFi D9cufKD/D+CBsuv/Py5AMYWfjv7gTZqB09sotaIzYWuyI/e6GRRFT2wzX1yOIl+I fhOr3AsHeFLWOAYd41DjMuqmqvQ5e/UigYxkDtssOCHVig7VtaQ0RKTEv6mMfDF4 6Ljgyi7RdGrgle41cDo6DBXTr0WZw6Y2eTLs0G+WCNkJ8/OMR9hLAt/YBg1mPEPo QUNTsqwNQ1Poxuxmo5fWqD0MhLAao7Wgm6dZTiECNPNNBsC91XRYR9jXF29xaB3h 3ekVCTdtI1+wUQolGw1/HZ7whaHkWGrxOY4qqiZsgYRYz1yl52Bt4sJDJYUHknbd GZ4JRkVQXD86D5txRLf500e03QCmDTXxjqEKSsNBNCtcpER1mp+3Hs/SImp/adRr 3tNuEMJduA/5jm27Nt+K13DwsazQXCJMDv5dTYlggBI9c3dhFDmjXNNGSvrvkBkf xW9FbSiHRRDoLR3UMuoR =Ghq/ -----END PGP SIGNATURE-----

2 1

Re: [3/3] msvcirt: Implement ios constructors and assignment
by Marvin July 2, 2015

July 2, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=14949 Your paranoid android. === wvistau64 (64 bit msvcirt) === No test summary line found === w2008s64 (64 bit msvcirt) === No test summary line found

1 0

Re: [2/3] msvcirt/tests: Add initial tests for ios
by Marvin July 2, 2015

July 2, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=14948 Your paranoid android. === wvistau64 (64 bit msvcirt) === No test summary line found === w2008s64 (64 bit msvcirt) === No test summary line found

1 0

A wrapper around the GTK+ rendering engine
by Ivan Akulinchev July 2, 2015

July 2, 2015

Hello, I just want to thank you for Wine and show you my own uxtheme.dll implementation, which uses the GTK+ rendering engine. Thus Wine applications look really native for users. Here is the link: https://github.com/akulinchev/uxthemegtk (see the screenshots at the bottom of the page) If you want, I can help you to add it to the Wine code. If not, I will develop it alone as a third-party project, but then I have a question: what is the best way to replace a Wine library? I think, I shouldn't change anything in /usr/lib/wine. I know about "native libs", but it's an ELF binary, not PE. Regards, Ivan

5 8

Re: [PATCH 4/4] d3d9/tests: Add basic tests for vertex blending.
by Henri Verbeet July 2, 2015

July 2, 2015

On 2 July 2015 at 08:26, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > + static const float quad_upper_right[] = > + { > + -1.0f, -1.0f, 0.0f, 0.0f, 0.0f, 0.0f, > + -1.0f, 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, > + 1.0f, -1.0f, 0.0f, 0.0f, 0.0f, 0.0f, > + 1.0f, 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, > + }, I think it's slightly more readable to specify these as e.g. static const struct { struct vec3 position; struct vec3 blendweights; } quad_upper_right[] = { ... }, instead of an otherwise unstructured collection of floats. You can also potentially fold these into the tests[] array. > + static const struct { > + const float *vertex_data; > + const POINT *quad_points; > + const POINT *empty_points; > + } > + tests[] = Position of the upper brace.

1 0

Re: [PATCH 2/4] wined3d: Implement vertex blending in glsl_vertex_pipe.
by Henri Verbeet July 2, 2015

July 2, 2015

On 2 July 2015 at 08:26, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > @@ -3071,7 +3075,7 @@ static inline BOOL shader_constant_is_local(const struct wined3d_shader *shader, > > void get_identity_matrix(struct wined3d_matrix *mat) DECLSPEC_HIDDEN; > void get_modelview_matrix(const struct wined3d_context *context, const struct wined3d_state *state, > - struct wined3d_matrix *mat) DECLSPEC_HIDDEN; > + int i, struct wined3d_matrix *mat) DECLSPEC_HIDDEN; I think we'll want the index to be unsigned. (Also applies to shader_glsl_ffp_vertex_normalmatrix_uniform() in patch 112562) Looks pretty good otherwise.

1 0

Re: [PATCH 1/2] comctl32: Set the default separator width when notifying a -ve cmd id.
by Marvin July 2, 2015

July 2, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=14914 Your paranoid android. === wvistau64 (64 bit toolbar) === toolbar.c:519: Test failed: Images count mismatch - 26 vs 10 toolbar.c:519: Test failed: Icon size mismatch - 8x8 vs 20x20 toolbar.c:523: Test failed: Images count mismatch - 28 vs 22 toolbar.c:523: Test failed: Icon size mismatch - 16x16 vs 20x20 toolbar.c:533: Test failed: Icon size mismatch - 8x8 vs 16x16 toolbar.c:536: Test failed: Icon size mismatch - 30x30 vs 16x16 toolbar.c:544: Test failed: Images count mismatch - 8 vs 13 toolbar.c:544: Test failed: Icon size mismatch - 30x30 vs 16x16 toolbar.c:548: Test failed: Images count mismatch - 208 vs 13 toolbar.c:548: Test failed: Icon size mismatch - 1x1 vs 16x16 toolbar.c:551: Test failed: Images count mismatch - 208 vs 13 toolbar.c:551: Test failed: Icon size mismatch - 1x5 vs 16x16 toolbar.c:554: Test failed: Images count mismatch - 41 vs 13 toolbar.c:554: Test failed: Icon size mismatch - 5x1 vs 16x16 toolbar.c:1331: Test failed: Icon size mismatch - 14x12 vs 16x15

2 1

Re: [PATCH 2/2] comctl32: Implement the legacy notifications during restore.
by Marvin July 1, 2015

July 1, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=14915 Your paranoid android. === wvistau64 (64 bit toolbar) === toolbar.c:584: Test failed: Images count mismatch - 26 vs 10 toolbar.c:584: Test failed: Icon size mismatch - 8x8 vs 20x20 toolbar.c:588: Test failed: Images count mismatch - 28 vs 22 toolbar.c:588: Test failed: Icon size mismatch - 16x16 vs 20x20 toolbar.c:598: Test failed: Icon size mismatch - 8x8 vs 16x16 toolbar.c:601: Test failed: Icon size mismatch - 30x30 vs 16x16 toolbar.c:609: Test failed: Images count mismatch - 8 vs 13 toolbar.c:609: Test failed: Icon size mismatch - 30x30 vs 16x16 toolbar.c:613: Test failed: Images count mismatch - 208 vs 13 toolbar.c:613: Test failed: Icon size mismatch - 1x1 vs 16x16 toolbar.c:616: Test failed: Images count mismatch - 208 vs 13 toolbar.c:616: Test failed: Icon size mismatch - 1x5 vs 16x16 toolbar.c:619: Test failed: Images count mismatch - 41 vs 13 toolbar.c:619: Test failed: Icon size mismatch - 5x1 vs 16x16 toolbar.c:1396: Test failed: Icon size mismatch - 14x12 vs 16x15

1 0

Re: ieframe: implement clicking on Properties
by Jacek Caban July 1, 2015

July 1, 2015

Hi Jared, On 06/30/15 16:00, Jared Smudde wrote: > When the user clicks on the properties menu in ieframe, launch inetcpl.cpl. > > dlls/ieframe/iexplore.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/dlls/ieframe/iexplore.c b/dlls/ieframe/iexplore.c > index 08bb167..c1d0d74 100644 > --- a/dlls/ieframe/iexplore.c > +++ b/dlls/ieframe/iexplore.c > @@ -402,6 +402,11 @@ static void ie_dialog_about(HWND hwnd) > DestroyIcon(icon); > } > > +static void ie_dialog_properties(HWND hwnd) > +{ > + ShellExecuteW(hwnd, NULL, L"inetcpl.cpl", NULL, NULL, 0); > +} I think that we should call inetcpl.cpl functions directly here (probably LaunchInternetControlPanel). Also, you can't use L"" for strings due to compatibility problems, see how other strings are declared. > + > static void add_tb_separator(HWND hwnd) > { > TBBUTTON btn; > @@ -629,6 +634,10 @@ static LRESULT iewnd_OnCommand(InternetExplorer *This, HWND hwnd, UINT msg, WPAR > case ID_BROWSE_QUIT: > ShowWindow(hwnd, SW_HIDE); > break; > + > + case ID_BROWSE_PROPERTIES: > + ie_dialog_properties(hwnd); > + break; Broken indention. Thanks, Jacek

1 0

Re: [PATCH 8/8] comctl32: Implement the legacy notifications during restore.
by Marvin July 1, 2015

July 1, 2015

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=14894 Your paranoid android. === wvistau64 (64 bit toolbar) === No test summary line found === w2008s64 (64 bit toolbar) === No test summary line found

2 1

Re: kernel32: K32EnumProcessModules: Handle NULL pointer gracefully.
by Alex Henrie July 1, 2015

July 1, 2015

> diff --git a/dlls/kernel32/module.c b/dlls/kernel32/module.c > index f495e81..5461881 100644 > --- a/dlls/kernel32/module.c > +++ b/dlls/kernel32/module.c > @@ -1226,6 +1226,12 @@ BOOL WINAPI K32EnumProcessModules(HANDLE process, HMODULE *lphModule, > if (!init_module_iterator(&iter, process)) > return FALSE; > > + if (!lphModule) > + { > + SetLastError(ERROR_NOACCESS); > + return FALSE; > + } > + > if (!needed) > { > SetLastError(ERROR_NOACCESS); Wouldn't it be easier to write "if (!lphModule || !needed)"? Adding a test or two would also be nice. -Alex

2 1

odbccp32: Implement SQLGetPrivateProfileString (try 6 - resend)
by Hugh McMaster July 1, 2015

July 1, 2015

>+ LONG ret = 0; >+ HKEY hkey; >+ DWORD size = 0; >+ BOOL usedefault = TRUE; >+ /* snip */ >+ clear_errors(); >+ >+ if(!cbRetBuffer) >+ return 0; >+ >+ if(RetBuffer) >+ RetBuffer[0] = 0; >+ >+ if(!lpszSection || !lpszEntry || !lpszDefault || !RetBuffer || !cbRetBuffer) >+ return ret; You are checking "if (!cbRetBuffer)" twice. Same in the next function. You don't need to clear RetBuffer. RegGetValue adds a null terminating character if it doesn't already exist. You also "return 0" and "return ret". They are the same at the moment, so be consistent. >+size = cbRetBuffer; >+if(RegGetValueW(hkeysect, NULL, lpszEntry, RRF_RT_REG_SZ, &type, RetBuffer, &size) == ERROR_SUCCESS) cbRetBuffer is the size in characters of the buffer pointed to by RetBuffer.[1] size needs to be in bytes, so unless RetBuffer uses char, this is wrong. >+ ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); >+ if(ret) >+ { >+ WideCharToMultiByte(CP_ACP, 0, retval, -1, RetBuffer, ret+1, NULL, NULL); >+ } This doesn't look right to me. "ret+1" should be the size, in bytes, of RetBuffer. [2] [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868%28v=vs.85… [2] https://msdn.microsoft.com/en-us/library/windows/desktop/dd374130%28v=vs.85…

1 0

Re: [PATCH 1/6]: msvcp110: Add tr2_sys__Copy_file implementation and test.
by Piotr Caban July 1, 2015

July 1, 2015

On 06/27/15 19:49, YongHaoHu wrote: > + ret = p_tr2_sys__Copy_file(tests[i].source, tests[i].dest, tests[i].fail_if_exists); > + ok(ret == GetLastError(), "test_tr2_sys__Copy_file(): test %d expect: %d, got %d\n", i+1, GetLastError(), ret); > + ok(errno == 0xdeadbeef, "test_tr2_sys__Copy_file(): test %d errno expect 0xdeadbeef, got %d\n", i+1, errno); Please check the return value of the function explicitly. Currently your implementation returns error while it should succeed and it's not visible in the tests. Thanks, Piotr

2 6

Proposal: to make binfmt-misc with wine workable and make Wine compadiblity modes more like Windows compadiblity mode.
by Peter Dolding July 1, 2015

July 1, 2015

For binfmt-misc to be workable a few things need to be known. 1) What version of wine 2) What wineprefix 3) What setting overrides. None of these can be done by environmental vars because binfmt-misc might be directly executing the file. Windows compadiblity mode does not use the registry like wine does. Instead it done in two horible halves. Half 1. The application manifest file. The mainfest file may be embedded in the .exe file or be .exe.mainfest https://msdn.microsoft.com/en-us/library/windows/desktop/hh848036%28v=vs.85… Yes this is where you set what version of Windows application was designed to run with. So running XP mode on Windows 7 is here. Half 2. Application Compatilibity Database This is where it gets horible using shims on particular executables to make broken executables work. Also when this gets too large starts slowing windows down as it searching the database to make applications work. Yes reason some old applications don't work with Windows 10 that worked with 7 is that their entries were deleted from this database. To solve the problem I think we could get away with just Half the manifest can include library overrides and some windows configuration tweaks. But we have problems the include library information wine needs because of native and built-in libraries. Due to the fact wine is running on Linux and other OS's some of the configuration tweaks are going to be wine dependant. So we need another schema. http://wiki.winehq.org/UsefulRegistryKeys Because if Microsoft manifest would tolerate alien schema really everything under software\wine\appdefaults could be moved from the registry to the manifest. Advantage 1 this can be write protected per application and second advantage possibility of embedding in the exe itself. Also for binfmt-misc support have in the schema the means to record wineprefix and wine to use. So the program starting wine applications by binfmt-misc looks for either a mainfest or a winemainfest file in the same directory as the exe to see what wine environment the application should be running with. If there is no configured environment possibly ask user what wineprefix they do what to run the application with. What I do not know is if Microsoft application manifest file will tolerate an alien schema. Don't have different versions of Windows to test if Microsoft application manifest with a alien schema parts works or just causes windows to throw error or just results in the manifest being complete ignored. Now if Microsoft application manifest will not tolerate alien I have to ask would creating own own like exe.winemainfest be acceptable. I do hope Microsoft application manifest will tolerate alien because it would be really useful to have applications with a manifest a values saying what versions of wine they were tested with by the maker. Currently there is no way for a application vendor to record in the application they tested with wine. A lot of ways putting what shim modifications the application need in the manifest would also remove having to look up a huge database. Getting binfmt-misc working also will remove having to use setcap on wineloader instead of the .exe. Also would make if someone set a capicapity limitation by logind not break every wine application just because a few application where needing privileged operation.. So this alteration would be getting closer to how Windows does stuff and in the process making Linux integration better. Peter Dolding

4 7

Re: [PATCH 2/2] msvcp90: Implement time_get<char> ctors and dtors (try 2)
by Alexandre Julliard July 1, 2015

July 1, 2015

Daniel Lehman <dlehman(a)esri.com> writes: > Try2: > - remove cast for Locinfo > - handle failed new() > - change 'unsigned int refs' to 'MSVCP_size_t refs' to match the rest of the file It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M msvcp60.dll -p msvcp60_test.exe.so ios && touch ios.ok wine: Unhandled page fault on write access to 0xd8003304 at address 0x7bc4e659 (thread 0009), starting debugger... Unhandled exception: page fault on write access to 0xd8003304 in 32-bit code (0x7bc4e659). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7bc4e659 ESP:0032f4e4 EBP:0032f688 EFLAGS:00010216( R- -- I -A-P- ) EAX:d8003300 EBX:7bcc3540 ECX:00010000 EDX:75003300 ESI:00331c40 EDI:00000018 Stack dump: 0x0032f4e4: 00000000 0032f688 7bc4e4ab 00000000 0x0032f4f4: 00330000 00000000 00000000 00330000 0x0032f504: 00000000 00000002 00000014 00000000 0x0032f514: 7bc6b946 0032f540 00330014 00000000 0x0032f524: 7b8c57ac 0032f558 7bc6ad4a f7532361 0x0032f534: f75324a1 7ed54740 7bc6ad4a 7b810000 Backtrace: =>0 0x7bc4e659 RtlAllocateHeap+0x1e9(heap=<couldn't compute location>, flags=<couldn't compute location>, size=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/../../include/wine/list.h:100] in ntdll (0x0032f688) 1 0x7eceb358 msvcrt_heap_alloc+0x57() in msvcrt (0x0032f6b8) 2 0x7eceb51c MSVCRT_operator_new+0x4b() in msvcrt (0x0032f6d8) 3 0x7eba526d locale__Locimp__Makexloc+0x49c(locinfo=0x32f780, cat=0x3f, locimp=0x3316d8, loc=(nil)) [/home/julliard/wine/wine/dlls/msvcp60/../msvcp90/locale.c:10584] in msvcp60 (0x0032f72c) 4 0x7eba5707 locale__Locimp__Makeloc+0x56(locinfo=0x32f780, cat=0x3f, locimp=0x3316d8, loc=(nil)) [/home/julliard/wine/wine/dlls/msvcp60/../msvcp90/locale.c:10617] in msvcp60 (0x0032f75c) 5 0x7eba5aba locale_ctor_cstr+0xb9(this=0x32f840, locname="German", cat=0x3f) [/home/julliard/wine/wine/dlls/msvcp60/../msvcp90/locale.c:10791] in msvcp60 (0x0032f7dc) 6 0x7eff37a4 test_num_get_get_double+0x353() [/home/julliard/wine/wine/dlls/msvcp60/tests/ios.c:910] in msvcp60_test (0x0032fc78) 7 0x7eff7212 func_ios+0xd91() [/home/julliard/wine/wine/dlls/msvcp60/tests/ios.c:1645] in msvcp60_test (0x0032fd58) 8 0x7eff3063 main+0x352(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/msvcp60/tests/../../../include/wine/test.h:584] in msvcp60_test (0x0032fe08) 9 0x7effac1f __wine_spec_exe_entry+0x6e(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in msvcp60_test (0x0032fe58) 10 0x7b85b55c call_process_entry+0xb() in kernel32 (0x0032fe78) 11 0x7b85c4ea start_process+0x59(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1104] in kernel32 (0x0032fea8) 12 0x7bc7a0b0 call_thread_func_wrapper+0xb() in ntdll (0x0032fec8) 13 0x7bc7cdc1 call_thread_func+0xb0(entry=0x7b85c490, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2732] in ntdll (0x0032ffa8) 14 0x7bc7a08e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 15 0x7bc51b87 start_process+0x16(kernel_start=0x7b85c490) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2868] in ntdll (0x0032ffe8) 16 0xf75fd21d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 17 0xf75fd380 wine_switch_to_stack+0x1f(func=0x7bc51b70, arg=0x7b85c490, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xffb94238) 18 0x7bc56ef1 LdrInitializeThunk+0x1f0(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2922] in ntdll (0xffb94278) 19 0x7b862213 __wine_kernel_init+0x9b2() [/home/julliard/wine/wine/dlls/kernel32/process.c:1276] in kernel32 (0xffb95168) 20 0x7bc57cb3 __wine_process_init+0x152() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3131] in ntdll (0xffb951e8) 21 0xf75fae83 wine_init+0x2c2(argc=0x3, argv=0xffb95724, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:958] in libwine.so.1 (0xffb95238) 22 0x7bf00d6a main+0x79(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:247] in <wine-loader> (0xffb95678) 23 0xf741ca63 __libc_start_main+0xf2() in libc.so.6 (0x00000000) 0x7bc4e659 RtlAllocateHeap+0x1e9 [/home/julliard/wine/wine/dlls/ntdll/../../include/wine/list.h:100] in ntdll: movl %edx,0x4(%eax) 100 elem->next->prev = elem->prev; -- Alexandre Julliard julliard(a)winehq.org

1 0