* direct hardware access that worked in win9x/3.x but is disallowed in NT (games usually) * ASLR breaks things, if you enable full ASLR on Windows it requires applications to be recompiled. I don't know how it's done now but in the past in their kernel they only enabled ASLR for base system executables * Windows 10 introduced something that broke some previous executables, I don't know details on this because I was out of Windows by then but I saw people complaining that this never happened before (it's probably happened before) * Windows tries to retain undocumented behavior (like order of items returned by an API call) from previous versions of Windows for some popular applications (I think simcity was one) but not always * application that relies on a symbol that got deprecated or was a private API
@Moon >direct hardware access that worked in win9x/3.x but is disallowed in NT (games usually) even in XP i remember suffering through this, game complained about "running windows NT" which was technically right but as a young kid...
@r000t@Moon A Windows emulator like you speak of already existed and is long dead. Even within that product itself, they switched from their Merge based emulation to a more general purpose x86 emulator later. https://dbpedia.org/page/Win4Lin
Intel already ships DXVK in their GPU drivers in lei of actually writing DirectX compatible drivers the normal way. Microsoft is sure to quietly adopt WINE any time now. Or, maybe they just don't give a shit about power users anymore and only want to focus on selling cloud instances of the Windows 11 desktop, running on who cares what kernel.
Honestly I'm kind of surprised the EU hasn't forced them to give money to the ReactOS project, like how cigarette companies have to pay for anti smoking ads in the US.
@olmitch@Moon Ideally like.... something like this should be one line of bash to call QEMU, honestly. But that's if I was doing it on Linux. I don't know if Windows has an equivalent of QEMU.