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

Re: msvcrt: Don't crash on NULL struct _tm in asctime
by Marvin May 12, 2014

May 12, 2014

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=6983 Your paranoid android. === w2000pro (32 bit time) === time: unhandled exception c0000005 at 78028AD5 === wxppro (32 bit time) === time: unhandled exception c0000005 at 77C4A8B6

1 0

Re: [PATCH 2/2] oleacc: Add GetStateText implementation (try2)
by Nikolay Sivov May 12, 2014

May 12, 2014

> + state_id = IDS_STATE_MIN; > + while(dwStateBit) { > + state_id++; > + dwStateBit /= 2; > + } It looks like ffs() could be used to do that. Actually it would be better to find a way to connect those resource ids with actual STATE_SYSTEM_* symbols, not sure if it's possible to do cleanly. Also I don't like formatting, especially prefixed names, but that's probably considered to be submitter choice.

2 3

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.
by Alexandre Julliard May 12, 2014

May 12, 2014

Ken Thomases <ken(a)codeweavers.com> writes: > The specific pixel format was never used. It was effectively just a flag > indicating if the window had a GL surface. This generalizes it from a flag > to a count, to allow for multiple GL surfaces. I'm not convinced that the concept of multiple surfaces makes sense, except maybe as a driver implementation detail. -- Alexandre Julliard julliard(a)winehq.org

4 15

Re: [PATCH] gdi32: Add MS Shell Dlg tests
by Dmitry Timoshkov May 12, 2014

