3 ms·

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 & M

by 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.
randomfool 7mo ago
Sinofsky kept talking about how many devs were making apps in JavaScript and how they would just be at home in Win8. This was before React, ES5 (no native classes! or promises!), etc- jQuery was still very popular and SPAs were extremely rare. He completely overlooked how dependent many of these devs were on their servers- Python, Ruby, PHP, etc.
- cjbgkagh 7mo ago
  They thought after V8 the performance was going keep improving and reach native speeds, they didn’t understand that the major performance wins were all upfront and it would hit a wall.
DeathArrow 7mo ago
It seems Windows division has too much power and they used it to break their things. Also, Windows division is shipping a subpar product now. In a sane world developer division and Windows division would think things together, developer division would produce the tools and the same tools would be used by Windows, other Microsoft products such as Office and third party developers. Why that doesn't happen at Microsoft, I don't understand. And I don't understand why Nadella doesn't do anything about it.
- sirjaz 7mo ago
  It's that Nadella doesn't really care about Windows, even though the kernel is the root of Azure. In addition, all the newer gui frameworks abandoned RAD interface. That is what made and still does make Winforms and WPF popular.
pjc50 7mo ago
> making the main menu bar ALL UPPER CASE I remember that. Especially silly. > Windows RT (not to be confused with WinRT, because Microsoft product naming!) The gold standard will always be "Xbox one series X", designed to be confused with Xbox one series S. Windows RT had one other anti-consumer and anti-developer feature: it was locked down like a Chromebook, so you could only use Store apps on it.
- int_19h 7mo ago
  > Windows RT had one other anti-consumer and anti-developer feature: it was locked down like a Chromebook, so you could only use Store apps on it. That was at least in part due to the aforementioned obsession with iPad and generally mobile. One thing that Sinofsky is not wrong about in his post is that the classic Win32 app model is not conductive to good battery life - there's very little there to properly handle things like automatic background suspension or low-power push notifications. WinRT was designed with that in mind, but that would make no difference if the apps would just ignore it, hence the heavy-handed push for WinRT apps only (AFAIR it wasn't restricted to Store, although you had to jump through some "developer mode" hoops to deploy apps directly).
  - ack_complete 7mo ago
    The main reason Win32 can't handle automatic background suspension or low-power push notifications is simply that those features haven't been exposed to it. There's nothing preventing a Win32 program from receiving those types of notifications and then being force-ended by the OS if it doesn't respond in time. When I first started porting programs to Windows ARM64, I didn't have an ARM64 device and had to test in QEMU. It ran extremely slowly, probably 1/50th of real time. All UWP programs like Calculator ran like a slug. But which programs still ran reasonably? Classic WinDbg and Task Manager. Two programs that were still plain Win32. There are significant issues with Win32, namely its lack of a permissions and isolation and lack of hardware acceleration in the old windowing UI (User/GDI). But the idea that Win32 is inherently power inefficient is, IMO, just BS. Its roots go back to CPUs that were orders of magnitude slower than modern CPUs and there is nothing difficult about making a Win32 program that idles at 0% CPU when not in use.
