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

Re: [PATCH 1/5] ddraw/tests: Rename modes and rectangles in test_coop_level_mode_set.
by Henri Verbeet Nov. 11, 2014

Nov. 11, 2014

On 10 November 2014 23:08, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > ddraw = create_ddraw(); > ok(!!ddraw, "Failed to create a ddraw object.\n"); > > + memset(&param, 0, sizeof(param)); > + hr = IDirectDraw7_EnumDisplayModes(ddraw, 0, NULL, &param, test_coop_level_mode_set_enum_cb); > + ok(SUCCEEDED(hr), "Failed to enumerate display mode, hr %#x.\n", hr); > + ref = IDirectDraw7_Release(ddraw); > + ok(ref == 0, "The ddraw object was not properly freed: refcount %u.\n", ref); ... > + ddraw = create_ddraw(); > + ok(!!ddraw, "Failed to create a ddraw object.\n"); This seems odd, why do you recreate the ddraw object?

1 0

Re: [PATCH 4/5] d3d8/tests: Fix some wndproc comparison error messages.
by Marvin Nov. 11, 2014

Nov. 11, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=10175 Your paranoid android. === w8 (32 bit device) === device.c:1173: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1218: Test failed: Reset failed, hr 0x88760868. device.c:1220: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1224: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1231: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1232: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1233: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1234: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1235: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1236: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1241: Test failed: Screen width is 640, expected 800. device.c:1242: Test failed: Screen height is 480, expected 600. device.c:1248: Test failed: Back buffer width is 640, expected 800. device.c:1250: Test failed: Back buffer height is 480, expected 600. device.c:1280: Test failed: Screen width is 640, expected 1024. device.c:1281: Test failed: Screen height is 480, expected 768. device.c:2439: Test failed: Expected foreground window 000701B2, got 0002004C. device.c:2808: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:2812: Test failed: Expected device window extended style 0x108, got 0x100. device.c:2834: Test failed: Failed to reset device, hr 0x88760868. device.c:2838: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:2842: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3209: Test failed: Failed to reset device. device.c:3216: Test failed: Expected {0, 0, 1024, 768}, got {0, 0, 512, 384}. device.c:3224: Test failed: Expected wndproc != 0x412eb0.

1 0

Re: avifil32: Simplify comparing two unsigned ints (PVS-Studio) (try 2)
by Ken Thomases Nov. 10, 2014

Nov. 10, 2014

