November 2010 - Wine-devel - list.winehq.org

Re: [2/2] oledb32/tests: Add the XP+ behaviour and mark it as todo_wine
by Alex Villacís Lasso 10 Nov '10

10 Nov '10

El 10/11/10 15:02, André Hentschel escribió: > That's the behaviour of XP and up: > http://test.winehq.org/data/tests/oledb32:convert.html > > It's tricky to fix in Wine as you really don't know how much space you have in dst and assuming space breaks other tests. > > --- > dlls/oledb32/tests/convert.c | 11 ++++++++--- > 1 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/dlls/oledb32/tests/convert.c b/dlls/oledb32/tests/convert.c > index b9ef71f..cdae859 100644 > --- a/dlls/oledb32/tests/convert.c > +++ b/dlls/oledb32/tests/convert.c > @@ -1469,10 +1469,15 @@ static void test_converttostr(void) > memset(dst, 0xcc, sizeof(dst)); > dst_len = 0x1234; > hr = IDataConvert_DataConvert(convert, DBTYPE_I2, DBTYPE_STR, 0,&dst_len, src, dst, 0, 0,&dst_status, 0, 0, 0); > - ok(hr == DB_E_ERRORSOCCURRED, "got %08x\n", hr); > - ok(dst_status == DBSTATUS_E_DATAOVERFLOW, "got %08x\n", dst_status); > + todo_wine ok(hr == S_OK || > + broken(hr == DB_E_ERRORSOCCURRED /* Win9x, WinMe, NT4 and 2k */), > + "got %08x\n", hr); > + todo_wine ok(dst_status == DBSTATUS_S_OK || > + broken(dst_status == DBSTATUS_E_DATAOVERFLOW /* Win9x, WinMe, NT4 and 2k */), > + "got %08x\n", dst_status); > ok(dst_len == 4, "got %d\n", dst_len); > - ok(dst[0] == (char)0xcc, "got %02x\n", dst[0]); > + todo_wine ok(dst[0] == '4' || > + broken(dst[0] == (char)0xcc /* Win9x, WinMe, NT4 and 2k */), "got %02x\n", dst[0]); > > *(short *)src = 4321; > memset(dst, 0xcc, sizeof(dst)); > Weird. When I wrote that test, the WinXP-SP2 virtual machine did return DB_E_ERRORSOCCURRED/DBSTATUS_E_DATAOVERFLOW on this condition (available space equal to zero), and did not touch the output buffer in the process. In my opinion, Win9x behavior is actually OK, and the behavior you observe is the one that should be flagged as broken. It is hard to imagine the newer behavior (apparently "assume unbounded output buffer if reported space is zero") as more correct than the Win9x behavior. I think this should be treated the same as your 1/2 patch, which flags the behavior as Vista-only brokenness.

2 1

Re: msvcrt: Fixed (_w)fopen_s with test. (try 3)
by Marvin 10 Nov '10

10 Nov '10

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=6935 Your paranoid android. === W98SE (32 bit file) === file.c:999: Test failed: smaller size block: Wrong error data () file.c:1007: Test failed: smaller size block: Stdout file shouldn't contain data

2 1

Re: msvcrt: Implement strncat_s.
by Alexandre Julliard 10 Nov '10

10 Nov '10

