February 2016 - Wine-devel - list.winehq.org

Running WineTest every day the easy way
by Francois Gouget 09 Feb '16

09 Feb '16

So this time I've done things in the right order: first publish the code and then announce it. So here's wt-daily, a script to "orchestrate all the daily WineTest runs and related tasks." Here's the 'quickstart guide': git clone https://github.com/fgouget/wt-daily.git cd wt-daily vi wt-daily.config In this file set the following environment variables: email="your email address here" tag="a-tag" desc="A description of your system for Wine developers" shutdown="suspend" Then when you know you won't be needing your computer for a while, just type ./wt-daily. This will update and rebuild Wine, run the tests and finally suspend your machine. It's that simple! If you'd rather not suspend your machine you can set shutdown to "poweroff", "reboot" or even leave it out to keep the computer on. By default wt-daily will ask for your green light before starting the tests. So you can start it while still using the computer and click 'Ok' once you take off. To have the tests run automatically (e.g. from cron), pass --auto-test on the command line or set default_options="--auto-test" in the configuration file. If you have a 64-bit system then you can also set the {tag,desc}wow32 and {tag,desc}wow64 variables to run the tests in a mixed 32/64-bit WinePrefix. If you have a Mac, set the {tag,desc}mac variables to run the tests using the Mac driver instead of (or in addition to) X11. The script should work on OS/X though I have obviously not tested it in a long time. I'ĺl be happy to get feedback on that, particularly in the form of patches. Now you can totally stop reading here. But there's a ton more that the script can do. Read on if you want to discover more. You can have the script start an application that will prevent the tests from running until you close it. I used that to run the tests on a MythTV client box. Wine would get updated and rebuilt in the background while I was watching TV and once that was done the script would run the tests and finally power off the computer. You can also take an image of a suitably configured Windows partition and have wt-daily restore that image to the partition, reboot to Windows which will automatically run WineTest (you'll find the batch script for that in the repository), then reboot back to Linux (or shutdown the computer). This functionality is used on the cw1-hd6800 and xw2-gtx560 CodeWeavers boxes to run the tests on Linux, then Windows 8.1 and then Windows 10. All automatically. The script actually runs every hour and skips the tests (and rebooting) if nothing changed since the last run. I also have this Windows image thing set up on my fg-acer64 laptop but there I interactively select which Windows image to restore, with a choice of Windows 8, 8.1 and 10 (or nothing if I don't feel like going through a reboot). You can also extend wt-daily to add non Wine tasks. For instance on my laptops it runs another script that synchronizes the Documents folder with my desktop and runs 'git fetch --all' in all my Git repositories. This way the next time I go offline everything is up to date. The repository also contains a number or scripts that you may find useful in your own automation tasks as they support not just Linux but OS/X too. wt-image Creates, checks, restores or reboots to a disk image. wt-bot Update, build and check the Wine source code, and run the tests. wt-make Seeks to automatically fully use CPU and I/O parallelism when running make. wt-ask Asks a simple Yes/No question to the user. wt-notify Displays a notification to the user. wt-power Powers off, reboots, suspends or hibernates the computer. wt-screensaver Controls the screensaver. In particular it can prevent it from triggering. wt-nice Runs the specified command with the lowest possible CPU and I/O priority. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

1 1

Re: [PATCH] gdi32: Fix otmfsSelection to have bold style set in case of bold simulation
by Marvin 09 Feb '16

09 Feb '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=20292 Your paranoid android. === wvistau64 (64 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

1 0

finalizing 64-bit mixed mode issues
by Paul Gofman 09 Feb '16

09 Feb '16

Hi Vincent, I currently have all my cases with 64-bit mixed assemblies calling pure .Net working just fine under Wine/Mono (well, almost fine, it looks like I found a bug in Mono System.Windows.Forms cs code, but this is a separate issue), but not with vanilla ones. The following issues are not fixed upstream yet: 1. Loading 32-bit pure assemblies in 64-bit code. The patch you attached some time ago (which includes CorValidateImage implementation) works just fine for me. Do you have any plans for pushing it upstream soon? 2. Mono JIT compiler PTR/I8 issues. I've extended a bit your test case and updated the patch in the Mono bug info. While we are waiting for some reply on this in Mono maybe it is possible to send my patch for wine-mono? I am not sure that it is fully correct (it would in fact require to get familiar with the whole JIT code generation path to make sure), but I presume it is safe to use as: - the changes relate to 64-bit code generation only, 32 bit is not affected anyhow; - as for 64 bit, the changes solely extend what instruction/call parameters are considered valid for JIT code generator. If something was valid without this patch, it will not be affected. If something was invalid and gets touched by the patch incorrectly for some cases, it will likely result in segfault instead of 'invalid il code' exception in the worst case. 3. 64-bit .Net programs constantly crashing on process exit for me (this affects test case with exe and dll you sent previously as well). The crash happens in Mono GC finalizing code triggered by System.Process.Exit call from mscoree CorExitProcess. The immediate crash reason is that some objects touched by GC through its hash tables get NULL vtable pointer somewhere earlier in deinitialization. I did not find the exact reason for this yet, but looked at coree.c in Mono where they just call ExitProcess without anything else, and comment says: "FIXME: This is not currently supported by the runtime.". If I do the same in mscoree CorExitProcess it fixes the issue with crash. Do you think this is a right way to do for now? If yes I could send a patch for this. Thanks, Paul.

