3 ms·

> the Windows guys were somehow allowed to reject the whole .NET concept What I heard was that the higher-ups pushed .NET as a core part of the OS pretty hard

> the Windows guys were somehow allowed to reject the whole .NET concept What I heard was that the higher-ups pushed .NET as a core part of the OS pretty hard during Longhorn, and it failed, leading to the Longhorn development reset around 2004 or 2005. Disclosure: I was on the Windows team at Microsoft, but long after all of this happened (2017-2020), and I never learned about Longhorn history from the inside. I don't remember sources for what I said above, though I think Herb Sutter has talked about it.

mike_hearn 2y ago
Yeah I've always assumed there must have been some really traumatic experiences in the past for Windows/.NET to become so completely divorced. I mean it'd have made sense to port or rewrite a pile of all the little utilities and subsystems that aren't performance sensitive at least. But I guess the backwards compatibility story w.r.t. .NET generics killed off their interest in allowing .NET to become a part of the Windows API.
- mwcampbell 2y ago
  One of the few Windows utilities that was allowed to be based on .NET, in Vista and Windows 7, was Narrator, the screen reader shipped with the OS. But Narrator was rewritten in C++ for Windows 8. That was still before I got there, but of course I asked about the history, since I was on the Narrator team. I think the deciding factor for doing the rewrite was the sluggish startup of the .NET version. I guess the need to run on Windows Phone 8.1 and Windows 10 Mobile was likely another factor, though now I don't recall if my teammates specifically said that it was.
- neonsunset 2y ago
  Back then performance profile of .NET (Framework) was just not where it is today sadly (even with C++/CLI there were warts, but I only know what is publicly available unlike the sibling comment).
senderista 2y ago
That is basically correct. All the Longhorn .NET code I'd written in the past 2 years was junked. Never understood why the concerns that led to .NET being dropped for OS development weren't addressed before development started.

mike_hearn 2y ago

Yeah I've always assumed there must have been some really traumatic experiences in the past for Windows/.NET to become so completely divorced. I mean it'd have made sense to port or rewrite a pile of all the little utilities and subsystems that aren't performance sensitive at least. But I guess the backwards compatibility story w.r.t. .NET generics killed off their interest in allowing .NET to become a part of the Windows API.

mwcampbell 2y ago
One of the few Windows utilities that was allowed to be based on .NET, in Vista and Windows 7, was Narrator, the screen reader shipped with the OS. But Narrator was rewritten in C++ for Windows 8. That was still before I got there, but of course I asked about the history, since I was on the Narrator team. I think the deciding factor for doing the rewrite was the sluggish startup of the .NET version. I guess the need to run on Windows Phone 8.1 and Windows 10 Mobile was likely another factor, though now I don't recall if my teammates specifically said that it was.
neonsunset 2y ago
Back then performance profile of .NET (Framework) was just not where it is today sadly (even with C++/CLI there were warts, but I only know what is publicly available unlike the sibling comment).

senderista 2y ago

That is basically correct. All the Longhorn .NET code I'd written in the past 2 years was junked. Never understood why the concerns that led to .NET being dropped for OS development weren't addressed before development started.