On Nov 10, 2014, at 4:56 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > try 2: added the missing +1 thanks to a hint by ken on irc > --- > dlls/avifil32/avifile.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c > index 6295c7b..3d90e20 100644 > --- a/dlls/avifil32/avifile.c > +++ b/dlls/avifil32/avifile.c > @@ -466,9 +466,9 @@ static HRESULT WINAPI IAVIFile_fnDeleteStream(IAVIFile *iface, DWORD fccType, LO > /* ... so delete it now */ > HeapFree(GetProcessHeap(), 0, This->ppStreams[nStream]); > > - if (This->fInfo.dwStreams - nStream > 0) > - memcpy(This->ppStreams + nStream, This->ppStreams + nStream + 1, > - (This->fInfo.dwStreams - nStream) * sizeof(IAVIStreamImpl*)); > + if (nStream < This->fInfo.dwStreams) > + memcpy(&This->ppStreams[nStream], &This->ppStreams[nStream + 1], > + (This->fInfo.dwStreams - nStream) * sizeof(This->ppStreams[0])); > > This->ppStreams[This->fInfo.dwStreams] = NULL; > This->fInfo.dwStreams--; This is a more faithful refactoring of the original logic. However, looking at it some more, it looks like the original logic was wrong. It's removing an entry from the array and shifting the following entries up to fill the gap. There are This->fInfo.dwStreams - nStream entries from the nStream'th one to the end. There are only This->fInfo.dwStreams - (nStream + 1) entries that actually _follow_ the nStream'th one. The original logic read past the end of the array and this logic still does. -Ken

1 1

Wine Mono 4.5.4 Release
by Vincent Povirk Nov. 10, 2014

Nov. 10, 2014

I have published version 4.5.4 of Wine Mono on sourceforge. Once again, it's been about a year since the last release. I really am trying to make these more frequent, but for various reasons it hasn't worked out that way. Due to some odd behavior in msi (or so I'm assuming, unfortunately I haven't had a chance to investigate in any detail), it is necessary to run 'wine64 msiexec /i wine-mono-4.5.4.msi' to install in a 64-bit prefix. Installing without the wine64 uses the 32-bit version of msiexec which somehow installs it alongside the default Wine Mono install instead of upgrading it. Any testing with .NET software (in particular .NET software that has been known to work before, if anyone knows of such a thing) would be appreciated. The source tarball is at https://sourceforge.net/projects/wine/files/Wine%20Mono/4.5.4/wine-mono-4.5… The binary is at https://sourceforge.net/projects/wine/files/Wine%20Mono/4.5.4/wine-mono-4.5… For developers, the source repository is at https://github.com/madewokherd/wine-mono Changes since 4.5.2: * Removed MonoGame. It was problematic because MG didn't have binary compatibility with XNA as a goal, I didn't have time to update from upstream, and the MS version of XNA was used anyway if it was installed, which it usually is. I may consider including a real XNA binary replacement if one appears, but for now I think it's better to work on making the MS implementation work. * It's no longer necessary to have gmcs installed to build from a tarball. Tarballs now include a build of Monolite for bootstrapping the compiler, which is the same thing the Mono project does with their tarballs. This was to avoid problems with old Mono versions not being able to bootstrap the current compiler. * A -l switch was added to build-winemono.sh, which fetches an official Monolite build and uses that to bootstrap the compiler. This is only useful if you are building from Git and don't have a sufficiently new gmcs to make this work. * The build will now abort if -t is specified and any tests fail to build. * The libmono build now specifies strict Dwarf2 debugging symbols, to keep it compatible with winedbg. * The libmono build now specifies static libgcc, to avoid linking errors on recent mingw. * We now use dllmap configuration to find MonoPosixHelper, which eliminates some diffs from upstream and will remove the need for Wine to mess with the PATH of .NET applications. * Added a Wine-specific implementation of System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeInterfaceAsObject and GetRuntimeInterfaceAsIntPtr. * Updated Mono to the master branch as of October 31, bringing in many changes including the following: * Fixed use of RVA fields pointing to zeroed static data that isn't physically in the PE file (improves managed C++ compatibility). * Added support for service processes using ServiceBase.Run. * It's now possible to change how debug output is printed via the embedding API, which will make possible a future change to Wine to send the output to the Unix stderr stream. * Beginnings of a System.Management implementation.

1 0

Re: [PATCH 3/3] mshtml: Added script element readyState and onreadystatechange tests.
by Marvin Nov. 10, 2014

Nov. 10, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=10164 Your paranoid android. === w8 (32 bit script) === script.c:632: Test failed: L"extern_res_script_rs = loaded0,eval,complete1, expected eval,complete1,"

1 0

Re: [PATCH 1/3] mshtml: Ignore query and hash parts in res protocol handler.
by Marvin Nov. 10, 2014

Nov. 10, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=10163 Your paranoid android. === w2000pro (32 bit protocol) === protocol.c:144: Test failed: expected: 00000000 got: 80070716 protocol.c:255: Test failed: Start failed: 80070716 protocol.c:258: Test failed: expected ReportProgress protocol.c:259: Test failed: expected ReportData protocol.c:280: Test failed: Read failed: 80004005 protocol.c:144: Test failed: expected: 00000000 got: 80070716 protocol.c:255: Test failed: Start failed: 80070716 protocol.c:258: Test failed: expected ReportProgress protocol.c:259: Test failed: expected ReportData protocol.c:280: Test failed: Read failed: 80004005

1 0

Sourceforge says 1.5.22 is the latest version
by Rosanne DiMesio Nov. 10, 2014

Nov. 10, 2014

Not really sure whose bug this is, but a user just pointed out that http://sourceforge.net/projects/wine/files/Source/ (which the source link at the bottom of our Downloads page leads to) has a line stating "Looking for the latest version? Download wine-1.5.22.tar.bz2 (21.2 MB)." The main project page, http://sourceforge.net/projects/wine/, also has a big green Download button for 1.5.22.tar.bz2.

4 3

Re: kernel32: add TRUST_E_NOSIGNATURE resource definition
by Alexandre Julliard Nov. 10, 2014

Nov. 10, 2014

Austin English <austinenglish(a)gmail.com> writes: > @@ -281,8 +281,8 @@ msg : msgid sevfacsym { test_id($1); } bodies { $$ = complete_msg($4, $1); } > ; > > msgid : tMSGID '=' id { > - if($3 & (~0xffff)) > - xyyerror("Message ID value out of range (0x%08x > 0xffff)\n", $3); > + if($3 & (~0xffffffff)) > + xyyerror("Message ID value out of range (0x%08x > 0xffffffff)\n", $3); There shouldn't be any need to change the message compiler, there are severity/facility message options. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: Move IME Window Procedure to user32
by Piotr Caban Nov. 10, 2014

Nov. 10, 2014

Hi, could you please give me any hints related to this patch? The way how imm32 is loaded or not is quite strange in it. It's generally matching native behavior but I'm not sure if it's needed here. I also don't see a nice way of testing it inside wine test suite. Thank you, Piotr

2 4

Re: [PATCH] reg.exe: Modernise print functions
by Jonathan Vollebregt Nov. 10, 2014

Nov. 10, 2014

> WCHAR msg_buffer[1024]; No easy way to get the expected size and dynamically allocate the output I take it? I looked into it before but besides _vscprintf (In msvcrt, which we're not allowed to use) there doesn't seem to be a way to get the expected output size besides perhaps growing the buffer over and over again until it fits (Which seems inefficient for a simple printing function)

1 0