October 2013 - Wine-Devel - list.winehq.org

Re: [4/5] ws2_32: Return an error from accept if the address buffer is too small.
by Marvin Oct. 2, 2013

Oct. 2, 2013

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://newtestbot.winehq.org/JobDetails.pl?Key=2609 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (c8): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (520): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 74AA9799 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (78c): unexpectedly at the OOB mark: 0

1 0

Re: [3/5] ws2_32: Add some tests for getpeername.
by Marvin Oct. 2, 2013

Oct. 2, 2013

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://newtestbot.winehq.org/JobDetails.pl?Key=2608 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (c8): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (320): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 74AA9799 === w2008s64 (64 bit sock) === sock.c:509: Test failed: oob_server (808): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (808): unexpectedly at the OOB mark: 0

1 0

Re: [2/5] ws2_32: Always clear res on error in getaddrinfo/GetAddrInfoW.
by Marvin Oct. 2, 2013

Oct. 2, 2013

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://newtestbot.winehq.org/JobDetails.pl?Key=2607 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (108): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (7c4): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 74AA9799 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (470): unexpectedly at the OOB mark: 0

1 0

Re: [1/2] gdi32: Fix the B spacing value of empty glyph. (try 3)
by Marvin Oct. 2, 2013

Oct. 2, 2013

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://newtestbot.winehq.org/JobDetails.pl?Key=2605 Your paranoid android. === wvista (32 bit font) === The test timed out === w2008s64 (32 bit font) === Failure running script in VM: network read timed out

1 0

Re: [2/2] gdi32: Don't modify output glyph metrics unless the function succeeds. (resend)
by Alexandre Julliard Oct. 2, 2013

Oct. 2, 2013

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > --- > dlls/gdi32/freetype.c | 12 ++++++++---- > dlls/gdi32/tests/font.c | 5 +++++ > 2 files changed, 13 insertions(+), 4 deletions(-) It looks like something is not quite right, this is causing strange spacing, for instance in the About dialog. -- Alexandre Julliard julliard(a)winehq.org

1 0

I'm not sure why it was rejected
by Akira Nakagawa Oct. 2, 2013

Oct. 2, 2013