May 12, 2014

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > + memset(&efnd, 0, sizeof(efnd)); > + strcpy(lf.lfFaceName, "MS Shell Dlg"); > + ret = EnumFontFamiliesExA(hdc, &lf, enum_fullname_data_proc, (LPARAM)&efnd, 0); > + ok(ret, "font MS Shell Dlg is not enumerated\n"); > + ret = strcmp((char*)efnd.elf[0].elfLogFont.lfFaceName, "MS Shell Dlg"); > + todo_wine ok(!ret, "expected MS Shell Dlg got %s\n", efnd.elf[0].elfLogFont.lfFaceName); > + ret = strcmp((char*)efnd.elf[0].elfFullName, "MS Shell Dlg"); > + ok(ret, "did not expect MS Shell Dlg\n"); Please add the tests for other font enumeration APIs (the may behave differently), and the tests with NULL face name (according to my tests in that case MS Shell Dlg won't be enumerated). Since that would clutter existing tests I'd suggest to move the new one into separate body and name it appropriately. -- Dmitry.

2 1

Re: comctl32/listview: Fix custom draw stage sequence
by Marvin May 12, 2014

May 12, 2014

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=6975 Your paranoid android. === w2000pro (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wxppro (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w8 (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (64 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

2 1

Re: [PATCH] gdi32: Add MS Shell Dlg tests
by Marvin May 12, 2014

May 12, 2014

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=6979 Your paranoid android. === wvistau64 (32 bit font) === The test timed out === wvistau64 (64 bit font) === The test timed out

1 0

Federal circuit reverses ruling on Java APIs
by Alex M May 11, 2014

May 11, 2014

https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracle-v-google-fede… This is very worrying news. What are the implications for WINE if this manages to go through entirely? -- Malo periculosam libertatem quam quietum servitium.

4 3

Testbot
by Mikael Ståldal May 11, 2014

May 11, 2014

I see in the patch list http://source.winehq.org/patches/ that the testbot run on some patches, but not all. What determine if it run or not?

2 4

Re: ced401: add initial support
by André Hentschel May 9, 2014

May 9, 2014

Am 09.05.2014 14:42, schrieb Alois Schlögl: > The attached patch includes the stubs for the ced1401 driver dll. > > This is a starting point to support ced1401/spike2/signal software. > > It's my first patch submission to wine - feedback welcome. > I also doubt that this wrapper get's included as it's too special. But when you finished your work, could you please share a link to github or somewhere with me. (I'm collecting wrappers for Wine on my website: http://dawncrow.de/wine/index.html )

1 0

Re: gdi32: Report unsubstituted font face names. (try 5)
by Alexandre Julliard May 9, 2014

May 9, 2014

Alex Henrie <alexhenrie24(a)gmail.com> writes: > I kept the full name tests, but now they make sure that the full name > is a SUBSTITUTED font name. It breaks the gdiplus tests: ../../../tools/runtest -q -P wine -T ../../.. -M gdiplus.dll -p gdiplus_test.exe.so font && touch font.ok font.c:759: Test failed: wrong face name MS Shell Dlg font.c:770: Test failed: wrong face name MS Shell Dlg make: *** [font.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wininet: Fix InternetGetConnectedStateEx[A|W] (try 2, resend)
by Alexandre Julliard May 9, 2014

May 9, 2014

Bruno Jesus <00cpxxx(a)gmail.com> writes: > @@ -1241,8 +1250,9 @@ BOOL WINAPI InternetGetConnectedStateExA(LPDWORD lpdwStatus, LPSTR lpszConnectio > dwReserved); > if (rc && lpwszConnectionName) > { > - WideCharToMultiByte(CP_ACP,0,lpwszConnectionName,-1,lpszConnectionName, > - dwNameLen, NULL, NULL); > + if (WideCharToMultiByte(CP_ACP,0,lpwszConnectionName,-1,lpszConnectionName, > + dwNameLen, NULL, NULL) == 0) > + *lpszConnectionName = '\0'; That doesn't seem to match what the W function does, and I don't see any tests for that case. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: comctl32: Tooltip AddTool needs to support TTTOOLINFOW_V3_SIZE
by Alexandre Julliard May 9, 2014

May 9, 2014

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -1037,8 +1037,9 @@ TOOLTIPS_AddToolT (TOOLTIPS_INFO *infoPtr, const TTTOOLINFOW *ti, BOOL isW) > infoPtr->hwndSelf, ti->hwnd, ti->uId, > (ti->uFlags & TTF_IDISHWND) ? " TTF_IDISHWND" : ""); > > - if (ti->cbSize >= TTTOOLINFOW_V2_SIZE && !ti->lpszText && isW) > - return FALSE; > + if ((ti->cbSize > TTTOOLINFOW_V2_SIZE && > + ti->cbSize != TTTOOLINFOW_V3_SIZE) && !ti->lpszText && isW) > + return FALSE; This doesn't make any sense. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ced401: add initial support
by Nikolay Sivov May 9, 2014

May 9, 2014

What does it have to do with Wine? Is it really some dll that Windows provides? > +/* > + * Use1432.dll > + * > + * Generated from/home/schloegl/.wine-1.7.17/drive_c/1401/utils/Use1432.dll by winedump. > + * > + * DO NOT SUBMIT GENERATED DLLS FOR INCLUSION INTO WINE! > + * > + */

3 3

Re: [PATCH 1/2] mshtml: Added IDispatchEx support to HTMLStyleSheetRulesCollection object.
by Marvin May 9, 2014

May 9, 2014

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=6935 Your paranoid android. === w2000pro (32 bit dom) === dom.c:6245: Test failed: unexpected guid {3050f2e5-98b5-11cf-bb82-00aa00bdce0b}

1 0

Re: [PATCH 2/2] oleacc: Add Client_accHitTest implementation
by Piotr Caban May 9, 2014

May 9, 2014

On 05/09/14 10:54, Piotr Caban wrote: > --- > dlls/oleacc/client.c | 22 +++++++++++++++++++-- > dlls/oleacc/tests/main.c | 50 > +++++++++++++++++++++++++++++++++++++++++++++--- > 2 files changed, 67 insertions(+), 5 deletions(-) > This patch is wrong. I'll send a fixed version.

1 0

Can I play with the Notepad code?
by Susan Cragin May 9, 2014

May 9, 2014

Hi. I want to make Notepad remember which encoding scheme you last used. Right now it defaults to ANSI Latin when opening a new file, and saves it that way too, unless you are careful. And, if I can, I want to make the following changes: (1) use ALT-Windows-key to move lines up and down. (2) use CTL-Windows-key to move paragraphs up and down. Lines and paragraphs are defined as follows: So this is a line of text. And this is line 2 of text. And this is line three of text. But they are all part of Paragraph 1. Paragraph 2 starts after a blank line is inserted. Sort of like Emacs. I've found the source code. I'm looking at where to put things. I can do it in lisp, and I've got help for C. http://source.winehq.org/source/programs/notepad/ Can I can I can I? It's going to take me a while, so don't hold your collective breath. Susan

3 2

Re: ws2_32: Return the correct error if SO_REUSEADDR is set in bind error
by Marvin May 9, 2014

May 9, 2014

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=6923 Your paranoid android. === w2008s64 (64 bit sock) === sock: unhandled exception c0000005 at 000007FEFFD49CD9

1 0

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 4)
by Marvin May 8, 2014

May 8, 2014

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=6914 Your paranoid android. === w2000pro (32 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma Bold === wxppro (32 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma Bold === w2008s64 (32 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma === w8 (32 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma === w2008s64 (64 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma

3 2

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 3)
by Alex Henrie May 8, 2014

May 8, 2014

2014-05-08 2:28 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: > Please add tests for the full name too. I thought I did: @@ -6031,6 +6042,8 @@ START_TEST(font) * I'd like to avoid them in this test. */ test_EnumFontFamilies("Arial Black", ANSI_CHARSET); + test_EnumFontFamilies("MS Shell Dlg", ANSI_CHARSET); + test_EnumFontFamilies("MS Shell Dlg 2", ANSI_CHARSET); test_EnumFontFamilies("Symbol", SYMBOL_CHARSET); if (is_truetype_font_installed("Arial Black") && (is_truetype_font_installed("Symbol") || is_truetype_font_installed("Wingdings"))) Is there a better way to test the full name? -Alex

2 1

Re: [PATCH] user32: Don't depend on HMENU being valid for popup menus
by Ken Thomases May 8, 2014

May 8, 2014

On May 6, 2014, at 9:28 AM, Andrew Eikum wrote: > +static HMENU MENU_GetHandle(POPUPMENU *menu) > +{ > + return menu ? menu->obj.handle : NULL; > +} Now that DestroyMenu() really destroys the handle, any use of the handle and thus this function has to be examined very carefully. The menu pointer may be valid and menu->obj.handle may have a value, but that value may no longer be a valid handle. > menuchar = SendMessageW( hwndOwner, WM_MENUCHAR, > - MAKEWPARAM( key, menu->wFlags ), (LPARAM)hmenu ); > + MAKEWPARAM( key, menu->wFlags ), (LPARAM)MENU_GetHandle(menu) ); So, here we're passing the menu handle in the WM_MENUCHAR message. If the menu has been destroyed, that's an invalid handle. We probably need tests to verify that that's what happens on Windows. That is, maybe it passes NULL. Or maybe the handle is still valid somehow. (The existing destroyed-submenu tests suggest that the handle isn't valid anymore, but maybe magic happens.) > - drawItem.hwndItem = (HWND)hmenu; > + drawItem.hwndItem = (HWND)MENU_GetHandle(menu); > - dis.hwndItem = (HWND)hmenu; > + dis.hwndItem = (HWND)MENU_GetHandle(menu); Same for the WM_DRAWITEM message. > @@ -1845,7 +1840,7 @@ static BOOL MENU_InitPopup( HWND hwndOwner, HMENU hmenu, UINT flags ) > menu->hWnd = CreateWindowExW( ex_style, (LPCWSTR)POPUPMENU_CLASS_ATOM, NULL, > WS_POPUP, 0, 0, 0, 0, > hwndOwner, 0, (HINSTANCE)GetWindowLongPtrW(hwndOwner, GWLP_HINSTANCE), > - (LPVOID)hmenu ); > + (LPVOID)MENU_GetHandle(menu) ); This one is interesting. This is a value that's just forwarded through to the WM_CREATE message via the lpCreateParams field of the CREATESTRUCTW pointed to by the lparam. It's then stored in the window extra space using SetWindowLongPtrW(). It's then looked up elsewhere in the window proc. Some cases in the window proc try to use the handle, which will fail if it's been destroyed. I think you can pass the menu pointer here instead of the menu handle. Likewise, I think you can store the menu pointer into the window extra space. You'd have to change the size of the extra space defined in the MENU_builtin_class struct. And you'd need to change all uses of Set/GetWindowLongPtrW() on the menu's window with 0 index. MENU_DrawPopupMenu() would need to be changed to take a menu pointer instead of a handle. A couple of those uses are for the MM_SETMENUHANDLE and MM_GETMENUHANDLE messages. I believe those are obsolete Wine-internal messages. They can probably be completely removed. For the MN_GETHMENU message, you can return MENU_GetHandle(GetWindowLongPtrW(hwnd, 0)), although, again, it would be good to test what Windows does for a destroyed-but-still-alive menu. The stored value is also used in GetMenuBarInfo(), so you'd want to rework that. > @@ -2023,18 +2018,17 @@ static void MENU_SelectItem( HWND hwndOwner, HMENU hmenu, UINT wIndex, > SendMessageW( hwndOwner, WM_MENUSELECT, MAKEWPARAM(pos, > ip->fType | ip->fState | > - (ptm->wFlags & MF_SYSMENU)), (LPARAM)topmenu); > + (topmenu->wFlags & MF_SYSMENU)), (LPARAM)topmenu); Here you missed a case. The lparam should be the menu handle, but topmenu is now a menu pointer. It might be good to also review all remaining uses of MENU_GetMenu(). Again, I think it should be possible to confine uses of menu handles just to the interfacing with client code. So, uses of MENU_GetMenu() at other places indicates that you're relying on the handle being valid. For example, the call to GetSubMenu() in MENU_FindItemByKey() or the calls to EnableMenuItem() in MENU_InitSysMenuPopup(). Unfortunately, that may involve creating a lot of helper functions. I didn't review further than this. Sorry that my suggestions are creating so much work. If you haven't already done so, you should probably get input from others (i.e. Alexandre) to see if my suggestions make sense. -Ken

2 3

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 3)
by Alexandre Julliard May 8, 2014

May 8, 2014

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -4741,6 +4741,17 @@ static void test_EnumFonts(void) > ret = EnumFontFamiliesA(hdc, NULL, enum_all_fonts_proc, (LPARAM)&lf); > ok(ret, "font Arial Italic Bold should not be enumerated\n"); > > + /* MS Shell Dlg and MS Shell Dlg 2 must exist */ > + ret = EnumFontFamiliesA(hdc, "MS Shell Dlg", enum_fonts_proc, (LPARAM)&lf); > + ok(!ret, "font MS Shell Dlg is not enumerated\n"); > + ret = strcmp(lf.lfFaceName, "MS Shell Dlg"); > + ok(!ret, "expected MS Shell Dlg got %s\n", lf.lfFaceName); > + > + ret = EnumFontFamiliesA(hdc, "MS Shell Dlg 2", enum_fonts_proc, (LPARAM)&lf); > + ok(!ret, "font MS Shell Dlg 2 is not enumerated\n"); > + ret = strcmp(lf.lfFaceName, "MS Shell Dlg 2"); > + ok(!ret, "expected MS Shell Dlg 2 got %s\n", lf.lfFaceName); Please add tests for the full name too. -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] comctl32/tests: Fix propsheet and listview tests which depend on being in foreground.
by Bernhard Übelacker May 7, 2014

May 7, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, the comctl32:propsheet and comctl32:listview are regularly failing on the Windows testbots. This is visible in these test runs with an "empty" patch to these tests: https://testbot.winehq.org/JobDetails.pl?Key=6828 https://testbot.winehq.org/JobDetails.pl?Key=6829 This is because windows forbids them to get into foreground. This patch is working around this by simulating an ALT key press and then calling SetForegroundWindow. These are the results with an earlier revision of this patch: https://testbot.winehq.org/JobDetails.pl?Key=6832 https://testbot.winehq.org/JobDetails.pl?Key=6833 Kind regards, Bernhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTaVcbAAoJEOlvol+DpkHmDb8IAKD/G0FWgDP8v44SpfqhHY2W 0g8fCzJY6/GhjweV6Mybwqx/YmeBwmc8qvRuHshDUm8WWZbI6yH14LEGz5GwbccI XH/kJgiqqaJH8AiCQM6chF+JBAz3URf9SsAsuDKBjNmpHSMkPAhC/JXecI43GMyX E2AoggKh6DXtEq3yOnGJIRSMAhGPJGYP1Vny5+rq6+rvg2DpNdGI11Xk4oCVgJvc cYCk3yVNKquv4JW8vg80ZJboglDff7omTBLJdF5Nkk5xSGY4iV7amp9CChEJN33N lsohSyvIXeDWegeCWaXGNGhTPXwuTb56tQG22uR7IxJscT8/cXsDQ4jYvuTHoXM= =hTJp -----END PGP SIGNATURE-----

2 2

Re: shell32: Use SW_HIDE with ShellExecuteA in tests.
by Marvin May 7, 2014

May 7, 2014

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=6894 Your paranoid android. === w2000pro (32 bit shlexec) === shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 === wxppro (32 bit shlexec) === shlexec.c:1220: Test failed: expected 1 args, got 4 === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1541: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1573: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1541: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1573: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\wtDFC3.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\wtDFC3.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2111: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\wtDFC3.tmp" Exec") succeeded: rc=42

1 0

Re: [PATCH 1/2] include: Added atlcom.h
by Vincent Povirk May 7, 2014

May 7, 2014

I think you should add this new header to include/Makefile.in.

2 1

Re: [PATCH] user32: Don't depend on HMENU being valid for popup menus
by Vincent Povirk May 7, 2014

May 7, 2014

if (menu->FocusedItem != NO_SELECTED_ITEM) { + ERR("focused: %u, nitms: 0x%x\n", + menu->FocusedItem, + menu->nItems); menu->items[menu->FocusedItem].fState &= ~(MF_HILITE|MF_MOUSESELECT); menu->FocusedItem = NO_SELECTED_ITEM; } Is this stray debugging code or a real error condition? - * Return the handle of the submenu, or hmenu if no submenu to display. + * Return the handle of the submenu, or menu if no submenu to display. Still slightly inaccurate as the returned submenu is no longer a handle. @@ -4787,24 +4770,29 @@ static BOOL SetMenuItemInfo_common(MENUITEM * menu, menu->wID = lpmii->wID; if (lpmii->fMask & MIIM_SUBMENU) { - menu->hSubMenu = lpmii->hSubMenu; - if (menu->hSubMenu) { - POPUPMENU *subMenu = MENU_GetMenu(menu->hSubMenu); - if (subMenu) { - if( MENU_depth( subMenu, 0) > MAXMENUDEPTH) { + if(menu->fType & MF_POPUP){ + if(menu->submenu) + InterlockedDecrement(&menu->submenu->refcount); + } How do we know this isn't the last reference? I'm not sure this frees submenus correctly. If I create a popup menu and add a submenu to it, that submenu has two references (one because it has an HMENU and one because it is a submenu). DestroyMenu should recursively destroy submenus. So it seems to me, destroying a menu needs to destroy the handles to submenus (if they have one) and release its references to them.

2 1

Re: [2/2] dpnet: Implement IDirectPlay8Client Initialize (try 2)
by Stefan Dösinger May 7, 2014

May 7, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-07 03:39, schrieb Alistair Leslie-Hughes: > Hi, Just a rebase. This looks ok to me. It depends on the test added by patch 1 though, so it'll have to wait until the test is sorted out. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTajllAAoJEN0/YqbEcdMwiTYP/icYQO8oZyCNCRTwoJ3Vdsbl mBbpWrXI2pT0ASEj30+WdJ7a7iJvZXc8tVSvvV8UtbQPLBRGI5Y9asJi9rKpNCLb ksP5vXKmsSxUewGGbX+rtYqRS/hL67NSTai1mb/hxkqGmmJqLbchzM3NP+GX4fvv e9w9p/DpfcOXGCrAtvuKSCzFPDwn60IVIIZVXTCnEs6KR3Vvq+NGnxmV9kwtEjCj idZI0cgPXwR/R0ybJdhFJpU3GHiyNWPAhI6kZcXNCv+kP90A6aDJ8rgd3SvcNEyt oxROFT7PsHUJmC72xixpscGMM5DLDijffVmtooTIgGHsM2iC8Yi4B5s+U77P0sBJ 3LGfYH68AIZtAA187A21WM+WLOtWV5vjihHIHxEO9UFmdI1G88f/9bG0n5YRlzkf Rh4xevGBw7/oks3q08uEMY2EwQdCL/NSx1HWNBtbohBKClZv+373cXEY9+lXPbl2 vA6P0KCUHf/JRM9v2b19UG7vffklCoymroQ8i4TD8qksBHdGq640MUqqyQaMfuu4 ZBrJH3Q+VTe79fcPTG4AyQrEUb1Xy+ohNIY5gN4e8UuvydEpcIId5a0Isu04u9Xr 02tjdraySJaW7ELq5+NoegH30O2Q8aJzPkY7aS2lWe+Kt8lgAUG+KKQXF4fKoeSH x6wbbtc5ojYjXXS91b8S =59Gh -----END PGP SIGNATURE-----

1 0

Re: [1/2] dpnet: Add IDirectPlay8Client tests (try 2)
by Stefan Dösinger May 7, 2014

May 7, 2014

Am 2014-05-07 03:39, schrieb Alistair Leslie-Hughes: > Hi, > Changed test_init_dp to return a boolean. Sorry, I was a bit slow with replying to your previous mail. Is there anything that prevents you from having a helper function that creates a new client object for each test? If you share one client object and the tests modify the state, then the tests end up depending on each other. We had a similar situation in the d3d8/9 visual tests (and still have in ddraw:visual), and it leads to hard to debug test failures. If the client object takes too long to create (I'd say > 0.25 seconds) then that's a reason to keep the client around. Otherwise creating a fresh one for each test and destroying it afterwards will really help you in the long run. Somewhat related: > +static BOOL test_init_dp(void) > ... > + hr = CoInitialize(0); > ... > +static void test_cleanup_dp(void) > ... > + CoUninitialize(); > +} I'd move that to the test's main function. (And no, I don't think there's a need to call CoInitialize / CoUninitialize more than once.) Cheers, Stefan

1 0

Re: dplayx: Initial msgtid variable
by Stefan Dösinger May 7, 2014

May 7, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-07 04:08, schrieb Alistair Leslie-Hughes: > + obj->msgtid = 0; > obj->ref = 0; > obj->refA = 0; > obj->ref2 = 0; IMO it would be better to use HEAP_ZERO_MEMORY in the HeapAlloc call a few lines above. This problem will keep coming back when more members are added. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTajXtAAoJEN0/YqbEcdMwF6kP/iJveqvV58YLeyd2bpJKOjim H2dF+Cll8hAayzziokzOhgf6BoMikhnwqQHtXSgZKuGjQl7oF6sy2qCr5wvfl13V bC9Me4DbXE9PEwT2ArEDiGkejg0G7KQ8qFVo6vFNIaRBEt0mgH0bFUntGPtZZgbV 9qT3KgoNGqOw4iI8rzh4ATabu9NizkI+b2UxMY+9lEf/RSur9pnX/XQhjRIvzZKS YT4exS5bdjZXcSN9aEPax9f+VmYKRyVBvo6O5PfdkqQNarFMc5bw6Utkab/0VbQb j5IM5dRdevTsqx1ZdqzAxlDCHEtRlQWR07A0unsg6JuCX8Rwn+lAh78NTozHWwIV qG31CoHV37WJggleZc2Rk5oSatlAVARwX/f2qJ9GA3fv5muJkpThc8HcEvTN1e/V zSmWBLljyF0I6a6a4P8k2Ch9ZmDnmDvIaGaJshnETt+ypgK2T2QI35pb2bh/pGmC ltWvEwRpbATmftl62Bu4511Afo8AGcXEa83SvfukPmHaAtiJ2TNI9/c1vCP/Pvke TeARP1gtvSh3Q7pwcXPIaAry/RLEYmMPJDAoKRkc+FM2O/4gNiUDUBIDeEpKJaB1 BM2HE0/TCrrIEkfE1RI9JseX79uylagiStAIUgKkqMfJxrXA50VX0bLnQq/qtayD vRfIAuYYb3hvpNll1gIT =rA1r -----END PGP SIGNATURE-----

1 0

Re: [PATCH 2/2] gdi32: Report unsubstituted font face names.
by Alexandre Julliard May 7, 2014

May 7, 2014

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -5765,6 +5765,11 @@ static BOOL enum_face_charsets(const Family *family, Face *face, struct enum_cha > else > strcpyW(elf.elfFullName, family->FamilyName); > } > + /* Make sure that MS Shell Dlg says "MS Shell Dlg" and not "Tahoma" */ > + if (unsubstituted_face_name) > + { > + lstrcpynW(elf.elfLogFont.lfFaceName, unsubstituted_face_name, LF_FACESIZE); > + } So what happens to the full name in that case? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: Make Treeview Notify the parent on a return key press
by Nikolay Sivov May 7, 2014

May 7, 2014

Quick testing doesn't show this notification, so I'm not convinced it's a right change. Please add a test.

1 0

Re: [1/2] dpnet: Add IDirectPlay8Client tests
by Stefan Dösinger May 7, 2014

May 7, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-05 08:46, schrieb Alistair Leslie-Hughes: > +static IDirectPlay8Client* client = NULL; > ... > + hr = CoCreateInstance(&CLSID_DirectPlay8Client, NULL, CLSCTX_INPROC_SERVER, &IID_IDirectPlay8Client, (void **)&client); > + ok(hr == S_OK, "CoCreateInstance failed with 0x%x\n", hr); > ... > + hr = IDirectPlay8Client_Close(client, 0); > + ok(hr == S_OK, "IDirectPlay8Client_Close failed with %x\n", hr); Please avoid such dependencies between different tests. If creating and releasing the client is something that every test has to do you can add helper functions for this task. > + for (i=0;i<items;i++) > + { > + trace("Found Service Provider: %s\n", wine_dbgstr_w(serv_prov_info->pwszName)); > + trace("Found guid: %s\n", wine_dbgstr_guid(&serv_prov_info->guid)); > + > + serv_prov_info++; > + } > + > + serv_prov_info -= items; /* set pointer back */ > + ok(HeapFree(GetProcessHeap(), 0, serv_prov_info), "Failed freeing server provider info\n"); You could use serv_prov_info as an array instead of doing the pointer arithmentic twice. E.g. trace("Found guid: %s\n", wine_dbgstr_guid(&serv_prov_info[i].guid)); > + hr = IDirectPlay8Client_EnumHosts(client, &appdesc, host, local, NULL, 0, INFINITE, 0, INFINITE, NULL, &async, 0); > + todo_wine ok(hr == DPNSUCCESS_PENDING, "IDirectPlay8Client_EnumServiceProviders failed with 0x%08x\n", hr); > + todo_wine ok(async, "No Handle returned\n"); > + > + hr = IDirectPlay8Client_CancelAsyncOperation(client, async, 0); > + ok(hr == S_OK, "IDirectPlay8Client_CancelAsyncOperation failed with 0x%08x\n", hr); Are you sure that this always returns DPNSUCCESS_PENDING? Couldn't it also return a result instantly? Overall I don't see the point in this test at the moment. As it is now it doesn't say much. This is just an opinion though, I'll leave the decision up to you. > + todo_wine ok(caps.dwMaxEnumPayloadSize == 983, "expected 983, got %d\n", caps.dwMaxEnumPayloadSize); Out of curiosity, do you have any idea where this value comes from? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTaTX9AAoJEN0/YqbEcdMwB6AP/jd1T0OLGPXO3pgF9boIHp6i yQTDCgf7Wq8zKJuxDZtOzfGzVbYqVeN8TDx9c3oD3RSru9bBIJ9Bjeu3hKqvL2Qo 4JRJZyQn665RymbKo/S9ivXBHmd9cuh4tfdTxHU7n0nVXICCNDniBxfAwr2HkkeB iyvMe8Ga3SPVCL+33XZAniPPFnfnEYkaqU42CTUUK2hlYyzb4bScihgdrUqoX36k RtvK2UKxOBT5E9nd0VIS/b8fF4uXFIzD7M6oEuzLObXL6XGsRNl2mtMpZ0ztlFpy PIF1AbFyK4tQA3obsTSWUVJVlQFLCurvqg2klLogewdyVy4wE4h0/oOCRCPhuVbR baJf0by5ZC4Os4YIZIzN0OOy0N3A+bMQI1VdvQTuMPwF+dYk268p0t77SN6F2gfa ts9MyQxYrhrao3+oI4Hw2ouYUxIYj+WxNSVCb01TjUrMVOMAeD1Ksttbk1g5ADdZ +DbV9CWuOhISjXh5OT8ToH0FxrImrby3FDyX/UFf2KPzwzKoX2kNyjtSHguPIOko 3jOnuVh8HsD7jX0sQqMMkdwsESdfTCwIHXLhbE4C08yxsu8ByNhFHme3oX4EcyPf oHRUA+w8Yr8rr+wSU1fpPEb79ZnMn5xfR7xZQKzX5af0ICta6k3UjtSeAuE6P1xX HFJrTsoKGibhnm6z2wZH =sF7u -----END PGP SIGNATURE-----

2 1

Re: [PATCH 2/2] gdi32: Report unsubstituted font face names.
by Marvin May 7, 2014

May 7, 2014

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=6860 Your paranoid android. === wvistau64 (32 bit font) === The test timed out

1 0

Testbot returning 500 - Internal server error message
by Bruno Jesus May 7, 2014

May 7, 2014

Hi all. While trying to upload a test in the command line parameter input the server returned a 500 error. Then I went back to the index and it's working but clicking on any test key will result in the error message as well. This may be an intermittent failure and I'm reporting it just to check because I don't recall any scheduled maintenance emails. Example: https://newtestbot.winehq.org/JobDetails.pl?Key=6858 Best regards, Bruno

2 1

Re: setupapi: SetupDiGetClassDevsExW should ignore DIGCF_ALLCLASSES if class set
by Nikolay Sivov May 6, 2014

May 6, 2014

Is it possible to add a test for that?

2 1

Wine talk at Linuxwochen Österreich
by Stefan Dösinger May 6, 2014

May 6, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I will give a talk about Wine gaming at Linuxwochen Österreich later this week: When: Friday, May 9th, 15:00 Where: FH Technikum Wien, HS 2.01, Vienna See http://www.linuxwochen.at/ and https://cfp.linuxwochen.at/en/LWW14/public/events/154 for more details Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTaQLIAAoJEN0/YqbEcdMwscQP/2OuAs1Z2MSrYNlXH4CJngDQ 0rqb4aCf32Yy5iVJ6XRbIkfPxrA+CpeX1fwCPpx1rGjJM9djQ1RnbQDb1dafCbYg 4qHJeMooZ9zbqB/6rUV9q2xk8E3Bnhi5RptBnwtEljUWCOTbCbTtevr5BjLbM/Dk Si4S2gFSkGCHyNFupxaIFGOseew3zLNSkFvqV4Pr/eX+j0GIT78t6CyqtFB/Vpvs nMBptteZSlwmvJ5Z9bX7ruUus9+Az2Q17UV4c0tN+x5xsLD6QpoJWocFyO/7SYy9 HTa6QWwDF+AWOiCkP3TdPz1U/bNcEzSEGpDcFaQNLABGFhVm3rpgsqoBwJln2BDH Ig0+pG7jQSaYm1qK6Y5Sx58rVTDXizWmr2QfGkqh3ZmaOBBXTqudtPbZ5lrCmk50 xtbwqymo/vLXaU5FbgY83VvDip3oCBwny+E8R+O/rL20h5bkLNnn5doU3Kt2GTKU c3eohbg/qAlBzxG0UrtSQdiNYeItABaFYvhAkg11g8y0yjiZYdiGHMz4cgUMaVoe qDR0DLLEFGqTqYvhs5+fiK09EjABSpTVSnuGwsX0zRphgLZqsBWvg/O7G3pCwZ4Y MamqhvKBXhS6sQVjyDujuqNvSon3IEcomPz/BazbzZjuqfMU8IdP2lk7CizfvBvM dX/IsNZR6MKxhDVHtfEB =F/a5 -----END PGP SIGNATURE-----

1 0

Re: setupapi: SetupDiGetClassDevsExW should ignore DIGCF_ALLCLASSES if class set
by Henri Verbeet May 6, 2014

May 6, 2014

On 6 May 2014 16:05, Mark Harmstone <hellas(a)burntcomma.com> wrote: > + if (flags & DIGCF_ALLCLASSES && class) > + flags -= DIGCF_ALLCLASSES; This works, of course, but the usual way to do that kind of thing would be "if (class) flags &= ~DIGCF_ALLCLASSES;"

1 0

Re: [PATCH] gdi32: Report unsubstituted font face names.
by Alexandre Julliard May 6, 2014

May 6, 2014

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -5805,12 +5810,13 @@ static BOOL freetype_EnumFonts( PHYSDEV dev, LPLOGFONTW plf, FONTENUMPROCW proc, > GDI_CheckNotLock(); > EnterCriticalSection( &freetype_cs ); > if(plf->lfFaceName[0]) { > - FontSubst *psub; > - psub = get_font_subst(&font_subst_list, plf->lfFaceName, plf->lfCharSet); > + FontSubst *psub = get_font_subst(&font_subst_list, plf->lfFaceName, plf->lfCharSet); > + WCHAR *unsubstitutedFaceName = NULL; > > if(psub) { > TRACE("substituting %s -> %s\n", debugstr_w(plf->lfFaceName), > debugstr_w(psub->to.name)); > + unsubstitutedFaceName = plf->lfFaceName; > lf = *plf; > strcpyW(lf.lfFaceName, psub->to.name); > plf = &lf; This could be seriously simplified then. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/5] server: Add socket-side support for the interface change notification object (resend).
by Alexandre Julliard May 6, 2014

May 6, 2014

"Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > This patch adds an async queue, list object, and interface change > object to the socket object in order to support interface change > notification objects (fully implemented in part 4). A significant > deviation from previous versions of this patch is that errors are > passed up from each routine so that it is easier to ensure that all > possible errors are properly reported. I believe that this is the > server style comment AJ had on IRC, but some clarification would be > appreciated. No, that's not how error handling works in the server. The functions that fail set last error and then you propagate that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/5] server: Add delayed processing for socket-specific ioctl() (resend).
by Alexandre Julliard May 6, 2014

May 6, 2014

"Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > @@ -523,17 +523,32 @@ obj_handle_t sock_ioctl( struct fd *fd, ioctl_code_t code, const async_data_t *a > int blocking, const void *data, data_size_t size ) > { > struct sock *sock = get_fd_user( fd ); > + obj_handle_t wait_handle = 0; > + async_data_t new_data; > + int error; > > assert( sock->obj.ops == &sock_ops ); > > + if (blocking) > + { > + if (!(wait_handle = alloc_wait_event( current->process ))) return 0; > + new_data = *async_data; > + new_data.event = wait_handle; > + async_data = &new_data; > + } > switch(code) > { > case WS_SIO_ADDRESS_LIST_CHANGE: > /* intentional fallthrough, not yet supported */ > default: > - set_error( STATUS_NOT_SUPPORTED ); > - return 0; > + error = STATUS_NOT_SUPPORTED; > + break; > } > + set_error( error ); > + if (error == STATUS_PENDING) > + return wait_handle; > + close_handle( current->process, wait_handle ); > + return 0; You should be doing that only as needed. It doesn't make sense to allocate a handle for unknown ioctls. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] winex11.drv: copy and paste files to/from X11 apps (try 2)
by Alexandre Julliard May 6, 2014

May 6, 2014

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > /************************************************************************** > + * X11DRV_CLIPBOARD_ExportHDROP > + * > + * Export CF_HDROP format to text/uri-list. > + */ > +static HANDLE X11DRV_CLIPBOARD_ExportHDROP(Display *display, Window requestor, Atom aTarget, > + Atom rprop, LPWINE_CLIPDATA lpdata, LPDWORD lpBytes) > +{ > + HDROP hDrop; > + UINT i; > + UINT numFiles; > + UINT totalSize = 0; > + HGLOBAL hClipData = NULL; > + char *text_uri_list = NULL; > + char *next; > + BOOLEAN succeeded = FALSE; > + > + *lpBytes = 0; > + > + if (!X11DRV_CLIPBOARD_RenderFormat(display, lpdata)) > + { > + ERR("Failed to export %04x format\n", lpdata->wFormatID); > + return 0; > + } > + > + hDrop = (HDROP) lpdata->hData; > + numFiles = DragQueryFileW(hDrop, 0xFFFFFFFF, NULL, 0); > + > + for (i = 0; i < numFiles; i++) > + { > + UINT dosFilenameSize; > + WCHAR *dosFilename; > + succeeded = FALSE; > + dosFilenameSize = 1 + DragQueryFileW(hDrop, i, NULL, 0); > + dosFilename = HeapAlloc(GetProcessHeap(), 0, dosFilenameSize*sizeof(WCHAR)); > + if (dosFilename) > + { > + char *unixFilename; > + DragQueryFileW(hDrop, i, dosFilename, dosFilenameSize); > + unixFilename = wine_get_unix_file_name(dosFilename); > + if (unixFilename) > + { > + totalSize += 8 + /* file:/// */ > + 3*(lstrlenA(unixFilename) - 1); /* "%xy" per char except first '/' */ > + succeeded = TRUE; > + HeapFree(GetProcessHeap(), 0, unixFilename); > + } > + HeapFree(GetProcessHeap(), 0, dosFilename); > + } > + if (!succeeded) > + { > + ERR("out of memory\n"); > + goto end; > + } > + } > + totalSize += 2 * numFiles; /* "\r\n" */ > + hClipData = GlobalAlloc(GMEM_MOVEABLE | GMEM_DDESHARE, totalSize); > + if (hClipData == NULL) > + { > + ERR("out of memory\n"); > + succeeded = FALSE; > + goto end; > + } > + text_uri_list = (char*) GlobalLock(hClipData); > + next = text_uri_list; > + for (i = 0; i < numFiles; i++) > + { > + UINT dosFilenameSize; > + WCHAR *dosFilename; > + succeeded = FALSE; > + dosFilenameSize = 1 + DragQueryFileW(hDrop, i, NULL, 0); > + dosFilename = HeapAlloc(GetProcessHeap(), 0, dosFilenameSize*sizeof(WCHAR)); > + if (dosFilename) > + { > + char *unixFilename; > + DragQueryFileW(hDrop, i, dosFilename, dosFilenameSize); > + unixFilename = wine_get_unix_file_name(dosFilename); > + if (unixFilename) > + { > + static const char *hex_table = "0123456789abcdef"; > + UINT u; > + *next++ = 'f'; > + *next++ = 'i'; > + *next++ = 'l'; > + *next++ = 'e'; > + *next++ = ':'; > + *next++ = '/'; > + *next++ = '/'; > + *next++ = '/'; > + /* URL encode everything - unnecessary, but easier/lighter than linking in shlwapi, and can't hurt */ > + for (u = 1; unixFilename[u]; u++) { > + *next++ = '%'; > + *next++ = hex_table[unixFilename[u] >> 4]; > + *next++ = hex_table[unixFilename[u] & 0xf]; > + } > + *next++ = '\r'; > + *next++ = '\n'; > + succeeded = TRUE; > + HeapFree(GetProcessHeap(), 0, unixFilename); > + } > + HeapFree(GetProcessHeap(), 0, dosFilename); > + } > + if (!succeeded) > + { > + ERR("out of memory\n"); > + goto end; > + } > + } > + > +end: > + if (succeeded) > + { > + GlobalUnlock(hClipData); > + *lpBytes = GlobalSize(hClipData); > + return hClipData; > + } > + else > + { > + if (text_uri_list) > + GlobalUnlock(hClipData); > + GlobalFree(hClipData); > + *lpBytes = 0; > + return 0; > + } > +} That's unnecessarily complicated and inefficient. You don't need to retrieve the file name 4 times, or to convert every filename to Unix twice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wined3d: Add a registry setting, DisabledExtensions, to disable the use of OpenGL and WGL extensions.
by Henri Verbeet May 6, 2014

May 6, 2014

On 6 May 2014 10:44, Ken Thomases <ken(a)codeweavers.com> wrote: > I'm inclined to say we don't really need this, but I'll leave that up to Alexandre. > + /* Second pass at disabling extensions. This (re)disables extensions that may > + be implied by the GL version or other extensions. */ Is this really a problem in practice? > + if (wined3d_settings.disabled_extensions) > + { > + parse_extension_string(gl_info, wined3d_settings.disabled_extensions, gl_extension_map, > + sizeof(gl_extension_map) / sizeof(*gl_extension_map), FALSE); > + if (WGL_Extensions) > + parse_extension_string(gl_info, wined3d_settings.disabled_extensions, wgl_extension_map, > + sizeof(wgl_extension_map) / sizeof(*wgl_extension_map), FALSE); > + } It may be nicer to just make parse_extension_string() handle a NULL "extensions" pointer, and skip all the conditionals here. > - gl_vendor = wined3d_guess_gl_vendor(gl_info, gl_vendor_str, gl_renderer_str); > - card_vendor = wined3d_guess_card_vendor(gl_vendor_str, gl_renderer_str); > - TRACE("Found GL_VENDOR (%s)->(0x%04x/0x%04x).\n", debugstr_a(gl_vendor_str), gl_vendor, card_vendor); > - > device = wined3d_guess_card(gl_info, gl_renderer_str, &gl_vendor, &card_vendor); > TRACE("Found (fake) card: 0x%x (vendor id), 0x%x (device id).\n", card_vendor, device); I guess this was broken up because of the extension checks in wined3d_guess_gl_vendor(). Is that really justified? Conceptually, if we really want the DisabledExtensions functionality in wined3d, I think it should behave like filtering the extension strings, as opposed to being some kind of generic way to disable specific wined3d code paths, but not others that depend on the same extensions.

1 0

Re: winex11: Silence a noisy winediag ERR in xrandr12_init_modes
by Henri Verbeet May 6, 2014

May 6, 2014

On 5 May 2014 22:53, André Hentschel <nerv(a)dawncrow.de> wrote: > - ERR_(winediag)("Broken NVIDIA RandR detected, falling back to RandR 1.0. " > - "Please consider using the Nouveau driver instead.\n"); > + static int once; > + if (!once++) ERR_(winediag)("Broken NVIDIA RandR detected, falling back to RandR 1.0. " > + "Please consider using the Nouveau driver instead.\n"); Does this actually help? We really shouldn't be calling X11DRV_XRandR_Init() much more often than once per process.

1 0

Re: [PATCH 5/5] ws2_32: Add an interactive test for interface change notifications (resend).
by Marvin May 6, 2014

May 6, 2014

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=6836 Your paranoid android. === wvistau64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000

1 0

Working on ATL, more real world test case needed
by Qian Hong May 5, 2014

May 5, 2014

Hi all, I'm working on atl80/atl100 recently, particularly on AtlAxCreateControl{,Lic}{,Ex}, AtlAxAttachControl, AtlIPersistStreamInit_{Load,Save}, AtlIPersistPropertyBag_{Load,Save} The motivation to work on AtlAxCreateControl* and AtlAxAttachControl* is for AliWangwang [1]; the motivation to work on AtlIPersistPropertyBag_Load is for QQ[2]. I've already have solution for those apps, however, I have some trouble on them: 1. I have more and more test case for ATL, and found more and more difference behaviors between native AtlAxCreateControl/AtlAxAttachControl and buitin's, some of native behavior looks unreasonable to me so I doubt if we want to follow that. It would be nice to test more real world application before deciding what to do next. 2. I found the (seems) undocumented ATL_PROPMAP_ENTRY struct is different between atl80 and atl100 from my black box testing result. I know QQ use atl80.AtlIPersistPropertyBag_Load which receive a ATL_PROPMAP_ENTRY input parameter, but I don't have any real world app to test the atl100 version or any other version. I'm interesting to know more apps depends on any version (atl/atl80/atl90/atl100/atl110) of AtlIPersistStreamInit_*/AtlIPersistPropertyBag_* to see how they work. I really appreciate a lot if anyone can help report ATL related bugs and CC me, maybe someone remembers some Apps have bugs on atl* but haven't report to bugzilla yet - I don't know any good way to find real world test case, that's why I'm here :) I'd really be happy to get some surprise smart way to do it! In short, any ATL related bugs are welcome, particularly on AtlAxCreateControl*/AtlAxAttachControl/AtlIPersistPropertyBag*/AtlIPersistStreamInit* if you know that's the culprit, but never mind for other ATL related bugs. Note: if an app bugs can be workaround by winetricks -q vcrun2005 / winetricks -q vcrun2008 / winetricks -q 2010, even with msvc*.dll override set to builtin, only leave native atl*.dll, then it is possible a ATL bug. Here are a few known ATL bugs: http://bugs.winehq.org/buglist.cgi?cmdtype=runnamed&list_id=147507&namedcmd… Thank you a lot for any help! [1] http://bugs.winehq.org/show_bug.cgi?id=33724 [2] http://bugs.winehq.org/show_bug.cgi?id=33822 -- Regards, Qian Hong - http://www.winehq.org

2 4

Re: [PATCH 2/5] wined3d: Validate and handle query size parameter. (try 2)
by Henri Verbeet May 5, 2014

May 5, 2014

On 2 May 2014 16:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static void fill_query_data(void *out, unsigned int out_size, const void *result, unsigned int result_size) > +{ > + unsigned int size = min(out_size, result_size); > + > + memcpy(out, result, size); > +} The extra "size" variable is perhaps a bit superfluous. Not sure if I care.

1 0

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 2)
by Henri Verbeet May 5, 2014

May 5, 2014

On 2 May 2014 16:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + memset(&data, 0xff, sizeof(data)); This is a bit of an odd way to write "data = ~0u;". > + ok(*(WORD *)&data == 1 || broken(*(WORD *)&data != 1), > + "Occlusion query returned an unexpected result (0x%.8x).\n", data); > + todo_wine ok(*((WORD *)&data + 1) == 0xffff, > + "data was modified outside of the expected size (0x%.8x).\n", data); I think this is a bit awkward, perhaps it makes more sense the declare "data" as something like "WORD data[4];". Also, can this really ever return 0 for the query data? Would it help to draw a different primitive type, instead of a tiny point? (Because, well, point rasterization is complicated.)

1 0

Re: [PATCH] setupapi: Implement a binary compatible string table
by Marvin May 4, 2014

May 4, 2014

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=6812 Your paranoid android. === wvistau64 (64 bit stringtable) === stringtable.c:351: Test failed: got 128 stringtable.c:352: Test failed: got 0, thread lcid 1401 === w2008s64 (64 bit stringtable) === stringtable.c:351: Test failed: got 124 stringtable.c:352: Test failed: got 0, thread lcid 409

1 0

Use WINE API from ELF application.
by John Found May 4, 2014

May 4, 2014

Is it possible to use the WINE functionality from inside regular ELF application. For example starting and debugging Windows application. Creating windows, etc. -- asm32.info <johnfound(a)asm32.info>

2 1

Re: Failing tests on testbots because of missing focus
by Francois Gouget May 4, 2014

May 4, 2014

On Sat, 3 May 2014, Bernhard Übelacker wrote: [...] > In my opinion the reason is that these tests get executed from an > application which does not have the current input focus. On the WineTestBot the tests are being run from a console window which is iconized. On the fg-* VMs the mechanism is similar, though it's possible the command window is no iconized. [...] > Also because the newtb* machines showed this error only sometimes (at > least before the testbot changes lately) probably some other tests are > doing something to change focus situation, or are running long enough > and windows is changing its focus policy there. Some tests cause Windows to be opened and stay around. In particular I remember that WineTest.exe typically leaves an Explorer window behind, most likely triggered by a shell32 or shlwapi test. The rpcrt4 tests and others also leave firewall windows behind, asking whether to unblock various ports (these tests don't actually need the ports to be unblocked and thus are not impacted by the questions being unanswered [1]). So based on your description it's quite likely that one of these windows is the one with the focus. [...] > Because of this affecting more tests (and probably this fix could also affect > tests running after this one), I am not sure if this is the right way to fix it: > > - should the test rely on being started from an application which > had focus? (e.g. change testbot to start the tests by an cmd window > which has guaranteed focus) Tests that need focus for one of their window should set up the focus themselves [2]. More generally tests should not rely on anyone else setting things up for them as that would make them too brittle and hard for developers to run 'correctly'. [1] I assume these tests bind their socket to any address and that's why they get these firewall questions. But in fact they only get connections from localhost which is unaffected by the firewall so it's possible they could avoid these questions by only binding to localhost. It's not clear that it's worth the trouble though. [2] I'll leave checking the proposed code to do so to other, more capable, hands (or eyes, braaaains, as the case may be). -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [PATCH] vbscript: Fixed CBool(try 3)
by Piotr Caban May 3, 2014

May 3, 2014

On 05/02/14 06:22, Shuai Meng wrote: > testbot:https://newtestbot.winehq.org/JobDetails.pl?Key=6731 > > Changelog: > added more tests on object; > changed the implemention of some tests that caused "Err.number = 0" > rearranged the order of tests > --- > dlls/vbscript/global.c | 41 ++++++++++------------------------- > dlls/vbscript/tests/api.vbs | 53 > +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 65 insertions(+), 29 deletions(-) > The tests are failing on wine on polish locale: LC_ALL=pl_PL make test ../../../tools/runtest -q -P wine -T ../../.. -M vbscript.dll -p vbscript_test.exe.so run && touch run.ok fixme:thread:GetThreadUILanguage : stub, returning default language. run.c:2102: Tests skipped: Skipping some tests in non-English locale fixme:vbscript:parse_script parser failed around L"<!--" fixme:vbscript:do_icall L"y" not found fixme:vbscript:DispatchEx_InvokeEx no letter/setter run.c:1917: Test failed: expected global_success_d run.c:1918: Test failed: expected global_success_i run.c:1920: Test failed: parse_script failed: 800a000d fixme:vbscript:ClassFactory_QueryInterface (0x7e2462ec)->({342d1ea0-ae25-11d1-89c5-006008c3fbfc} 0x33f7b0) fixme:vbscript:RegExp2_QueryInterface (0x130a88)->({fc4801a3-2ba9-11cf-a229-00aa003d7352} 0x33f74c) fixme:vbscript:interp_enumnext uninitialized fixme:vbscript:interp_newenum Unsupported for {VT_EMPTY} fixme:vbscript:interp_enumnext uninitialized fixme:vbscript:show_msgbox failed: 80004005 fixme:vbscript:show_msgbox blocked make: *** [run.ok] B³±d 3

2 6

Re: [PATCH] vbscript: Fixed CBool(try 4)
by Marvin May 3, 2014

May 3, 2014

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=6774 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: dpnet/tests: Add a trailing '\n' to an ok() call.
by Marvin May 2, 2014

May 2, 2014

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

1 0

Building Wine conformance tests on Windows
by Albert Szilvasy May 2, 2014

May 2, 2014

Hello there, It appears that it is not possible to build the Wine conformance tests on Windows as described here: http://www.winehq.org/site/docs/winedev-guide/testing-windows In particular, when I try to build against the latest Windows SDK I get all sorts of errors. Take for example, kernel32/tests/loader.c. It refers to IMAGE_FILE_MACHINE_ARM64. This symbol does not exist in winnt.h from Microsoft but does exist in the wine version. How do people build the conformance tests? Cross compile on Linux? Thanks, albert

6 7

Re: ole32/tests: Add a trailing '\n' to an ok() call.
by Marvin May 2, 2014

May 2, 2014

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

1 0

Re: [PATCH] ddraw/tests: Add a test for getdc palette handling (try 3).
by Marvin May 2, 2014

May 2, 2014

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=6752 Your paranoid android. === wvistau64 (64 bit ddraw2) === ddraw2.c:5645: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw1) === ddraw1.c:4569: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw7) === ddraw7.c:6369: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw4) === ddraw4.c:6546: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 6: Got unexpected pitch 252, expected 256.

1 0

Re: [PATCH 3/3] wined3d: Remove broken gdi palette code.
by Marvin May 2, 2014

May 2, 2014

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=6747 Your paranoid android. === wvistau64 (64 bit ddraw2) === ddraw2.c:5645: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw1) === ddraw1.c:4569: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw7) === ddraw7.c:6369: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw4) === ddraw4.c:6546: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 6: Got unexpected pitch 252, expected 256.

1 0

Re: [PATCH 1/3] ddraw/tests: Add a test for getdc palette handling (try 2).
by Henri Verbeet May 2, 2014

May 2, 2014

On 2 May 2014 13:43, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * contains uninitialized garbage. See comments beflow for the P8 case. */ This is minor of course, but "below". > + /* See Win8 refcounting remarks in test_primary_palette. */ I think this is superfluous here as well. With those fixed, I think this set is ok.

1 0

Re: [PATCH 2/3] ddraw/tests: Test mipmap GetDC behavior.
by Marvin May 2, 2014

May 2, 2014

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=6746 Your paranoid android. === wvistau64 (64 bit ddraw2) === ddraw2.c:5645: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw1) === ddraw1.c:4569: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw7) === ddraw7.c:6369: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw4) === ddraw4.c:6546: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 6: Got unexpected pitch 252, expected 256.

