5 ms·

Steven Sinofsky wrote this piece a couple of weeks ago about the same topic: https://x.com/stevesi/status/2036921223150440542 https://x.com/stevesi/status/2036

Steven Sinofsky wrote this piece a couple of weeks ago about the same topic: https://x.com/stevesi/status/2036921223150440542 https://x.com/stevesi/status/2036921223150440542

deleted 7mo ago
[deleted]
dang 7mo ago
Since that article is a response to this one, we'll add a link to it in the toptext above. Thanks!
- markus_zhang 7mo ago
  Thank you!
int_19h 7mo ago
It's very amusing to see Sinofsky of all people all but dumping on .NET and (still?!) not understanding why developers so proactively jumped ship from Win32 & MFC hell to WinForms. Or why the HTML/JS app model in Win8 never really took off. I was in DevDiv during his great WinRT push and the overall feeling I remember was that the guys in Windows had zero clue as to what the devs actually wanted, but were hell bent on scorching all the ground that wasn't theirs. My team actually did some prototyping for Python/WinRT support, and we had it working to the point of the visual WPF designer in Visual Studio even. Unlike JS, it was full fledged - you could use anything in WinRT same as C#, extend classes etc, while JS limited you to a "consumer" surface of the API. That prototype was killed because Windows (i.e. at the time = Sinofsky) said they didn't think developers cared about anything but JS so they didn't need another high level language. It was also when Windows was aggressively pushing their Metro styling on everything in the company, sometimes to ridiculous lengths - e.g. Visual Studio at the time "aligned" with Metro by, I kid you not, making the main menu bar ALL UPPER CASE so that it looked like Metro tabs! You can still see the blog posts announcing this "feature" when it shipped in the first public beta of VS 2012, and the comments on them. And then there was Windows RT (not to be confused with WinRT, because Microsoft product naming!). Aka the Windows-on-ARM that ditched decades of backwards compatibility because Sinofsky decided that rebooting the ecosystem is the only way to compete with iPad or whatever. What actually happened was that the users went WTF because none of their native apps - which, contrary to his take, were very much alive and kicking! - worked there, and devs went WTF because they were told that they'd need to rewrite everything yet again in some new thing that was kinda sorta but not quite like WPF, because Windows just hated .NET that much and couldn't accept that the devs liked it over their stuff. So the app store was a barren waste, and without apps there would be no users. Some of the technical details in there are plain wrong, too. For instance, .NET 3.0 actually shipped in Vista, contrary to his claim that it was shipped in Win7 (and that it was the first time .NET shipped in consumer Windows - in fact, that would be .NET 1.1 shipping in WinXP SP1).
- cjbgkagh 7mo ago
  Often kind of person who makes such mistakes is the kind of person unable to learn from them. The post by Sinofsky is exactly as I imagined it would be.