I cannnot make sure my patch 99266 <cid:part1.07050802.08000504(a)gmail.com> was rejected. From: Akira Nakagawa <matyapiro31(a)gmail.com> Subject: add ualapi directory(try 15) Message-Id: <52496BA8.1020908(a)gmail.com> Date: Mon, 30 Sep 2013 21:16:40 +0900 I think it has no problem without what Bruno said. So this is the last one. >From e7b788f927621f5d8544bbf73f1e155e05098387 Mon Sep 17 00:00:00 2001 Message-Id: <e7b788f927621f5d8544bbf73f1e155e05098387.1380543383.git.matyapiro31(a)gmail…> From: Akira Nakagawa <matyapiro31(a)gmail.com> Date: Mon, 30 Sep 2013 21:13:52 +0900 Subject: [PATCH] add ual directory (try 15) --- dlls/ualapi/Makefile.in | 6 ++++ dlls/ualapi/main.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++ dlls/ualapi/ualapi.spec | 4 +++ include/ual.h | 47 +++++++++++++++++++++++++++ 4 files changed, 143 insertions(+) diff --git a/dlls/ualapi/Makefile.in b/dlls/ualapi/Makefile.in new file mode 100644 index 0000000..59e56fe --- /dev/null +++ b/dlls/ualapi/Makefile.in @@ -0,0 +1,6 @@ +MODULE = ualapi.dll +IMPORTLIB = ualapi + +C_SRCS = main.c + +(a)MAKE_DLL_RULES@ diff --git a/dlls/ualapi/main.c b/dlls/ualapi/main.c new file mode 100644 index 0000000..7b3ff7b --- /dev/null +++ b/dlls/ualapi/main.c @@ -0,0 +1,86 @@ +/* + * main.c + * This file is part of wine + * + * Copyright (C) 2013 - Akira Nakagawa + * + * wine is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * wine is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with wine. If not, see <http://www.gnu.org/licenses/>. + */ +#include <stdio.h> +#include "windef.h" +#include "winbase.h" +#include "winuser.h" +#include "wine/debug.h" +#include "ual.h" + +WINE_DEFAULT_DEBUG_CHANNEL(ualapi); + +/***************************************************** + * DllMain + */ +BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) +{ + TRACE("(%p, %d, %p)\n", hinstDLL, fdwReason, lpvReserved); + switch (fdwReason) + { + case DLL_WINE_PREATTACH: + return FALSE; /* prefer native version */ + case DLL_PROCESS_ATTACH: + DisableThreadLibraryCalls(hinstDLL); + break; + } + return TRUE; +} + +/* + * Return S_OK if succeed,or return error code + * It records Data of the user. + */ +HRESULT +WINAPI +UalStart( + PUAL_DATA_BLOB Data){ + FIXME("This function is not supported.\n"); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return S_OK; +} + +HRESULT +WINAPI +UalStop( + PUAL_DATA_BLOB Data){ + FIXME("This function is not supported.\n"); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return S_OK; +} + +HRESULT +WINAPI +UalInstrument( + PUAL_DATA_BLOB Data){ + FIXME("This function is not supported.\n"); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return S_OK; +} + +HRESULT +WINAPI +UalRegisterProduct( + const WCHAR* wszProductName, + const WCHAR* wszRoleName, + const WCHAR* wszGuid){ + FIXME("This function is not supported.\n"); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return S_OK; +} diff --git a/dlls/ualapi/ualapi.spec b/dlls/ualapi/ualapi.spec new file mode 100644 index 0000000..b7682fb --- /dev/null +++ b/dlls/ualapi/ualapi.spec @@ -0,0 +1,4 @@ +@ stdcall UalStart(ptr) +@ stdcall UalStop(ptr) +@ stdcall UalInstrument(ptr) +@ stdcall UalRegisterProduct(wstr wstr wstr) diff --git a/include/ual.h b/include/ual.h new file mode 100644 index 0000000..14f1c74 --- /dev/null +++ b/include/ual.h @@ -0,0 +1,47 @@ +/* + * ual.h: User Access Logging + * This file is part of wine + * + * Copyright (C) 2013 - Akira Nakagawa + * + * wine is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * wine is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with wine. If not, see <http://www.gnu.org/licenses/>. + */ + + +#ifndef _UAL_H_INCLUDED +#define _UAL_H_INCLUDED + +#include <winsock2.h> + +typedef struct tagUAL_DATA_BLOB +{ + DWORD Size; + GUID RoleGuid; + GUID TenantId; + SOCKADDR_STORAGE Address; + WCHAR UserName[MAX_PATH]; +} UAL_DATA_BLOB, *PUAL_DATA_BLOB; + +HRESULT WINAPI UalStart(PUAL_DATA_BLOB Data); + +HRESULT WINAPI UalStop(PUAL_DATA_BLOB Data); + +HRESULT WINAPI UalInstrument(PUAL_DATA_BLOB Data); + +HRESULT WINAPI UalRegisterProduct( + const WCHAR* wszProductName, + const WCHAR* wszRoleName, + const WCHAR* wszGuid); +#endif + -- 1.8.1.2

4 3

Re: [PATCH 4/7] msvcr90/tests: Use the W form of CreateEvent().
by Marvin Oct. 2, 2013

Oct. 2, 2013

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://newtestbot.winehq.org/JobDetails.pl?Key=2457 Your paranoid android. === wxppro (32 bit msvcr90) === No test summary line found

1 0

Re: [PATCH 2/7] qedit/tests: Use the W version of FindResource().
by Marvin Oct. 2, 2013