Eryk Wieliczko <ewdevel(a)gmail.com> writes: > +int CDECL MSVCRT_strncat_s( char* dst, MSVCRT_size_t elem, const char* src, MSVCRT_size_t count ) > +{ > + MSVCRT_size_t i, j; > + if(!dst) return MSVCRT_EINVAL; > + if(elem == 0) return MSVCRT_EINVAL; > + if(!src) > + { > + dst[0] = '\0'; > + return MSVCRT_EINVAL; > + } Again, you should be using the parameter checking macros. -- Alexandre Julliard julliard(a)winehq.org

1 0

website: 404 Translated to Hebrew
by Yaron Shahrabani 10 Nov '10

10 Nov '10

Kind regards, Yaron Shahrabani <Hebrew translator>

2 1

Re: [PATCH 2/2 resend] urlmon: Added more IInternetProtocolEx tests.
by Marvin 10 Nov '10

10 Nov '10

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=6947 Your paranoid android. === W2K3R2SESP2 (32 bit protocol) === protocol.c:978: Test failed: hrResult = 800c0007, expected: 00000000 protocol.c:983: Test failed: dwError == ERROR_SUCCESS protocol.c:2776: Test failed: Read failed: 800c0007 (0 bytes) Timeout

1 0

Re: msvcrt: Fixed (_w)fopen_s with test. (try 2)
by Dmitry Timoshkov 10 Nov '10

10 Nov '10

Eryk Wieliczko <ewdevel(a)gmail.com> wrote: > + if (!p_fopen_s) > + { > + win_skip("Skipping fopen_s test\n"); > + return; > + } > + else > + { > + /* testing fopen_s */ > + ret = p_fopen_s(&file, name, "w"); > + ok(ret == 0, "fopen_s failed with %d\n", ret); > + ok(file != 0, "fopen_s failed to return value\n"); > + fwrite(name, sizeof(name), 1, file); > + > + ret = fclose(file); > + ok(ret != EOF, "File failed to close\n"); > + > + file = fopen(name, "r"); > + ok(file != 0, "fopen failed\n"); > + len = fread(buff, 1, sizeof(name), file); > + ok(len == sizeof(name), "File length supposed to be %d, not %d\n", sizeof(name), len); > + buff[sizeof(name)] = '\0'; > + ok(strcmp(name, buff) == 0, "File content mismatch! Got %s, expected %s\n", buff, name); > + > + ret = fclose(file); > + ok(ret != EOF, "File failed to close\n"); > + > + ok(_unlink(name) == 0, "Couldn't unlink file named '%s'\n", name); > + } > +} The whole 'else { }' block is not necessary, same for the test below. -- Dmitry.

1 0

GetSystemPaletteEntries() patch
by Eric Durbin 10 Nov '10

10 Nov '10

What was wrong with the patch sent in this post? http://article.gmane.org/gmane.comp.emulators.wine.devel/54403%29

1 0

Re: msvcrt: Fixed (_w)fopen_s with test. (try 2)
by Marvin 10 Nov '10

10 Nov '10

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=6922 Your paranoid android. === W98SE (32 bit file) === file.c:999: Test failed: smaller size block: Wrong error data () file.c:1007: Test failed: smaller size block: Stdout file shouldn't contain data

1 0

Re: krnl386.exe: Mention dosemu
by Charles Davis 09 Nov '10

09 Nov '10

On 11/9/10 4:20 PM, André Hentschel wrote: > @@ -643,7 +643,7 @@ static DWORD WINAPI MZ_DOSVM( LPVOID lpExtra ) > > if (GetLastError() == ERROR_NOT_SUPPORTED) > MESSAGE( "wine: Cannot start DOS application %s\n" > - " because vm86 mode is not supported on this platform.\n", > + " because vm86 mode is not supported on this platform, try dosemu.\n", You mean DOSBox, right? dosemu needs vm86(2) anyway, and AFAIK isn't even available on non-Linux. Chip

1 0

Re: msvcrt: Fixed (_w)fopen_s always fails.
by Austin English 09 Nov '10

09 Nov '10

On Tue, Nov 9, 2010 at 9:38 PM, Eryk Wieliczko <ewdevel(a)gmail.com> wrote: > (_w)fopen_s were always failing due to regression introduced in > commit 00f07046c0be658d97c47f69e1b4c518bc06b3a2 > --- > dlls/msvcrt/file.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/msvcrt/file.c b/dlls/msvcrt/file.c > index 329cdeb..91cd448 100644 > --- a/dlls/msvcrt/file.c > +++ b/dlls/msvcrt/file.c > @@ -2742,7 +2742,7 @@ int CDECL MSVCRT_fopen_s(MSVCRT_FILE** pFile, > const char *filename, const char *mode) > { > if (!MSVCRT_CHECK_PMT(pFile != NULL) || !MSVCRT_CHECK_PMT(filename != NULL) || > - MSVCRT_CHECK_PMT(mode != NULL)) { > + !MSVCRT_CHECK_PMT(mode != NULL)) { > *MSVCRT__errno() = MSVCRT_EINVAL; > return MSVCRT_EINVAL; > } > @@ -2769,7 +2769,7 @@ int CDECL MSVCRT__wfopen_s(MSVCRT_FILE** pFile, const MSVCRT_wchar_t *filename, > const MSVCRT_wchar_t *mode) > { > if (!MSVCRT_CHECK_PMT(pFile != NULL) || !MSVCRT_CHECK_PMT(filename != NULL) || > - MSVCRT_CHECK_PMT(mode != NULL)) { > + !MSVCRT_CHECK_PMT(mode != NULL)) { > *MSVCRT__errno() = MSVCRT_EINVAL; > return MSVCRT_EINVAL; > } > -- > 1.7.0.4 Sounds like a good reason to add a unit test to prevent it from happening again, then. -- -Austin

1 0