- wine-devel - winehq.org

Re: [PATCH 1/2] d3d9/tests: Extend the FPU setup test.
by Henri Verbeet 27 Feb '15

27 Feb '15

Not that I would terribly mind if this got comitted, but I have to wonder if this really has a lot of value as a regression test?

3 3

Re: [PATCH] [shell32] Implement SHRunControlPanel using ShellExecute
by Nikolay Sivov 27 Feb '15

27 Feb '15

On 26.02.2015 17:01, Robert Naumann wrote: > --- > dlls/shell32/shellord.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/dlls/shell32/shellord.c b/dlls/shell32/shellord.c > index 914dc5a..9ea3d62 100644 > --- a/dlls/shell32/shellord.c > +++ b/dlls/shell32/shellord.c > @@ -1129,8 +1129,10 @@ HRESULT WINAPI SHWinHelp (DWORD v, DWORD w, DWORD x, DWORD z) > */ > BOOL WINAPI SHRunControlPanel (LPCWSTR commandLine, HWND parent) > { > - FIXME("(%s, %p): stub\n", debugstr_w(commandLine), parent); > - return FALSE; > + if((int)ShellExecute(parent,NULL,commandLine,NULL,NULL,SW_NORMAL)>32) > + return TRUE; > + else > + return FALSE; > } Why 32? Also please don't remove tracing line.

2 2

Re: msvcrt: Use Dragon4 algorithm to fix inconsistent rounding behaviour for sprintf and add tests.
by Zhenbo Li 27 Feb '15

27 Feb '15

Hi, YongHao, Quite a huge patch lol I tried your patch. $ patch -p1 <0012-msvcrt-Use-Dragon4-algorithm-to-fix-inconsistent-round.txt (Stripping trailing CRs from patch; use --binary to disable.) patching file dlls/msvcrt/dragon4.h (Stripping trailing CRs from patch; use --binary to disable.) patching file dlls/msvcrt/printf.h (Stripping trailing CRs from patch; use --binary to disable.) patching file dlls/msvcrt/tests/printf.c (Stripping trailing CRs from patch; use --binary to disable.) patching file dlls/msvcrt/wine_printfloat.h Is this critical? Also, your patch failed to compile on my computer. dragon4.h:10:0: error: unterminated #ifndef #ifndef __WINE_STDIO_H Why is it necessary here? And then, wine_printfloat.h:26:15: error: unknown type name 'uint32_t' It seems that you're using C99 types? It is not allowed in wine code[1] Finally, you've created two files with ZLIB license. Is it better to move all the ZLIB license code to one file? I'm not sure about that. Could someone have a check to avoid legal problems? [1]: wiki.winehq.org/Developers-Hints 2015-02-26 23:13 GMT+08:00 YongHao Hu <christopherwuy(a)gmail.com>: > Fix bug https://bugs.winehq.org/show_bug.cgi?id=37913 . > The Dragon4 algorithm implementation is based on > http://www.ryanjuckett.com/programming/printing-floating-point-numbers/. > > --- > dlls/msvcrt/dragon4.h | 670 > ++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcrt/printf.h | 43 +-- > dlls/msvcrt/tests/printf.c | 83 +++++- > dlls/msvcrt/wine_printfloat.h | 248 ++++++++++++++++ > 4 files changed, 1026 insertions(+), 18 deletions(-) > create mode 100644 dlls/msvcrt/dragon4.h > create mode 100644 dlls/msvcrt/wine_printfloat.h > > > > > -- Have a nice day! Zhenbo Li

2 1

Re: [PATCH 1/1] handling sysex midi messages in winecoreaudio
by Andrew Eikum 26 Feb '15

26 Feb '15

