May 2012 - Wine-Devel - list.winehq.org

Re: [1/3] user32/tests: Comment-out PostQuitMessage (causes tests skip)

by Alexey Slepov

Guys, so how about this? diff --git a/dlls/user32/tests/dialog.c b/dlls/user32/tests/dialog.c index 6bd34b3..4301c8d 100644 --- a/dlls/user32/tests/dialog.c +++ b/dlls/user32/tests/dialog.c @@ -1027,9 +1027,6 @@ static INT_PTR CALLBACK DestroyOnCloseDlgWinProc (HWND hDlg, UINT uiMsg, case WM_CLOSE: DestroyWindow(hDlg); return TRUE; - case WM_DESTROY: - PostQuitMessage(0); - return TRUE; } return FALSE; } 29.05.2012, 01:16, "Alexey Slepov" <sir-lexa(a)yandex.ru>: > I figured out now. > As described in wine sources, PostQuitMessage() sets a flag in the thread's message queue that signals it to generate > a WM_QUIT message when there are no other pending sent or posted messages in the queue. > The tests with skipped testcases are those which use WM_TIMER messages - test_timer_message() and my test. > In DIALOG_DoDialogBox() there is clearly defined that on receiving WM_QUIT message the window is destroyed. So timer messages just do not reach queue. > > I thought about solution again and now I think that it would be better to remove at all lines about WM_DESTROY handling, such as we don't handle this message. And let it be handled by default. That code does nothing except posting WM_QUIT messages leading to test skipping. (test passed on WineBot) > > What do you think? > > > 28.05.2012, 10:32, "Dmitry Timoshkov" <dmitry(a)baikal.ru>: >> sir-lexa <sir-lexa(a)yandex.ru> wrote: >>> case WM_DESTROY: >>> - PostQuitMessage(0); >>> + /* PostQuitMessage(0); It lets some tests to be skipped */ >>> return TRUE; >> This is not acceptable, there is much more behind the scene. You need >> to figure out the real reason of skipping the tests. >> >> -- >> Dmitry.

May 31, 2012

Re: [PATCH 3/5] ddraw/tests: Add test_coop_level_mode_set() for older ddraw versions.

by Marvin

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=18687 Your paranoid android. === WNT4WSSP6 (32 bit ddraw2) === ddraw2.c:2282: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw2.c:2284: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:2310: Test failed: Expected surface width 640, got 800. ddraw2.c:2312: Test failed: Expected surface height 480, got 600. ddraw2.c:2327: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:2338: Test failed: Expected surface width 640, got 800. ddraw2.c:2340: Test failed: Expected surface height 480, got 600. ddraw2.c:2406: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw2.c:2408: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:2434: Test failed: Expected surface width 640, got 800. ddraw2.c:2436: Test failed: Expected surface height 480, got 600. ddraw2.c:2451: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:2462: Test failed: Expected surface width 640, got 800. ddraw2.c:2464: Test failed: Expected surface height 480, got 600. === WNT4WSSP6 (32 bit ddraw1) === ddraw1.c:2145: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw1.c:2147: Test failed: Expected message 0x7e, but didn't receive it. ddraw1.c:2173: Test failed: Expected surface width 640, got 800. ddraw1.c:2175: Test failed: Expected surface height 480, got 600. ddraw1.c:2190: Test failed: Expected message 0x7e, but didn't receive it. ddraw1.c:2201: Test failed: Expected surface width 640, got 800. ddraw1.c:2203: Test failed: Expected surface height 480, got 600. ddraw1.c:2269: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw1.c:2271: Test failed: Expected message 0x7e, but didn't receive it. ddraw1.c:2297: Test failed: Expected surface width 640, got 800. ddraw1.c:2299: Test failed: Expected surface height 480, got 600. ddraw1.c:2314: Test failed: Expected message 0x7e, but didn't receive it. ddraw1.c:2325: Test failed: Expected surface width 640, got 800. ddraw1.c:2327: Test failed: Expected surface height 480, got 600.

