January 2024 - Wine-Devel - list.winehq.org

[RFC PATCH 3/9] ntsync: Introduce NTSYNC_IOC_CREATE_SEM and NTSYNC_IOC_DELETE.

by Elizabeth Figura

These correspond to the NT syscalls NtCreateSemaphore() and NtClose(). Unlike those functions, however, these ioctls do not handle object names, or lookup of existing objects, or handle reference counting, but simply create the underlying primitive. The user space emulator is expected to implement those functions if they are required. Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- drivers/misc/ntsync.c | 117 ++++++++++++++++++++++++++++++++++++ include/uapi/linux/ntsync.h | 25 ++++++++ 2 files changed, 142 insertions(+) create mode 100644 include/uapi/linux/ntsync.h diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c index 84b498e2b2d5..3287b94be351 100644 --- a/drivers/misc/ntsync.c +++ b/drivers/misc/ntsync.c @@ -8,23 +8,140 @@ #include <linux/fs.h> #include <linux/miscdevice.h> #include <linux/module.h> +#include <linux/slab.h> +#include <linux/xarray.h> +#include <uapi/linux/ntsync.h> #define NTSYNC_NAME "ntsync" +enum ntsync_type { + NTSYNC_TYPE_SEM, +}; + +struct ntsync_obj { + struct rcu_head rhead; + struct kref refcount; + + enum ntsync_type type; + + union { + struct { + __u32 count; + __u32 max; + } sem; + } u; +}; + +struct ntsync_device { + struct xarray objects; +}; + +static void destroy_obj(struct kref *ref) +{ + struct ntsync_obj *obj = container_of(ref, struct ntsync_obj, refcount); + + kfree_rcu(obj, rhead); +} + +static void put_obj(struct ntsync_obj *obj) +{ + kref_put(&obj->refcount, destroy_obj); +} + static int ntsync_char_open(struct inode *inode, struct file *file) { + struct ntsync_device *dev; + + dev = kzalloc(sizeof(*dev), GFP_KERNEL); + if (!dev) + return -ENOMEM; + + xa_init_flags(&dev->objects, XA_FLAGS_ALLOC); + + file->private_data = dev; return nonseekable_open(inode, file); } static int ntsync_char_release(struct inode *inode, struct file *file) { + struct ntsync_device *dev = file->private_data; + struct ntsync_obj *obj; + unsigned long id; + + xa_for_each(&dev->objects, id, obj) + put_obj(obj); + + xa_destroy(&dev->objects); + + kfree(dev); + + return 0; +} + +static void init_obj(struct ntsync_obj *obj) +{ + kref_init(&obj->refcount); +} + +static int ntsync_create_sem(struct ntsync_device *dev, void __user *argp) +{ + struct ntsync_sem_args __user *user_args = argp; + struct ntsync_sem_args args; + struct ntsync_obj *sem; + __u32 id; + int ret; + + if (copy_from_user(&args, argp, sizeof(args))) + return -EFAULT; + + if (args.count > args.max) + return -EINVAL; + + sem = kzalloc(sizeof(*sem), GFP_KERNEL); + if (!sem) + return -ENOMEM; + + init_obj(sem); + sem->type = NTSYNC_TYPE_SEM; + sem->u.sem.count = args.count; + sem->u.sem.max = args.max; + + ret = xa_alloc(&dev->objects, &id, sem, xa_limit_32b, GFP_KERNEL); + if (ret < 0) { + kfree(sem); + return ret; + } + + return put_user(id, &user_args->sem); +} + +static int ntsync_delete(struct ntsync_device *dev, void __user *argp) +{ + struct ntsync_obj *obj; + __u32 id; + + if (get_user(id, (__u32 __user *)argp)) + return -EFAULT; + + obj = xa_erase(&dev->objects, id); + if (!obj) + return -EINVAL; + + put_obj(obj); return 0; } static long ntsync_char_ioctl(struct file *file, unsigned int cmd, unsigned long parm) { + struct ntsync_device *dev = file->private_data; + void __user *argp = (void __user *)parm; + switch (cmd) { + case NTSYNC_IOC_CREATE_SEM: + return ntsync_create_sem(dev, argp); + case NTSYNC_IOC_DELETE: + return ntsync_delete(dev, argp); default: return -ENOIOCTLCMD; } diff --git a/include/uapi/linux/ntsync.h b/include/uapi/linux/ntsync.h new file mode 100644 index 000000000000..d97afc138dcc --- /dev/null +++ b/include/uapi/linux/ntsync.h @@ -0,0 +1,25 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +/* + * Kernel support for NT synchronization primitive emulation + * + * Copyright (C) 2021-2022 Elizabeth Figura + */ + +#ifndef __LINUX_NTSYNC_H +#define __LINUX_NTSYNC_H + +#include <linux/types.h> + +struct ntsync_sem_args { + __u32 sem; + __u32 count; + __u32 max; +}; + +#define NTSYNC_IOC_BASE 0xf7 + +#define NTSYNC_IOC_CREATE_SEM _IOWR(NTSYNC_IOC_BASE, 0, \ + struct ntsync_sem_args) +#define NTSYNC_IOC_DELETE _IOW (NTSYNC_IOC_BASE, 1, __u32) + +#endif -- 2.43.0

Jan. 24, 2024

[RFC PATCH 2/9] ntsync: Reserve a minor device number and ioctl range.

by Elizabeth Figura

Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- Documentation/admin-guide/devices.txt | 3 ++- Documentation/userspace-api/ioctl/ioctl-number.rst | 2 ++ drivers/misc/ntsync.c | 3 ++- include/linux/miscdevice.h | 1 + 4 files changed, 7 insertions(+), 2 deletions(-) diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt index 94c98be1329a..041404397ee5 100644 --- a/Documentation/admin-guide/devices.txt +++ b/Documentation/admin-guide/devices.txt @@ -376,8 +376,9 @@ 240 = /dev/userio Serio driver testing device 241 = /dev/vhost-vsock Host kernel driver for virtio vsock 242 = /dev/rfkill Turning off radio transmissions (rfkill) + 243 = /dev/ntsync NT synchronization primitive device - 243-254 Reserved for local use + 244-254 Reserved for local use 255 Reserved for MISC_DYNAMIC_MINOR 11 char Raw keyboard device (Linux/SPARC only) diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 457e16f06e04..a1326a5bc2e0 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -378,6 +378,8 @@ Code Seq# Include File Comments <mailto:thomas(a)winischhofer.net> 0xF6 all LTTng Linux Trace Toolkit Next Generation <mailto:mathieu.desnoyers(a)efficios.com> +0xF7 00-1F uapi/linux/ntsync.h NT synchronization primitives + <mailto:wine-devel(a)winehq.org> 0xF8 all arch/x86/include/uapi/asm/amd_hsmp.h AMD HSMP EPYC system management interface driver <mailto:nchatrad(a)amd.com> 0xFD all linux/dm-ioctl.h diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c index 9424c6210e51..84b498e2b2d5 100644 --- a/drivers/misc/ntsync.c +++ b/drivers/misc/ntsync.c @@ -40,7 +40,7 @@ static const struct file_operations ntsync_fops = { }; static struct miscdevice ntsync_misc = { - .minor = MISC_DYNAMIC_MINOR, + .minor = NTSYNC_MINOR, .name = NTSYNC_NAME, .fops = &ntsync_fops, }; @@ -51,3 +51,4 @@ MODULE_AUTHOR("Elizabeth Figura"); MODULE_DESCRIPTION("Kernel driver for NT synchronization primitives"); MODULE_LICENSE("GPL"); MODULE_ALIAS("devname:" NTSYNC_NAME); +MODULE_ALIAS_MISCDEV(NTSYNC_MINOR); diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h index c0fea6ca5076..fe5d9366fdf7 100644 --- a/include/linux/miscdevice.h +++ b/include/linux/miscdevice.h @@ -71,6 +71,7 @@ #define USERIO_MINOR 240 #define VHOST_VSOCK_MINOR 241 #define RFKILL_MINOR 242 +#define NTSYNC_MINOR 243 #define MISC_DYNAMIC_MINOR 255 struct device; -- 2.43.0

Jan. 24, 2024

[RFC PATCH 1/9] ntsync: Introduce the ntsync driver and character device.

by Elizabeth Figura

ntsync uses a misc device as the simplest and least intrusive uAPI interface. Each file description on the device represents an isolated NT instance, intended to correspond to a single NT virtual machine. Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- drivers/misc/Kconfig | 9 ++++++++ drivers/misc/Makefile | 1 + drivers/misc/ntsync.c | 53 +++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 63 insertions(+) create mode 100644 drivers/misc/ntsync.c diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 4fb291f0bf7c..bdd8a71bd853 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -504,6 +504,15 @@ config OPEN_DICE measured boot flow. Userspace can use CDIs for remote attestation and sealing. +config NTSYNC + tristate "NT synchronization primitive emulation" + help + This module provides kernel support for emulation of Windows NT + synchronization primitives. It is not a hardware driver. + + To compile this driver as a module, choose M here: the + module will be called ntsync. + If unsure, say N. config VCPU_STALL_DETECTOR diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index ea6ea5bbbc9c..153a3f4837e8 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -59,6 +59,7 @@ obj-$(CONFIG_PVPANIC) += pvpanic/ obj-$(CONFIG_UACCE) += uacce/ obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o obj-$(CONFIG_HISI_HIKEY_USB) += hisi_hikey_usb.o +obj-$(CONFIG_NTSYNC) += ntsync.o obj-$(CONFIG_HI6421V600_IRQ) += hi6421v600-irq.o obj-$(CONFIG_OPEN_DICE) += open-dice.o obj-$(CONFIG_GP_PCI1XXXX) += mchp_pci1xxxx/ diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c new file mode 100644 index 000000000000..9424c6210e51 --- /dev/null +++ b/drivers/misc/ntsync.c @@ -0,0 +1,53 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * ntsync.c - Kernel driver for NT synchronization primitives + * + * Copyright (C) 2021-2022 Elizabeth Figura + */ + +#include <linux/fs.h> +#include <linux/miscdevice.h> +#include <linux/module.h> + +#define NTSYNC_NAME "ntsync" + +static int ntsync_char_open(struct inode *inode, struct file *file) +{ + return nonseekable_open(inode, file); +} + +static int ntsync_char_release(struct inode *inode, struct file *file) +{ + return 0; +} + +static long ntsync_char_ioctl(struct file *file, unsigned int cmd, + unsigned long parm) +{ + switch (cmd) { + default: + return -ENOIOCTLCMD; + } +} + +static const struct file_operations ntsync_fops = { + .owner = THIS_MODULE, + .open = ntsync_char_open, + .release = ntsync_char_release, + .unlocked_ioctl = ntsync_char_ioctl, + .compat_ioctl = ntsync_char_ioctl, + .llseek = no_llseek, +}; + +static struct miscdevice ntsync_misc = { + .minor = MISC_DYNAMIC_MINOR, + .name = NTSYNC_NAME, + .fops = &ntsync_fops, +}; + +module_misc_device(ntsync_misc); + +MODULE_AUTHOR("Elizabeth Figura"); +MODULE_DESCRIPTION("Kernel driver for NT synchronization primitives"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("devname:" NTSYNC_NAME); -- 2.43.0

Jan. 24, 2024

[RFC PATCH 0/9] NT synchronization primitive driver

by Elizabeth Figura

