wine-devel

wine-devel@winehq.org

4 participants
84401 discussions

Re: [PATCH v2 0/5] MR71: ntdll: Simplify heap validation functions. - approved
by Alexandre Julliard (＠julliard) 16 May '22

16 May '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/71

1 0

Re: [PATCH v3 0/1] MR70: msvcrt: Hook up __C_specific_handler and __jump_unwind for arm - approved
by Alexandre Julliard (＠julliard) 16 May '22

16 May '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/70

1 0

Re: [PATCH v2 0/2] MR72: win32u: Handle sys color brushes in fill_rect. - approved
by Alexandre Julliard (＠julliard) 16 May '22

16 May '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/72

1 0

Re: [PATCH v2 0/4] MR32: ntdll: Collect logical processor info just once at process start. - approved
by Alexandre Julliard (＠julliard) 16 May '22

16 May '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/32

1 0

Re: [PATCH v4 0/6] MR62: windows.gaming.input: More force feedback implementation. - approved
by Alexandre Julliard (＠julliard) 16 May '22

16 May '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/62

1 0

Re: [PATCH v2 0/1] MR67: shell32/tests: Use 'shellpath' as tmpfile name in PathResolve tests - approved
by Alexandre Julliard (＠julliard) 16 May '22

16 May '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/67

1 0

Re: [PATCH v5 0/5] MR34: windows.media.speech: Changes for IAsyncAction. - approved
by Alexandre Julliard (＠julliard) 16 May '22

16 May '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/34

1 0

Would implementing UMDF support be useful (or even viable)?
by Mark N 16 May '22

16 May '22

Hello, I was reading about the Windows User Mode Device Framework (aka UMDF) and I was interested in possibly working on adding support for UMDF drivers in Wine. I think there are Windows drivers out there that run entirely in usermode (e.g. some USB drivers) which could be successfully ported to Linux this way. However I'm still new to Wine so I thought I'd ask - has anybody else ever explored doing this? Would this sort of thing be a good fit for Wine in general? Thanks! Mark N

4 4

[PATCH v2 0/3] MR69: include: Add __WINE_MALLOC attribute and use it for allocation functions.
by Brendan Shanks (＠bshanks) 16 May '22

16 May '22

With this patch, lib/wine/x86_64-windows/ ends up 100 KB smaller, and I would expect performance benefits too. >From https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-ma…: Attribute malloc indicates that a function is malloc-like, i.e., that the pointer P returned by the function cannot alias any other pointer valid when the function returns, and moreover no pointers to valid objects occur in any storage addressed by P. In addition, the GCC predicts that a function with the attribute returns non-null in most cases. Using the attribute with no arguments is designed to improve optimization by relying on the aliasing property it implies. Functions like malloc and calloc have this property because they return a pointer to uninitialized or zeroed-out, newly obtained storage. However, functions like realloc do not have this property, as they may return pointers to storage containing pointers to existing objects. Additionally, since all such functions are assumed to return null only infrequently, callers can be optimized based on that assumption. -- v2: crypt32/tests: Fix mismatched deallocation function. include: Add __WINE_DEALLOC attribute and use it for allocation functions. include: Add __WINE_MALLOC attribute and use it for allocation functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/69

2 4

32bit Wine on macOS Catalina
by Eddie Hillenbrand 16 May '22

16 May '22

Hi all, Reading everything I can find about Wine on macOS, seems like there still isn't a good solution for 32bit on Catalina and beyond.[1] I'm currently running Catalina and don't intend to upgrade my Mac or the OS anytime soon. My goal is to compile everything on Catalina and to run 32bit Wine on Catalina. I can compile 64bit Wine without a problem and 32bit Wine compiles against the MacOSX10.13.sdk. I can run 32bit Wine with the `no32exec=0' boot argument and DYLD_ROOT_PATH pointing at a directory containing `/System' & `/usr/lib' from a machine running 10.13. It crashes because of kernel changes that are incompatible with libraries from High Sierra. Specifically, (10.15) libdispatch redefined work queue priorities, so the (10.15) kernel starts the work queue thread with an invalid priority as understood by (10.13) libdispatch. Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Illegal instruction: 4 Termination Reason: Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [22976] Application Specific Information: dyld2 mode BUG IN CLIENT OF LIBDISPATCH: Corrupted priority [...] Thread 1 Crashed: 0 libdispatch.dylib 0x0643aef5 _dispatch_worker_thread3 + 180 1 libsystem_pthread.dylib 0x068c3fa5 _pthread_wqthread + 1356 2 libsystem_pthread.dylib 0x068c3a32 start_wqthread + 34 Initially, I thought using DYLD_ROOT_PATH with 10.13 system directories was the way to go. So I modified libdispatch to use the new priority definitions and replaced `/usr/lib/system/libdispatch.dylib' in the DYLD_ROOT_PATH with my modified version. This got past the work queue crash, but a few other crashes emerged that needed to be squashed in libdispatch, eventually I made it to NSApplication initialization. Unfortunately, the application initialization crashes when it tries to initialize the user defaults subsystem. I was hoping I would only have to solve a few crashes in some of the open source libraries. Of course this wasn't the case. Since I had made it past the initial app bootstrapping and into ObjC frameworks I was no longer in open source code. I could have kept playing Whac-A-Mole, as it is especially easy to monkey patch ObjC code with method swizzling. I considered going down this path, but before going there, I decided to try a DYLD_ROOT_PATH with system directories from 10.14. I'm glad I tried using 10.14 dylibs before sinking more time into patching and hacking my way through 10.13 dylibs. The 10.14 dylibs don't crash, instead the WindowServer refuses to allow a connection from a 32bit process. _RegisterApplication(), FAILED TO REGISTER PROCESS WITH CPS/CoreGraphics in WindowServer, err=-304 I suspected this might be an AppKit limitation so I tried using the deprecated Carbon libs and got the same error. Then I tried using private WindowServer APIs directly, which didn't error in the same way, but also didn't draw anything.[2] Compiling the same code for 64bit, however, draws as expected. A way forward for 32bit Wine is possible. Just do drawing in a 64bit process. It might sound like a hack, but drawing or interacting with the WindowServer is already done using IPC—it is just transparent to the developer. I already made a proof of concept, so I know the technique is solid. Additionally, on Catalina at least, this removes the need for the DYLD_ROOT_PATH since the 32bit process would, in theory, only need to link with libSystem and it ships with 32bit binaries. $ sw_vers -productVersion 10.15.7 $ lipo -info /usr/lib/libSystem.dylib Architectures in the fat file: /usr/lib/libSystem.dylib are: x86_64 i386 And by extension, most everything in the umbrella framework `/usr/lib/system/*' also contains 32bit binaries. My intention is to put the winemac.drv in its own 64bit process. I don't really have a question, this is more a statement of intent, but I'd welcome any feedback, thoughts, or concerns. If nothing else this email memorializes the things someone is likely to encounter if they try to make 32bit Wine run on Catalina or anyone that tries to run any 32bit app on Catalina. Eddie [1] I'm aware of CrossOver, etc. [2] I did eventually get one of the private functions to return -304 which is probably significant as it matches the _RegisterApplication() error.

6 8

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