https://bugs.winehq.org/show_bug.cgi?id=45032
Bug ID: 45032 Summary: WineTest does not run the vcomp tests Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: vcomp Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com Distribution: ---
So WineTest is not running the vcomp tests. What happens is this:
* It parses the vcomp_test.exe filename and concludes that this tests the vcomp dll.
* It does a LoadLibraryExA("vcomp.dll", NULL, LOAD_LIBRARY_AS_DATAFILE) which fails (as expected) and concludes that the dll is missing:
vcomp=dll is missing
* Since the dll is missing WineTest skips the vcomp tests.
According to Dan Kegel (see bug 31609) this is a manifest / activation context issue and he sent a patch for it [1]. However the patch was for the TestBot [2], not WineTest, and as far as I can tell it's not working.
Furthermore WineTest already has activation context code that seems equivalent to Dan Kegel's patch.
Note that not all VMs have vcomp.dll. Based on the current results the 32 bit dll is present on the TestBot's w2000pro, wxppro, w2003std, wvistau64*, w2008s64, w8, w864 VMs and the 64 bit one is present on wvistau64, w2008s64 and w864.
Note that some online resources seem to imply that vcomp.dll is present in the Visual C++ 2005 redistributable (and VC++ 2005 was indeed installed on all the VMs that have vcomp.dll except w2008s64 (though maybe it was installed and it was not written down)). Some VMs seem to have other versions such as vcomp90.dll but not vcomp.dll.
[1] https://bugs.winehq.org/show_bug.cgi?id=31609 https://www.winehq.org/pipermail/wine-patches/2012-September/117631.html
[2] Paradoxically the TestBot has no problem running the vcomp tests now that they dynamically load the vcomp dll. That's because the TestBot makes no assumption based on the executable filename since one can upload test binaries that don't follow any naming scheme. So now that the test dynamically loads vcomp.dll the TestBot cannot check for it.
https://bugs.winehq.org/show_bug.cgi?id=45032
--- Comment #1 from François Gouget fgouget@codeweavers.com --- The last time this was discussed on wine-devel there was a suggestion to give up on checking for the presence of the dlls (or at least not let that stop us from running the tests), and to simply run the test executable.
Indeed we could run 'foo_test.exe --list' to not risk running a test (the unfortunate default if there is only one unit test).
However in the case of a missing dll this would cause the executable to get stuck while Windows shows a dialog saying the dll is missing. This would cause a timeout and delay the tests way too much. Also, killing the process does not dismiss the windows dialog.
Maybe we could take a page out of the shlexec test and wait for the executable for 5 seconds and do a FindWindowA("#32770", "Windows") to click on the OK ourselves.
But I believe on Windows 8+ we had problems due to Windows popping up a window offering to install the missing dll but we could not intercept that one. This should be verified though. Also the dlls could be installed on machines where that is a problem.
https://bugs.winehq.org/show_bug.cgi?id=45032
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- This also affects ntoskrnl.exe now.
https://bugs.winehq.org/show_bug.cgi?id=45032
--- Comment #3 from François Gouget fgouget@codeweavers.com --- The ntoskrnl.exe tests seem to be run fine: https://test.winehq.org/data/tests/ntoskrnl.exe:ntoskrnl.html
https://bugs.winehq.org/show_bug.cgi?id=45032
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- (In reply to François Gouget from comment #3)
The ntoskrnl.exe tests seem to be run fine: https://test.winehq.org/data/tests/ntoskrnl.exe:ntoskrnl.html
Not quite; they're skipped on WoW64 (except Windows 7 apparently for some reason). Not that this matters a lot, on second thought, since I'm pretty sure they'd be skipped then anyway for being unsigned.
https://bugs.winehq.org/show_bug.cgi?id=45032
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|vcomp |testcases
--- Comment #5 from François Gouget fgouget@codeweavers.com --- Changed to component to testcases since the bug is in WineTest.
https://bugs.winehq.org/show_bug.cgi?id=45032
--- Comment #6 from Zebediah Figura z.figura12@gmail.com --- Could we do what TestLauncher does and trawl the image file headers?
https://bugs.winehq.org/show_bug.cgi?id=45032
--- Comment #7 from François Gouget fgouget@codeweavers.com --- The TestLauncher approach is not foolproof either: https://bugs.winehq.org/show_bug.cgi?id=31609
https://bugs.winehq.org/show_bug.cgi?id=45032
--- Comment #8 from Zebediah Figura z.figura12@gmail.com --- But we already deal with manifests in winetest, right? Or is there some other issue I'm missing?
Besides the problem of not running vcomp I notice that user32:winstation is already suffering from the aforementioned dialog boxes in the case of d3dcompiler and mfreadwrite, and apparently also comctl32 [1], which is why my attention was drawn to this bug.
[1] http://test.winehq.org/data/6a157b7e8fdb8966d7d8335123c7d070b75d1b68/win10_n...
https://bugs.winehq.org/show_bug.cgi?id=45032
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |fgouget@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=45032
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED Fixed by SHA1| |e618fb526d06ae19306bae88e81 | |e0214fcbd7d85
--- Comment #9 from François Gouget fgouget@codeweavers.com --- This is fixed by the same patch as for bug 50783. This allows the following extra tests to run now (and maybe more): vcomp, vcomp110, infosoft, and the 32-bit ntoskrnl.exe on 64-bit Windows.
commit e618fb526d06ae19306bae88e81e0214fcbd7d85 Author: Francois Gouget fgouget@codeweavers.com Date: Tue Mar 16 10:34:07 2021 +0100
winetest: Fix detecting whether a test can be run or not.
Rather than second-guessing the loader, run 'test.exe --list' with the critical-error handler message box disabled and use the resulting exit codes. But keep the activation context and COM code to improve the chances of getting the dll version.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45032 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50783 Signed-off-by: Francois Gouget fgouget@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=45032
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.5.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla