[soulbadguy]

Indeed. The CLR from its inception implemented a lot of features for helping native inter-op. I would guess that msft did make the effort simply because of their large legacy c/c++/win32 code base.

It's a shame really that msft stewardship of the .net/clr was so lacking. Of all the modern virtual machine clr us pretty much up there

[int_19h]

The goal wasn't so much native interop as being the universal VM for different languages. Specifically, they had an explicit requirement that pure CLR bytecode should be a valid compilation target for C++ (among other things - such as what would eventually become F#, hence why CLR also has explicit tailcalls, for example). But, of course, when you have all the necessary abstractions, that also allows for easy interop with the world outside the VM.

It's too bad that this vision was never fully realized - in part, because .NET was not open enough originally, but also because of internal divisions in Microsoft itself. If it did, we could have had the equivalent of both LLVM and WebAssembly much, much earlier.

[pjmlp]

The internal divisions had more a play into this than anything else, Windows could have evolved into something like Android or Inferno, but that isn't something that those on Sinofsky's team would accept.

Also why we got WinRT being like .NET, but with COM and C++, with .NET Native being a complete difference compiler toolchain, as he got hold of the Windows reigns.

[pjmlp]

Because it was yet another all-in, where all future Microsoft software was going to be .NET based, but WinDev/Office never played ball.

We just have to go back in time and see all those Visual Studio.NET shows on surviving documents, or how Ext-VOS (what became .NET) was being done at MSR.

We could have had something like Android, Inferno/Limbo in terms of .NET usage across the Windows layers, but it always bumps into the love for COM and C++, which incendently is how many Longhorn ideas were remade in Vista and continues to this day, using COM instead of .NET.