4 ms·

Right, they tried adopting C#/XAML for the shell and Office with Longhorn, and when that project failed they decided to essentially reimplement WPF and .net in

Right, they tried adopting C#/XAML for the shell and Office with Longhorn, and when that project failed they decided to essentially reimplement WPF and .net in native code, e.g. WPF text stack -> DirectWrite WPF visual layer -> Direct2D, Windows.UI.Composition WPF UI layer -> WinRT XAML .net type system/metadata -> WinRT metadata CAS/partial trust/other .net security stuff -> AppContainer ClickOnce -> AppX If you compare what .net was supposed to be around 3.0 with what .net Core is now, they've basically stripped out all of the "OS-like" stuff - UI frameworks, app model/packaging, security - and taken the stance that those are the responsibility of the OS. UWP is just the Windows native implementation of the stuff that was stripped out of .net to be left up to each OS

pjmlp 10y ago
I always thought that .NET should have been AOT compiled to native code since day one, not the JIT/NGEN mix, given Anders experience with Turbo Pascal and Delphi. But as someone that follows Windows development since 3.0, and had the pleasure to being introduced to Oberon, I think one of the biggest reasons for Longhorn's failure was the wars between DevTools and WinDev. To build on your mappings, many other components shown up as COM in Vista and since then the majority of Windows APIs are actually COM based, not Win32 C style ones. Reading the paper about Ext-VOS, .NET's genesis, and doing the comparisasion with how WinRT looks like, was quite interesting.