December 2022 - Wine-Devel - list.winehq.org

Re: TestBot News: Missing dlls and VM updates

by Francois Gouget

On Thu, 22 Dec 2022, Fabian Maurer wrote: > > * d3dcompiler_46 > > I can install version 43 and 47 from dxwebsetup.exe without trouble. > > But d3dcompiler_46.dll? No idea. > > According to winetricks: [...] > Hope that is of use. Thanks. It would be nice to have a more standard / official way of installing these but such a way probably does not exist anymore. -- Francois Gouget <fgouget(a)codeweavers.com>

Dec. 28, 2022

Re: CPython fails to import symlinked packages in recent versions of Wine Staging - how to debug?

by Sebastian M. Ernst

Am 28.12.22 um 15:15 schrieb Eric Pouech: > Le 28/12/2022 à 14:35, Sebastian M. Ernst a écrit : >> Hi all, >> >> I have noticed a "new" issue in Wine Staging that I believe must have >> found its way into it in the October to November time frame. > > please file a bug report on https://bugs.winehq.org to track this https://bugs.winehq.org/show_bug.cgi?id=54228 > the next move should be to run a regression test > (https://wiki.winehq.org/Regression_Testing) to pinpoint the offending > patch A quick "poor-man's regression test" based on Ubuntu packages actually puts the breaking change between staging 7.17 (working) and staging 7.18 (broken), i.e. between ca September 9th and 23rd (build dates). Thanks for keeping them all online.

Dec. 28, 2022

Re: CPython fails to import symlinked packages in recent versions of Wine Staging - how to debug?

by Eric Pouech

Le 28/12/2022 à 14:35, Sebastian M. Ernst a écrit : > Hi all, > > I have noticed a "new" issue in Wine Staging that I believe must have > found its way into it in the October to November time frame. please file a bug report on https://bugs.winehq.org to track this the next move should be to run a regression test (https://wiki.winehq.org/Regression_Testing) to pinpoint the offending patch TIA

Dec. 28, 2022

CPython fails to import symlinked packages in recent versions of Wine Staging - how to debug?

by Sebastian M. Ernst

Hi all, I have noticed a "new" issue in Wine Staging that I believe must have found its way into it in the October to November time frame. I am heavily using CPython on top of Wine. When Python imports modules, it looks for them in certain paths, specified in `sys.path`. For development, it is common practise to symlink a package's folder from e.g. a git repo into one of the folders contained in `sys.path`, usually `site-packages`. Python then happily imports the module from there for e.g. testing. Many tools are built around this workflow. This used to work with Wine Staging until about September and still works with stable releases of Wine 7. However, in recent versions of Wine Staging, 7.22 and 8.0-rc2, the import fails: ``` Traceback (most recent call last): File "<string>", line 1, in <module> File "Z:\work\bar\__init__.py", line 1, in <module> from .subbar import funcbar ModuleNotFoundError: No module named 'bar.subbar' ``` Python's module import mechanism appears to follow the symlink correctly (into module "bar") but fails to "locate" stuff within the linked folder (submodule "bar.subbar"). Other Python code can at least correctly navigate the linked folder's contents, so I am suspecting a `stat` syscall of some kind to return unusual values. Python's import mechanism was rewritten recently, so only versions prior to Python 3.10 appear to be affected. Many packages support down to 3.7 at the moment. A minimal reproducer, all steps included: https://gist.github.com/s-m-e/84d5fbf5663825a46d9ae98e4636d8ec Wine builds from dl.winehq.org/wine-builds/ubuntu on Ubuntu 22.04. I am not sure what I am looking for. How would I debug this from Wine's side or, in other words, what am I looking for in Wine's logs? Is there something that I can try as a workaround (other than going back to older versions of Wine)? Thanks, Sebastian

Dec. 28, 2022