2 6

Re: [PATCH 1/2] gdi32: Fix otmfsSelection to have italic style set in case of oblique simulation
by Dmitry Timoshkov 09 Feb '16

09 Feb '16

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + hdc = GetDC(0); > + hfont = CreateFontIndirectA(lf); > + ok(hfont != NULL, "failed to create a font\n"); > + > + hfont_old = SelectObject(hdc, hfont); Please avoid using GetDC(0) for all kinds of graphics tests, this may lead (inadvertently) to graphics artifacts because it's basically an eqivalent of CreateDC("display"). I'd suggest to use CreateCompatibleDC(0) instead, and create a dedicated window if painting is really desired. -- Dmitry.

2 1

Re: [PATCH 2/2] gdi32/tests: Turn some asserts in font tests into regular tests
by Marvin 09 Feb '16

09 Feb '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=20287 Your paranoid android. === wvistau64 (32 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) === wvistau64 (64 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

1 0

Re: [PATCH 5/5] d3d11/tests: Test creation of typeless resources.
by Henri Verbeet 09 Feb '16

09 Feb '16

On 9 February 2016 at 11:24, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + enum resource_type > + { > + rt_texture_2d, > + rt_texture_3d, > + }; > + > + static const struct > + { > + DXGI_FORMAT format; > + D3D11_BIND_FLAG bind_flags; > + enum resource_type type; Why not D3D11_RESOURCE_DIMENSION?

2 2

Re: [PATCH] winebuild: When building implibs, invoke dlltool with a machine type.
by Alexandre Julliard 09 Feb '16

09 Feb '16

Charles Davis <cdavis5x(a)gmail.com> writes: > That way, if the installed MinGW toolchain is multilib enabled (as mine > is), the import libraries will get built for the correct architecture. This breaks the build for me: /usr/bin/x86_64-w64-mingw32-dlltool: Machine 'x86_64' not supported winebuild: /usr/bin/x86_64-w64-mingw32-dlltool failed with status 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Gecko 2.44 not there yet?
by Gerald Pfeifer 09 Feb '16

09 Feb '16

I noticed that the release notes of Wine 1.9.3 announced a "new version of the Geck engine based on Firefox 44". Alas, none of the many sf.net mirrors I tried carries http://*.dl.sourceforge.net/project/wine/Wine%20Gecko/2.44/ . The Wiki at https://wiki.winehq.org/Gecko refers to http://dl.winehq.org/wine/wine-gecko/2.40//wine_gecko-2.44-x86.msi which does not exist either. (Note 2.40 vs 2.44.) And http://sourceforge.net/projects/wine/files/Wine%20Gecko/ does not seem to carry a trace, either. Gerald

2 2

Re: [PATCH 1/5] wined3d: Add support for WINED3DFMT_R16_UINT format.
by Józef Kucia 09 Feb '16

09 Feb '16

On Tue, Feb 9, 2016 at 10:53 AM, Józef Kucia <jkucia(a)codeweavers.com> wrote: > struct wined3d_format_block_info > @@ -1138,6 +1139,10 @@ static const struct wined3d_format_texture_info format_texture_info[] = > WINED3DFMT_FLAG_TEXTURE | WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING > | WINED3DFMT_FLAG_RENDERTARGET, > ARB_TEXTURE_RG, NULL}, > + {WINED3DFMT_R16_UINT, GL_R16UI, GL_R16UI, 0, > + GL_RED_INTEGER, GL_UNSIGNED_SHORT, 0, > + WINED3DFMT_FLAG_TEXTURE, > + WINED3D_GL_VERSION_3_0, NULL}, Actually, it should depend on ARB_TEXTURE_RG.

1 0

Re: [PATCH 2/2 v2] odbccp32: Implement SQLRemoveDriver/SQLRemoveDriverW
by Sebastian Lackner 09 Feb '16

09 Feb '16

On 07.01.2016 08:15, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/odbccp32/odbccp32.c | 57 ++++++++++++++++++++++++++++++++++++++++------ > dlls/odbccp32/tests/misc.c | 4 ++-- > 2 files changed, 52 insertions(+), 9 deletions(-) > > diff --git a/dlls/odbccp32/odbccp32.c b/dlls/odbccp32/odbccp32.c > index 3d150a1..a55947b 100644 > --- a/dlls/odbccp32/odbccp32.c > +++ b/dlls/odbccp32/odbccp32.c > @@ -1105,22 +1105,65 @@ BOOL WINAPI SQLRemoveDefaultDataSource(void) > return FALSE; > } > > -BOOL WINAPI SQLRemoveDriverW(LPCWSTR lpszDriver, BOOL fRemoveDSN, > - LPDWORD lpdwUsageCount) > +BOOL WINAPI SQLRemoveDriverW(LPCWSTR lpszDriver, BOOL removeDSN, LPDWORD usage_count) When you are refactoring code like this, please also use "const WCHAR *" and "DWORD *" instead of LP* types. Any reason why you keep the ugly name for lpszDriver? > { > + DWORD usage_cnt = 0; > + HKEY hkey; > + > clear_errors(); > - FIXME("%s %d %p\n", debugstr_w(lpszDriver), fRemoveDSN, lpdwUsageCount); > - if (lpdwUsageCount) *lpdwUsageCount = 1; > + TRACE("%s %d %p\n", debugstr_w(lpszDriver), removeDSN, usage_count); > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, odbcini, &hkey) == ERROR_SUCCESS) > + { > + HKEY hkeydriver; > + > + if (RegOpenKeyW(hkey, lpszDriver, &hkeydriver) == ERROR_SUCCESS) > + { > + if (usage_count) > + { > + if (RegGetValueA(hkeydriver, NULL, "UsageCount", RRF_RT_DWORD, NULL, &usage_cnt, NULL) == ERROR_SUCCESS) > + { > + usage_cnt--; Implementing UsageCount handling only here doesn't seem very useful. It also has to be set / updated, and depending on the result the code below should behave different. > + } > + } > + > + RegCloseKey(hkeydriver); > + } > + > + if(RegDeleteKeyW(hkey, lpszDriver) != ERROR_SUCCESS) > + ERR("Failed to delete registry key: %s\n", debugstr_w(lpszDriver)); > + > + if (RegOpenKeyW(hkey, odbcdrivers, &hkeydriver) == ERROR_SUCCESS) > + { > + if(RegDeleteValueW(hkeydriver, lpszDriver) != ERROR_SUCCESS) > + ERR("Failed to delete registry value: %s\n", debugstr_w(lpszDriver)); > + > + RegCloseKey(hkeydriver); > + } > + > + } > + > + if (usage_count) > + *usage_count = usage_cnt; > + > return TRUE; > } > > BOOL WINAPI SQLRemoveDriver(LPCSTR lpszDriver, BOOL fRemoveDSN, > LPDWORD lpdwUsageCount) > { > + WCHAR *driver; > + BOOL ret; > + > clear_errors(); > - FIXME("%s %d %p\n", debugstr_a(lpszDriver), fRemoveDSN, lpdwUsageCount); > - if (lpdwUsageCount) *lpdwUsageCount = 1; > - return TRUE; > + TRACE("%s %d %p\n", debugstr_a(lpszDriver), fRemoveDSN, lpdwUsageCount); > + > + driver = SQLInstall_strdup(lpszDriver); > + > + ret = SQLRemoveDriverW(driver, fRemoveDSN, lpdwUsageCount); > + > + HeapFree(GetProcessHeap(), 0, driver); > + return ret; > } > > BOOL WINAPI SQLRemoveDriverManager(LPDWORD pdwUsageCount) > diff --git a/dlls/odbccp32/tests/misc.c b/dlls/odbccp32/tests/misc.c > index 3ae1fd3..e3adffd 100644 > --- a/dlls/odbccp32/tests/misc.c > +++ b/dlls/odbccp32/tests/misc.c > @@ -462,12 +462,12 @@ void test_SQLInstallDriverEx(void) > cnt = 100; > ret = SQLRemoveDriver("WINE ODBC Driver", FALSE, &cnt); > ok(ret, "SQLRemoveDriver failed\n"); > - todo_wine ok(cnt == 0, "SQLRemoveDriver failed %d\n", cnt); > + ok(cnt == 0, "SQLRemoveDriver failed %d\n", cnt); > > cnt = 100; > ret = SQLRemoveDriver("WINE ODBC Driver Path", FALSE, &cnt); > ok(ret, "SQLRemoveDriver failed\n"); > - todo_wine ok(cnt == 0, "SQLRemoveDriver failed %d\n", cnt); > + ok(cnt == 0, "SQLRemoveDriver failed %d\n", cnt); > } > > START_TEST(misc) >

1 0