7 ms·

Unfortunate news; though most won't miss it, I will. It was the last smartphone option that avoided both the Scylla of Google's data vacuuming and the Charybdi

Unfortunate news; though most won't miss it, I will. It was the last smartphone option that avoided both the Scylla of Google's data vacuuming and the Charybdis of Apple's pricey walled garden and their "my way or the highway" design philosophy. Plus, the live tiles are actually useful in a smartphone context. Microsoft (and by that I mean both Arbogast and Myerson) was just plain stupid to break app compatibility multiple times between Windows Mobile 6.x and Windows Phone 10. What exactly did they think was going to happen to their app count after pissing off their developer base?

scarface74 8y ago
It’s good to not keep app compatibility forever. When you don’t you get the hodgepodge mess of Windows. Apple has broken compatibility plenty of times and has been able to move its customer base to the new platform.
- mikestew 8y ago
  Apple has broken compatibility plenty of times When Apple breaks compatibility, I have to tweak the Objective-C code I've been toting around for ten years. When Microsoft broke WinMo compatibility, you burned it to the ground and started over.
  - scarface74 8y ago
    Were you around for either the 68K to PPC transition, the PPC to x86 transition or have you had to move from Carbon to Cocoa?
    - craftyguy 8y ago
      Apple was using x86 10 years ago, so I would assume the former..
    - mikestew 8y ago
      I was not writing Objective-C code for any of those on mobile platforms, which is the topic at hand. EDIT: though in rereading your original comment, it's a fair question. Yes, I was around. No, I still don't think it applies. Even considering desktop, IMO Apple made great efforts to make such transitions at least somewhat seamless. In more than one instance, Microsoft's mobile message was: "that app won't run on the new OS without a lot of work."
  - WorldMaker 8y ago
    If you burned it to the ground and started over, that may have also been on you. The amount of code that was capable to run unchanged between 6.5 (CF), 7 (Silverlight-like-CF), 8.1+ (.NET Core) was very high. Sure, there was a ton of churn between 6.5's horrid WinForms fork, 7's Silverlight XAML, 8's .NET Core-ish version of Silverlight-ish XAML, and 10's WinRT XAML, but if the majority of your app wasn't just UI code-behind (at which point, why not rearchitect to a good MVVM pattern or relative?), transitioning that XAML should have been simple.
    - ThrowawayR2 8y ago
      Perhaps he's referring to the Win32-style apps that were the norm on Windows Mobile 6.0 and earlier? There was an huge number of apps (for that era anyway) that were obsoleted by the transition away from that paradigm.
      - WorldMaker 8y ago
        Yeah, it is possible that it could have been written in C/C++ Win32-ish COM. Though Microsoft was never subtle in Windows Mobile <= 6.5 in telling developers they should only use .NET Compact Framework's System.Windows.Forms fork on that platform, as opposed to Desktop Windows where it has seemed far too subtle in their framework recommendations (partly because they were far too divided internally in the Desktop space). As I said, from that perspective, most Compact Framework code should have worked in Silverlight other than UI rewrite because the Silverlight runtime wasn't far from CF. It needed a recompile, but not necessarily a rewrite, in theory. (Though obviously theory and practice are very different things.)
nwah1 8y ago
Regardless of the merits of the platform, avoiding a monoculture itself has benefits such as encouraging open standards. Every competitor platform that has died has harmed the long term health of the ecosystem of open standards. Microsoft's OS itself was not open source, of course, although MS has turned around into a very open source oriented company across much of their stack. However, their data vacuuming is also high as they are hoping to compete with Google. And if you do what they want, and install lots of microsoft apps on your Android or iPhone, then rest assured they will vacuum all the data just like the other guys. Trusting any of these companies on that front is naive.
WorldMaker 8y ago
> It was the last smartphone option that avoided both the Scylla of Google's data vacuuming and the Charybdis of Apple's pricey walled garden Yeah, the December date here confirms what Wikipedia has stated for a while for the RS3 fork's security lifetime. December is actually one bonus month past the expected 18 months. I expect I will continue to procrastinate making a decision until that Holiday season, really. I had an iPhone (3GS) and switching back to iOS doesn't really excite me. I develop some from Android and rather dislike it (though I realize that apps like Microsoft Launcher and Launcher 10 presumably make it more Windows Phone-like than iOS is capable of being), and I still hold a grudge against Google for killing Reader. It's not a decision I look forward to. Two ugly options and not a good reason to pick one, other than "I don't think I want a mobile computer on my person that isn't receiving security updates."
m45t3r 8y ago
> Microsoft (and by that I mean both Arbogast and Myerson) was just plain stupid to break app compatibility multiple times between Windows Mobile 6.x and Windows Phone 10. What exactly did they think was going to happen to their app count after pissing off their developer base? I think the problem was not breaking compatibility between WM and WP, but breaking compatibility between WP7 and WP8. That and being too little too late (small number of apps when both Android and iOS stores were thriving).
- pjmlp 8y ago
  The WinDev and its support by management was certainly a cause for it. Instead of improving the Silverlight + XNA programming models, they just rebooted everything with WinRT, using an incompatible .NET implementation and forcing three implementation stacks (phone, tablet and desktop). Followed by the UAP partial reunification in 8.1, then the UWP reboot.
