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

Re: [PATCH] wmvcore/tests: add tests for WMReader methods
by Alistair Leslie-Hughes July 27, 2017

July 27, 2017

Hi Jefferson, Thanks for the updated patch. When applying your patch there lot of whitespace errors (mostly from the header). warning: squelched 3569 whitespace errors warning: 3574 lines add whitespace errors. After look at qedit/tests, include the wma directly as a resource. (unless someone else objects) >// MSDN says dwType is a QWORD, but it is actually a DWORD C++ style comments aren't allowed. > ok(dwType == WMT_TYPE_DWORD, "onStatus pValue not WMT_TYPE_QWORD (%d), but %d\n", (int)WMT_TYPE_DWORD, dwType); Again WMT_TYPE_QWORD is incorrect here, and remove the (int)WMT_TYPE_DWORD parameter. TestWMReaderCallback_AddRef/Release could just return 2/1 respectfully. The object doesn't need to be deleted nor is there any reference type checks. wmvcore.c: In function ‘test_wmreader_play_wma’: wmvcore.c:425:8: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ok((int)(onStatus_event = CreateEventW(NULL, FALSE, FALSE, NULL)), "Could not create event\n"); ^ You dont delete the wma file. Best Regards Alistair Leslie-Hughes

1 0

Re: [PATCH 2/7] regedit: Use a helper function to allocate memory and check for a valid pointer
by Alexandre Julliard July 27, 2017

July 27, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > +static void *heap_alloc(size_t size) > +{ > + void *buf; > + > + if (!(buf = HeapAlloc(GetProcessHeap(), 0, size))) > + { > + ERR("Out of memory!\n"); > + exit(1); > + } > + > + return buf; > +} That's not the standard heap_alloc(), so a different name would be preferable. I'd suggest heap_xalloc by analogy with xmalloc. -- Alexandre Julliard julliard(a)winehq.org

2 2

Unicode normalization for Wine
by Artur Świgoń July 26, 2017

July 26, 2017

