wine-devel October 2024

wine-devel@winehq.org

14 participants
15 discussions

Trouble compiling Winelib DLL for 64-bit on OpenSUSE
by aleithner＠level101.at 18 Oct '24

18 Oct '24

Hi, I have previously asked about the problem I'm describing below on openSUSE's forums [1], StackOverflow [2] and Wine's forums [3], where dimesio told me that I could try to ask here. If this is the wrong place to ask, I apologise. Over the past few weeks, I've been re-implementing a DLL using Winelib to be able to leverage Unix sockets to communicate with a Linux process outside of Wine. For context, I'm on a 64-bit machine running openSUSE Tumbleweed. I've had success compiling the DLL as a 32-bit object using the command line winegcc -m32 -L/usr/lib64/wine/i386-unix -shared -o myproject.dll myproject_main.c myproject.spec This DLL (myproject.dll.so) works as expected, i.e. 32-bit Windows programs running under Wine can load and execute the DLL just fine. (I've found specifying -L/usr/lib64/wine/i386-unix to be necessary since WineGCC didn't pick up Wine's library path by itself.) Now, I've been trying to compile this same project as a 64-bit object using winegcc -L/usr/lib64/wine/x86_64-unix -shared -o myproject64.dll myproject_main.c myproject.spec and I'm facing the following WineGCC output: /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -ladvapi32: No such file or directory /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -luser32: No such file or directory /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -lwinecrt0: No such file or directory /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -lkernel32: No such file or directory /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -lntdll: No such file or directory collect2: error: ld returned 1 exit status winegcc: /usr/bin/gcc failed As I've discovered, openSUSE's wine-devel package does not provide any archive files in /usr/lib64/wine/x86_64-unix, whereas wine-devel-32bit does provide archive files under /usr/lib/wine/i386-unix (symlinked with the same directory in /usr/lib64). Interestingly, I've inspected Wine's Fedora packages [4] and haven't found these archive files for 32-bit but only for 64-bit; so, the Fedora packages seem to have the opposite "problem." Now, I've tried to use the archive files provided by openSUSE's 64-bit wine-devel package under /usr/lib64/wine/x86_64-windows, but of course they're PE binaries so LD complains it can't link to my Winelib DLL: /usr/bin/ld: relocatable linking with relocations from format pe-x86-64 (/usr/lib64/wine/x86_64-windows/libwinecrt0.a(debug.o)) to format elf64-x86-64 (tmp66fd686a/myproject64-00000001.spec-00000001.o) is not supported winebuild: /usr/bin/ld failed with status 1 winegcc: /usr/bin/winebuild failed I feel like I should be able to compile this Winelib DLL as both a 32-bit and a 64-bit object respectively, on any supported system. (I haven't found any info on this skimming through the Winelib User's Guide [5].) Is this assumption wrong? If so, what's the correct way of building Winelib DLLs? If not, how can I get a 64-bit version of this DLL? Any advice on what I might be misunderstanding or doing wrong or what might be the cause of this problem would be greatly appreciated. Best regards, Alexander Leithner [1]: https://forums.opensuse.org/t/wines-64-bit-archive-files-are-missing/179038 [2]: https://stackoverflow.com/questions/79058718/whats-the-correct-way-of-build… [3]: https://forum.winehq.org/viewtopic.php?t=39513 [4]: e.g. https://dl.winehq.org/wine-builds/fedora/40/x86_64/wine-staging-9.19-1.1.x8… under /opt/wine-staging/lib64/wine inside the package [5]: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-Guide

6 5

Discussing paths forward for OpenGL mappings on Wow64
by Derek Lesho 15 Oct '24

15 Oct '24

Hi everyone, I'm creating this thread to start a discussion about how we want to complete GL support on Wow64, in the hopes that, if we want a MESA extension for this, we can get it to them sooner rather than later. The core of the problem is same that we faced for Vulkan: namely that host visible mappings from graphics APIs may be located above 32-bit memory, in which case we can't pass them to the application as is. In the current implementation that Rémi wrote a few years ago, we use a temporary buffer for glMapBuffer, and manually have to copy the data from it back to the real mapping on glUnmapBuffer. This solution works for most applications, but is slower than direct writes, and doesn't allow use of the GL_MAP_PERSISTENT_BIT glMapBuffer flag, where the application doesn't have to unmap the memory before usage by the API. Because of this problem, we can't support GL versions >= 4.4 in this path, which admittedly isn't a huge problem considering wined3d now supports Vulkan, but does rule out some native GL apps/games from running on the new path. I'll go over a few potential solutions: - "Just Use Zink": this idea has been floated for a while, and would be to use a PE build of Zink, the MESA gallium driver on top of Vulkan, which would then automatically make use of our VK_EXT_map_memory_placed integration in winevulkan and bypass the problem. Rémi has a branch with a draft solution for this [1] The advantage of approach is that it doesn't require any more extensions to any more APIs, but the disadvantage is that Wine would have to worry about keeping a separate version of Mesa up to date and support for building the required c++ components of mesa to its build system, as can be seen in the commits. - GL extension with placed memory allocation callback: In this case, Wine provides a map and unmap callback for the GL implementation to use in creating the pages it needs for GPU-mappings. In comparison to the PE Zink solution, we can continue to use system libraries, and maintain fast buffer IO, as long as the glMapBuffer implementation returns the mapped ptr directly. The main downside for this solution is of course the introduction of a new extension to the mostly dormant GL API, but here it would be possible to just use a VK_EXT_map_memory leveraging Zink like in the first solution, only this time on the Unix side. For this solution I've created a draft: Wine MR [2] Mesa Branch with Zink implementation [3] - glMapBuffer extension which we send our placed allocation: The idea here is that slightly extended glMapBuffer could be sent a flag to use Wine mapping, avoiding callbacks and targeting the problem where it manifests for Wine (when we get an address out of 32-bit space). This was briefly discussed on the LGD discord server, but it won't work well, due to the fact that a GL buffer is usually only a suballocation of a memory mapping, and often has already been assigned to another pool of memory by the time glMapMemory is called. Mesa would have to add a considerable sized implementation setting up custom-allocator pools, and be able to move buffers between them to implement this. - glBufferStorage extension to ease Mesa implementation: The next logical conclusion based on the problems of the last solution is that the Mesa implementation should get the information about any custom allocation at buffer creation time. The closest equivalent to this is the glBufferStorage entry, where we could create a new type of memory that we would ask the implementation to put the buffer in. For this solution we'd either have to implement custom memory allocator or introduce more API entries in order to allow the driver to convey to the application what size mappings it prefers. This would be very unwieldy, and wouldn't solve speed up the slow buffer copies for legacy buffers which don't use ARB_buffer_storage. - finally, going off the last possibility, if we're willing to create our own buffer allocator (we probably shouldn't, as the driver probably knows best), we could use the already existing EXT_external_objects extensions to import Vulkan memory objects, from which our allocator would allocate slices for the buffers. In glMapBuffer we would then return the Vulkan placed memory mapping. If I got anything wrong or overlooked anything, please let me know. If we decide on a solution that involves mesa, I would gladly then include the mesa-dev list to see if they have opinions for/against any of the proposals. Thanks, Derek 1: https://gitlab.winehq.org/rbernon/wine/-/tree/wip/just-use-zink 2: https://gitlab.winehq.org/wine/wine/-/merge_requests/6663 3: https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation

5 7

wined3d surface handle buffer overflow
by Fabian Maurer 11 Oct '24

11 Oct '24

Hello, I'm currently investigating a wined3d regression that leads to an assert - bug 57300. In short, there is memorys corruption in "d3d_device2_SwapTextureHandles" when copying a "global handle table" handle into the "device handle table". The "device handle table" is only 64 entries long, but the handle is bigger than that - writing out of bounds. As I see, it all surfaces get allocated into the global handle table. Then in d3d_device2_SwapTextureHandles they get copied into the device handle table. Once in "CreateStateBlock" and once in "EndStateBlock". The device handle table only contains the wined3d state block handle. If those assumptions are correct, I have a few questions: 1) Isn't there a risk of overriding the state block handle when swapping the texture with handle 1? 2) Why are the handles only copied, completely bypassing the ddraw_allocate_handle function? Doesn't this mess up the next call to "ddraw_allocate_handle"? A potential solution to the buffer overflow would be the increase the size of the table if the handle doesn't fit. But I don't know if that's the correct course of action, and I don't know what to do with the table size / count values. Or maybe there' something else wrong here that I'm not seeing, insights would be appreciated. Regards, Fabian Maurer

2 1

Upcoming vkd3d 1.14 release
by Henri Verbeet 10 Oct '24

10 Oct '24

Hi all, As previously announced, the planned release date for vkd3d 1.14 is November 21. That means the public API will become frozen two weeks from now on October 24, and features will be frozen after November 7. As usual, if you're an upstream vkd3d developer, please do the following: - Keep an eye on Bugzilla for any reported regressions. - Review any API changes since the previous release. - Verify all vkd3d tests pass on your hardware/setup, and please send fixes if they don't. - Review and improve the documentation. - Apply your best judgment about which patches are appropriate for the current stage of the release process. If you're a downstream user of vkd3d, please test your applications for any regressions, and file bug reports if you find any. The planned release date for vkd3d 1.15 is February 19. Regards, Henri

1 0

Wine staging 9.19 release
by Alistair Leslie-Hughes 05 Oct '24

05 Oct '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.19 (354 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * d3dx9_36: Add format description for X8L8V8U8 for format conversions. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest 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

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 October 2024