Const-me 8y ago
> break app compatibility multiple times between Windows Mobile 6.x and Windows Phone 10 They only did once in WP7. After WP7 there were very minor changes in the APIs. They never forced you to rewrite WP7 silverlight to 8.1 WinRT or 10 UWP. They recommended to do so and wrote porting guides, but silverlight remained compatible.

scarface74 8y ago

It’s good to not keep app compatibility forever. When you don’t you get the hodgepodge mess of Windows. Apple has broken compatibility plenty of times and has been able to move its customer base to the new platform.

mikestew 8y ago
Apple has broken compatibility plenty of times When Apple breaks compatibility, I have to tweak the Objective-C code I've been toting around for ten years. When Microsoft broke WinMo compatibility, you burned it to the ground and started over.
- scarface74 8y ago
  Were you around for either the 68K to PPC transition, the PPC to x86 transition or have you had to move from Carbon to Cocoa?
  - craftyguy 8y ago
    Apple was using x86 10 years ago, so I would assume the former..
  - mikestew 8y ago
    I was not writing Objective-C code for any of those on mobile platforms, which is the topic at hand. EDIT: though in rereading your original comment, it's a fair question. Yes, I was around. No, I still don't think it applies. Even considering desktop, IMO Apple made great efforts to make such transitions at least somewhat seamless. In more than one instance, Microsoft's mobile message was: "that app won't run on the new OS without a lot of work."
- WorldMaker 8y ago
  If you burned it to the ground and started over, that may have also been on you. The amount of code that was capable to run unchanged between 6.5 (CF), 7 (Silverlight-like-CF), 8.1+ (.NET Core) was very high. Sure, there was a ton of churn between 6.5's horrid WinForms fork, 7's Silverlight XAML, 8's .NET Core-ish version of Silverlight-ish XAML, and 10's WinRT XAML, but if the majority of your app wasn't just UI code-behind (at which point, why not rearchitect to a good MVVM pattern or relative?), transitioning that XAML should have been simple.
  - ThrowawayR2 8y ago
    Perhaps he's referring to the Win32-style apps that were the norm on Windows Mobile 6.0 and earlier? There was an huge number of apps (for that era anyway) that were obsoleted by the transition away from that paradigm.
    - WorldMaker 8y ago
      Yeah, it is possible that it could have been written in C/C++ Win32-ish COM. Though Microsoft was never subtle in Windows Mobile <= 6.5 in telling developers they should only use .NET Compact Framework's System.Windows.Forms fork on that platform, as opposed to Desktop Windows where it has seemed far too subtle in their framework recommendations (partly because they were far too divided internally in the Desktop space). As I said, from that perspective, most Compact Framework code should have worked in Silverlight other than UI rewrite because the Silverlight runtime wasn't far from CF. It needed a recompile, but not necessarily a rewrite, in theory. (Though obviously theory and practice are very different things.)

nwah1 8y ago

Regardless of the merits of the platform, avoiding a monoculture itself has benefits such as encouraging open standards. Every competitor platform that has died has harmed the long term health of the ecosystem of open standards. Microsoft's OS itself was not open source, of course, although MS has turned around into a very open source oriented company across much of their stack. However, their data vacuuming is also high as they are hoping to compete with Google. And if you do what they want, and install lots of microsoft apps on your Android or iPhone, then rest assured they will vacuum all the data just like the other guys. Trusting any of these companies on that front is naive.

WorldMaker 8y ago

> It was the last smartphone option that avoided both the Scylla of Google's data vacuuming and the Charybdis of Apple's pricey walled garden Yeah, the December date here confirms what Wikipedia has stated for a while for the RS3 fork's security lifetime. December is actually one bonus month past the expected 18 months. I expect I will continue to procrastinate making a decision until that Holiday season, really. I had an iPhone (3GS) and switching back to iOS doesn't really excite me. I develop some from Android and rather dislike it (though I realize that apps like Microsoft Launcher and Launcher 10 presumably make it more Windows Phone-like than iOS is capable of being), and I still hold a grudge against Google for killing Reader. It's not a decision I look forward to. Two ugly options and not a good reason to pick one, other than "I don't think I want a mobile computer on my person that isn't receiving security updates."

m45t3r 8y ago

> Microsoft (and by that I mean both Arbogast and Myerson) was just plain stupid to break app compatibility multiple times between Windows Mobile 6.x and Windows Phone 10. What exactly did they think was going to happen to their app count after pissing off their developer base? I think the problem was not breaking compatibility between WM and WP, but breaking compatibility between WP7 and WP8. That and being too little too late (small number of apps when both Android and iOS stores were thriving).

pjmlp 8y ago
The WinDev and its support by management was certainly a cause for it. Instead of improving the Silverlight + XNA programming models, they just rebooted everything with WinRT, using an incompatible .NET implementation and forcing three implementation stacks (phone, tablet and desktop). Followed by the UAP partial reunification in 8.1, then the UWP reboot.

Const-me 8y ago

> break app compatibility multiple times between Windows Mobile 6.x and Windows Phone 10 They only did once in WP7. After WP7 there were very minor changes in the APIs. They never forced you to rewrite WP7 silverlight to 8.1 WinRT or 10 UWP. They recommended to do so and wrote porting guides, but silverlight remained compatible.