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

Re: comctl32: Tooltip AddTool needs to support TTTOOLINFOW_V3_SIZE

by Alexandre Julliard

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

May 9, 2014

Re: wininet: Fix InternetGetConnectedStateEx[A|W] (try 2, resend)

by Alexandre Julliard

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

May 9, 2014

Re: ced401: add initial support

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-09 15:51, schrieb Nikolay Sivov: > It doesn't mean this module should be added in Wine. Right place > for it is your own copy of Wine repo with any custom patch you > like. I wouldn't dismiss it per se. We ship an openal wrapper even though openal isn't a part of Windows, but a redistributable provided by Creative Technology. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTbOJYAAoJEN0/YqbEcdMwr6QP/3aU6t4MpiIBNIL61Jp/J/Rs 976cMzVMne+XksYyQJp3wzyfWUTor3WULwlGK5q46I3/Q+4nkFI7Nr2sqyR+wD3M sFGbfF9dbqIFsDpO93GceqH2RU+tk0+EyfySfgHf751qRU/TVRXx6fBH4EMLR93Q MCKrgMhoVk1zCSyKC1HoOZMlsFcqBEAFkbUI3kogdm7ccdHIxA2VU35yFBDBg+gu ZWnEbwqwuC0WBpTgl/592h4IgIdrEmLt6mahxcNhyGRRlrPaC62nagjHNea1etCQ BOTorAudk8HnTfYChql+T2X++axEsXxhx0XKlGAN55jq0zC+/D0fTjx0/pdPxp2T q1JZSDaxTCUk+PfdGNCtSLO7Qtfmob38nDOuGTdbe4atsyr7mWf3n2UljlqyY0Uq aVMvnCtlnafG0lNByj/UMxONt+8jbInaDk0PbyIjyo6Pfq1CglG1sCf+Zy6EYgKW PMjpWYNJr/PLE28Hl++25vmdu12wgmEw3Dg5CGRA9R0kyBTWLRdMQ/jxcbaQscsg 5K6wPR2UL+lgKBICEImEYkcQZ4EuNO9wND8JVGLkxW7ns3JxprTbWyL6aRibaaHn RrUWIb+LmPlOwm5Lm3YNuv58pji2RVu32lTfLG6zgyAfJq8m/SxIL5Mx6eu9R/1v B6OYOzYGFhkNd0zJ4y1z =hKhJ -----END PGP SIGNATURE-----

May 9, 2014

Re: ced401: add initial support

by Nikolay Sivov

On 5/9/2014 17:43, Alois Schlögl wrote: > > The dll comes with the ced1401 (try1432 [1], spike [2], signal) > software from CED. > It requires access to the USB with access through ced_usb.sys (on > win32) or ced_us64.sys (on win64) which are not supported by wine > (http://wiki.winehq.org/USB) The idea doing it this way was suggested > here: > http://www.winehq.org/pipermail/wine-devel/2014-April/103711.html It doesn't mean this module should be added in Wine. Right place for it is your own copy of Wine repo with any custom patch you like. > > Alois > > > [1] http://appdb.winehq.org/objectManager.php?sClass=version&iId=30056 > [2] http://appdb.winehq.org/objectManager.php?sClass=application&iId=9146 >

May 9, 2014

Re: ced401: add initial support

by Alois Schlögl

The dll comes with the ced1401 (try1432 [1], spike [2], signal) software from CED. It requires access to the USB with access through ced_usb.sys (on win32) or ced_us64.sys (on win64) which are not supported by wine (http://wiki.winehq.org/USB) The idea doing it this way was suggested here: http://www.winehq.org/pipermail/wine-devel/2014-April/103711.html Alois [1] http://appdb.winehq.org/objectManager.php?sClass=version&iId=30056 [2] http://appdb.winehq.org/objectManager.php?sClass=application&iId=9146 On 2014-05-09 14:55, Nikolay Sivov wrote: > 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! >> + * >> + */ > > > >

May 9, 2014

Re: ced401: add initial support

by Nikolay Sivov

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! > + * > + */

May 9, 2014

Re: [PATCH 1/2] mshtml: Added IDispatchEx support to HTMLStyleSheetRulesCollection object.

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

May 9, 2014

Re: [PATCH 2/2] oleacc: Add Client_accHitTest implementation

by Piotr Caban

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.

May 9, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Alexandre Julliard

Ken Thomases <ken(a)codeweavers.com> writes: > On May 8, 2014, at 3:18 AM, Alexandre Julliard wrote: >> It can't be using an old surface unless you introduced the concept of >> multiple surfaces in the first place... > > You don't even acknowledge the need for multiple surfaces _serially_? > That wined3d might create a surface on a virgin window and then > destroy it, and then later create another one? It's probably a question of terminology. To my mind, there is one place in the window where you can render stuff, using a specific pixel format. If multiple users try to set a different format on the window at the same time, there's a need to arbitrate that. Your solution is to create multiple surfaces, but then this moves the problem to arbitrating which surface is the "real" one, i.e. the one that actually puts something on the screen. Because in the end there's only one visible window surface. Obviously under X11 we need to create a new drawable because the format is set at creation time, but that doesn't necessarily have to be something that wined3d knows about. Conceptually it's still the same window surface. >> The concept of supporting multiple active surfaces clearly raises a >> number of questions, and so far it seems the answer is always "we >> don't know because no app ever does this". So it feels to me like a >> solution in search of a problem... > > That's exactly backward. The problems are real and known. My work > solves them. You are hypothesizing that my work will cause problems > which would only happen if apps did what "no app ever does". No, that's not what I'm saying. I'm sure your approach is solving problems. My point is that the mechanism you are introducing raises new questions, like what happens when two surfaces are active at the same time. You are saying that this can be left undefined because no app ever does it, which leads me to wonder whether the API shouldn't better reflect what apps actually do. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2014

Re: Can I play with the Notepad code?

by David Quintana (gigaherz)

Keep in mind that Wine is open-source, and you are completely free to take the Notepad code and do whatever changes you want to it, as long as you keep using a compatible license if you plan on releasing the changed version. On 8 May 2014 23:07, Gediminas Jakutis <gediminas(a)varciai.lt> wrote: > On 2014.05.08 23:54, Susan Cragin wrote: >> >> 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 >> > > Hello! > > #define I_am_not_an_authority > > Wine's goal is to copy Windows' behavior as close as possible, ideally – act identically. So if this means those changes would make it deviate from that, I don't think this would have much of a chance to be accepted into Wine. > > #undef I_am_not_an_authority > > Hope this helps! > > -- > Gediminas Jakutis > LDK Varčiai www.varciai.lt > >

May 9, 2014

Re: ws2_32: Return the correct error if SO_REUSEADDR is set in bind error

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

May 8, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Ken Thomases

On May 8, 2014, at 3:18 AM, Alexandre Julliard wrote: > Ken Thomases <ken(a)codeweavers.com> writes: > >> I already explained. In the multi-threaded case, one thread can still >> be using an old surface after another thread released it and created a >> new one. > > It can't be using an old surface unless you introduced the concept of > multiple surfaces in the first place... You don't even acknowledge the need for multiple surfaces _serially_? That wined3d might create a surface on a virgin window and then destroy it, and then later create another one? > If the API is only, say, > wglSetPixelFormatWINE, then the change is considered instantaneous, and > threads that try to use the old format get an error, or get ignored. Or compete with the new pixel format causing pixel format thrashing, which is the status quo. > Obviously, in the driver implementation, it may require you to recreate > an X11 window, and possibly keep the old X11 window around to prevent > crashes, but that doesn't mean that the concept of multiple active > surfaces needs to become part of the exposed API. What requires it is all of the bugs caused by the status quo. The sole client of the new extension is wined3d. D3D and wined3d allow multiple swapchains to simultaneously target the same window. Each may use a different pixel format or swap interval. Likewise, WGL may set a pixel format or swap interval on a window simultaneously being used for D3D. In both WGL and GLX, the pixel format and the swap interval are properties of the drawable. They currently conflict, causing various failures. We need them to be independent so they don't interfere with each other. Therefore, wined3d requires multiple drawables. It may be theoretical that any app actually uses such multiple swapchains for rendering simultaneously, but as Stefan pointed out it's not theoretical that apps set up such swapchains. In any case, in designing an API for the use of wined3d, I need to support what wined3d supports, even in theory. > The concept of supporting multiple active surfaces clearly raises a number of questions, and so far it seems the answer is always "we don't know because no app ever does this". So it feels to me like a solution in search of a problem... That's exactly backward. The problems are real and known. My work solves them. You are hypothesizing that my work will cause problems which would only happen if apps did what "no app ever does". If the presence of multiple surfaces causes such a problem, we'll then have an actual real world case and can debug and solve it. Ideally, we'd do that debugging before the bulk of my work is actually committed, and some of our testers have indeed been helping me identify and debug issues with my patches. So far, the existence of multiple surfaces has not been one of them. -Ken

May 8, 2014

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 4)

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > So it looks like the full name is supposed to reflect the real font's > name after all. Does this mean that we can just commit > http://source.winehq.org/patches/data/104434 ? Looks like it, but please resend a version that also includes your new tests. -- Alexandre Julliard julliard(a)winehq.org

May 8, 2014

Re: Wine Test analysis, report

by Francois Gouget

On Sun, 4 May 2014, André Hentschel wrote: [...] > I did some wpcap tests recently and somethings different between xp and vista64: > https://testbot.winehq.org/JobDetails.pl?Key=6811 > Are there different network setups on those machines, e.g. the vista one having more networks than xp, or something like that? Neither of these two VMs has anything special network-wise besides WinPcap. However note that the Vista VM is 64-bit and I'm not sure how WinPcap handles 32-bit applications on a 64-bit system. But maybe that does not matter. -- Francois Gouget <fgouget(a)codeweavers.com>

May 8, 2014

Re: Can I play with the Notepad code?

by Gediminas Jakutis

On 2014.05.08 23:54, Susan Cragin wrote: > > 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 > Hello! #define I_am_not_an_authority Wine's goal is to copy Windows' behavior as close as possible, ideally – act identically. So if this means those changes would make it deviate from that, I don't think this would have much of a chance to be accepted into Wine. #undef I_am_not_an_authority Hope this helps! -- Gediminas Jakutis LDK Varčiai www.varciai.lt

May 8, 2014

Can I play with the Notepad code?

by Susan Cragin

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

May 8, 2014

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 4)