May 31, 2012

Re: [PATCH 3/3] ntdll/tests: Add tests for RtlGetProductInfo [resend]

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > Clone the kernel32 tests to verify, that the NULL pointer > check is present in ntdll.dll That's not useful, it's clearly the same function, it doesn't need to be tested twice. -- Alexandre Julliard julliard(a)winehq.org

May 31, 2012

Re: [PATCH 1/5] win16/int21: make found filename uppercase.

by Alexandre Julliard

Oleksij Rempel <bug-track(a)fisher-privat.net> writes: > it is true, i used "char *". I just copy pasted this part from > "Convert ASCIIZ string to uppercase" in int21.c > So probably this should be fixed too. > > Or there is any way no interest to apply current patch? Only if you can show an application that depends on this. Otherwise there's no reason to change anything. -- Alexandre Julliard julliard(a)winehq.org

May 31, 2012

Re: [PATCH 1/5] win16/int21: make found filename uppercase.

by Oleksij Rempel

Am 30.05.2012 23:06, schrieb David Laight: > On Wed, May 30, 2012 at 01:32:28PM +0200, Alexandre Julliard wrote: >> Oleksij Rempel <bug-track(a)fisher-privat.net> writes: >> >>> @@ -3961,6 +3962,8 @@ static int INT21_FindNext( CONTEXT *context ) >>> INT21_FindPath = dta->fullPath = NULL; >>> } >>> dta->count = n; >>> + p = dta->filename; >>> + for ( ; *p; p++) *p = toupper(*p); >> >> Using toupper is probably not a good idea on OEM codepage strings. Which >> app depends on this? > > I'd also guess that 'p' is defined as 'char *'. > The domain of toupper() isn't char, the value must be cast to > 'unsigned char' (or the pointer to 'unsigned char *'). > > David > it is true, i used "char *". I just copy pasted this part from "Convert ASCIIZ string to uppercase" in int21.c So probably this should be fixed too. Or there is any way no interest to apply current patch? -- Regards, Oleksij

May 31, 2012

Re: [4/4] windowscodecs: Add stub IWICMetadataBlockReader to PNG decoder.

by Marvin

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=18675 Your paranoid android. === WXPPROSP3 (32 bit metadata) === metadata: unhandled exception c0000005 at 4CCA826D === W2K8SE (32 bit metadata) === metadata: unhandled exception c0000005 at 72C28045

May 30, 2012

Re: [3/4] windowscodecs: Add test for IWICMetadataBlockReader interface.

by Marvin

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=18674 Your paranoid android. === WXPPROSP3 (32 bit metadata) === metadata: unhandled exception c0000005 at 4CCA826D === W2K8SE (32 bit metadata) === metadata: unhandled exception c0000005 at 72C28045

May 30, 2012

crypt32/tests(1/6): Don't shadow a variable with a variable of a different type

by Juan Lang

--Juan

May 30, 2012

Re: [PATCH 1/5] win16/int21: make found filename uppercase.

by David Laight

On Wed, May 30, 2012 at 01:32:28PM +0200, Alexandre Julliard wrote: > Oleksij Rempel <bug-track(a)fisher-privat.net> writes: > > > @@ -3961,6 +3962,8 @@ static int INT21_FindNext( CONTEXT *context ) > > INT21_FindPath = dta->fullPath = NULL; > > } > > dta->count = n; > > + p = dta->filename; > > + for ( ; *p; p++) *p = toupper(*p); > > Using toupper is probably not a good idea on OEM codepage strings. Which > app depends on this? I'd also guess that 'p' is defined as 'char *'. The domain of toupper() isn't char, the value must be cast to 'unsigned char' (or the pointer to 'unsigned char *'). David -- David Laight: david(a)l8s.co.uk

May 30, 2012