Oct. 2, 2013

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://newtestbot.winehq.org/JobDetails.pl?Key=2455 Your paranoid android. === w2008s64 (32 bit mediadet) === mediadet.c:149: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 0040184A === w2008s64 (64 bit mediadet) === mediadet.c:149: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 00000000004017A3

1 0

Re: Re: kernel32/tests: Fix the test_waittxempty() timeout.
by Marvin Oct. 2, 2013

Oct. 2, 2013

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://newtestbot.winehq.org/JobDetails.pl?Key=2434 Your paranoid android. === wxppro (32 bit comm) === comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... No test summary line found Failure running script in VM: network read timed out === w2008s64 (32 bit comm) === comm.c:1670: test_AbortWaitCts timeout 500 handle 000000C4 comm.c:1637: Changing CommMask on the fly for handle 000000C4 after timeout 500 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 No test summary line found Failure running script in VM: network read timed out === w7pro64 (32 bit comm) === comm.c:1670: test_AbortWaitCts timeout 500 handle 00000130 comm.c:1637: Changing CommMask on the fly for handle 00000130 after timeout 500 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1094: Test failed: WriteFile failed with a timeout comm.c:1096: Test failed: GetOverlappedResult reported error 996 comm.c:1097: Test failed: expected 64000, written 0 Timeout === w2008s64 (64 bit comm) === comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 Timeout === w7pro64 (64 bit comm) === comm.c:887: WaitCommEvent for EV_TXEMPTY took 0 ms (timeout 1000) comm.c:1670: test_AbortWaitCts timeout 500 handle 00000000000000CC comm.c:1637: Changing CommMask on the fly for handle 00000000000000CC after timeout 500 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 Timeout

1 0

Re: Assorted spelling fixes.
by Marvin Oct. 2, 2013

Oct. 2, 2013

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

1 0

Re: Assorted spelling fixes.
by Marvin Oct. 2, 2013

Oct. 2, 2013

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

1 0

Re: Assorted spelling fixes.
by Marvin Oct. 2, 2013

Oct. 2, 2013

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

1 0

Re: Assorted spelling fixes.
by Marvin Oct. 2, 2013

Oct. 2, 2013

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

1 0

Re: Assorted spelling fixes.
by Marvin Oct. 2, 2013

Oct. 2, 2013

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

1 0

Re: [5/5] gdi32: Don't modify output glyph metrics unless the function succeeds. (resend)
by Marvin Oct. 2, 2013

Oct. 2, 2013

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://newtestbot.winehq.org/JobDetails.pl?Key=2426 Your paranoid android. === wvista (32 bit font) === The test timed out === w2008s64 (32 bit font) === Failure running script in VM: network read timed out === w2008s64 (64 bit font) === Failure running script in VM: network read timed out

1 0

Re: kernel32: Add tests for job objects (try 3)
by Nikolay Sivov Oct. 2, 2013

Oct. 2, 2013

On 10/2/2013 12:58, Andrew Cook wrote: > + if(!pCreateJobObjectW) { > + win_skip("No job object support\n"); > + return; > + } Once you checked that I suppose you don't need to check for pIsProcessInJob being null, or it still could happen? > + if (option && strcmp(option, "wait") == 0) { > + /* for job object tests */ > + Sleep(3000); > + return; > + } Is it really necessary?

1 0

Re: winemac: Reapply display modes when switching back to app after "escaping" with Command-Tab.
by Ken Thomases Oct. 2, 2013

Oct. 2, 2013

On Oct 1, 2013, at 11:24 PM, Ken Thomases wrote: > May fix bug <http://bugs.winehq.org/show_bug.cgi?id=34475>. Should fix bug <http://bugs.winehq.org/show_bug.cgi?id=34209>, too. -Ken

1 0

Re: mshtml: Added support for 'document' and 'window' script for attribute values.
by Marvin Oct. 1, 2013

Oct. 1, 2013

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

1 0

Re: imm32: ImmGetCandidateWindow should not return unset data
by Alexandre Julliard Oct. 1, 2013

