Calling game-playing a stress test of a translation layer is a bit misleading. The idea is to abstract out the incidental complexity of system and library call

Calling game-playing a stress test of a translation layer is a bit misleading. The idea is to abstract out the incidental complexity of system and library calls and function names, etc., so that the irreducible complexity of writing graphics data to the GPU runs at the same speed. For business software, the complexity is not incidental as shown by the difficulty of writing Wine. When Microsoft makes up entirely new chunks of software and calls them "system libraries", Wine has to replicate their functionality. Such as with including IE as a component of Windows, Wine essentially had to replicate all that functionality in order to run things like Quickbooks. When they added .NET as a "system" component, Wine had to make that work by allowing .NET installs that work or replicating the functionality. Now, with WPF-based Universal Windows Platform apps, the windows API has become horribly complex with lots of little features and bugs that have to be copied to bring a translator to feature parity. If you go through the Wine source code, you'll see that a lot of stuff is still unimplemented, for features that existed as of 1999 or so in Windows. Windows has like 3 different ways of formatting text on the screen. It has several graphics apis. It has multiple apis for accessing the same hardware (like scanners). There are lots of little bits of functionality shipped as part of the operating system that seem unnecessary until a random business app uses them. Getting the "essential" services for a small slice (like with ndiswrapper drivers) is a lot easier than being able to take one of these old applications like Quickbooks and make it work correctly.