Re: [2/2]kernel32/test: added test for OutputDebugStringA called with NULL pointer

by Marvin

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=18671 Your paranoid android. === WXPPROSP3 (32 bit debugger) === Timeout === W2K3R2SESP2 (32 bit debugger) === Timeout

May 30, 2012

Re: [1/5] windowscodecs: Implement IWICStream::InitializeFromIStream. (try 2)

by Vincent Povirk

BTW, the patch looks good to me. On Tue, May 29, 2012 at 8:07 AM, Vincent Povirk <madewokherd(a)gmail.com> wrote: >>> + offset.QuadPart = 0; >>> + size.u.LowPart = 0xffffffff; >>> + size.u.HighPart = 0xffffffff; >>> + return IWICStream_InitializeFromIStreamRegion(iface, pIStream, offset, size); >> >> What prevents you from discovering correct stream size? > > The size passed to InitializeFromIStreamRegion is an upper limit. If > the underlying stream is smaller, the appropriate size will still be > reported from Read, Stat, and Seek.

May 30, 2012

Re: [1/2] mscoree: Install Wine Mono on prefix update.

by Alexandre Julliard

Vincent Povirk <madewokherd(a)gmail.com> writes: >> This is breaking 64-bit prefixes, because things are not done in the >> correct order. > > Can you explain what exactly is breaking? Most of my testing has been > in 64-bit prefixes, and I haven't noticed any new problems (other than > lack of gluezilla). Many things don't end up in the right place in the registry, probably because it's trying to create 32-bit keys before the symlinks are in place or something like that. -- Alexandre Julliard julliard(a)winehq.org

May 30, 2012

Re: [1/2] mscoree: Install Wine Mono on prefix update.

by Vincent Povirk

> This is breaking 64-bit prefixes, because things are not done in the > correct order. Can you explain what exactly is breaking? Most of my testing has been in 64-bit prefixes, and I haven't noticed any new problems (other than lack of gluezilla).

May 30, 2012

Re: [PATCH 4/4] jscript: Added VT_I2 tests

by Marvin

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=18657 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

May 30, 2012

Re: [PATCH 1/5] win16/int21: make found filename uppercase.

by Oleksij Rempel

Am 30.05.2012 13:32, schrieb Alexandre Julliard: > Oleksij Rempel <bug-track(a)fisher-privat.net> writes: > >> @@ -3961,6 +3962,8 @@ static int INT21_FindNext( CONTEXT *context ) >> INT21_FindPath = dta->fullPath = NULL; >> } >> dta->count = n; >> + p = dta->filename; >> + for ( ; *p; p++) *p = toupper(*p); > > Using toupper is probably not a good idea on OEM codepage strings. Which > app depends on this? Probably none. I created this patch by hunting this get_media_id bug. I even created small windows program calling findfirst/findnext to compare the output produced by windows and wine. I just reverted this patch and tested with the program i was working on and it still works. So no need to apply this patch. -- Regards, Oleksij

May 30, 2012

Re: [1/2] mscoree: Install Wine Mono on prefix update.

by Alexandre Julliard

Vincent Povirk <madewokherd(a)gmail.com> writes: > From d271ba591f6afb4e0b2356da24841f54d5f11b9b Mon Sep 17 00:00:00 2001 > From: Vincent Povirk <vincent(a)codeweavers.com> > Date: Tue, 29 May 2012 10:35:36 -0500 > Subject: [PATCH 1/2] mscoree: Install Wine Mono on prefix update. > > --- > dlls/mscoree/mscoree_main.c | 120 +++++++++++++++++++++++++++++++++++++++++++ > tools/wine.inf.in | 1 + > 2 files changed, 121 insertions(+) This is breaking 64-bit prefixes, because things are not done in the correct order. It also looks like the package is not creating the 64-bit registry keys. -- Alexandre Julliard julliard(a)winehq.org

May 30, 2012

Re: [PATCH 1/5] win16/int21: make found filename uppercase.

by Alexandre Julliard

Oleksij Rempel <bug-track(a)fisher-privat.net> writes: > @@ -3961,6 +3962,8 @@ static int INT21_FindNext( CONTEXT *context ) > INT21_FindPath = dta->fullPath = NULL; > } > dta->count = n; > + p = dta->filename; > + for ( ; *p; p++) *p = toupper(*p); Using toupper is probably not a good idea on OEM codepage strings. Which app depends on this? -- Alexandre Julliard julliard(a)winehq.org

May 30, 2012

Re: [PATCH 2/3] jscript: Get rid of ret_nan hack

by Jacek Caban

On 05/29/12 22:06, Ruslan Kabatsayev wrote: > Hello, > > This patch (committed as d0a719a79dae001df341db907fcae54118691d35) > leads to compilation error: > > make[1]: Entering directory `/fastdocs/programmer/wine-git/dlls/msadp32.acm' > make[1]: Nothing to be done for `all'. > make[1]: Leaving directory `/fastdocs/programmer/wine-git/dlls/msadp32.acm' > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ > -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers > -Wstrict-prototypes -Wtype-limits -Wwrite-strings > -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op > -I/usr/include/freetype2 -I/opt/Xorg-7.5/include > -L/opt/Xorg-7.5/lib -o string.o string.c > lex.c: In function ‘cc_token’: > lex.c:936:71: error: ‘NAN’ undeclared (first use in this function) > lex.c:936:71: note: each undeclared identifier is reported only once > for each function it appears in > make[1]: *** [lex.o] Error 1 > > I've tried doing git clean -xdf, but this still doesn't compile. > Thanks for the report, I've sent a fix: http://source.winehq.org/patches/data/86689 Cheers, Jacek

May 30, 2012

Re: ru.po: improved an Russian translation

by Nikolay Sivov

On Wed, May 30, 2012 at 10:20 AM, Julian Rüger <jr98(a)gmx.net> wrote: > > 3. You have a lot of changes like this: > >> #: crypt32.rc:198 >> msgid "Access Method=" >> -msgstr "Метод доступа=" >> +msgstr "Метод доступа: " > It makes no sense to do that. > I don't think that's a good idea... Afaik, the general guideline is to > not change formatting and punctuation (from the English original), > unless there's a rule in the Russian language that specifically dictates > it. (For example in French, you need spaces in front of colons and > stuff) > No, there's no such rule to force you to use specific formatting in this case. There's probably some typography guidelines for that but it clearly doesn't apply in this case - it should follow English name format.

May 30, 2012

Re: ru.po: improved an Russian translation

by Julian Rüger

Am Dienstag, den 29.05.2012, 23:04 +0400 schrieb Oleg Yarigin: > There are some improvements of a style (now it is more official) and > non-translated empty lines. > > > To avoid an character encoding interruption, I send the diff file as a > packed text file attachment (ru_diff.txt.bz2, 22.3 KB). Hi Oleg, a few remarks about your patch: 1. Patches should be sent to wine-patches(a)winehq.org, not wine-devel. However, if you only want to ask for review and not send the patch in yet, wine-devel is fine. 2. You should generate your patch using "git format-patch", see http://wiki.winehq.org/GitWine 3. You have a lot of changes like this: > #: crypt32.rc:198 > msgid "Access Method=" > -msgstr "Метод доступа=" > +msgstr "Метод доступа: " I don't think that's a good idea... Afaik, the general guideline is to not change formatting and punctuation (from the English original), unless there's a rule in the Russian language that specifically dictates it. (For example in French, you need spaces in front of colons and stuff) I don't know Russian, so I may be wrong here. 4. A normal, UTF-8 formatted textfile as an attachment (preferably generated by git format-patch, see above) should suffice, you shouldn't need to pack it. I guess an archive could also confuse the automated scripts, requiring Alexandre to manually unpack it and add your patch to the incoming queue (http://source.winehq.org/patches/) Again, I may be wrong about that, but it would not hurt I think. OK, enough of my nagging ;) Please understand this as constructive criticism, it will help getting your patch accepted and not cause extra work for the maintainer (Alexandre). It looks like you invested a lot of effort, thanks for that. I don't speak Russian, so I can't say anything else, maybe it would also help to ask the current translator for review (I think Nikolay Sivov). Best regards, Julian

