You have 32-bit compatibility layers going back to Windows 95, including whatever is needed to render a GUI from that era. And you have 64-bit, possibly going as far back as Windows XP.
Are you sure? IIRC, from Windows 7 onwards XP compatibility was handled with a VM, and I'm fairly confident there's little in the way of Win95 support in Windows 10 (bear in mind Windows 10 is a continuation of the Windows NT line of operating systems, the Win9x operating systems were not in this lineage).
> IIRC, from Windows 7 onwards XP compatibility was handled with a VM
You have a funny definition of "is handled with". Your link describes manually installing additional, optional software to get a VM, not a feature of the Windows OS. I don't think very many people have done this and plenty of XP-era software "just works" without it.
XP mode exists in Windows 7 and beyond because Microsoft doesn't promise full compatibility with Windows XP. If some XP software "just works" it's no guarantee that it will continue to work as Windows changes. Furthermore, regarding "optional software to get a VM, not a feature of the Windows OS", XP Mode is a feature of the OS in the sense that the seamless integration with the apps running in the VM was designed by Microsoft for the purpose of supporting older software.
Out of interest, which XP-era software just works without it? I'm not talking about software that has been compiled for later Windows versions, I'm talking about software that hasn't been updated since XP.
> "Simply, it does not. Do a clean install. It's not there. That is why you have to go to that web page and click that big "download" button."
The assertion made was that Windows 10 contains multiple versions of Windows under the hood. If XP was one of these OS then there would be no need for that 'big download button', yet it exists. Why do you think that is?
> "PS: I was on the windows team during development of 7."
Good, then you can clear up what incompatibilities Windows 7 has with older Windows versions. For example, what level of support is there for Windows 95 software?
I didn't work on app compat, but there are a number of things that come to mind.
The first line of defense is that over the years and on average Win32 and COM were not built stupidly, but with an eye towards compatibility. It's a stable API. The fact that over history there have been 3 independent kernels (9x, NT, CE) that speak it and you could reasonably have a single code base running on all 3 does some good in this area. (And 9x/NT were largely binary compatible.) And hence there are simple things like: don't change function signatures release to release, don't change COM vtables without introducing a new interface leaving the old one in place, introduce size and version fields in structures so that future versions can add to them without breaking old callers, etc.
But there are also mitigations for incorrect or impolite misuse of Win32 that might be common in old software.
Example: If a 32-bit application writes to C:\Windows or some such like programs used to (and a current OS would have locked down by permissions), Vista and higher will redirect to AppData\Local\VirtualStore in the user's home directory. [1]
Example: Certain features like DEP and ASLR are opt-in at the binary level. An old binary will get an executable stack and no ASLR by default because old code might rely on these.
Example: There is actually a framework of app compat shims for common historical misuse of Win32 API. [2] When I worked at MS some time ago I used to read these in the source tree when I was bored or for simple amusement/curiosity. One of them for a particular 9x game always stuck in my mind, it had to do with API misuse and differences between 9x kernel32.dll (typically traps into the kernel right away) and NT kernel32.dll (which usually calls into ntdll after doing some user mode conversion), but maybe I won't go into more detail than that here ...
So my point is... You've got a stable API in Win32, you've got fairly conservative introduction of features that tend to break things, you've even got a way to selectively change how APIs behave for popular old apps. These things work pretty well by and large. Why waste a bunch of time and disk space with VMs?
On your side of the fence there is a VM host built into the Windows kernel (Hyper-V) and I think RDP can make remote apps (where "remote" could mean inside a VM guest) look pretty good. That is probably what is happening in "XP Mode". I don't think it'll necessarily do a better job than just Windows being Windows, which IMO does pretty well for most old software.
Citations using publicly available sources:
[1] Wikipedia article for UAC - https://en.wikipedia.org/wiki/User_Account_Control : For example, if an application attempts to write to a directory such as "C:\Program Files\appname\settings.ini" to which the user does not have write permission, the write will be redirected to "C:\Users\username\AppData\Local\VirtualStore\Program Files\appname\settings.ini".
What do you mean? Having both 32-/64-bit versions of things? Or separate versions of DLLs for compatibility mode(s)? Something else?