wine-devel

wine-devel@winehq.org

9 participants
84457 discussions

Debugging channel weirdness
by Zebediah Figura 14 Feb '23

14 Feb '23

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

2 6

Hangover Update
by André Zwing 11 Feb '23

11 Feb '23

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

1 0

Compiling issues on macOS after 7.20 on ARM
by Jason Millard 10 Feb '23

10 Feb '23

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 git@github.com: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

2 4

Wine staging 8.1 release
by Alistair Leslie-Hughes 03 Feb '23

03 Feb '23

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.

1 0

Re: How should one report GitLab CI bugs?
by Francois Gouget 26 Jan '23

26 Jan '23

On Thu, 19 Jan 2023, Alexandre Julliard wrote: [...] > Would it mean failures that only happen on Gitlab CI? Or failures that > happen in CI but also elsewhere? Either way, the distinction doesn't > seem all that useful to me. The idea was that some Wine developers may be more interested in fixing bugs causing false positives in the new CI system (GitLab CI) than in the old one (TestBot). So identifying those in Bugzilla may help them find targets to work on. But of course that assumes that set of developers is non-empty. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: Alexandre Julliard : shell32: Allocate a full SHITEMID to avoid a compiler warning.
by Eric Pouech 26 Jan '23

26 Jan '23

Le 25/01/2023 à 22:22, Alexandre Julliard a écrit : > Module: wine > Branch: master > Commit: c844ebdb0ae8994ee4f3d1d3c1697ece06f52a4e > URL: https://gitlab.winehq.org/wine/wine/-/commit/c844ebdb0ae8994ee4f3d1d3c1697e… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Jan 24 22:22:52 2023 +0100 > > shell32: Allocate a full SHITEMID to avoid a compiler warning. > > --- > > dlls/shell32/shfldr_fs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/shell32/shfldr_fs.c b/dlls/shell32/shfldr_fs.c > index 662d8b52d5b..d47911dbef7 100644 > --- a/dlls/shell32/shfldr_fs.c > +++ b/dlls/shell32/shfldr_fs.c > @@ -347,7 +347,7 @@ IShellFolder_fnParseDisplayName (IShellFolder2 * iface, > /* Special case for the root folder. */ > if (!wcsicmp( szPath, L"\\\\?\\unix\\" )) > { > - *ppidl = SHAlloc(sizeof(USHORT)); > + *ppidl = SHAlloc(sizeof(*ppidl)); shouldn't it be sizeof(**ppidl) instead to better match the patch description?

1 0

Problem with the wine-gitlab mailing list archive?
by Francois Gouget 26 Jan '23

26 Jan '23

The wine-gitlab mailing list archive shows no new message since last Tuesday (2022-10-18). Yet I did receive emails on that list since then. https://www.winehq.org/mailman3/hyperkitty/list/wine-gitlab@winehq.org/ What's going on? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

4 7

dmloader:dmloader crash on gitlab-debian-64
by Francois Gouget 26 Jan '23

26 Jan '23

On test.winehq.org I see that dmloader:dmloader crashed on gitlab-debian-64 due to an assertion (2023-01-12): 060c:loader: 104 tests executed (0 marked as todo, 0 as flaky, 0 failures), 0 skipped. dmloader:loader:060c done (-2147483391) in 0s 88B Test failed: crash (80000101) https://test.winehq.org/data/patterns.html#dmloader:loader I'd like to know if this is caused by the one assert() in stream_get_chunk(). A backtrace could help in that regard but: * The test report on test.winehq.org only has the test output, not Wine's stderr traces which is where a backtrace would be. http://winetest.dolphin/data/047118247ce489a7138428c8b2cd5692ed04337e/linux… * And the GitLab log has neither the test output nor the Wine traces. https://gitlab.winehq.org/wine/wine/-/jobs/8996 So are the Wine traces available somewhere for GitLab's nightly WineTest runs? -- Francois Gouget <fgouget(a)codeweavers.com>

2 2

Wine staging 8.0 release
by Alistair Leslie-Hughes 25 Jan '23

25 Jan '23

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

1 0

8.0 release notes (draft)
by Alexandre Julliard 24 Jan '23

24 Jan '23

