- wine-devel - winehq.org

Re: [PATCH 1/5] ddraw/tests: Move IDirect3DViewport::TransformVertices tests to ddraw1.c.
by Marvin 29 Aug '16

29 Aug '16

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=25437 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit d3d) === d3d.c:2051: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2235: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2382: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [v2 2/2] winejoystick.drv: Disable joysticks via wine registry on Mac
by Ken Thomases 29 Aug '16

29 Aug '16

Hi, On Aug 29, 2016, at 6:03 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > +static void char_device_name_length(IOHIDDeviceRef device, char *name, int max_length) > +{ > + CFStringRef str = copy_device_name(device); > + CFIndex len = CFStringGetLength(str); > + > + if (name) > + name[0] = 0; > + > + if (max_length >= len) > + { > + CFStringGetCString(str,name,max_length,kCFStringEncodingASCII); > + CFRelease(str); > + } > + else > + { > + CFStringRef substr = CFStringCreateWithSubstring(kCFAllocatorDefault, str, CFRangeMake(0, max_length)); > + CFRelease(str); > + CFStringGetCString(substr,name,max_length,kCFStringEncodingASCII); > + CFRelease(substr); > + } > +} I realize you based this function on code from DInput. Unfortunately, that code is pretty badly broken. CFStringGetLength() returns the length of the string in UTF-16 code units, which is basically the same as WCHARs. It's not meaningful to compare that to a buffer size that's in ASCII chars. Using ASCII is wrong, too. If the name has any non-ASCII characters in it, the conversion will just fail. Second, it's potentially unnecessarily restrictive. Your device_disabled_registry() function, by virtue of using the "A" variant RegQueryValueEx(), uses the ANSI code page, not ASCII. The ANSI code page could maybe handle more names than ASCII would. You could get a wide string and then use WideCharToMultiByte() to convert it to CP_ACP, but since you control all of the relevant code, it's just better to work with wide strings throughout. Change your device_disabled_registry() and get_config_key() functions to accept a wide string. Then, you can safely use CFStringGetLength() and CFStringGetCharacters() to acquire the WCHAR-based wide string from the CFString. You can just cast a WCHAR* to a UniChar*. -Ken

1 0

Re: [v2 1/2] winejoystick.drv: Add functionality to disable joystick via registry
by Ken Thomases 29 Aug '16

29 Aug '16

On Aug 29, 2016, at 6:03 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > + get_app_key(&hkey, &appkey); > + > + /* Joystick settings are in the 'joysticks' subkey */ > + if (appkey) > + { > + if (RegOpenKeyA(appkey, joystick_key, &temp)) temp = 0; > + RegCloseKey(appkey); > + appkey = temp; > + } > + if (hkey) > + { > + if (RegOpenKeyA(hkey, joystick_key, &temp)) temp = 0; > + RegCloseKey(hkey); > + hkey = temp; > + } It seems the appending of the Joysticks subkey should be done in get_app_key(). -Ken

1 0

Re: rpcrt4/tests: Don't load GetUserNameEx dynamically.
by Marvin 29 Aug '16

29 Aug '16

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=25430 Your paranoid android. === w864 (32 bit rpc) === rpc.c:815: Test failed: GUID does not appear to contain a MAC address: {9d7329b2-6dfd-11e6-be78-e71666c2e04a} === w864 (64 bit rpc) === rpc.c:815: Test failed: GUID does not appear to contain a MAC address: {cfff88a2-6dfd-11e6-be78-e71666c2e04a} === w8 (32 bit server) === server.c:1010: Test failed: get_ranged_enum() returned 2000814083 instead of RE3 === w864 (32 bit server) === server.c:1010: Test failed: get_ranged_enum() returned 2009071619 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 2009071619 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 2009071619 instead of RE3 === w864 (64 bit server) === server.c:1010: Test failed: get_ranged_enum() returned 4390915 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 117440515 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 4390915 instead of RE3 === w1064 (64 bit server) === server.c:1010: Test failed: get_ranged_enum() returned 6356995 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 6029315 instead of RE3

1 0

Re: d3drm/tests: Fix crash when surface can't be created
by Henri Verbeet 29 Aug '16

29 Aug '16

On 28 August 2016 at 16:49, André Hentschel <nerv(a)dawncrow.de> wrote: > Should fix crashes like: > https://test.winehq.org/data/a83d5d3b83042d2305de0595c0d03e4e7bf1e29e/xp_wx… > Does this happen on any setups that aren't using "VirtualBox Graphics Adapter" as display driver? I don't think failing the test or skipping is ultimately much more useful than crashing here, but if it's just about skipping cleanly I'd rather just blacklist the driver in a way similar to ddraw_is_warp() in the ddraw tests.

1 0

Re: [v1 1/5] winejoystick.drv: Add functionality to disable joystick via registry
by Bruno Jesus 29 Aug '16

29 Aug '16

On Sun, Aug 28, 2016 at 3:18 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > Adds device_disabled_registry, helper functions to shared joystick code Hi, thanks for working on this. The problem with this series is that you are introducing dead code in patches 1, 2 and 3. As the code is not used anywhere until patch 5. Patch 4 also adds dead code that is only used in patch 5. IMO you should merge patches 1,2,3 into a single patch and also 4 and 5 into second patch. This will make the dead code will last a single commit. Best wishes, Bruno

2 1

Re: [PATCH 1/2] rbtree.h: Store parent in each entry and use that to manipulate the tree without a stack.
by Henri Verbeet 29 Aug '16

29 Aug '16

On 10 August 2016 at 16:01, Jacek Caban <jacek(a)codeweavers.com> wrote: > include/wine/rbtree.h | 376 > +++++++++++++++++++++++++++----------------------- > 1 file changed, 200 insertions(+), 176 deletions(-) > Since this patch was assigned to me... I think this patch has quite a number of unrelated changes, to the point that the patch touches over half of the lines in the file and I think deletion for example ends up just being a different algorithm. And while the aforementioned means I didn't look at everything in quite the amount of detail that would otherwise be appropriate, I do think some of those changes make things overly complicated. For example, a straightforward modification to wine_rb_put() would turn it into something like the following: static inline int wine_rb_put(struct wine_rb_tree *tree, const void *key, struct wine_rb_entry *entry) { struct wine_rb_entry **node = &tree->root; struct wine_rb_entry *parent = *node; while (*node) { int c; if (!(c = tree->functions->compare(key, *node))) return -1; parent = *node; if (c < 0) node = &(*node)->left; else node = &(*node)->right; } entry->flags = WINE_RB_FLAG_RED; entry->parent = parent; entry->left = NULL; entry->right = NULL; *node = entry; wine_rb_fixup(&tree->root, entry); tree->root->flags &= ~WINE_RB_FLAG_RED; return 0; } I think that's much clearer than what this patch does with wine_rb_put().

3 10