This patch series introduces a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuills, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == This is the first part of a 32-patch series. The series comprises 17 patches which contain the actual implementation, 13 which provide self-tests, 1 to update the MAINTAINERS file, and 1 to add API documentation. The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. Since I do not expect familiarity with Windows syscalls, however, and especially not with some of the more subtle or unspecified behaviour that they provide, the documentation patch included in the series also describes the intended behaviour in detail, and can be used as a specification for the rest of the series. The entire series can be retrieved or browsed here: https://repo.or.cz/linux/zf.git/shortlog/refs/heads/ntsync4 The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync4 == Implementation == Some aspects of the implementation may deserve particular comment: * In the interest of performance, each object is governed only by a single spinlock. However, NTSYNC_IOC_WAIT_ALL requires that the state of multiple objects be changed as a single atomic operation. In order to achieve this, we first take a device-wide lock ("wait_all_lock") any time we are going to lock more than one object at a time. The maximum number of objects that can be used in a vectored wait, and therefore the maximum that can be locked simultaneously, is 64. This number is NT's own limit. The acquisition of multiple spinlocks will degrade performance. This is a conscious choice, however. Wait-for-all is known to be a very rare operation in practice, especially with counts that approach the maximum, and it is the intent of the ntsync driver to optimize the wait-for-any pattern at the expense of the wait-for-all pattern as much as possible. * NT mutexes are tied to their threads on an OS level, and the kernel includes builtin support for "robust" mutexes. In order to keep the ntsync driver self-contained and avoid touching more code than necessary, it does not hook into task exit nor use pids. Instead, the user space emulator is expected to manage thread IDs and pass them as an argument to any relevant functions; this is the "owner" field of ntsync_wait_args and ntsync_mutex_args. When the emulator detects that a thread dies, it should therefore call NTSYNC_IOC_KILL_OWNER, which will mark mutexes owned by that thread (if any) as abandoned. * This implementation uses a misc device mostly because it seemed like the simplest and least obtrusive option. Besides simplicitly of implementation, the only particularly interesting advantage is the ability to create an arbitrary number of "contexts" (corresponding to Windows virtual machines) which are self-contained and shareable across multiple processes; this maps nicely to file descriptions (i.e. struct file). This is not impossible with syscalls of course but would require an extra argument. On the other hand, there is no reason to forbid using ntsync by default from user-mode processes, and (as far as I understand) to do so with a char device requires explicit configuration by e.g. udev or init. Since this is done with e.g. fuse, I assume this is the model to follow, but I may have chosen something deprecated. * ntsync is module-capable mostly because there was nothing preventing it, and because it aided development. I am not aware of any reason why being a module is required, though. * The misc minor number has not been reserved with LANANA. I am not sure at what point in the process this makes the most sense, but since this is still only an RFC I've abstained from doing so yet. Elizabeth Figura (9): ntsync: Introduce the ntsync driver and character device. ntsync: Reserve a minor device number and ioctl range. ntsync: Introduce NTSYNC_IOC_CREATE_SEM and NTSYNC_IOC_DELETE. ntsync: Introduce NTSYNC_IOC_PUT_SEM. ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_PUT_MUTEX. ntsync: Introduce NTSYNC_IOC_KILL_OWNER. Documentation/admin-guide/devices.txt | 3 +- .../userspace-api/ioctl/ioctl-number.rst | 2 + drivers/misc/Kconfig | 9 + drivers/misc/Makefile | 1 + drivers/misc/ntsync.c | 916 ++++++++++++++++++ include/linux/miscdevice.h | 1 + include/uapi/linux/ntsync.h | 53 + 7 files changed, 984 insertions(+), 1 deletion(-) create mode 100644 drivers/misc/ntsync.c create mode 100644 include/uapi/linux/ntsync.h base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d -- 2.43.0

Jan. 24, 2024

Re: 9.0 release notes, please review

by Alexandre Julliard

Elizabeth Figura <zfigura(a)codeweavers.com> writes: > I do agree that we should wait for real interest before going back and > fixing this case, but at the same time I too fear that this sets a > dangerous precedent. I think it is a serious mistake to deprecate old > wow64 until it offers at *least* the same support, and I also think we > should have communicated its limitations clearly in the release notes, > regardless of how obscure are the affected areas of Wine. There's nothing dangerous about it. Our philosophy has always been to only work on things that users actually need. If there are some limitations that users run into, we'll work on fixing them. If no one runs into them, it means they don't need to be fixed. That's also why we don't wait for a new feature to be perfect before telling users to use it; because we don't need perfection, all we need is for it to address the users' needs. And the only way to know this is to have people use it and tell us what doesn't work for them. -- Alexandre Julliard julliard(a)winehq.org

Jan. 18, 2024

Re: 9.0 release notes, please review

by Esme Povirk

Some Wine Mono highlights, if it's not too late: Builtin assemblies in Wine Mono and those installed in the Windows Global Assembly Cache now take priority over assembly dll's located in the application's directory. Internal assemblies have been renamed to prevent namespace collisions with applications, for example the builtin FNA.dll is now WineMono.FNA.dll. The PresentationFramework.Aero2 and System.Windows.Controls.Ribbon assemblies have been added.

Jan. 18, 2024

Re: 9.0 release notes, please review

by Elizabeth Figura

On Wednesday, 17 January 2024 13:54:02 CST Hans Leidekker wrote: > On Wed, 2024-01-17 at 13:05 -0600, Elizabeth Figura wrote: > > On Wednesday, 17 January 2024 08:57:14 CST Hans Leidekker wrote: > > > On Wed, 2024-01-17 at 16:17 +0200, Gabriel Ivăncescu wrote: > > > > On 17/01/2024 01:31, Francois Gouget wrote: > > > > > On Tue, 16 Jan 2024, Hans Leidekker wrote: > > > > > > > > > > > On Tue, 2024-01-16 at 18:24 +0100, Francois Gouget wrote: > > > > > > > > - Smart cards are supported in the Winscard dll, using the Unix > > > > > > > > PSCSlite library. > > > > > > > > > > > > > > It should probably be noted that this is not supported for 32-bit > > > > > > > Windows applications despite Wine providing a 32-bit winscard.dll. > > > > > > > > > > > > It is supported for 32-bit applications but currently only in the new > > > > > > Wow64 setup. > > > > > > > > > > And since no one will use that mode the release notes should note that > > > > > this is not supported in pure 32-bit Wine and for 32-bit applications > > > > > running in the default old WoW64 mode that every Linux distribution will > > > > > ship. > > > > > > Arch is already offering new-style wow64 packages and macOS users have no > > > choice. > > > > So Arch is shipping Wine packages with crippled 3D support? > > I guess they do. They don't replace the old-style wow64 packages however. > What are our options for fixing this? I looked just now, and Arch's wine package [1] still uses old-style wow64 (look in "Source Files", navigate to PKGBUILD; there's no --enable-arch usage there.) There's no official package that uses new wow64. There is a wine-wow64 AUR package [2] that uses new wow64, but the AUR is basically for unvetted community packages, and Arch doesn't even provide binaries for those. [1] https://archlinux.org/packages/multilib/x86_64/wine/ [2] https://aur.archlinux.org/packages/wine-wow64 > I was curious about 16-bit support and found that Windows has dropped it > recently. One option for Windows users to keep running these apps is a port of > winevdm(!) to 64-bit Windows: > > https://github.com/otya128/winevdm > > I gave it a try on a new wow64 build and to my surprise it worked. I only had > to add native overrides for the 16-bit system dlls. Well, to be pedantic they *completely* dropped support for 16-bit recently (Windows 11, I think?), but it was never supported on 64-bit machines, which is the impetus for winevdm. winevdm works by emulating segmented code. I don't know how that emulation is done or how accurate or performant it is. I would be wary of just depending on it until that's been tested. And in any case Wine doesn't need to drop 16-bit support yet. > > > > Not being use-able in pure 32-bit Wine sounds pretty bad, I hope it > > > > doesn't become a trend. > > > > > > I don't believee there are many users stuck on pure 32-bit Wine that also need > > > winscard support. Note that it was never usable when pure 32-bit Wine was still > > > the norm. Adding support isn't free unfortunately and I don't think that passing > > > the tests is sufficient reason to pay that cost. I'd rather wait and see if > > > there's real interest. > > > > Isn't it unusable in old wow64 as well? > > It is. Then anyone on old wow64 support is going to have to manually compile Wine just to get winscard support in a 32-bit application. I do agree that we should wait for real interest before going back and fixing this case, but at the same time I too fear that this sets a dangerous precedent. I think it is a serious mistake to deprecate old wow64 until it offers at *least* the same support, and I also think we should have communicated its limitations clearly in the release notes, regardless of how obscure are the affected areas of Wine. --Zeb

Jan. 18, 2024

Re: 9.0 release notes, please review

by Hans Leidekker

On Wed, 2024-01-17 at 13:05 -0600, Elizabeth Figura wrote: > On Wednesday, 17 January 2024 08:57:14 CST Hans Leidekker wrote: > > On Wed, 2024-01-17 at 16:17 +0200, Gabriel Ivăncescu wrote: > > > On 17/01/2024 01:31, Francois Gouget wrote: > > > > On Tue, 16 Jan 2024, Hans Leidekker wrote: > > > > > > > > > On Tue, 2024-01-16 at 18:24 +0100, Francois Gouget wrote: > > > > > > > - Smart cards are supported in the Winscard dll, using the Unix > > > > > > > PSCSlite library. > > > > > > > > > > > > It should probably be noted that this is not supported for 32-bit > > > > > > Windows applications despite Wine providing a 32-bit winscard.dll. > > > > > > > > > > It is supported for 32-bit applications but currently only in the new > > > > > Wow64 setup. > > > > > > > > And since no one will use that mode the release notes should note that > > > > this is not supported in pure 32-bit Wine and for 32-bit applications > > > > running in the default old WoW64 mode that every Linux distribution will > > > > ship. > > > > Arch is already offering new-style wow64 packages and macOS users have no > > choice. > > So Arch is shipping Wine packages with crippled 3D support? I guess they do. They don't replace the old-style wow64 packages however. What are our options for fixing this? I was curious about 16-bit support and found that Windows has dropped it recently. One option for Windows users to keep running these apps is a port of winevdm(!) to 64-bit Windows: https://github.com/otya128/winevdm I gave it a try on a new wow64 build and to my surprise it worked. I only had to add native overrides for the 16-bit system dlls. > > > Not being use-able in pure 32-bit Wine sounds pretty bad, I hope it > > > doesn't become a trend. > > > > I don't believee there are many users stuck on pure 32-bit Wine that also need > > winscard support. Note that it was never usable when pure 32-bit Wine was still > > the norm. Adding support isn't free unfortunately and I don't think that passing > > the tests is sufficient reason to pay that cost. I'd rather wait and see if > > there's real interest. > > Isn't it unusable in old wow64 as well? It is.

Jan. 17, 2024

Re: 9.0 release notes, please review

by DodoGTA GT

> So Arch is shipping Wine packages with crippled 3D support? I still see i386-unix directory in the wine package files (so I don't think Arch is doing that)

Jan. 17, 2024

Re: 9.0 release notes, please review

by Elizabeth Figura

On Wednesday, 17 January 2024 08:57:14 CST Hans Leidekker wrote: > On Wed, 2024-01-17 at 16:17 +0200, Gabriel Ivăncescu wrote: > > On 17/01/2024 01:31, Francois Gouget wrote: > > > On Tue, 16 Jan 2024, Hans Leidekker wrote: > > > > > > > On Tue, 2024-01-16 at 18:24 +0100, Francois Gouget wrote: > > > > > > - Smart cards are supported in the Winscard dll, using the Unix > > > > > > PSCSlite library. > > > > > > > > > > It should probably be noted that this is not supported for 32-bit > > > > > Windows applications despite Wine providing a 32-bit winscard.dll. > > > > > > > > It is supported for 32-bit applications but currently only in the new > > > > Wow64 setup. > > > > > > And since no one will use that mode the release notes should note that > > > this is not supported in pure 32-bit Wine and for 32-bit applications > > > running in the default old WoW64 mode that every Linux distribution will > > > ship. > > Arch is already offering new-style wow64 packages and macOS users have no > choice. So Arch is shipping Wine packages with crippled 3D support? > > Not being use-able in pure 32-bit Wine sounds pretty bad, I hope it > > doesn't become a trend. > > I don't believee there are many users stuck on pure 32-bit Wine that also need > winscard support. Note that it was never usable when pure 32-bit Wine was still > the norm. Adding support isn't free unfortunately and I don't think that passing > the tests is sufficient reason to pay that cost. I'd rather wait and see if > there's real interest. Isn't it unusable in old wow64 as well?

Jan. 17, 2024