Microsoft has a very elaborate backwards compatibility system. They can do things like like to some processes about what version of Windows they are running on, change the behavior of particular APIs to work around application bugs, and generally inject whatever hacks and adjustments that they need in order to ensure that old or badly written software continues to run on new versions of Windows.

It's glorious (lousy software continues to work while Microsoft is able to continue improving the OS) and terrible (software developers who are updating their software get shims applied and this complicates development, hides bugs, etc.

https://en.wikipedia.org/wiki/Shim_(computing)

In context, the Microsoft OS detecting the problematic driver and patching out calls to various functions to make it behave better.

This is more commonly used for bug-for-bug backwards compatibility: if there's a a third-party application that was incorrectly using some Windows API which has been fixed in a newer version, and the fix breaks the application, MS might shim that version of the application with a call to the older version of the function or even a new piece of code that emulates the desired behavior.

(Non-Windows users might recognize this as the same basic technical approach as LD_PRELOAD / DYLD_INSERT_LIBRARIES, or a little more generically, symbol versioning.)

Redefining a thing to do a different thing to achieve the same result. You'll see it a lot in older systems where you have a billion deprecated functions, and instead of changing each instance to use the new version, you trick the system by appropriating the old version to point to custom code that runs the new version and passes back whatever the old version is expected to return.

I typically think of that as a facade. I guess it depends on what direction you are looking at it from?

So like monkey-patching?

Similar, yes.

Windows has loads of stuff that is run conditionally on hardware and software configuration. I would not be surprised if Microsoft added a check to make the functions mentioned have different behavior. If you read the latest Windows Internals you'll learn about tons of things along those lines. There's lots of very specific behavior that gets triggered when you run things in compatibility mode, for example.

Basically, Windows' value proposition is broad hardware and software compatibility, and it will bend over backwards to make that happen, despite a developer's best efforts.