1 0

Re: [PATCH 1/3] ddraw/tests: Add a test for getdc palette handling (try 2).
by Marvin May 2, 2014

May 2, 2014

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=6745 Your paranoid android. === wvistau64 (64 bit ddraw2) === ddraw2.c:5645: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw1) === ddraw1.c:4569: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw7) === ddraw7.c:6369: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw4) === ddraw4.c:6546: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 6: Got unexpected pitch 252, expected 256.

1 0

Re: [PATCH] user32: Don't destroy in-use menus
by Ken Thomases May 2, 2014

May 2, 2014

On May 1, 2014, at 2:19 PM, Andrew Eikum wrote: > + /* two different kinds of "reference" counting. in_use is for internal > + * refcounting for e.g. submenus. user_destroyed indicates whether > + * DestroyMenu has been invoked on a handle returned by CreateMenu. */ > + BOOL in_use, user_destroyed; First, since in_use is a count, it probably shouldn't be a BOOL. Second, I haven't reviewed the menu code thoroughly, but I think that it would be better to conceptually separate the handle from the internal structure. Internal references to submenus and the like should be by pointers to the structure. The handle should only be used at the interface with external clients. Then, there should be only one reference count. It's the count of users of the structure. The handle represents one reference. Each place where a pointer to the structure is stored is another reference. DestroyMenu() should really destroy the handle (and thus decrement the reference count), not just mark it as "destroyed". -Ken

