November 2015 - Wine-devel - list.winehq.org

Re: ws2_32/tests: Check if the first IP is a default route in gethostbyname
by Marvin 25 Nov '15

25 Nov '15

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=18529 Your paranoid android. === w2008s64 (32 bit sock) === sock.c:4482: Test failed: failed to find interface index 12 sock.c:4485: Test failed: failed to find the first IP from gethostbyname! === w2008s64 (64 bit sock) === sock.c:4482: Test failed: failed to find interface index 12 sock.c:4485: Test failed: failed to find the first IP from gethostbyname!

1 0

Re: shlwapi: Don't bother trying to duplicate nil handle
by Bruno Jesus 25 Nov '15

25 Nov '15

On Wed, Nov 25, 2015 at 3:17 PM, Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> wrote: > Fix one of the error leak source that prevents the installer to succeed > (bug 36838). > > The original code did try to duplicate the handle even though it is > null, and that causes last error to be set to ERROR_INVALID_HANDLE. The > game installer chokes at some point when the last error is anything but > zero and fails to complete the installation. Returning a null handle > value is sufficient to indicate that error condition. The SHMapHandle is > not supposed to set last error on failure. A test wouldn't hurt, like the attached patch. Maybe to make this more convincing the test should be sent separate to prove current wine behavior is wrong.

1 0

Re: Shell32: Check if is_wow64 before calling wow64 functions
by Nikolay Sivov 25 Nov '15

25 Nov '15

Hi, Olivier. > + pIsWow64Process = (void*)GetProcAddress(GetModuleHandleA("kernel32"), "IsWow64Process"); There's no reason to do that, just use it in a normal static way.

1 0

Good way to use custom .dll.so ?
by lemonsqueeze 25 Nov '15

25 Nov '15

Hi, Working on a regression bug with a specific app atm https://bugs.winehq.org/show_bug.cgi?id=38137 I've traced the problem to ieframe.dll.so and came up with a version that fixes it : overwriting /usr/lib/i386-linux-gnu/wine/ieframe.dll.so with it problem is gone. Now I have no idea what side effects this could have for other apps, so I'd rather leave the system lib alone and override it just for this app. How do I do this ?? I've come across http://wine-wiki.org/index.php/WINEDLLPATH which seems to be what I'm looking for but it's not working. (setting WINEDLLPATH new dll.so is not used) Bottom of page also mentions that : > For DLLs at least, you should be able to rename the .dll.so to a > .dll and stick it in the application's directory. That doesn't work either. There's got to be a clean way of doing this, am I missing something here ? In case that matters, working with wine 1.6 atm (Looking for Ubuntu Trusty fix) Cheers

2 3

Re: Shell32: Check if is_wow64 before calling wow64 functions
by Dmitry Timoshkov 25 Nov '15

25 Nov '15

"Olivier F. R. Dierick" <o.dierick(a)piezo-forte.be> wrote: > + static BOOL (WINAPI *pIsWow64Process)(HANDLE, PBOOL); There is no need to make it static; -- Dmitry.

1 0

Good way to use custom .dll.so ?
by river 25 Nov '15

25 Nov '15

Hi, Working on a regression bug with a specific app atm https://bugs.winehq.org/show_bug.cgi?id=38137 I've traced the problem to ieframe.dll.so and came up with a version that fixes it : overwriting /usr/lib/i386-linux-gnu/wine/ieframe.dll.so with it problem is gone. Now I have no idea what side effects this could have for other apps, so I'd rather leave the system lib alone and override it just for this app. How do I do this ?? I've come across http://wine-wiki.org/index.php/WINEDLLPATH which seems to be what I'm looking for but it's not working. (setting WINEDLLPATH new dll.so is not used). Bottom of page also mentions that : > For DLLs at least, you should be able to rename the .dll.so to a > .dll and stick it in the application's directory. That doesn't work either. Sure there's got to be a clean way of doing this, am I missing something here ? In case that matters, working with wine 1.6 atm (Looking for Ubuntu Trusty fix) Cheers

1 0

Re: ws2_32/tests: Add more tests related to WSACleanup
by Marvin 24 Nov '15

24 Nov '15

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=18520 Your paranoid android. === w7pro64 (64 bit sock) === sock.c:7622: Test failed: bytesReturned isn't supposed to be 1 sock.c:7668: Test failed: Waiting for timeout failed with 0 + errno 997

1 0

A new attempt on WSACleanup
by Bruno Jesus 24 Nov '15

24 Nov '15

Hi all, a possible way to solve the WSACleanup in the DLL side is to retrieve all existing sockets from the current process in a server call and then closing then inside winsock. Is it possible to make a wine server call that returns variable length data? If yes, can anyone show an example? Such function would also allow for a proper implementation of SetTcpEntry (iphlpapi) which would make firewalls that like to close TCP connections happy.

4 8

Re: msacm32/tests: Add some acmStreamPrepareHeader and acmStreamConvert tests (try 2)
by Andrew Eikum 24 Nov '15

24 Nov '15

On Tue, Nov 24, 2015 at 05:08:00PM +0800, Bruno Jesus wrote: > + hdr.cbSrcLengthUsed = 12345; > + hdr.cbDstLengthUsed = 12345; The rest looks OK, but I don't understand why these are set. Does the application really set them to this value after Prepare and before Convert? The tests seem to behave the same if I leave them at 0. Andrew

2 2

Re: [PATCH] dxgi: Implement dxgi_output_GetDesc().
by Marvin 24 Nov '15

24 Nov '15

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=18498 Your paranoid android. === w1064 (32 bit device) === device.c:1147: Test failed: Got unexpected hr 0, test 16. device.c:1147: Test failed: Got unexpected hr 0x87a0001, test 39.

1 0