3 ms·

Well hindsight is 20:20 so I won't be too harsh on them, but a clairvoyant Windows team could have done some serious competitive analysis to try and discern why

Well hindsight is 20:20 so I won't be too harsh on them, but a clairvoyant Windows team could have done some serious competitive analysis to try and discern why developers were wanting to build web apps despite the clear lead the MS ecosystem had in GUI toolkit quality, developer tools, languages and even (at that time) job market for devs. I think if they'd done that they'd have concluded: • Devs pick the web because it means deployment+start can be one click on a hyperlink, the browser will also update your software without any prompting of the user. • Sandboxing really matters because it's what enables the former. • Guaranteed and easy server connectivity really matters. • High level scripting really matters. So, they could have e.g. tried to make a sandboxed version of Visual Basic in which the P-code you downloaded was used just for UI, with all other serious logic on the server. Maybe even using a properly client/server variant of DCOM to provide client<->server calls. Basically a kind of web browser like thing but on top of the MS stack instead of HTML. Devs would probably have found that pretty compelling. ActiveX was the closest attempt but it didn't fit the bill. It wasn't sandboxed in any way, and ActiveX controls took forever to download because they were all native code. They definitely weren't high level and you didn't get any kind of convenient server connectivity out of the box either. Then BillG decided to do .NET and I guess code sandboxing got sucked up into that project, the Windows guys were somehow allowed to reject the whole .NET concept, and deployment wasn't sorted out for many years. Kernel level native code sandboxing wasn't possible on the Win 9x codebase and is still pretty ropey even in Win 11, so that was also out. Apple didn't really win against the web, and their API is largely backwards compatible to the start of OS X. Also, the initial versions of OS X did contain support for both running old MacOS Classic apps in emulation, and also porting them to the new APIs whilst minimizing the size of rewrite required (Carbon). So their backwards compatibility isn't too bad.

mwcampbell 2y ago
> 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.

mwcampbell 2y ago

> 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.