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

Processing flags before files in regsvr32
by Hugh McMaster 15 Jul '15

15 Jul '15

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 15 Jul '15

15 Jul '15

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 15 Jul '15

15 Jul '15

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 14 Jul '15

14 Jul '15

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 14 Jul '15

14 Jul '15

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 13 Jul '15

13 Jul '15

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 13 Jul '15

13 Jul '15

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 13 Jul '15

13 Jul '15

Looks good to me, thanks.

1 0

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

13 Jul '15

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 13 Jul '15

13 Jul '15

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