- wine-devel - winehq.org

Re: [1/5] comctl32/tests: more tests for icon spacing calculation
by Alexandre Julliard 25 Jan '13

25 Jan '13

Daniel Jelinski <djelinski1(a)gmail.com> writes: > +#ifdef _WIN64 > + /* NOTE: -1 is not treated the same as (DWORD)-1 by 64bit listview */ > + ret = SendMessage(hwnd, LVM_SETICONSPACING, 0, (DWORD)-1); > +todo_wine { > + expect(100, LOWORD(ret)); > + expect(0xFFFF, HIWORD(ret)); > +} > + ret = SendMessage(hwnd, LVM_SETICONSPACING, 0, 0xBAADF00DDEADBEEFLL); Please avoid ifdefs and long long constants. -- Alexandre Julliard julliard(a)winehq.org

3 2

Wine Wiki needs your help!
by Dimi Paun 25 Jan '13

25 Jan '13

Folks, As we all know, through the years spam has been an ongoing problem. We dealt with it OK, as we valued the openness of our wiki. That's good. However, all this churn has accumulated a lot of garbage on the system, as orphaned pages and dummy users. These have accumulated to such an extent that we are reaching system limits. I need your help to clean them out. First, we have to separate the spam from the real content. I've created a Google Spreadsheet for pages: https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idFNE… and one for users: https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idGdP… We need to mark spam as "Spam" and what's good as "OK" in the "Spam" column. I'll take that data and apply it to the wiki. Please let me know if we can do this any simpler or if there are any problems. Thanks! -- Dimi Paun Lattica, Inc.

8 18

Re: [1/6] windowscodecs: Add tests for IPropertyBag2
by Vincent Povirk 24 Jan '13

24 Jan '13

Other than the 6/6, this series looks good to me. Thanks for breaking this up. It makes it much easier to review.

1 0

Re: [6/6] windowscodecs: Implement IPropertyBag2::Read
by Vincent Povirk 24 Jan '13

24 Jan '13

+ if (idx > -1) + { + VariantInit(pvarValue+i); + res = VariantCopy(pvarValue+i, This->values+idx); + phrError[i] = res; + if (FAILED(res)) + break; + } This looks wrong to me. We have an array of error values to set for each read attempt, so it seems like each read should be independent - one failure shouldn't cause us to give up on the others, nor to free the values we already read successfully. If this is really how Windows works, we need a test for it.

1 0

Re: [5/6] windowscodecs: Implement IPropertyBag2::Write
by Vincent Povirk 24 Jan '13

24 Jan '13

