February 2015 - Wine-Devel - list.winehq.org

Re: [3/5] comctl32: Implement TaskDialogIndirect as a custom dialog box (try 2)

by Nikolay Sivov

On 23.02.2015 15:42, Joachim Priesner wrote: > + if (IS_INTRESOURCE(text)) > + { > + SetLastError(S_OK); > + LoadStringW(instance, LOWORD(text), (LPWSTR)result, 0); > + return HRESULT_FROM_WIN32(GetLastError()); > + } You don't need SetLastError(), especially not with HRESULT value. And GetLastError() should only be used when LoadStringW() fails. The rest looks good enough to me.

Feb. 24, 2015

Re: [2/5] comctl32: Add and fix tests for invalid TaskDialogIndirect arguments (try 2)

by Nikolay Sivov

On 23.02.2015 15:41, Joachim Priesner wrote: > > START_TEST(taskdialog) > @@ -49,6 +79,20 @@ START_TEST(taskdialog) > if (!load_v6_module(&ctx_cookie, &hCtx)) > return; > > + hComctl32 = LoadLibraryA("comctl32.dll"); > + if (!hComctl32) > + { > + skip("Failed to load comctl32.dll. Skipping the test\n"); > + return; > + } It's unlikely if will fail to load, also load_v6_module() already calls LoadLibraryA(), so you probably need GetModuleHandle().

Feb. 24, 2015

Re: makedep: Sanitize the module names before turning them into resource ids.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > On Fri, 20 Feb 2015, Alexandre Julliard wrote: > [...] >> There's no reason that resource ids can't contain dashes, > > You're right, it's a bug in wrc. > > The simple fix would be to add '-' to the set of allowed characters for > tIDENT but in fact the resource and type ids (and probably filenames) > can contain pretty much any character. That's much harder to handle in > the parser however :-( Yes, cf. bug 786. >> and besides, winetest won't know what to do with it if you change the >> name. > > I did test and that worked... just had to use underscores. I don't see how winetest can find the dll if it's using underscores. -- Alexandre Julliard julliard(a)winehq.org

Feb. 24, 2015

Re: dwrite/tests: Place test font file in a temporary location, make sure it's deleted at the end

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 https://testbot.winehq.org/JobDetails.pl?Key=11677 Your paranoid android. === wvistau64 (32 bit font) === font.c:99: Test failed: failed to delete file L"wine_test_font.ttf", error 2 === w2008s64 (32 bit font) === font.c:99: Test failed: failed to delete file L"wine_test_font.ttf", error 2 === wvistau64 (64 bit font) === font.c:99: Test failed: failed to delete file L"wine_test_font.ttf", error 2 === w2008s64 (64 bit font) === font.c:99: Test failed: failed to delete file L"wine_test_font.ttf", error 2 === wvistau64 (32 bit analyzer) === analyzer.c:474: Test failed: failed to delete file L"C:\\Users\\winetest\\AppData\\Local\\Temp\\wine_test_font.ttf", error 5 === w2008s64 (32 bit analyzer) === analyzer.c:474: Test failed: failed to delete file L"C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\wine_test_font.ttf", error 5 === wvistau64 (64 bit analyzer) === analyzer.c:474: Test failed: failed to delete file L"C:\\Users\\winetest\\AppData\\Local\\Temp\\wine_test_font.ttf", error 5 === w2008s64 (64 bit analyzer) === analyzer.c:474: Test failed: failed to delete file L"C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\wine_test_font.ttf", error 5

Feb. 23, 2015

Re: Abbreviation of "microsecond" in sane.ds

by Alex Henrie

2015-02-23 5:33 GMT-07:00 Michael Stefaniuc <mstefani(a)redhat.com>: > On 02/23/2015 11:11 AM, Alex Henrie wrote: >> http://source.winehq.org/git/wine.git/blob/c72f9a0082c3cc07454fb93bca88e294… >> >> Is there a compelling reason why "microsecond" is abbreviated as >> "us" instead of "μs"? This library doesn't correspond to any >> Windows library, so we should be free to use the more correct >> abbreviation. Or can sane.rc only accept ASCII characters? > I remember that there was a thread on wine-devel about that 1+ years > ago. You might want to search for that if nobody remembers. Found it, thanks: https://www.winehq.org/pipermail/wine-devel/2012-August/096729.html 2015-02-23 7:13 GMT-07:00 Alexandre Julliard <julliard(a)winehq.org>: > Message ids have to be in ASCII. The po file takes care of mapping it to > the correct string. Thanks for explaining this again. I didn't realize that there was an en.po until now. It sounds like it would be a good idea to start accepting UTF-8 in rc files, or at least add a comment to this one explaining that it is corrected in the po files. -Alex