by Alex Henrie

So it looks like the full name is supposed to reflect the real font's name after all. Does this mean that we can just commit http://source.winehq.org/patches/data/104434 ? -Alex

May 8, 2014

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 4)

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=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

May 8, 2014

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 3)

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > 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); That only tests that the font is found, but not what is enumerated as full name for it. You probably want to use enum_fullname_data_proc or something along those lines. -- Alexandre Julliard julliard(a)winehq.org

May 8, 2014

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 3)

by Alex Henrie

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

May 8, 2014

Re: [PATCH] user32: Don't depend on HMENU being valid for popup menus

by Andrew Eikum

On Wed, May 07, 2014 at 03:59:07PM -0500, Ken Thomases wrote: > On May 7, 2014, at 9:57 AM, Andrew Eikum wrote: > > Unless I'm mistaken, these issues existed before this patch as well. > > DestroyMenu has always closed the handle, and additionally destroyed > > the struct. Now we preserve the struct if it's referenced by another > > menu. > > Well, first of all, the situation before this patch has problems > because of that, which is what you're trying to solve. > > Also, the specific issue of having the struct and going from that to > the handle, which might not be valid, and then implicitly expecting to > be able to get back to the struct is new. > I don't think it is new. Before the patch, we still relied on the HMENU being valid, it's just stored in a different place now. I don't think I've introduced any dependencies on the handle being valid that weren't already there, I've only removed them. Yes, there are some remaining, but those can be addressed in future patches as applications need it. The only new problem I can think of is where before we would have just passed an invalid HMENU, now the struct may have been destroyed and we can no longer get the HMENU. But this issue is precisely why I had to add the struct refcounting to this large patch instead of breaking it out, so this should not actually be a problem. > > There is some precedent for Windows returning an invalid HMENU. See > > the second GetMenuItemInfoA call in test_subpopup_locked_by_menu which > > returns the handle of the submenu that was just destroyed. > > Yes. I'm just not sure if that's what happens in these particular > circumstances. And I'm not so terribly concerned about the handle > being passed out to other code being invalid, although it would be > good to know we're doing the right thing. It's mostly about places > where the code has the menu pointer, obtains the menu handle from it, > passes that to other code in the menu module, and then tries to get > the menu pointer again. > You're right that those should be cleaned up, but this patch is already huge at over 700 changed lines. Future patches could address those issues as needed. This patch shouldn't make them any worse than they already are. Andrew

May 8, 2014

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 3)

by Alexandre Julliard

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

May 8, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Alexandre Julliard

Ken Thomases <ken(a)codeweavers.com> writes: > I already explained. In the multi-threaded case, one thread can still > be using an old surface after another thread released it and created a > new one. It can't be using an old surface unless you introduced the concept of multiple surfaces in the first place... If the API is only, say, wglSetPixelFormatWINE, then the change is considered instantaneous, and threads that try to use the old format get an error, or get ignored. Obviously, in the driver implementation, it may require you to recreate an X11 window, and possibly keep the old X11 window around to prevent crashes, but that doesn't mean that the concept of multiple active surfaces needs to become part of the exposed API. > Beyond that, although I'm not aware of a case where an app uses two > D3D devices to target the same window, I'm also not seeing anything in > the docs which says it's not allowed. For example, > IDirect3DSwapChain9::Present() takes an hDestWindowOverride parameter > which causes that particular present to target a window that was > previously unrelated to the swapchain. I see nothing in the docs that > suggest there's a limitation on which window you can use (other than > that it be visible or top-level). No error code meaning "invalid > window" or "window format mismatch". Maybe more test cases would be in order then. The concept of supporting multiple active surfaces clearly raises a number of questions, and so far it seems the answer is always "we don't know because no app ever does this". So it feels to me like a solution in search of a problem... -- Alexandre Julliard julliard(a)winehq.org

May 8, 2014

Re: [PATCH] comctl32/tests: Fix propsheet and listview tests which depend on being in foreground.

by Bernhard Übelacker

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Nikolay, > I don't know about propsheet part, but for a listview you're > setting parent to foreground, does it mean that lately created > child listview will be foreground as well? Cause failing test is > about mouse movements over listview, not its parent. If I understand you correct yes, most of the listviews in the tests are created with the parent window being that one I try to get to foreground. Therefore the failing listview is then also in foreground. If you execute this test in windows from a cmd window which has focus then the test is not failing. But when you immediately after starting the test click to another opened window or minimize the cmd window this failure can be reproduced. So one could say this patch is not fixing the test - it only changes the environment to the state it currently expects. Kind regards, Bernhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTarcHAAoJEOlvol+DpkHmBzYH/2osoORR6zfcN0ZbKzp3jT2s CfhFvpONTDkyQTMFht8m1qZAwl2xRqjnCoA/JxYLNJqpzIatQ6RuDIOrPuL4SL8F Zz9QkZ13eF5ww9DHaFpc+w0coi2RdUamtNK6SzU3L55m8drwsJpLv0cyCnLhDuLK uvhj8ZSppatnsLxcIdjon1seaLUhHBwICaGtoUjKPb3NaL3LGIt410dddFFgXFir Mv+A+pewmnkvhyJQmzdoUDz90cwK/YZFFUX8pGNdLDjA3TCHzn7/gWIzX081vxj8 B+dSmarM3CTLZ63cFn3aMDAunuLGc9GSWDFacQfM3ndSxMXTXZl/YDJWyn6T82U= =5kGN -----END PGP SIGNATURE-----