Folks, The final 8.0 will be released shortly. Thanks to everybody who helped fix regressions! We didn't quite make it back to the 7.0 count, but we've still made very good progress, with over 160 bugs fixed during code freeze. Below is the draft of the release notes, please have a look and let me know if anything is incorrect or missing. Thanks to Jacek, Nikolay, Rémi and Zeb for their help with this! -- Alexandre Julliard julliard(a)winehq.org ---------------------------------------------------------------- What's new in Wine 8.0 ====================== *** PE modules - After 4 years of work, the PE conversion is finally complete: all modules can be built in PE format. This is an important milestone on the road to supporting various features such as copy protection, 32-bit applications on 64-bit hosts, Windows debuggers, x86 applications on ARM, etc. However, some modules still perform direct calls between the PE and the Unix part, instead of going through the NT system call interface. The remaining direct calls will be removed during the Wine 8.x development phase. - A special syscall dispatcher is used for PE -> Unix transitions, to avoid the overhead of a full NT system call. This minimizes the performance impact of the new architecture, in particular for the OpenGL and Vulkan libraries. - Building mixed Windows/Unix libraries in ELF format (.dll.so libraries) is still supported for use in Winelib applications. However, such applications won't support features enabled by the NT syscall interface, such as WoW64 without 32-bit libraries. *** WoW64 - WoW64 thunks are implemented for essentially all Unix libraries, enabling a 32-bit PE module to call a 64-bit Unix library. Once the remaining direct PE/Unix calls have been removed, this will make it possible to run 32-bit Windows applications without any 32-bit Unix library. - When the 32-bit Wine loader isn't found, 32-bit applications are started in the new "Windows-like" WoW64 mode (where 32-bit code runs inside a 64-bit host process). This mode can be enabled by building with the '--enable-archs' configure option. Since in case of configuration errors it is possible for it to be triggered inadvertently, applications started in this mode print the warning "starting in experimental wow64 mode". *** Graphics - The "Light" theme is enabled in the default configuration, for a more modern look. Other themes can still be configured through WineCfg. - The graphics drivers (winex11.drv, winemac.drv, wineandroid.drv) are converted to run on the Unix side of the syscall boundary, and interface with the Unix side of the Win32u library. - The Print Processor architecture is implemented. This will be used to avoid direct PE<->Unix calls in the printer driver. - Effects are supported in Direct2D, including description parsing and a number of core objects. - Command lists recording and playback are implemented in Direct2D. - The Vulkan driver supports up to version 1.3.237 of the Vulkan spec. *** Direct3D - Many optimizations related to streaming map acceleration are implemented, in common code as well as in the GL renderer. Depending on the application, this may result in major performance improvements. - Adapter video memory budget change notifications are implemented. - The Vulkan renderer supports setting multiple viewports and scissor rectangles. - Several Direct3D 10 and 11 features, which were already implemented, are accurately reported through capability flags: - Per-format support for vertex and index buffers. - Per-format support for all capabilities via D3D11_FEATURE_FORMAT_SUPPORT. - No-overwrite maps on shader resources and constant buffers. - Partial range binding of constant buffers. - For convenience, a new WINE_D3D_CONFIG environment variable may be used instead of modifying the HKEY_CURRENT_USER\Software\Wine\Direct3D registry key. The value is a comma- or semicolon-separated list of key-value pairs, e.g.: WINE_D3D_CONFIG="renderer=vulkan;VideoPciVendorID=0xc0de" If an individual setting is specified in both the environment variable and the registry, the former takes precedence. - The Direct3D graphics card database recognizes more graphics cards. - The Vulkan renderer limits the maximum Direct3D feature level based on available Vulkan features. *** Audio / Video - The MPEG-1 audio decoder filter for layers 1 and 2, and the separate filter for layer 3, are both implemented on top of GStreamer. - The ASF reader filter is implemented. - The OpenAL32.dll wrapper library is removed, in favor of the native OpenAL32.dll library shipped by Windows applications. *** Media Foundation - Content type resolution is improved in the Media Foundation Player. - Rate control is implemented. - The Enhanced Video Renderer default mixer and presenter are better supported. - The DirectShow filter is implemented in the Enhanced Video Renderer. - An initial framework is implemented for the Writer encoding API. - The topology loader is better supported. *** Input devices - Controller hotplug support is greatly improved, and controller removal and insertion are correctly dispatched to applications. - Driving wheel device detection and reporting is better implemented, using the SDL library and HID usages as hints for the device types. - Force feedback effect support is improved, specifically with driving wheels controllers. - The HID Haptics specification is used for left / right motor rumble and trigger rumble. It makes it possible for device drivers to expose haptics support over HidRaw, and overcome EvDev limitations. - The Joystick Control Panel is redesigned, with new graphics and a dedicated view for XInput gamepads. - Sony DualShock and DualSense controllers are supported when the hidraw backend is used, and exposed to applications in the same way as they are on Windows. - The Windows.Gaming.Input module is introduced, one of the first WinRT modules in Wine, implementing a new programming interface to access gamepads, joysticks and driving wheel devices. For this new input API, hotplug notifications are also implemented, as well as force feedback effects and haptics. This API is the first one to support trigger rumble. *** Internationalization - A proper locale database, in Windows locale.nls format, is generated from the Unicode CLDR database. The list of supported locales is essentially identical to that of the latest Windows version. - Unicode string comparison is based on the Windows Sortkey database and algorithms instead of the Unicode Collation Algorithm, yielding more compatible results. - Characters from high Unicode planes (in UTF-16 encoding) are supported in most functions, in particular for case mappings, BiDi formatting, and character shaping. - The UTF-8 encoding is supported as Ansi codepage. It is enabled when requested by the application's manifest. - Unicode character tables are based on version 15.0.0 of the Unicode Standard. - The timezone data is generated from the IANA timezone database version 2022g. *** Text and fonts - Font linking is enabled for most system fonts, which should fix missing glyphs in CJK locales. - Font fallback in DirectWrite is reworked, with additional support for an large number of scripts. *** Kernel - The ApiSetSchema database is implemented, replacing all the api-ms-* forwarding modules. This reduces both disk space and address space usage. - DOS file attributes are persistent, and stored on disk using the filesystem's extended attributes, in a format compatible with Samba. *** Internet and networking - The Online Certificate Status Protocol (OCSP) is implemented. - More EcmaScript features are supported in JScript standard-compliant mode. - The JScript garbage collector is implemented. - Accessibility support is enabled in Wine Gecko package. - Web Storage, Performance object and more event objects are implemented in MSHTML. *** Mono / .NET - The Mono engine is updated to version 7.4.0. The list of changes can be viewed at https://github.com/madewokherd/wine-mono/releases/tag/wine-mono-7.4.0 *** Builtin applications - All the builtin applications use Common Controls version 6, which enables theming and high-DPI rendering by default. - The Wine Debugger (winedbg) prints thread names in the 'info thread' listing, for applications that set the names of their threads. All internal Wine threads also set their own name. - The QWORD type is supported in the REGEDIT and REG registry tools. - Notepad has a status bar displaying the current cursor position. The Goto Line functionality is also implemented. - The builtin console programs print data in the OEM codepage, for better compatibility with applications reading their output. - The Service Control tool (sc.exe) supports the 'query' command. *** Development tools - The PE conversion has made it necessary to implement a new mechanism to run static C++ constructors in Winelib ELF applications. Unfortunately, this requires the corresponding modules to be rebuilt with Wine 8.0. The rebuilt modules will still run correctly on older Wine versions, but older modules will no longer execute static constructors when run on Wine 8.0. - In regression tests, individual checks can be marked as "flaky". This is useful for checks that depend on external factors such as network timings. The errors are still reported but not counted as failures. - Test failure messages can be printed in color by setting the WINETEST_COLOR environment variable, to make them easier to spot in the test log. - The Resource Compiler (WRC) and Message Compiler (WMC) use the locale.nls database to detect languages and codepages, and thus support all the Windows locales. - The WineDump tool supports printing the contents of Enhanced Metafile spool files, as well as more contents from PDB files. *** Build infrastructure - PE binaries can be built for multiple architectures from the same build tree, using the '--enable-archs' option to configure, for example '--enable-archs=i386,x86_64'. This can be used to enable the experimental WoW64 mode, where 32-bit applications can run without any 32-bit host libraries. - Data types that are defined as 'long' on Windows are defined as 'long' instead of 'int' on all platforms with a 32-bit long type. This is more compatible, but it can cause printf format warnings with Unix compilers. In Winelib code, it can be disabled by defining WINE_NO_LONG_TYPES. - Import libraries can be generated without using dlltool, by passing the '--without-dlltool' option to winebuild. This is used to avoid dlltool bugs with delay import libraries. - Libraries that contain only resources and no code can be built with the '--data-only' option to winegcc, which makes them smaller and more efficient to load. *** Bundled libraries - Faudio is updated to the upstream release 22.11. - LCMS2 is updated to the upstream release 2.14. - LibJPEG is updated to the upstream release 9e. - LibMPG123 is updated to the upstream release 1.31.1. - LibPng is updated to the upstream release 1.6.39. - LibTiff is updated to the upstream release 4.4.0. - LibXml2 is updated to the upstream release 2.10.3. - LibXslt is updated to the upstream release 1.1.37. - Zlib is updated to the upstream release 1.2.13. *** Platform-specific features - The experimental WoW64 architecture is supported on macOS versions from 10.15. - 64-bit time_t is supported on 32-bit Linux with recent Glibc versions. - Exception unwinding on ARM platforms is extended with EHABI support on ARM32 and Dwarf support on ARM64. *** Miscellaneous - RSA encryption and the RSA-PSS signing algorithm are implemented. - An initial version of the UI Automation API is implemented. - C++11 syntax is supported in function name demangling. *** External dependencies - The vkd3d and LDAP libraries are bundled in the source tree and built as PE. The corresponding Unix libraries are no longer needed. - The OpenAL library is no longer used.

