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 11, 2015

July 11, 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 9, 2015

July 9, 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