Dear All, My name is Artur and I'm participating in Google Summer of Code 2017 for Wine. Under Nikolay's supervision, I'm working on implementation of Unicode normalization. I probably should have introduced myself some time ago to share results of my research and my ideas, but I also wanted to wait until I could illustrate my points with some code. I'm not sure whether everyone is familiar with Unicode normalization forms, so here's a short summary of concepts and terms I may use. For detailed information, please see [1]. - Characters that look the same on the screen may be encoded in a few different ways. Accented Latin letters may constitute a familiar example. The letter 'é' can be U+00E9 (LATIN SMALL LETTER E WITH ACUTE), but it also can be represented as the sequence U+0065 U+0301 (LATIN SMALL LETTER E, COMBINING ACUTE ACCENT). Many of 1114112 (if I remember the number correctly) Unicode characters are decomposable, i.e. they can also be represented by a different sequence of characters. - Text in normalization form NFD ('D' stands for 'decomposition') does not contain any decomposable characters, e.g. there is U+0065 U+0301 instead of U+00E9. The combining characters (such as the above-mentioned acute accent) have a well defined order, using the concept of combining classes. [2 §3.11] - Text in normalization form NFKD ('K' stands for 'compatibility') has the properties of NFD, plus characters that are typographical variants of other characters (e.g. superscripts, ligatures, etc.) are mapped to 'plain' characters. - Text that will be normalized into the form NFC and NFKC ('C' stands for 'composition') has to be fully decomposed first (NFD and NFKD, respectively) and starters (characters with a combining class zero) plus following non- starters (combining class greater than zero) can be composed into single characters provided that they exist in Unicode and are not present in [3]. I've developed a draft implementation of NFD & NFKD (mapping characters to decomposed sequences as well as reordering combining characters) and written a test program that uses official Unicode test data. [4] My goal was to provide support for codepoints greater than 0xFFFF, encoded in UTF-16 as surrogate pairs. More on that below. The attachment [gsoc-v2.patch] is a diff of my working branch against master. Most notable changes include: - Necessary changes to tools/make_unicode. - New function wine_decompose_string(). - Draft implementation of two Windows API functions: NormalizeString() and IsNormalizedString() (the latter temporarily returns TRUE). [5][6] Rationale and comments: - tools/make_unicode did not collect all necessary data (most notably, compatibility mappings), so a new data structure, @decomp_table_full has been added. Its unification with @decomp_table is yet to be resolved. - The procedure dump_decompose_table() in that script has been rewritten to accomodate all aspects described above and below. Two helper subroutines have been added. - However, the C code section embedded within the script has grown substantially, so it may be desirable to move it to a separate file. - Adding wine_decompose_string() makes sense since surrogate pairs behave like a string and the Unicode Canonical Ordering Algorithm (for combining characters) is an in-place bubble sort on the string, per Unicode specification. - While the code in libs/port/decompose.c (and embedded in tools/make_unicode) implements normalization, it currently serves the purpose of confirmation that the generated data is correct. It hasn't been yet optimized or cleaned up, because the organization of the data is open to discussion now, so the code may still change substantially. - It has been previously assumed that a decomposition mapping of any character is two characters long. This is certainly not true for NFKD, where a character like U+FDFA decomposes to a string of length 18. Therefore, the tables in libs/port/decompose.c contain pairs of offsets to null-terminated mappings in another table (decomp_data, first in that file), one entry for NFD and one for NFKD, instead of two-character mappings. Moreover, since many NFD and NFKD are identical, they have been placed in the same table, with identical mappings merged and fully expanded (i.e. any decomposable characters in the data have been replaced by fully decomposed sequences), to minimize runtime overhead. - The original idea of multi-stage tables (using the most significant bits of a codepoint to obtain an offset to another table etc.) has been preserved, although the tables are no longer combined into a single table. This is because some sub-tables can use a narrower data type, which saves space, especially when data for all Unicode codepoints is included. - Tables of combining classes have a similar structure. - Mappings for characters above 0xFFFF are encoded as UTF-16 (using surrogate pairs), but a single codepoint (UTF-32 if you like) is used for table indexing. Setting $utflim in make_unicode to 65536 is the simplest way to disable support for such characters, but supporting surrogate pairs should not affect any text-related Wine component in a negative way. - As composition depends directly on decomposition, it is the next thing to work on. The attachment [unorm_test.c] is my test program. It should build fine with mingw-w64 or winegcc without any specific compiler flags. It looks for [4] in its directory or accepts a path to that file as an argument. Option -d makes it run only decomposition tests, option -s limits the range to 0xFFFF. No tests should fail with the -s option and 80 of 187460 should fail without it due to incomplete support for surrogate pairs in the reordering part. For details of failed tests, please run with the -v option. Is there a place for such a program somewhere in the Wine source tree? I'd be more than happy to answer your questions, address your comments, and listen to your opinions regarding Unicode normalization. Regards, Artur Świgoń [1] http://www.unicode.org/reports/tr15/ [2] http://www.unicode.org/versions/Unicode10.0.0/ch03.pdf [3] http://www.unicode.org/Public/10.0.0/ucd/CompositionExclusions.txt [4] http://www.unicode.org/Public/10.0.0/ucd/NormalizationTest.txt [5] https://msdn.microsoft.com/en-us/library/windows/desktop/dd319093(v=vs.85).… [6] https://msdn.microsoft.com/en-us/library/windows/desktop/dd318671(v=vs.85).…

2 1

Unicode normalization for Wine - new patch
by Artur Świgoń July 26, 2017

July 26, 2017

I'm not sure whether I've sent the updated patch in my previous email. This one is the one that passes the number of tests I described in my previous message. Sorry for confusion. Artur

1 0

Re: [PATCH] wmvcore/tests: add tests for WMReader methods
by Alistair Leslie-Hughes July 25, 2017

July 25, 2017