orthoxerox 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. Yeah, he's talking about WinForms like it was a whole new thing, but it was a very transparent OO layer over Win32 and extremely similar both to VB and Borland Delphi. It was one of the reasons why .NET survived at all when Linux servers became the default option.
markus_zhang 7mo ago
I have always been tempted to use WPF but I’m reluctant to learn a whole new language for side projects. Especially nowadays C# seems to be as huge as C++. Oh well maybe I should grit through the beginning phase.
hyperrail 7mo ago
(disclaimer: I was an individual engineer in the Windows division during the Windows 8 project, i.e. reporting through Steven Sinofksy) I think you're being a bit unfair to the Windows division during the Win8 lifecycle. Maybe that's just my rose-tinted glasses though. I know there are some HN/proggit commenters who like to harp on the supposed toxic rivalry between the Windows orgs and Microsoft developer tools orgs and how it has made Windows' developer platform much worse over the years, but I have always thought we had a better relationship than that, since my group's product was the main reason for yours for many years, and your group delivered so much for us in turn. Clearly your side had at least some reason to see things differently. On behalf of all of us, yes even up to stevesi, I'm sorry. Now let me completely undermine my apology by nitpicking your comment :) [continued in my replies to this comment]
- hyperrail 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. At the risk of getting my Microsoft history wrong, I'm fairly sure that Steven Sinofsky wasn't working on Windows or even MFC (i.e. what he did as one of you guys) in .NET's early days of 1999-2003. He was leading Office at that time. Office of that era was transitioning from the Windows XP look that still persists in Windows Forms to the early Ribbon, and was then (as now?) using very custom GUI code that didn't correspond to any specific higher-level Windows app framework. Mac OS Office apps had just separated their codebase again from Windows apps after being unified in the mid-90s to get to feature parity (which annoyed Mac users who felt they now had non-native-feeling apps that were slow and bloated), and the "Office framework" was still quite distinct from any single-platform Windows app as a result of that. So if Sinofsky did not understand why people went from USER/GDI to WinForms, that may just have been the fact that nobody working for him had felt the need to make that transition.
- hyperrail 7mo ago
  > 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. I think the real mistake there was not so much that a particular projection of the Windows Runtime was stopped, but the more general idea that developers should be forced to consume what became known as the Universal Windows Platform or author custom WinRT components through only Microsoft-made WinRT projections. In the name of winning over new or inexperienced Windows developers with "simpler, safer" projections, we in the Windows division almost completely failed for about 5 years to document or even explicitly say that WinRT was essentially just "COM: The Good Parts, Version 2012". (Martyn Lovell's Build talks on the origin of WinRT were a notable exception to this.) This discouraged people from using their existing COM skills to develop Metro-style/UWP apps or to gradually adopt features from UWP APIs that were accessible to them in their existing desktop apps. Other people have written that "WinRT=COM" thinking is actually a bad idea because it forces people to deal with COM and its more annoying ideas (separate IDL etc.); I disagree because we should have reached out to people who live in COM world to get a ready developer base. That mistake was a key part of the still larger mistake you touched on of trying to make the UWP and desktop worlds 2 completely different developer platforms that happen to co-exist on the same desktop edition of the Windows OS. That was the key "we didn't listen to developers" mistake that set up UWP for its market failure. Another example: Even today, you can't adopt the battery-friendly UWP app lifecycle using Windows App SDK, which is supposed to be the UWP successor for desktop app developers. So much for WinAppSDK (or indeed UWP/Metro-style apps in Win8) enabling a true no-compromise user experience. It took real tours-de-force like Kenny Kerr building C++/WinRT and blogging about it, Raymond Chen blogging about using WinRT APIs through the unprojected "ABI" interfaces, or the VideoLAN organization building a Win8/Win10 UWP version of VLC in C, to get the word out that the UWP world wasn't some alien thing with dark magic that only Microsoft wizards had full access to. And it doesn't help that the wizards really do have a few special powers that they jealously guard even now.

by int_19h 7mo ago

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.

randomfool 7mo ago

Sinofsky kept talking about how many devs were making apps in JavaScript and how they would just be at home in Win8. This was before React, ES5 (no native classes! or promises!), etc- jQuery was still very popular and SPAs were extremely rare. He completely overlooked how dependent many of these devs were on their servers- Python, Ruby, PHP, etc.

cjbgkagh 7mo ago
They thought after V8 the performance was going keep improving and reach native speeds, they didn’t understand that the major performance wins were all upfront and it would hit a wall.

DeathArrow 7mo ago

It seems Windows division has too much power and they used it to break their things. Also, Windows division is shipping a subpar product now. In a sane world developer division and Windows division would think things together, developer division would produce the tools and the same tools would be used by Windows, other Microsoft products such as Office and third party developers. Why that doesn't happen at Microsoft, I don't understand. And I don't understand why Nadella doesn't do anything about it.

sirjaz 7mo ago
It's that Nadella doesn't really care about Windows, even though the kernel is the root of Azure. In addition, all the newer gui frameworks abandoned RAD interface. That is what made and still does make Winforms and WPF popular.

pjc50 7mo ago

> making the main menu bar ALL UPPER CASE I remember that. Especially silly. > Windows RT (not to be confused with WinRT, because Microsoft product naming!) The gold standard will always be "Xbox one series X", designed to be confused with Xbox one series S. Windows RT had one other anti-consumer and anti-developer feature: it was locked down like a Chromebook, so you could only use Store apps on it.

int_19h 7mo ago
> Windows RT had one other anti-consumer and anti-developer feature: it was locked down like a Chromebook, so you could only use Store apps on it. That was at least in part due to the aforementioned obsession with iPad and generally mobile. One thing that Sinofsky is not wrong about in his post is that the classic Win32 app model is not conductive to good battery life - there's very little there to properly handle things like automatic background suspension or low-power push notifications. WinRT was designed with that in mind, but that would make no difference if the apps would just ignore it, hence the heavy-handed push for WinRT apps only (AFAIR it wasn't restricted to Store, although you had to jump through some "developer mode" hoops to deploy apps directly).
- ack_complete 7mo ago
  The main reason Win32 can't handle automatic background suspension or low-power push notifications is simply that those features haven't been exposed to it. There's nothing preventing a Win32 program from receiving those types of notifications and then being force-ended by the OS if it doesn't respond in time. When I first started porting programs to Windows ARM64, I didn't have an ARM64 device and had to test in QEMU. It ran extremely slowly, probably 1/50th of real time. All UWP programs like Calculator ran like a slug. But which programs still ran reasonably? Classic WinDbg and Task Manager. Two programs that were still plain Win32. There are significant issues with Win32, namely its lack of a permissions and isolation and lack of hardware acceleration in the old windowing UI (User/GDI). But the idea that Win32 is inherently power inefficient is, IMO, just BS. Its roots go back to CPUs that were orders of magnitude slower than modern CPUs and there is nothing difficult about making a Win32 program that idles at 0% CPU when not in use.

