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.

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.

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.

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.