Hi Jefferson, > > +typedef struct { > + IWMReaderCallback IWMReaderCallback_iface; > + LONG ref; > + HRESULT (*onStatusCallback)(WMT_STATUS, HRESULT, WMT_ATTR_DATATYPE, BYTE*, void*, void*); > + HRESULT (*onSampleCallback)(DWORD, QWORD, QWORD, DWORD, INSSBuffer*, void*, void*); > + void *pvCallbackContext; > +} TestWMReaderCallback; I'm still a little confused as to why you need this structure when the IWMReaderCallbackVtbl with a few globals would work just as well. > +static HRESULT onStatus_test_wmreader_play_wma( > + WMT_STATUS status, > + HRESULT hr, > + WMT_ATTR_DATATYPE dwType, > + BYTE *pValue, > + void *pvContext, > + void *pvCallbackContext) > +{ > + struct callback_context_test_wmreader_play_wma *pTestContext = > + (struct callback_context_test_wmreader_play_wma*)pvCallbackContext; > + DWORD *dwordValue; > + > + CHECK_EXPECT(onStatus); > + ok(status == onStatus_expected_statuses_test_wmreader_play_wma[pTestContext->onStatus_call_count], > + "onStatus called with unexpected status: %d\n", status); > + if (status == WMT_OPENED) { > + ok(pvContext == pTestContext->pvContextOpen, > + "onStatus was not passed pvContext: expected %p, actual %p\n", pTestContext->pvContextOpen, pvContext); > + } > + else /* status == WMT_STARTED, or later */ { > + ok(pvContext == pTestContext->pvContextStart, > + "onStatus was not passed pvContext: expected %p, actual %p\n", pTestContext->pvContextStart, pvContext); > + } > + switch (status) { > + case WMT_STARTED: > + // MSDN says dwType is a QWORD, but it is actually a DWORD > + ok(dwType == WMT_TYPE_DWORD, "onStatus pValue not WMT_TYPE_QWORD (%d), but %d\n", (int)WMT_TYPE_DWORD, dwType); WMT_TYPE_QWORD typo? > + dwordValue = (DWORD*)pValue; > + ok(*dwordValue == 0, "onStatus call for WMT_STARTED not passed correct starting timestamp: %u\n", *dwordValue); > + SET_EXPECT(onSample); > + break; > + default: > + break; > + } The switch and if could be merged > + /* Get format count. */ > + formatCount = 0; > + hr = IWMReader_GetOutputFormatCount(reader, 0, &formatCount); > + todo_wine ok(hr == S_OK, "Failed to get output format count: 0x%08x\n", hr); formatCount should be checked Best Regards Alistair Leslie-Hughes

2 2

Re: wined3d: Fix context backup window handling.
by Henri Verbeet July 25, 2017

July 25, 2017

On 25 July 2017 at 22:35, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > - if (dc == context->hdc && !context->hdc_is_private && WindowFromDC(dc) != context->win_handle) > + if (dc == context->hdc && !private && WindowFromDC(dc) != context->win_handle) While that works, I think I'd feel happier about the code if the "dc", "private" and "format" parameters just went away. I.e., the reason they still exist is mostly the backup window path in context_set_gl_context(), and I don't think there's a reason that particular path shouldn't just set the appropriate (hdc, hdc_is_private, hdc_has_format) fields in the context instead.

1 0

Re: [PATCH] gdiplus: Avoid division by zero in SOFTWARE_GdipDrawThinPath
by Fabian Maurer July 25, 2017

July 25, 2017

Or maybe we should draw this single pixel? Regards, Fabian Maurer

2 2

Re: [PATCH 4/4 v2] mshtml: Add IElementTraversal::get_firstElementChild implementation
by Marvin July 25, 2017

July 25, 2017

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=32476 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath htmldoc.c:5092: Test failed: unexpected call {d9befc84-f21e-4166-874b-a8d3010dc764}

1 0