On Wed, Feb 25, 2015 at 09:58:41PM +0100, tinez wrote: > Hi, > > this patch fixes handling sysex midi messages in winecoreaudio > driver. The code was based on winealsa driver implementation. > I've tested it using external midi hardware + midi monitoring tools > (MidiOX). My motivation was to fix Nord Modular Editor software > which is needed to control Nord Modular G1 hardware synthetizer. > After applying the patch it works without problems. > I've also sent out patch to electro-music.com for other people to > test and it was received well (you can see the thread here > electro-music.com/forum/viewtopic.php?t=62683). > Thanks, looks mostly good. A few Wine style notes in-line below. > regards, tinez > > --- > dlls/winecoreaudio.drv/midi.c | 66 > ++++++++++++++++++++++++++++++------------- > 1 file changed, 47 insertions(+), 19 deletions(-) > From e18b1c9876730d9557b97f3e16249b20eae4e875 Mon Sep 17 00:00:00 2001 > From: tinez <tinez(a)tlen.pl> Wine requires full, real names for patches. > Date: Thu, 21 Aug 2014 23:13:31 +0200 > Subject: [PATCH 1/1] handling sysex midi messages in winecoreaudio > > --- > dlls/winecoreaudio.drv/midi.c | 66 ++++++++++++++++++++++++++++++------------- > 1 file changed, 47 insertions(+), 19 deletions(-) > > diff --git a/dlls/winecoreaudio.drv/midi.c b/dlls/winecoreaudio.drv/midi.c > index 8593e9c..c7a1ded 100644 > --- a/dlls/winecoreaudio.drv/midi.c > +++ b/dlls/winecoreaudio.drv/midi.c > @@ -437,9 +437,9 @@ static DWORD MIDIOut_LongData(WORD wDevID, LPMIDIHDR lpMidiHdr, DWORD dwSize) > return MMSYSERR_ERROR; > } > } > - else > + else if (destinations[wDevID].caps.wTechnology == MOD_MIDIPORT) > { > - FIXME("MOD_MIDIPORT\n"); > + MIDIOut_Send(MIDIOutPort, destinations[wDevID].dest, lpData, lpMidiHdr->dwBufferLength); > } > > lpMidiHdr->dwFlags &= ~MHDR_INQUEUE; > @@ -836,26 +836,55 @@ static CFDataRef MIDIIn_MessageHandler(CFMessagePortRef local, SInt32 msgid, CFD > if (src->state < 1) > { > TRACE("input not started, thrown away\n"); > - goto done; > - } > - /* FIXME skipping SysEx */ > - if (msg->data[0] == 0xF0) > - { > - FIXME("Starting System Exclusive\n"); > - src->state |= 2; > + return NULL; > } > - if (src->state & 2) > - { > - for (i = 0; i < msg->length; ++i) > - { > - if (msg->data[i] == 0xF7) > - { > - FIXME("Ending System Exclusive\n"); > - src->state &= ~2; > + > + bool sysexStart = (msg->data[0] == 0xF0); > + Wine uses C89, so we don't have 'bool'. You could change this to a BOOL instead. > + if (sysexStart || src->state & 2) { > + if (sysexStart) { > + TRACE("Receiving sysex message\n"); > + src->state |= 2; > + } > + > + int pos = 0; > + int len = msg->length; > + C89 also doesn't let you declare new variables in the middle of a block. They must be declared at the start of a block. > + EnterCriticalSection(&midiInLock); > + currentTime = GetTickCount() - src->startTime; > + > + while (len) { > + LPMIDIHDR lpMidiHdr = src->lpQueueHdr; > + > + if (lpMidiHdr != NULL) { > + int copylen = min(len, lpMidiHdr->dwBufferLength - lpMidiHdr->dwBytesRecorded); > + memcpy(lpMidiHdr->lpData + lpMidiHdr->dwBytesRecorded, msg->data + pos, copylen); > + lpMidiHdr->dwBytesRecorded += copylen; > + len -= copylen; > + pos += copylen; > + > + TRACE("Copied %d bytes of sysex message\n", copylen); > + > + if ((lpMidiHdr->dwBytesRecorded == lpMidiHdr->dwBufferLength) || > + (*(BYTE*)(lpMidiHdr->lpData + lpMidiHdr->dwBytesRecorded - 1) == 0xF7)) { > + TRACE("Sysex message complete (or buffer limit reached), dispatching %d bytes\n", lpMidiHdr->dwBytesRecorded); Tabs should be spaces, for consistency with the rest of your code. > + src->lpQueueHdr = lpMidiHdr->lpNext; > + lpMidiHdr->dwFlags &= ~MHDR_INQUEUE; > + lpMidiHdr->dwFlags |= MHDR_DONE; > + MIDI_NotifyClient(msg->devID, MIM_LONGDATA, (DWORD_PTR)lpMidiHdr, currentTime); > + src->state &= ~2; > + } > + } > + else { Here, too. > + FIXME("Sysex data received but no buffer to store it!\n"); > + break; > } > } > - goto done; > + > + LeaveCriticalSection(&midiInLock); > + return NULL; > } > + > EnterCriticalSection(&midiInLock); > currentTime = GetTickCount() - src->startTime; > > @@ -889,7 +918,6 @@ static CFDataRef MIDIIn_MessageHandler(CFMessagePortRef local, SInt32 msgid, CFD > CFRunLoopStop(CFRunLoopGetCurrent()); > break; > } > -done: > return NULL; > } > > -- > 1.9.3 (Apple Git-50)

2 2

Re: [PATCH try2] urlmon: Added IInternetBindInfo implementation to BindStatusCallback object.
by Marvin 26 Feb '15

26 Feb '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=11751 Your paranoid android. === w7u (32 bit url) === url.c:3632: Test failed: expected OnProgress_DOWNLOADINGDATA === wvistau64 (64 bit url) === url.c:3632: Test failed: expected OnProgress_DOWNLOADINGDATA

2 1

Re: [PATCH 3/5] wined3d: Remove ARB_/EXT_TEXTURE_ENV_ADD.
by Henri Verbeet 26 Feb '15

26 Feb '15

On 24 February 2015 at 13:38, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > Unused. > --- But they should be used by ffp_fragment_get_caps(), since set_tex_op() uses that functionality.

3 3

Re: [3/3] dpnet: Convert Address components to use a list
by Stefan Dösinger 26 Feb '15

26 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alistair, Alexandre made me aware that I missed a blaring issue here: Am 2015-02-26 um 04:32 schrieb Alistair Leslie-Hughes: > + temp = heap_realloc(This->components, sizeof(struct > component *) * This->comp_count+1 ); X * This->comp_count+1 won't do what you want it to do. Also he wants the array to be grown by doubling it. If the expected component count is low as you say, allocate the expected count at object creation (e.g. 4), and then double the array in case you need to grow it. Also, in terms of style, you can write sizeof(*This->components) instead of sizeof(struct component *). That way you won't have to change the code if you change the type of This->components. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU7tiXAAoJEN0/YqbEcdMw6NwP/iWzcMCi48YkZ5iu52GrQDTo 86BL0M0VjFy72VDJq58pXvrK+7skm7JlI+jj/hdF0dtXg7ga6OCHqMwdyKdpUisB P93rCUVNOWvtqWltjct3UjdFM0PUD+IU9s5r3nX6sYMxwU++Kt31q5Cxq5APwxUO XplBpKeoRKtx44xgX0o84/hv6MijePDbocn+sQ3gBSyG4UdC4lt9F1Ze57r87DoW F0LkapFizu+45sRVWm6d6ANL4VL+pq3vVmjlIFRUPerVlIRRGEXnE3/5RqBegOUw MWFqRzj7LicQsy2tyan01o+OoUqGQL6ynesKj+I2LMf76i5JlSPGxoYMYlsk3vE+ JXn74dqP9iX6+Rhk7mv6q4iOQNOYsH5BraRWWLCT3vzr5DZESk+pjqn3ECKPkkZQ S88g9ismdDLkQ5pSNT/tbxeV2oRQSa4cTPp8aSNa5ttZtvwJhoHZjUGtdxAU7Go2 DcJuSbmTXFQo50Iaaw8Qlb+ZPbUVE0rjcALkKH74Bhq5vSbRkA1eu69A2TQOB9S3 x1sVVT78YhhWkl6qjESrhP0NFApNiCunUIK2U110aagOHGUyFaRix5DNN3lCO0ZT n9bvdXbZGCgg5RhxgIaqvTuGBhVZh882tpWecazipmYePUmO+4GzGwWGfxfyPymO qzUzMMRIGsukENMDUaus =3JhD -----END PGP SIGNATURE-----

1 0

Re: [1/3] dpnet: Add check for mismatched string lengths
by Stefan Dösinger 26 Feb '15

26 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm sorry, I missed one problem in my earlier reviews of this change: Am 2015-02-26 um 04:31 schrieb Alistair Leslie-Hughes: > case DPNA_DATATYPE_STRING: > + if (((strlenW((WCHAR*)lpvData)+1)*sizeof(WCHAR)) != dwDataSize) > + return DPNERR_INVALIDPARAM; > heap_free(entry->data.string); At the time when you do the check and the error return you have already allocated a new entry and added it to the list. Thus if the check fails you'll leave a zombie component attached to the address object. This also applies to the already existing DWORD size check. You can move the check in front of the loop that searches if such a component name already exists. I also recommend to to write extra tests for these cases: What happens if a new component with an invalid data size is added? Does GetComponentByName return something? What happens if a component already exists and you try to re-add it with an invalid data? Does the old data stay intact? The other two patches look good to me and seem to apply without this one. I'll inform Alexandre on IRC. The subject of patch 3 is broken though, maybe Alexandre can correct it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU7tO3AAoJEN0/YqbEcdMw6z8P/AoWZwr4ysFdMvMBdqlZTVTH bUFYX62n8gj/IADpL1TIq8NN87Q2H2gv+V9p+6IOcvymMkDOVa/jfK+tBtZVLjmy MoLDx/+hJ2Ef8LteV2qiFO4y50btO32ibPrxY6C/jdJ5gj8dHrsjOQQSUiiAHAfQ N4Hl1j9BVblH7elBEa/Anuk+1aArnXncYU3q2wI50HRfgVShDo+3LO8jA4XzQyQM U3Gk0n5YeRapnPH0WAq9FH8o45dUFg3vtkx8M0wpzIHNGsZn91/RlIHOh7m5O9Xx S6mGU9xkhIDoWsRP+I0dIROa/QDVM7aTw8z8jpPVVwc7gS/z7k95BT/skSXw/ryH s4zOZvoS+P4vtJGgQrwnZDpEywJu7p6hdvWcUBEM85ZWvqh2Ui4em9WrW0nsmFeL VC9WcEFG4N8vzAGRK6yF2luyKrygj8KZGukZ2HCJGrjK0pAnln+BSs2V2M4cZMd6 uJus8bKJMcM2oGoB5UbpHMKRlIgSXrO0nwibUYJ02Kp3dpTUG0oHSXer+HFzImvA 2VLinduPKpA0g9XSXtCdUaXZghpQf6K4e7lwDyoikgFZs5x5G6qNYQIx2MtrJwJ2 oQ0YILD8thFi1QQrH7DLqQAGA0kAarDs0wClct5kQ3uiiT3t9a3Rklql/EYPdz3m VvgO1NqMg7yqPq0KMGKl =5ibs -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/3] services: Monitor process handles for process quit
by Alexandre Julliard 26 Feb '15

26 Feb '15

Andrew Eikum <aeikum(a)codeweavers.com> writes: > @@ -1636,13 +1638,30 @@ DWORD events_loop(void) > > do > { > - err = WaitForMultipleObjects(2, wait_handles, FALSE, timeout); > + num_handles = 2; > + > + /* monitor tracked process handles for process end */ > + EnterCriticalSection(&timeout_queue_cs); > + LIST_FOR_EACH_ENTRY(iter, &timeout_queue, struct timeout_queue_elem, entry) > + { > + if(num_handles == max_handles) > + { > + max_handles++; > + wait_handles = HeapReAlloc(GetProcessHeap(), 0, wait_handles, sizeof(HANDLE) * max_handles); > + } You don't need heap allocation, you can't wait for more than MAXIMUM_WAIT_OBJECTS anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: SysDateTimePick32 control add Alt+down hot key likewindows (try 2)
by Nikolay Sivov 26 Feb '15

26 Feb '15

On 25.02.2015 10:56, Changhui Liu wrote: > Superseded patch 109085 > http://source.winehq.org/patches/data/109085 > > Change log: > 1, Pass test on all Windows. > > 2, Add DTN_DROPDOWN and DTN_CLOSEUPnotification test. > > 3, > >>>/ + case WM_SYSKEYDOWN: > />>/ + if (wParam == VK_DOWN) > />>/ + { > />>/ + POINT pt; > />>/ + RECT rect; > />>/ + GetClientRect(hwnd, &rect); > />>/ + pt.x = rect.right - GetSystemMetrics(SM_CXVSCROLL)/2; > />>/ + pt.y = rect.top + GetSystemMetrics(SM_CYHSCROLL)/2; > />>/ + > />>/ + return DATETIME_LButtonDown (infoPtr, (SHORT)pt.x, (SHORT)pt.y); > />>/ + } > />>/ + > />> >>>If it really works this way you should just make it drop directly, >>without faking click point coordinates. > > Because most of code of the directly implement are same as DATETIME_LButtonDown, > and too many repeat code looks bad. > So faking click point coordinates can reuse code. > I'm not saying you should duplicate it, but reuse it in a clean way without hit testing - move relevant code somewhere and use it. > + if (WM_NOTIFY == message) > + { > + NMHDR* hdr = (NMHDR*)lParam; > + > + if (hdr->code == DTN_DROPDOWN) > + { > + g_hWndMonthCal = (HWND)SendMessageA(hdr->hwndFrom, DTM_GETMONTHCAL, 0, 0); > + trace("open SysMonthCal32=%p\n", g_hWndMonthCal ); > + } > + else if (hdr->code == DTN_CLOSEUP) > + { > + trace("close SysMonthCal32=%p\n", g_hWndMonthCal); > + } > + } That's not a notification test as you don't check anything. Please add a proper message sequence test, we have tons of examples for those.

2 1

Re: urlmon: Added IInternetBindInfo implementation to BindStatusCallback object.
by Marvin 25 Feb '15

25 Feb '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=11740 Your paranoid android. === w2000pro (32 bit url) === url.c:2683: Test failed: Could not get IInternetBindInfo interface: 80004002 url: unhandled exception c0000005 at 0044A249

1 0

Re: (try 6)[1/5] imm32: Move thread data from TLSEntry to an internal list
by Alexandre Julliard 25 Feb '15

25 Feb '15

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -1512,11 +1589,15 @@ BOOL WINAPI ImmGetConversionStatus( > */ > HWND WINAPI ImmGetDefaultIMEWnd(HWND hWnd) > { > - if (IMM_GetThreadData()->hwndDefault == NULL) > - IMM_GetThreadData()->hwndDefault = CreateWindowExW( WS_EX_TOOLWINDOW, > + HWND ret; > + IMMThreadData* thread_data = IMM_GetThreadData(0); > + if (thread_data->hwndDefault == NULL) > + thread_data->hwndDefault = CreateWindowExW( WS_EX_TOOLWINDOW, > szwIME, NULL, WS_POPUP, 0, 0, 1, 1, 0, 0, 0, 0); > - TRACE("Default is %p\n",IMM_GetThreadData()->hwndDefault); > - return IMM_GetThreadData()->hwndDefault; > + ret = thread_data->hwndDefault; > + LeaveCriticalSection(&threaddata_cs); > + TRACE("Default is %p\n",ret); > + return ret; You can't create a window while holding the critical section, this will cause deadlocks. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: mshtml: Correctly handle S_OK with NULL URL return from TranslateUrl.
by Marvin 25 Feb '15

25 Feb '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=11724 Your paranoid android. === wvistau64 (32 bit htmldoc) === The test timed out

2 1

Re: comctl32: SysDateTimePick32 control add Alt+down hot key likewindows (try 2)
by Marvin 25 Feb '15

25 Feb '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=11722 Your paranoid android. === wvistau64 (32 bit datetime) === The test timed out

1 0

Re: [PATCH 3/3] scrrun: Implement HashVal for floating point keys (try2)
by Marvin 24 Feb '15

24 Feb '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=11712 Your paranoid android. === wvistau64 (64 bit dictionary) === dictionary.c:349: Test failed: got hash 0x000001f4 dictionary.c:374: Test failed: got hash 0x000001f4 === w2008s64 (64 bit dictionary) === dictionary.c:349: Test failed: got hash 0x000001f4 dictionary.c:374: Test failed: got hash 0x000001f4

1 0

Re: [PATCH 3/3] scrrun: Implement HashVal for floating point keys
by Marvin 24 Feb '15

24 Feb '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=11703 Your paranoid android. === w2000pro (32 bit dictionary) === dictionary.c:240: Test failed: 0: text mode: got hash 0x00000415, expected 0x00000000 dictionary.c:254: Test failed: 0: db mode: got hash 0x00000415, expected 0x00000000 dictionary.c:240: Test failed: 1: text mode: got hash 0x000003e8, expected 0x00000000 dictionary.c:254: Test failed: 1: db mode: got hash 0x000003e8, expected 0x00000000 dictionary.c:240: Test failed: 2: text mode: got hash 0x0000028a, expected 0x00000000 dictionary.c:254: Test failed: 2: db mode: got hash 0x0000028a, expected 0x00000000 dictionary.c:240: Test failed: 3: text mode: got hash 0x00000061, expected 0x00000000 dictionary.c:254: Test failed: 3: db mode: got hash 0x00000061, expected 0x00000000 dictionary.c:240: Test failed: 4: text mode: got hash 0x00000061, expected 0x00000000 dictionary.c:254: Test failed: 4: db mode: got hash 0x00000061, expected 0x00000000 dictionary.c:263: Test failed: got 0x00000000 dictionary.c:271: Test failed: got 0x00000000 dictionary.c:279: Test failed: got 0x00000000 dictionary.c:281: Test failed: got hash 0x000000a1 dictionary.c:287: Test failed: got 0x00000000 dictionary.c:295: Test failed: got 0x00000000 dictionary.c:303: Test failed: got 0x00000000 dictionary.c:347: Test failed: got 0x00000000 dictionary.c:349: Test failed: got hash 0x00000000 dictionary.c:372: Test failed: got 0x00000000 dictionary.c:374: Test failed: got hash 0x00000000 === w2003std (32 bit dictionary) === dictionary.c:263: Test failed: got 0x00000000 dictionary.c:271: Test failed: got 0x00000000 dictionary.c:279: Test failed: got 0x00000000 dictionary.c:281: Test failed: got hash 0x000000a1 dictionary.c:287: Test failed: got 0x00000000 dictionary.c:295: Test failed: got 0x00000000 dictionary.c:303: Test failed: got 0x00000000 dictionary.c:347: Test failed: got 0x00000000 dictionary.c:372: Test failed: got 0x00000000 === wvistau64 (64 bit dictionary) === dictionary.c:347: Test failed: got 0x00000000 dictionary.c:349: Test failed: got hash 0x000001f4 dictionary.c:372: Test failed: got 0x00000000 dictionary.c:374: Test failed: got hash 0x000001f4 === w2008s64 (64 bit dictionary) === dictionary.c:347: Test failed: got 0x00000000 dictionary.c:349: Test failed: got hash 0x000001f4 dictionary.c:372: Test failed: got 0x00000000 dictionary.c:374: Test failed: got hash 0x000001f4

1 0

Re: [PATCH 2/3] scrrun: Implement HashVal property for integer keys
by Marvin 24 Feb '15

24 Feb '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=11702 Your paranoid android. === w2000pro (32 bit dictionary) === dictionary.c:211: Test failed: 0: text mode: got hash 0x00000415, expected 0x00000000 dictionary.c:225: Test failed: 0: db mode: got hash 0x00000415, expected 0x00000000 dictionary.c:211: Test failed: 1: text mode: got hash 0x000003e8, expected 0x00000000 dictionary.c:225: Test failed: 1: db mode: got hash 0x000003e8, expected 0x00000000 dictionary.c:211: Test failed: 2: text mode: got hash 0x0000028a, expected 0x00000000 dictionary.c:225: Test failed: 2: db mode: got hash 0x0000028a, expected 0x00000000 dictionary.c:211: Test failed: 3: text mode: got hash 0x00000061, expected 0x00000000 dictionary.c:225: Test failed: 3: db mode: got hash 0x00000061, expected 0x00000000 dictionary.c:211: Test failed: 4: text mode: got hash 0x00000061, expected 0x00000000 dictionary.c:225: Test failed: 4: db mode: got hash 0x00000061, expected 0x00000000 dictionary.c:234: Test failed: got 0x00000000 dictionary.c:242: Test failed: got 0x00000000 dictionary.c:250: Test failed: got 0x00000000 dictionary.c:252: Test failed: got hash 0x000000a1 dictionary.c:258: Test failed: got 0x00000000 dictionary.c:266: Test failed: got 0x00000000 dictionary.c:274: Test failed: got 0x00000000 === w2003std (32 bit dictionary) === dictionary.c:234: Test failed: got 0x00000000 dictionary.c:242: Test failed: got 0x00000000 dictionary.c:250: Test failed: got 0x00000000 dictionary.c:252: Test failed: got hash 0x000000a1 dictionary.c:258: Test failed: got 0x00000000 dictionary.c:266: Test failed: got 0x00000000 dictionary.c:274: Test failed: got 0x00000000

1 0

Re: [PATCH 1/3] scrrun: Implement HashVal property for VT_BSTR case
by Marvin 24 Feb '15

24 Feb '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=11701 Your paranoid android. === w2000pro (32 bit dictionary) === dictionary.c:201: Test failed: 0: text mode: got hash 0x00000415, expected 0x00000000 dictionary.c:215: Test failed: 0: db mode: got hash 0x00000415, expected 0x00000000 dictionary.c:201: Test failed: 1: text mode: got hash 0x000003e8, expected 0x00000000 dictionary.c:215: Test failed: 1: db mode: got hash 0x000003e8, expected 0x00000000 dictionary.c:201: Test failed: 2: text mode: got hash 0x0000028a, expected 0x00000000 dictionary.c:215: Test failed: 2: db mode: got hash 0x0000028a, expected 0x00000000 dictionary.c:201: Test failed: 3: text mode: got hash 0x00000061, expected 0x00000000 dictionary.c:215: Test failed: 3: db mode: got hash 0x00000061, expected 0x00000000 dictionary.c:201: Test failed: 4: text mode: got hash 0x00000061, expected 0x00000000 dictionary.c:215: Test failed: 4: db mode: got hash 0x00000061, expected 0x00000000

1 0

Re: [2/3] winmm: Add .wav extension when searching for PlaySound.
by Marvin 24 Feb '15

24 Feb '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=11694 Your paranoid android. === w2000pro (32 bit wave) === wave.c:1679: Test failed: PlaySound succeeded, got 1 === wxppro (32 bit wave) === wave.c:1679: Test failed: PlaySound succeeded, got 1 === w2003std (32 bit wave) === wave.c:1679: Test failed: PlaySound succeeded, got 1 === wvistau64 (32 bit wave) === wave.c:1662: Test failed: PlaySound failed, got 0 wave.c:1666: Test failed: PlaySound failed, got 0 wave.c:1674: Test failed: PlaySound failed, got 0 === w2008s64 (32 bit wave) === wave.c:1662: Test failed: PlaySound failed, got 0 wave.c:1666: Test failed: PlaySound failed, got 0 wave.c:1674: Test failed: PlaySound failed, got 0 === wvistau64 (64 bit wave) === wave.c:1662: Test failed: PlaySound failed, got 0 wave.c:1666: Test failed: PlaySound failed, got 0 wave.c:1674: Test failed: PlaySound failed, got 0 === w2008s64 (64 bit wave) === wave.c:1662: Test failed: PlaySound failed, got 0 wave.c:1666: Test failed: PlaySound failed, got 0 wave.c:1674: Test failed: PlaySound failed, got 0

1 0

Re: [3/5] comctl32: Implement TaskDialogIndirect as a custom dialog box (try 2)
by Nikolay Sivov 24 Feb '15

24 Feb '15

On 23.02.2015 15:42, Joachim Priesner wrote: > + if (IS_INTRESOURCE(text)) > + { > + SetLastError(S_OK); > + LoadStringW(instance, LOWORD(text), (LPWSTR)result, 0); > + return HRESULT_FROM_WIN32(GetLastError()); > + } You don't need SetLastError(), especially not with HRESULT value. And GetLastError() should only be used when LoadStringW() fails. The rest looks good enough to me.

3 8

Re: [1/3] winmm/tests: Add tests for PlaySound().
by Marvin 24 Feb '15

24 Feb '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=11693 Your paranoid android. === w2000pro (32 bit wave) === wave.c:1679: Test failed: PlaySound succeeded, got 1 === wxppro (32 bit wave) === wave.c:1679: Test failed: PlaySound succeeded, got 1 === w2003std (32 bit wave) === wave.c:1679: Test failed: PlaySound succeeded, got 1 === wvistau64 (32 bit wave) === wave.c:1662: Test failed: PlaySound failed, got 0 wave.c:1666: Test failed: PlaySound failed, got 0 wave.c:1674: Test failed: PlaySound failed, got 0 === w2008s64 (32 bit wave) === wave.c:1662: Test failed: PlaySound failed, got 0 wave.c:1666: Test failed: PlaySound failed, got 0 wave.c:1674: Test failed: PlaySound failed, got 0 === wvistau64 (64 bit wave) === wave.c:1662: Test failed: PlaySound failed, got 0 wave.c:1666: Test failed: PlaySound failed, got 0 wave.c:1674: Test failed: PlaySound failed, got 0 === w2008s64 (64 bit wave) === wave.c:1662: Test failed: PlaySound failed, got 0 wave.c:1666: Test failed: PlaySound failed, got 0 wave.c:1674: Test failed: PlaySound failed, got 0

1 0

Re: [PATCH] uxtheme: support images in GetThemeBackgroundRegion
by Alexandre Julliard 24 Feb '15

24 Feb '15

Mark Harmstone <hellas(a)burntcomma.com> writes: > + dc = CreateCompatibleDC(NULL); > + if (!dc) { > + WARN("CreateCompatibleDC failed\n"); > + DeleteObject(hrgn); > + return E_FAIL; > + } > + > + bmp = CreateBitmap(rect->right - rect->left, rect->bottom - rect->top, 1, 32, NULL); You need a DIB for this, not a device bitmap. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] ntdll/tests: Add tests for TpSimpleTryPost function.
by Alexandre Julliard 24 Feb '15

24 Feb '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > + /* post the callback using new threadpool */ > + userdata = 0; > + memset(&environment, 0, sizeof(environment)); > + environment.Version = 1; > + environment.Pool = pool; > + status = pTpSimpleTryPost(simple_cb, &userdata, &environment); > + ok(!status, "TpSimpleTryPost failed with status %x\n", status); > + while (userdata == 0) Sleep(10); > + ok(userdata == 1, "expected userdata = 1, got %u\n", userdata); Please try to use synchronization objects instead of sleeps. > + /* make sure worker threads have terminated */ > + Sleep(100); Same here. Why do you need that? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/5] comctl32: Add and fix tests for invalid TaskDialogIndirect arguments (try 2)
by Nikolay Sivov 24 Feb '15

24 Feb '15

On 23.02.2015 15:41, Joachim Priesner wrote: > > START_TEST(taskdialog) > @@ -49,6 +79,20 @@ START_TEST(taskdialog) > if (!load_v6_module(&ctx_cookie, &hCtx)) > return; > > + hComctl32 = LoadLibraryA("comctl32.dll"); > + if (!hComctl32) > + { > + skip("Failed to load comctl32.dll. Skipping the test\n"); > + return; > + } It's unlikely if will fail to load, also load_v6_module() already calls LoadLibraryA(), so you probably need GetModuleHandle().

1 0

Re: makedep: Sanitize the module names before turning them into resource ids.
by Alexandre Julliard 24 Feb '15

24 Feb '15

Francois Gouget <fgouget(a)free.fr> writes: > Resource ids cannot contain dashes so replace them with underscores. > This makes it possible to build tests for dlls containing dashes into their names like the api-* ones. There's no reason that resource ids can't contain dashes, and besides, winetest won't know what to do with it if you change the name. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: dwrite/tests: Place test font file in a temporary location, make sure it's deleted at the end
by Marvin 23 Feb '15

23 Feb '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=11677 Your paranoid android. === wvistau64 (32 bit font) === font.c:99: Test failed: failed to delete file L"wine_test_font.ttf", error 2 === w2008s64 (32 bit font) === font.c:99: Test failed: failed to delete file L"wine_test_font.ttf", error 2 === wvistau64 (64 bit font) === font.c:99: Test failed: failed to delete file L"wine_test_font.ttf", error 2 === w2008s64 (64 bit font) === font.c:99: Test failed: failed to delete file L"wine_test_font.ttf", error 2 === wvistau64 (32 bit analyzer) === analyzer.c:474: Test failed: failed to delete file L"C:\\Users\\winetest\\AppData\\Local\\Temp\\wine_test_font.ttf", error 5 === w2008s64 (32 bit analyzer) === analyzer.c:474: Test failed: failed to delete file L"C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\wine_test_font.ttf", error 5 === wvistau64 (64 bit analyzer) === analyzer.c:474: Test failed: failed to delete file L"C:\\Users\\winetest\\AppData\\Local\\Temp\\wine_test_font.ttf", error 5 === w2008s64 (64 bit analyzer) === analyzer.c:474: Test failed: failed to delete file L"C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\wine_test_font.ttf", error 5

1 0

Abbreviation of "microsecond" in sane.ds
by Alex Henrie 23 Feb '15

23 Feb '15

http://source.winehq.org/git/wine.git/blob/c72f9a0082c3cc07454fb93bca88e294… Is there a compelling reason why "microsecond" is abbreviated as "us" instead of "μs"? This library doesn't correspond to any Windows library, so we should be free to use the more correct abbreviation. Or can sane.rc only accept ASCII characters? -Alex

3 3

Re: mshtml/tests: Remove an always true conditional subexpression (PVS-Studio)
by Marvin 23 Feb '15

23 Feb '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=11654 Your paranoid android. === wvistau64 (32 bit events) === events.c:939: Test failed: unexpected call img_onerror === w7u (32 bit events) === events.c:939: Test failed: unexpected call img_onerror The test timed out

2 1

Re: fltmgr.sys: add stub dll (try 2)
by Alistair Leslie-Hughes 23 Feb '15

23 Feb '15

On 11/02/15 08:15, Austin English wrote: > https://bugs.winehq.org/show_bug.cgi?id=23583 > > -- > -Austin > This file belongs in the "system32\drivers" directory. Best Regards Alistair Leslie-Hughes

2 1

Re: [2/2] version: Test for VerQueryValueA
by Stefan Dösinger 23 Feb '15

23 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-18 um 22:41 schrieb Mark Jansen: > + char preparedbuffer[] = { > + 0x04, 0x01, 0x34, 0x00, 0x00, 0x00, 0x56, 0x00, 0x53, 0x00, 0x5f, 0x00, 0x56, 0x00, 0x45, 0x00, > + 0x52, 0x00, 0x53, 0x00, 0x49, 0x00, 0x4f, 0x00, 0x4e, 0x00, 0x5f, 0x00, 0x49, 0x00, 0x4e, 0x00, > + 0x46, 0x00, 0x4f, 0x00, 0x00, 0x00, 0x00, 0x00, 0xbd, 0x04, 0xef, 0xfe, 0x00, 0x00, 0x01, 0x00, > + 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, > ... Is it possible to put the test data into dlls/version/test/version.rc in plain text instead of using an unreadable blob? If not, please add a comment to explain what is in the blob. > + ret = VerQueryValueA(preparedbuffer, "StringFileInfo", (LPVOID*)&p, &len); > + ok(ret, "VerQueryValue error %u\n", GetLastError()); > + ok(len == 0, "VerQueryValue returned %u, expected 0\n", len); > + ok(p != (char *)0xdeadbeef, "not expected 0xdeadbeef\n"); Does p point to a 0 byte now? (i.e., ok(!*p, "Expected a terminated string\n"); or something like this.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU6ukyAAoJEN0/YqbEcdMwivkQAIz6mLYCOP2607ACoDIuX58M 5oaF83RA4wjqTAtOQYbIGFqTtM0kT5rANLgh5cMkgNETSttl8ZgJlyECUmz8ArHA VQv0kr0VsgdurFmhoxA37Cw9kou4b2hgsyimfr0dvjahJAroZJgIzXSbtUVgMVQ3 SUoluqPMSuXod/xW78lVwLI5HLm79/cJdizo+PiWLmLrlNiga6k295eKAfd5Tcco qHo+bCf56s0FRlaD4eZ+5AWl5nDP0eP7aGpddBtk4a0Y5E/3npD+9KE2L/hIlTdy kbSSW+NUfWAIUKzVFgVr9m/ejGjTMCb6ieHfuK/7S9oU6jCJyM/mwg++vsgdUJbI ts03c3UXV/JXGuDSEkxqMNLdhVM0Jv9RLCz4GlwdH7LlSiO9UOGjUpMF2steuULm FwirfHXCV1FyZBWIZyHfUw9wykoY4613S49Iq3EGZKKPQmzSi0p+Aygm2Mz6+LhM ApI/rVpGs7rqTxYZWZEgcaadpCGlwczOrgbQYEEoxdaYMm8GbEWRyDXjsHiC9NF4 RbWV+n69+wzC7bOIYqHQSkXEWNEuFlLjn4MElHCqBkGlwTsw9HIPofN6wDbORONt xKP5s14VduDyJdT21jYLJJUvIxO3R7OSNxoWIoKBOofFlQeT0c6WHvnqSqW9e7ED sX3108dzC77WwIVODqFm =gsJF -----END PGP SIGNATURE-----

2 1

Re: [PATCH 2/3] ntdll/tests: Add tests for RtlIpv6StringToAddress (try 3)
by Stefan Dösinger 23 Feb '15

23 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks again for your work and patience! This goes in the right direction in my eyes. The full set of address tests are run against both versions, and it documents the differences between non-ex and ex better. Can you do the same with the ipv4 tests in patch 1? Am 2015-02-19 um 23:38 schrieb Mark Jansen: > +/* ipv6 addresses from https://github.com/beaugunderson/javascript-ipv6/tree/master/test/data */ > +static const struct > +{ > + PCSTR address; > + NTSTATUS res; > + int terminator_offset; > + int ip[8]; > + int broken; What is the meaning of broken here? Different behavior among different Windows versions? Or deviation from your source above? > + int ex_fails; /* 1 means ex should fail, 2 means skip for ex */ Style hint: You can use an enum in this case. I guess you need the skip value because the last test fails on non-ex and succeeds on ex and your expected address does not match. Similarly, the behavior that the function writes to the output address even in case of a failure isn't exactly helpful. - From patch 3: > + if (ipv6_tests[i].ex_fails == 2) /* testing vs ex doesnt >make sense. */ > + continue; Please document why, it took me a while to come up with the guess above. (And I'm not even sure it's the real reason). You're also not checking the output IP for the IP tests from the non-ex tests here. Is there a reason for that? Are there any cases where -Ex returns a different IP than non-ex? > + if (ipv6_tests[i].ip[0] == -1) > + { > + for (j = 0; j < 8; ++j) > + expected_ip.s6_words[j] = 0xabab; > + } I guess you want to avoid writing 0xabab 8 times in the table. I don't have any objection, but I can't predict if Alexandre likes it - technically this is redundant code. I'd say keep it for now, if he doesn't like it he will tell you. > + for (j = 0; j < 8; ++j) > + expected_ip.s6_words[j] = ipv6_tests[i].ip[j]; Would this do the right thing on big endian machines? About some individual tests: > + { "1111:2222:3333:4444:5555:6666:7777::", STATUS_SUCCESS, 34, { 0x1111, 0x2222, 0x3333, 0x4444, 0x5555, 0x6666, 0x7777, 0 }, 1 }, Now that's an interesting corner case. Out of curiosity, what does "1111:2222:3333:4444:5555:6666:7777:" do in non-ex and ex (one : removed)? > + { "::0:0:0:0:0:0:0", STATUS_SUCCESS, 13, { 0, 0, 0, 0, 0, 0, 0, 0 }, 0, 1 }, > + { "::0:a:b:c:d:e:f", STATUS_SUCCESS, 13, { 0, 0, 0, 0xa00, 0xb00, 0xc00, 0xd00, 0xe00 }, 0, 1 }, Here it would be interesting to know what IP -Ex writes before it fails. I don't see why -Ex would fail if -Ex calls non-ex, given that the terminator points way beyond the problematic "::" at the start. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5xDbAAoJEN0/YqbEcdMwmEIP/0ti3aPWMeI8yetig2eTIuAG 2QhNad7bgFgioJBremjKPDuDJViYhkv4XoIwie6bRFSF9VnEECmiv2wObhRz2e0E MgK1bGkZc0BXs4TiVoa/+JVxWgo3ddWn1Wpj+hyVRAvyEfj4NNfRWvcGaQ+cZmwu Sd0tx7BqCQLSPnNwyrl53nqVWjkkmARdSF2pLDMgXkwtGXlR2b2irYslYg+Sqgvb +ORAryKZvVLt8vL6wBclb8ruFWpro7/Rio6eZb8EfoRNH+8YdYWUrdfcoCE4Ui0i W2xsOnahZuPvuQR9id8zp4etIa+YrlGlVsIfHZrzDzCvbyuBlq+niSeWZxgNwMs+ IUpHoHj0TYNUZ9A7PB16UPHowsPVE5GYvsdjFr4Rj8rHxQqvftpTwFxRqWuV4qkQ Qx+achRcfA/qXWWYHksENuQJxF29vIbgiLbpvW256A6zmsAvB/+LlqndeF+BuW4I 3rQ2H7ADBAMx8IscePSDNLAKd2vsYWj8gFlw7y10HnIE7/zedqtWPIaGocFnS0u5 QR/ETfUW5uvOr4rqMcyMCxg3yhc/QvYV67LFMrLusJ1IlCBhcfAC4r2B91sECHXr fJvdfGwL6HBt3tAJ5zxXZjTEwiFc77TGxswbt4lQplhFqTHfi/ZovGUiS/W3nQl6 vX0zFtoYLTRAK0KtCNiP =JRkZ -----END PGP SIGNATURE-----

2 3

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 7)
by Stefan Dösinger 23 Feb '15

23 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks again for your work! Am 2015-02-23 um 08:41 schrieb Alistair Leslie-Hughes: > +{ > + if (!This->comp_count) > + This->components = heap_alloc( sizeof(struct component *) * This->comp_count+1 ); > + else > + This->components = heap_realloc(This->components, sizeof(struct component *) * This->comp_count+1 ); > + > + This->components[This->comp_count] = item; > + This->comp_count++; > +} This still has no error checks. > @@ -369,9 +397,48 @@ static HRESULT WINAPI IDirectPlay8AddressImpl_GetComponentByIndex(IDirectPlay8Ad > const DWORD dwComponentID, WCHAR *pwszName, DWORD *pdwNameLen, void *pvBuffer, > DWORD *pdwBufferSize, DWORD *pdwDataType) > { > ... > + if (!pdwNameLen || !pdwBufferSize) > + return E_POINTER; In GetComponentByName you have additional checks for !pvBuffer. What is pwszName name used for? Are you supposed to write the name of the retrieved component (with proper length checks)? > case DPNA_DATATYPE_STRING: > + if(dwDataSize != ((strlenW((WCHAR*)lpvData)+1) * sizeof(WCHAR))) > + return DPNERR_INVALIDPARAM; I expect this also applies to DPNA_DATATYPE_STRING_ANSI. Please move it to a separate patch (preferably before the GetComponentByIndex changes), together with the tests for the length check. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU6uQ9AAoJEN0/YqbEcdMwW4wP/0wYOQ+Sw3FZw/TAQ682yMmb FJBuRuymWoQthCAnc7kS7wsDwz+erbNPqjFE/MUrbuTHeIRtRJegtMTcLsq/ycSx pzV9uaZoG9MkGMPky/TTgWAyOvWu6w1fVBgUunnQlX8okMk+HMve+qiayeuHSgj9 CyznrrG/gLsVamZfJidnpMlwJ3a2Az5GOYG3yoCKGEiBzthS8niRvf4PLrNa/T5s /YUcfoorChwNnTEu1F+BEJt/CJTFy+qnrGOplDo5cCG6XJ9cK10JEsXybShSA1LT byol2yxMHNR1MdKw/ZsDJiS8RDnCPKTZiaY45FB7BZkyle5J/jJ9wfkBX/L+ID3M mMM1qo5nKjjbiICMkYIRHO4LW9lyCT4FKBLkXwGWTo7Npxpb7iB5Jo2X5sl8o3K4 d1TL7kjdmIj3nz+TbPyVrZZHV4GkBJ3Wgmv1b+uNdPQ6SSotzy6I6FzG1YkivQvF mo8cFFJTs0OO/fUBN5wggkiU4YAheHn258wz7EcepyPMH431GsFp9QVcZbNEQVNi hEasoqLeql/GzI0ZRmOLTLdueVsajZGhoHLGgN10SSql60dfsPZhfpQMrhsX8HQf Ub5SXqAWAc3vZmvv1I1POyUATNxTV8WWZfSmd7QBv+4qsJX2hsXE3Y4/I8cmIv0I OonvF4surL4lU+vFIkJC =eOzT -----END PGP SIGNATURE-----

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 7)
by Marvin 23 Feb '15

23 Feb '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=11662 Your paranoid android. === w8 (32 bit address) === The test timed out

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 6)
by Marvin 23 Feb '15

23 Feb '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=11659 Your paranoid android. === w2000pro (32 bit address) === address.c:100: Test failed: got 0x80070057 === wxppro (32 bit address) === address.c:100: Test failed: got 0x80070057 === w2003std (32 bit address) === address.c:100: Test failed: got 0x80070057 === wvistau64 (32 bit address) === address.c:100: Test failed: got 0x80070057 === w2008s64 (32 bit address) === address.c:100: Test failed: got 0x80070057 === w7u (32 bit address) === address.c:100: Test failed: got 0x80070057 === w8 (32 bit address) === The test timed out === wvistau64 (64 bit address) === address.c:100: Test failed: got 0x80070057 === w2008s64 (64 bit address) === address.c:100: Test failed: got 0x80070057

1 0

Want to work in your project in Google summer of code 2015
by Shanti Swarup Tunga 22 Feb '15

22 Feb '15

Sir I Shanti Swarup Tunga , having good knowledge in C programming want to work in your project . So kindly suggest me some prerequisite knowledge to apply for your project.

2 1

Re: d3d8/tests: Test the return value of CreateVolumeTexture (PVS-Studio)
by Marvin 21 Feb '15

21 Feb '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=11656 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2557: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2562: Test failed: The focus window is active. device.c:2570: Test failed: Got unexpected hr 0x88760869. device.c:2576: Test failed: Got unexpect screen size 800x600. device.c:2591: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2600: Test failed: Got unexpect screen size 800x600. device.c:2613: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2621: Test failed: Got unexpect width 640. device.c:2622: Test failed: Got unexpect height 480.

2 1

Re: [PATCH 2/5] d3d9/tests: Add a test for 2D D3DFMT_V16U16 textures.
by Stefan Dösinger 20 Feb '15

20 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am working on a more comprehensive test for V8U8, V16U16, L6V5U5, X8L8V8U8 and Q8W8V8U8. I have attached the current status of this test. I am still struggling with finding the right precision that makes all Windows machines happy. There are also some problems with our conversion code. Your test tests the case of a non-even width, whereas my test doesn't do that. I can build that into my test as well. We can still commit your test if you want, and I'll remove it again in my patch (together with x8l8v8u8_test). Stefan Am 2015-02-20 um 13:06 schrieb Matteo Bruni: > --- > dlls/d3d9/tests/visual.c | 148 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 148 insertions(+) > > diff --git a/dlls/d3d9/tests/visual.c b/dlls/d3d9/tests/visual.c > index 5f64ec3..2152ba6 100644 > --- a/dlls/d3d9/tests/visual.c > +++ b/dlls/d3d9/tests/visual.c > @@ -16208,6 +16208,153 @@ done: > DestroyWindow(window); > } > > +static void v16u16_test(void) > +{ > + IDirect3DTexture9 *texture; > + IDirect3DPixelShader9 *shader; > + IDirect3DDevice9 *device; > + D3DLOCKED_RECT rect; > + IDirect3D9 *d3d; > + unsigned int i; > + ULONG refcount; > + D3DCAPS9 caps; > + SHORT *texel; > + DWORD color; > + HWND window; > + HRESULT hr; > + > + static const struct > + { > + struct vec3 position; > + struct vec2 texcrd; > + } > + quads[] = > + { > + {{-1.0f, -1.0f, 0.0f}, {0.0f, 0.0f}}, > + {{-1.0f, 1.0f, 0.0f}, {0.0f, 1.0f}}, > + {{ 1.0f, -1.0f, 1.0f}, {1.0f, 0.0f}}, > + {{ 1.0f, 1.0f, 1.0f}, {1.0f, 1.0f}}, > + }; > + static const DWORD shader_code[] = > + { > + 0xffff0101, /* ps_1_1 */ > + 0x00000051, 0xa00f0000, 0x3f000000, 0x3f000000, /* def c0, 0.5, 0.5, */ > + 0x3f000000, 0x3f000000, /* 0.5, 0.5 */ > + 0x00000042, 0xb00f0000, /* tex t0 */ > + 0x00000004, 0x800f0000, 0xb0e40000, 0xa0e40000, 0xa0e40000, /* mad r0, t0, c0, c0 */ > + 0x0000ffff /* end */ > + }; > + > + window = CreateWindowA("static", "d3d9_test", WS_OVERLAPPEDWINDOW | WS_VISIBLE, > + 0, 0, 640, 480, NULL, NULL, NULL, NULL); > + d3d = Direct3DCreate9(D3D_SDK_VERSION); > + ok(!!d3d, "Failed to create a D3D object.\n"); > + if (!(device = create_device(d3d, window, window, TRUE))) > + { > + skip("Failed to create a D3D device, skipping tests.\n"); > + goto done; > + } > + > + hr = IDirect3DDevice9_GetDeviceCaps(device, &caps); > + ok(SUCCEEDED(hr), "Failed to get device caps, hr %#x.\n", hr); > + if (caps.PixelShaderVersion < D3DPS_VERSION(1, 1)) > + { > + skip("No ps_1_1 support, skipping tests.\n"); > + IDirect3DDevice9_Release(device); > + goto done; > + } > + if (FAILED(IDirect3D9_CheckDeviceFormat(d3d, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, > + D3DFMT_X8R8G8B8, 0, D3DRTYPE_TEXTURE, D3DFMT_V16U16))) > + { > + skip("V16U16 textures are not supported, skipping test.\n"); > + IDirect3DDevice9_Release(device); > + goto done; > + } > + > + hr = IDirect3DDevice9_SetFVF(device, D3DFVF_XYZ | D3DFVF_TEX1); > + ok(SUCCEEDED(hr), "Failed to set FVF, hr %#x.\n", hr); > + hr = IDirect3DDevice9_CreatePixelShader(device, shader_code, &shader); > + ok(SUCCEEDED(hr), "Failed to create pixel shader, hr %#x.\n", hr); > + hr = IDirect3DDevice9_SetPixelShader(device, shader); > + ok(SUCCEEDED(hr), "Failed to set pixel shader, hr %#x.\n", hr); > + hr = IDirect3DDevice9_SetSamplerState(device, 0, D3DSAMP_MAGFILTER, D3DTEXF_POINT); > + ok(SUCCEEDED(hr), "Failed to set filter, hr %#x.\n", hr); > + > + for (i = 0; i < 2; ++i) > + { > + D3DPOOL pool; > + > + if (i) > + pool = D3DPOOL_SYSTEMMEM; > + else > + pool = D3DPOOL_MANAGED; > + > + hr = IDirect3DDevice9_CreateTexture(device, 1, 2, 1, 0, D3DFMT_V16U16, > + pool, &texture, NULL); > + ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr); > + > + hr = IDirect3DTexture9_LockRect(texture, 0, &rect, NULL, 0); > + ok(SUCCEEDED(hr), "Failed to lock texture, hr %#x.\n", hr); > + > + texel = (SHORT *)((BYTE *)rect.pBits + 0 * rect.Pitch); > + texel[0] = 32767; > + texel[1] = 32767; > + texel = (SHORT *)((BYTE *)rect.pBits + 1 * rect.Pitch); > + texel[0] = -32768; > + texel[1] = 0; > + > + hr = IDirect3DTexture9_UnlockRect(texture, 0); > + ok(SUCCEEDED(hr), "Failed to unlock texture, hr %#x.\n", hr); > + > + if (i) > + { > + IDirect3DTexture9 *texture2; > + > + hr = IDirect3DDevice9_CreateTexture(device, 1, 2, 1, 0, D3DFMT_V16U16, > + D3DPOOL_DEFAULT, &texture2, NULL); > + ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr); > + > + hr = IDirect3DDevice9_UpdateTexture(device, (IDirect3DBaseTexture9 *)texture, > + (IDirect3DBaseTexture9 *)texture2); > + ok(SUCCEEDED(hr), "Failed to update texture, hr %#x.\n", hr); > + > + IDirect3DTexture9_Release(texture); > + texture = texture2; > + } > + > + hr = IDirect3DDevice9_SetTexture(device, 0, (IDirect3DBaseTexture9 *)texture); > + ok(SUCCEEDED(hr), "Failed to set texture, hr %#x.\n", hr); > + > + hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, 0x00ff00ff, 1.0f, 0); > + ok(SUCCEEDED(hr), "Failed to clear, hr %#x.\n", hr); > + hr = IDirect3DDevice9_BeginScene(device); > + ok(SUCCEEDED(hr), "Failed to begin scene, hr %#x.\n", hr); > + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, &quads[0], sizeof(*quads)); > + ok(SUCCEEDED(hr), "Failed to draw, hr %#x.\n", hr); > + hr = IDirect3DDevice9_EndScene(device); > + ok(SUCCEEDED(hr), "Failed to end scene, hr %#x.\n", hr); > + > + color = getPixelColor(device, 320, 160); > + ok (color_match(color, 0x00007fff, 1), > + "Expected color 0x00007fff, got %#x, V16U16 input -32768, 0.\n", color); > + color = getPixelColor(device, 320, 400); > + ok (color_match(color, 0x00ffffff, 1), > + "Expected color 0x00ffffff, got %#x, V16U16 input 32767, 32767.\n", color); > + > + hr = IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL); > + ok(SUCCEEDED(hr), "Failed to present, hr %#x.\n", hr); > + > + IDirect3DVolumeTexture9_Release(texture); > + } > + > + IDirect3DPixelShader9_Release(shader); > + refcount = IDirect3DDevice9_Release(device); > + ok(!refcount, "Device has %u references left.\n", refcount); > +done: > + IDirect3D9_Release(d3d); > + DestroyWindow(window); > +} > + > static void add_dirty_rect_test_draw(IDirect3DDevice9 *device) > { > HRESULT hr; > @@ -17566,6 +17713,7 @@ START_TEST(visual) > texkill_test(); > x8l8v8u8_test(); > volume_v16u16_test(); > + v16u16_test(); > constant_clamp_ps_test(); > cnd_test(); > dp2add_ps_test(); > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5yi0AAoJEN0/YqbEcdMwXdcP/2QHNZaeHncB/4If+JfpQEOv Vto9Z3ip/eGDuOCRylNjiL47VZfYyuqXHe8EoGzKkuGmtGvPjr2ZhkebUf0l9OIN g2LAqQIa17nYTJFnO6ofzHjcWb++mdIDG1lVUJFKyhIS2vl0xjfB3V4wteMLDffS R6CTtAS49vxFL2lzDwrWaEj2SYhnnybNoKLdhOY5jXH31kcz5W9k3Fzr5Umb2dPB q3tyZHZtYHHsR5kXCmJO6DA456y8euFqzR9GK5/0nDUlh8CGV74pPL6pZMnoPn7c ssXU4HzPB9zPI6zVZBTV8+oOmHWFDn1YZL1M/w50rxY35XvjkU3vs4oezuHMkZBS wXt30QYWBRhFFB3Z2lq9jv9JZXA9V2+A8WmJMbblgv662QsctIAmT9ZAc2xycm7R ye89fHEC3xXFmM6jdJqS1k5MrA5R1li5YFbS18ujcAXVYCW3v8JtK0G05h2zy9e1 KifoVA8o+cVV0Sh2GtYoifLSNvpYo2AlCrP7/cjOyR6igiShK5pF+pktRIlsraM2 3Hl0wGjr2TPhTCTQQPKsskVNvKE+017e4+fwaFI8fRgF3zYSgLSKZELPFY05bzBX OOcbNSEqjRkFtoQoerBR7vx7yrU+85lwd945AGS3URF8KqkavK1LYsAfmLnFu90y YltdeSdbSvQDHCQ4CmmL =D2Pe -----END PGP SIGNATURE-----

3 3

Re: [PATCH 5/5] d3d9/tests: Move a Present out of the loops in fog_with_shader_test().
by Henri Verbeet 20 Feb '15

20 Feb '15

On 20 February 2015 at 13:06, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > It reduces the duration of the visual test with all the other functions > from visual.c compiled out from 9 to 1.5 seconds for me (on a Radeon > HD 5650M, Linux, Mesa). > --- For what it's worth, I think we can actually just remove most of the Present() calls in the tests. It's perhaps fun to keep for nostalgic reasons, but I think the only time anyone really wants to see what gets drawn is while debugging failures.

2 1

Is it possible to detect if a variable is in stack or heap based on its address?
by Bruno Jesus 20 Feb '15

20 Feb '15

Hi all, the subject explains my needs. I would like to understand if printing %p of a pointer can help me check if it's in the stack or was allocated with some memory management functions. Something like: void test() { char stack[10], *heap = HeapAlloc(1234); printf("%p %p", stack, heap); } Can I be sure the first printed value is from stack and the second from heap? A plus question would be: Is it possible to know if an address is a const string? These questions are related to debugging wine functions based on trace debugs. Thanks in advance and best wishes, Bruno

2 2

Re: [PATCH 3/3] dwrite/tests: Test default colors of render target memory HDC
by Marvin 20 Feb '15

20 Feb '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=11640 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/3] dwrite/tests: Fixed font instance leak
by Marvin 20 Feb '15

20 Feb '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=11639 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: iccvid: Allow top-down videos to be played upside down
by Bruno Jesus 20 Feb '15

20 Feb '15

On Wed, Feb 18, 2015 at 7:31 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > In my opinion this is better than not having videos played at all, and > it may attract other people attention to the real problem and possible > solutions on where to invert the buffer after decoding or maybe > decoding directly to the right buffer position inside decode_cinepak. > > Related to bug https://bugs.winehq.org/show_bug.cgi?id=29852 Please ignore this patch, Dmitry is shedding some light in this problem.

1 0

Re: xaudio2_{7, 8}: Implement IXaudio interface as stub (try 2)
by Nikolay Sivov 19 Feb '15

19 Feb '15

> +static const struct IXAudio2Vtbl XAudio2_Vtbl; You wouldn't need this if you've moved XAudio2_create() after vtbl declaration. > + > +HRESULT XAudio2_create(IUnknown *pUnkOuter, LPVOID *ppObj) Please use better names, and "void **". > +{ > + IXAudio2Impl* object; > + > + TRACE("(%p, %p)\n", pUnkOuter, ppObj); > + > + if(pUnkOuter) > + return CLASS_E_NOAGGREGATION; > + > + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IXAudio2Impl)); > + if(!object) > + return E_OUTOFMEMORY; No need for HEAP_ZERO_MEMORY. > + > + *ppObj = object; That's not how it's done - return proper interface pointer. > HRESULT WINAPI DllRegisterServer(void) > { > TRACE("\n"); > - return __wine_register_resources( instance ); > + return __wine_register_resources(instance); > } You can probably leave this as it is.