Oct. 1, 2013

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -663,6 +663,8 @@ HIMC WINAPI ImmCreateContext(void) > gl->dwSize = sizeof(GUIDELINE); > ImmUnlockIMCC(new_context->IMC.hGuideLine); > > + memset(new_context->IMC.cfCandForm, -1, sizeof(new_context->IMC.cfCandForm)); > + That's ugly. If you are using the index for validity checking then you should put some appropriate value in there, there's no reason to put garbage in the whole structure. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: mscoree: Implement CreateInterface
by Vincent Povirk Oct. 1, 2013

Oct. 1, 2013

Any reason not to share code with CLRCreateInstance?

1 0

Re: [4/5] gdi32: Fix the B spacing value of empty glyph. (try 2)
by Alexandre Julliard Oct. 1, 2013

Oct. 1, 2013

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Try 2: > - Get rid of redundant trace message in the last patch. > > --- > dlls/gdi32/freetype.c | 2 +- > dlls/gdi32/tests/font.c | 8 +++++++- > 2 files changed, 8 insertions(+), 2 deletions(-) This is causing failures here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok font.c:1133: Test succeeded inside todo block: LTR -1 advanced: abcA's sign should be unchanged font.c:1141: Test succeeded inside todo block: LTR -1 advanced: abcfA's sign should be unchanged font.c:1133: Test succeeded inside todo block: RTL 1 advanced: abcA's sign should be unchanged font.c:1141: Test succeeded inside todo block: RTL 1 advanced: abcfA's sign should be unchanged -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32/tests: Fix the test_waittxempty() timeout.
by Francois Gouget Oct. 1, 2013

Oct. 1, 2013