Re: [PATCH 3/4 v2] mshtml: Expose IElementTraversal interface to scripts
by Marvin July 25, 2017

July 25, 2017

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=32475 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath htmldoc.c:5092: Test failed: unexpected call {d9befc84-f21e-4166-874b-a8d3010dc764}

1 0

Re: [PATCH 3/4 v2] mshtml: Expose IElementTraversal interface to scripts
by Jacek Caban July 25, 2017

July 25, 2017

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>

1 0

Re: [PATCH 4/4] mshtml: Add IElementTraversal::get_firstElementChild implementation
by Marvin July 25, 2017

July 25, 2017

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=32474 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath

1 0

Re: [PATCH 3/4] mshtml: Expose IElementTraversal interface to scripts
by Marvin July 25, 2017

July 25, 2017

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=32473 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath

1 0

Re: [PATCH 1/5] po: Fix a typo in the Norwegian translation
by Kim Malmo July 25, 2017

July 25, 2017

Thank you kindly! How did you find it? I read through the patch 3 times and missed it. Kim --- Den 24. juli 2017 14:47, skrev Hugh McMaster: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > po/nb_NO.po | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/po/nb_NO.po b/po/nb_NO.po > index 2fa8d89863..0ad494b4f2 100644 > --- a/po/nb_NO.po > +++ b/po/nb_NO.po > @@ -12512,7 +12512,7 @@ msgstr "regedit: Registerverdien \"%1\" vil bli eksportert som binære data.\n" > > #: regedit.rc:427 > msgid "regedit: Invalid system key [%1]\n" > -msgstr "reg: Ugyldig systemnøkkel [%1]\n" > +msgstr "regedit: Ugyldig systemnøkkel [%1]\n" > > #: regedit.rc:428 > msgid ""

1 0

Re: [1/2] gdi32/tests: Add test for SetPixel erase with R2_XORPEN
by Huw Davies July 24, 2017

July 24, 2017

On Mon, Jul 24, 2017 at 12:57:30AM +1000, Tim Worthington wrote: > diff --git a/dlls/gdi32/tests/dib.c b/dlls/gdi32/tests/dib.c > --- a/dlls/gdi32/tests/dib.c > +++ b/dlls/gdi32/tests/dib.c > @@ -2703,6 +2703,26 @@ > ret = ExtFloodFill( hdc, -1, -1, RGB( 0, 0xff, 0 ), FLOODFILLSURFACE ); > ok (!ret, "got ret %d\n", ret); > > + /* SetPixel erase with R2_XORPEN */ > + if ( ( bmi->bmiHeader.biBitCount >= 16 ) > + || ( ( bmi->bmiHeader.biClrUsed == 256 ) && ( bmi->bmiHeader.biBitCount == 8 ) ) ) > + { > + int rop2; > + COLORREF set, get; > + > + rop2 = GetROP2( hdc ); > + for (i = 0; i < 256; i++) > + { > + SetROP2( hdc, R2_COPYPEN ); > + set = SetPixel( hdc, i * 2, 30, RGB( (i & 0x07) << 5, (i & 0x38) << 2, i & 0xc0 ) ); > + SetROP2( hdc, R2_XORPEN ); > + SetPixel( hdc, i * 2, 30, set ); > + get = GetPixel( hdc, i * 2, 30 ); > + ok( get == 0, "got %08x and %08x\n", set, get ); > + } > + SetROP2( hdc, rop2 ); > + } > + > SelectObject(hdc, orig_brush); > SelectObject(hdc, orig_pen); > DeleteObject(solid_brush); Hi Tim, Thank you for your contribution to Wine. There were a number of issues with this series, which by the time I'd reviewed them meant I'd essentially re-written the patches; so I just sent them in: https://source.winehq.org/patches/data/136093 https://source.winehq.org/patches/data/136094 This seemed more efficient than explaining the problems and suggesting alternative approaches. If you're interested, please free feel to look at my patches and ask if there's anything you're curious about. Huw.

