5 ms·

About 7 years too late. This thing should have been drowned in the bathtub when it was called WinRT. An excellent example of the hubris of the Windows division,

About 7 years too late. This thing should have been drowned in the bathtub when it was called WinRT. An excellent example of the hubris of the Windows division, leading to the demise of Windows Phone (and Windows in due course). The genius who convinced Microsoft to throw its weight behind an API completely incompatible with everything they had done before should be lauded for chutzpah. They couldn't have done a better job of destroying Windows, if that was their goal.

eganist 7y ago
Ideologically, I'm opposed to the assertions you've made in these two paragraphs primarily because the bloat and backwards compatibility requirements made innovation more difficult given the diversity of hosts which had to be supported. But I'll acknowledge that I've got a substantial bias here considering I both keenly observed and to a very modest extent contributed to external coverage of the development of the platform reboots conceived during Longhorn/Vista/7/8 (Avalon/WPF, Indigo/WCF, WinFS, WinRT, some of which succeeded, some of which died) and the efforts to shed legacy platforms dating back almost three decades now. Why do you believe what you believe? Citations would be helpful, but I recognize we're discussing opinions.
- muststopmyths 7y ago
  Fair enough. Let me lay this out as a long time Windows developer and someone who loved Windows Phone 7/8 compared to iOS and Android. 1. The first version of WP7 was fine. Silverlight was a pretty mature technology and there was developer interest (at least in the Microsoft ecosystem). 2. WP8 (and Windows 8) came out with WinRT. This was incompatible with existing ways of writing Windows code, so you couldn't bring (almost) any legacy code over. This means that extensive porting efforts were required for code that used to work fine on Win32. This was particularly brutal for open source libraries (like OpenCV/OpenSSL etc.) which were sorely necessary if you wanted to target all 3 mobile platforms. In addition there was a much smaller API surface. Bluetooth LE or VPN APIs for example never came out until too late. You couldn't even create COM ports (necessary for GPS dongles) in a Windows 8 (not mobile, just regular desktop) WinRT/UAP app. So Win32 applications would work just fine on Windows 8, but if you wanted they fancy new features, you were either SOL or had a long development cycle ahead of you. The forced async paradigm also added massive complexity for cross-platform development. They failed to see people rapidly losing interest in Windows (Charles Petzold's Windows 8 book sold so badly, he gave up on Windows for Xamarin. This is the guy who literally wrote the Bible of Windows GUI programming) and take action to remedy that. Instead, they spent time and effort on half-assing "Bridges" which they then rapidly lost interest in and stopped supporting. It's fine to try to shed legacy platforms, but you don't do it at the cost of developer traction, at the very moment when you need them most. They could have done a lot more to make it easier for developers to bring code over. MS OpenTech, for example, was a worthy initiative that again got killed too soon. So, my opinion is that nothing but hubris explains the decision to go down the road of abandoning Win32 at a time when Microsoft needed its developers more than anything else. Having worked at Microsoft way back in the day, I've seen many bad ideas get pushed out, but Microsoft always used to treat developers with respect. WinRT was just a massive slap in the face in comparison. *edited formating
  - _pmf_ 7y ago
    I actually bought this particular book to make sense of the mess (i.e. 80% of the API surface missing), but of course it did not help here. The way to brigde UWP and regular Win32 APIs was described in this utterly kafkaesque document[0], which was the point where I decided that this is a complete deadend. I implore anyone to read it, and remember: this was the solution to a problem that could have been solved by importing a DLL in any sane ecosystem. [0] https://docs.microsoft.com/de-de/windows/uwp/winrt-components/brokered-windows-runtime-components-for-side-loaded-windows-store-apps https://docs.microsoft.com/de-de/windows/uwp/winrt-component...
- lozenge 7y ago
  .NET was available for old versions of Windows, had full capabilities, and could be distributed any way. It caught on. UWP meant dropping support for old Windows, you can't even access the filesystem (open a playlist file? Unzip an archive? Open subtitle files? Nah), and you can only publish on Windows Store which nobody visits. It didn't catch on. I feel for the developers at MS building a platform nobody would use. Until this announcement.
- hyperman1 7y ago
  To be honest, I'm completely of the opposite opinion. Backwards compatibility means I don't have to rewrite anything again and again and again. Compare with gtk, which breaks backward compatibility liberally. After a few versions, old applications stop working unless someone takes the time to fix them. This means application progress is reset again and again. We lose tons of old code for no good reason. OTOH, the old tools written in win95's win32 or in x11's xlib (or posix, mother of all stable APIs), still work 20 years later. This means you can focus on improving instead of rebuilding. Don't get me wrong: Backwards compatibility is a cost. But I'd rather have to pay it once, centrally, instead of distributed over all applications. Very rarely you can deprecate and fix a small part. But in general, libraries are the ground upon which applications are built. That ground should be stable. BTW, I fear the damage wayland will do to the linux ecosystem.
pjmlp 7y ago
I bet it was related to Sinofsky and the whole WinDev vs DevTools political issues that also torpedoed the Longhorn and Midori efforts.

eganist 7y ago

Ideologically, I'm opposed to the assertions you've made in these two paragraphs primarily because the bloat and backwards compatibility requirements made innovation more difficult given the diversity of hosts which had to be supported. But I'll acknowledge that I've got a substantial bias here considering I both keenly observed and to a very modest extent contributed to external coverage of the development of the platform reboots conceived during Longhorn/Vista/7/8 (Avalon/WPF, Indigo/WCF, WinFS, WinRT, some of which succeeded, some of which died) and the efforts to shed legacy platforms dating back almost three decades now. Why do you believe what you believe? Citations would be helpful, but I recognize we're discussing opinions.

muststopmyths 7y ago
Fair enough. Let me lay this out as a long time Windows developer and someone who loved Windows Phone 7/8 compared to iOS and Android. 1. The first version of WP7 was fine. Silverlight was a pretty mature technology and there was developer interest (at least in the Microsoft ecosystem). 2. WP8 (and Windows 8) came out with WinRT. This was incompatible with existing ways of writing Windows code, so you couldn't bring (almost) any legacy code over. This means that extensive porting efforts were required for code that used to work fine on Win32. This was particularly brutal for open source libraries (like OpenCV/OpenSSL etc.) which were sorely necessary if you wanted to target all 3 mobile platforms. In addition there was a much smaller API surface. Bluetooth LE or VPN APIs for example never came out until too late. You couldn't even create COM ports (necessary for GPS dongles) in a Windows 8 (not mobile, just regular desktop) WinRT/UAP app. So Win32 applications would work just fine on Windows 8, but if you wanted they fancy new features, you were either SOL or had a long development cycle ahead of you. The forced async paradigm also added massive complexity for cross-platform development. They failed to see people rapidly losing interest in Windows (Charles Petzold's Windows 8 book sold so badly, he gave up on Windows for Xamarin. This is the guy who literally wrote the Bible of Windows GUI programming) and take action to remedy that. Instead, they spent time and effort on half-assing "Bridges" which they then rapidly lost interest in and stopped supporting. It's fine to try to shed legacy platforms, but you don't do it at the cost of developer traction, at the very moment when you need them most. They could have done a lot more to make it easier for developers to bring code over. MS OpenTech, for example, was a worthy initiative that again got killed too soon. So, my opinion is that nothing but hubris explains the decision to go down the road of abandoning Win32 at a time when Microsoft needed its developers more than anything else. Having worked at Microsoft way back in the day, I've seen many bad ideas get pushed out, but Microsoft always used to treat developers with respect. WinRT was just a massive slap in the face in comparison. *edited formating
- _pmf_ 7y ago
  I actually bought this particular book to make sense of the mess (i.e. 80% of the API surface missing), but of course it did not help here. The way to brigde UWP and regular Win32 APIs was described in this utterly kafkaesque document[0], which was the point where I decided that this is a complete deadend. I implore anyone to read it, and remember: this was the solution to a problem that could have been solved by importing a DLL in any sane ecosystem. [0] https://docs.microsoft.com/de-de/windows/uwp/winrt-components/brokered-windows-runtime-components-for-side-loaded-windows-store-apps https://docs.microsoft.com/de-de/windows/uwp/winrt-component...
lozenge 7y ago
.NET was available for old versions of Windows, had full capabilities, and could be distributed any way. It caught on. UWP meant dropping support for old Windows, you can't even access the filesystem (open a playlist file? Unzip an archive? Open subtitle files? Nah), and you can only publish on Windows Store which nobody visits. It didn't catch on. I feel for the developers at MS building a platform nobody would use. Until this announcement.
hyperman1 7y ago
To be honest, I'm completely of the opposite opinion. Backwards compatibility means I don't have to rewrite anything again and again and again. Compare with gtk, which breaks backward compatibility liberally. After a few versions, old applications stop working unless someone takes the time to fix them. This means application progress is reset again and again. We lose tons of old code for no good reason. OTOH, the old tools written in win95's win32 or in x11's xlib (or posix, mother of all stable APIs), still work 20 years later. This means you can focus on improving instead of rebuilding. Don't get me wrong: Backwards compatibility is a cost. But I'd rather have to pay it once, centrally, instead of distributed over all applications. Very rarely you can deprecate and fix a small part. But in general, libraries are the ground upon which applications are built. That ground should be stable. BTW, I fear the damage wayland will do to the linux ecosystem.

pjmlp 7y ago

I bet it was related to Sinofsky and the whole WinDev vs DevTools political issues that also torpedoed the Longhorn and Midori efforts.