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

Re: widl: Set name return value (passed by reference) in the alias case alias case in get_user_type.
by Alexandre Julliard 22 Nov '20

22 Nov '20

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > So, I admit I don't really know this code, but looking at it (triggered > by a warning issued by GCC development versions), I noticed that this > variable passed by reference is not initialized here. It's initialized when we return a type, and it doesn't need to be initialized on NULL return. The code is correct, but you could probably set the variable to NULL in the caller to silence the warning. -- Alexandre Julliard julliard(a)winehq.org

2 1

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer 22 Nov '20

22 Nov '20

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong 28 Sep '18

28 Sep '18

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

5 6

COM tracing ...
by Michael Meeks 21 Aug '18

21 Aug '18

Hi guys, Rather a peripheral question; apologies for that - but I'd imagine there are experts here that may be able to help. I have a black-box problem - a Windows app dealing with confidential data that I can't easily touch (and thus can't get to run under Wine) - which does some small but critical automation of MS Office - using VBS / COM scripting. I'd -really- love some input on how best to trace that series of COM method calls on Windows itself ie. the (remote) service activation, and the RPC beyond that - particularly the method names, parameters etc. of the COM/OLE Office API. I've tried (so far): http://www.rohitab.com/apimonitor which, while closed, looks interesting; but traces a lot in a hard-to-search way and doesn't appear to do the trick. https://support.microsoft.com/en-us/help/926098/how-to-enable-com-and-com-d… Sounds useful: using Event Tracing for Windows (ETW) but has this rather unhelpful property: "The binary file must be formatted by Microsoft so that it can be analyzed. Please forward the .etl files to your support contact. ..." ;-) Component models used to be all the rage in my youth ;-) surely someone solved the "strace for COM calls" problem elegantly some-when ! Crazily - might it be possible to instrument, interpose and use Wine's COM impl. on Windows [ which sounds a bit 'exciting' ;-], or ? Anyhow - help much appreciated & sorry for the noise ! Regards, Michael. -- michael.meeks(a)collabora.com <><, Pseudo Engineer, itinerant idiot

2 4

[PATCH v2] ddraw/tests: Recognize mipmap brokenness on Windows 8 and 10
by Alex Henrie 16 Jul '18

16 Jul '18

Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> --- v2: Reset diff_count3 to 0 after use dlls/ddraw/tests/d3d.c | 77 ++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 56 insertions(+), 21 deletions(-) diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c index 77836fd627..3cc40e24c4 100644 --- a/dlls/ddraw/tests/d3d.c +++ b/dlls/ddraw/tests/d3d.c @@ -24,6 +24,7 @@ #include "wine/test.h" #include <limits.h> +#include <math.h> #include "initguid.h" #include "ddraw.h" #include "d3d.h" @@ -1418,7 +1419,7 @@ static void DeviceLoadTest(void) RECT loadrect; POINT loadpoint; int i, i1, i2; - unsigned diff_count = 0, diff_count2 = 0; + unsigned diff_count = 0, diff_count2 = 0, diff_count3 = 0; unsigned x, y; BOOL load_mip_subset_broken = FALSE; IDirectDrawPalette *palettes[5]; @@ -1939,6 +1940,7 @@ static void DeviceLoadTest(void) { diff_count = 0; diff_count2 = 0; + diff_count3 = 0; memset(&ddsd, 0, sizeof(DDSURFACEDESC2)); ddsd.dwSize = sizeof(ddsd); @@ -1953,6 +1955,9 @@ static void DeviceLoadTest(void) for (x = 0; x < ddsd.dwWidth; x++) { DWORD color = *textureRow++; + DWORD r = (color & 0xff0000) >> 16; + DWORD g = (color & 0xff00) >> 8; + DWORD b = (color & 0xff); if (x < loadpoint.x || x >= loadpoint.x + loadrect.right - loadrect.left || y < loadpoint.y || y >= loadpoint.y + loadrect.bottom - loadrect.top) @@ -1961,10 +1966,6 @@ static void DeviceLoadTest(void) } else { - DWORD r = (color & 0xff0000) >> 16; - DWORD g = (color & 0xff00) >> 8; - DWORD b = (color & 0xff); - if (r != (0xf0 | i1) || g != x + loadrect.left - loadpoint.x || b != y + loadrect.top - loadpoint.y) diff_count++; } @@ -1978,21 +1979,29 @@ static void DeviceLoadTest(void) } else { - DWORD r = (color & 0xff0000) >> 16; - DWORD g = (color & 0xff00) >> 8; - DWORD b = (color & 0xff); - if (r != (0xf0 | i1) || !IS_VALUE_NEAR(g, x + loadrect.left - loadpoint.x) || !IS_VALUE_NEAR(b, y + loadrect.top - loadpoint.y)) diff_count2++; } + + /* some windows 8 and 10 machines copy the wrong mip */ + if (x < loadpoint.x / 16 || x >= ceil((loadpoint.x + loadrect.right - loadrect.left) / 16.0) || + y < loadpoint.y / 16 || y >= ceil((loadpoint.y + loadrect.bottom - loadrect.top) / 16.0)) + { + if (color & 0xffffff) diff_count3++; + } + else + { + if (r != (0xf0 | (i1 + 4)) || g != x || b != y) diff_count3++; + } } } hr = IDirectDrawSurface7_Unlock(texture_levels[1][i1], NULL); ok(hr==DD_OK, "IDirectDrawSurface7_Unlock returned: %x\n",hr); - ok(diff_count == 0 || diff_count2 == 0, "Unexpected destination texture level pixels; %u differences at %d level\n", - MIN(diff_count, diff_count2), i1); + ok(diff_count == 0 || diff_count2 == 0 || broken(diff_count3 == 0), + "Unexpected destination texture level pixels; %u differences, %d level\n", + MIN(MIN(diff_count, diff_count2), diff_count3), i1); loadpoint.x /= 2; loadpoint.y /= 2; @@ -2145,6 +2154,7 @@ static void DeviceLoadTest(void) skip("IDirect3DDevice7_Load is broken (happens on some modern Windows installations like XP). Skipping affected tests.\n"); } else { diff_count = 0; + diff_count3 = 0; for (y = 0 ; y < ddsd.dwHeight; y++) { @@ -2153,6 +2163,9 @@ static void DeviceLoadTest(void) for (x = 0; x < ddsd.dwWidth; x++) { DWORD color = *textureRow++; + DWORD r = (color & 0xff0000) >> 16; + DWORD g = (color & 0xff00) >> 8; + DWORD b = (color & 0xff); if (x < loadpoint.x || x >= loadpoint.x + loadrect.right - loadrect.left || y < loadpoint.y || y >= loadpoint.y + loadrect.bottom - loadrect.top) @@ -2161,13 +2174,20 @@ static void DeviceLoadTest(void) } else { - DWORD r = (color & 0xff0000) >> 16; - DWORD g = (color & 0xff00) >> 8; - DWORD b = (color & 0xff); - if (r != (0xf0 | 2) || g != x + loadrect.left - loadpoint.x || b != y + loadrect.top - loadpoint.y) diff_count++; } + + /* some windows 8 and 10 machines copy the wrong mip */ + if (x < loadpoint.x / 16 || x >= (loadpoint.x + loadrect.right - loadrect.left) / 16 || + y < loadpoint.y / 16 || y >= (loadpoint.y + loadrect.bottom - loadrect.top) / 16) + { + if (color & 0xffffff) diff_count3++; + } + else + { + if (r != 0xf7 || g != x || b != y) diff_count3++; + } } } } @@ -2175,7 +2195,9 @@ static void DeviceLoadTest(void) hr = IDirectDrawSurface7_Unlock(texture_levels[1][0], NULL); ok(hr==DD_OK, "IDirectDrawSurface7_Unlock returned: %x\n",hr); - ok(diff_count == 0, "Unexpected destination texture level pixels; %u differences\n", diff_count); + ok(diff_count == 0 || broken(diff_count3 == 0), + "Unexpected destination texture level pixels; %u differences\n", + MIN(diff_count, diff_count3)); for (i = 0; i < 2; i++) { @@ -2287,6 +2309,7 @@ static void DeviceLoadTest(void) if (ddsd.dwWidth == ddsd2.dwWidth && ddsd.dwHeight == ddsd2.dwHeight) { diff_count = 0; + diff_count3 = 0; memset(&ddsd, 0, sizeof(DDSURFACEDESC2)); ddsd.dwSize = sizeof(ddsd); @@ -2301,6 +2324,9 @@ static void DeviceLoadTest(void) for (x = 0; x < ddsd.dwWidth; x++) { DWORD color = *textureRow++; + DWORD r = (color & 0xff0000) >> 16; + DWORD g = (color & 0xff00) >> 8; + DWORD b = (color & 0xff); if (x < loadpoint.x || x >= loadpoint.x + loadrect.right - loadrect.left || y < loadpoint.y || y >= loadpoint.y + loadrect.bottom - loadrect.top) @@ -2309,20 +2335,29 @@ static void DeviceLoadTest(void) } else { - DWORD r = (color & 0xff0000) >> 16; - DWORD g = (color & 0xff00) >> 8; - DWORD b = (color & 0xff); - if (r != (0xf0 | i1) || g != x + loadrect.left - loadpoint.x || b != y + loadrect.top - loadpoint.y) diff_count++; } + + /* some windows 8 and 10 machines copy the wrong mip */ + if (x < loadpoint.x / 16 || x >= ceil((loadpoint.x + loadrect.right - loadrect.left) / 16.0) || + y < loadpoint.y / 16 || y >= ceil((loadpoint.y + loadrect.bottom - loadrect.top) / 16.0)) + { + if (color & 0xffffff) diff_count3++; + } + else + { + if (r != (0xf0 | (i + 4)) || g != x || b != y) diff_count3++; + } } } hr = IDirectDrawSurface7_Unlock(texture_levels[1][i], NULL); ok(hr==DD_OK, "IDirectDrawSurface7_Unlock returned: %x\n",hr); - ok(diff_count == 0, "Unexpected destination texture level pixels; %u differences at %d level\n", diff_count, i1); + ok(diff_count == 0 || broken(diff_count3 == 0), + "Unexpected destination texture level pixels; %u differences at %d level\n", + MIN(diff_count, diff_count3), i1); i++; } -- 2.16.2

2 3

ODBC Databases: Jet/Access success
by Barry Bird 14 Jun '18

14 Jun '18

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

WineConf 2018
by Henri Verbeet 30 Apr '18

30 Apr '18

Hi all, The Wine Project is happy to announce that WineConf 2018 will take place on June 29 - July 1 2018 in The Hague, The Netherlands. As some of you will undoubtedly be aware, this will coincide with the 25th anniversary of Wine. WineConf is the Wine Project's yearly conference, where members of the Wine community, the broader Free Software community and interested users meet up over food and drinks. We traditionally also have a number of talks by attendees, as well as some formal and informal discussions about anything vaguely Wine related. We're still working out some of the details, but since this years' WineConf will take place slightly earlier in the year than has traditionally been the case, we'd like to give everyone sufficient advance notice to make travel arrangements, in particular those of you that would need Visas to travel to The Hague. Subscribe to wineconf(a)winehq.org to stay up-to-date with further developments. Information will also get added to https://wiki.winehq.org/WineConf2018 as it becomes available. Should you have any questions, feel free to send an e-mail to either wineconf(a)winehq.org or me personally, and we'll do our best to come up with an answer. Henri

2 5

Your weekly winetest update
by Zebediah Figura 09 Mar '18

09 Mar '18

Hello folks, my name is Zebediah Figura, and I'll be taking over for Jeremy White today. I'd like to start out by thanking everyone who has been working on fixing tests, with special notice to Alex Henrie who has fixed more Windows tests recently than probably anyone else combined. This mail however is not about Windows at all but Wine. Item one: it seems to me—perhaps naïvely so, but it seems to me that we are closer than ever to having an entirely green machine (well, orange really) on the Linux end—so much so that I'm going to run through the failures that are left. Please do take the time to at least skim, since in some cases this is an RFC and what to do to fix a test isn't exactly clear even though the cause is. I also have a few other comments, so I'd appreciate your reading through to the end of this mail. So, without further ado: --- * kernel32:change is due to the asynchronous nature of inotify. How should this be fixed? inotify gives us one creation event and two or more notifications on the parent. It's not clear how to fix this in the test. It certainly doesn't seem possible to make the server behave like Windows. * ole32:clipboard is explained and fixed by 140671 [1]. * quartz:filtergraph is a number of problems related to winegstreamer teardown. I have a set of patches in my local tree which should clear up most to all of these, and I'd like to start submitting these soon. * shell32:shelllink needs some discussion, I think. The problem is that winemenubuilder is holding the file when we check for leaks. On Windows I would imagine all menu-building would be done synchronously, but on Wine this is implausible since we need to create our own copy of the link icon possibly after the link is created. At one point I suggested that menu-building should occur on prefix shutdown, which, while not really possible to do on top of the Windows API, might nevertheless be the best solution. * urlmon:protocol is explained and fixed by 121083 [2]. This solution is less clean than is ideal, but my further attempts to synchronize more cleanly were met with other failures. I'm willing to take another look at this, although I'd appreciate help. * user32:msg is now down to one consistent failure. This is explained and fixed by 140924/140925 [3]/[4]. * user32:win, perhaps one of the most notorious offenders, has three consistent failures left, and possibly some more intermittent ones. - Lines 3364-5 (test_SetForegroundWindow) and 9940-4 (test_LockWindowUpdate) were determined by jwhite to be the fault of the hwndMain test window being minimized during the test. I further investigated and traced this down, surprisingly enough, to a bug in fvwm, which I've reported at [5]. The bug involves a lot of steps to trigger, notably, and we can (and, I think, should) work around it by modifying the test machine configuration: either by changing the focus mode from MouseFocus, or by removing the RaiseTransient or StackTransientParent style. - Line 6838 (test_EnableWindow) is explained and fixed by 141063 [6]. * wininet:ftp, which affects both Linux and Windows, is a recent failure, as can be seen at [7]. But nothing was changed in the tests at that point. It seems more likely that something changed with respect to the ftp.winehq.org server itself, some time on or before 3 January. Could someone with knowledge of wininet or of the FTP server be implored to look into this? Then there are the following failures. I haven't investigated any of these at all, partly because I'm as yet completely unfamiliar with the respective APIs: * A number of Direct3D failures, all (?) of which seem to be dependent on the driver used. I'm not going to enumerate them all here, but I will make note of the fact that cw1 only needs d3d10core:device, d3d11:d3d11, and d3d9:visual, and cw2 only needs d3d9:device. All of these are consistent. * mmdevapi:capture, intermittent and rare. * mmdevapi:render, intermittent but less rare. * mshtml:htmldoc, intermittent but almost consistent. * urlmon:misc, intermittent. * xaudio2_7:xaudio2, intermittent. While I'm certainly willing to fix every last failure myself if need be, just think how much easier it would be if people who were familiar with the code took a look at it! Then there's one very weird set of failures: every D3D-related test from ddraw:ddraw2 onward (i.e. ddraw, dxdiagn, dxgi), on cw1-hd6800-wow32—and only that architecture—fails to print its summary line. This has been the case for since at least early November (unfortunately I lost the exact date when this started happening, but it wasn't obviously the result of any commit). And, finally, the 64-bit failures: * d3dx9_36:math is slightly off on the spherical harmonics values due to the differences in FP math on 64-bit. Here's inviting someone who knows the math to check all of our numbers and make sure they're correct, or otherwise do as Alex Henrie did for spherical light [8]. All others are due to lack of typelib marshaling: * ieframe:ie * msxml3:domdoc * oleaut32:tmarshal * shell32:shelldispatch * user32:dialog (indirectly, since msxml3:domdoc crashes and leaves the winedbg window open) Perhaps in these cases the best thing to do is to mark those todo_wine_if (sizeof (void *) == 8), since properly implementing the 64-bit marshaller takes more work than anyone is willing to do. --- The ultimate goal, of course, is that we finally get a way to run testbot patches on [ideally multiple] Linux machines. Nobody needs me to tell them how important this is, but of course it's also important that we start from a clean slate, since these tests are going to be run for *every* patch, not just those that modify the tests. So while Linux is in a better state than some Windows versions at this point, it seems to me that we really do want a wholly green machine. Along these lines it's worth noting, by the way, that except for the D3D failures, there seems to be no difference between cw1 and cw2. It seems to me it would be a good thing if we started testing multiple window managers as well (and in particular we may want to test those which see common use such as KWin and Mutter). Also along these lines: presumably setting up the testbot to run linux tests is going to require a fair amount of work, and that work is going to be implied to be François' responsibility. I'd just like to say that I'm willing to help as much as I can, though. Okay, so, all that said, we have another problem. I've tried running winetest on my own machine recently, in the interest of rooting out some of the rarer failures, and I've found that the reports it generates are consistently about 1.7 MB long, which is of course over the 1.5 MB limit that test.winehq.org accepts. I did some sed'ing and came up with the worst offenders as being: test bytes % of report d3d11:d3d11 286861 16.27 ws2_32:sock 108672 6.17 kernel32:virtual 75963 4.29 gdi32:font 64700 3.61 user32:win 62114 3.52 shell32:shlexec 41235 2.34 user32:msg 37126 2.11 This isn't, I assert, something wrong with my setup. The D3D team's obviously admirable predisposition toward verbosity, and the need to print a large number of floating-point values, combined with a total of 2167 tests marked todo, has taken over almost one-sixth of the report. But even with d3d11 removed, the report just barely sneaks in under the limit, at 1475812 bytes. One might blame an excess of trace lines, as last time, but in all reality, I am inclined to think that 1.5 MB is no longer a reasonable limit for a test report. If there is an inherent limitation brought on by server storage space or processing power, well, so be it, but if not we probably will want to either raise it—or otherwise start investing energy into getting rid of existing todos. Alright, that's finally it from me, I promise. At least for now ;-) [1] https://source.winehq.org/patches/data/140671 [2] https://www.winehq.org/pipermail/wine-devel/2018-January/121083.html [3] https://source.winehq.org/patches/data/140924 [4] https://source.winehq.org/patches/data/140925 [5] https://github.com/fvwmorg/fvwm/issues/51 [6] https://source.winehq.org/patches/data/141063 [7] http://test.winehq.org/data/tests/wininet:ftp.html [8] https://source.winehq.org/git/wine.git/commit/07f7022fccc1c51eb4ccb4b6735e7…

5 12

[PATCH] winetest/dissect: Stop complaining if a test file doesn't match the current test.
by Zebediah Figura 07 Mar '18

07 Mar '18

Now that we have support for custom dlls in e.g. dlls/msi/tests/custom.c. --- winetest/dissect | 2 -- 1 file changed, 2 deletions(-) diff --git a/winetest/dissect b/winetest/dissect index 9635f0a..7416317 100755 --- a/winetest/dissect +++ b/winetest/dissect @@ -624,7 +624,6 @@ while ($line = <IN>) { add_test_line("failed", escapeHTML($pollution) . get_source_link($l_unit, $l_num) .": ". escapeHTML($l_text)); - check_unit($l_unit, "failure"); $failures++; } elsif ($line =~ /^()([_a-z0-9]+)\.c:(\d+): (Test marked todo: .*)$/ or @@ -635,7 +634,6 @@ while ($line = <IN>) { add_test_line("todo", escapeHTML($pollution) . get_source_link($l_unit, $l_num) .": ". escapeHTML($l_text)); - check_unit($l_unit, "todo"); $todo++; } elsif ($line =~ /^()([_a-z0-9]+)\.c:(\d+): (Tests skipped: .*)$/ or -- 2.7.4

2 3

Google Summer of Code 2018
by André Hentschel 04 Mar '18

04 Mar '18

Hi, I'm currently doing the Org application for Wine, hopefully we'll have a great GSoC year! For now, I need two things from you: - Go through https://wiki.winehq.org/Summer_Of_Code and add/cleanup/remove ideas - Send me a mail if you would like to be a mentor (I will also invite usual mentor candidates to catch the lazy people :) )

5 5