3 ms·

Doesn't look to me like they're trying to kill .NET at all. Maybe F# in particular isn't getting the love and attention it deserves but they'd have to be mental

by smcl 3y ago

Doesn't look to me like they're trying to kill .NET at all. Maybe F# in particular isn't getting the love and attention it deserves but they'd have to be mental to be actively trying to kill off something as popular as .NET

pjmlp 3y ago
Kill in the sense that from WinDev point of view, the less .NET ships on Windows the better. In case you aren't aware, WinRT basically marks the turning point started with Longhorn ideas being rewriten into COM. With WinRT, they basically went back to the drawing board of Ext-VOS, a COM based runtime for all Microsoft languages, hence why .NET on WinRT/UWP isn't quite the same as classical .NET and is AOT compiled, with classes being mapped into WinRT types (which is basically COM, with IInspectable in addition to IUnknown and .NET metadata instead of COM type libraries). Mostly driven by Steven Sinofsky and his point of view on managed code. This didn't turned out as expected, but still the idea going forward is to make WinRT additions to classical COM usable in Win32 outside UWP application identity model. "Turning to the past to power Windows’ future: An in-depth look at WinRT" https://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/ https://arstechnica.com/features/2012/10/windows-8-and-winrt... Naturally since DevDiv also has something to say, .NET isn't going anywhere. And since nowadays "Azure OS" matters more than Windows, WinDev point of view is mostly relevant for Windows Server and Hyper-V workloads.
- WorldMaker 3y ago
  UWP never required AOT, it was an opt-in performance boost (that has since been rebuilt to support all of .NET in ".NET Native"). Today's post-UWP C#/WinRT bindings don't require AOT either. Beyond WinRT, .NET (Core) has supported all the raw COM, including COM component hosting since at least .NET Core 3.0. It's Windows-Only, of course, to use that, but that should go without saying. It's mostly backwards compatible with the old .NET Fx 1.0 ways of doing COM and a lot of the old code still "just works". .NET has proven that with .NET 5+ and all the many ways it (again) supports raw Win32 fun in the classic WinForms ways. (And all the ways that even .NET Fx 1.0 code has a compatibility path into .NET 5.) It would have been nice if Windows had stronger embraced .NET, but WinRT is still closer to .NET in spirit than old raw COM anyway.
  - pjmlp 3y ago
    UWP always deployed via AOT on the store. .NET Core doesn't do COM type libraries like the Framework does, you are supposed to manually write IDL files like in the old days. Additionally CCW/RCW infrastructure is considered outdated and you should use the new, more boilerplate based COM APIs introduced for COM and CsWinRT support. Lots of changes, with more work, for little value.

by smcl 3y ago

pjmlp 3y ago

Kill in the sense that from WinDev point of view, the less .NET ships on Windows the better. In case you aren't aware, WinRT basically marks the turning point started with Longhorn ideas being rewriten into COM. With WinRT, they basically went back to the drawing board of Ext-VOS, a COM based runtime for all Microsoft languages, hence why .NET on WinRT/UWP isn't quite the same as classical .NET and is AOT compiled, with classes being mapped into WinRT types (which is basically COM, with IInspectable in addition to IUnknown and .NET metadata instead of COM type libraries). Mostly driven by Steven Sinofsky and his point of view on managed code. This didn't turned out as expected, but still the idea going forward is to make WinRT additions to classical COM usable in Win32 outside UWP application identity model. "Turning to the past to power Windows’ future: An in-depth look at WinRT" https://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/ https://arstechnica.com/features/2012/10/windows-8-and-winrt... Naturally since DevDiv also has something to say, .NET isn't going anywhere. And since nowadays "Azure OS" matters more than Windows, WinDev point of view is mostly relevant for Windows Server and Hyper-V workloads.

WorldMaker 3y ago
UWP never required AOT, it was an opt-in performance boost (that has since been rebuilt to support all of .NET in ".NET Native"). Today's post-UWP C#/WinRT bindings don't require AOT either. Beyond WinRT, .NET (Core) has supported all the raw COM, including COM component hosting since at least .NET Core 3.0. It's Windows-Only, of course, to use that, but that should go without saying. It's mostly backwards compatible with the old .NET Fx 1.0 ways of doing COM and a lot of the old code still "just works". .NET has proven that with .NET 5+ and all the many ways it (again) supports raw Win32 fun in the classic WinForms ways. (And all the ways that even .NET Fx 1.0 code has a compatibility path into .NET 5.) It would have been nice if Windows had stronger embraced .NET, but WinRT is still closer to .NET in spirit than old raw COM anyway.
- pjmlp 3y ago
  UWP always deployed via AOT on the store. .NET Core doesn't do COM type libraries like the Framework does, you are supposed to manually write IDL files like in the old days. Additionally CCW/RCW infrastructure is considered outdated and you should use the new, more boilerplate based COM APIs introduced for COM and CsWinRT support. Lots of changes, with more work, for little value.