2 1

Re: dpnet: Implement IDirectPlay8LobbiedApplication Initialize (try 2)
by Stefan Dösinger May 2, 2014

May 2, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-02 07:26, schrieb Alistair Leslie-Hughes: > Hi, Remove the Initial value from Create function. The changes of > spaces was done on purpose, future patches will change the other > places. > > Changelog: dpnet: Implement IDirectPlay8LobbiedApplication > Initialize Looks good to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTY2cZAAoJEN0/YqbEcdMwKTgP/1rHmFZTq7GVcDfVyvjgrJvv BQmCMFJZs0/DYgy0+D+ZR5UccLaaoJD75+GyWjSuw2AITOHJ2q8kyREAms4nNQiR /DUa4ZDMeCFfVuC7aStSal2LOiMEqfZycrHa5ryu189mhoyObOT+xQtRa19rzxuJ OLN4IDe0eOSx1KyShiFzYueLY+oNnIf5IJ/omCTfvug5xPP45ZUby74VTXzmahD3 FU+oEBisuv2vXC7mHCjIsWUCadOh1G3UHtZ39/w/70Yj9HaxGipq6bxN4CD/5gho 99qy5JqqE+88gLTjgvsAFGoUpXCdc6k2hQXW9FviV/PbIYFy62tzmpmicmHVknKO XKrRP74l4bI4QutTxBOwN4d2SmGhFD/y8n0oi1c6SgwgfzdMO9nEv3Bx4F7d+pzi JZJnN7A++j5OInGow4xHd1b6oui55MLIMtbW3QJ7auBM+Ue0tB68UKYcrZkPYb29 JpmxFoNSJbqGAhw+0YH5KiemYKb7y/KD7uctrKodsbzQJFqA5gGEUTrTj7h2mo4+ kws3INzZlWJLMIoreaxtfNCco+SFtYIhD72io9KGSdIXc92GJOLTcG0JHXNC709s Rr3Ttl7hnYN6Y6YZsCpZQKE29ZsivUVUs4idL2AuYzHlUWbdJm3RUTRQVF7ncM2f OScvgQEx3PjLqCg861pY =pRHL -----END PGP SIGNATURE-----