May 7, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-07 22:50, schrieb Ken Thomases: > Beyond that, although I'm not aware of a case where an app uses two > D3D devices to target the same window, I'm also not seeing > anything in the docs which says it's not allowed. There are applications that use two devices, even if they don't render from both. Sins of a Solar Empire (the relatively new game on Steam) is such a case. I also remember seeing this in ddraw, but I can't think of any specific game right now. My general impression of such applications is that they fail to release the old device rather than deliberately use two different devices. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTap7yAAoJEN0/YqbEcdMwoJQP/1MvcFryJxW+CEQNypQSPcSc SKgl/MFuMBdQ7OGiOtSlQhPCr4Ii2iQZWHU+PMCqXFz5C7Ulb685arOd6aCvMJOG fAUEkC3UteXKY1RhswaIxpZp1mhLQjQyTzcGeu2pUEvrXPnilKQ8UuRyiNP+A7So jWxyXIVHAOhcpX5e3jsIkJs5WlmOXxtlZF/BW5hbFE8sULigqoJgc8mGAiIT/XJa Ay+TlBW/kteL27fai/WM2mAaD6SZlvdgqALbgvf+BiZQSNvvsj/81FXs8LkGdXiW rv72F1/ikYHJOLlvGHFfEN49/yOLHoDrdmv1OH8yE0qahoOZ43W6iZOD5RoGlglN 3yHnqMHGRrk7QvR7P4XYBfZlgw9iRbt9dyU4A/Tq5vgpqOBa/bpDZOcRFOaDm8i5 hUng/S6kDC8PuvfsNe7vBolJx3NvE+RkKCedMpsjVOn18wEeBJ5d0OR/ecnU5HIb 1Lps55Qc2Lfz1ktIEXnsQVkkULDNO55WEmRHBd/DXW+gQ8jjPoW/lx1TxecAKeP9 JG/yP0Yk7gGQrJ7kr/DYyja670pqHKflKN5kpHEd0cusu713Qk2T9lDaELehWs/m JIgLbvLDxoPqqFWr51anNH1J+VTQrIGwXrNb1KZ2DJczyiGLKiH4Cu0EJ3bYi92j JPeo6kCIL5lR5KDNRLt1 =h7To -----END PGP SIGNATURE-----

May 7, 2014

Re: [PATCH] user32: Don't depend on HMENU being valid for popup menus

by Ken Thomases

On May 7, 2014, at 9:57 AM, Andrew Eikum wrote: > On Wed, May 07, 2014 at 06:09:44AM -0500, Ken Thomases wrote: >> 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. >> > > Unless I'm mistaken, these issues existed before this patch as well. > DestroyMenu has always closed the handle, and additionally destroyed > the struct. Now we preserve the struct if it's referenced by another > menu. Well, first of all, the situation before this patch has problems because of that, which is what you're trying to solve. Also, the specific issue of having the struct and going from that to the handle, which might not be valid, and then implicitly expecting to be able to get back to the struct is new. > There is some precedent for Windows returning an invalid HMENU. See > the second GetMenuItemInfoA call in test_subpopup_locked_by_menu which > returns the handle of the submenu that was just destroyed. Yes. I'm just not sure if that's what happens in these particular circumstances. And I'm not so terribly concerned about the handle being passed out to other code being invalid, although it would be good to know we're doing the right thing. It's mostly about places where the code has the menu pointer, obtains the menu handle from it, passes that to other code in the menu module, and then tries to get the menu pointer again. -Ken

May 7, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Ken Thomases

On May 7, 2014, at 8:10 AM, Alexandre Julliard wrote: > I don't see why D3D would need anything like that. I'm not sure if you followed the "Fixing conflicts between WineD3D and WGL" thread. That explains it along with some of the bugs that were known at the time. Since that thread was started, we've identified more bugs (not necessarily new ones) that my patches fix. > Do you really need to > be able to set a new pixel format but still draw with the old one and > expect the output to be visible? I am not aware of anything which tries to draw simultaneously using WGL and D3D or two D3D devices/swapchains targeting the same window. But there are definitely apps which care that GetPixelFormat() continues to return the WGL value even while a D3D swapchain is set up to target the same window, for example. > It seems to me all you really want is to restore the pixel format after > D3D has used it, to avoid messing up WGL. Wined3d is already restoring the pixel format, but it caused a bunch of regressions. Wined3d needs to "restore" things every time a call into it returns back to the caller, not just when the device and swapchain are torn down. There's no guarantee that an app won't try to do WGL stuff while a swapchain is set up, even if it's not actually rendering to both simultaneously. With the X11 driver, that restore is expensive and causes X windows to be destroyed and recreated, which causes rendering failures. The proper solution is for D3D to target a different object which maintains separate metadata. > This may require the driver to > maintain a separate D3D pixel format, and possibly two surfaces, or > maybe one surface recreated as needed once the app uses WGL again, but I > don't see why it would justify adding an API to manage an arbitrary > number of surfaces. I already explained. In the multi-threaded case, one thread can still be using an old surface after another thread released it and created a new one. Beyond that, although I'm not aware of a case where an app uses two D3D devices to target the same window, I'm also not seeing anything in the docs which says it's not allowed. For example, IDirect3DSwapChain9::Present() takes an hDestWindowOverride parameter which causes that particular present to target a window that was previously unrelated to the swapchain. I see nothing in the docs that suggest there's a limitation on which window you can use (other than that it be visible or top-level). No error code meaning "invalid window" or "window format mismatch". In any case, once you have support for two surfaces, you're already supporting multiple surfaces. The code would not be especially (any?) simpler if it were limited to one WGL surface and one D3D surface per window. -Ken

May 7, 2014

Re: shell32: Use SW_HIDE with ShellExecuteA in tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at 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

May 7, 2014

Re: [PATCH 1/2] include: Added atlcom.h

by Qian Hong

On Wed, May 7, 2014 at 11:55 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > I think you should add this new header to include/Makefile.in. > Thanks a lot, I missed it. Will resend. -- Regards, Qian Hong - http://www.codeweavers.com

May 7, 2014

Re: [PATCH 1/2] include: Added atlcom.h

by Vincent Povirk

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

May 7, 2014

Re: [PATCH] user32: Don't depend on HMENU being valid for popup menus

by Andrew Eikum

On Wed, May 07, 2014 at 06:09:44AM -0500, Ken Thomases wrote: > 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. > Unless I'm mistaken, these issues existed before this patch as well. DestroyMenu has always closed the handle, and additionally destroyed the struct. Now we preserve the struct if it's referenced by another menu. > > 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. > There is some precedent for Windows returning an invalid HMENU. See the second GetMenuItemInfoA call in test_subpopup_locked_by_menu which returns the handle of the submenu that was just destroyed. > > @@ -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. > This is a pretty straightforward change, so I wrote a new patch to clean it up. > 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. > Yes, we should head in this direction. It would be really nice to clean up the use-after-free FIXME in MENU_GetMenu. I think that's outside the scope of this particular patch, though. > 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. > It feels right to me, at least. Thanks for reviewing! Andrew

May 7, 2014

Re: [PATCH] user32: Don't depend on HMENU being valid for popup menus

by Andrew Eikum

On Tue, May 06, 2014 at 04:34:21PM -0500, Vincent Povirk wrote: > 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? > Yes, it's debugging code. The dangers of sending really large patches... > 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. > We don't have any tests for this, though MSDN agrees with you. I'm surprised that adding a submenu transfers the HMENU ownership to the owning menu. I'll add a DestroyMenu call for submenus in MENU_ReleaseMenu, which should close the handle and release the final reference. I fixed the other errors you pointed out. Thanks for reviewing! Andrew

May 7, 2014

Re: [2/2] dpnet: Implement IDirectPlay8Client Initialize (try 2)

by Stefan Dösinger

-----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-----

May 7, 2014

Re: [1/2] dpnet: Add IDirectPlay8Client tests (try 2)

by Stefan Dösinger

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

May 7, 2014

Re: dplayx: Initial msgtid variable

by Stefan Dösinger

-----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-----

May 7, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Alexandre Julliard