orthoxerox 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. Yeah, he's talking about WinForms like it was a whole new thing, but it was a very transparent OO layer over Win32 and extremely similar both to VB and Borland Delphi. It was one of the reasons why .NET survived at all when Linux servers became the default option.

markus_zhang 7mo ago

I have always been tempted to use WPF but I’m reluctant to learn a whole new language for side projects. Especially nowadays C# seems to be as huge as C++. Oh well maybe I should grit through the beginning phase.

hyperrail 7mo ago

(disclaimer: I was an individual engineer in the Windows division during the Windows 8 project, i.e. reporting through Steven Sinofksy) I think you're being a bit unfair to the Windows division during the Win8 lifecycle. Maybe that's just my rose-tinted glasses though. I know there are some HN/proggit commenters who like to harp on the supposed toxic rivalry between the Windows orgs and Microsoft developer tools orgs and how it has made Windows' developer platform much worse over the years, but I have always thought we had a better relationship than that, since my group's product was the main reason for yours for many years, and your group delivered so much for us in turn. Clearly your side had at least some reason to see things differently. On behalf of all of us, yes even up to stevesi, I'm sorry. Now let me completely undermine my apology by nitpicking your comment :) [continued in my replies to this comment]

hyperrail 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. At the risk of getting my Microsoft history wrong, I'm fairly sure that Steven Sinofsky wasn't working on Windows or even MFC (i.e. what he did as one of you guys) in .NET's early days of 1999-2003. He was leading Office at that time. Office of that era was transitioning from the Windows XP look that still persists in Windows Forms to the early Ribbon, and was then (as now?) using very custom GUI code that didn't correspond to any specific higher-level Windows app framework. Mac OS Office apps had just separated their codebase again from Windows apps after being unified in the mid-90s to get to feature parity (which annoyed Mac users who felt they now had non-native-feeling apps that were slow and bloated), and the "Office framework" was still quite distinct from any single-platform Windows app as a result of that. So if Sinofsky did not understand why people went from USER/GDI to WinForms, that may just have been the fact that nobody working for him had felt the need to make that transition.
hyperrail 7mo ago
> 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. I think the real mistake there was not so much that a particular projection of the Windows Runtime was stopped, but the more general idea that developers should be forced to consume what became known as the Universal Windows Platform or author custom WinRT components through only Microsoft-made WinRT projections. In the name of winning over new or inexperienced Windows developers with "simpler, safer" projections, we in the Windows division almost completely failed for about 5 years to document or even explicitly say that WinRT was essentially just "COM: The Good Parts, Version 2012". (Martyn Lovell's Build talks on the origin of WinRT were a notable exception to this.) This discouraged people from using their existing COM skills to develop Metro-style/UWP apps or to gradually adopt features from UWP APIs that were accessible to them in their existing desktop apps. Other people have written that "WinRT=COM" thinking is actually a bad idea because it forces people to deal with COM and its more annoying ideas (separate IDL etc.); I disagree because we should have reached out to people who live in COM world to get a ready developer base. That mistake was a key part of the still larger mistake you touched on of trying to make the UWP and desktop worlds 2 completely different developer platforms that happen to co-exist on the same desktop edition of the Windows OS. That was the key "we didn't listen to developers" mistake that set up UWP for its market failure. Another example: Even today, you can't adopt the battery-friendly UWP app lifecycle using Windows App SDK, which is supposed to be the UWP successor for desktop app developers. So much for WinAppSDK (or indeed UWP/Metro-style apps in Win8) enabling a true no-compromise user experience. It took real tours-de-force like Kenny Kerr building C++/WinRT and blogging about it, Raymond Chen blogging about using WinRT APIs through the unprojected "ABI" interfaces, or the VideoLAN organization building a Win8/Win10 UWP version of VLC in C, to get the word out that the UWP world wasn't some alien thing with dark magic that only Microsoft wizards had full access to. And it doesn't help that the wizards really do have a few special powers that they jealously guard even now.