March 2025 - Wine-Devel - list.winehq.org

Testbot since the weekend not reachable

by Bernhard Übelacker

Hello, is someone else also experiencing issues when accessing testbot.winehq.org? This seems to have caused missing results for the Friday tests run. Today in my browser still no results get shown. Querying via wget it shows data gets delivered after 3 minutes. The resulting page looks like at Friday got 5900 jobs queued (151728 to 157632). These jobs are all prefixed with [wine-devel], like if there was a jam in the patch submission? Kind regards, Bernhard $ LANG=C wget -O testbot.html https://testbot.winehq.org/ 2>&1 | ts '%Y-%m-%d %H:%M:%S:' 2025-03-11 09:55:15: --2025-03-11 09:55:15-- https://testbot.winehq.org/ 2025-03-11 09:55:15: Resolving testbot.winehq.org (testbot.winehq.org) 104.130.219.87, 2001:4801:7828:101:be76:4eff:fe10:1727 2025-03-11 09:56:20: Connecting to testbot.winehq.org (testbot.winehq.org)|104.130.219.87|:443... connected. 2025-03-11 09:58:00: HTTP request sent, awaiting response... 200 OK 2025-03-11 09:58:00: Length: unspecified [text/html] 2025-03-11 09:58:00: Saving to: 'testbot.html' 2025-03-11 09:58:00: 2025-03-11 09:58:00: 0K .......... .......... .......... .......... .......... 187K 2025-03-11 09:58:00: 50K .......... .......... .......... .......... .......... 236K ... 2025-03-11 09:58:11: 2350K .......... .......... .......... .......... .......... 349K 2025-03-11 09:58:13: 2400K .......... .......... 8.99K=13s 2025-03-11 09:58:13: 2025-03-11 09:58:13: 2025-03-11 09:58:13 (188 KB/s) - 'testbot.html' saved [2478249] 2025-03-11 09:58:13:

March 11, 2025

Re: Apple Silicon compilation

by Elizabeth Figura

On Monday, March 10, 2025 9:54:18 PM Central Daylight Time robert lippmann wrote: > > * MacOS won't allow you to map anything below 4 GB, so Wine can't place > > the > > KSHARED_USER_DATA at 0x7ffe0000. > > Actually, Windows doesn’t do that anymore on 64 bit systems: > > https://msrc.microsoft.com/blog/2022/04/randomizing-the-kuser_shared_data-st > ructure-on-windows/ That's not quite what you think. Microsoft can't actually move the KUSD without breaking things in both the user and the kernel; it's de facto API. Rather, what they did is make the *kernel* page read-only (the user page was already read-only), and map a writable copy at a different address (the kernel page needs to be writable so that the kernel can update dynamic fields like time). This doesn't help us because we still need to map the read-only page.

March 11, 2025

Re: Apple Silicon compilation

by Dean Greer

It’s not a great idea to use too many macOS only functions over FOSS Unix libraries when possible. Wine used to use way more macOS backends and those quickly became broken and took a lot of convincing to remove said dead code. On Mon, Mar 10, 2025 at 10:54 PM robert lippmann < robert.lippmann.development(a)gmail.com> wrote: > > * MacOS won't allow you to map anything below 4 GB, so Wine can't place the > > KSHARED_USER_DATA at 0x7ffe0000. > > > Actually, Windows doesn’t do that anymore on 64 bit systems: > > msrc.microsoft.com > <https://msrc.microsoft.com/blog/2022/04/randomizing-the-kuser_shared_data-s…> > > <https://msrc.microsoft.com/blog/2022/04/randomizing-the-kuser_shared_data-s…> > <https://msrc.microsoft.com/blog/2022/04/randomizing-the-kuser_shared_data-s…> > > > * ARM MacOS has 16 kb pages whereas Windows has 4kb ones. > > > Yeah, that seems to be the sticking point. Asahi has that problem too. > > I’ve been thinking about that, and was wondering if it might just be a > better idea to delegate functions to their UIKit/Foundation/whatever > frameworks. > > It would probably need to be a fork, since Wine can’t have objective C > code (and Apple is moving to Swift anyway). > > Or, I saw this for making Cocoa C bindings: > [image: c_ocoa.png] > > FelixK15/c_ocoa <https://github.com/FelixK15/c_ocoa> > github.com <https://github.com/FelixK15/c_ocoa> > <https://github.com/FelixK15/c_ocoa> > > > >

March 11, 2025

Re: Apple Silicon compilation

by robert lippmann

> > * MacOS won't allow you to map anything below 4 GB, so Wine can't place the > KSHARED_USER_DATA at 0x7ffe0000. > Actually, Windows doesn’t do that anymore on 64 bit systems: https://msrc.microsoft.com/blog/2022/04/randomizing-the-kuser_shared_data-s… > * ARM MacOS has 16 kb pages whereas Windows has 4kb ones. > Yeah, that seems to be the sticking point. Asahi has that problem too. I’ve been thinking about that, and was wondering if it might just be a better idea to delegate functions to their UIKit/Foundation/whatever frameworks. It would probably need to be a fork, since Wine can’t have objective C code (and Apple is moving to Swift anyway). Or, I saw this for making Cocoa C bindings: https://github.com/FelixK15/c_ocoa FelixK15/c_ocoa github.com

March 11, 2025

Re: Wine compatibility checking tool

by Elizabeth Figura

On Monday, 10 March 2025 14:55:47 CDT robert lippmann wrote: > > > > > Relatively few bugs are actually because a missing or stub export. Just because the export is there doesn't mean it behaves the way the application expects. > > > > And not everything an application imports is actually called. That's why we have the @stub lines in the first place. It shuts up a lot of spam at program load time and still writes clear information when the function is actually called. FIXME lines/warnings aren't free - they tend to mislead users into thinking the crash is because of the last FIXME they saw. > > > > Library imports also don't find COM interfaces used. > > Ah, that’s what I was wondering. I must have found a rare case of an application that uses a rarely used part of the Win32 SDK which hasn’t been implemented yet. > > I don't know if I'd call it rare necessarily; it happens fairly often (as you can tell by the number of new stubs that show up on the list), but the amount of development time it takes up is certainly proportionally minuscule. I would simply say that the compatibility checking tool you're describing already exists, and is called "Wine". It's overwhelmingly clear when a program fails that way.

March 10, 2025

Re: Wine compatibility checking tool

by robert lippmann

> > Relatively few bugs are actually because a missing or stub export. Just because the export is there doesn't mean it behaves the way the application expects. > > And not everything an application imports is actually called. That's why we have the @stub lines in the first place. It shuts up a lot of spam at program load time and still writes clear information when the function is actually called. FIXME lines/warnings aren't free - they tend to mislead users into thinking the crash is because of the last FIXME they saw. > > Library imports also don't find COM interfaces used. Ah, that’s what I was wondering. I must have found a rare case of an application that uses a rarely used part of the Win32 SDK which hasn’t been implemented yet.

March 10, 2025

Re: Wine compatibility checking tool

by Stefan Dösinger

> Am 10.03.2025 um 21:29 schrieb robert lippmann <robert.lippmann.development(a)gmail.com>: > > I was thinking more to pro-actively determine if a program might crash so that wine developers can (possibly) focus efforts on implementing those stub functions to increase overall app compatibility. Relatively few bugs are actually because a missing or stub export. Just because the export is there doesn't mean it behaves the way the application expects. And not everything an application imports is actually called. That's why we have the @stub lines in the first place. It shuts up a lot of spam at program load time and still writes clear information when the function is actually called. FIXME lines/warnings aren't free - they tend to mislead users into thinking the crash is because of the last FIXME they saw. Library imports also don't find COM interfaces used.

March 10, 2025

Re: Wine compatibility checking tool

by robert lippmann

I was thinking more to pro-actively determine if a program might crash so that wine developers can (possibly) focus efforts on implementing those stub functions to increase overall app compatibility. > On Mar 10, 2025, at 12:05 PM, Esme Povirk <esme(a)codeweavers.com> wrote: > > I don't think it'd be very useful, at least for understanding crashes. If the program actually calls those functions before the crash, there will be a fixme or exception that tells us that (with the possible exception of using GetProcAddress, but we can't detect that from a PE image anyway). > > On 2025-03-09 22:49, robert lippmann wrote: >> Hi all, >> >> I had an idea for something that might be useful and wanted to know everyone’s thoughts. >> >> Basically, create a program that will take a Windows executable/dll, find all the imports and check Wine’s .spec files to see if the imports are stubs or don’t exist. Obviously could also go recursive through imports of other dlls down to the win32 sdk level too. >> >> It might help figure out some “why is this program crashing” issues. >> >> Thoughts? >> Rob >> >

March 10, 2025

Re: Wine compatibility checking tool

by Esme Povirk

I don't think it'd be very useful, at least for understanding crashes. If the program actually calls those functions before the crash, there will be a fixme or exception that tells us that (with the possible exception of using GetProcAddress, but we can't detect that from a PE image anyway). On 2025-03-09 22:49, robert lippmann wrote: > Hi all, > > I had an idea for something that might be useful and wanted to know everyone’s thoughts. > > Basically, create a program that will take a Windows executable/dll, find all the imports and check Wine’s .spec files to see if the imports are stubs or don’t exist. Obviously could also go recursive through imports of other dlls down to the win32 sdk level too. > > It might help figure out some “why is this program crashing” issues. > > Thoughts? > Rob > >

March 10, 2025

Wine compatibility checking tool

by robert lippmann

Hi all, I had an idea for something that might be useful and wanted to know everyone’s thoughts. Basically, create a program that will take a Windows executable/dll, find all the imports and check Wine’s .spec files to see if the imports are stubs or don’t exist. Obviously could also go recursive through imports of other dlls down to the win32 sdk level too. It might help figure out some “why is this program crashing” issues. Thoughts? Rob

March 9, 2025