On Tue, 1 Oct 2013, Francois Gouget wrote: [...] > The timeout was too short and would only work for UARTs that have a > FIFO and where the trigger level was set just right. With this patch > we calculate how much time sending the test data will actually take > and tack on a small margin to take into account scheduling delays. I should note that this does not fix the test failuers on the QEmu VMs, specifically the WineTestBot ones. If QEmu 1.1.2 is anything like QEmu 1.6.0, then the serial port seems to operate at a fixed speed of about 1800000bps. This is so out of line with the 150bps that we request that it causes the test to fail. [...] > * Windows reports that all bytes have been sent not when the UART's > buffer is empty but when they all made it to the UART's buffer. Note > that this can be tested (see next mail). And here is this test. IT IS NOT MEANT TO BE COMMITTED. (but seeing the WineTestBot results would still be interesting) On my one Windows PC with a real UART (Intel(R) 82801DBM LPC Interface Controller - 24CC, i.e. ICH4 which emulates a 16550A UART) I get the following results which clearly illustrate the impact of the FIFO/trigger level. comm.c:1100: WaitCommEvent(1 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(2 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(3 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(4 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(5 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(6 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(7 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(8 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(9 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(10 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(11 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(12 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(13 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(14 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(15 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(16 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(17 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(18 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(19 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(20 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(21 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(22 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(23 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(24 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(25 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(26 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(27 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(28 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(29 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(30 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(31 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(32 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(33 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(34 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(35 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(36 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(37 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(38 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(39 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(40 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(41 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(42 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(43 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(44 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(45 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(46 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(47 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(48 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(49 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(50 bytes) for EV_TXEMPTY took 2734 ms -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

1 0

Re: [3/3] ws2_32: Always return the source address from WSAAccept.
by Marvin Oct. 1, 2013

Oct. 1, 2013

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://newtestbot.winehq.org/JobDetails.pl?Key=2421 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (b0): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (5a0): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (624): unexpectedly at the OOB mark: 0

1 0

Re: [2/3] ws2_32: Return an error from accept if the address buffer is too small.
by Marvin Oct. 1, 2013

Oct. 1, 2013

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://newtestbot.winehq.org/JobDetails.pl?Key=2420 Your paranoid android. === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (5a0): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 757A9799 === w7pro64 (32 bit sock) === sock.c:528: Test failed: oob_server (778): not at the OOB mark: 1 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (7f8): unexpectedly at the OOB mark: 0

1 0

Re: [PATCH] dsound: fixup IDirectSoundCaptureBuffer_QueryInterface
by Andrew Eikum Oct. 1, 2013

Oct. 1, 2013

Seems reasonable, but could you put together some tests to show this? Andrew On Sat, Sep 28, 2013 at 10:41:15AM +0200, Maarten Lankhorst wrote: > diff --git a/dlls/dsound/capture.c b/dlls/dsound/capture.c > index 40f1702..0fe300c 100644 > --- a/dlls/dsound/capture.c > +++ b/dlls/dsound/capture.c > @@ -51,7 +51,7 @@ typedef struct IDirectSoundCaptureBufferImpl > IDirectSoundCaptureBuffer8 IDirectSoundCaptureBuffer8_iface; > IDirectSoundNotify IDirectSoundNotify_iface; > LONG numIfaces; /* "in use interfaces" refcount */ > - LONG ref, refn; > + LONG ref, refn, has_dsc8; > /* IDirectSoundCaptureBuffer fields */ > DirectSoundCaptureDevice *device; > DSCBUFFERDESC *pdscbd; > @@ -241,8 +241,9 @@ static HRESULT WINAPI IDirectSoundCaptureBufferImpl_QueryInterface(IDirectSoundC > > *ppobj = NULL; > > - if ( IsEqualGUID( &IID_IDirectSoundCaptureBuffer, riid ) || > - IsEqualGUID( &IID_IDirectSoundCaptureBuffer8, riid ) ) { > + if ( IsEqualIID( &IID_IUnknown, riid ) || > + IsEqualIID( &IID_IDirectSoundCaptureBuffer, riid ) || > + (This->has_dsc8 && IsEqualIID( &IID_IDirectSoundCaptureBuffer8, riid )) ) { > IDirectSoundCaptureBuffer8_AddRef(iface); > *ppobj = iface; > return S_OK; > @@ -1239,6 +1240,8 @@ static HRESULT WINAPI IDirectSoundCaptureImpl_CreateCaptureBuffer(IDirectSoundCa > > if (hr != DS_OK) > WARN("IDirectSoundCaptureBufferImpl_Create failed\n"); > + else > + This->device->capture_buffer->has_dsc8 = This->has_dsc8; > > return hr; > } > > >

1 0

Re: [3/3] ws2_32: Always return the source address from WSAAccept.
by Bruno Jesus Oct. 1, 2013

Oct. 1, 2013

On Tue, Oct 1, 2013 at 6:37 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > --- > dlls/ws2_32/socket.c | 9 +-------- > dlls/ws2_32/tests/sock.c | 6 +++--- > 2 files changed, 4 insertions(+), 11 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index c34de4b..6855298 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -6546,12 +6546,8 @@ SOCKET WINAPI WSAAccept( SOCKET s, struct WS_sockaddr *addr, LPINT addrlen, > TRACE("Socket %04lx, sockaddr %p, addrlen %p, fnCondition %p, dwCallbackData %ld\n", > s, addr, addrlen, lpfnCondition, dwCallbackData); > > - > - size = sizeof(src_addr); > - cs = WS_accept(s, &src_addr, &size); > - > + cs = WS_accept(s, addr, addrlen); The parameter addr may be NULL in WSAAccept, I can't check the source code right now but what will WS_accept do in this case? Best wishes, Bruno

2 1

Re: [1/3] ws2_32: Always clear res on error in getaddrinfo/GetAddrInfoW.
by Marvin Oct. 1, 2013

Oct. 1, 2013

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://newtestbot.winehq.org/JobDetails.pl?Key=2419 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (2a4): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (774): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (884): unexpectedly at the OOB mark: 0 === w7pro64 (64 bit sock) === sock.c:509: Test failed: oob_server (af8): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (af8): unexpectedly at the OOB mark: 0 sock.c:288: Test failed: do_synchronous_recv (af8): error 10054: sock.c:534: Test failed: oob_server (af8): not at the OOB mark: 1

1 0

Re: [PATCH 2/5] wined3d: Move location management into the resource.
by Henri Verbeet Oct. 1, 2013

Oct. 1, 2013

Please split this.

1 0

Re: [PATCH 2/5] wined3d: Move location management into the resource.
by Stefan Dösinger Oct. 1, 2013

Oct. 1, 2013

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, To illustrate the goal of these patches I've attached an archive of all surface cleanup patches to this mail. The goal is to merge GL buffer object handling of buffers, surfaces and volumes. The main motivation for this is to handle WINED3D_MAP_DISCARD in one central place once dynamic resource handling is implemented in the command stream. The 4 patches in this series move location and buffer handling code from volume.c to resource.c. The next patches remove broken(overlay, partial rectangle handling) and half-broken(direct DIB maps, buffers) surface features. The next step is migrating surfaces to the resource location and loading code in resource.c. After that WINED3D_LOCATION_DISCARDED handling is improved and previously removed surface features re-added. Due to the removal of some surface features, performance regressions are possible. I think it's unlikely because the existing surface PBO code doesn't really do what it is supposed to do. Functional regressions should not happen. This patchset does not deal with d3d buffers. The central aspect of merging buffer handling is removing color and rhw conversion support. (or, alternatively, adding a separate location WINED3D_LOCATION_CONVBUFFER if we really want to keep the conversion code.) There are some problems later in the patchset that need fixing: Patch 24 is too big, patches 48 and 52 need to be moved. Non-GL ddraw rendering is broken at the moment (black screen). My patches don't make this any worse, but I'd like to fix it to make sure non-GL operation works as intended. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSSqzhAAoJEN0/YqbEcdMww1wP/jYYo0B/igDHd0QwOkwk8DIz ip4PKHxRgqaSYzswcBGZge+iBrJrvXSHh3cScG9KJ1a/VeaRlPyhDsFDzPce1VDK 0IX7iF/gKpZazPVy21lSIPQMlErSVy58fkIsd/PqKV/zyU8zNyZDkYU3n80itYrq Y3hPhaKbJIDN8QbhIOZu0egaiHObcwomBgZCfrUv+hr+xf+gMERYbqN9gj2JWFwJ dx4EzdeTFw1CZkFExbAJKt5zWA2KeFyitVU887WOSJpa3UbqemGpOID8vnYZlABZ mmqrS22XWjXlo2+0s0NufxeQJHvzpkcludLkg8a12r4FDs+ORYYnGbUeUy2o2Rud uV2quoeucA1TEAyF20JCrVNuCvDz5nvQq19rzR51k7FF/IsKGiI823ZGA54F4Dkn DZkyDcE0rnI2Re+br1aM31ZUt/maTxQMpk10BAAjwz1jbXQ4plZ9dtO9/DObdw8r nfPDJz+DsuBv19Th7MPjTxvXRjxVFTzlfuXNk/cOfAhgNdpEFSOGCAexGi6moSq1 6slQeLb8PqmO/83JQBuz4OI86dSoGSC6O9c/TtWXdW1PgCDyHgFvNb3jmQHsf7ya U1o2TkkNhLvfYz5Eo85Ep8oyVIF09CDrqQzUo10q33K5Y2E3RM8Xbxc+crGtjgxA TGwCwR8SRvAW+DfeP7bq =MEk/ -----END PGP SIGNATURE-----

1 0

Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
by Alexandre Julliard Oct. 1, 2013

Oct. 1, 2013

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/ntdll/file.c | 3 ++- > dlls/ntdll/tests/file.c | 5 +++-- > 2 files changed, 5 insertions(+), 3 deletions(-) I don't see the point. Do you actually have an app that depends on this? -- Alexandre Julliard julliard(a)winehq.org

2 6

Re: ntdll: Fix the version reported for 64-bit Windows XP.
by Alexandre Julliard Oct. 1, 2013

Oct. 1, 2013

Hans Leidekker <hans(a)codeweavers.com> writes: > @@ -129,11 +129,19 @@ static const RTL_OSVERSIONINFOEXW VersionData[NB_WINDOWS_VERSIONS] = > 4, 0, 0, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field with a value! */ > }, > /* WINXP */ > +#ifdef _WIN64 > + { > + sizeof(RTL_OSVERSIONINFOEXW), 5, 2, 0xECE, VER_PLATFORM_WIN32_NT, > + {'S','e','r','v','i','c','e',' ','P','a','c','k',' ','1',0}, > + 1, 0, VER_SUITE_SINGLEUSERTS, VER_NT_WORKSTATION, 0 > + }, > +#else > { > sizeof(RTL_OSVERSIONINFOEXW), 5, 1, 0xA28, VER_PLATFORM_WIN32_NT, > {'S','e','r','v','i','c','e',' ','P','a','c','k',' ','3',0}, > 3, 0, VER_SUITE_SINGLEUSERTS, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field with a value! */ > }, > +#endif This would mean that the 32-bit side sees a different version. I don't think that's correct. -- Alexandre Julliard julliard(a)winehq.org

1 0

mscoree: Implement CreateInterface
by Alistair Leslie-Hughes Oct. 1, 2013

Oct. 1, 2013

Hi, Changelog: mscoree: Implement CreateInterface Best Regards Alistair Leslie-Hughes

1 0

oledb32: Implement IDataSourceLocator get/put hWnd (try 4)
by Alistair Leslie-Hughes Oct. 1, 2013

Oct. 1, 2013

Hi, Corrected warnings. Changelog: Implement IDataSourceLocator get/put hWnd Best Regards Alistair Leslie-Hughes

1 0

Re: ws2_32: Implement WSASendMsg() (try 3)
by Marvin Oct. 1, 2013

Oct. 1, 2013

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://newtestbot.winehq.org/JobDetails.pl?Key=2414 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (210): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (5a0): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (6b0): unexpectedly at the OOB mark: 0

1 0

Increasing max_req_size and subsequent errors
by Hugh McMaster Sept. 30, 2013

Sept. 30, 2013

I need to increase the $max_req_size in tools/make_requests. A new request structure for GetConsoleScreenBufferInfoEx is 80 bytes and primarily made up of 16 unsigned long integers. This is fine, but raises the error: wineserver: request.c:755: open_master_socket: Assertion `sizeof(union generic_reply) == sizeof(struct request_max_size)' failed. It looks like this error is connected to struct request_max_size { int pad[16]; }; in include/wine/server_protocol.h. But other than increasing the size of the array, I'm not sure how to fix this appropriately. Any advice will be appreciated.

1 1

Re: [1/3] gdi32: Return fake BBox when requested empty glyph metrics. (try 3)
by Bruno Jesus Sept. 30, 2013

Sept. 30, 2013

On Fri, Sep 27, 2013 at 8:16 AM, Akihiro Sagawa <sagawa.aki(a)gmail.com> wrote: > > Fixes bug 18440, 20847. > > Try 3: > - Rebase to recent source. > - Separate ABC metrics change. > - Use conditional operator. > --- > dlls/gdi32/freetype.c | 4 ++-- > dlls/gdi32/tests/font.c | 24 ++++++++---------------- > 2 files changed, 10 insertions(+), 18 deletions(-) > + ok(gm.gmBlackBoxY == 1, "%2d:expected 1, got %u\n", fmt[i], gm.gmBlackBoxX); There seems to be a copy&paste issue in all lines related to gmBlackBoxY reporting the error as gmBlackBoxX. Regards, Bruno

1 0