Ken Thomases <ken(a)codeweavers.com> writes: > On May 7, 2014, at 4:57 AM, Alexandre Julliard wrote: > >> Sure, but IMO if the driver needs this it's doing something wrong. Maybe >> I just don't understand what you are trying to do, but the notion of an >> arbitrary number of surfaces per window doesn't make any sense to me. > > I'm writing a WGL extension with a function for creating surfaces. > There's one implicit for WGL when the app sets a pixel format on a > window, but we want wined3d to create separate ones to avoid messing > up externally visible state. Wined3d may create a surface for a > window, use it, and then tear it down. However, other threads may > still have a DC referencing that surface and have a context current on > it. They will eventually clear that up when they next call into > wined3d, but there's an indefinite period before that happens. > Meanwhile, the first thread may create a new surface for the window. > Etc. > > Each of these surfaces may have different pixel formats. In the X11 driver, a different pixel format implies a different FBConfig and a different visual, so requires a new X window. > > Yes, there's a question about what happens if multiple surfaces are > actually being used for rendering simultaneously. Only one can be > seen at a time, so what's the point, right? In my current patches, > the most recent one created is in front and visible. I've got plans > to make it so that the one most recently made current for a context > will be in front. I don't see why D3D would need anything like that. Do you really need to be able to set a new pixel format but still draw with the old one and expect the output to be visible? It seems to me all you really want is to restore the pixel format after D3D has used it, to avoid messing up WGL. This may require the driver to maintain a separate D3D pixel format, and possibly two surfaces, or maybe one surface recreated as needed once the app uses WGL again, but I don't see why it would justify adding an API to manage an arbitrary number of surfaces. What are the use cases for this? -- Alexandre Julliard julliard(a)winehq.org

May 7, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Ken Thomases

On May 7, 2014, at 4:57 AM, Alexandre Julliard wrote: > Sure, but IMO if the driver needs this it's doing something wrong. Maybe > I just don't understand what you are trying to do, but the notion of an > arbitrary number of surfaces per window doesn't make any sense to me. I'm writing a WGL extension with a function for creating surfaces. There's one implicit for WGL when the app sets a pixel format on a window, but we want wined3d to create separate ones to avoid messing up externally visible state. Wined3d may create a surface for a window, use it, and then tear it down. However, other threads may still have a DC referencing that surface and have a context current on it. They will eventually clear that up when they next call into wined3d, but there's an indefinite period before that happens. Meanwhile, the first thread may create a new surface for the window. Etc. Each of these surfaces may have different pixel formats. In the X11 driver, a different pixel format implies a different FBConfig and a different visual, so requires a new X window. Yes, there's a question about what happens if multiple surfaces are actually being used for rendering simultaneously. Only one can be seen at a time, so what's the point, right? In my current patches, the most recent one created is in front and visible. I've got plans to make it so that the one most recently made current for a context will be in front. I don't know what happens on Windows if WGL and D3D are used simultaneously against the same window, or if two D3D devices or swapchains attempt to simultaneously target the same window. The tests already show that using D3D on a window which has had a WGL pixel format set on it doesn't generate errors. And we know that some games do that. I just don't know if they actually make a context current or try rendering while D3D is in use. The wined3d code certainly assumes that the app may have made a WGL context current before calling into it and goes to the trouble of restoring it before returning. In any case, if D3D is used temporarily, then after it's done (on all threads) we'd like the window to be returned to a state as though D3D were never used on it. If no WGL pixel format had been set, then it should have no surfaces and user32 and gdi32 should resume normal rendering. If one had been set, then it should have just the WGL surface. -Ken

May 7, 2014

Re: [PATCH] user32: Don't depend on HMENU being valid for popup menus

by Ken Thomases

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

May 7, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Alexandre Julliard

Ken Thomases <ken(a)codeweavers.com> writes: > It's the difference between code which, when a surface is destroyed, > simply decrements that count in user32 vs. one which has to search in > two different lists to see if there are any remaining surfaces for > that window and, if there aren't, clearing the "flag" in user32. It's > not particularly difficult, it's just simpler and cleaner with a > count. Putting it in the driver means adding complexity into each > driver. > > This entire piece of functionality in user32 is for the benefit of the > driver. It's all implementation detail. I don't understand why it > shouldn't take the form that's most suited to the needs of the driver. Sure, but IMO if the driver needs this it's doing something wrong. Maybe I just don't understand what you are trying to do, but the notion of an arbitrary number of surfaces per window doesn't make any sense to me. -- Alexandre Julliard julliard(a)winehq.org

May 7, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Ken Thomases

On May 7, 2014, at 3:17 AM, Alexandre Julliard wrote: > Ken Thomases <ken(a)codeweavers.com> writes: > >> Well, it doesn't make much sense for user32 to know the particular pixel format, either. There's not a single pixel format for each window. WGL and D3D can use separate formats. That's at the center of what I'm doing. >> >> A change to use a boolean flag instead of a pixel format ID would be as complicated for user32 as this patch and would make the driver work more complicated. > > It's already treated as a flag as you noted, so I don't see why you'd > need to change anything. The _effect_ is of a flag, but it's called a pixel format. It'd be nice to fix its name to match its interpretation. And, besides the renaming, the only other change that my patch made to user32 was changing a single "=" to "+=". I don't feel like it's adding much in the way of complexity. >> It seems to me that this is purely a practical matter. We need user32 to behave differently when there's any GL surface(s) than when there are none. Something has to keep count and it seems simplest to track the count in user32. > > Surely the driver already knows if there are surfaces, I don't see why > you need a count at all, much less in user32. It's the difference between code which, when a surface is destroyed, simply decrements that count in user32 vs. one which has to search in two different lists to see if there are any remaining surfaces for that window and, if there aren't, clearing the "flag" in user32. It's not particularly difficult, it's just simpler and cleaner with a count. Putting it in the driver means adding complexity into each driver. This entire piece of functionality in user32 is for the benefit of the driver. It's all implementation detail. I don't understand why it shouldn't take the form that's most suited to the needs of the driver. -Ken

May 7, 2014

Re: [PATCH 2/2] gdi32: Report unsubstituted font face names.

by Alexandre Julliard

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

May 7, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Alexandre Julliard

Ken Thomases <ken(a)codeweavers.com> writes: > Well, it doesn't make much sense for user32 to know the particular pixel format, either. There's not a single pixel format for each window. WGL and D3D can use separate formats. That's at the center of what I'm doing. > > A change to use a boolean flag instead of a pixel format ID would be as complicated for user32 as this patch and would make the driver work more complicated. It's already treated as a flag as you noted, so I don't see why you'd need to change anything. > It seems to me that this is purely a practical matter. We need user32 to behave differently when there's any GL surface(s) than when there are none. Something has to keep count and it seems simplest to track the count in user32. Surely the driver already knows if there are surfaces, I don't see why you need a count at all, much less in user32. -- Alexandre Julliard julliard(a)winehq.org

May 7, 2014

Re: [PATCH] comctl32/tests: Fix propsheet and listview tests which depend on being in foreground.

by Nikolay Sivov

> @@ -587,6 +587,7 @@ static HWND create_parent_window(BOOL Unicode) > WS_MAXIMIZEBOX | WS_VISIBLE, > 0, 0, 100, 100, > GetDesktopWindow(), NULL, GetModuleHandleA(NULL), NULL); > + force_set_foreground_window(hwnd); > SetWindowPos( hwnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOSIZE|SWP_NOMOVE ); > return hwnd; > } I don't know about propsheet part, but for a listview you're setting parent to foreground, does it mean that lately created child listview will be foreground as well? Cause failing test is about mouse movements over listview, not its parent.

May 7, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Ken Thomases

On May 6, 2014, at 10:23 PM, Ken Thomases wrote: > Leaving aside the specifics of the implementation (i.e. the WGL_WINE_surface extension), conceptually, either or both of WGL and D3D need to be able to independently tell user32 to make this change in its behavior. Oh, and D3D's requests can be temporary. -Ken

May 6, 2014

Re: comctl32: Make Treeview Notify the parent on a return key press

by Nikolay Sivov

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

May 6, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Ken Thomases

On May 6, 2014, at 8:42 AM, Alexandre Julliard wrote: > 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. Well, it doesn't make much sense for user32 to know the particular pixel format, either. There's not a single pixel format for each window. WGL and D3D can use separate formats. That's at the center of what I'm doing. A change to use a boolean flag instead of a pixel format ID would be as complicated for user32 as this patch and would make the driver work more complicated. It seems to me that this is purely a practical matter. We need user32 to behave differently when there's any GL surface(s) than when there are none. Something has to keep count and it seems simplest to track the count in user32. Leaving aside the specifics of the implementation (i.e. the WGL_WINE_surface extension), conceptually, either or both of WGL and D3D need to be able to independently tell user32 to make this change in its behavior. -Ken

May 6, 2014

Re: [1/2] dpnet: Add IDirectPlay8Client tests

by Alistair Leslie-Hughes

> 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. A usual approach is to only have a single client, so I've changed the init function to fail if we don't have a client pointer. >> + 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. Since we are running asynchronously, this is the default return value. > >> + 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? No, I don't know where these value come from. However they seem to be same between windows versions. Best Regards Alistair Leslie-Hughes

May 6, 2014

Re: [PATCH 2/2] gdi32: Report unsubstituted font face names.

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

May 6, 2014

Re: Testbot returning 500 - Internal server error message

by Francois Gouget

On Tue, 6 May 2014, Bruno Jesus wrote: > 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 I believe this is fixed. The web server just needed to be restarted after the WineTestBot code update. Let me know if you still get this error. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, it's computer science.

May 6, 2014

[PATCH] comctl32/tests: Fix propsheet and listview tests which depend on being in foreground.

by Bernhard Übelacker

-----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-----

May 6, 2014

Re: [PATCH] user32: Don't depend on HMENU being valid for popup menus

by Vincent Povirk

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.

May 6, 2014

Testbot returning 500 - Internal server error message

by Bruno Jesus

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

May 6, 2014

Re: [1/2] dpnet: Add IDirectPlay8Client tests

by Stefan Dösinger

-----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-----

May 6, 2014

Re: setupapi: SetupDiGetClassDevsExW should ignore DIGCF_ALLCLASSES if class set

by Mark Harmstone

Sorry, I'm not sure - I'm very new to this. It looks like something very similar is going on at dlls/setupapi/tests/devinst.c:1078 already. Unless you've manually created the relevant entries under HKLM\System\CurrentControlSet the function wouldn't work anyway. On 06/05/14 15:38, Nikolay Sivov wrote: > Is it possible to add a test for that?

May 6, 2014

Wine talk at Linuxwochen Österreich

by Stefan Dösinger

-----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-----

May 6, 2014

Re: setupapi: SetupDiGetClassDevsExW should ignore DIGCF_ALLCLASSES if class set

by Henri Verbeet

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;"

May 6, 2014

Re: [PATCH] gdi32: Report unsubstituted font face names.

by Alexandre Julliard

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

May 6, 2014

Re: setupapi: SetupDiGetClassDevsExW should ignore DIGCF_ALLCLASSES if class set

by Nikolay Sivov

Is it possible to add a test for that?

May 6, 2014

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.

by Alexandre Julliard

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

May 6, 2014

Re: [PATCH 3/5] server: Add socket-side support for the interface change notification object (resend).

by Alexandre Julliard

"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

May 6, 2014

Re: [PATCH 2/5] server: Add delayed processing for socket-specific ioctl() (resend).

by Alexandre Julliard

"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

May 6, 2014

Re: [PATCH 2/3] winex11.drv: copy and paste files to/from X11 apps (try 2)

by Alexandre Julliard

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

May 6, 2014

Re: wined3d: Add a registry setting, DisabledExtensions, to disable the use of OpenGL and WGL extensions.

by Henri Verbeet

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.

May 6, 2014

Re: winex11: Silence a noisy winediag ERR in xrandr12_init_modes

by Henri Verbeet

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.

May 6, 2014

Re: [PATCH 5/5] ws2_32: Add an interactive test for interface change notifications (resend).

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

May 5, 2014

Re: Working on ATL, more real world test case needed

by Vincent Povirk

> Could you confirm that the structure ATL_PROPMAP_ENTRY and the > prototype of AtlIPersistStreamInit_Load/AtlIPersistStreamInit_Save/AtlIPersistPropertyBag_Load/AtlIPersistPropertyBag_Save > are all in atlcom.h? Are they in any IDL files? I'll send a patch to > add these structure and prototype if they are in header files or IDL > files. Yep, those are all in atlcom.h. They're not in idl files.

May 5, 2014

Re: [PATCH 2/5] wined3d: Validate and handle query size parameter. (try 2)

by Henri Verbeet

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.

May 5, 2014

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 2)

by Henri Verbeet

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.)

May 5, 2014

Re: [PATCH] setupapi: Implement a binary compatible string table

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=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

May 4, 2014

Re: Wine Test analysis, report

by André Hentschel

Am 02.05.2014 22:03, schrieb Francois Gouget: > > * I've put the Vista 64-bit VM back online yesterday. Since it's an > Ultimate edition I configured it for Arabic so we have a RTL test > configuration. That VM also runs the tests from the E: drive instead > of the usual C: drive so if tests make incorrect drive assumptions we > should catch them. Finally it also has WinPcap and the various extar > DirectX, msxml and Visual C++ runtime components. I did some wpcap tests recently and somethings different between xp and vista64: https://testbot.winehq.org/JobDetails.pl?Key=6811 Are there different network setups on those machines, e.g. the vista one having more networks than xp, or something like that?

May 4, 2014

Re: Use WINE API from ELF application.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-03 12:17, schrieb John Found: > Is it possible to use the WINE functionality from inside regular > ELF application. For example starting and debugging Windows > application. Creating windows, etc. Sort of. See http://wiki.winehq.org/Winelib . You can create a Windows application that is an ELF binary and can link normally to other Linux libraries. But this binary has to run inside a full Wine environment. You probably want to simply do -luser32 -lkernel32 when linking your application and not bother about the rest of the Wine environment. Unfortunately this is not possible - there are parts of the Windows API that need more than just a library, like the Windows registry. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTZh1oAAoJEN0/YqbEcdMwhO0P/1S34BPMLbAiTWahp9LT+iuy 0M2YUe50cCItdVNLpEW4fWc9GEPULGoSSryL6lfxz+JZinak1jtL4eDAG0mHH84K tO/Zhx0i9AdOBruZoWwbJ9H4BVgsQPm08ATdL0c8ApndilKdCPW+3GqO8iNXG8+1 GWwFEYfQKUbqO3cW3OjK26LE1gbOkPWXVlqWgzgrXIon3RHrDjeV7UK4kyZD4+yh pX5I6SPkxaYJoEJMROKT4MpJ4w+k3WnL2WJX18dBesTGNOVmEpjwkehy2zV7VddE uuUvmamtUXN4+laeM1MrUgIFz1A5vfMFYeV9Yw+8wnz07tPtjic0sfy+L00wd3QD 08cC6NMokk6cdAWP2sVKmScScC2/cU7L9tjBn6M0eKpMgLJ3Z0uFFGgLfnRXIYuQ xLMVy2YyZG1T9feC6CFiOUg8FngqNxn7mVbQ1qtRSw/6JAJVCWBdidkZvCx6eYoA oQ4OzebIKUjPFXw5Cqpb/owdw1wTi67CgUk5fwq03jFjqq8IEpKxZNKBIAmVvg74 sy6VoLtYzYCyXKyi+R8A4gvMegemwqIu5xLDBkzMbeXmC27E0MoQ6b2hl5VC/DMQ CaNECuiciaER59VA9D/Z++t2Hp0TgPom+5lKVT8FEz0miiwLww1wDjDvfRQYRBX6 1v/ZES18LTcRAm5AEgh7 =ywNI -----END PGP SIGNATURE-----

May 4, 2014

Re: Failing tests on testbots because of missing focus

by Francois Gouget

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>

May 4, 2014

Re: Wine Test analysis, report

by Saulius Krasuckas

* On Fri, 2 May 2014, Francois Gouget wrote: > > Concerning the test results: ... > * The 32-bit Windows 8 VM seems to complete the tests in time but it > has 52 failures for the one run I checked and thus its results are > ignored too. I've run WRT on 64-bit Win 8.1 on a physical machine some day ago. Tail of the output: Running: Done (517 of 517) Cleaning up - 63 failures Warning: 63 tests failed, there's probably something broken with your setup. You need to address this before submitting results. Finished - 63 failures This is notebook with usual workspace / configuration. The message is misleading or the limit is too low. Should I send a patch? S.

May 3, 2014

Re: Working on ATL, more real world test case needed

by Qian Hong

On Sat, May 3, 2014 at 3:24 AM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > ATL_PROPMAP_ENTRY is the same from atl71 through atl90. In atl100 and > atl110 it looks like this: Thanks Vincent, that helps a lot! Could you confirm that the structure ATL_PROPMAP_ENTRY and the prototype of AtlIPersistStreamInit_Load/AtlIPersistStreamInit_Save/AtlIPersistPropertyBag_Load/AtlIPersistPropertyBag_Save are all in atlcom.h? Are they in any IDL files? I'll send a patch to add these structure and prototype if they are in header files or IDL files. Thanks for the links as well! -- Regards, Qian Hong - http://www.winehq.org

May 3, 2014

Use WINE API from ELF application.

by John Found

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>

May 3, 2014

Re: [PATCH] vbscript: Fixed CBool(try 3)

by Shuai Meng

2014-05-02 21:10 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 05/02/14 14:10, Piotr Caban wrote: > >> 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 >> > The tests are also failing on windows with polish locale. It's caused by > different decimal separator. Please disable this tests on non-english > locale: > Call ok(CBool("0.1") = True, "CBool(""0.1"") = " & CBool("0.1")) > Call ok(getVT(CBool("0.1")) = "VT_BOOL", "getVT(CBool(""0.1"")) = " & > getVT(CBool("0.1"))) > > Also it turns out that "Prawda" string (True translated to polish) is > working on windows with polish locale. This means that you were right using > VARIANT_LOCALBOOL flag in VariantChangeType. Sorry for that. > > Thanks, > Piotr > Well, about two weeks ago I tested CStr(True) = "True" on windows with different locales, and I'd like to share the results. Maybe they can help in the future. When locale is zh_CN, ko_KR, ja_JP : CStr(True) = "True" and CStr(False) = "False" can pass directly while others caused an error. de_DE：CStr(True) = "Wahr"; CStr(False) = "Falsch" ru_RU: CStr(True) = "\0418\0441\0442\38\043d\0430"; CStr(False) = "\041b\043e\0436\044c" pl_PL: CStr(True) = "Prawda"; CStr(False) = "Fa\0142sz" fr_FR : CStr(True) = "Vrai"; CStr(False) = "Faux" Thanks.

May 3, 2014

Re: [PATCH] vbscript: Fixed CBool(try 4)

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=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

May 2, 2014

Re: dpnet/tests: Add a trailing '\n' to an ok() call.

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

May 2, 2014

Re: Building Wine conformance tests on Windows

by Dmitry Timoshkov

Albert Szilvasy <albert.szilvasy(a)autodesk.com> wrote: > RE: the test needs to be fixed > > There are lots of other errors. It looks like nobody has tried to build > against the windows sdk headers for some time. I could try to fix it but > if this isn't the way people work then it will get broken again and again. > I'd rather stay on the beaten path than bushwhack on some old overgrown > trail. I routinely build Wine tests with PSDK headers and tools when I start working on some area in Wine which needs tests. Probably a few other people build Wine tests under Windows as well, but probably most of developers simply crosscompile since it's way easier. > RE: Another solution is to build with the Wine headers > > I've also tried this and it gets me further but not all the way. I'm just > trying to build the kernel32 tests for now and I get a linker error: > volume.obj : error LNK2019: unresolved external symbol _strcasecmp > referenced in function _test_GetVolumePathNameA > > This is expected since _strcasecmp is called stricmp on Windows. A test failing to compile with PSDK is a bug, and eventually should be fixed. I'd suggest to limit the effort by the tests you really need at this point and make only them build with PSDK as an exersize, once you do it fixing other tests will be much easier. -- Dmitry.

May 2, 2014

Re: Wine Test analysis, report

by Francois Gouget

On Fri, 25 Apr 2014, Jeremy White wrote: [...] > I'm waiting for Francois to report that things are essentially operational > again; until I get that word, I'm not planning to beat the drum. Here's the belated status update. In short the WineTestBot is essentially operational. * I've put the Vista 64-bit VM back online yesterday. Since it's an Ultimate edition I configured it for Arabic so we have a RTL test configuration. That VM also runs the tests from the E: drive instead of the usual C: drive so if tests make incorrect drive assumptions we should catch them. Finally it also has WinPcap and the various extar DirectX, msxml and Visual C++ runtime components. * I have not checked the revert times yet. They are definitely not catastrophic but I'm not sure they are very good either (maybe on the order of 1 to 3 minutes for some VMs but I could be wrong). * There are some VM configuration changes that could be useful. For instance it seems testing Chinese rather than Japanese would better exercise the font association code. Also it would be interesting to have the systray in a non default position. Working those in should not be too hard so I'll try to do it at some point. Concerning the test results: * The MSI tests are timing out on XP, Windows 2008 and Windows 7 64-bit. I'm using the same disk configuration as before so they have no particular reason to be slow. Since the timeouts don't happen with all the VMs, maybe it's a Windows configuration issue rather than a VM configuration one. * The ntdll:exception test crashes instead of having failures. That's because we switched the processor form AMD to Intel. Huw submitted a patch that should fix this so there's hope this will be fixed at some point. * The results of the 64-bit Windows 8 VM are being ignored. That's because it does not complete the tests within the alloted 30 minutes. The fault with dpnet:address, dpnet:peer, dpnet:server, msi:action, msi:msi which all time out, accounting for 10 minutes. I forgot to retweak the Windows 8 configuration to avoid the dpnet timeouts. I guess I'll have to readd them. * The 32-bit Windows 8 VM seems to complete the tests in time but it has 52 failures for the one run I checked and thus its results are ignored too. But for now I will focus on fixing the issues with the WineTestBot engine code: if I ask Alexandre to restart it again he'll blow a gasket ;-) Also I want to put an end to the network read timeout errors so we no longer get boterrors. And when an error happens I also want the WineTestBot engine to better handle them, for instance if there was a network outage while running a test, that test should be requeued for when the network is back. -- Francois Gouget <fgouget(a)codeweavers.com>

May 2, 2014

Re: Building Wine conformance tests on Windows

by Julius Schwartzenberg

Albert Szilvasy wrote: > RE: the test needs to be fixed > > There are lots of other errors. It looks like nobody has tried to build against the windows sdk headers for some time. I could try to fix it but if this isn't the way people work then it will get broken again and again. I'd rather stay on the beaten path than bushwhack on some old overgrown trail. At least the avifil32 tests were known not to build on Windows and it is not trivial to fix the problem. If you just need the tests, cross-compilation is easy. If you really need to build on Windows, I suspect that getting at least the most important tests to build would be possible without much effort, but I could be completely wrong. Best regards, Julius

May 2, 2014

Re: Building Wine conformance tests on Windows

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-02 19:34, schrieb Albert Szilvasy: > There are lots of other errors. It looks like nobody has tried to > build against the windows sdk headers for some time. I could try to > fix it but if this isn't the way people work then it will get > broken again and again. I'd rather stay on the beaten path than > bushwhack on some old overgrown trail. I am building the d3d tests and libraries with Visual Studio 2013. I sent a number of patches to fix them, but I am sure many more remain outside the d3d code. I'm also using Wine's headers because I am building parts of the implementation as well. I am using Microsoft's import libraries where possible. This currently fails for d3d8 (because it doesn't exist any longer) and d3dcompiler (because D3DDisassemble is a private export). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTY/HcAAoJEN0/YqbEcdMwUIgP/39a8gnOG6Q4ZOsjkdUNf7Eg cLlSB7FBaH+ePPC/7dxExYAvov7rPFMF1n7L9Wr4zSJTiffEEWZE1NPYsscrVZvS SJxB/tbHZNIDwVhf7+cs2Un8ExtUG9YMj0kL8B2KCyikiY5fa2vi+mgOuO1uIzPP GnKmuySPFtMyUGYtohvPlh1y2qOgWbAFgLuXTx4wtpJx/DMNmzs8escbIeEvhXmT BO5QuF6BFDawMq1k5pSW7UFezHp7gsoNj8OeuI2iJNEp/QilZtl0JJoRNo7ePrKc K86f1EW5KbsbHElnNFL/QiselAyGdTpyWIjXvVuX7sDM+sQQCKg2LZjWcx72svk/ LULZ9GZo/816ZHHKhoAnMCZyEf1D8qwMe1lnwkv4aZKmt0//+imSNQrZfctkpF/S sNnRwDPdGKKuzsCyZrK16FetYSwjHKC6gHKEDEnIL/lL41nsoshrkjCPZub+cdT/ g5waUORYUGmgQ7pUuv/UD8umFTwLqlR8j7SMa/aaPtsKN/o4TlO2OrN23USha3ds 0MXYAkZxgQdoQWBENbNdub76FYH/45furiCtXkbpfvNeUENuXbHCVA5o9M7TGU7I 2gpLvukO3AoXEkh1XM8VU5SZJCGl9G2o7HwbxOSyY0k/GAJNNY1uS+l3MScVOk03 wmcivp9mstSOrINl7g5H =J/JN -----END PGP SIGNATURE-----