3 2

Wine staging 8.0-rc5 release
by Alistair Leslie-Hughes 22 Jan '23

22 Jan '23

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

1 0

[WINE-CE] Wine-CE Can Run Cross Instruction Architecture Windows App
by fanwj＠mail.ustc.edu.cn 19 Jan '23

19 Jan '23

Wine-CE (Chimera Edition) is a compatibility layer capable of running Windows applications on Cross-architecture paltform of Linux. It is base on Wine Project and Qemu Project. Project Address: https://gitee.com/fanwenjie/wine-ce TEST App: Sword and Fairy 3 Demonstration: https://www.bilibili.com/video/BV1Kd4y157Lm

2 1

How should one report GitLab CI bugs?
by Francois Gouget 18 Jan '23

18 Jan '23

How should one report GitLab CI bugs? I'm thinking of two types of bugs. 1. Wine test bugs that specifically happen on the GitLab CI infrastructure. See for instance bug 54334 which describes a set of qasf:asfreader failures that has, so far, only been seen in the Linux GitLab CI. I'm thinking some Wine developers may be particularly interested in getting such bugs fixed and thus would want to have a way to find them. Would a 'gitlabci' or just 'ci' keyword be appropriate? 2. Bugs and missing features in the GitLab CI infrastructure itself. For instance the failures that gitlab-win10-21h2 gets in the ole32:clipboard, riched20:richole and user32:msg tests strongly suggest that the AMD driver was installed with its Adrenalin GUI. Since it is known to interfere with the clipboard this could be considered a bug in that Windows 10 VM configuration. (Alternatively one could argue the tests should be modified to be resistant to such interference which would move this issue to the first category.) Which product should one pick in Bugzilla for reporting such bugs? They would not fit in 'Wine' product or any of the other existing products except 'Wine-Testbot' if one considers the GitLab CI to be the new TestBot (though I think that would be quite confusing). -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Wine staging 8.0-rc4 release
by Alistair Leslie-Hughes 15 Jan '23