- pragmatic 7mo ago
  How is he dunking on .net? I think one of his main points is server .net was (and is) great. But the UI part of it was cloudy. I see it as complimentary to the post not contradicting it.
  - int_19h 7mo ago
    The UI part is exactly what I meant. WinForms was a godsend for professional developers making line-of-business apps, because previously if you used first-party dev tooling, you either had to deal with the considerable limitations of Visual Basic, or you had to deal with MFC that was low-level enough that all the things that were tedious about Win32 remained tedious. In comparison, Borland had Delphi, and there was a good reason why it was so popular back in 90s and early 00s, and why Microsoft ultimately acqui-hired its main designer specifically to work on .NET (and it very much shows in the design of both C#, which owes as much to Component Pascal as to Java, and of WinForms, which is so similar to VCL). With WinForms, we actually got something that was convenient without shackling you. And the whole cross-language story was great, too, especially around .NET 2.0 - with C++/CLI you could very easily wrap any random native code C or C++ library for consumption from .NET, with end-to-end integration in the build system, IDE etc.
    - ack_complete 7mo ago
      Eh, WinForms did a lot to make Win32 UI accessible and usable -- especially layout and easy customization -- but I have to differ on the cross-language story. It was great, IF you were making primarily a C# program that happened to use some C/C++ components. From the native code side, it was not so great. The .NET 2.0 CLR had very poor support for hosting from the native side and really wanted you to make a program that was .NET first, it didn't work well if you wanted something like primarily a C++ program that hosted a C# UI in the same process. Reverse P/Invoke via native exports wasn't exposed, so creating DLLs for consumption by non-.NET programs was difficult. Mixed mode debugging was and still is painful, with the debugger being glacially slow at some operations like OutputDebugString() processing and blocking some native features like data breakpoints, and the CLR eating access violation exceptions from native code so they couldn't be debugged properly. Build-mode wise, we had to ban C++/CLI assemblies depending on C# assemblies because the C# project system didn't handle incremental builds properly and forced the dependent C++ assembly to rebuild all the time. These issues still largely exist and are an issue with WPF. It's a great UI framework, but it's unusable unless your front end is primarily a C# program.
deleted 7mo ago
[deleted]
CamperBob2 7mo ago
Is there any way to get to the article without going through x.com? xcancel.com just says "Nitter doesn't support this feature yet, but it might in the future."
orthoxerox 7mo ago
I've read this and the relevant chapters on his Substack and I think I get the idea that he tried to implement, but it's obvious in 2026 where his vision diverged from what people really wanted. In the ideal world, Win32 applications would have automatically run in a sandboxed WinRT environment with granular permissions. A program thinks it's accessing a USB webcam, but it is actually accessing a Win32 shim that goes to the WinRT that first prompts the user to obtain the necessary permission and then goes to the real Win32 USB API to interface with the camera. A program is trying to access a file that hasn't been selected in the "Open file" dialog or dragged into it or passed as a command line argument? Raise a "malicious access" warning. Overly complicated programs like antiviruses would have been able to get a "hall pass", either by registering their builds with Microsoft or asking for an administrator-level exception. Of course, this would've been terribly hard to implement. Doing it natively would be supremely complicated, much harder than just designing a whole new userland API like WinRT. And sandboxing every application in something similar to Sandboxie would've been too taxing on the PCs from that time.

Steven Sinofsky wrote this piece a couple of weeks ago about the same topic: https://x.com/stevesi/status/2036921223150440542 https://x.com/stevesi/status/2036921223150440542

deleted 7mo ago

[deleted]

dang 7mo ago

Since that article is a response to this one, we'll add a link to it in the toptext above. Thanks!

markus_zhang 7mo ago
Thank you!

int_19h 7mo ago

It's very amusing to see Sinofsky of all people all but dumping on .NET and (still?!) not understanding why developers so proactively jumped ship from Win32 & MFC hell to WinForms. Or why the HTML/JS app model in Win8 never really took off. I was in DevDiv during his great WinRT push and the overall feeling I remember was that the guys in Windows had zero clue as to what the devs actually wanted, but were hell bent on scorching all the ground that wasn't theirs. My team actually did some prototyping for Python/WinRT support, and we had it working to the point of the visual WPF designer in Visual Studio even. Unlike JS, it was full fledged - you could use anything in WinRT same as C#, extend classes etc, while JS limited you to a "consumer" surface of the API. That prototype was killed because Windows (i.e. at the time = Sinofsky) said they didn't think developers cared about anything but JS so they didn't need another high level language. It was also when Windows was aggressively pushing their Metro styling on everything in the company, sometimes to ridiculous lengths - e.g. Visual Studio at the time "aligned" with Metro by, I kid you not, making the main menu bar ALL UPPER CASE so that it looked like Metro tabs! You can still see the blog posts announcing this "feature" when it shipped in the first public beta of VS 2012, and the comments on them. And then there was Windows RT (not to be confused with WinRT, because Microsoft product naming!). Aka the Windows-on-ARM that ditched decades of backwards compatibility because Sinofsky decided that rebooting the ecosystem is the only way to compete with iPad or whatever. What actually happened was that the users went WTF because none of their native apps - which, contrary to his take, were very much alive and kicking! - worked there, and devs went WTF because they were told that they'd need to rewrite everything yet again in some new thing that was kinda sorta but not quite like WPF, because Windows just hated .NET that much and couldn't accept that the devs liked it over their stuff. So the app store was a barren waste, and without apps there would be no users. Some of the technical details in there are plain wrong, too. For instance, .NET 3.0 actually shipped in Vista, contrary to his claim that it was shipped in Win7 (and that it was the first time .NET shipped in consumer Windows - in fact, that would be .NET 1.1 shipping in WinXP SP1).

cjbgkagh 7mo ago
Often kind of person who makes such mistakes is the kind of person unable to learn from them. The post by Sinofsky is exactly as I imagined it would be.
pragmatic 7mo ago
How is he dunking on .net? I think one of his main points is server .net was (and is) great. But the UI part of it was cloudy. I see it as complimentary to the post not contradicting it.
- int_19h 7mo ago
  The UI part is exactly what I meant. WinForms was a godsend for professional developers making line-of-business apps, because previously if you used first-party dev tooling, you either had to deal with the considerable limitations of Visual Basic, or you had to deal with MFC that was low-level enough that all the things that were tedious about Win32 remained tedious. In comparison, Borland had Delphi, and there was a good reason why it was so popular back in 90s and early 00s, and why Microsoft ultimately acqui-hired its main designer specifically to work on .NET (and it very much shows in the design of both C#, which owes as much to Component Pascal as to Java, and of WinForms, which is so similar to VCL). With WinForms, we actually got something that was convenient without shackling you. And the whole cross-language story was great, too, especially around .NET 2.0 - with C++/CLI you could very easily wrap any random native code C or C++ library for consumption from .NET, with end-to-end integration in the build system, IDE etc.
  - ack_complete 7mo ago
    Eh, WinForms did a lot to make Win32 UI accessible and usable -- especially layout and easy customization -- but I have to differ on the cross-language story. It was great, IF you were making primarily a C# program that happened to use some C/C++ components. From the native code side, it was not so great. The .NET 2.0 CLR had very poor support for hosting from the native side and really wanted you to make a program that was .NET first, it didn't work well if you wanted something like primarily a C++ program that hosted a C# UI in the same process. Reverse P/Invoke via native exports wasn't exposed, so creating DLLs for consumption by non-.NET programs was difficult. Mixed mode debugging was and still is painful, with the debugger being glacially slow at some operations like OutputDebugString() processing and blocking some native features like data breakpoints, and the CLR eating access violation exceptions from native code so they couldn't be debugged properly. Build-mode wise, we had to ban C++/CLI assemblies depending on C# assemblies because the C# project system didn't handle incremental builds properly and forced the dependent C++ assembly to rebuild all the time. These issues still largely exist and are an issue with WPF. It's a great UI framework, but it's unusable unless your front end is primarily a C# program.

deleted 7mo ago

[deleted]

CamperBob2 7mo ago

Is there any way to get to the article without going through x.com? xcancel.com just says "Nitter doesn't support this feature yet, but it might in the future."

orthoxerox 7mo ago

I've read this and the relevant chapters on his Substack and I think I get the idea that he tried to implement, but it's obvious in 2026 where his vision diverged from what people really wanted. In the ideal world, Win32 applications would have automatically run in a sandboxed WinRT environment with granular permissions. A program thinks it's accessing a USB webcam, but it is actually accessing a Win32 shim that goes to the WinRT that first prompts the user to obtain the necessary permission and then goes to the real Win32 USB API to interface with the camera. A program is trying to access a file that hasn't been selected in the "Open file" dialog or dragged into it or passed as a command line argument? Raise a "malicious access" warning. Overly complicated programs like antiviruses would have been able to get a "hall pass", either by registering their builds with Microsoft or asking for an administrator-level exception. Of course, this would've been terribly hard to implement. Doing it natively would be supremely complicated, much harder than just designing a whole new userland API like WinRT. And sandboxing every application in something similar to Sandboxie would've been too taxing on the PCs from that time.