1 0

Re: [3/5] comctl32: Implement TaskDialogIndirect as a custom dialog box
by Nikolay Sivov 19 Feb '15

19 Feb '15

On 19.02.2015 15:23, Joachim Priesner wrote: > + WCHAR *windowTitleBuffer = NULL; > + UINT len = LoadStringW(config->hInstance, LOWORD(config->pszWindowTitle), (LPWSTR)&ptr, 0); > + if (len) > + { > + windowTitleBuffer = Alloc((len + 1) * sizeof(WCHAR)); > + if (!windowTitleBuffer) > + { > + EndDialog(hwnd, E_OUTOFMEMORY); > + return; > + } > + memcpy(windowTitleBuffer, ptr, len * sizeof(WCHAR)); > + windowTitleBuffer[len] = 0; > + SetWindowTextW(hwnd, windowTitleBuffer); > + } That's essentially the same code you're using to set IDC_CONTENT text. Could you add a helper that does all of that? Also it will probably take fewer lines to use LoadStringW() to fill your buffer and set terminating null. > + /* Destroy unused common buttons. */ > + TRACE("dwCommonButtons=%x\n", config->dwCommonButtons); > + if (!(config->dwCommonButtons & TDCBF_YES_BUTTON)) > + DestroyWindow(GetDlgItem(hwnd, IDYES)); Did you check that it's actually destroyed and not just hidden? > + WCHAR buttonText[1024]; > + int w, h; > + if (GetWindowTextW(hItem, buttonText, 1024)) Where does this limit come from? > + /* Query parent window/desktop size and center window. */ > + monitor = MonitorFromWindow(config->hwndParent ? config->hwndParent : GetActiveWindow(), > + MONITOR_DEFAULTTOPRIMARY); > + monitorInfo.cbSize = sizeof(monitorInfo); > + GetMonitorInfoW(monitor, &monitorInfo); > + windowLeft = (monitorInfo.rcWork.left + monitorInfo.rcWork.right > + - (windowClientWidth + windowBorderWidth)) / 2; > + windowTop = (monitorInfo.rcWork.top + monitorInfo.rcWork.bottom > + - (windowClientHeight + windowBorderHeight)) / 2; > + SetWindowPos(hwnd, 0, windowLeft, windowTop, > + windowClientWidth + windowBorderWidth, windowClientHeight + windowBorderHeight, > + SWP_NOZORDER | SWP_NOACTIVATE | SWP_NOREDRAW); This looks overcomplicated, isn't it enough to use desktop window if no parent was specified? > + DeleteObject(mainInstructionFont); > + Free(contentBuffer); > + Free(mainInstructionBuffer); It's better to free right when you don't need it anymore, and please use simpler/shorter names.