Feb. 23, 2015

Re: makedep: Sanitize the module names before turning them into resource ids.

by Francois Gouget

On Fri, 20 Feb 2015, Alexandre Julliard wrote: [...] > There's no reason that resource ids can't contain dashes, You're right, it's a bug in wrc. The simple fix would be to add '-' to the set of allowed characters for tIDENT but in fact the resource and type ids (and probably filenames) can contain pretty much any character. That's much harder to handle in the parser however :-( The problem is we can have things like: --- /* A resource called '1,2,3,4' of type '5,6,7,8' */ 1,2,3,4 5,6,7,8 special-characters-must-be-quoted.exe /* A VERSIONINFO resource called '4,3,2,1' */ 4,3,2,1 16 FILEVERSION 1,0x2,3,4 FILESUBTYPE 0x0 { BLOCK "StringFileInfo" { } } 1,2,%,4 5,$,7,( api.exe --- So the problem is that sometimes 1,2,3,4 should be treated as a single token (tIDENT), and sometimes as 7 tokens: four numbers and three commas. I'm not sure the lexer can distinguish between these two cases on its own. Maybe if it switches to the 'numbers please' mode when returning a FILEVERSION token (and the others like it), and also when returning an opening brace. It would then have to count the opening/closing braces (resp BEGIN/END tokens) to know when to go back to its default state. And this probably is not limited to the VERSIONINFO type of resource. Another option would be to switch the lexer state from the grammatical parser but that's frowned upon. So if it's not necessary it would be nice to avoid it. Interestingly, commas are not allowed in unquoted filenames: this means that at this point it treats commas as separators, just like in the file resource. However characters like '^' or '$' are allowed. Any opening brace also seems to have an impact: '1 3,4 dummy' complains dummy does not exist, but '{ 1 3,4 dummy' complains '3' does not exist. So does '{ 1,2 3,4' so the first comma does not seem to be treated as a separator. > and besides, winetest won't know what to do with it if you change the > name. I did test and that worked... just had to use underscores. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ E-Voting: It's not the people who vote that count. It's the people who count the votes.

Feb. 23, 2015

Re: Abbreviation of "microsecond" in sane.ds

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > http://source.winehq.org/git/wine.git/blob/c72f9a0082c3cc07454fb93bca88e294… > > Is there a compelling reason why "microsecond" is abbreviated as "us" > instead of "μs"? This library doesn't correspond to any Windows > library, so we should be free to use the more correct abbreviation. Or > can sane.rc only accept ASCII characters? Message ids have to be in ASCII. The po file takes care of mapping it to the correct string. -- Alexandre Julliard julliard(a)winehq.org

Feb. 23, 2015

Re: Abbreviation of "microsecond" in sane.ds

by Michael Stefaniuc

On 02/23/2015 11:11 AM, Alex Henrie wrote: > http://source.winehq.org/git/wine.git/blob/c72f9a0082c3cc07454fb93bca88e294… > > Is there a compelling reason why "microsecond" is abbreviated as > "us" instead of "μs"? This library doesn't correspond to any > Windows library, so we should be free to use the more correct > abbreviation. Or can sane.rc only accept ASCII characters? I remember that there was a thread on wine-devel about that 1+ years ago. You might want to search for that if nobody remembers. bye michael

Feb. 23, 2015

Re: mshtml/tests: Remove an always true conditional subexpression (PVS-Studio)

by Michael Stefaniuc

On 02/21/2015 06:18 PM, Marvin wrote: > 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://testbot.winehq.org/JobDetails.pl?Key=11654 > > Your paranoid android. > > > === wvistau64 (32 bit events) === events.c:939: Test failed: > unexpected call img_onerror > > === w7u (32 bit events) === events.c:939: Test failed: unexpected > call img_onerror The test timed out That seems to be a fluke as a rerun of the tests passed on those machines https://testbot.winehq.org/JobDetails.pl?Key=11663 Ignore the w2000pro and w2003std failures as those are permanent issues unrelated to my patch. That's why Marvin didn't complain about those. bye michael

Feb. 23, 2015

Re: fltmgr.sys: add stub dll (try 2)

by Austin English

On Mon, Feb 23, 2015 at 2:00 AM, Alistair Leslie-Hughes < leslie_alistair(a)hotmail.com> wrote: > On 11/02/15 08:15, Austin English wrote: > >> https://bugs.winehq.org/show_bug.cgi?id=23583 >> >> -- >> -Austin >> >> This file belongs in the "system32\drivers" directory. > > > Best Regards > Alistair Leslie-Hughes > That's where it's going, %12% corresponds to system32/drivers, the same as mountmgr.sys and ndis.sys before it. -- -Austin

Feb. 23, 2015