May 2, 2014

Re: Working on ATL, more real world test case needed

by Vincent Povirk

ATL_PROPMAP_ENTRY is the same from atl71 through atl90. In atl100 and atl110 it looks like this: struct ATL_PROPMAP_ENTRY { LPCOLESTR szDesc; const CLSID* pclsidPropPage; const IID* piidDispatch; void *rgclsidAllowed; DWORD cclsidAllowed; DISPID dispid; DWORD dwOffsetData; DWORD dwSizeData; VARTYPE vt; }; While the structure itself is undocumented, there are documented macros that create it: http://msdn.microsoft.com/en-us/library/ee845406.aspx http://msdn.microsoft.com/en-us/library/ee845404.aspx For the callback macros, the callback function is stored in rgclsidAllowed, and cclsidAllowed is 0. The only public mention of the callback signature I could find is in this article: http://msdn.microsoft.com/en-gb/vstudio/ee309358.aspx

May 2, 2014

Re: ole32/tests: Add a trailing '\n' to an ok() call.

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

May 2, 2014

Re: Working on ATL, more real world test case needed

by Vincent Povirk

I was doing some work earlier with Piotr (which has now stalled for some reason) on implementing MFC. We settled on an approach where I would use the MS headers to describe to him the ABI without implementation details (by writing headers and test cases mostly), and he would implement the actual library. The ATL headers are related, so I should be able to at least get you the correct struct layouts for all versions. I may also be able to build test programs in MSVC, if that would help.

May 2, 2014

Re: Building Wine conformance tests on Windows

by Michael Stefaniuc

On 05/02/2014 07:44 PM, Henri Verbeet wrote: > On 2 May 2014 19:34, Albert Szilvasy <albert.szilvasy(a)autodesk.com> wrote: >> This really makes me wonder if building these tests on Windows is at all viable. It seems that people use some other method to build this stuff. I've checked winetest64.exe from http://test.winehq.org/data/ and it definitely wasn't built with the Microsoft toolset. I think I'll move on and try to cross compile on Linux, I suspect that's the beaten path. >> > If you only care about building the tests to run them on Windows (as > opposed to building the tests on Windows specifically), I think "make > crosstest" is the easiest way. You may have to install mingw-w64 for > that to work. In that case there is even an easier solution: Just throw the patch at the WineTestBot https://testbot.winehq.org/ You can then download the binary from there in addition to have the testbot run it on its Windows VMs. bye michael

May 2, 2014

Working on ATL, more real world test case needed

by Qian Hong

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

May 2, 2014

Re: Building Wine conformance tests on Windows

by Henri Verbeet

On 2 May 2014 19:34, Albert Szilvasy <albert.szilvasy(a)autodesk.com> wrote: > This really makes me wonder if building these tests on Windows is at all viable. It seems that people use some other method to build this stuff. I've checked winetest64.exe from http://test.winehq.org/data/ and it definitely wasn't built with the Microsoft toolset. I think I'll move on and try to cross compile on Linux, I suspect that's the beaten path. > If you only care about building the tests to run them on Windows (as opposed to building the tests on Windows specifically), I think "make crosstest" is the easiest way. You may have to install mingw-w64 for that to work.

May 2, 2014

RE: Building Wine conformance tests on Windows

by Albert Szilvasy

Thanks Dimitry, I'm new to wine so please excuse my naïveté and ignorance. RE: the test needs to be fixed There are lots of other errors. It looks like nobody has tried to build against the windows sdk headers for some time. I could try to fix it but if this isn't the way people work then it will get broken again and again. I'd rather stay on the beaten path than bushwhack on some old overgrown trail. RE: Another solution is to build with the Wine headers I've also tried this and it gets me further but not all the way. I'm just trying to build the kernel32 tests for now and I get a linker error: volume.obj : error LNK2019: unresolved external symbol _strcasecmp referenced in function _test_GetVolumePathNameA This is expected since _strcasecmp is called stricmp on Windows. This really makes me wonder if building these tests on Windows is at all viable. It seems that people use some other method to build this stuff. I've checked winetest64.exe from http://test.winehq.org/data/ and it definitely wasn't built with the Microsoft toolset. I think I'll move on and try to cross compile on Linux, I suspect that's the beaten path. albert -----Original Message----- From: Dmitry Timoshkov [mailto:dmitry.timoshkov(a)gmail.com] On Behalf Of Dmitry Timoshkov Sent: Thursday, May 1, 2014 22:40 To: Albert Szilvasy Cc: wine-devel(a)winehq.org Subject: Re: Building Wine conformance tests on Windows Albert Szilvasy <albert.szilvasy(a)autodesk.com> wrote: > 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. In this particular case the test needs to be fixed. Another solution is to build with Wine headers. -- Dmitry.

May 2, 2014

Re: [PATCH] ddraw/tests: Add a test for getdc palette handling (try 3).

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=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.

May 2, 2014

Re: [PATCH] vbscript: Fixed CBool(try 3)

by Piotr Caban

On 05/02/14 17:08, Shuai Meng wrote: > I have done the things above, anythings else to be noticed? If not, I > will resend this patch after testing it. I don't see other problems related to that patch. Thanks, Piotr

May 2, 2014

Re: [PATCH] vbscript: Fixed CBool(try 3)

by Shuai Meng

2014-05-02 21:10 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 05/02/14 14:10, Piotr Caban wrote: > >> 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 >> > The tests are also failing on windows with polish locale. It's caused by > different decimal separator. Please disable this tests on non-english > locale: > Call ok(CBool("0.1") = True, "CBool(""0.1"") = " & CBool("0.1")) > Call ok(getVT(CBool("0.1")) = "VT_BOOL", "getVT(CBool(""0.1"")) = " & > getVT(CBool("0.1"))) > > Also it turns out that "Prawda" string (True translated to polish) is > working on windows with polish locale. This means that you were right using > VARIANT_LOCALBOOL flag in VariantChangeType. Sorry for that. > > Thanks, > Piotr > I have done the things above, anythings else to be noticed? If not, I will resend this patch after testing it.

May 2, 2014

Re: [PATCH 3/3] wined3d: Remove broken gdi palette code.

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=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.

May 2, 2014

Re: [PATCH] vbscript: Fixed CBool(try 3)

by Piotr Caban

On 05/02/14 16:03, Shuai Meng wrote: > That's all right. So need I test the patch in other locales such as > French or German on both wine and windows? The idea is that the tests should pass on every windows and wine no matter what locale is set. I think that you don't have to do it yourself. Hopefully in most cases testbot will catch the problems (it has some non-english test machines).

May 2, 2014

Re: [PATCH] vbscript: Fixed CBool(try 3)

by Shuai Meng

2014-05-02 21:10 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 05/02/14 14:10, Piotr Caban wrote: > >> 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 >> > The tests are also failing on windows with polish locale. It's caused by > different decimal separator. Please disable this tests on non-english > locale: > Call ok(CBool("0.1") = True, "CBool(""0.1"") = " & CBool("0.1")) > Call ok(getVT(CBool("0.1")) = "VT_BOOL", "getVT(CBool(""0.1"")) = " & > getVT(CBool("0.1"))) > > ok. > Also it turns out that "Prawda" string (True translated to polish) is > working on windows with polish locale. This means that you were right using > VARIANT_LOCALBOOL flag in VariantChangeType. Sorry for that. > > That's all right. So need I test the patch in other locales such as French or German on both wine and windows? > Thanks, > Piotr >

May 2, 2014

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

by Henri Verbeet

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.

May 2, 2014

Re: [PATCH 2/3] ddraw/tests: Test mipmap GetDC behavior.

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=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.

May 2, 2014

Re: [PATCH] vbscript: Fixed CBool(try 3)

by Piotr Caban

On 05/02/14 14:10, Piotr Caban wrote: > 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 The tests are also failing on windows with polish locale. It's caused by different decimal separator. Please disable this tests on non-english locale: Call ok(CBool("0.1") = True, "CBool(""0.1"") = " & CBool("0.1")) Call ok(getVT(CBool("0.1")) = "VT_BOOL", "getVT(CBool(""0.1"")) = " & getVT(CBool("0.1"))) Also it turns out that "Prawda" string (True translated to polish) is working on windows with polish locale. This means that you were right using VARIANT_LOCALBOOL flag in VariantChangeType. Sorry for that. Thanks, Piotr

May 2, 2014

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

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=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.

May 2, 2014

Re: [PATCH] vbscript: Fixed CBool(try 3)

by Piotr Caban

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

May 2, 2014

Re: [PATCH] user32: Don't destroy in-use menus

by Andrew Eikum

On Thu, May 01, 2014 at 04:38:44PM -0500, Ken Thomases wrote: > 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. > I see what you mean. I had thought the submenu handle was used in the TrackPopupMenu test directly, but it actually gets the parent menu handle. Meaning we don't need to keep the submenu handle valid, even though GetMenuItemInfo actually returns the destroyed submenu handle. > DestroyMenu() should really destroy the handle (and thus decrement the reference count), not just mark it as "destroyed". > I'll try this along with your handle/struct separation suggestion. Thanks for reviewing. Andrew

May 2, 2014

Re: dpnet: Implement IDirectPlay8LobbiedApplication Initialize (try 2)

by Stefan Dösinger

-----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-----

May 2, 2014

Re: dpnet: Store DPN_SP_CAPS as part of the object

by Stefan Dösinger

-----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-----

May 2, 2014

Re: dpnet: Implement IDirectPlay8Client Initialize

by Alistair Leslie-Hughes

Hi Stefan, On 2/05/2014 3:06 AM, Stefan Dösinger wrote: > -----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. > This file is a copy of peer.c, changed to support the IDirectPlay8Client interface. Any tests that didn't currently pass are marked with todo_wine. I'm happy to submit only the tests if needed. Best Regards Alistair Leslie-Hughes

May 2, 2014

Re: Building Wine conformance tests on Windows

by Dmitry Timoshkov

Albert Szilvasy <albert.szilvasy(a)autodesk.com> wrote: > 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. In this particular case the test needs to be fixed. Another solution is to build with Wine headers. -- Dmitry.

May 2, 2014

Building Wine conformance tests on Windows

by Albert Szilvasy

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

May 2, 2014

Re: [PATCH] vbscript: Fixed CBool(try 3)

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=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

May 1, 2014

Re: [PATCH] user32: Don't destroy in-use menus

by Ken Thomases

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

May 1, 2014

Re: dpnet: Implement IDirectPlay8Client Initialize

by Stefan Dösinger

-----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-----

May 1, 2014

Re: dpnet: Implement IDirectPlay8LobbiedApplication Initialize

by Stefan Dösinger

-----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-----

May 1, 2014

Re: [PATCH 2/6] wined3d: Validate and handle query size parameter.

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=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).

May 1, 2014

Re: [PATCH 1/6] d3d9/tests: Test GetData behavior with various size values.

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=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).

May 1, 2014

Re: [PATCH] vbscript: Fixed CBool(try 2)

by Jacek Caban

On 05/01/14 16:38, Piotr Caban wrote: > >> These are the failing tests: >> Call testCBoolError("#TRUE#", 458) >> Call testCBoolError("#FALSE#", 458) >> Call testCBoolError(MyObject, 458) > In order to fix it you need to change the implementation. Probably you > need to check if string equals to "#TRUE#" and return early without > calling VariantChangeType. I'm not sure what needs to be done in > MyObject case. Actually, I'd like to see a cleaner solution than special casing specific strings. Jacek

May 1, 2014

Re: [PATCH] vbscript: Fixed CBool(try 2)

by Piotr Caban

On 05/01/14 15:22, Shuai Meng wrote: > I have changed the tests like this and they can pass on wine with no > failure. > 481 Sub testCBoolError > 482 on error resume next > 483 > 484 Call Err.clear() > 485 Call CBool("") > 486 Call ok(Err.number = 13, "Err.number = " & Err.number) > 487 > 488 Call Err.clear() > 489 Call CBool("#False#") > 490 Call ok(Err.number = 13, "Err.number = " & Err.number) > 491 > 492 Call Err.clear() > 493 Call CBool("#True#") > 494 Call ok(Err.number = 13, "Err.number = " & Err.number) > 495 > 496 Call Err.clear() > 497 Call CBool("MyObject") > 498 Call ok(Err.number = 13, "Err.number = " & Err.number) > 499 End Sub I think that previous way of implementing this tests was nicer. The results are different because you're testing different things (e.g. "MyObject" instead of MyObject, "#True#" instead of "#TRUE#"). > These are the failing tests: > Call testCBoolError("#TRUE#", 458) > Call testCBoolError("#FALSE#", 458) > Call testCBoolError(MyObject, 458) In order to fix it you need to change the implementation. Probably you need to check if string equals to "#TRUE#" and return early without calling VariantChangeType. I'm not sure what needs to be done in MyObject case. > As showed above, I have changed 458 into 13, and can pass on winxp. > However there two failures come nowhere like this: > run.c:1013: Test failed: api.vbs: L"Err.number = 0" > run.c:1013: Test failed: api.vbs: L"Err.number = 0" > I can't understand it: if Err.number = 0 then everything is right, why > does it come out? It's happening because on wine the test is succeeding while it's supposed to fail. > 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)) > > Ok, but does this mean I am testing object in the proper way? Currently you're only testing what happens if default value is unset (variant VT_EMPTY). This is just testing what happens if other values are returned.

May 1, 2014

Re: [PATCH 11/11] oleacc: Add tests for default client accessible object (try2)

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=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)

May 1, 2014

Re: [PATCH 11/11] oleacc: Add tests for default client accessible object

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

May 1, 2014

regsvr32 patches (argument handler, unicode)

by Hugh McMaster

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

May 1, 2014

Re: user32: Reduce the minimum Set[System]Timer from 15 ms to 10 ms.

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=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

May 1, 2014

Re: [PATCH] vbscript: Fixed CBool(try 2)

by Shuai Meng

Thank you for commenting. 2014-05-01 17:59 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > 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" > > I have changed the tests like this and they can pass on wine with no failure. 481 Sub testCBoolError 482 on error resume next 483 484 Call Err.clear() 485 Call CBool("") 486 Call ok(Err.number = 13, "Err.number = " & Err.number) 487 488 Call Err.clear() 489 Call CBool("#False#") 490 Call ok(Err.number = 13, "Err.number = " & Err.number) 491 492 Call Err.clear() 493 Call CBool("#True#") 494 Call ok(Err.number = 13, "Err.number = " & Err.number) 495 496 Call Err.clear() 497 Call CBool("MyObject") 498 Call ok(Err.number = 13, "Err.number = " & Err.number) 499 End Sub These are the failing tests: > Call testCBoolError("#TRUE#", 458) > Call testCBoolError("#FALSE#", 458) > Call testCBoolError(MyObject, 458) > > As showed above, I have changed 458 into 13, and can pass on winxp. However there two failures come nowhere like this: run.c:1013: Test failed: api.vbs: L"Err.number = 0" run.c:1013: Test failed: api.vbs: L"Err.number = 0" I can't understand it: if Err.number = 0 then everything is right, why does it come out? > 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)) > Ok, but does this mean I am testing object in the proper way?

May 1, 2014

Re: [PATCH] vbscript: Fixed CBool(try 2)

by Piotr Caban

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))

May 1, 2014

AW: imagehlp: Implement (parts of) BindImageEx (try 5)

by Bernhard Reiter

*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.

May 1, 2014

Re: msi: Expand REG_EXPAND_SZ keys when resolving AppSearch entries

by Hans Leidekker

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.

May 1, 2014

Re: [PATCH] vbscript: Fixed CBool(try 2)

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=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

May 1, 2014

Re: msi: Expand REG_EXPAND_SZ keys when resolving AppSearch entries

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=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

May 1, 2014