Re: dxdiagn: Do fill DMI information on Linux
by Chris Robinson 28 Aug '16

28 Aug '16

On 08/28/2016 02:50 AM, Ruslan Kabatsayev wrote: > This patch makes previously empty fields szSystemManufacturerEnglish, > szSystemManufacturerEnglish and szBIOSEnglish in DxDiag filled with the > DMI information. This is the same information I get on my test Windows > system. > Currently this is only implemented for Linux, on other platforms > the fields remain empty. Are there functions to get this info in the Windows API? If so, it may be worth using/implementing those API calls, instead of reading it directly from the host like this.

2 1

Issues if GLX_SWAP_METHOD_OML is not fully supported
by Fabian Maurer 28 Aug '16

28 Aug '16

Hello, I have an OpenGL program that tries to use WGL_SWAP_METHOD, but while my graphics card supports GLX_OML_swap_method, no pixelformat supports its value GLX_SWAP_EXCHANGE_OML. Is this a graphics driver issue? I'm using the most recent open source mesa drivers. Attached a patch proposal to deal with the issue in wine, but I'm not sure if this is the right course of action to take. Fabian Maurer

2 2

How to link winreg.h to winejoystick.drv during compilation
by DavidL 28 Aug '16

28 Aug '16

I'm trying to add the ability to read registry keys to winejoystick.drv using functions like RegQueryValueExA, RegOpenKeyA, and RegCloseKey. However, I am getting linker errors where they are showing up as undefined symbols. The changed files are attached. The functions get_app_key, get_config_key, and device_disabled_registry are copied from various files in dinput and I assumed I needed to import advapi32 in the makefile.in since that's what type the aforementioned registry functions are, but I'm obviously misunderstanding how this works. Any help appreciated! Thanks, David

3 4

Re: Add a GUI for dxdiag program
by Aaryaman Vasishta 27 Aug '16

27 Aug '16