if (This->properties[i].pstrName) { HeapFree(GetProcessHeap(), 0, This->properties[i].pstrName); + VariantClear( This->values+i ); /* Not initialized if pstrName not initialized */ } ... { This->properties = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(PROPBAG2)*count); - - if (!This->properties) + This->values = HeapAlloc(GetProcessHeap(), 0, sizeof(VARIANT)*count); + + if (!This->properties || !This->values) res = E_OUTOFMEMORY; else for (i=0; i < count; i++) Well, that explains why you had the NULL check in the previous patch. If you allocate values with HEAP_ZERO_MEMORY, you don't have to use VariantInit, and you could simplify your Release code (at least in terms of the effort required to verify that it is correct). I think the way it is now is technically correct though. + { + if (pPropBag[i].pstrName) + FIXME("Application tried to set the unknown option %s.\n", + debugstr_w(pPropBag[i].pstrName)); + /* FIXME: Function is not atomar on error, but MSDN does not say anything about it + * (no reset of items between 0 and i-1) */ + return E_FAIL; + } Bit of an indentation glitch there - the return statement isn't (and shouldn't be) in the if statement.

1 0

Re: [4/6] windowscodecs: Implement IPropertyBag2::GetPropertyInfo
by Vincent Povirk 24 Jan '13

24 Jan '13

+ if (This->properties[i].pstrName) + { + HeapFree(GetProcessHeap(), 0, This->properties[i].pstrName); + } HeapFree already checks for NULL, so there's no need for an if statement here.

1 0

Re: [PATCH] ieframe/tests: Don't convert to long path name until the file exists
by Marvin 24 Jan '13

24 Jan '13

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 http://testbot.winehq.org/JobDetails.pl?Key=24128 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === Timeout === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2607: Test failed: expected GetOverridesKeyPath webbrowser.c:2612: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2613: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3046: Test failed: doc_disp == NULL webbrowser: unhandled exception c0000005 at 00402F21

1 0

Re: ws2_32: Use assignment instead of memcpy to copy structs.
by Michael Stefaniuc 24 Jan '13

24 Jan '13

Forgot to add the credit for this patch series as I didn't wrote this coccinelle script: Found using the memcpy-assign.cocci script submitted for inclusion into the Linux kernel: https://systeme.lip6.fr/pipermail/cocci/2013-January/000121.html bye michael On 01/24/2013 02:21 PM, Michael Stefaniuc wrote: > --- > dlls/ws2_32/socket.c | 2 +- > dlls/ws2_32/tests/sock.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index c390828..6fd1e34 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -2183,7 +2183,7 @@ static BOOL interface_bind( SOCKET s, int fd, struct sockaddr *addr ) > > if (setsockopt(fd, IPPROTO_IP, IP_UNICAST_IF, &ifindex, sizeof(ifindex)) != 0) > goto cleanup; /* Failed to suggest egress interface */ > - memcpy(&specific_interface_filter, &generic_interface_filter, sizeof(generic_interface_filter)); > + specific_interface_filter = generic_interface_filter; > specific_interface_filter.iface_rule.k = adapter->Index; > filter_prog.len = sizeof(generic_interface_filter)/sizeof(struct sock_filter); > filter_prog.filter = (struct sock_filter *) &specific_interface_filter; > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 56a64bc..4b4b99a 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -2725,7 +2725,7 @@ static void test_getsockname(void) > return; > } > > - memcpy(&sa_get, &sa_set, sizeof(sa_set)); > + sa_get = sa_set; > if (getsockname(sock, (struct sockaddr*) &sa_get, &sa_get_len) == 0) > ok(0, "getsockname on unbound socket should fail\n"); > else {

1 0

Re: ieframe: Fixed a race in tests
by Marvin 24 Jan '13

24 Jan '13

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 http://testbot.winehq.org/JobDetails.pl?Key=24121 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === Timeout === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2607: Test failed: expected GetOverridesKeyPath webbrowser.c:2612: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2613: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3046: Test failed: doc_disp == NULL webbrowser: unhandled exception c0000005 at 00402F21

1 0

Re: [PATCH 2/2] vbscript: Added GetObject tests
by Marvin 24 Jan '13

24 Jan '13

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 http://testbot.winehq.org/JobDetails.pl?Key=24115 Your paranoid android. === W2KPROSP4 (32 bit createobj) === createobj.c:999: Test failed: ParseScriptText failed: 8007007e createobj.c:1000: Test failed: expected QI_IObjectWithSite createobj.c:1001: Test failed: expected SetSite createobj.c:1002: Test failed: expected reportSuccess createobj.c:1008: Test failed: hres = 8007007e createobj.c:1009: Test failed: expected QI_IObjectWithSite createobj.c:1010: Test failed: expected SetSite createobj.c:1015: Test failed: ParseScriptText failed: 8007007e createobj.c:1016: Test failed: expected QI_IObjectWithSite createobj.c:1017: Test failed: expected reportSuccess

1 0

Please perform MIDI test with MS OS
by Joerg-Cyril.Hoehle＠t-systems.com 24 Jan '13

24 Jan '13

Hi, if you can, please download the test executable from https://testbot.winehq.org/JobDetails.pl?Key=24107 and run it on a native MS machine (32 and 64 bit). Please send me the results, no need to post. I particularly welcome test results from old w9k machines! Thank you, Jörg Höhle

1 0

Re: [PATCH] kernel32: implement condition variables (try 5)
by Marvin 24 Jan '13

24 Jan '13

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 http://testbot.winehq.org/JobDetails.pl?Key=24106 Your paranoid android. === W7PROX64 (32 bit sync) === sync.c:947: Test failed: DeleteTimerQueueTimer sync.c:948: Test failed: ChangeTimerQueueTimer

1 0

Re: [PATCH 5/5] d3d*/tests: Add simple DrawRectPatch tests
by Marvin 24 Jan '13

24 Jan '13

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 http://testbot.winehq.org/JobDetails.pl?Key=24105 Your paranoid android. === WXPPROSP3 (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === W2K3R2SESP2 (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === WVISTAADM (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === W2K8SE (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === W7PRO (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === W7PROX64 (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === TEST64_W7SP1 (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === W7PROX64 (64 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === TEST64_W7SP1 (64 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a.

1 0

Re: [PATCH 5/5] d3d*/tests: Add simple DrawRectPatch tests
by Marvin 24 Jan '13

24 Jan '13

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 http://testbot.winehq.org/JobDetails.pl?Key=24104 Your paranoid android. === WXPPROSP3 (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a. === W2K3R2SESP2 (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a. === WVISTAADM (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a. === W2K8SE (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a. === W7PRO (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a. === W7PROX64 (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a. === TEST64_W7SP1 (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a.

1 0

Re: po: Update Lithuanian translation
by Lauri Kenttä 23 Jan '13

23 Jan '13

I don't really read Lithuanian, but just in case: "No Ports" means "number of ports" or more exactly "number of datagrams which were rejected because the port in the datagram was invalid". Reference: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366929%28v=vs.85%… André, any chance to make the original string (netstat.rc:52, "No Ports") better? -- Lauri Kenttä

1 0

Re: [PATCH 1/8] winhttp: Use schannel in netconn_secure_connect if OpenSSL is not available
by Alexandre Julliard 23 Jan '13

23 Jan '13

Jacek Caban <jacek(a)codeweavers.com> writes: > The following patch makes winhttp use schannel instead of OpenSSL for > SSL (HTTPS) connections. It is made to be as minimal change as possible > (but complete enough to replace all OpenSSL functionality) to limit the > scope for potential regressions. Further changes and improvements are > left for later. It doesn't work here: ../../../tools/runtest -q -P wine -M winhttp.dll -T ../../.. -p winhttp_test.exe.so winhttp.c && touch winhttp.ok net.c:607: read_ssl_chunk: Assertion `bufs[0].cbBuffer < ssl_buf_size' failed. wine: Assertion failed at address 0x68000822 (thread 0028), starting debugger... Unhandled exception: assertion failed in 32-bit code (0x68000822). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68000822 ESP:0032f29c EBP:0032f2a8 EFLAGS:00000206( - -- I - -P- ) EAX:00000000 EBX:000057a6 ECX:000057a6 EDX:00000006 ESI:682e429f EDI:68308ff4 Stack dump: 0x0032f29c: 681d4941 68308ff4 0032f3c8 0032f3d0 0x0032f2ac: 681d7d72 00000006 0032f348 00000000 0x0032f2bc: 0032f2f0 682208ed 00000068 00000058 0x0032f2cc: 0032f3e0 0032f30c 00000068 00000058 0x0032f2dc: 00000050 7d99bd70 68308ff4 00000050 0x0032f2ec: 0000004f 0032f3b8 6820fa92 7d99bd78 Backtrace: =>0 0x68000822 GLIBC_2+0x822() in ld-linux.so.2 (0x0032f2a8) 1 0x681d7d72 abort+0x181() in libc.so.6 (0x0032f3d0) 2 0x681cdb58 __assert_fail+0xf7() in libc.so.6 (0x0032f418) 3 0x68510524 netconn_recv+0x7c3(conn=0x12e98c, buf=0x32fc8d, len=0x13, flags=0x100, recvd=0x32f508) [/home/julliard/wine/wine/dlls/winhttp/net.c:607] in winhttp (0x0032f4c8) 4 0x68513b91 receive_data_chunked+0x80(request=0x12e938, buffer=0x32fc8d, size=0x20, read=0x32fb14, async=0) [/home/julliard/wine/wine/dlls/winhttp/request.c:1733] in winhttp (0x0032fad8) 5 0x685186ed read_data+0x18c(request=0x12e938, buffer=0x32fc80, to_read=0x20, read=0x32fc6c, async=0) [/home/julliard/wine/wine/dlls/winhttp/request.c:1799] in winhttp (0x0032fb68) 6 0x6851a0c2 WinHttpReadData+0x81(hrequest=<couldn't compute location>, buffer=<couldn't compute location>, to_read=<couldn't compute location>, read=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winhttp/request.c:2097] in winhttp (0x0032fbb8) 7 0x684ef626 func_winhttp+0xdd5() [/home/julliard/wine/wine/dlls/winhttp/tests/winhttp.c:879] in winhttp_test (0x0032fd38) 8 0x684de037 main+0x386(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/winhttp/tests/../../../include/wine/test.h:557] in winhttp_test (0x0032fe08) 9 0x684f2e60 __wine_spec_exe_entry+0x7f(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in winhttp_test (0x0032fe58) 10 0x7b8602bc call_process_entry+0xb() in kernel32 (0x0032fe78) 11 0x7b86149b start_process+0x6a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1084] in kernel32 (0x0032feb8) 12 0x7bc7a2e0 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 13 0x7bc7d09d call_thread_func+0x7c(entry=0x7b861430, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2522] in ntdll (0x0032ffa8) 14 0x7bc7a2be call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 15 0x7bc4fc4e start_process+0x1d(kernel_start=0x7b861430) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2691] in ntdll (0x0032ffe8) 16 0x6802947d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 17 0x6802953b wine_switch_to_stack+0x2a(func=0x7bc4fc30, arg=0x7b861430, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xfffe93e8) 18 0x7bc5573f LdrInitializeThunk+0x3be(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2747] in ntdll (0xfffe9458) 19 0x7b867a78 __wine_kernel_init+0xbe7() [/home/julliard/wine/wine/dlls/kernel32/process.c:1257] in kernel32 (0xfffea368) 20 0x7bc55e13 __wine_process_init+0x182() [/home/julliard/wine/wine/dlls/ntdll/loader.c:2956] in ntdll (0xfffea3f8) 21 0x680270c2 wine_init+0x2a1(argc=0x3, argv=0xfffea944, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:841] in libwine.so.1 (0xfffea458) 22 0x7bf00e7b main+0x7a(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:237] in <wine-loader> (0xfffea898) -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] wined3d: Ignore clears if count = 0 and rects != NULL
by Henri Verbeet 23 Jan '13

23 Jan '13

On 23 January 2013 13:14, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > dlls/d3d8/tests/visual.c | 17 +++++++++++++++++ > dlls/d3d9/tests/visual.c | 16 ++++++++++++++++ > dlls/ddraw/tests/ddraw7.c | 36 ++++++++++++++++++++++++++++++++++++ > dlls/wined3d/device.c | 6 ++++++ > 4 files changed, 75 insertions(+) > Although I don't expect a difference in behaviour, it probably wouldn't hurt to add tests for the other ddraw versions as well (i.e. through the viewport interface).

2 2

Re: [PATCH] advapi32: Use the lower 32bit of the special HKEYs on 64bit.
by Alexandre Julliard 23 Jan '13

23 Jan '13

Rico Schüller <kgbricola(a)web.de> writes: > @@ -228,9 +228,9 @@ static NTSTATUS open_key( HKEY *retkey, ACCESS_MASK access, OBJECT_ATTRIBUTES *a > static HKEY create_special_root_hkey( HKEY hkey, DWORD access ) > { > HKEY ret = 0; > - int idx = (UINT_PTR)hkey - (UINT_PTR)HKEY_SPECIAL_ROOT_FIRST; > + int idx = (DWORD)hkey - (DWORD)HKEY_SPECIAL_ROOT_FIRST; > > - if (hkey == HKEY_CURRENT_USER) > + if ((DWORD)hkey == (DWORD)HKEY_CURRENT_USER) You want HandleToUlong and the like. > @@ -947,6 +948,57 @@ static void test_reg_open_key(void) > "RegOpenKeyEx with KEY_WOW64_64KEY failed (err=%u)\n", ret); > RegCloseKey(hkResult); > > + /* check special HKEYs on 64bit > + * only the lower 4 bytes of the supplied key are used > + */ > + if (ptr_size == 64) > + { > + DWORD mask = ~0U; > + HKEY hkBig = (HKEY)((ULONG_PTR)HKEY_CURRENT_USER & mask); > + > + ret = RegOpenKeyA(HKEY_CURRENT_USER, "Software", &hkResult); > + ok(ret == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %d\n", ret); > + ok(hkResult != NULL, "expected hkResult != NULL\n"); > + hkPreserve = hkResult; > + RegCloseKey(hkResult); > + > + hkBig = (HKEY)(((ULONG_PTR)HKEY_CURRENT_USER & mask) | 0x100000000ULL); > + ret = RegOpenKeyA(hkBig, "Software", &hkResult); > + ok(ret == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %d\n", ret); > + ok(hkResult == hkPreserve, "expected hkResult == hkPreserve\n"); > + RegCloseKey(hkResult); Please don't use long long constants. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] advapi32: Use the lower 32bit of the special HKEYs on 64bit.
by Rico Schüller 23 Jan '13

23 Jan '13

Hi, please don't apply this one, I somehow garbled the rebase ... Cheers Rico On 23.01.2013 12:24, Rico Schüller wrote: > --- > dlls/advapi32/registry.c | 18 +++++++------- > dlls/advapi32/tests/registry.c | 54 > ++++++++++++++++++++++++++++++++++++++++-- > 2 files changed, 61 insertions(+), 11 deletions(-) > > > > >

1 0

Re: [1/2] wineps.drv: Implement GetGlyphIndices.
by Dmitry Timoshkov 23 Jan '13

23 Jan '13

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > ExtTextOutW calls GetTextExtentExPointI for the (char_extra || dc->breakExtra) > case, and one of its helpers unconditionally calls dc->GetGlyphIndices and > dc->GetTextExtentExPointI which crashes for a wineps.drv device. > > These 2 patches make ExtTextOutW work in this case. What is the reason that these patches are marked as pending? -- Dmitry.

2 5

Re: include: flesh out d3d11.idl (try 4)
by Dmitry Timoshkov 23 Jan '13

23 Jan '13

Austin English <austinenglish(a)gmail.com> wrote: > try 4: only include enough to add a stub for D3D11CreateDevice, You could also try to make it work for compilers that don't suppport anonymous unions. -- Dmitry.

1 0

Re: macdrv: implement getting and setting the screen saver state, version 6
by Ken Thomases 22 Jan '13

22 Jan '13

On Jan 22, 2013, at 5:33 PM, C.W. Betts wrote: > Yet another fix. Looks good to me. Thanks for doing this and for putting up with me. Cheers, Ken

1 0

macdrv: implement getting and setting the screen saver state. if(Style)
by Joerg-Cyril.Hoehle＠t-systems.com 22 Jan '13

22 Jan '13

Hi, Ken Thomases wrote: >> + if(success != kIOReturnSuccess) >Another style nitpick: please put a space between "if" and the condition. > That applies to the "if(count2)" above, too. I find this over the top. Where is the rule? Andrew Eikum's mmdevapi code -- which I don't consider very old in Wine -- uses exactly 0 space between if and (). So what is it that the Wine "project" can tell new contributors? The only rule I see is: "Look at the code surrounding the patch" and its corollary: "if you create a new module, you're the first and define the style others will have to follow." Regards, Jörg Höhle

3 2

Re: macdrv: implement getting and setting the screen saver state, version 5
by Ken Thomases 22 Jan '13

22 Jan '13

On Jan 22, 2013, at 12:22 PM, C.W. Betts wrote: > This version should fix the problems you mentioned Sorry about this – I should have thought about this last time – but I think you shouldn't fall through in the SPI_SETSCREENSAVEACTIVE case. It's asking for trouble in the future, if anybody adds another case to the switch statement. I think it would be better to just explicitly return FALSE and put in a comment explaining why (like you suggested for the X11 driver). Thanks for your persistence! -Ken

1 0

Re: usp10: add ShapeCharGlyphProp_Latin to properly handle invalid and zero width character properties for Latin
by Alexandre Julliard 22 Jan '13

22 Jan '13

Aric Stewart <aric(a)codeweavers.com> writes: > --- > dlls/usp10/shape.c | 33 +++++++++++++++++++++++++++------ > 1 files changed, 27 insertions(+), 6 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p usp10_test.exe.so usp10.c && touch usp10.ok usp10.c:1407: Test failed: uJustification incorrect usp10.c:1410: Test failed: uJustification incorrect usp10.c:1411: Test failed: fClusterStart incorrect usp10.c:1414: Test failed: fClusterStart incorrect usp10.c:1190: Test failed: 0: uJustification incorrect (0) usp10.c:1190: Test failed: 0: fClusterStart incorrect (0) usp10.c:1190: Test failed: 3: uJustification incorrect (0) usp10.c:1190: Test failed: 3: fClusterStart incorrect (0) make[1]: *** [usp10.ok] Error 8 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: dbghelp: Implement rudimentary stack walk for ARM64
by Eric Pouech 22 Jan '13

22 Jan '13

> + if ((frame->AddrPC.Mode == AddrModeFlat) && > + (frame->AddrFrame.Mode != AddrModeFlat)) this looks strange to me. I guess, you want to check that both mode address modes are AddrModeFlat A+ -- Eric Pouech

2 3

RFC: Remove auto-scan of ALSA devices from winealsa.drv (and get repeatable behaviour)
by Joerg-Cyril.Hoehle＠t-systems.com 22 Jan '13

22 Jan '13

Hi, please view the winmm:wave test results from Francois Gouget's machines fg-acer64-t32 fg-acer64-wow32 fg-acer64-t64 fg-acer64-wow64 http://test.winehq.org/data/dabde6a04f6d02233bc5074a8eba613b2c4adc68/index_… Is their configuration the same except for 32/64bit? We see 3 types of results 2x: 2 devices, no ALSA "default" device(!), one HDA-An, one HDA-HDMI 1x: 3 devices incl. ALSA "default", all tests successful 1x: 3 devices incl. ALSA "default", dev. 1 HDA-An yields MMSYSERR_ALLOCATED Is their configuration truly the same? Is that yet another aretefact of ALSA device enumeration? It could well be. Again, I argue in favor of removing the enumeration code. I want users to get repeatable results. I don't want Wine's winmm to map device 0 as ALSA "default" on one run and "HDMI-An" on another run. Andrew Eikum was in favour of this too and since implemented winmm device notification upon change. Remember the December thread: http://www.winehq.org/pipermail/wine-devel/2012-December/098114.html Of course, the winecfg/GUI issue need be addressed. Regards, Jörg Höhle

4 7

Re: [PATCH 6/8] winhttp: Added schannel-based netconn_get_cipher_strength implementation
by Hans Leidekker 22 Jan '13

22 Jan '13

On Tue, 2013-01-22 at 16:49 +0100, Jacek Caban wrote: > @@ -1460,6 +1460,13 @@ int netconn_get_cipher_strength( netconn_t *conn ) > pSSL_CIPHER_get_bits( cipher, &bits ); > return bits; > #else > - return 0; > + SecPkgContext_ConnectionInfo conn_info; > + SECURITY_STATUS res; > + > + if (!conn->secure) return 0; > + res = QueryContextAttributesW(&conn->ssl_ctx, SECPKG_ATTR_REMOTE_CERT_CONTEXT, (void*)&conn_info); That should be SECPKG_ATTR_CONNECTION_INFO.

2 1

winmm/tests: Allow more margin in the test_asyncWAVE() playback check.
by Joerg-Cyril.Hoehle＠t-systems.com 22 Jan '13

22 Jan '13

Francois, thank you for helping remove timing-caused flakiness from the tests. I believe you forgot to test your patch in Wine(!). The test + ok(400 <= p2 && p2 <= 600, "%ums is not in the expected 400-600ms range\n", p2); should fail in every version of Wine. Ironically, the reason is mentioned in your patch: /* Give Wine's asynchronous thread time to start up. Furthermore, * it uses 3 buffers per second, so that the positions reported * will be 333ms, 667ms etc. at best. */ IIRC, the first non-null position reported by Wine is 667ms, because it successfully queues two 333ms buffers to waveOut. I suggest adding a todo_wine plus an additional ok(0<p2 && strcmp(buf,"2000")) that Wine won't fail. And I'd decrease the sleep to e.g. 200 and 100 <= p2 && p2 <= 300 All those times sum up, the winmm test run long enough already. MCIWave should use winmm:waveOutGetPosition while playing, however the MCI devices hardly have any decent thread-safety and the construct if(status == MODE_PLAYING) waveOutGetPosition(hWave, &pos) else pos = stopped_pos; is unsafe, as the player may have exited meanwhile and closed hWave. It's a compatibility bug since day one of mciwave in git history that the position increments 3 times per second only. Yet so far, no app seems to have been bothered. Regards, Jörg Höhle

2 2

Re: macdrv: implement getting and setting the screen saver state. if(Style)
by Christian Costa 22 Jan '13

22 Jan '13

Well, 'grep "if(" * -r | wc -l' and 'grep "if (" * -r | wc -l'. :) 2013/1/22 Bruno Jesus <00cpxxx(a)gmail.com>: > Out of curiosity can you explain the shell wizardry you used to get the > stats? > > Thanks, > Bruno > > > On Tue, Jan 22, 2013 at 10:52 AM, Christian Costa <titan.costa(a)gmail.com> > wrote: >> >> 2013/1/22 <Joerg-Cyril.Hoehle(a)t-systems.com>: >> > Hi, >> > >> > Ken Thomases wrote: >> >>> + if(success != kIOReturnSuccess) >> >>Another style nitpick: please put a space between "if" and the >> >> condition. >> >> That applies to the "if(count2)" above, too. >> > >> > I find this over the top. Where is the rule? >> > Andrew Eikum's mmdevapi code -- which I don't consider very old in Wine >> > -- >> > uses exactly 0 space between if and (). >> > >> > So what is it that the Wine "project" can tell new contributors? >> > >> > The only rule I see is: "Look at the code surrounding the patch" and >> > its corollary: "if you create a new module, you're the first and define >> > the style others will have to follow." >> > >> >> Hi, >> >> Just some stats regard "if" before Dan beat me at it ;) : >> - without space => 39979 >> - with space => 144133 >> >> The space is better to make the distinction between C keyword and >> function name. Off course it's a personal taste. :) >> >> Bye, >> Christian >> >> > > > > -- > universe* god::bigbang (void); //and then it all began...

1 0

Re: user32/tests: Test standard scrollbar's initialization (try 2).
by Dmitry Timoshkov 22 Jan '13

22 Jan '13

Sergey Guralnik <serhio(a)etersoft.ru> wrote: > Subject: user32/tests: Test standard scrollbar's initialization (try 2). If it matters the test looks good to me. -- Dmitry.

1 0

Re: [PATCH] windowscodecs: Add support for DIB format.
by Dmitry Timoshkov 22 Jan '13

22 Jan '13

Christian Costa <titan.costa(a)gmail.com> wrote: > cpp_quote("DEFINE_GUID(CLSID_WICBmpDecoder, 0x6b462062,0x7cbf,0x400d,0x9f,0xdb,0x81,0x3d,0xd1,0x0f,0x27,0x78);") > +cpp_quote("DEFINE_GUID(CLSID_WICDibDecoder, 0x6b462062,0x7cbf,0x400d,0x9f,0xdb,0x81,0x3d,0xd1,0x0f,0x27,0x79);") > cpp_quote("DEFINE_GUID(CLSID_WICPngDecoder, 0x389ea17b,0x5078,0x4cde,0xb6,0xef,0x25,0xc1,0x51,0x75,0xc7,0x51);") > cpp_quote("DEFINE_GUID(CLSID_WICIcoDecoder, 0xc61bfcdf,0x2e0f,0x4aad,0xa8,0xd7,0xe0,0x6b,0xaf,0xeb,0xcd,0xfe);") > cpp_quote("DEFINE_GUID(CLSID_WICJpegDecoder, 0x9456a480,0xe88b,0x43ea,0x9e,0x73,0x0b,0x2d,0x9b,0x71,0xb1,0xca);") > @@ -1002,6 +1003,7 @@ cpp_quote("DEFINE_GUID(CLSID_WICWmpEncoder, 0xac4ce3cb,0xe1c1,0x44cd,0x82,0x15,0 > cpp_quote("DEFINE_GUID(CLSID_WICDefaultFormatConverter, 0x1a3f11dc,0xb514,0x4b17,0x8c,0x5f,0x21,0x54,0x51,0x38,0x52,0xf1);") > > cpp_quote("DEFINE_GUID(GUID_ContainerFormatBmp, 0x0af1d87e,0xfcfe,0x4188,0xbd,0xeb,0xa7,0x90,0x64,0x71,0xcb,0xe3);") > +cpp_quote("DEFINE_GUID(GUID_ContainerFormatDib, 0x0af1d87e,0xfcfe,0x4188,0xbd,0xeb,0xa7,0x90,0x64,0x71,0xcb,0xe4);") Is this mocked up names? I couldn't find WIC DIB decoder definitions in the PSDK headers. -- Dmitry.

3 10

Re: macdrv: implement getting and setting the screen saver state, version 4
by Ken Thomases 22 Jan '13

22 Jan '13

Hi, On Jan 21, 2013, at 6:21 PM, C.W. Betts wrote: > This version falls through in SPI_SETSCREENSAVEACTIVE. Sadly, you used C++ style for the fall-through comment. :-/ Also, you have some trailing whitespace and the patch no longer applies cleanly after today's commits of mine. It should be easy to fix that though. There aren't any serious conflicts. -Ken

1 0

Adding DECLSPEC_ALIGN(4) to structs for atomic DWORD access
by Joerg-Cyril.Hoehle＠t-systems.com 22 Jan '13

22 Jan '13

Hi, there are some places in Wine where I believe atomic access to 32bit entities is expected by the programmer, yet I see little or no measures to ensure this. DWORD-Alignment is essential when several threads can access the same DWORD variable outside of a mutex (or within the implementation of the mutex). DECLSPEC_ALIGN(4) is the declaration that could be used to enforce it within a struct, assuming the struct itself is somehow aligned. E.g. shouldn't CRITICAL_SECTION objects be aligned when used within other (non-public) structs? (Presumably public MS structs cannot be augmented with alignment declarations) DECLSPEC_ALIGN is hardly used in Wine http://source.winehq.org/ident?i=RTL_CRITICAL_SECTION Other examples where I'm considering adding DWORD-alignment to read DWORD-sized objects atomically: - MCI position values (for MCI_STATUS_POSITION) - MIDI end_thread control variable - mmdevapi GetCurrentPadding (as part of lock-less patch) Would such patches be welcome? Are they superfluous, assuming that DWORD-alignment is granted and using DECLSPEC_ALIGN() only for larger alignments, e.g. 8 or 16 (that seems to be the current use)? One benefit I see is to highlight those variables shared among several threads. Regards, Jörg Höhle

3 2

Re: x11drv: Return true when handling SPI_SETSCREENSAVEACTIVE
by Alexandre Julliard 22 Jan '13

22 Jan '13

"C.W. Betts" <computers57(a)hotmail.com> writes: > I noticed in my research that the X11 driver doesn't return true in > SystemParametersInfo when handling SPI_SETSCREENSAVEACTIVE. This patch > fixes this. That's on purpose, it also needs to update the registry entry. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: macdrv: implement getting and setting the screen saver state, version 3
by Ken Thomases 21 Jan '13

21 Jan '13

On Jan 21, 2013, at 11:50 AM, C.W. Betts wrote: > This version gets rid of redundant comments. According to Alexandre's comment on your X11 driver patch, you should be returning FALSE from the "SET" case so that user32 will update the registry. Otherwise, looking good. -Ken

1 0

Re: [PATCH] winebuild: Use Clang to assemble if found.
by Alexandre Julliard 21 Jan '13

21 Jan '13

Charles Davis <cdavis5x(a)gmail.com> writes: > @@ -319,26 +341,27 @@ char *find_tool( const char *name, const char * const *names ) > names = alt_names; > } > > - while (*names) > + /* If we have a target triple, we really need to try the list of names > + * twice: once with the triple, and once without. > + */ This doesn't make sense, if we have a target it means we are cross-compiling, and we need to use the correct tool. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: macdrv: implement getting and setting the screen saver state, version 2
by Ken Thomases 21 Jan '13

21 Jan '13

Hi, On Jan 20, 2013, at 2:00 PM, C.W. Betts wrote: > This version implements changes and advice from Ken Thomases, including using kIOPMAssertionTypePreventUserIdleDisplaySleep on Lion and later. Also, some comments were added. > + //Get pre-Lion no display sleep counts C++-style comments ("//") are not allowed in Wine C code. They aren't portable. > + CFNumberRef count = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypeNoDisplaySleep); > + CFNumberRef count2 = NULL; > + long longCount = 0; > + long longCount2 = 0; > + CFNumberGetValue(count, kCFNumberLongType, &longCount); > + //If available, get Lion and later no display sleep counts > + count2 = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypePreventUserIdleDisplaySleep); > + if (count2) > + CFNumberGetValue(count2, kCFNumberLongType, &longCount2); The issue discussed for the previous patch is still present. For example, the following code would be internally consistent and also safe: CFNumberRef count = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypeNoDisplaySleep); CFNumberRef count2 = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypePreventUserIdleDisplaySleep); long longCount = 0; long longCount2 = 0; if (count) CFNumberGetValue(count, kCFNumberLongType, &longCount); if (count2) CFNumberGetValue(count2, kCFNumberLongType, &longCount2); (Note that this reorganization also eliminates a dead store. You were initializing count2 and then unconditionally assigning it, making the initialization redundant. Such unnecessary initializations also defeat potentially valuable compiler warnings.) > + if (longCount || longCount2 ) There's an extraneous space before the closing parenthesis. > + //Release power assertion > + IOReturn success = IOPMAssertionRelease(powerAssertion); The comment is useless. It tells us nothing that the code doesn't. Please don't do that. In fact, most of the comments you added are like this. > + //Are we running Lion or later? > + if (kCFCoreFoundationVersionNumber >= kCFCoreFoundationVersionNumber10_7) > + //If so, use Lion's name > + assertName = kIOPMAssertionTypePreventUserIdleDisplaySleep; > + else > + //If not, use old name > + assertName = kIOPMAssertionTypeNoDisplaySleep; I'm not sure it's correct that these are two different names for roughly the same thing. I think the two assertion types do slightly different things. "NoDisplaySleep" seeks to prevent display sleep for any (non-forced) reason. "PreventUserIdleDisplaySleep" only seeks to prevent display sleep that is due to user idleness. As I suggested previously, I do want us to use PreventUserIdleDisplaySleep when it's available, so that's good. (Thank you for making that change.) What I'm saying now is mostly just that the comments are misleading. I suggest just removing the comments within the "if". The code is understandable without them. Also, this bit of code uses tabs to indent when none of the rest does. Please be consistent with the surrounding code. Thanks, Ken

2 2

Re: configure.ac: check for a good enough version of libv4l1.h (try 2)
by Alexandre Julliard 21 Jan '13

21 Jan '13

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > @@ -676,6 +676,22 @@ AC_CHECK_HEADERS([linux/videodev.h linux/videodev2.h libv4l1.h],,, > #include <asm/types.h> > #endif]) > > +dnl **** Check for libv4l1.h **** > +if test "x$with_v4l" != "xno" > +then > + ac_save_CPPFLAGS="$CPPFLAGS" > + if test "$PKG_CONFIG" != "false" > + then > + ac_libv4l1_libs="`$PKG_CONFIG --libs libv4l1 2>/dev/null`" > + ac_libv4l1_cflags="`$PKG_CONFIG --cflags libv4l1 2>/dev/null`" > + CPPFLAGS="$CPPFLAGS $ac_libv4l1_cflags" > + AC_CHECK_TYPES([struct video_picture],,,[#include <libv4l1.h>]) > + fi > + CPPFLAGS="$ac_save_CPPFLAGS" > + WINE_NOTICE_WITH(libv4l1,[test "x$ac_cv_type_struct_video_picture" = "x"], > + [libv4l1 ${notice_platform}development files not found or too old.]) > +fi It doesn't make sense to use pkg-config for the test since we don't use it when including the header. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] netstat: Implement the TCP stats output
by Frédéric Delanoy 21 Jan '13

21 Jan '13

On Sun, Jan 20, 2013 at 8:09 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > + IDS_TCP_SEGM_RECV, "Segments Recieved" Typo here: should be "Received" (same issue on the 2nd patch) Frédéric

1 0

Re: macdrv: implement getting and setting the screen saver state.
by Ken Thomases 21 Jan '13

21 Jan '13

Hi, On Jan 19, 2013, at 4:08 PM, C.W. Betts wrote: > This implements getting and setting the screen saver state on the Mac Wine driver. Thanks for your contribution to the Mac driver. There are some issues with the patch: > + CFDictionaryRef assertsionStats = NULL; That variable name has a misspelling. It should probably be "assertionStates". > + CFNumberRef count = CFDictionaryGetValue(assertsionStats, kIOPMAssertionTypeNoDisplaySleep); > + CFNumberRef count2 = NULL; > + long longCount = 0; > + long longCount2 = 0; > + CFNumberGetValue(count, kCFNumberLongType, &longCount); > + count2 = CFDictionaryGetValue(assertsionStats, kIOPMAssertionTypePreventUserIdleDisplaySleep); > + if(count2) > + CFNumberGetValue(count2, kCFNumberLongType, &longCount2); Why are the two assertion types handled differently here? You get the value in the initializer in one case but not in the other. You check if the CFNumber pointer is NULL in one case but not the other. They should probably both be handled the same way. Some better variable names would be nice, too. > + if (longCount + longCount2 > 0) If think it's better to use "if (longCount || longCount2)". We're really interested in whether or not either is non-zero. If, somehow, the sum overflows or one is a large negative value, we still want to consider that as the screen saver being disabled. > + { > + *(BOOL *)ptr_param = FALSE; > + } It's a minor style preference, but I prefer that single-statement bodies for "if"s not have braces. > + if(success != kIOReturnSuccess) Another style nitpick: please put a space between "if" and the condition. That applies to the "if(count2)" above, too. > + /* > + Introduced in 10.6, not available in 10.5 > + IOReturn success = IOPMAssertionCreateWithName( > + kIOPMAssertionTypeNoDisplaySleep, kIOPMAssertionLevelOn, > + CFSTR("Wine Process requesting no screen saver"), &powerAssertion); > + */ To Alexandre's chagrin, the Mac driver requires 10.6. So, you might as well use the newer function. > + IOReturn success = IOPMAssertionCreate(kIOPMAssertionTypeNoDisplaySleep, > + kIOPMAssertionLevelOn, &powerAssertion); We should use kIOPMAssertionTypePreventUserIdleDisplaySleep instead on OS versions where it's available. We could either check a framework version variable (e.g. kCFCoreFoundationVersionNumber) or check if the dictionary returned from IOPMCopyAssertionsStatus() contains kIOPMAssertionTypePreventUserIdleDisplaySleep as a key. > + break; This seems extraneous. Cheers, Ken

2 2

wiki
by Rico Schüller 20 Jan '13

20 Jan '13

Hi, is anyone able to get the wiki up again? Somehow the wiki (http://wiki.winehq.org/) is not reachable from here. Cheers Rico

4 3

Re: [3/6] windowscodecs: Implement tiff encoder options (TiffCompressionMethod and CompressionQuality)
by Dmitry Timoshkov 20 Jan '13

20 Jan '13

Ludger Sprenker <ludger(a)sprenker.net> wrote: > + read_hr = IPropertyBag2_Read(pIEncoderOptions, 2, pb, NULL, v, hr); > + if (SUCCEEDED(hr)) Looks like a typo. -- Dmitry.

2 1

Re: [3/5] comctl32/listview: always use large icon size when calculating icon spacing
by Marvin 20 Jan '13

20 Jan '13

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 http://testbot.winehq.org/JobDetails.pl?Key=24024 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

2 1

Re: [5/5] comctl32/listview: fix LVM_SETICONSPACING on 64bit machines
by Marvin 20 Jan '13

20 Jan '13

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 http://testbot.winehq.org/JobDetails.pl?Key=24026 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [4/5] comctl32/listview: do not touch icon spacing if set explicitly
by Marvin 20 Jan '13

20 Jan '13

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 http://testbot.winehq.org/JobDetails.pl?Key=24025 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

User driver function conventions
by C.W. Betts 19 Jan '13

19 Jan '13

I'm wondering what the user driver functions GetScreenSaveActive and SetScreenSaveActive are supposed to do. I have an implementation against CodeWeaver's changes to Wine and I just want to make sure that I'm making the functions properly. First is GetScreenStateActive. Does it check for if the screen saver is disabled for the whole system or just the app. And SetScreenStateActive. Is it supposed to set the activity for the whole system (I.E. if two apps call SetScreenStateActive to yes, then one to no, does the screen saver run) or is it per-app?

2 3

Re: [1/6] windowscodecs: Implementation of IPropertyBag2
by Vincent Povirk 19 Jan '13

19 Jan '13

You'll probably have to split this into smaller patches. + return E_FAIL; /* FIXME: Function is not atomar on error, but MSDN does not say anything about it */ I don't understand. Are you saying native leaks memory on error, and if so how do you know this? + FIXME("Application tried to set the unknown option %s. " + "This may be an application error but is probably caused by an incomplete implementation in wine\n", + debugstr_w(pPropBag[i].pstrName)); I don't think the extra explanation of why this is a FIXME adds anything. + if (This->properties[idx].vt != V_VT(pvarValue+i)) + return E_FAIL; Are you sure this shouldn't be converted? + while (TRUE) + { + CoTaskMemFree( pPropBag[--i].pstrName ); + if(i == 0) + break; + } This could be written more simply as a do/while loop. +extern HRESULT CreateEncoderPropertyBag(PROPBAG2 *options, UINT count, IPropertyBag2 **property) DECLSPEC_HIDDEN; This adds code that's not really used. You might want to start out by changing the arguments of CreatePropertyBag2 and adding the IWICComponentFactory method. Then you can write tests first and remove todo's as you go. I don't think there's any reason to keep a constructor with the old set of arguments around.

1 0

winetestbot back online, for now
by Maarten Lankhorst 19 Jan '13

19 Jan '13

Hey, It looks like the vmware licensing issues are resolved, so all testbot vm's are online again. I hope the replacement testbot is coming along nicely, because winetestbot is still scheduled to go permanently offline in may. ~Maarten

1 0

Truncate MIDI SysEx messages after termination byte
by Joerg-Cyril.Hoehle＠t-systems.com 18 Jan '13

18 Jan '13

Hi, Johannes Kroll wrote: >+ for(i = 0; i < lpMidiOutHdr->dwBufferLength; i++) >+ if((unsigned char)lpMidiOutHdr->lpData[i] == 0xF7 && i < lpMidiOutHdr->dwBufferLength-1) What about for(i = 0; i+1 < lpMidiOutHdr->dwBufferLength, i++) without the redundant second if(&&) half? I'm always happy when somebody with real MIDI HW speaks up, because I'm not convinced that the Wine MIDI code does TRT about SysEx -- based on my readings, not experience, as I own no MIDI device... In particular, do you have any experience with multi-part SysEx messages (e.g. large data, such as uploads)? Still, I'm not persuaded that your patch is at the right place. I believe the midi* functions should be tiny wrappers around MODM_* messages, same for the wave* functions. Every time I see somebody attempt to violate this 1:1 mapping, I'm suspicious. Perhaps the logic that you're adding belongs to the individual wine*.drv/midi.c? Do you get to see this warning from winealsa.drv where it specifically checks for a terminating F7 (but not intermediate F7)? http://source.winehq.org/source/dlls/winealsa.drv/midi.c#L969 964 /* FIXME: MS doc is not 100% clear. Will lpData only contain system exclusive 965 * data, or can it also contain raw MIDI data, to be split up and sent to 966 * modShortData() ? 967 * If the latest is true, then the following WARNing will fire up 968 */ 969 if (lpData[0] != 0xF0 || lpData[lpMidiHdr->dwBufferLength - 1] != 0xF7) { 970 WARN("Alleged system exclusive buffer is not correct\n\tPlease report with MIDI file\n"); 971 lpNewData = HeapAlloc(GetProcessHeap(), 0, lpMidiHdr->dwBufferLength + 2); 972 } Therefore, I'd be happy if you could invest some more time and check, based on your real MIDI HW, and perhaps native w* machines, whether MODM_LONGDATA and midiOutLongMsg are equivalent or whether midiOut* does some additional processing. Regards, Jörg Höhle

3 6

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