2 1

Re: [2/5] comctl32: Add and fix tests for invalid TaskDialogIndirect arguments
by Nikolay Sivov 19 Feb '15

19 Feb '15

On 19.02.2015 15:22, Joachim Priesner wrote: > +static void test_TaskDialogIndirect_InvalidParameters(void) > +{ No need to be that explicit, just start test_TaskDialogIndirect() with these tests.

1 0

Re: [5/5] comctl32: Implement the TaskDialog function
by Nikolay Sivov 19 Feb '15

19 Feb '15

On 19.02.2015 15:23, Joachim Priesner wrote: > } > > /*********************************************************************** > + * TaskDialog [COMCTL32.@] > + */ > +HRESULT WINAPI TaskDialog(HWND hWndParent, HINSTANCE hInstance, PCWSTR pszWindowTitle, > + PCWSTR pszMainInstruction, PCWSTR pszContent, > + TASKDIALOG_COMMON_BUTTON_FLAGS dwCommonButtons, PCWSTR pszIcon, > + int *pnButton) Please don't use prefixed notation for names. > +static void test_TaskDialog_ProcAddr(void) > +{ > + void *ptr = GetProcAddress(hComctl32, (const CHAR*)344); > + ok(ptr == pTaskDialog, "got wrong pointer for ordinal 344, %p expected %p\n", ptr, pTaskDialog); > +} > + This doesn't need its own test function. > START_TEST(taskdialog) > { > ULONG_PTR ctx_cookie; > @@ -80,11 +87,22 @@ START_TEST(taskdialog) > if (!pTaskDialogIndirect) > { > win_skip("TaskDialogIndirect() is missing. Skipping the tests\n"); > - return; > + } > + else > + { > + test_TaskDialogIndirect_ProcAddr(); > + test_TaskDialogIndirect_InvalidParameters(); > } > > - test_TaskDialogIndirect_ProcAddr(); > - test_TaskDialogIndirect_InvalidParameters(); > + pTaskDialog = (void*)GetProcAddress(hComctl32, "TaskDialog"); > + if (!pTaskDialog) > + { > + win_skip("TaskDialog() is missing. Skipping the tests\n"); > + } > + else > + { > + test_TaskDialog_ProcAddr(); > + } > I don't think you need two win_skip()'s here. If TaskDialogIndirect() is available, TaskDialog() is here too, right?

1 0

Re: [v2 1/4] reg: Add sane_path function to do preliniary key validation
by Stefan Dösinger 19 Feb '15

19 Feb '15

1 0

Re: [PATCH 1/3] ntdll/tests: Add tests for RtlIpv4StringToAddressEx, RtlIpv6StringToAddress (try 2)
by Stefan Dösinger 19 Feb '15

19 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've already talked to Mark about this on #winehackers, just repeating it for the list: My remaining request with these tests is that I believe we should test the full set of inputs against the Ex and non-Ex versions and ideally reuse the test table (for base and ex, not for ipv4 and ipv6). That will tell us if there's any difference in the IP parsing part of the base and Ex functions. It'll also be interesting how the base function handles ports in the string, and, in case of ipv6, brackets around the IP. Other than that two minor style issues: Change the subject of patch one (it only handles RtlIpv4StringToAddressEx), and you still have different levels of indentation in the line continuations of some ok() statements. Cheers, Stefan Am 2015-02-15 um 18:02 schrieb Mark Jansen: > Add test for RtlIpv4StringToAddressEx > > --- dlls/ntdll/tests/rtl.c | 101 > +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, > 101 insertions(+) > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU4c5HAAoJEN0/YqbEcdMwnPIP/RT2i0fG4cPqKikwa26VbRyn EG2yeG78Wjx/vysLuQfGe8alhUycGrgMzW4N4m8QiAx/xNFv4eX0OdI+5gYMbSHK dYZSzTSKbqoJbnBlZwt1MoaaNceX/zIEy2WoaRCYpsUJfpscT/sOdJ+/gW55gDkH 605vvruhgJFSFVeZDVzfR9gQcY51iHB0KDemX2p1mwHElr6+HwYSHOQt+8KCL8YV wfC87NSMEAfEjIudYPL7SFHvUuLr3GoHBBt57R9p/2gNT7eJ7ll9ANvShFkRENjL jmKJQj7exehqrAGNWBqbeIPSjHBQoGl/UZPwIE39UioNhRo+sWi5A8tBbUMyL3o5 VENuxL987kU1L9Xpa6/jEcrQksgafCa742/wWSAjPGE0D2iTUr0hQN0zQoioTPA/ zuaDyDO3CBCyFaF0A9h9FzxOkuRAHo6TSKw0IYOrI2XENAoqQ+B+fX0ll9t/5Tu0 iUIea06yp2/fRButo58sJNAd3dUZpRKf1qT+Eu7Cn+AJfgi3TsKY/Lw0gvyb4XJh qOdp7EPzqY1PURn6+Z8aDwNZRA2du3NM91SSMfwz+qwZtakf8K/XtkpC1CpNLONJ kfltxHVALBKT0NTDzvprrSzvTVH90hJLE+nX/E5Qf6SzeRVqxsPomBtOj2VLuapZ 4ehIhXsaEJJz9jc31tr9 =E0dA -----END PGP SIGNATURE-----

2 2

Re: dlls/dsrole: Add undocumented api set
by Nikolay Sivov 19 Feb '15

19 Feb '15

On 19.02.2015 3:58, Andrew Cook wrote: > Required by native aclui.dll If it's the only user, it's questionable whether we need this module.

2 1

Re: [PATCH 4/5] wined3d: Reject unsupported pitches in wined3d_surface_update_desc().
by Stefan Dösinger 18 Feb '15

18 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-18 um 14:20 schrieb Matteo Bruni: > + if (pitch & (texture_resource->format->byte_count - 1)) > + { > + WARN("Pitch unsupported, not a multiple of the texture format byte width.\n"); > + return WINED3DERR_INVALIDCALL; > + } I'd prefer this to be an ERR instead, and the return statement removed. The idea is that since we don't ever expect this check to be true it shouldn't result in different behavior and can be compiled out in a build where debugging is disabled. The basic idea originated from Henri: https://www.winehq.org/pipermail/wine-devel/2013-August/100974.html . -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5KrDAAoJEN0/YqbEcdMwdj0P/0kphTArNNtcxtIbt5noekiX wTwi7X6YhxkjryHENqvYKKO8ckBftBoxJHo9o4I82Cc+IRvj9GvrvvuZ5FuiMsJO 6dGmo5JSHnGGNG3rl/oZt31v3P/1LAba3GoFAgRwBfXCULue6gNRyC8+57ahlbLy xVWc2m249URRP3ML/O9+bXlzA61oQdS+5q54T+jmYv3X8K8AgDHATu114mcpxaAq hkHIKmW2WCoigCBrNHQTzcxMG3lsavMbnuMxSvQ/01/mwrKvmYYkvvBtR/AVI6W+ I7HLF4KZlz5BLZnS71joW2LLL35/z/3qtmaHi8dq/kCMaajow9dBQmstcUFvwJ4p UknSxgcCOgKreAZH3yTOH5LNgf8qZvB21wQ5Cn0NGEBW7bZKdUxfRftFN8IQY1Ht NhGB9cmvo3Ozv0z+i7wMfcXjntT9wL/2H77RqC4Xb9Z/igo+E2LJN0XqQYvwvtj7 wG4Fw5rH7vrO4g/IcfFYvbT7CMUYrPWtFaTfiMn5IOQZ4mx2gacktHcpZJnCUjw5 /uTQo+089YosnM+xY/WvDnjjI13svZt5c3gUMlvha30RjsX7PDfih/vNrr0qR5Y/ C6TLk8ffbmPOX6TTobndfZrWdb2sP3d7x1T1tx9nMAKJG0HFy5wvFoygEDOzFRYU tG/x7wnrmr3fYfUSEPJY =LuAf -----END PGP SIGNATURE-----

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel