January 2014 - Wine-devel - list.winehq.org

Re: [PATCH] bcrypt: Added stub implementation for BCryptGetFipsAlgorithmMode
by Dmitry Timoshkov 23 Jan '14

23 Jan '14

Kai Blaschke <kai.blaschke(a)kb-dev.net> wrote: > diff --git a/dlls/bcrypt/tests/Makefile.in b/dlls/bcrypt/tests/Makefile.in > new file mode 100644 > index 0000000..363986e > --- /dev/null > +++ b/dlls/bcrypt/tests/Makefile.in > @@ -0,0 +1,5 @@ > +TESTDLL = bcrypt.dll > +IMPORTS = user32 gdi32 bcrypt user32 and gdi32 APIs are not used in the test and should be removed from the imports list. > +static void test_getFipsAlgorithmMode(void) > +{ > + BOOLEAN result = TRUE; > + NTSTATUS status = BCryptGetFipsAlgorithmMode(&result); > + ok(!status, "expected status STATUS_SUCCESS(0), got %d\n", status); > + ok(!result, "expected result FALSE, got %d\n", result); > +} Probably BCryptGetFipsAlgorithmMode should be loaded dynamically. A usual test for invalid (NULL) argument would be useful. Also status should be printed in hex to match ntstatus.h definitions. -- Dmitry.

2 1

Re: shlwapi/tests: Avoid preprocessor check to ensure it compiles
by Dmitry Timoshkov 23 Jan '14

23 Jan '14

André Hentschel <nerv(a)dawncrow.de> wrote: > -#if 0 /* This test crashes on WinXP SP2 */ > +if (0) > +{ > ret = (*pSHCreateStreamOnFileA)(test_file, mode | stgm, NULL); > ok(ret == E_INVALIDARG, "SHCreateStreamOnFileA: expected E_INVALIDARG, got 0x%08x\n", ret); > -#endif > +} Please keep the comment. -- Dmitry.

1 0

Re:Add support to arguments with dash in taskkill
by Akira Nakagawa 23 Jan '14

23 Jan '14

if (*argdata != '/' && *argdata != '-') argdata is wchar type,so you should do as if (*argdata != L'/' && *argdata != L'-')

2 1

Re: [PATCH 1/2] advapi32: Foundation for HKCR merge
by Marvin 23 Jan '14

23 Jan '14

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

1 0

Re: user32/tests: Avoid preprocessor checks to ensure it compiles
by Marvin 22 Jan '14