15 Jan '23

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

1 0

FOSDEM 2023
by Henri Verbeet 09 Jan '23

09 Jan '23

This year FOSDEM will once again take place in Brussels, on February 4 and 5. The Wine project won't have an official presence at the conference this year, but a (modest) number of us do intend to visit Brussels during that time. Is anyone else already planning to attend this year? Like previous conferences, you'll be able to find most of us in the #wineconf:matrix.org Matrix room. Henri

2 1

Wine staging 8.0-rc3 release
by Alistair Leslie-Hughes 08 Jan '23

08 Jan '23

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

1 0

HiDPI / Scaling window content
by Jordan Johnston 06 Jan '23

06 Jan '23

Hey all, I'm looking for some pointers on coming up with a hack to better support HiDPI with wine on my hi-res display (not something that would be submitted upstream. "hack" indeed)... As you are all probably aware; while you can adjust DPI in Winecfg, that only affects Windows UI elements ~ but It does not help with anything outside of that... I have some apps that are basically unusable with HiDPI and i've tried multiple solutions, to no avail. (and setting my resolution to 1440x900 isn't a viable solution either). I've been poking around dlls/winex11.drv and I'm wondering if anyone might have pointers on how some of the scale related stuff works? -- I'm wondering if it may be possible to hack the x11 code to multiply the scale of the window contents? (and perhaps, I can then wrap it in an env variable for use)... If anyone has any pointers, or if they think something like this could work -- I'd appreciate your insights (again, I'm just looking for kind of a one-off hack, not something upstream-able.. I'm sure HiDPI compatibility-mode will land upstream, at some point (Windows has this)). While I am familiar with some of Wine's internals - the graphics stack, window management / x11 code is somewhat alien to me. Alternatively, i suppose if someone is working on related code and has a git branch / patchwork available, I'd be open to try that out too. Thanks, and Happy New Year to you all! Jordan

4 7

CPython fails to import symlinked packages in recent versions of Wine Staging - how to debug?
by Sebastian M. Ernst 28 Dec '22

28 Dec '22

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

2 2

Wine staging 8.0-rc2 release
by Alistair Leslie-Hughes 23 Dec '22

23 Dec '22

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.

1 0

UIRibbon 2022 Edition
by Fabian Maurer 18 Dec '22

18 Dec '22

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

1 0

Re: How to delete a git branch that's not been merged?
by Gerald Pfeifer 17 Dec '22

17 Dec '22

On Tue, 13 Dec 2022, Gerald Pfeifer wrote: > https://wiki.winehq.org/Git_Wine_Tutorial#Deleting_branches has > > Deleting branches > > git branch -D new-branch > > Alas that does not work for me. > > % git branch -a > * master > remotes/origin/HEAD -> origin/master > remotes/origin/dll_soinit.c-stddef.h : > > % git branch -D dll_soinit.c-stddef.h > error: branch 'dll_soinit.c-stddef.h' not found. I believe I can now answer my own question, having dug into it a bit. The invocation above is for *local* branches, branches in the local checkout. To remove a *remote* branch, for example where a merge request was not accepted or was "bad" for some reason, we need to use `git push` instead of `git branch`: % git push origin --delete dll_soinit.c-stddef.h I plan on adding this to the Wiki in a few days. Any suggestions/concerns? Gerald

2 1

git pull --rebase upstream ?
by Gerald Pfeifer 16 Dec '22

16 Dec '22

These days I find myself spending more time wrestling with Git/Gitlab than it takes me to create and test a patch. So I am keenly interested to help improve https://wiki.winehq.org/Git_Wine_Tutorial#Creating_a_fork_on_Gitlab :-) Here is the first item: I ran # git clone git@gitlab.winehq.org:gerald/wine.git # git remote add upstream https://gitlab.winehq.org/wine/wine.git followed by # git pull --rebase upstream following https://wiki.winehq.org/Git_Wine_Tutorial#Creating_a_fork_on_Gitlab And there is where the instructions fail as follows: # git pull --rebase upstream From https://gitlab.winehq.org/wine/wine * [new branch] master -> upstream/master * [new branch] oldstable -> upstream/oldstable * [new branch] stable -> upstream/stable You asked to pull from the remote 'upstream', but did not specify a branch. Because this is not the default configured remote for your current branch, you must specify a branch on the command line. It appears the invocation should be shown as # git pull --rebase upstream master instead? Gerald PS: I'd volunteer to update the Wiki accordingly if confirmed, alas my wiki.winehq.org account (GeraldPfeifer) does not appear to exist any longer? And creating a new one is not possible?

2 2

Wayland driver - December 2022 update
by Alexandros Frantzis 16 Dec '22

16 Dec '22

Hi everyone! It's been some time since our last Wayland driver update ([1]), and, with the year coming to an end, I wanted to share information about the progress we made this year and discuss future steps. The focus in 2022 was on maturing the Wayland driver and keeping up to date with the Wine upstream internal changes. This involved, among other things, splitting the driver into a PE and Unix part, updating it for the latest internal driver APIs, and making preparations to support WoW64 (we are not there yet, but we are close). A significant improvement compared to last year is support for cross-process rendering, which is required by Chromium/CEF applications. Last year the driver was able to run Chrome with the "--in-process" command-line option. This year Chrome is supported without any special flags, fully GPU accelerated on both OpenGL and Vulkan! This was achieved by implementing what is effectively an internal off-screen swapchain in the driver's OpenGL and Vulkan integration code, along with a mechanism to send buffers to other processes for presentation when needed. This update also brings enhanced support for the linux-dmabuf v4 Wayland protocol (aka dmabuf-feedback), which allows compositors to dynamically send information about optimal formats and modifiers, e.g., depending on the surface presentation mode (fullscreen vs windowed). Our new internal OpenGL swapchain can handle such feedback directly, while for Vulkan we rely on the Wayland WSI to provide this functionality. This year we also made a lot of smaller scale fixes and enhancements, that in aggregate have greatly improved driver stability. These were a result of both testing we performed ourselves, and also of reports from people trying out the Wayland driver, for which we are very grateful. All the features listed in our previous update (multi-monitor, display mode changes, copy-paste, keymaps, relative mouse etc) have been further refined. One issue for which we haven't yet found a reasonable solution, is how to properly position the context/right-click menu in the standalone systray. The Wayland driver uses the Wayland protocol in a manner that, although in spec, exercises less well-trodden paths in compositor code. Throughout the year we have come across a few issues with compositors, which we have been working with upstreams to address. One issue that people should be aware of, in particular, manifests as improper relative mouse motion in first-person 3D games when using the Wayland driver with some compositors (e.g., see [2]). TL;DR of how to use the development branch: $ git clone -b wayland https://gitlab.collabora.com/alf/wine/ $ cd wine $ ./configure --with-wayland [--with-vulkan] $ make [-jN] $ DISPLAY= WAYLAND_DISPLAY=wayland-0 ./wine ... Especially note the use of 'DISPLAY=', which we use to opt in to the Wayland driver by disabling the higher priority X11 driver. Here is a video showing the latest version of the Wayland driver in action (note that in this video I am using Mutter from git main that includes the fix for the relative motion issues mentioned above): https://www.youtube.com/watch?v=lZ-MK72Kyp8 --- Next steps: Last year, due to the extensive ongoing internal rework in Wine (e.g., win32u), the decision was made to postpone the upstreaming of the Wayland driver until some amount of internal stability had been reached. My impression is that things are a lot more stable now, from the drivers' point of view at least. Is there any upcoming work that people feel would be severely hindered by the upstreaming of the Wayland driver? Ideally, I would like to start the upstreaming effort (which I expect will take some time) at some point early next year, after the codebase has been unfrozen. Does this sound reasonable? Thanks, Alexandros [1] https://www.winehq.org/pipermail/wine-devel/2021-December/203035.html [2] https://gitlab.gnome.org/GNOME/mutter/-/issues/2223

2 2

Why is vkd3d an extra projekt?
by Fabian Maurer 13 Dec '22

13 Dec '22

Hello, For a while now I'm curious, so I have to ask: Why is vkd3d an extra project? Is that because it is reusable as standalone library? Just curious, because it's the only library in Wine that is a separate project. Wouldn't it have made sense to develop it as part of Wine to reuse the wine infrastructure and always have the most recent code for dx12/shaders? Regards, Fabian Maurer

3 2

What does the "Override" button do in joy.cpl?
by Alex Henrie 13 Dec '22

13 Dec '22

While looking at the new messages to translate for Wine 8.0, I noticed several like this: "No user detected on slot #0, make sure your gamepad is plugged in, and not overriden for DInput in the Joysticks tab." Leaving aside the misspelling of "overridden" in English, I want to make sure that I translate this text intelligibly into Catalan. I assume that the message is related to the "Override" button in joy.cpl. What exactly does that button do? -Alex

2 2

← Newer
1
...
8
9
10
11
12
13
14
...
3379
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel