I have been reviewing the TestBot and GitLab CI test results for the
merged MRs. While doing that I updated the TestBot's known failures list
(https://testbot.winehq.org/FailuresList.pl) in order to drive down the
false positive rate.
Incidentally I also collected the list of test units causing false
positives, so I'll start with that. Specifically, here are the bugs to
fix to help the GitLab CI:
* Bug 53433 - mmdevapi:capture - impacted 18 MRs
* Bug 54064 - ntdll:threadpool - impacted 15 MRs
* Bug 54078 - ntdll:pipe - impacted 11 MRs
* Bug 54140 - mmdevapi:render - impacted 5 MRs
* Bug 54005 - ole32:clipboard - impacted 5 MRs
* Bug 54037 - user32:msg - impacted 5 MRs
* Bug 54074 - ws2_32:sock - impacted 5 MRs
I classified the TestBot / GitLab CI results as follows:
* False positive
Cases where the CI system incorrectly claimed the MR introduces new
failures. This is typically the case when the failures that are
already present in nightly WineTest results.
* Bad merge
MRs that break a test and got merged anyway.
* Collateral Damage from a bad merge
The false positives (aka collateral damage) caused by one of the bad
merges above.
* Outside interference
This identifies false positives that are not random and intrinsic to
the test but that result from change outside the Wine infrastructure,
for instance certificates that expire, or configuration changes to
servers that break the tests that depend on it.
Of those the only ones that a CI can really avoid are the first type,
aka "False positive". So I calculated the corresponding weekly rate:
Adjusted False Positive rate
Week | TestBot | GitLab CI
2022-11-14 | 21.9% | 8.3%
2022-11-21 | 8.0% | 21.6%
2022-11-28 | 14.7% | 28.4%
2022-12-05 | 8.5% | 24.5%
2022-12-12 | 0.0% | 20.0%
Note that the TestBot's 8% rate for the 11-21 week is not representative
because Wine was broken that week (collateral damage) which prevented
the tests from running in Wine, and thus from contributing real "false
positives". Also the 12-12 week is still incomplete obviously.
Even so I think his shows the TestBot is improving.
Here's a list of the incidents for the weeks above:
* 11-14 An external certificate revocation issue caused crypt32:cert to
fail systematically. This impacted 14 merge requests and was fixed in
MR1360.
* 11-17 MR!1399 got merged despite the TestBot detecting that it
prevented 32-bit Wine tests from running to completion. This impacted
39 merge requests. I could have reduced that number if I had been
faster to reconfigure the TestBot to stop running the full 32-bit Wine
test suite. This was fixed in MR!1524.
* 11-17 MR!1398 got merged despite the TestBot detecting that it broke
ntoskrnl.exe:ntoskrnl on Windows 7. This was fixed in MR!1803.
* 11-22 MR!1495 got merged despite the TestBot detecting that it broke
vbscript:run on Windows *. I don't have a record of the impacted MRs
or of when it was fixed.
* 11-23 The b00a831d direct commit broke kernel32:process in Wine. This
got fixed since.
* 12-07 MR!1732 got merged despite the TestBot detecting that it broke
taskschd:scheduler on Windows *. I immediately added a known failure
entry and no MR got impacted. This was fixed in MR!1736.
If not filtering out the failures caused by these incidents, the false
positive rate is:
Raw False Positive rate
Week | TestBot | GitLab CI
2022-11-14 | 52.1% | 27.1%
2022-11-21 | 50.0% | 29.5%
2022-11-28 | 20.0% | 33.7%
2022-12-05 | 19.1% | 57.4%
2022-12-12 | 0.0% | 20.0%
I think that also shows that the TestBot is improving.
I have attached the raw data I collected and shell snippets to
extract various statistics (failures-mr.txt) as well as a spreadsheet
import (failures.xls).
--
Francois Gouget <fgouget(a)codeweavers.com>
I reviewed the tests that are skipped because the dll is missing on
Windows and I found 4 tests that are never run on Windows which makes
them a bit pointless:
* d3dcompiler_46
I can install version 43 and 47 from dxwebsetup.exe without trouble.
But d3dcompiler_46.dll? No idea.
* d3drm
Is this a deprecated Direct 3D 8 dll? dxwebsetup.exe does not install
it.
* msvcr70
As far as I know this dll is part of the Visual Studio 7.0 runtime.
But that runtime is nowhere to be found.
* msvcrtd
The test look like they succeed on test.winehq.org but in fact all
they do is skip the tests:
debug.c:45: Tests skipped: LoadLibraryA failed to load msvcrtd.dll with GLE=126
(where 126 == ERROR_MOD_NOT_FOUND)
That's the debug version of the Visual C++ C library. As such it's not
shipped by the runtime redistributables. Also, which C runtime does it
correspond to? (iirc it was already there in the 90s)
Note: I'd rather not download these dlls from the many
'not.trojan.horse.dlls.trust.me.com' websites.
VM updates:
* debiant
The gst-plugins-base1.0-dev maintainer intentionally removed
multi-arch support in version 1.20.3-2. As a result GStreamer support
went missing in 32-bit builds when Wine's detection code was tweaked
recently, which in turn caused a lot of new failures (bug 53977).
So I hacked multi-arch support back in and the 32-bit tests are back
to normal.
Another point is that updating the X11 / Mesa packages causes the X
server to crash during the Direct 3D tests. So for now that VM is
frozen in time. That's all worrying for the future Debian 12.
* w11pro64
I added a bunch of Visual Studio C runtime dlls, including msvcr71
which I got through the .Net 1.1 framework. I also added a number of
Direct 3D dlls that don't ship with Windows by default.
* w1064v1709
It seems this snapshot was not entirely idle so I retook it after
Windows Update finished installing the already downloaded
updates (see bug 54158).
This does not seem to have made much of a difference :-(
(particularly for bug 53227)
* w1064v1909
Windows Defender was not disabled and was intefering with the tests
from time to time. That's because 1909 is the first Windows version
where Defender cannot be disabled and where I have to exclude the
WineTest folder instead.
This is fixed now.
* w1064v2004
This snapshot also had some trouble with Windows Update not being idle
so I retook it. This does not seem to have made much of a difference
either :-(
--
Francois Gouget <fgouget(a)codeweavers.com>
Hi all,
The tentative release date for vkd3d 1.7 is March 22, in slightly under
4 weeks. Please test your applications for any regressions, review any
API changes since vkd3d 1.6, and so on. While starting today it will
become increasingly harder to make major code changes until the release,
improvements to the API documentation and tests are welcome as always.
For vkd3d 1.8, the release following 1.7, we're currently aiming for a
date in late June.
Regards,
Henri
Binary packages for various distributions will be available from:
https://www.winehq.org/download
Summary since last release
* Rebased to current wine 8.2 (531 patches are applied to wine vanilla)
The patchinstall.sh script is no longer available and users should use
the staging/patchinstall.py instead.
For those that wanted to use ODBC in windows applications, this is the
release for you.
For those using ADO to connect to a dababase via ODBC, you will still
need to use the native version of msado15 and msdasql. Through some of
the bugs have been identified and fixed in this wine release there is
still more work to be done.
Some cavets on the ODBC support
* Only the Unicode drivers for MySql/PostgreSQL were tested.
* Not all functions have been mapped, so lodge a bug if something is
missing.
Developers.
If anybody has time to have a look over or reivew the patchset, that
would be great. Don't be scared of the 43 patches, most of them are
calls into the loaded driver (boiler plate stuff).
Users.
If you are a user of unixODBC with wine, it would be great if you could
post on bug 54499, the database used or if you prefer to use the
standard windows driver.
Known issues.
* Using SQLDriverConnectW to connect to an ANSI ODBC driver will fail
(works on windows).
* The Driver DLL is possible loaded multiple times (Should have map of
driver/function table).
Upstreamed (Either directly from staging or fixed with a similar patch).
* None
Added:
* [52233] Black NPC's skin or minor rendering glitches in multiple games
(Batman: Arkham Knight, Steel Division: Normandy 44)
* [48220] dxruby needs WAVE form loading implemented
* [45135] Black Rockman Shooter has no sound, implementation missing in
dmime
* [34751] Aura: Fate of the Ages: sounds aren't played, but music works fine
* [9027] No sound for rise of nations - all versions
* [54499] Native ODBC drivers should be able be used.
Updated:
* Install scripts updated to Python 3
* winex11-Fixed-scancodes (was winex11-key_translation)
* ntdll-NtDevicePath
* ntdll-Junction_Points
Where can you help
* Run Steam/Battle.net/GOG/UPlay/Epic
* Test your favorite game.
* Test your favorite applications.
* Improve staging patches and get them accepted upstream.
* Suggest patches to be included in staging.
As always, if you find a bug, please report it via
https://bugs.winehq.org
Best Regards
Alistair.
Hi all,
I was running into some odd behaviour while debugging—specifically, I
found that specifying the d3d channel in WINEDEBUG was cutting my
performance in half, even when disabling logging, and even when it
should have been functionally identical to a run without the d3d channel
specified.
I was able to "fix" this inconsistency with this diff:
diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c
index 1bd8f900d22..f0e4b824918 100644
--- a/dlls/ntdll/thread.c
+++ b/dlls/ntdll/thread.c
@@ -103,7 +103,11 @@ unsigned char __cdecl __wine_dbg_get_channel_flags(
struct __wine_debug_channel
{
pos = (min + max) / 2;
res = strcmp( channel->name, debug_options[pos].name );
- if (!res) return debug_options[pos].flags;
+ if (!res)
+ {
+ if (channel->flags & (1 << __WINE_DBCL_INIT))
channel->flags = debug_options[pos].flags;
+ return debug_options[pos].flags;
+ }
if (res < 0) max = pos - 1;
else min = pos + 1;
}
Which makes sense to some degree, but leaves three questions unanswered,
which I was hoping someone might be able to cluebat me on:
(1) Why does setting channel->flags affect performance at all? I'm
thoroughly baffled by this one.
(2) Why was this diff not applied in the first place? (Simple oversight?)
(3) Why does __WINE_DBCL_INIT even exist, if its only purpose is to
guard out a single assignment?
--Zeb
Hi,
As you might know, Hangover development stalled years ago waiting for the WoW64 support in Wine to complete.
With Wine 8.0 (and even better with Jaceks wow branch) this is now done. In October I started to connect Qemu
to that WoW64 support in my spare time and it progressed until I finally was able to publish some of that work
today. It's still missing instructions and even some patches, but it should give a good introduction on what
this will look like.
In fact I started to get wowarmhw running, so I could do the first steps on a x86-64 machine to run ARM32
binaries. But exactly this part is missing for now as things changed since then.
So in case I made you curious, here's the code :)
https://github.com/AndreRH/hangover
Hello.
I’m using parts of Wine (specifically the vbscript engine) while porting Visual Pinball to be cross platform.
I have been using the WIDL utility extensively and it has worked great.
I wanted to keep my patches up to date so I don’t fall behind, however I am having issues compiling wine after version 7.20.
This was my typical compile:
brew install llvm llvm-mingw
git clone -b wine-7.20 git://source.winehq.org/git/wine.git
git clone [email protected]:vpinball/pinmame.git
cd wine
export MACOSX_DEPLOYMENT_TARGET="10.14"
export LDFLAGS="-Wl,-rpath,/opt/X11/lib"
export PATH="$(brew --prefix llvm)/bin:$PATH"
export PATH="$(brew --prefix bison)/bin:$PATH"
./configure --without-freetype
make -j10
tools/widl/widl -o ../vpinmame_i.h --nostdinc -Ldlls/\* -Iinclude -D__WINESRC__ -D_UCRT ../pinmame/src/win32com/VPinMAME.idl
Now with anything past 7.20 I’m getting:
configure: error: PE cross-compilation is required for ARM64, please install clang/llvm-dlltool/lld, or llvm-mingw.
Is there anyway to disable this?
Thanks
Jason
Binary packages for various distributions will be available from:
https://www.winehq.org/download
Summary since last release
* Rebased to current wine 8.1 (475 patches are applied to wine vanilla)
Upstreamed (Either directly from staging or fixed with a similar patch).
* rpcrt4: Avoid implicit cast of interface pointer.
* include: Add _XHR enum values
* ntdll-Builtin_Prot (removed as PE conversion is complete)
Added:
* None
Updated:
* ntdll-Placeholders
Where can you help
* Run Steam/Battle.net/GOG/UPlay/Epic
* Test your favorite game.
* Test your favorite applications.
* Improve staging patches and get them accepted upstream.
* Suggest patches to be included in staging.
As always, if you find a bug, please report it via
https://bugs.winehq.org
Best Regards
Alistair.