22 Jan '14

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=4400 Your paranoid android. === wxppro (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000800C4 fg 00030052 in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 00000000 win.c:2952: Test failed: GetFocus() = 00000000 win.c:2975: Test failed: GetActiveWindow() = 00000000 win.c:2975: Test failed: GetFocus() = 00000000 win.c:3036: Test failed: GetActiveWindow() = 00000000 win.c:3036: Test failed: GetFocus() = 00000000 === wvista (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000602B4 fg 00020222 in hook HCBT_ACTIVATE === w2008s64 (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000600F0 fg 0001004E in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 00000000 win.c:2952: Test failed: GetFocus() = 00000000 win.c:2975: Test failed: GetActiveWindow() = 00000000 win.c:2975: Test failed: GetFocus() = 00000000 win.c:3036: Test failed: GetActiveWindow() = 00000000 win.c:3036: Test failed: GetFocus() = 00000000 === w7pro64 (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 00060106 fg 00010064 in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 00000000 win.c:2952: Test failed: GetFocus() = 00000000 win.c:2975: Test failed: GetActiveWindow() = 00000000 win.c:2975: Test failed: GetFocus() = 00000000 win.c:3036: Test failed: GetActiveWindow() = 00000000 win.c:3036: Test failed: GetFocus() = 00000000 === w2008s64 (64 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 00000000000600F0 fg 000000000001004E in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 0000000000000000 win.c:2952: Test failed: GetFocus() = 0000000000000000 win.c:2975: Test failed: GetActiveWindow() = 0000000000000000 win.c:2975: Test failed: GetFocus() = 0000000000000000 win.c:3036: Test failed: GetActiveWindow() = 0000000000000000 win.c:3036: Test failed: GetFocus() = 0000000000000000 === w7pro64 (64 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 0000000000060106 fg 0000000000010064 in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 0000000000000000 win.c:2952: Test failed: GetFocus() = 0000000000000000 win.c:2975: Test failed: GetActiveWindow() = 0000000000000000 win.c:2975: Test failed: GetFocus() = 0000000000000000 win.c:3036: Test failed: GetActiveWindow() = 0000000000000000 win.c:3036: Test failed: GetFocus() = 0000000000000000

1 0

Re: add Japanese man page of wine.
by Akihiro Sagawa 22 Jan '14

22 Jan '14

On Tue, 21 Jan 2014 23:56:15 +0900, Akira Nakagawa wrote: > diff --git a/loader/Makefile.in b/loader/Makefile.in > index 665bdda..80966fa 100644 > --- a/loader/Makefile.in > +++ b/loader/Makefile.in > @@ -8,6 +8,7 @@ MANPAGES = \ > wine.de.UTF-8.man.in \ > wine.fr.UTF-8.man.in \ > wine.man.in \ > + wine.ja.UTF-8.man.in \ > wine.pl.UTF-8.man.in > > IN_SRCS = \ Please keep alphabetical order. > diff --git a/loader/wine.ja.UTF-8.man.in b/loader/wine.ja.UTF-8.man.in > new file mode 100644 > index 0000000..c07adaa > --- /dev/null > +++ b/loader/wine.ja.UTF-8.man.in > @@ -0,0 +1,304 @@ (..) > +CUIの実行可能プログラム(Windowsコンソールプログラム)を実行するには、 > +.BR wineの代わりに The last line should be ".BR wine の代わりに" (note the space character after wine). Because groff thinks "wineの代わりに" is one word, whole of the sentence outputs in bold face. But, we just need to emphasize "wine". Please recheck other .RI, .RB, .BR, .IR macro lines. groff_man(7) describes these macro usages. Akihiro Sagawa

1 0

Re: Add support to arguments with dash in taskkill
by 中川祥 22 Jan '14

22 Jan '14

you compare the text without checking if it is 2 byte word. Is there any problem?

2 1

Re: [PATCH 2/3] riched20: Use codepage in ME_ToUnicode. (try 7)
by Alexandre Julliard 21 Jan '14

21 Jan '14

Jactry Zeng <jactry92(a)gmail.com> writes: > From 4bda4b989cef6ee1f45e6ee989e63db05ef770de Mon Sep 17 00:00:00 2001 > From: Jactry Zeng <jactry92(a)gmail.com> > Date: Sun, 5 Jan 2014 20:58:55 +0800 > Subject: riched20: Use codepage in ME_ToUnicode. > > --- > dlls/riched20/editor.c | 15 ++++++++------- > dlls/riched20/editor.h | 4 ++-- > dlls/riched20/string.c | 12 ++++++------ > 3 files changed, 16 insertions(+), 15 deletions(-) It doesn't work: ../../../tools/runtest -q -P wine -T ../../.. -M riched20.dll -p riched20_test.exe.so editor && touch editor.ok editor.c:7423: Test failed: GetWindowText returned 1 editor.c:7424: Test failed: buf = l make: *** [editor.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [patch]: include : Add missing API to direct-x 9's shader header
by Dmitry Timoshkov 21 Jan '14

21 Jan '14

Kai Tietz <ktietz70(a)googlemail.com> wrote: > -DEFINE_GUID(IID_ID3DXConstantTable, 0x9dca3190, 0x38b9, 0x4fc3, 0x92, > 0xe3, 0x39, 0xc6, 0xdd, 0xfb, 0x35, 0x8b); > +DEFINE_GUID(IID_ID3DXConstantTable, 0xab3c758f, 0x93e, 0x4356, 0xb7, > 0x62, 0x4d, 0xb1, 0x8f, 0x1b, 0x3a, 0x1); A quick google search seems to contradict this change. Where does this come from? Also all of this looks like a plain copy/paste from MS headers, you can't do that. -- Dmitry.

3 2

Re: [PATCH v7 1/7] VFS: Introduce new O_DENY* open flags
by Pavel Shilovsky 21 Jan '14

21 Jan '14

2014/1/20 One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk>: >> > Shouldn't this also check for CAP_SYS_DAC or some similar permission so >> > that root can override such a mess (eg to fix full disks in an >> > emergency) ? >> >> May be it's better to let root an ability to remount the system >> without sharelock mount option and then fix an emergency? > > Doesn't that involve breaking the service for all users of the system > relying upon those locks, while root being allowed to ignore the locks > does not ? If we allow root to remount without "sharelock" (or bypass conflict checks), it will definitely break the service for all users. Probably it's better to stop the service (that cause all sharelocks to be unlocked), fix the emergency and start the service again. In the current state, the patchset doesn't allow any sort of ignoring those locks for mounts with "sharelock" option (either remount without "sharelock" or set special capabilities). It was done to make sure nothing breaks applications relying upon sharelock behavior. Also, that's why "sharelock" mount option was added: this behavior is dangerous to be on critical system paths like "/" or "/lib" and not suitable for global use. -- Best regards, Pavel Shilovsky.

1 0