4 ms·

WPF has a dependency on the CLR which made it a non-starter for the Windows and Office teams. That's the main reason WinRT/UWP XAML was developed in the first p

WPF has a dependency on the CLR which made it a non-starter for the Windows and Office teams. That's the main reason WinRT/UWP XAML was developed in the first place; they wanted a developer platform they could use themselves, and those teams are unlikely to adopt C# anytime soon.

pjmlp 10y ago
Actually WinRT/UWP are the Longhorn ideas, using the original design of .NET, originally known as COM+ Runtime. Also a reason why .NET is AOT compiled to native code on UWP.
- contextfree 10y ago
  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.

pjmlp 10y ago

Actually WinRT/UWP are the Longhorn ideas, using the original design of .NET, originally known as COM+ Runtime. Also a reason why .NET is AOT compiled to native code on UWP.

contextfree 10y ago
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.