2 1

Re: [PATCH] user32: In CURSORICON_FindBestCursor scale cursor correctly
by Fabian Maurer July 24, 2017

July 24, 2017

Was too slow, not needed anymore after d0e8170c90ef63363f8389be2619c9332ae2c371. Regards, Fabian Maurer

1 0

Re: [PATCH] wmvcore/tests: add tests for WMReader methods
by Alistair Leslie-Hughes July 24, 2017

July 24, 2017

Hi Jefferson, On 24/07/17 08:26, Jefferson Carpenter wrote: > Create a sample WMA file, which is saved into a temp directory at the > beginning of the wmvcore tests. > > Added a IWMReaderCallback implementation for use in conformance tests. > > Tested various playback-related WMReader methods. > > Changes in version 2 of this patch: Declared loop variable at top of > function, and using C89-style comments. The callback interface can just be static, see mshtml/tests/htmldoc.c for an example. Maybe using the CHECKED_CALLED syntax to check if something was been called. If the order of called is important then see msxml3/tests/saxreader.c for an example. You cannot use Sleep in tests, no matter how small it has to wait, instead use an Event+WaitForSingleObject. Use HeapAlloc/HeapFree instead of malloc/free, create a worker function if required. + IWMReader *reader; Leaking reader + /* Get output props. */ + hr = IWMReader_GetOutputProps(reader, 0, &props); + todo_wine ok(hr == S_OK, "Failed to get output props: 0x%08x\n", Leaking props here. .... + for (i = 0; i < formatCount; i++) { + /* Get output props for format. */ + hr = IWMReader_GetOutputFormat(reader, 0, i, &props); + todo_wine ok(hr == S_OK, "Failed to get output format: and here. Best Regards Alistair Leslie-Hughes

2 1

Re: mscoree: Update for mono profiler api v2.
by Vincent Povirk July 24, 2017

July 24, 2017

Please don't commit this. They just changed it again and put in compatibility functions for the old API.

1 0

Some clarification of msi messages for translation and pedantic remarks
by Julian Rüger July 24, 2017

July 24, 2017

Hi Zebediah (and list), I'd like some clarification of a few terms used in the new msi messages, to make sure I translate the correct meaning. :) #: msi.rc:103 msgid "Searching for related applications" ... #: msi.rc:111 msgid "Migrating feature states from related applications" related as in 'similar' or 'belonging together' or something else? I'd guess #2. #: msi.rc:113 msgid "Publishing assembly information" assembly as in 'binary/executable file/dll', 'the assembler language' or just 'putting together'? I strongly suspect #1, and that is a tough one. There is no fitting translation in German and this is not one of the many, many cases where you would just use the original English term. It sounds totally awkward. (Maybe because words ending in y are usually Germanized to use other suffixes. Just does not work with 'Assembly') EDIT: Never mind, I just looked it up and M$ does indeed use the untranslated original, even in compound words.. Ughhh! #: msi.rc:120 msgid "Registering Class servers" ... #: msi.rc:122 msgid "Registering extension servers" It's 'Server' in German as well for the hardware (machine/host) or applications/services like Apache, but this feels like a different thing. Am I being silly? Maybe this can only be answered by other German speakers. #: msi.rc:130 msi.rc:154 msgid "Updating environment strings" Can I just call this environment variables? Sounds more natural than the compound word with string ("Umgebungszeichenketten")... Thanks for your help and for all your work! Best, Julian PS: Some other questions/comments, unrelated to translation: #: msi.rc:168 msi.rc:171 msi.rc:175 msgid "File: [1], Directory: [9], Size: [6]" ... #: msi.rc:170 msgid "File: [1], Directory: [9], Size: [6]" Are these supposed to be separate, but identical? #: msi.rc:173 msgid "File: [1], Dependencies: [2]" ^^ Two spaces on purpose? #: msi.rc:176 msi.rc:177 msgid "Application Context:[1], Assembly Name:[2]" Missing spaces? #: msi.rc:189 msi.rc:209 msgid "Name: [1], Value: [2], Action [3]" Missing colon? (Action: [3])? #: msi.rc:178 msgid "File: [1], Directory: [2], Size: [3]" ... #: msi.rc:193 msi.rc:210 msgid "File: [1], Section: [2], Key: [3], Value: [4]" Duplicate spaces again?

2 1

Re: [PATCH 4/5] reg: Use a helper function to allocate and re-allocate memory
by Alexandre Julliard July 24, 2017

July 24, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -174,6 +177,26 @@ static BOOL ask_confirm(unsigned int msgid, WCHAR *reg_info) > } > } > > +#define CHECK_ENOUGH_MEMORY(p) \ > +if (!(p)) \ > +{ \ > + output_message(STRING_OUT_OF_MEMORY, __FILE__, __LINE__); \ > + exit(1); \ > +} > + > +static void *resize_buffer(void *buf, size_t count) > +{ > + void *new_buf; > + > + if (buf) > + new_buf = HeapReAlloc(GetProcessHeap(), 0, buf, count); > + else > + new_buf = HeapAlloc(GetProcessHeap(), 0, count); > + > + CHECK_ENOUGH_MEMORY(new_buf); > + return new_buf; > +} The macro is not needed, and the message doesn't need to be localized, since this would require allocating memory. I think you'll also want a separate wrapper for HeapAlloc. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] msvcrt: Don't set errno when calling trigonometric functions with NAN.
by Piotr Caban July 24, 2017

July 24, 2017

Hi, I've done some more reading about it and it looks like our implementation is not behaving in similar way as native does. The error handling should call _matherr function (see also __setusermatherr). Thanks to implementing it that way we easily write code that is compatible with older versions of C-runtime (by providing different default implementation of matherr function that prevents setting errno). I think it's best to implement it that way to avoid potential regressions. Thanks, Piotr

2 2

Re: ntdll: Add padding to the stack structure for quad-word alignment on ARM64
by Alexandre Julliard July 24, 2017

July 24, 2017

André Hentschel <nerv(a)dawncrow.de> writes: > EXCEPTION_RECORD is not correctly aligned and until bd1f7ef1868dd563a82eacd1bf414bf8d1a7254e, CONTEXT wasn't either, > which ended up in a correctly aligned structure, but the mentioned commit changed that. > > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/ntdll/signal_arm64.c | 1 + > 1 file changed, 1 insertion(+) You should probably handle that in the existing alignment computation instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2 3/3] msvcr120: Add log1p.
by Piotr Caban July 24, 2017

July 24, 2017

On 07/14/17 07:14, Alex Henrie wrote: > +/********************************************************************* > + * log1pf (MSVCR120.@) > + */ > +float CDECL MSVCR120_log1pf(float x) > +{ > +#ifdef HAVE_LOG1PF > + return log1pf(x); > +#else > + return log(1 + x); > +#endif > +} Please also set errno in this function. Thanks, Piotr

2 3

Re: [PATCH] wmvcore/tests: add tests for WMReader methods
by Marvin July 23, 2017

July 23, 2017

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=32460 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH] gdiplus: free dash_pattern_scaled (Coverity)
by Vincent Povirk July 23, 2017

July 23, 2017

Thanks, Marcus. Unfortunately, with my patch for the same issue (caught by valgrind), this no longer applies. Can you rebase this please?

2 1

Re: ntdll: Fix stack alignment in RtlRaiseException assembly code.
by Alexandre Julliard July 21, 2017

July 21, 2017

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > Please review carefully, don't want to break anything shortly before the > release. ;) > > dlls/ntdll/signal_i386.c | 41 ++++++++++++++++++++++++----------------- > 1 file changed, 24 insertions(+), 17 deletions(-) All it does is call other API functions that will align the stack anyway, so I'm not sure it's worth the trouble. -- Alexandre Julliard julliard(a)winehq.org

2 2