Hi, Thanks for your patch! I see there are still many style inconsistencies here, like "foo=bar;" and "foo = bar;" mixed together. Same for passing arguments, like "foo(bar,baz)" and "foo(bar, baz)" mixed together. Please try sticking to a single convention, it helps in code readability. There also might be an issue with the consistency of indendation on longer lines which do not fit. As long as you keep the indentation levels consistent across the file you should be fine. On Sat, Aug 27, 2016 at 1:56 PM, Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: > +INT_PTR CALLBACK system_tab_proc(HWND hsystab, UINT msg, WPARAM wparam, > LPARAM lparam) > +{ > + switch(msg) > + { > + case WM_COMMAND: > + switch(HIWORD(wparam)) > + { > + case BN_CLICKED: > + switch(wparam) > + { > + case IDC_WHQL_CHECKBOX: > + { > + update_dxdiag_info(); > + return TRUE; > + } > + } > + break; > There's an indentation issue here. You should still wait for others to review this before re-sending this patch though. Cheers, Aaryaman

2 2

Yet another xinput implementation for the xbox360 controller
by Bruno Jesus 27 Aug '16

27 Aug '16

Hi to everybody. In order to exercise dinput (which is overly complex) I have implemented xinput using dinput. Xinput is as easy as winmm joystick support, I guess MS wanted to go back to the basics. I know that this is not really useful specially when HID kicks in but as I said it was an exercise and now I can play Broforce properly with the Xbox controller and force feedback. If you know a game that is xinput only and it does not work with this patch tests are appreciated (+xinput,+dinput). Most of the code can still be reused for HID IMO, just change the dinput functions. If you want force feedback remember to disable the (js) joystick in the control panel. Also if you have other controller brands it must have at least 6 axis, 11 buttons and 1 POV to work, but the mapping has to be redone. If it has less buttons you can relax the checks in dinput_is_good. Last but not least I know I should have used dinput to map the axes values for me but I was tired of reading dinput docs and it was easy enough to convert manually. Best wishes, Bruno

1 1

Re: [PATCH 1/2] user32: Wait before getting/setting the cursor position in send_hardware_message
by Alexandre Julliard 27 Aug '16

27 Aug '16

Max Qian <public(a)maxqia.com> writes: > Signed-off-by: Max Qian <public(a)maxqia.com> > --- > dlls/user32/message.c | 20 +++++++++++++------- > include/wine/server_protocol.h | 8 ++------ > server/protocol.def | 4 ---- > server/queue.c | 5 ----- > server/request.h | 6 +----- > server/trace.c | 4 ---- > 6 files changed, 16 insertions(+), 31 deletions(-) There's a lot of complexity in the mouse input code, but it was all added for a reason. There are many games that do strange things with mouse input. If you want to remove things, you'll need to explain why you think they are no longer necessary. They were definitely necessary when I added them. That doesn't mean that it's perfect, but I think you should be looking into ways of tweaking the existing code instead of taking an axe to it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Bugs in gcc 5.3.0, 5.4.0 with force_align_arg_pointer
by Daniel Santos 27 Aug '16

27 Aug '16

Just to let you guys know, there's a bug in gcc 5.3 & 5.4 that causes wine's 64 bit code to be generated as if the incoming stack boundary was 8 bytes. This makes the pro/epilogues all bloaty with unaligned movups for SSE saves/restores. This can be avoided by actually *not* using force_align_arg_pointer or -mstackrealign. Note however that when using either of those, we should supply -mincoming-stack-boundary=4 so that gcc knows what alignment to force the arg pointer to... except that that is also expertly broken. I'm not aware of this actually causing any crashes or UB, just producing slower, bloaty code. There was also PR69140 that caused build breakage when the stack pointer wasn't properly aligned, but I guess this is a flaw that got exposed once force_align_arg_pointer started breaking alignment on x64 abi. Daniel

1 0

Re: kernel32: Fixed handling LOCALE_NAME_USER_DEFAULT in GetLocaleInfoEx.
by Marvin 26 Aug '16

26 Aug '16

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=25413 Your paranoid android. === w1064 (32 bit locale) === locale.c:2554: Test failed: LCMapStringEx should fail with bad locale name locale.c:2555: Test failed: unexpected error code -559038737 locale.c:2646: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4382: Test failed: IsValidLocaleName should have failed locale.c:4384: Test failed: IsValidLocaleName should have failed locale.c:4767: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4769: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2554: Test failed: LCMapStringEx should fail with bad locale name locale.c:2555: Test failed: unexpected error code -559038737 locale.c:2646: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4382: Test failed: IsValidLocaleName should have failed locale.c:4384: Test failed: IsValidLocaleName should have failed locale.c:4767: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4769: Test failed: For id 7, Expected IVC, got ''

1 0

Re: user32: Fix DefWindowProc behavior on WM_NCRBUTTONDOWN message
by Marvin 26 Aug '16

26 Aug '16

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=25405 Your paranoid android. === w7u (32 bit msg) === msg.c:4771: Test failed: ShowWindow(SW_RESTORE):overlapped: 18: the msg sequence is not complete: expected 0000 - actual 0088 === w8 (32 bit msg) === msg.c:13932: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w864 (32 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:13932: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w1064 (32 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:13932: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w864 (64 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:13932: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w1064 (64 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:7078: Test failed: SetWindowPos:FrameChanged_clip: 10: the msg sequence is not complete: expected 0000 - actual 001a msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:13932: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000

1 0

Re: [2/3] winex11: Returning more reliable value from X11DRV_MsgWaitForMultipleObjects.
by Ken Thomases 26 Aug '16

26 Aug '16

Hi, On Aug 23, 2016, at 8:13 AM, Akihiro Sagawa <sagawa.aki(a)gmail.com> wrote: > > This patch fixes ole32 test failure with my IME window patch. > > After processing several X events, X11DRV_MsgWaitForMultipleObjects always > tells us that a new message is available. This is not true for some cases. > > For instance, when we call DestroyWindow, the X queues DestroyEvent. Then, > X11DRV_MsgWaitForMultipleObjects handles the event only; none is posted or > sent as hwnd for destroyed window is unavailable. However, the function > states "new message is available" by returning count - 1 value. > > This is an issue for CoWaitForMultipleHandles because it expects a new > message in the queue and consumes the message. I'm looking at this with an eye toward whether the Mac driver needs a similar change. First, there's no change in the ole32 tests with or without your IME window patch when using the Mac driver. There's a clipboard failure but everything else succeeds. Second, the Mac driver doesn't have a notion of the window being destroyed behind our backs. I.e. there's nothing like a DestroyNotify event for a window whose HWND is still valid. But, just because that particular case doesn't come up doesn't mean the change is not still relevant to the Mac driver for other cases. However, I'm having a hard time seeing the logic of your change. In process_events(), you use a variable named "queued" to hold the result of calls to event handlers. That implies that event handlers should only return true if they have posted or sent a Windows message or hardware input. But that doesn't seem to be what you've actually done in the event handlers. For example, in the first "if" statement in X11DRV_MapNotify(), you return true without queuing anything. Instead, you seem to be returning true for some notion of "success" in handling events, but I'm not sure how that plays into the rationale for this patch. Am I misunderstanding something? I also don't get why you changed the TRACE at the end of process_events(). The events really were processed. They aren't "ignored" just because they didn't result in messages or input being queued. Also, shouldn't the return type of process_events() be changed to BOOL? Thanks, Ken

2 1

What flavor of C does Wine source target?
by Ruslan Kabatsayev 26 Aug '16

26 Aug '16

Hello all, While developing some code for Wine I wanted to ensure that I don't use some C99 features like C++-style comments or declaration of variables after statement. But the only way I found to do this with gcc was to use '-std=c89 -pedantic'. This appears to break lots of other things in winelib, particularly 'inline' functions, so it can't really be used for Wine/Winelib sources. The default for GCC is gnu89, which does allow the things Wine doesn't want. So, I wonder now, what flavor of C does Wine actually target? What tools can I use to automatically restrict language features? Regards, Ruslan

3 2

Re: [PATCH 3/6] wined3d: Handle WINED3DFMT_FLAG_BROKEN_PITCH in wined3d_format_calculate_size().
by Marvin 26 Aug '16

26 Aug '16

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=25402 Your paranoid android. === w864 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f.

1 0

Re: [PATCH 3/6] wined3d: Handle WINED3DFMT_FLAG_BROKEN_PITCH in wined3d_format_calculate_size().
by Marvin 26 Aug '16

26 Aug '16

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=25401 Your paranoid android. === w8 (32 bit device) === device.c:2779: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2784: Test failed: The focus window is active. device.c:2792: Test failed: Got unexpected hr 0x88760869. device.c:2796: Test failed: Got unexpect screen size 800x600. device.c:2811: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2820: Test failed: Got unexpect screen size 800x600. device.c:2833: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2841: Test failed: Got unexpect width 640. device.c:2842: Test failed: Got unexpect height 480. === w864 (32 bit device) === device.c:2779: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2784: Test failed: The focus window is active. device.c:2792: Test failed: Got unexpected hr 0x88760869. device.c:2796: Test failed: Got unexpect screen size 800x600. device.c:2811: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2820: Test failed: Got unexpect screen size 800x600. device.c:2833: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2841: Test failed: Got unexpect width 640. device.c:2842: Test failed: Got unexpect height 480. === w1064 (32 bit device) === device.c:2779: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2784: Test failed: The focus window is active. device.c:2792: Test failed: Got unexpected hr 0x88760869. device.c:2796: Test failed: Got unexpect screen size 800x600. device.c:2811: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2820: Test failed: Got unexpect screen size 800x600. device.c:2833: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2841: Test failed: Got unexpect width 640. device.c:2842: Test failed: Got unexpect height 480.

1 0

Re: ntdll: Add missing stdint.h include for kfreebsd architectures.
by Jens Reyer 26 Aug '16

26 Aug '16

On 24.08.2016 19:05, Marvin wrote: > Thank you for your contribution to Wine! > > This is an automated notification to let you know that your patch has > been reviewed and its status set to "Pending". > > This means that the patch is not necessarily wrong, but its > correctness is not obvious. You should either write a test case > demonstrating that it is correct, try to fix the problem in a more > straightforward way, or better explain why you are doing things this > way. > > If you do not understand the reason for this status, disagree with our > assessment, or are simply not sure how to proceed next, please ask for > clarification by replying to this email. It's not clear to me why this was set to pending, so I'll try to cover most bases in this mail: I assume the patch itself is fine!? We deploy it on every arch (Linux: amd64 arm64 armel armhf i386 powerpc, hurd-i386, kfreebsd-i386) Authorship: The original author Mike (CCed in patch submission) is quite short on time, so I decided to bring this patch (and others that we have in Debian) here. The whole Debian packaging is LGPL-2.1+ licensed (except if we use 3rd party stuff, which isn't the case for this patch). See [1]. History of this patch: 1.7.45-1 add, Michael Gilbert [2] 1.7.54-1 temporarily disable, Michael Gilbert [3] 1.7.54-2 refresh and readd, Michael Gilbert [4] 1.7.55-1 rename, Michael Gilbert [5] 1.9.9-1 refresh, Jens Reyer [6] Is this patch needed? Related (fixed) build failures: The last successful build on kfreebsd-i386 without this patch was 1.7.41-1. There's no data for 1.7.42/1.7.43. 1.7.44 failed to build. With the patch 1.7.45 and following versions built. When the patch was removed temporarily 1.7.54-1 failed to build. Later versions with patch built again. A list of all build logs is available at [7]. I didn't run a regression test, nor can name the relevant commit that caused the failure (I assume it was a change in Wine). If required I might verify if the patch is still needed today, but I'd have to apply for access to a kfreebsd machine first. I hope this clarifies everything Greets jre [1] https://anonscm.debian.org/git/pkg-wine/wine.git/tree/debian/copyright [2] https://anonscm.debian.org/git/pkg-wine/wine.git/commit/?id=4d7a55e [3] https://anonscm.debian.org/git/pkg-wine/wine.git/commit/?id=94643f4 [4] https://anonscm.debian.org/git/pkg-wine/wine.git/commit/?id=0fa1339 [5] https://anonscm.debian.org/git/pkg-wine/wine.git/commit/?id=8deb56f [6] https://anonscm.debian.org/git/pkg-wine/wine.git/commit/?id=3d3f870 [7] https://buildd.debian.org/status/logs.php?pkg=wine-development&arch=kfreebs…

1 1

Re: [PATCH 4/4] oleaut32: Implement ITypeComp::Bind() proxy/stub
by Huw Davies 26 Aug '16

26 Aug '16

On Thu, Aug 25, 2016 at 08:57:18PM +0300, Nikolay Sivov wrote: > + if (hr == S_OK) > + { > + switch (*desckind) > + { > + case DESCKIND_FUNCDESC: > + bindptr->lpfuncdesc = funcdesc; > + break; > + case DESCKIND_VARDESC: > + bindptr->lpvardesc = vardesc; > + break; > + case DESCKIND_TYPECOMP: > + bindptr->lptcomp = typecomp; > + break; > + default: > + ; > + } You're missing DESCKIND_IMPLICITAPPOBJ which should be handled like DESCKIND_VARDESC. Huw.

1 0

Re: kernel32/tests: Add a missing linebreak to an ok() message.
by Marvin 26 Aug '16

26 Aug '16

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=25390 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

1 0

Re: [PATCH] ntdll: Set Rip in for longjmp in RtlRestoreContext (try3)
by Marvin 26 Aug '16

26 Aug '16

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=25379 Your paranoid android. === wvistau64 (32 bit exception) === exception.c:551: Test failed: 42: Unexpected eip 0x2c0000/0x2c0001 exception: unhandled exception 80000004 at 002C0000 exception.c:551: Test failed: 42: Unexpected eip 0x77baed97/0x2c0001 === w7u (32 bit exception) === exception.c:551: Test failed: 42: Unexpected eip 0x3c0000/0x3c0001 exception: unhandled exception 80000004 at 003C0000 exception.c:551: Test failed: 42: Unexpected eip 0x77cde34f/0x3c0001 === w1064 (32 bit exception) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9) The test VM has crashed, rebooted or lost connectivity (or the TestAgent server died) === w1064 (64 bit exception) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9) The test VM has crashed, rebooted or lost connectivity (or the TestAgent server died)

1 0

Re: What flavor of C does Wine source target?
by achbarrr＠gmail.com 26 Aug '16

26 Aug '16

hello Ruslan wine is looking like emulator its works same like bluestacks app player. if its true wine is not emulator its must work like other. Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: >Hello all, > >While developing some code for Wine I wanted to ensure that I don't >use some C99 features like C++-style comments or declaration of >variables after statement. But the only way I found to do this with >gcc was to use '-std=c89 -pedantic'. This appears to break lots of >other things in winelib, particularly 'inline' functions, so it can't >really be used for Wine/Winelib sources. The default for GCC is gnu89, >which does allow the things Wine doesn't want. > >So, I wonder now, what flavor of C does Wine actually target? What >tools can I use to automatically restrict language features? > >Regards, >Ruslan > >

1 0

Re: [PATCH] wined3d: Fix ATI1 buffer size, try 3
by Marvin 26 Aug '16

26 Aug '16

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=25380 Your paranoid android. === w864 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f.

1 0

Re: [PATCH] ntdll: Use boot time to calculate tick count
by Ken Thomases 25 Aug '16

25 Aug '16

On Aug 25, 2016, at 2:55 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > Two catches with the macOS behavior: First, this implementation is much > more expensive than one system call in a very frequently called > function. mach_absolute_time() isn't even a system call. It's implemented in user space. It reads the TSC from the CPU and applies adjustments read from the commpage. There's a potential for it to loop if the commpage is adjusted while it's running. > It's an open question whether fixing behavior on sleep is > worth the cost. Second, the boot time has precision only to the nearest > second. This could cause skew if the current time is updated in <~1 > second intervals. Actually, it will cause skew whenever the current time is updated by a delta that's not whole seconds. Another issue is the race between sysctl() and gettimeofday(). If a time adjustment occurs between them, you'll get an incorrect result. This could be detected by checking the boot time again after gettimeofday() and repeating if it changed. Unfortunately, that adds even more overhead. (Actually, if we track the last known boot time in a static, we could only check it after and loop if it changed. That requires interlocked updating of the static, though, to make it thread safe.) Unfortunately, I don't know a good solution. I think that it may be a bug that mach_absolute_time() doesn't count time spent sleeping, but that's of no comfort. -Ken

1 0

Re: [PATCH] ntdll: Set Rip in for longjmp in RtlRestoreContext (try2)
by Piotr Caban 25 Aug '16

25 Aug '16

Hi Daniel, On 08/18/16 18:29, Daniel Lehman wrote: > + pass = 0; > + pRtlCaptureContext(&ctx); > + if (InterlockedIncrement(&pass) == 1) /* interlocked to prevent compiler from moving */ The patch looks good for me except one thing that I don't understand. Why there's no risk that compiler will move the pass=0 assignment after pRtlCaptureContext call? Maybe something like this will be more correct: pass = 0; InterlockedIncrement(&pass); pRtlCaptureContext(&ctx); if (InterlockedIncrement(&pass) == 2) ? Thanks, Piotr

2 1

Re: [PATCH] user32: Only use the driver for getting the position
by Alexandre Julliard 25 Aug '16

25 Aug '16

Max Qian <public(a)maxqia.com> writes: > This fixes bug 24951 and reverts GetCursorPos related > changes from commits 39c4e6d, f1a3480, and 6576703. This is going to break things that use low-level hooks, in particular dinput, since the cursor won't be in sync with the hardware events. We also have tests for that: ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so input && touch input.ok input.c:1299: Test failed: Wrong new pos: (103,103) input.c:1302: Test failed: Wrong new pos: (106,106) input.c:1305: Test failed: Wrong new pos: (109,109) input.c:1308: Test failed: Wrong new pos: (112,112) make: *** [input.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2] d3d8/tests: Prefer higher resolutions in test_reset().
by Marvin 25 Aug '16

25 Aug '16

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=25373 Your paranoid android. === w8 (32 bit device) === device.c:2794: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2799: Test failed: The focus window is active. device.c:2807: Test failed: Got unexpected hr 0x88760869. device.c:2811: Test failed: Got unexpect screen size 800x600. device.c:2826: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2835: Test failed: Got unexpect screen size 800x600. device.c:2848: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2856: Test failed: Got unexpect width 640. device.c:2857: Test failed: Got unexpect height 480. === w864 (32 bit device) === device.c:2794: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2799: Test failed: The focus window is active. device.c:2807: Test failed: Got unexpected hr 0x88760869. device.c:2811: Test failed: Got unexpect screen size 800x600. device.c:2826: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2835: Test failed: Got unexpect screen size 800x600. device.c:2848: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2856: Test failed: Got unexpect width 640. device.c:2857: Test failed: Got unexpect height 480. === w1064 (32 bit device) === device.c:2794: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2799: Test failed: The focus window is active. device.c:2807: Test failed: Got unexpected hr 0x88760869. device.c:2811: Test failed: Got unexpect screen size 800x600. device.c:2826: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2835: Test failed: Got unexpect screen size 800x600. device.c:2848: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2856: Test failed: Got unexpect width 640. device.c:2857: Test failed: Got unexpect height 480.

1 0

Re: [PATCH v9 2/3] shell32: Implement FolderItems_Item.
by Sebastian Lackner 25 Aug '16

25 Aug '16

On 23.08.2016 06:02, Alex Henrie wrote: > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shelldispatch.c | 136 +++++++++++++++++++++++++++++++++++-- > dlls/shell32/tests/shelldispatch.c | 13 ---- > 2 files changed, 130 insertions(+), 19 deletions(-) > Thanks for the updated version, this already looks much better. Nevertheless, I have two more small requests: * You decided to use StrDupW(), but there shouldn't be any need to use this shlwapi function. The only other place where it was used in shell32 was wrong and has been fixed with: http://source.winehq.org/git/wine.git/commit/a11fb74ffb15b60768c6fa49b07251… I would suggest to move the strdupW() function which is used in other parts of shell32 to the public header file and then use that instead. * You decided to use exponential growth for the filenames buffer which is better than allocating only one element at once. Nevertheless, it might still waste a lot of memory. I would suggest to use either linear growth or attempt to shrink the buffer size to release unnecessary space. Patch 1 should technically be fine, but the code still looks unnecessary complex to me. I will think about some ways to simplify it a bit more. Regards, Sebastian

2 1

Re: [PATCH v8 2/3] shell32: Implement FolderItems_Item.
by Sebastian Lackner 25 Aug '16

25 Aug '16

On 19.08.2016 11:43, Alex Henrie wrote: > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shelldispatch.c | 133 +++++++++++++++++++++++++++++++++++-- > dlls/shell32/tests/shelldispatch.c | 12 ---- > 2 files changed, 127 insertions(+), 18 deletions(-) > > diff --git a/dlls/shell32/shelldispatch.c b/dlls/shell32/shelldispatch.c > index ac79302..a456ad4 100644 > --- a/dlls/shell32/shelldispatch.c > +++ b/dlls/shell32/shelldispatch.c > @@ -68,6 +68,9 @@ typedef struct { > typedef struct { > FolderItems3 FolderItems3_iface; > LONG ref; > + VARIANT dir; > + BSTR *item_paths; > + LONG item_count; > } FolderItemsImpl; > > typedef struct { > @@ -989,11 +992,18 @@ static ULONG WINAPI FolderItemsImpl_Release(FolderItems3 *iface) > { > FolderItemsImpl *This = impl_from_FolderItems(iface); > ULONG ref = InterlockedDecrement(&This->ref); > + int i; > > TRACE("(%p), new refcount=%i\n", iface, ref); > > if (!ref) > + { > + VariantClear(&This->dir); > + for (i = 0; i < This->item_count; i++) > + SysFreeString(This->item_paths[i]); > + HeapFree(GetProcessHeap(), 0, This->item_paths); > HeapFree(GetProcessHeap(), 0, This); > + } > return ref; > } > > @@ -1079,10 +1089,47 @@ static HRESULT WINAPI FolderItemsImpl_get_Parent(FolderItems3 *iface, IDispatch > > static HRESULT WINAPI FolderItemsImpl_Item(FolderItems3 *iface, VARIANT index, FolderItem **ppid) > { > - FIXME("(%p,%s,%p)\n", iface, debugstr_variant(&index), ppid); > + FolderItemsImpl *This = impl_from_FolderItems(iface); > + VARIANT path; > + int i; > + > + TRACE("(%p,%s,%p)\n", iface, debugstr_variant(&index), ppid); > > *ppid = NULL; > - return E_NOTIMPL; > + > + switch (V_VT(&index)) > + { > + case VT_I2: > + VariantChangeType(&index, &index, 0, VT_I4); > + /* fall through */ > + case VT_I4: > + if (V_I4(&index) < 0 || V_I4(&index) >= This->item_count) > + return S_FALSE; > + > + V_VT(&path) = VT_BSTR; > + V_BSTR(&path) = This->item_paths[V_I4(&index)]; > + return FolderItem_Constructor(&path, ppid); > + > + case VT_BSTR: > + for (i = 0; i < This->item_count; i++) > + { > + if (!lstrcmpW(V_BSTR(&index), PathFindFileNameW(This->item_paths[i]))) Usually strcmpW is preferred in Wine code. Its better to do NULL pointer checks explicitly. > + { > + V_VT(&path) = VT_BSTR; > + V_BSTR(&path) = This->item_paths[i]; > + return FolderItem_Constructor(&path, ppid); > + } > + } > + return S_FALSE; > + > + case VT_ERROR: > + V_VT(&path) = VT_BSTR; > + V_BSTR(&path) = V_BSTR(&This->dir); > + return FolderItem_Constructor(&path, ppid); You can also pass &This->dir directly to the constructor. > + > + default: > + return E_NOTIMPL; > + } > } > > static HRESULT WINAPI FolderItemsImpl__NewEnum(FolderItems3 *iface, IUnknown **ppunk) > @@ -1139,21 +1186,93 @@ static const FolderItems3Vtbl FolderItemsImpl_Vtbl = { > FolderItemsImpl_get_Verbs > }; > > -static HRESULT FolderItems_Constructor(FolderItems **ppfi) > +static HRESULT FolderItems_Constructor(VARIANT *dir, FolderItems **ppfi) > { > + static const WCHAR backslash_star[] = {'\\','*',0}; > + static const WCHAR dot[] = {'.',0}; > + static const WCHAR dot_dot[] = {'.','.',0}; > FolderItemsImpl *This; > + WCHAR path[MAX_PATH + 2]; > + HANDLE first_file; > + WIN32_FIND_DATAW file_info; > + BSTR *paths; > + HRESULT ret; > > TRACE("\n"); Not really an issue, but you could add a trace for the function arguments here. > > *ppfi = NULL; > > + if (V_VT(dir) == VT_I4) > + { > + FIXME("special folder constants are not supported\n"); > + return E_NOTIMPL; > + } > + > This = HeapAlloc(GetProcessHeap(), 0, sizeof(FolderItemsImpl)); > if (!This) return E_OUTOFMEMORY; > This->FolderItems3_iface.lpVtbl = &FolderItemsImpl_Vtbl; > This->ref = 1; > > + VariantInit(&This->dir); > + ret = VariantCopy(&This->dir, dir); > + if (FAILED(ret)) > + { > + HeapFree(GetProcessHeap(), 0, This); > + return E_OUTOFMEMORY; > + } > + > + This->item_paths = HeapAlloc(GetProcessHeap(), 0, sizeof(BSTR)); > + if (!This->item_paths) > + { > + VariantClear(&This->dir); > + HeapFree(GetProcessHeap(), 0, This); > + return E_OUTOFMEMORY; > + } > + This->item_count = 0; > + > + lstrcpyW(path, V_BSTR(dir)); > + lstrcatW(path, backslash_star); > + first_file = FindFirstFileW(path, &file_info); > + if (first_file != INVALID_HANDLE_VALUE) > + { > + do > + { > + if (!lstrcmpW(file_info.cFileName, dot) || !lstrcmpW(file_info.cFileName, dot_dot)) > + continue; Similar to above, strcmpW is usually preferred. > + > + if (!PathCombineW(path, V_BSTR(dir), file_info.cFileName)) > + { > + ret = E_OUTOFMEMORY; > + goto fail; > + } I think it makes more sense to store the relative paths, there is no need to prepend the directory name in advance. FolderItemsImpl_Item also expects a relative path for example. > + > + paths = HeapReAlloc(GetProcessHeap(), 0, This->item_paths, (This->item_count + 1) * sizeof(BSTR)); It seems more reasonable to increase the buffer size in bigger chunks. Its better to have a few entries overhead than to do frequent reallocs. > + if (!paths) > + { > + ret = E_OUTOFMEMORY; > + goto fail; > + } > + This->item_paths = paths; > + > + This->item_paths[This->item_count] = SysAllocString(path); > + if (!This->item_paths[This->item_count]) > + { > + ret = E_OUTOFMEMORY; > + goto fail; > + } > + This->item_count++; > + } > + while (FindNextFileW(first_file, &file_info)); > + > + FindClose(first_file); > + } > + > *ppfi = (FolderItems*)&This->FolderItems3_iface; > - return S_OK; > + return ret; It is better to return S_OK explicitly because !FAILED(ret) could still be any other value >= 0, like S_FALSE for example. > + > +fail: You are leaking the FindFirstFile handle here. > + FolderItems3_Release(&This->FolderItems3_iface); > + return ret; > } > > static HRESULT WINAPI FolderImpl_QueryInterface(Folder3 *iface, REFIID riid, > @@ -1308,9 +1427,11 @@ static HRESULT WINAPI FolderImpl_get_ParentFolder(Folder3 *iface, Folder **ppsf) > > static HRESULT WINAPI FolderImpl_Items(Folder3 *iface, FolderItems **ppid) > { > - FIXME("(%p,%p)\n", iface, ppid); > + FolderImpl *This = impl_from_Folder(iface); > + > + TRACE("(%p,%p)\n", iface, ppid); > > - return FolderItems_Constructor(ppid); > + return FolderItems_Constructor(&This->dir, ppid); > } > > static HRESULT WINAPI FolderImpl_ParseName(Folder3 *iface, BSTR name, FolderItem **item) > diff --git a/dlls/shell32/tests/shelldispatch.c b/dlls/shell32/tests/shelldispatch.c > index 6715794..dc4fda4 100644 > --- a/dlls/shell32/tests/shelldispatch.c > +++ b/dlls/shell32/tests/shelldispatch.c > @@ -390,7 +390,6 @@ todo_wine > r = FolderItems_Item(items, var, NULL); > > r = FolderItems_Item(items, var, &item); > -todo_wine > ok(r == S_FALSE, "expected S_FALSE, got %08x\n", r); > ok(!item, "item is not null\n"); > > @@ -470,14 +469,11 @@ todo_wine > r = FolderItems_Item(items, var, &item); > if (i == VT_I2 || i == VT_I4 || i == VT_ERROR) > { > -todo_wine > ok(r == S_OK, "type %d: expected S_OK, got %08x\n", i, r); > -todo_wine > ok(!!item, "item is null\n"); > } > else if (i == VT_BSTR) > { > -todo_wine > ok(r == S_FALSE, "type %d: expected S_FALSE, got %08x\n", i, r); > ok(!item, "item is not null\n"); > } > @@ -495,11 +491,8 @@ todo_wine > V_VT(&var) = VT_ERROR; > V_ERROR(&var) = i; > r = FolderItems_Item(items, var, &item); > -todo_wine > ok(r == S_OK, "expected S_OK, got %08x\n", r); > -todo_wine > ok(!!item, "item is null\n"); > - if (!item) continue; > > bstr = NULL; > r = FolderItem_get_Path(item, &bstr); > @@ -518,7 +511,6 @@ todo_wine > V_I4(&var) = -1; > item = (FolderItem*)0xdeadbeef; > r = FolderItems_Item(items, var, &item); > -todo_wine > ok(r == S_FALSE, "expected S_FALSE, got %08x\n", r); > ok(!item, "item is not null\n"); > > @@ -541,11 +533,8 @@ todo_wine > > item = NULL; > r = FolderItems_Item(items, var, &item); > -todo_wine > ok(r == S_OK, "file_defs[%d], %d: FolderItems::Item failed: %08x\n", i, j, r); > -todo_wine > ok(!!item, "file_defs[%d], %d: item is null\n", i, j); > - if (!item) continue; > > item2 = NULL; > r = FolderItems_Item(items, var, &item2); > @@ -572,7 +561,6 @@ todo_wine > V_I4(&var) = sizeof(file_defs)/sizeof(file_defs[0]); > item = (FolderItem*)0xdeadbeef; > r = FolderItems_Item(items, var, &item); > -todo_wine > ok(r == S_FALSE, "expected S_FALSE, got %08x\n", r); > ok(!item, "item is not null\n"); > >

2 3

Re: [PATCH] kernel32: Improve tests for pUnregisterWait(0)
by Marvin 25 Aug '16

25 Aug '16

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=25353 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

1 0

Re: [PATCH] dinput: Add the 16-bit DLL version on acmGetVersion
by Bruno Jesus 24 Aug '16

24 Aug '16

Sorry, wrong subject. Sent a new one. On Wed, Aug 24, 2016 at 8:09 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Remove the annoying message when Wine is configured as 3.11. The DLL version 2.1 number was tested on Windows 3.11. > > Source for test: > http://alexa.pro.br/~bruno/wine/acm.c > > Compiled 16-bit EXE: > http://alexa.pro.br/~bruno/wine/acm.exe > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/msacm32/msacm32_main.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/msacm32/msacm32_main.c b/dlls/msacm32/msacm32_main.c > index a47611c..efe58af 100644 > --- a/dlls/msacm32/msacm32_main.c > +++ b/dlls/msacm32/msacm32_main.c > @@ -84,6 +84,8 @@ DWORD WINAPI acmGetVersion(void) > switch (version.dwPlatformId) { > case VER_PLATFORM_WIN32_NT: > return 0x04000565; /* 4.0.1381 */ > + case VER_PLATFORM_WIN32s: > + return 0x02010000; /* 2.1 */ > default: > FIXME("%x not supported\n", version.dwPlatformId); > /* fall through */ > -- > 2.9.3 >

1 0

Re: [PATCH 4/4] msvcr90: Add _fpieee_flt tests
by Marvin 24 Aug '16

24 Aug '16

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=25343 Your paranoid android. === wxppro (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w2003std (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === wvistau64 (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w2008s64 (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w7u (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w7pro64 (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w8 (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w864 (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w1064 (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b

1 0

Re: [PATCH] wined3d: Fix ATI1 buffer size, try 2
by Henri Verbeet 24 Aug '16

24 Aug '16

On 22 August 2016 at 18:53, Patrick Rudolph <siro(a)das-labor.org> wrote: > Apitrace crashes on WINE when trying to playback a trace containing ATI1 textures. > > Add a tests to show that "unknown" formats like ATI1 are backed by a buffer > of size pitch * height. Without the attaced fix the tests will crash. > > Calculate correct buffer size in wined3d_format_calculate_pitch for formats that > have WINED3DFMT_FLAG_BROKEN_PITCH flag set. > Remove no longer needed check in texture_resource_sub_resource_map. > > Signed-off-by: Patrick Rudolph <siro(a)das-labor.org> > --- > dlls/d3d9/tests/device.c | 8 ++++++++ > dlls/wined3d/texture.c | 10 +--------- > dlls/wined3d/utils.c | 9 ++++++++- > 3 files changed, 17 insertions(+), 10 deletions(-) > This breaks the tests. For example: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so visual && touch visual.ok visual.c:9512: Tests skipped: Card has unconditional NP2 support, skipping conditional NP2 tests visual.c:13651: Tests skipped: No NVDB (depth bounds test) support, skipping tests. visual.c:17111: Tests skipped: DXT5 volume textures are not supported, skipping test. visual.c:17966: Test failed: Got unexpected color 0x008080ff, case 2. visual.c:17966: Test failed: Got unexpected color 0x008080ff, case 3. visual.c:19801: Tests skipped: Volume ATI2N textures are not supported, skipping some tests. Makefile:276: recipe for target 'visual.ok' failed make: *** [visual.ok] Error 2

1 0

Re: [PATCH 2/7] d3d8/tests: Prefer higher resolutions in test_reset().
by Henri Verbeet 24 Aug '16

24 Aug '16

On 22 August 2016 at 14:53, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -21,6 +21,8 @@ > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > */ > > +#include <stdlib.h> > + > #define WINVER 0x0602 /* for CURSOR_SUPPRESSED */ This causes warnings from make crosstest for me: device.c:26:0: warning: "WINVER" redefined #define WINVER 0x0602 /* for CURSOR_SUPPRESSED */ ^ In file included from /usr/share/mingw-w64/include/crtdefs.h:10:0, from /usr/share/mingw-w64/include/stdlib.h:9, from device.c:24: /usr/share/mingw-w64/include/_mingw.h:225:0: note: this is the location of the previous definition #define WINVER 0x0502 ^

1 0

Re: ntoskrnl.exe: Implement ZwLoadDriver and ZwUnloadDriver based on services API.
by Sebastian Lackner 23 Aug '16

23 Aug '16

On 22.08.2016 16:12, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > This hides the complicated services API behind some easy to use functions :) > The timeout are a bit arbitrary and can be adjusted if they do not work well > enough in practice. Based on Arics feedback this solution is confirmed to work > for his purpose. > > dlls/ntoskrnl.exe/Makefile.in | 1 > dlls/ntoskrnl.exe/ntoskrnl.c | 164 ++++++++++++++++++++++++++++++++++++ > dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 4 > 3 files changed, 167 insertions(+), 2 deletions(-) Aric already signed off, but please ignore this patch. I am planning to send a new version shortly. The functions should also strip off the registry prefix.

1 0

Re: Adding binfmt configuration to official Wine packages
by Alex Henrie 23 Aug '16

23 Aug '16

2016-08-23 4:45 GMT-06:00 Rosanne DiMesio <dimesio(a)earthlink.net>: > On Mon, 22 Aug 2016 20:26:51 -0600 > Alex Henrie <alexhenrie24(a)gmail.com> wrote: > >> In fact, it's easy to >> forget that you have to explicitly give execution permissions to a >> downloaded file before Linux will let you execute it. If the file is >> on a USB drive, unless the drive has a Linux filesystem, the binary >> must be moved off of the drive before it can receive execution >> permissions. >> > > I have portable Firefox on a FAT32 formatted flash drive and Wine is able to run it. Wine will run any EXE as long as you start it (or your desktop environment starts it) with `wine foobar.exe`. If you start it with `./foobar.exe` instead, the file must be executable and binfmt must be set up correctly. Interestingly, it looks like Arch Linux and Ubuntu have both started to mount FAT32 filesystems with the "showexec" option. This makes EXE files on USB drives executable automatically. (It doesn't look very smart, it just turns on executability if the filename ends in ".exe".) So I stand corrected; you're right that it's no longer necessary to change the mount options or copy the EXE to another filesystem. Still, no desktop environment is going to execute files off of a USB drive without asking. -Alex

1 0

Adding binfmt configuration to official Wine packages
by Bruno Jesus 23 Aug '16

23 Aug '16

Hi, I would like to please call for attention on bug https://bugs.winehq.org/show_bug.cgi?id=39884 As far as I understand there are only benefits to users if we allow .exe files to run through binfmt, would it pose any kind of problem to add this configuration to our packages? Best wishes, Bruno

6 19

Re: [PATCH] Get the position from the driver on every GetCursorPos run
by Alexandre Julliard 23 Aug '16

23 Aug '16

Max Qian <public(a)maxqia.com> writes: > This reverts the GetCursorPos changes in commits 6576703 and f1a3480 to fix bug 24951. This is going to reintroduce the performance issues that the changes were supposed to fix. Doing a server round-trip on every GetCursorPos gives bad results in many apps. You'll need to find a fix that doesn't require this. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [resend PATCH] ntdll: Tolerate null handle in DeregisterWait
by Bruno Jesus 23 Aug '16

23 Aug '16

On Fri, Aug 19, 2016 at 6:24 PM, Keno Fischer <keno(a)juliacomputing.com> wrote: Hi, is the subject supposed to be Tolerate NULL handle in UnregisterWait? > diff --git a/dlls/kernel32/tests/thread.c b/dlls/kernel32/tests/thread.c > index a9a04df..44c6278 100644 > --- a/dlls/kernel32/tests/thread.c > +++ b/dlls/kernel32/tests/thread.c > @@ -1245,6 +1245,11 @@ static void test_RegisterWaitForSingleObject(void) > > ret = pUnregisterWait(wait_handle); > ok(ret, "UnregisterWait failed with error %d\n", GetLastError()); > + > + /* Test UnregisterWait null argument case */ > + ret = pUnregisterWait(0); > + ok(!ret && GetLastError() == ERROR_INVALID_HANDLE, > + "UnregisterWait failed with unexpected error %d\n", GetLastError()); > } Please test ret and GetLastError separately as the rest of the code does most times. If you see other tests that test GetLastError you will notice that they call SetLastError before calling the tested function to ensure the error is not from a previous test. So add a SetLastError(0xdeadbeef) before the call to pUnregisterWait to ensure the ERROR_INVALID_HANDLE returned is from UnregisterWait. Also for consistency why not pUnregisterWait(NULL) instead of (0)?

3 2

Re: [PATCH] dinput: 0 is a valid fd (Coverity)
by Bruno Jesus 23 Aug '16

23 Aug '16

On Mon, Aug 22, 2016 at 6:19 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > 1371727 Resource leak > (will not happen in Wine, but it is valid) > > Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> This patch is superseeded by http://source.winehq.org/patches/data/125859

1 0

Re: dinput: Check the return of open() properly (Coverity)
by Bruno Jesus 22 Aug '16

22 Aug '16

On Mon, Aug 22, 2016 at 6:07 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> This patch is superseeded by http://source.winehq.org/patches/data/125859

1 0

Re: [PATCH] wined3d: Fix ATI1 buffer size, try 2
by Marvin 22 Aug '16

22 Aug '16

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=25322 Your paranoid android. === w864 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f.

1 0

Re: [PATCH v8 1/3] shell32/tests: Add tests for FolderItems_Item and FolderItems_get_Count.
by Sebastian Lackner 22 Aug '16

22 Aug '16

On 19.08.2016 11:43, Alex Henrie wrote: > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > v8 initializes V_ERROR(&var), item, item2, and i correctly. It also adds > checks that the test files were created and written successfully. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/tests/Makefile.in | 2 +- > dlls/shell32/tests/shelldispatch.c | 229 +++++++++++++++++++++++++++++++++++-- > 2 files changed, 219 insertions(+), 12 deletions(-) > I think this patch is unfortunately still a bit too noisy to be applied separately. If you want to keep the "bruteforce" tests I would suggest to move the implementation into the first patch, or alternatively change the FIXME to a TRACE. Besides that I am basically fine, although there are probably some ways how to improve the code style a bit further. Regards, Sebastian

2 2

Re: [PATCH v8 3/3] shell32: Implement FolderItems_get_Count.
by Sebastian Lackner 22 Aug '16

22 Aug '16

On 19.08.2016 11:43, Alex Henrie wrote: > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shelldispatch.c | 10 ++++++++-- > dlls/shell32/tests/shelldispatch.c | 6 ------ > 2 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/dlls/shell32/shelldispatch.c b/dlls/shell32/shelldispatch.c > index a456ad4..86b77d6 100644 > --- a/dlls/shell32/shelldispatch.c > +++ b/dlls/shell32/shelldispatch.c > @@ -1061,9 +1061,15 @@ static HRESULT WINAPI FolderItemsImpl_Invoke(FolderItems3 *iface, > > static HRESULT WINAPI FolderItemsImpl_get_Count(FolderItems3 *iface, LONG *count) > { > - FIXME("(%p,%p)\n", iface, count); > + FolderItemsImpl *This = impl_from_FolderItems(iface); > > - return E_NOTIMPL; > + TRACE("(%p,%p)\n", iface, count); > + > + if (!count) > + return E_INVALIDARG; The tests contain a comment which suggests that Windows does not do such checks. If this is true I would suggest to simplify it also here in your implementation. > + > + *count = This->item_count; > + return S_OK; > } > > static HRESULT WINAPI FolderItemsImpl_get_Application(FolderItems3 *iface, IDispatch **ppid) > diff --git a/dlls/shell32/tests/shelldispatch.c b/dlls/shell32/tests/shelldispatch.c > index dc4fda4..42cfbf7 100644 > --- a/dlls/shell32/tests/shelldispatch.c > +++ b/dlls/shell32/tests/shelldispatch.c > @@ -378,9 +378,7 @@ static void test_items(void) > r = FolderItems_get_Count(items, NULL); > > r = FolderItems_get_Count(items, &lcount); > -todo_wine > ok(r == S_OK, "FolderItems::get_Count failed: %08x\n", r); > -todo_wine > ok(!lcount, "expected 0 files, got %d\n", lcount); > > V_VT(&var) = VT_I4; > @@ -435,9 +433,7 @@ todo_wine > > lcount = -1; > r = FolderItems_get_Count(items, &lcount); > -todo_wine > ok(r == S_OK, "FolderItems::get_Count failed: %08x\n", r); > -todo_wine > ok(!lcount, "expected 0 files, got %d\n", lcount); > FolderItems_Release(items); > > @@ -455,9 +451,7 @@ todo_wine > > lcount = -1; > r = FolderItems_get_Count(items, &lcount); > -todo_wine > ok(r == S_OK, "FolderItems::get_Count failed: %08x\n", r); > -todo_wine > ok(lcount == sizeof(file_defs)/sizeof(file_defs[0]), > "expected %d files, got %d\n", sizeof(file_defs)/sizeof(file_defs[0]), lcount); > >

2 1

Re: [PATCH 3/3] wpc: Register WindowsParentalControls class.
by Marvin 22 Aug '16

22 Aug '16

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=25317 Your paranoid android. === build (build) === Recreation of tests/Makefile failed

1 0

Re: [PATCH 2/3] wpc: Added basic tests.
by Marvin 22 Aug '16

22 Aug '16

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=25316 Your paranoid android. === build (build) === Recreation of tests/Makefile failed

1 0

Re: [PATCH 7/7] d3d9: Forbid display mode and back buffer mismatch in IDirect3DDevice9Ex_ResetEx().
by Marvin 22 Aug '16

22 Aug '16

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=25314 Your paranoid android. === w1064 (32 bit d3d9ex) === d3d9ex.c:2828: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2830: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2828: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2830: Test failed: Got unexpected hr 0, i=1. === w1064 (64 bit d3d9ex) === d3d9ex.c:2828: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2830: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2828: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2830: Test failed: Got unexpected hr 0, i=1.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel