wine-devel

wine-devel@winehq.org

4 participants
84464 discussions

x86 SGDT emulation for Wine
by Elizabeth Figura 03 Jan '24

03 Jan '24

Hello all, There is a Windows 98 program, a game called Nuclear Strike, which wants to do some amount of direct VGA access. Part of this is port I/O, which naturally throws SIGILL that we can trivially catch and emulate in Wine. The other part is direct access to the video memory at 0xa0000, which in general isn't a problem to catch and virtualize as well. However, this program is a bit creative about how it accesses that memory; instead of just writing to 0xa0000 directly, it looks up a segment descriptor whose base is at 0xa0000 and then uses the %es override to write bytes. In pseudo-C, what it does is: int get_vga_selector() { sgdt(&gdt_size, &gdt_ptr); sldt(&ldt_segment); ++gdt_size; descriptor = gdt_ptr; while (descriptor->base != 0xa0000) { ++descriptor; gdt_size -= sizeof(*descriptor); if (!gdt_size) break; } if (gdt_size) return (descriptor - gdt_ptr) << 3; descriptor = gdt_ptr[ldt_segment >> 3]->base; ldt_size = gdt_ptr[ldt_segment >> 3]->limit + 1; while (descriptor->base != 0xa0000) { ++descriptor; ldt_size -= sizeof(*descriptor); if (!ldt_size) break; } if (ldt_size) return (descriptor - ldt_ptr) << 3; return 0; } Currently we emulate IDT access. On a read fault, we execute sidt ourselves, check if the read address falls within the IDT, and return some dummy data from the exception handler if it does [1]. We can easily enough implement GDT access as well this way, and there is even an out-of-tree patch written some years ago that does this, and helps the game run. However, there are two problems that I have observed or anticipated: (1) On systems with UMIP, the kernel emulates sgdt instructions and returns a consistent address which we can guarantee is invalid. However, it also returns a size of zero. The program doesn't expect this (cf. the way the loop is written above) and I believe will effectively loop forever in that case, or until it finds the VGA selector or hits invalid memory. I see two obvious ways to fix this: either adjust the size of the fake kernel GDT, or provide a switch to stop emulating and let Wine handle it. The latter may very well a more sustainable option in the long term (although I'll admit I can't immediately come up with a reason why, other than "we might need to raise the size yet again".) Does anyone have opinions on this particular topic? I can look into writing a patch but I'm not sure what the best approach is. (2) On 64-bit systems without UMIP, sgdt returns a truncated address when in 32-bit mode. This truncated address in practice might point anywhere in the address space, including to valid memory. In order to fix this, we would need the kernel to guarantee that the GDT base points to an address whose bottom 32 bits we can guarantee are inaccessible. This is relatively easy to achieve ourselves by simply mapping those pages as noaccess, but it also means that those pages can't overlap something we need; we already go to pains to make sure that certain parts of the address space are free. Broadly anything above the 2G boundary *should* be okay though. Is this feasible? We could also just decide we don't care about systems without UMIP, but that seems a bit unfortunate; it's not that old of a feature. But I also have no idea how hard it would be to make this kind of a guarantee on the kernel side. This is also, theoretically, a problem for the IDT, except that on the machines I've tested, the IDT is always at 0xfffffe0000000000. That's not great either (it's certainly caused some weirdness and confusion when debugging, when we unexpectedly catch an unrelated null pointer access) but it seems to work in practice. --Zeb [1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/krnl386.exe16/ instr.c#l702

3 3

Handling stack overflow
by Dāvis Mosāns 01 Jan '24

01 Jan '24

Hi, I've been looking to get League of Legends work in Wine. The issue is that their Anti-Cheat hooks bunch of functions in ntdll.dll directly by prepending `jmp their_code` before the real function and it seems it messes something up. Anyway, topic of this email is about handling of stack overflow. When their exception handler gets messed up it is invoked recursively until stack overflow. And because it happened while it was in critical section it causes other threads to deadlock. My question is how such case should be handled? When thread is killed should lock be released so other threads can still proceed? Or maybe just whole process should be killed if any thread has stack overflow? To me it looks like in Windows when exception handler goes too deep then Just in Time debugger is invoked or if that's not enabled then process is killed with EXCEPTION_ACCESS_VIOLATION (maybe because it tried to access beyond end of stack?) Log looks like: [...] 0120:trace:seh:call_handler calling handler 00006FFFFFC97030 (rec=00007F3214C54360, frame=00007F3214D4E710 context=00007F3214C538D0, dispatch=00007F3214C537A0) 0120:trace:seh:call_handler handler at 00006FFFFFC97030 returned 2 0120:trace:seh:call_stack_handlers nested exception 0120:trace:seh:call_handler calling handler 00000001413B347C (rec=00007F3214C54360, frame=00007F3214D4F570 context=00007F3214C538D0, dispatch=00007F3214C537A0) 0120:err:virtual:virtual_setup_exception stack overflow 2576 bytes addr 0x6ffff9e66327 stack 0x7f3214c505f0 (0x7f3214c50000-0x7f3214c51000-0x7f3214d50000) 0124:err:sync:RtlpWaitForCriticalSection section 00006FFFFFCAE4C0 "../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 0124, blocked by 0120, retrying (60 sec) 011c:err:sync:RtlpWaitForCriticalSection section 00006FFFFFCAE4C0 "../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 011c, blocked by 0120, retrying (60 sec) [...] // stuck like this And several threads stuck like this Thread 8 (Thread 472 "011c"): #0 0x00006fffffc966d4 in NtWaitForAlertByThreadId () from /opt/wine-lol-staging/lib/wine/x86_64-windows/ntdll.dll #1 0x00006fffffc9db68 in RtlWaitOnAddress (addr=addr@entry=0x6fffffcae4d8 <loader_section+24>, cmp=cmp@entry=0x6fffffcbda90 <zero>, size=size@entry=4, timeout=timeout@entry=0x7fc37b38f700) at ../wine/dlls/ntdll/sync.c:912 #2 0x00006fffffc9dd06 in wait_semaphore (timeout=<optimized out>, crit=0x6fffffcae4c0 <loader_section>) at ../wine/dlls/ntdll/sync.c:196 #3 RtlpWaitForCriticalSection (crit=crit@entry=0x6fffffcae4c0 <loader_section>) at ../wine/dlls/ntdll/sync.c:314 #4 0x00006fffffc9df71 in RtlEnterCriticalSection (crit=crit@entry=0x6fffffcae4c0 <loader_section>) at ../wine/dlls/ntdll/sync.c:383 #5 0x00006fffffc7667b in loader_init (context=context@entry=0x7fc37b38fb00, entry=entry@entry=0x7fc37b38fb80) at ../wine/dlls/ntdll/loader.c:4405 #6 0x00006fffffc9a444 in LdrInitializeThunk (context=0x7fc37b38fb00, unk2=<optimized out>, unk3=<optimized out>, unk4=<optimized out>) at ../wine/dlls/ntdll/signal_x86_64.c:1716 #7 0x00006ffff88f7954 in ?? () from /mnt/Riot Games/League of Legends/wine/dosdevices/s:/Riot Games/League of Legends/Game/stub.dll Best regards, Dāvis

3 4

Wine staging 9.0-rc3 release
by Alistair Leslie-Hughes 23 Dec '23

23 Dec '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc3 (498 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 staging 9.0-rc2 release
by Alistair Leslie-Hughes 16 Dec '23

16 Dec '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc2 (498 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * [45455] setupapi: Add stub for DriverStoreFindDriverPackageW. * [55282] where: Implement search with default options. Updated: * vkd3d-latest to 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

Code freeze for Wine 9.0
by Alexandre Julliard 10 Dec '23

10 Dec '23

Folks, With the end of the year approaching, it's time to start preparing for the 9.0 stable release. We'll follow the same schedule as every year, with code freeze in early December, and a final release sometime in January. This year, the code freeze period will start on December 8th. So if you have things that you'd like to see included in 9.0, make sure to submit them soon, so that there's enough time for review before code freeze starts. -- Alexandre Julliard julliard(a)winehq.org

1 1

Wine staging 9.0-rc1 release
by Alistair Leslie-Hughes 09 Dec '23

09 Dec '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc1 (493 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * bcrypt: Allow multiple backends to coexist. * bcrypt: Implement BCryptSecretAgreement with libgcrypt. * bcrypt: Implement BCRYPT_KDF_HASH. Added: * None Updated: * vkd3d-latest to latest. * ntdll-DOS_Attributes * mfplat-streaming-support * ntdll-ForceBottomUpAlloc 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 8.0.2 fails to create a window
by volker.schlegel＠tutanota.com 01 Dec '23

01 Dec '23

Hello everyone,I've recently switched from Manjaro to Mint, and just installed WINE again.Latest stable release, 8.0.2, from the wineHQ repos.Any application trying to create a window seems to crash.Example crash dump (new prefix): https://pastebin.com/T6WG9EhQ Since it seems to be a graphics issue, here is the output of inxi -G: https://pastebin.com/SvURv3fYWhile searching for a fix I stumbled across this bug, might be related? https://bugs.winehq.org/show_bug.cgi?id=51210"Deactivate your GPU" isn't really a solution though in my opinion.I'd try to actually fix it myself (I've built wine myself before, and I have written quite a bit of C code), but I've never used Vulkan or OpenGL, so any help is appreciated!

1 0

Wine staging 8.21 release
by Alistair Leslie-Hughes 25 Nov '23

25 Nov '23

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

GCC 4.3 support and language features
by Fabian Maurer 22 Nov '23

22 Nov '23

Hello wine-devel, I wanted to follow up on the discussion on https://gitlab.winehq.org/wine/ wine/-/merge_requests/3059 For those not in the loop: The question came up what GCC version is the oldest supported one, and which language features can't be used in Wine. Is there already a wiki entry on this? Associated bug report: https://bugs.winehq.org/show_bug.cgi?id=54601 (Compilation fails with gcc 4.3.4 (error: unknown field ‘Type’ specified in initializer) I have a bunch of gcc 4.3 patches, and if it's supported, I think it would be useful getting those in before the next stable. Although ongoing gcc 4.3 support is probably a bit of work, since most people don't test against gcc 4.3 compatibility so there's some "regressions" from time to time. An option would be to just patch it when someone complains, which would be the most reasonable to me. Or just cap it at 4.8 which currently works. In the end, some compiler will be too old, so where is the line? In a similar vein, what about https://bugs.winehq.org/show_bug.cgi?id=20474 (Wine can't be built with GCC in C99 mode) Is this a supported setup? IMHO itwould be too much effort work to get this working, but I don't make the decisions. Regards, Fabian Maurer

8 9

Wine staging 8.20 release
by Alistair Leslie-Hughes 11 Nov '23

11 Nov '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.20 (493 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * winemenubuilder: Create .desktop files for programs that open URIs. * winecfg: Mention protocol associations. Added: * None Updated: * vkd3d-latest to 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

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