1 0

Re: dpnet: Store DPN_SP_CAPS as part of the object
by Stefan Dösinger May 2, 2014

May 2, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-02 07:58, schrieb Alistair Leslie-Hughes: > +void init_dpn_sp_caps(DPN_SP_CAPS * pdpspCaps) DECLSPEC_HIDDEN; Why do you need the declaration in the header file? As far as I can see you're calling it from one file only. If you'll need it in a later patch just add it in the patch that needs it and keep the function static for now. Please avoid the Hungarian notation ("pdpspCaps") in new code. While you're at it: The placement of the * is inconsistent with the rest of the code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTY2axAAoJEN0/YqbEcdMwOGYP/12lXZrx8HnEa1y1N3VHd/7W DMA9os0kqxyEuvBO0+4QCaTi8s8yjhlA0034xK4Tjl+ZYCy3sK8cx+1q1sM4PV2L XYxaRxddqWtNkuEVXbm9Kcq/P+xIzv+d8zcZ0j8WcPOX2fn0Y6YTyBGDHKQZGq/y QFLN1rLDoUksJ78L6Ik7s6zalGLmPw3SeZ7vsTvjiEaXBbbj/wBXy1LY/I4lVxXO uleeQpApV/h/3ul5mne9hnU5SkpskW6ECaNTW1ggmxA+GCSzy0UGK7Cd+LOb/gL+ wLaFXzdBop25LyGygNuzd6w+SwZ2VULPJY+IwVvZvprGMMQYYxrrdtc6B5kgJm51 tpitxyX/s2IqJUFDLPOp5yDUowmfrNWlrptS6iOjJ/j8g29PvTz4MAmoABm8UHm+ eDYUsn1jQhWp9zA7cuZL5G9JpxA7hY5xwlttBZLHqyYWzsNqC0c0XELwp6sCMAqx rH9RmFNH/Oo75puFav0YdfIQ1Zwmt8wgnaobFS1COIZ8u3gXAc36HsrPfQiaPIPQ TYiO7EwPAFx3+Tz1FHNln/PjUnbbND7s5KJtRs9CxVMiGnN3oyw7wNRyB7HbKP0u YcMXCTv6MlpMnFVSXM7zf0E1ahxTmMY3Z6qr+Y/N3EQVY+vHKxNBlXNZsaLfiJqj 8aXBZ1QdgGJ//Jn0dn3d =VadZ -----END PGP SIGNATURE-----

1 0

Re: dpnet: Implement IDirectPlay8Client Initialize
by Stefan Dösinger May 2, 2014

May 2, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-01 07:41, schrieb Alistair Leslie-Hughes: > +START_TEST(client) > +{ > + test_init_dp(); > + test_enum_service_providers(); > + test_enum_hosts(); > + test_get_sp_caps(); > + test_cleanup_dp(); > +} I think that needs splitting. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIbBAEBAgAGBQJTYn8SAAoJEN0/YqbEcdMwonoP9A8x5zWuCAlVxAVYi9Hsz7yL jkSay3KVxAmyU1mkboG3LBVEQP/ZSkD99oXlu2t/++GL2+FZuX9ms9vJNSxmETQn WBdu9LRqqh8QrGKuKjdyjr8aPzphqAkwNkfbHFpfvTZ9WDGqSXV2atv7pFB7ytfH 4Qrs//RYXE6n6feQB2LGSp6faupX+SGWA5hAKyWD3oKUthMNTo4C9lCjeBKg7az1 kvY45VbTthruv+YHuPnMBZk/hH5yZpxhyrM7yvBwMz/raia05Rf4Ok9xrp8FVX9k IyYX+vgYWi5OtK5XRtpwih3qpnk1v975owTcHmK/ngU2g/wkCmYszXhs+1t5hVti e4rMDByQXXgdFKV0w9uT1YnUwqgRIFMizKGLmBEougFzjtUVndXwK4U7tE0ar2Pd wwDnkQ5m0mcpZ2X690aGqnXhXg8hxsvMCFEDNQvwStH/2d1+2qpjrkaZ5WSW5W7E kEn1tTcqipoK2AVZ49ZXBa6xdtPn/ZafK3YWzwv5nvv52BhL7XE3HIByZvcuD5IM LdEr3O0xVojJLRoJ7f9dzUJWK+Fgi5TvVRMabzYEMemLWfQLEuNIZvse7JvXXu+5 bomwR2QR8+2+xv1L60CbMVepidN8bduQXNyzQdE974ZeK8ahLxWvUBS8mAlmb9aF /xU3BmBfPBwIVQIxw+s= =MrVx -----END PGP SIGNATURE-----

2 1

Re: [PATCH] vbscript: Fixed CBool(try 3)
by Marvin May 2, 2014

May 2, 2014

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=6732 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found

1 0

Re: dpnet: Implement IDirectPlay8LobbiedApplication Initialize
by Stefan Dösinger May 1, 2014

May 1, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-01 07:42, schrieb Alistair Leslie-Hughes: > static HRESULT WINAPI IDirectPlay8LobbiedApplicationImpl_RegisterProgram(IDirectPlay8LobbiedApplication *iface, > @@ -191,6 +201,11 @@ HRESULT DPNET_CreateDirectPlay8LobbiedApp(LPCLASSFACTORY iface, LPUNKNOWN punkOu > } > app->IDirectPlay8LobbiedApplication_iface.lpVtbl = &DirectPlay8LobbiedApplication_Vtbl; > app->ref = 0; > + app->msghandler = NULL; > + app->flags = 0; > + app->usercontext = NULL; > + app->connection = NULL; This is redundant, HEAP_ZERO_MEMORY clears that for you. Also, in the other patches you changed the indentation to 4 spaces, but not here. If this was intentional I'm fine with that - just pointing it out. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTYn7KAAoJEN0/YqbEcdMwV2UP/jkWB0vY5CLO+A0z9JISmIJT V+dlgPTTWHYgxTVBpDVoBlfYl3vmVTqoHPMExWef8lts0Dx1+Gv0pDQZpwUFXJ9P 9jOBZsuyNwcwU1uSm8BvFXQFWs6XCUoQn9nHC5Y9GNezLQy4KRpPX3xkHf1QuHZw CI/Z8oLwcHT9zy4uWUcYe1ciATCRHx9noLFR7cHIIkOuI1kakptX1DYMp39uo7Hg qah9QP+yA88MDnXQlUSLOSui0dd7lmbqPTHwsHAm8VCgUWUdqFIT0Yt5kITxZjyW tKz1XM7aRZ+V4kbdg8R7PbmFdent/xa79ceOnOIg5MQEWc3LBY+ynh5vgAqEUgAA ynIFlJMyB09D9JRVKj6ETxoIrx+m+FN/z6xD66GvD9ehqQZXH8v+fUc+xyGg0d5o Yj+2R0HJLUEtN7h3n1o9+8EJ6YhmceyOnu7OtrSN7Mapw7qXT4aESSCiRy8j7c1T fy3qvPrmEPRjCN8e1Tu0IJn4EyQl6Eke9BB4CXtuxhOgNC+Z2GekgU1k4Dj78iiQ VXpD9jw/CblEYv+iu4Lvo+E76nHMvF4R0M/UooS+urSnIfKGiNSorMCJOQ+xM1hs b634KfA1gpfq/foDRY0pVcxQVEbN5nKS8vAiv7wul/bhIoWMAZr2DktBdYP08Ye2 pbmU+Nd4X5lclBbj2Rnq =jFdr -----END PGP SIGNATURE-----

1 0

Re: [PATCH 2/6] wined3d: Validate and handle query size parameter.
by Marvin May 1, 2014

May 1, 2014

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=6720 Your paranoid android. === w864 (32 bit device) === device.c:3856: Test failed: Occlusion query returned an unexpected result (0xffff0000). device.c:3861: Test failed: Occlusion query returned an unexpected result (0x00000000). device.c:3866: Test failed: Occlusion query returned an unexpected result (0x00000000). === w864 (64 bit device) === device.c:3856: Test failed: Occlusion query returned an unexpected result (0xffff0000). device.c:3861: Test failed: Occlusion query returned an unexpected result (0x00000000). device.c:3866: Test failed: Occlusion query returned an unexpected result (0x00000000).

1 0

Re: [PATCH 1/6] d3d9/tests: Test GetData behavior with various size values.
by Marvin May 1, 2014

May 1, 2014

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=6719 Your paranoid android. === w864 (32 bit device) === device.c:3856: Test failed: Occlusion query returned an unexpected result (0xffff0000). device.c:3861: Test failed: Occlusion query returned an unexpected result (0x00000000). device.c:3866: Test failed: Occlusion query returned an unexpected result (0x00000000). === w864 (64 bit device) === device.c:3856: Test failed: Occlusion query returned an unexpected result (0xffff0000). device.c:3861: Test failed: Occlusion query returned an unexpected result (0x00000000). device.c:3866: Test failed: Occlusion query returned an unexpected result (0x00000000).

1 0

Re: [PATCH] vbscript: Fixed CBool(try 2)
by Piotr Caban May 1, 2014

May 1, 2014

On 05/01/14 10:16, Shuai Meng wrote: > Changelog: > added tests on object subtype. > improved CBool. > > https://newtestbot.winehq.org/JobDetails.pl?Key=6689 > > --- > dlls/vbscript/global.c | 41 > ++++++++++++----------------------------- > dlls/vbscript/tests/api.vbs | 42 > ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 54 insertions(+), 29 deletions(-) The tests are not passing on wine: run.c:1013: Test failed: api.vbs: L"Err.number = 0" run.c:1013: Test failed: api.vbs: L"Err.number = 0" run.c:1013: Test failed: api.vbs: L"Err.number = 0" These are the failing tests: Call testCBoolError("#TRUE#", 458) Call testCBoolError("#FALSE#", 458) Call testCBoolError(MyObject, 458) Could you please also add following tests: MyObject.myval = 1 Call ok(CBool(MyObject) = True, "CBool(MyObject) = " & CBool(MyObject)) MyObject.myval = 0 Call ok(CBool(MyObject) = False, "CBool(MyObject) = " & CBool(MyObject))

3 3

Re: [PATCH 11/11] oleacc: Add tests for default client accessible object (try2)
by Marvin May 1, 2014

May 1, 2014

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=6716 Your paranoid android. === w2000pro (32 bit main) === main.c:347: Test failed: V_I4(&v) = 8000 === w2008s64 (64 bit main) === main.c:223: Test failed: wparam = 0 main.c:229: Test failed: unexpected (-12) === w864 (64 bit main) === main.c:223: Test failed: wparam = 0 main.c:229: Test failed: unexpected (-12)

1 0

Re: [PATCH 11/11] oleacc: Add tests for default client accessible object
by Marvin May 1, 2014

May 1, 2014

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=6714 Your paranoid android. === build (build) === Unable to regenerate dlls/oleacc/Makefile Unable to regenerate dlls/oleacc/Makefile

1 0

regsvr32 patches (argument handler, unicode)
by Hugh McMaster May 1, 2014

May 1, 2014

Is there a reason that patches 104221 to 104224 were not committed? Perhaps a test case is needed? [1/4] regsvr32: Implement new method of handling arguments/flags ( http://source.winehq.org/patches/data/104221 ) This patch replaces the existing argument/flag handler in regsvr32.c (mostly repeated calls to strcasecmp) with a new handler based on a switch statement. [2/4] regsvr32: Convert to Unicod ( http://source.winehq.org/patches/data/104222 ) This patch modifies the source in regsvr32.c so that regsvr32.exe runs entirely in Unicode. Note that the Windows version has Unicode support. Wine does not (yet). [3/4] regsvr32: Add WriteFile support ( http://source.winehq.org/patches/data/104223 ) This patch adds WriteFile() support to regsvr32's output_write() function. It is used in the event that WriteConsoleW() fails. [4/4] regsvr32: Fix a number of errors in the comments of regsvr32.c ( http://source.winehq.org/patches/data/104224 ) This patch fixes a number of spelling, grammar and logic errors in the comments of regsvr32.c. Thank you. -- Hugh McMaster

1 0

Re: user32: Reduce the minimum Set[System]Timer from 15 ms to 10 ms.
by Marvin May 1, 2014

May 1, 2014

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=6713 Your paranoid android. === wxppro (32 bit msg) === msg.c:13332: Test failed: 9: WaitForSingleObject failed === w7u (32 bit msg) === msg.c:12098: Test failed: unexpected hwnd 00150136 msg.c:12120: Test failed: bad time 31ef4/31f14

1 0

AW: imagehlp: Implement (parts of) BindImageEx (try 5)
by Bernhard Reiter May 1, 2014

May 1, 2014

*ping* No comments or reviews? -------- Ursprüngliche Nachricht -------- Von: Bernhard Reiter <ockham(a)raz.or.at> Datum: An: wine-patches(a)winehq.org Betreff: imagehlp: Implement (parts of) BindImageEx (try 5) Some more fixes to make tests pass on Windows, and to adjust implementation accordingly.

1 0

Re: msi: Expand REG_EXPAND_SZ keys when resolving AppSearch entries
by Hans Leidekker May 1, 2014

May 1, 2014

On Wed, 2014-04-30 at 16:08 +0200, Jérôme Gardou wrote: > Resent for lack of comments on wine-devel. > > --- > dlls/msi/appsearch.c | 22 ++++++++++++++++++++++ > dlls/msi/tests/package.c | 22 ++++++++++++++++++++++ > 2 files changed, 44 insertions(+) Looks good, thanks.

1 0

Re: [PATCH] vbscript: Fixed CBool(try 2)
by Marvin May 1, 2014

May 1, 2014

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=6706 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found

1 0

Re: msi: Expand REG_EXPAND_SZ keys when resolving AppSearch entries
by Marvin May 1, 2014

May 1, 2014

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=6702 Your paranoid android. === w2000pro (32 bit package) === package.c:3978: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:3984: Test failed: Expected "C:\\FileName2", got "C:\FileName2" package.c:3990: Test failed: Expected "C:\\FileName3", got "C:\FileName3" package.c:4002: Test failed: Expected "C:\\FileName5", got "C:\FileName5" package.c:4008: Test failed: Expected "C:\\", got "C:\" package.c:4014: Test failed: Expected "C:\\", got "C:\" package.c:4030: Test failed: Expected "C:\\FileName8.dll", got "C:\FileName8.dll" package.c:4041: Test failed: Expected "C:\\FileName10.dll", got "C:\FileName10.dll" package.c:4500: Test failed: Expected ERROR_SUCCESS, got 1627 package.c:4592: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4603: Test failed: Expected "C:\\", got "C:\" package.c:4614: Test failed: Expected "C:\\", got "C:\" package.c:4664: Test failed: Expected "C:\\FileName3.dll", got "C:\FileName3.dll" package.c:4675: Test failed: Expected "C:\\FileName5.dll", got "C:\FileName5.dll" package.c:4690: Test failed: Expected "C:\\", got "C:\" package.c:4695: Test failed: Expected "", got "C:\" package.c:4711: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4720: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4970: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4981: Test failed: Expected "C:\\", got "C:\" package.c:4987: Test failed: Expected "C:\\", got "C:\" package.c:5008: Test failed: Expected "C:\\FileName2.dll", got "C:\FileName2.dll" package.c:5019: Test failed: Expected "C:\\FileName4.dll", got "C:\FileName4.dll" package.c:5259: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:5265: Test failed: Expected "C:\\", got "C:\" package.c:5282: Test failed: Expected "C:\\one\two\three\FileName2", got "C:\one\two\three\FileName2" package.c:5293: Test failed: Expected "C:\\one\two\three\FileName2", got "C:\one\two\three\FileName2" package.c:5301: Test failed: Expected "C:\\FileName3.dll", got "C:\FileName3.dll" package.c:5645: Test failed: Expected C:\\winetest-package.msi, got C:\winetest-package.msi package.c:6277: Test failed: Expected C:\\abelisaurus or empty string, got C:\abelisaurus package.c:6301: Test failed: Expected C:\\ or empty string, got C:\ package.c:6345: Test failed: Expected C:\\ or empty string, got C:\ package.c:6354: Test failed: Expected C:\\neosodon\ or empty string, got C:\neosodon\ package.c:6584: Test failed: Expected "C:\\", got "C:\" package.c:6585: Test failed: Expected 4, got 3 package.c:6592: Test failed: Expected "C:\\", got "C:\" package.c:6593: Test failed: Expected 4, got 3 package.c:6609: Test failed: Expected "C:\\", got "C:\" package.c:6610: Test failed: Expected 4, got 3 package.c:6616: Test failed: Expected "C:\\", got "C:\" package.c:6617: Test failed: Expected 4, got 3 package.c:6624: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6625: Test failed: Expected 14, got 13 package.c:6632: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6633: Test failed: Expected 19, got 18 package.c:6643: Test failed: Expected "C:\\", got "C:\" package.c:6644: Test failed: Expected 4, got 3 package.c:6651: Test failed: Expected "C:\\", got "C:\" package.c:6652: Test failed: Expected 4, got 3 package.c:6668: Test failed: Expected "C:\\", got "C:\" package.c:6669: Test failed: Expected 4, got 3 package.c:6675: Test failed: Expected "C:\\", got "C:\" package.c:6676: Test failed: Expected 4, got 3 package.c:6683: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6684: Test failed: Expected 14, got 13 package.c:6691: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6692: Test failed: Expected 19, got 18 package.c:6702: Test failed: Expected "C:\\", got "C:\" package.c:6703: Test failed: Expected 4, got 3 package.c:6710: Test failed: Expected "C:\\", got "C:\" package.c:6711: Test failed: Expected 4, got 3 package.c:6727: Test failed: Expected "C:\\", got "C:\" package.c:6728: Test failed: Expected 4, got 3 package.c:6734: Test failed: Expected "C:\\", got "C:\" package.c:6735: Test failed: Expected 4, got 3 package.c:6742: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6743: Test failed: Expected 14, got 13 package.c:6750: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6751: Test failed: Expected 19, got 18 package.c:6761: Test failed: Expected "C:\\", got "C:\" package.c:6762: Test failed: Expected 4, got 3 package.c:6769: Test failed: Expected "C:\\", got "C:\" package.c:6770: Test failed: Expected 4, got 3 package.c:6786: Test failed: Expected "C:\\", got "C:\" package.c:6787: Test failed: Expected 4, got 3 package.c:6793: Test failed: Expected "C:\\", got "C:\" package.c:6794: Test failed: Expected 4, got 3 package.c:6801: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6802: Test failed: Expected 14, got 13 package.c:6809: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6810: Test failed: Expected 19, got 18 package.c:6825: Test failed: Expected 4, got 3 package.c:6842: Test failed: Expected 4, got 3 package.c:6848: Test failed: Expected ERROR_MORE_DATA, got 0 package.c:6851: Test failed: Expected 4, got 3 package.c:6858: Test failed: Expected "C:\\", got "C:\" package.c:6859: Test failed: Expected 4, got 3 package.c:6870: Test failed: Expected "C:\\", got "C:\" package.c:6871: Test failed: Expected 4, got 3 package.c:6966: Test failed: Expected "C:\\", got "C:\" package.c:6967: Test failed: Expected 4, got 3 package.c:6974: Test failed: Expected "C:\\", got "C:\" package.c:6975: Test failed: Expected 4, got 3 package.c:6984: Test failed: Expected "C:\\", got "C:\" package.c:6985: Test failed: Expected 4, got 3 package.c:6993: Test failed: Expected "C:\\", got "C:\" package.c:6994: Test failed: Expected 4, got 3 package.c:7000: Test failed: Expected "C:\\", got "C:\" package.c:7001: Test failed: Expected 4, got 3 package.c:7008: Test failed: Expected "C:\\", got "C:\" package.c:7009: Test failed: Expected 4, got 3 package.c:7016: Test failed: Expected "C:\\", got "C:\" package.c:7017: Test failed: Expected 4, got 3 package.c:7027: Test failed: Expected "C:\\", got "C:\" package.c:7028: Test failed: Expected 4, got 3 package.c:7035: Test failed: Expected "C:\\", got "C:\" package.c:7036: Test failed: Expected 4, got 3 package.c:7045: Test failed: Expected "C:\\", got "C:\" package.c:7046: Test failed: Expected 4, got 3 package.c:7054: Test failed: Expected "C:\\", got "C:\" package.c:7055: Test failed: Expected 4, got 3 package.c:7061: Test failed: Expected "C:\\", got "C:\" package.c:7062: Test failed: Expected 4, got 3 package.c:7069: Test failed: Expected "C:\\", got "C:\" package.c:7070: Test failed: Expected 4, got 3 package.c:7077: Test failed: Expected "C:\\", got "C:\" package.c:7078: Test failed: Expected 4, got 3 package.c:7088: Test failed: Expected "C:\\", got "C:\" package.c:7089: Test failed: Expected 4, got 3 package.c:7096: Test failed: Expected "C:\\", got "C:\" package.c:7097: Test failed: Expected 4, got 3 package.c:7106: Test failed: Expected "C:\\", got "C:\" package.c:7107: Test failed: Expected 4, got 3 package.c:7115: Test failed: Expected "C:\\", got "C:\" package.c:7116: Test failed: Expected 4, got 3 package.c:7122: Test failed: Expected "C:\\", got "C:\" package.c:7123: Test failed: Expected 4, got 3 package.c:7130: Test failed: Expected "C:\\", got "C:\" package.c:7131: Test failed: Expected 4, got 3 package.c:7138: Test failed: Expected "C:\\", got "C:\" package.c:7139: Test failed: Expected 4, got 3 package.c:7149: Test failed: Expected "C:\\", got "C:\" package.c:7150: Test failed: Expected 4, got 3 package.c:7157: Test failed: Expected "C:\\", got "C:\" package.c:7158: Test failed: Expected 4, got 3 package.c:7167: Test failed: Expected "C:\\", got "C:\" package.c:7168: Test failed: Expected 4, got 3 package.c:7176: Test failed: Expected "C:\\", got "C:\" package.c:7177: Test failed: Expected 4, got 3 package.c:7183: Test failed: Expected "C:\\", got "C:\" package.c:7184: Test failed: Expected 4, got 3 package.c:7191: Test failed: Expected "C:\\", got "C:\" package.c:7192: Test failed: Expected 4, got 3 package.c:7199: Test failed: Expected "C:\\", got "C:\" package.c:7200: Test failed: Expected 4, got 3 package.c:7297: Test failed: Expected "C:\\long\", got "C:\long\" package.c:7298: Test failed: Expected 9, got 8 package.c:7307: Test failed: Expected "C:\\long\", got "C:\long\" package.c:7308: Test failed: Expected 9, got 8 package.c:7317: Test failed: Expected "C:\\long\", got "C:\long\" package.c:7318: Test failed: Expected 9, got 8 package.c:7329: Test failed: Expected "C:\\two\", got "C:\two\" package.c:7330: Test failed: Expected 8, got 7 package.c:7341: Test failed: Expected "C:\\four\", got "C:\four\" package.c:7342: Test failed: Expected 9, got 8 package.c:7353: Test failed: Expected "C:\\six\", got "C:\six\" package.c:7354: Test failed: Expected 8, got 7 package.c:7365: Test failed: Expected "C:\\eight\", got "C:\eight\" package.c:7366: Test failed: Expected 10, got 9 package.c:7377: Test failed: Expected "C:\\ten\", got "C:\ten\" package.c:7378: Test failed: Expected 8, got 7 package.c:7389: Test failed: Expected "C:\\twelve\", got "C:\twelve\" package.c:7390: Test failed: Expected 11, got 10 package.c:7441: Test failed: Expected "C:\\short\", got "C:\short\" package.c:7442: Test failed: Expected 10, got 9 package.c:7451: Test failed: Expected "C:\\short\", got "C:\short\" package.c:7452: Test failed: Expected 10, got 9 package.c:7461: Test failed: Expected "C:\\short\", got "C:\short\" package.c:7462: Test failed: Expected 10, got 9 package.c:7473: Test failed: Expected "C:\\one\", got "C:\one\" package.c:7474: Test failed: Expected 8, got 7 package.c:7485: Test failed: Expected "C:\\three\", got "C:\three\" package.c:7486: Test failed: Expected 10, got 9 package.c:7497: Test failed: Expected "C:\\five\", got "C:\five\" package.c:7498: Test failed: Expected 9, got 8 package.c:7509: Test failed: Expected "C:\\seven\", got "C:\seven\" package.c:7510: Test failed: Expected 10, got 9 package.c:7521: Test failed: Expected "C:\\nine\", got "C:\nine\" package.c:7522: Test failed: Expected 9, got 8 package.c:7533: Test failed: Expected "C:\\eleven\", got "C:\eleven\" package.c:7534: Test failed: Expected 11, got 10 package.c:7670: Test failed: Expected "C:\\", got "C:\" package.c:7671: Test failed: Expected 4, got 3 package.c:7682: Test failed: Expected "C:\\", got "C:\" package.c:7683: Test failed: Expected 4, got 3 package.c:7690: Test failed: Expected "C:\\", got "C:\" package.c:7691: Test failed: Expected 4, got 3 package.c:7788: Test failed: Expected "C:\\", got "C:\" package.c:7789: Test failed: Expected 4, got 3 package.c:7796: Test failed: Expected "C:\\", got "C:\" package.c:7797: Test failed: Expected 4, got 3 package.c:7804: Test failed: Expected "C:\\", got "C:\" package.c:7805: Test failed: Expected 4, got 3 package.c:7824: Test failed: Expected "C:\\", got "C:\" package.c:7825: Test failed: Expected 4, got 3 package.c:7832: Test failed: Expected "C:\\", got "C:\" package.c:7833: Test failed: Expected 4, got 3 package.c:7852: Test failed: Expected "C:\\", got "C:\" package.c:7853: Test failed: Expected 4, got 3 package.c:7860: Test failed: Expected "C:\\", got "C:\" package.c:7861: Test failed: Expected 4, got 3 package.c:7880: Test failed: Expected "C:\\", got "C:\" package.c:7881: Test failed: Expected 4, got 3 package.c:7888: Test failed: Expected "C:\\", got "C:\" package.c:7889: Test failed: Expected 4, got 3 === w7u (32 bit package) === The test timed out

1 0