May 30, 2012

stub for SetThreadStackGuarantee

by Daniel Jelinski

Hello, SQL Server Management Studio 2005 needs SetThreadStackGuarantee to either be absent or return TRUE - otherwise it refuses to run at all. Is there a reason for this stub to return FALSE? Regards, Daniel

May 29, 2012

Re: [PATCH 2/3] jscript: Get rid of ret_nan hack

by Ruslan Kabatsayev

Hello, This patch (committed as d0a719a79dae001df341db907fcae54118691d35) leads to compilation error: make[1]: Entering directory `/fastdocs/programmer/wine-git/dlls/msadp32.acm' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/fastdocs/programmer/wine-git/dlls/msadp32.acm' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -I/opt/Xorg-7.5/include -L/opt/Xorg-7.5/lib -o string.o string.c lex.c: In function ‘cc_token’: lex.c:936:71: error: ‘NAN’ undeclared (first use in this function) lex.c:936:71: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [lex.o] Error 1 I've tried doing git clean -xdf, but this still doesn't compile. Regards, Ruslan On Tue, May 29, 2012 at 2:53 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > dlls/jscript/date.c | 28 ++++++++++++++-------------- > dlls/jscript/error.c | 3 ++- > dlls/jscript/global.c | 2 +- > dlls/jscript/jscript.h | 7 ------- > dlls/jscript/jsutils.c | 6 +++--- > dlls/jscript/lex.c | 2 +- > 6 files changed, 21 insertions(+), 27 deletions(-) > > > > >

May 29, 2012

ru.po: improved an Russian translation

by Oleg Yarigin

There are some improvements of a style (now it is more official) and non-translated empty lines. To avoid an character encoding interruption, I send the diff file as a packed text file attachment (ru_diff.txt.bz2, 22.3 KB).

May 29, 2012

Re: kernel32/volume: Don't modify the last error in GetVolumeInformation

by Alexandre Goujon

On Tue, May 29, 2012 at 7:07 PM, Alexandre Julliard <julliard(a)winehq.org>wrote: > Alexandre Goujon <ale.goujon(a)gmail.com> writes: > > > @@ -729,6 +731,8 @@ BOOL WINAPI GetVolumeInformationW( LPCWSTR root, > LPWSTR label, DWORD label_len, > > } > > else > > { > > + /* At this point, last error is ERROR_NOT_SUPPORTED. > Restoring the previous one */ > > + SetLastError(lastError); > > You should never need to do that sort of thing, there are no guarantees > about last error on success. > > -- > Alexandre Julliard > julliard(a)winehq.org > I know but The Sims 3 calls GetLastError very often (in the top 10), nearly between each call, maybe to check if a specific error does (or doesn't) occur. It troubled me when I investigated a bug and I thought the cost was so low that we could do it anyway. But I know you are right, so just forget about it. PS: FYI I tested it on WIndows and the last error is not changed (but it doesn't matter as you said)

May 29, 2012

Re: kernel32/volume: Don't modify the last error in GetVolumeInformation

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -729,6 +731,8 @@ BOOL WINAPI GetVolumeInformationW( LPCWSTR root, LPWSTR label, DWORD label_len, > } > else > { > + /* At this point, last error is ERROR_NOT_SUPPORTED. Restoring the previous one */ > + SetLastError(lastError); You should never need to do that sort of thing, there are no guarantees about last error on success. -- Alexandre Julliard julliard(a)winehq.org

May 29, 2012