Comment by Kwpolska
6 days ago
Many Windows Server admin tools (such as Server Manager or Virtual Machine Connection) and MMC snap-ins (e.g. Event Viewer, Hyper-V Manager) are written in .NET Framework 4. PowerShell is .NET Framework 4. Everyone’s favorite bloated IDE (Visual Studio) is .NET Framework 4 as well.
In the Office land, Excel’s Power Query is .NET Framework 4.
Adopting the modern .NET is probably harder due to its lifecycle.
Calculator is C# as well (though apparently that's somewhat recent: https://github.com/microsoft/calculator/pull/1598).
Porting to C# was a community effort after it went open source, it was originally C++/CX.
Powershell is .NET Core since version 6, the .NET Framework one is Powershell 5.1.
Yeah, Microsoft themselves have issue moving away from .NET Framework.
You can add SQL Server CLR, Dynamics, Sharepoint on prem, to the list.
OMG could you imagine writing MMC snap-ins using some sort of plugin declspec import bs in C++? .Net and reflection with Assembly.Load saves so much time and effort to build modular “ship it now, deliver features later, extend it if we fall behind” apps. Not that those are good things, it just means you can defer until your MS PM gets the budget to fill those backfill positions that have been open for 12 months because the hiring bar is astrophysics
I can, because due to Windows team love for COM and C++, many extension points require doing exactly that.
Want to extend the context menu actions, or add new thumbnail capabilities for a recent file format?
It is exactly that.
Even with WinRT Runtime Components, they were doing in a way that some APIs were only surfaced when using the components from C++.
Quite a different approach from OS / language teams at Apple and Google, where productivity with better languages has a priority no matter what.