Wine staging 8.0-rc2 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.0-rc2 (474 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * none Added: * None Updated: * ntdll-NtDevicePath 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.

Dec. 23, 2022

Re: TestBot News: Missing dlls and VM updates

by Fabian Maurer

> * d3dcompiler_46 > I can install version 43 and 47 from dxwebsetup.exe without trouble. > But d3dcompiler_46.dll? No idea. According to winetricks: win32 http://download.microsoft.com/download/F/1/3/F1300C9C-A120-4341-90DF-8A5250… 2630bae9681db6a9f6722366f47d055c.cab fil47ed91e900f4b9d9659b66a211b57c39 -> d3dcompiler_46.dll win64 http://download.microsoft.com/download/F/1/3/F1300C9C-A120-4341-90DF-8A5250… 61d57a7a82309cd161a854a6f4619e52.cab fil8c20206095817436f8df4a711faee5b7 -> d3dcompiler_46.dll > * d3drm > Is this a deprecated Direct 3D 8 dll? dxwebsetup.exe does not install > it. Yes, but I thought it's shipped with Windows XP. At least on my VM, it is. winetricks gets it from https://files.holarse-linuxgaming.de/mirrors/microsoft/ directx_feb2010_redist.exe (dxnt.cab), but it's not installed on Win7... Is extracting it from the directx redist an option for the VMs? > * 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. I managed to source one: https://web.archive.org/web/20060509134332/http:// download.microsoft.com/download/4/1/a/41a70f33-ee71-417c-b830-4d3bd0acac13/ VS7.0sp1-KB837234-X86.exe Needs manual extraction though, and the files have weird names. Apart from that, it should work. Hope that is of use. Regards, Fabian Maurer

Dec. 22, 2022

Re: TestBot News: Missing dlls and VM updates

by Bernhard Übelacker

Am 22.12.22 um 02:19 schrieb Rémi Bernon: > On 12/22/22 01:57, Francois Gouget wrote: >> >> 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. >> > I don't know if it's related but I recently had to forcefully set > GALLIUM_DRIVER=llvmpipe environment variable when running stuff on > Xephyr or over ssh X11 forwarding. Otherwise Mesa was crashing trying to > instantiate a d3d12 driver (!!). > > Cheers, Hello, that could probably be https://bugs.debian.org/1025312 , which should already be fixed in unstable, but not yet transitioned to testing. Kind regards, Bernhard

Dec. 22, 2022

Re: TestBot News: Missing dlls and VM updates

by Rémi Bernon

On 12/22/22 01:57, Francois Gouget wrote: > > 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. > I don't know if it's related but I recently had to forcefully set GALLIUM_DRIVER=llvmpipe environment variable when running stuff on Xephyr or over ssh X11 forwarding. Otherwise Mesa was crashing trying to instantiate a d3d12 driver (!!). Cheers, -- Rémi Bernon <rbernon(a)codeweavers.com>

Dec. 22, 2022

TestBot News: Missing dlls and VM updates

by Francois Gouget

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>

Dec. 22, 2022

UIRibbon 2022 Edition

by Fabian Maurer

Hello wine-devel, trying to get more work done on UiRibbon during the holidays, could need some help regarding planning though. Short rundown: uiribbon.dll uses a proprietary binary format to load ribbon structure data. This is created using UICC.exe (shipped by windows SDK) from a XML markup; the binary is embedded into the application. I already reversed the binary format pretty far, and wrote a file format description. That file format description uses Kaitai Struct, a declarative language to generate binary data parsers. Currently I'm working on a Kaitai backend to generate a C parser. I'm probably going to create a folder under "libs" called "uiribbon" where said description and classes generated by kaitai struct (and the runtime) can lie. I do believe that leaving the parser/generation up to Kaitai is a good idea, especially since Wine itself doesn't need to rely on Kaitai. Just need it to regenerate the parser if the format description is modified. I hope that's not a problem, because I really want to go the Kaitai Struct route. The problem: Still not sure how to deal with tests. And if we need to use a writer.. I could make a "custom UICC", a program to turn XML markup into the binary format. Not really useful for applications, but could be a "nice to have" or useful for tests. Lots of work though. Problem 1: Windows doesn't ship UICC by default. That means if we need it for tests, it needs to be installed, or tests won't be able to run. Problem 2: Windows doesn't really have a parser exposed for the binary markup. You can load it and it either works, or doesn't - in the worst case the application simply crashes. Other error cases simply create a broken ribbon, only displayed completely in black. Not easy to see what's wrong, or test if it's wrong to begin with. Although it should probably be possible to extract existing UI elements using uiautomation. Not sure exactly how useful it is. Question is how we do the tests: 1) Put markup and according binaries into the tests, write tests against the binaries to assert what we expect from the written markup. If I recall correctly, embedding binary blobs wasn't too well received. 2) Put markup into tests. Compile it on windows using real UICC, test the parser that way (using something like C_SRCS = ../uiribbon_parser.c to have the parser available in the tests) 3) Compile markup using custom UICC, test the ribbon against windows (using uiautomation, limited testing only). Maybe some combination. Thoughts? Regards, Fabian Maurer

Dec. 18, 2022