[andy_xor_andrew]

Curious if someone could enlighten me-

How much of these sorts of patches are specifically checking if a certain application is running, and then changing behavior to match what that application expects? And how much of it is simply better emulating the Windows API in general?

I think there are benefits to both approaches, not criticizing either one. I'm just curious if the implementation of a patch like this is "We fixed an inconsistency between Wine and Windows" vs "We're checking if Photoshop is running and using a different locking primitive" or whatever.

[spijdar]

I can't speak to this case specifically, but it's worth pointing out that Windows itself applies many patches for specific applications, so it follows that Wine could be obliged to mimic that behavior in cases where the application relies on it.

[superb_dev]

Not just Windows, it’s pretty common all over the place. I know for a fact web browsers and GPU driver will do the same

[Telaneo]

A tale as old as time.

https://arstechnica.com/gadgets/2022/10/windows-95-went-the-...

https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42...

https://devblogs.microsoft.com/oldnewthing/20160418-00/?p=93...

[ddtaylor]

The vast majority of Windows applications uses probably 1% of the API. That's why you can play a lot of games or run a lot of different apps and they mostly seem to work and only usually the obscure features like the help section or something might not work correctly.

In this case it looks like Adobe was doing a bunch of stuff related to Internet explorer that was critical to even having the basic functionality of their installer or launchers working.

Oftentimes if you take a program that is not running correctly or at all you can look at the log output and see a large stream of unsupported or partially supported API calls.

[imtringued]

This patch in particular is about implementation differences between Microsoft's XML implementation and libxml2 and the emulation of Internet Explorer quirks. [0], [1]

>And how much of it is simply better emulating the Windows API in general?

It depends on your definition of "Windows API". If you think Internet Explorer is part of the "Windows API", then this patch is 100% about better emulating the "Windows API".

>How much of these sorts of patches are specifically checking if a certain application is running, and then changing behavior to match what that application expects?

Probably near zero, because there is not much point in doing so. If you need to get a specific application to run on Wine that doesn't work out of the box, you're expected to follow an application specific recipe (installing particular versions of Windows libraries or selecting the version of Windows to be compatible with) rather than Wine itself special casing application support. There were plenty of ways to get Photoshop running on Wine in the past, the practical problem was that they were too reliant on already having a full Windows installation, which defeats the point of using Wine.

[0] https://github.com/PhialsBasement/wine-adobe-installers/comm...

[1] https://gitlab.winehq.org/wine/wine-staging/-/commit/8090aa9...

[YokoZar]

In general free open-source Wine has been developed with the philosophy of of not allowing application-specific code. Crossover (and presumably Photon), however, allows such patches for supported applications.

Patches can be motivated by specific apps, of course, but generally the requirement is to complete the patch implementing/fixing some API in a generic way, proven by additions to the test suite showing the same behavior on Windows.

[charcircuit]

The opposite it true too. Wine doesn't allow any code that isn't used. You have to find a specific app that uses it. If you don't know an app that calls a portion of a API you can not implement it even if the official documentation and behavior of using it on Windows makes it obvious how it should be implemented.