The thing about the MS platforms that has always been an issue is that they change the developer APIs around all the time. Every year they come out with the latest greatest way to access a database or whatever and it really isn't that much better than what they had last year, but it still requires a rewrite.

Yes. They also rewrite stuff half way through and tell you it's the same project just to piss you off. Windows Workflow and Windows Communication Foundation for example.

I'm really disinclined to invest in any of their technology because my headspace is finite and I want to deliver business value, not change the unworn carpets once a year.

It's also just such a bad idea because they never get to mature their features, add uniqueness or allow 3rd party devs to build the ecosystem. They just build the same thing over and over again while their competitors keep refining, innovating and adding features. Really a bound to fail strategy

Exactly that.

The feedback loop is shit as well. Out falls a broken pile of shit for a CTP. No one accepts any feedback. It hits RTM, no one accepts any feedback. Two years down the line, the same bugs are open.

You should hear the partner reps wanting to cry when you report a bug in something that you NEED a fix for and are paying support for. You get fuck all other than a registry fix or a hack even if the mainline product is falling to bits across a thousand or so users (which is what happened to us).

Money where the mouth is as well. Typical shit:

https://github.com/Microsoft/SCVMMLinuxGuestAgent/issues/2 -> ignored. Regularly hoses our new VMs deploying windows on SCVMM.

https://github.com/dotnet/cli/issues/3093 -> fuck you go away we're just going to take your data unless you set a magic variable even though no one wants to give it away as indicated by the ticket and there are bugs in the configuration and it causes people massive audit problems.

From the second ticket

> It's only a matter of time before some enterprising journalist looking for a scoop picks up on this. The headlines here are not good: "Microsoft caught with sneaky program to spy on companies"

Let me take care of that...

Edit: Wrote several of germanys biggest tech sites with focus on dataprotection aswell as the german ministry for cyber security with a link to that ticket. Let's see what happens

Excellent, hopefully something positive comes from it. :)

On a similar note if they get back to you, Mozilla is testing the waters with dumb privacy invasion stuff in Germany soon too:

https://www.ghacks.net/2017/10/06/mozilla-to-launch-firefox-...

They're probably across that already though, but if not it might be useful to point out to them. :)

You do undrrstand thus is a one year old issue in a pre-release of .net core 1 (current version is 2.0)?

The issue is well documented and explained: https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry

I applaud your vigilance, but you are a bit late.

Good work - thank you :)

Maybe MS and the FLOSS world aren’t as different as we thought. Look up CADT by Zawinski for details.

Difference is I’m not paying them. We pay Microsoft a metric fuck load of money.

Same here. I can't even imagine how 3rd party tool developers feel. Let's say you have a grid component. In the last few years you had to do a Winforms and several XAML versions( WPF, WinRT, Silverlight and now UWP). The XAML look superficially the same but all have their set of weird limitations and bugs. I am definitely done with Windows desktop.

Wow, imagine someone trying to make this statement 15 years ago...things have sure changed.

Indeed. 15 years ago I kind of enjoyed it. Win32/winforms is still less horrible than the web these days.

Win32 is in no way less horrible than the Web. Win32 doesn't have any device-independent layout, at all. Forget about handling HiDPI sensibly. RegisterClassEx/CreateWindowEx are incredibly verbose. WndProcs are a mess compared to individual event handlers. The mishmash of COM and inconsistently named C APIs is terrible. COM involves a monstrous amount of boilerplate. COM requires you to deal with apartment threading, legacy that exists primarily for compatibility with Visual Basic 6, which is of course no longer supported but still saddles the platform. Creating an OpenGL context with WGL, with the "false context" stuff, is a nightmare compared to WebGL. Memory management is a giant pain to deal with. The GDI APIs are archaic and slow. I could go on…

Yet I would rather take all of that than dealing with Frankenstein CSS/HTML/JavaScript programming, while making sure it is pixel perfect across all browsers and not making use of the OS features and computer hardware that made me buy it in first place, e.g. WebGL 2.0 on DX 12 GPU.

Most of the issues you mention are solved in .NET, WPF and UWP. COM is a breeze to use in Delphi, MFC/ATL, .NET, C++/CX.

Windows is much more than just Win32.

Apparently Windows event system is so bad, that the younger generation re-inventing it in the form of React.

Also Cocoa, UI Kit, Android and Qt are all better solutions than Web.

Despite the populist mindset that programming the web is a shitshow, it’s really not. Tooling these days is pretty incredible and the ecosystem is pretty great when you are found needing - issues get fixed, PR’s get accepted. It’s a much better experience than a 20 year old environment where everything is set in stone, yet bugs and inconsistencies still exist.

The tools and software for traditional windows app programming have long been neglected and the newer ones throw you into a niche — and still don’t provide a cohesive story.

I would much rather pick up react and produce a working product in less time it takes to troubleshoot XAML databindng and styles, for instance. If my windows app needed something like a map component, I can drop one in my macOS, iOS app - the same one baked into the os - and on the web have an assortment of components to choose from — with WebGL support baked in.

Also, there isn’t such thing as a DX only gfx card - it happily runs OpenGL games and apps just fine

> Tooling these days is pretty incredible and the ecosystem is pretty great when you are found needing - issues get fixed, PR’s get accepted. It’s a much better experience than a 20 year old environment where everything is set in stone, yet bugs and inconsistencies still exist.

Try to make a CRUD SPA as fast as a Delphi one, including a nice L&F by default, just with mouse clicks and setting a few properties.

> Also, there isn’t such thing as a DX only gfx card - it happily runs OpenGL games and apps just fine

This statement means you don't have much experience in graphics programming, at least regarding the fun of dealing with drivers and how OEMs classify GPU features.

So if you prefer I will rephrase it as "WebGL 2.0 on OpenGL 4.6 GPU".

Now feel free to compare what it means in GPU features.

Hint, WebGL 2.0 is basically OpenGL ES 3.0, which maps to OpenGL 4.3.

https://www.khronos.org/developers/reference-cards/

> Try to make a CRUD SPA as fast as a Delphi one, including a nice L&F by default, just with mouse clicks and setting a few properties.

Use Bootstrap for the look and feel. The browser's painting stack is far faster than Delphi's '90s style GDI, so you don't have to do anything there.

You love to use the GDI example against native devs, a Win16 technology, long superceded by better alternatives on Windows.

I only used Delphi as an example, because in 2017 the Web is yet to produce anything that approaches it, even Web Components are yet to be fully done.

A RAD tool is much more than just rendering widgets, a simple CRUD application should be doable just by clicking and setting properties, including talking to the database backend.

Speaking of WebComponents, when will Mozilla support HTML Imports?

> Yet I would rather take all of that than dealing with Frankenstein CSS/HTML/JavaScript programming

I wouldn't.

> Most of the issues you mention are solved in .NET, WPF and UWP.

I wasn't talking about .NET, WPF, and UWP. I was responding to the claim that Petzold-style Win32 apps are better than the Web.

> Apparently Windows event system is so bad, that the younger generation re-inventing it in the form of React.

Huh? React is not WndProc.

> Also Cocoa, UI Kit, Android and Qt are all better solutions than Web.

Disagree.

I've written the same WebGL app twice now, once in Cocoa/Objective-C and once on the Web, with a TypeScript and Webpack stack. Once I got over the initial hump of learning the technology, it was a much nicer experience than my experience with Cocoa. TypeScript is a better language for UI development than C++, Java, or Obj-C, and the fact that the browser implementation of WebGL smooths over the issues with OpenGL on Mac was a huge relief.

Petzold-style Win32 apps were already out of fashion on Windows 95.

Apparently others with better knowledge of Web than me, think otherwise about React vs WndProc.

https://bitquabit.com/post/the-more-things-change/

As for your WebGL example, I would have used Swift with SceneKit instead, regarding productivity in native development on Apple systems.

You're assumptions are outdated

Please provide a link to a Delphi like tool for the Web, including components for backend comunication.

Allow me to present: https://anvil.works/

Visual interface editor? Check.

Component-based UI model? Check. (It's all in Python, everything is an object, very Delphi-ish.)

Back-end communication? Check. (One-line RPC to call functions on the server.)

Database integration? Check.

(The built-in datastore runs on Postgres, and lets you do things like delegate views on a table directly to the client. Mix this with data bindings, and you can create CRUD apps with tiny amounts of code. Or you can start importing the appropriate Python libraries and go to town with your favourite DB.)

Thanks for proving me wrong, Anvil actually does look quite good.

That sounds exactly like the state of affairs the moment you pick a JavaScript framework, which was my point.

Yeah... because compatibility here is MUST.

What I find missing, compared to back-in-the-day, is the _maturity_ of that ecosystem.

Win32 has warts on warts, but around the year 2000 the MS development space was a monoculture and the COM-to-GUI story was increasingly mature and integrated.

.Net came along and, on the one hand, positioned MS to be a whole different kind of tool provider (F# on dotnet core on linux in kuberernetes is niiiiice), but they also lost a few hundred man-years worth of local improvements to their platform. This without providing a credible replacement for Win32 ensuring it would be around for decades.

That fracture fractured again with XAML, again losing tons of maturity, and then fractured even further with the UWP/Silverlight/Metro/WhoKnows. I've never been a bigger fan of MS's product line, but can't justify or defend using much on the client other than html for fancy things or standard winforms for deployability.

Most of the legacy stuff continues working long after it's the hot new thing, though.

Until you hit a bug. The one that killed us was we had to deploy a registry fix to 2000 workstations at hundreds of companies because they broke ClickOnce in IE9 and later. It still isn't fixed today. We still have to eat the administrative cost. Over time, that's a shit ton of cash leaked out on a mistake the vendor has made.

Clickonce is such garbage. I'm sorry I ever heard of it.

I can't believe an company so vested in the enterprise market can do such a terrible job of allowing companies to deploy enterprise software. Click once isn't supported in VS anymore, and was always horrible when it came to things like CI servers anyway. Windows 10 store requires running on azure which make it a no go, doesn't allow push updates anyway. The best options have always been third party ones like chocolatey or NSIS, but they are limited as well, chocolatey does not allow push based and NSIS is pretty weird.

19 years after the first release of apt-get and I'm still waiting for MS to give me something half as good.

Click-Once is like... the smartest idea that ever got built by people who have never worked in places that need something like Click-Once.

I am of the opinion that if they had dropped the "use apps over the web" angle and focused on small-medium-enterprise continuous deployment they woulda had a true game changer on their hands... Click-Once dovetails naturally into something like Apples launchpad, its "turn it off and turn it on again" workflow was ideal for 'Sue in Accounting', its simplified publishing model is great for ISVs with lots of customers, and its sandboxy requirements are a natural fit for the way dotnet core is coming together.

And, yeah, that the Windows ecosystem is still worseoff than apt-get forever ago is a) shocking, b) further proof that Richard Stallman was right about everything ;)

the next Windows update adds ClickOnce-like functionality to its app installer: https://blogs.msdn.microsoft.com/appinstaller/2017/09/27/aut...

perhaps doesn't solve your problems yet :)

Wix isn’t terrible. We use that for deploying two products. When I say not terrible it hides a lot of the design by committee ugliness of MSI packages.

Have you looked at chocolatey as a total replacement for apt-get? If you havent, be prepared for eye gouging disappointment! :(

That too!

But it never matures. You are stuck with half-assed stuff in many cases.

...sometimes to the extent where the hospitals in your country get crippled by malware :-/

Basically "Fire and Motion" in a situation where that strategy is NOT to their advantage.

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

Wow that was a great read.

As stupid as [my reply] may sound, thanks. Your comment prompted me to read that, and you were right, it was a great read.

I do get where you're coming from but I have a more moderate perspective.

I mean we can certainly point to examples where that's the case: Silverlight's a classic here, if that term's even appropriate, and then of course there's WP7, 8, and 10, as mentioned by the grandparent. And these are clearly not trivial examples.

Nevertheless, I must point out that large bodies of code I wrote in the mid-noughties are still running substantially unmodified today. What's perhaps interesting is that these codebases are desktop tools, where it can be argued that Microsoft have achieved true mastery (after WPF came out everything notably settled down, and unlike MFC and WinForms it really hasn't been replaced).

It tends to be other areas where the worst of the churn has occurred: web, mobile, database access (how many versions of EF to get it right?). Of course, these are areas that have seen significant growth over the past few years.

Still, even in their worst period Microsoft did not begin to approach the lunacy of framework churn in the JavaScript world.

My pet theory is that this is because the dev tools department at Microsoft is not a pure cost centre with the sole task of improving the platform, they have Visual Studio licenses to sell. If there is any truth in that, we should see a slow decline in "API of the year" as non-subscription licenses (where customers are prone to skip an update when it does not have enough "revolutionary must-haves") are slowly phased out.

    My pet theory is that this is because the dev 
    tools department at Microsoft is not a pure cost 
    centre with the sole task of improving the platform, 
    they have Visual Studio licenses to sell.

This is the single most baffling thing about Windows to me, and it always has been. Why insist on trying to sell Visual Studio licenses, instead of maximizing the amount of software written for your platform(s)?

It doesn't even seem like they're acting in rational self-interest by doing that.

I suppose their rationale is that they give a lot of development tools away for free, and you only really have to pay for the really enterprise-y editions. I guess? Still dumb to me.

MS DOS used to come with a Basic interpreter, if that's what you mean ;)

Later, when the PC platform became what we know today, there wasn't really a channel for free (small f) software except shareware magazines and Microsoft surely would not be seen with that crowd! In those days, Microsoft wasn't concerned with losing the heads and minds to another platform but with losing the revenue to Borland. Since then, more and more has been made available (I still fondly remember laying my hands on the first Windows SDK day came with a free command line version of the MSVC compiler), but it is a culture shift that won't be rushed as long as there are no really pressing reasons.

> Why insist on trying to sell Visual Studio licenses, instead of maximizing the amount of software written for your platform(s)?

For a while now they haven't been doing that. Community editions are just as good as paid ones and before that Express versions were still comparable if not better than open source IDEs.

Licensing their dev toools gives discounts on tools for development which pushes orgs to buy for-realsies licenses.

Partnering with them gives rebates on their dev tools licenses and gives you kickback when you push your customers to buy for-realsies licenses.

VS is just the fishermans hook, the haul are the 600 SQL server CPU licenses you have ticking all day, every day.

> The thing about the MS platforms that has always been an issue is that they change the developer APIs around all the time.

There was a time when MS would detecting the binary name, and change core kernel functionality just to provide bug-compatibility to older versions of Windows. By that time they got an unbeatable market dominance...

That’s because you don’t get promoted there unless you do something new and super complicated. That’s also part of the reason why Android SDK is such a pile of garbage, the other part being they rush half baked shit to market all the time.

In Microsoft's defense, they also tend to support their stuff for a long time. I work with MFC every day. It's 20+ years old and still being developed.

I stumbled over a few bugs in WPF (worked in WPF3.5, would hang in WPF4), which were, for at least 4 years, documented and "WONTFIX" with no acceptable workaround (workaround provided slows things down by a factor of 10 under some circumstances).

Maybe it's fixed with the reinvigorated WPF on Win10. I don't care anymore, but I do caution anyone to ever use any MS Technology younger than 15 years.

I'd say .Net Core is worth considering, but no real UI story as of yet... pretty nice for services though.

OMG. MFC ? You mean Microsoft Foundation Classes ? mmh. that stuff is still supported ? eventhough there was/is all the .NET crazyness. That's actually pretty good of MS. I guess the main question is: how do you in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ?

Maybe there's a cautionary tale about being an early adopter here. I don't know if I would start a new project with MFC, but it was a fantastic decision in 1996.

In a way, I think it's harder to pick technologies today for large projects. It seems like if something isn't new and growing steadily, it's stale and fading fast. What are the tools and frameworks with a long, healthy middle age ahead of them? I'm learning Go right now because there are a couple of web services I need, but I'm not that confident that I'll be able to run the same code for the next 20 years.

Kind of, OWL and VCL were much better technology but Borland's management...

Oh man, I remember those now. You're right - they were better. It reinforces my point about how difficult it is to choose a long-term technology. It feels a little like picking stocks.

Erlang, for instance? Picking up a new shiny thing and complaining that it's not something with a proven track of backward compatibility is not a rational thing to do.

As someone that worked on migrations to Silverlight and then to UWP, I still don't understand why these are seen as such big deals. The APIs were more similar than they were different and XAML is still XAML. (The only big loss from Silverlight was being able to browser-host it, but even then that was probably worth losing for the greater good to avoid terrible plugin websites.) The only thing they really dropped was Silverlight as (an unnecessary) brand name.

If they had semvered the whole thing: Avalon => UWP 0.x, WPF => UWP 1.x, Silverlight => UWP 2.x, Windows 8.1 UAP => UWP 3.x, today's UWP ~=> UWP 4.x, I don't think any developer would have blinked, I feel like we'd have a lot fewer people feeling they dropped support for things... Then again, developers like to complain when their cheese is moved, it could be just like Python 2 versus Python 3 or VB6 versus VB7.

At the mean time we are celebrating 10 years with the same UI engine: https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-o...

The only major thing: added Direct2D H/W accelerated backend to support high-DPI and multi-DPI systems. Yet incremental addition of CSS features.

You couldn't just port from WPF to Silverlight. They took away tons of features. WinRT was even worse. No idea about UWP but I don't care anymore.

That's why I mentioned semver. APIs change all the time, backwards compatibility gets broken. Yes, conversions weren't always straight forward, but often were possible, and there was an evolutionary arc to it all, and a migration story to follow, even when sometimes that story was a bit rougher than anyone wanted.

They couldn't have done that because these technologies are not exactly for the same things and don't have the same features.

Silverlight was mainly for apps embedded in the browser. It was very limited compared to WPF and not meant to replace it.

Similarly, Metro was not meant to replace WPF. It was extremely limited in what you can do. You couldn't build serious desktop apps with that.

The fact that all those technologies use XAML does not mean they're newer versions of the same thing. The difference in APIs is not what matters, it's the difference in what they can actually do and how that makes them different.

The family tree seems pretty clear to me, yes, Silverlight was a sideways jag, but it wasn't originally "just" for embedding in the browser, it was a cross-platform WPF subset. (In the family tree both WPF and Silverlight, sometimes codenamed WPF/E for Everywhere, split from different goals of the original Avalon project.)

I think you can tell that WinRT/Metro/UWP was/is meant to replace WPF. It used to be extremely limited, but A) had a bigger cross-platform reach that WPF (ARM is/was a big deal), so started with the cross-platform subset, B) was essentially "Win64" from scratch so had a lot of pieces to build.

Starting next month-ish UWP supports .NET Standard 2.0 and the hard work of the re-convergence of classic desktop .NET and cross-platform .NET APIs has happened (huzzah), and it will be a lot harder to argue that UWP is "extremely limited" compared to WPF because 70% of NuGet will just work.

You still don't have a clear path forward from WPF. I don't understand why they even needed UWP. Why not improve WPF?

I think .NET Standard 2.0 is about the clearest path you could get forward from WPF.

> I don't understand why they even needed UWP. Why not improve WPF?

The short story: 1) To first-class support more platforms/architectures (ARM). 2) To support C/C++ and other COM developers, bringing everyone COM [WinRT] [1] and Managed (.NET) to the same table. (Microsoft still has a lot of teams invested in C/C++; it shouldn't be a surprise that they couldn't just focus on .NET and leave C/C++ devs behind.)

The full story I think is pretty fascinating, but that's the executive summary.

[1] Crazy aside: the tech still sort of known as WinRT is closer to the original goal of .NET as a COM replacement than .NET became. It's also close enough to COM that I'm still surprised no one's admitted to building a UWP Delphi or VB6 app. (Not that I'd admit to doing so if I built such a beast.)

That's a very charitable explanation that I find hard to accept. I think it's more that MS .Net development is organized in way that it's easy to do new stuff but hard to maintain an effort long time. In other areas they are able to make progress without breaking everything all the time. C# has stayed backwards compatible while still moving forward quickly. SQL server doesn't release a new version every 2 years that breaks old stuff.

Somehow they seem to lack leadership.

Keep in mind that .NET Core is almost the same .NET runtime/framework (little-f) that powers UWP. It's been a huge hurdle across the board, web and desktop alike. I'm sure if the .NET team had had a magic wand to shrink the .NET Framework (cap-f) down to a smaller size and remove all the legacy Win32 code without breaking so much compatibility they would have.

It's easy to say in hindsight that they should have tried for something like what .NET Standard 2.0 is today earlier, but I, at least, can't blame them for attempting to try to clean house and remove terrible dev experiences like AppDomains and DataTable. Those APIs are terrible and should have died.

But again they have no upgrade path. They just produce something new and expect everyone to jump on board. My expectation is that UWP will last 2-3 years and then they will have something else that does the same but in a different way and UWP is in maintenance mode.

You may be confused. .NET Standard 2.0 support for UWP means the upgrade path is (finally) here today. Start a UWP project in VS 2017.4, make sure the project targets the Fall Creator's Update (the Windows 10 feature update to be released at the end of this month), and from that UWP app you can now add a reference to almost anything on NuGet you want. .NET Standard 2.0 support means that if it ran on the .NET Framework 4.x, it likely runs on UWP now (with rarer but obvious exceptions like using old WPF or WinForms libraries, some of which will still "work" as no-ops not actually doing anything).

Again, I'm not sure how much clearer of an upgrade path you could want? If you have a WPF app today, everything but the XAML will work in Fall Creators Update UWP. The XAML may even be trivial to convert to UWP XAML, they are related like family.

Wait so are you saying UWP apps can now access the machine they're running on in a sane manner (so, limited only by the privileges of the user who ran the app, without additional limitations enforced by the platform itself)?

Because that was the main limitation of Metro apps, you couldn't really do anything useful with them, you couldn't even access the hard drive normally or edit the windows registry. This is why you couldn't "upgrade". It wasn't an upgrade to any previous tech, it was a downgrade as the platform literally had less capabilities. It is, or at least was, basically a platform for making sandboxed mobile apps that you can run on the desktop...

This is why they clearly weren't (at least Metro, I haven't worked with UWP) an "upgrade" to anything. Silverlight wasn't an "upgrade" to WPF for the exact same reason. It was a more limited platform and you couldn't switch WPF apps over. So MS calling Silverlight or Metro a new version of WPF would have been retarded.

Things are still sandboxed, but the sandbox has grown a lot since early Windows 8 ("Metro" era). Depending on your definition of "sane", it seems rather "sane" to me to have at least some sandbox protection of the applications to run. Yes, Windows 8 felt like a straight-jacket more than a sandbox to some, but current UWP, especially with .NET Standard 2.0 support in the FCU, at least builds with most of the libraries even if some of them are essentially no-ops or (security) exceptions at runtime.

So, you still can't touch the registry by default, but why would you want to? There are much better places to store stuff.

The UWP is meant to be a replacement for Win32, so it shouldn't be a shock that a lot of Win32 components aren't available by default.

However, you can use the Desktop Bridge and request permission in your app manifest for more privileges, including things like registry access. The Desktop Bridge has a lot of examples out there on things you can do. You can use the Desktop Bridge to transition a WPF app slowly to UWP over time. For instance, you could launch UWP screens from your WPF app, allowing you to move piece-at-a-time if you wanted. There are even samples on how to migrate settings currently stored in the registry (ugh, why) over to Local AppData storage like a proper application, to transition away from Win32 bad practices. (Of course, the parts of the application that need the Desktop Bridge will only work on Windows with a Win32 subsystem.)

There was no migration story. Usually an API gets more features but in this case they took away a lot of critical stuff. A lot of us write applications that need the full power of the OS and not just a small arbitrarily chosen subset.

These frameworks are by no way equivalent. Silverlight was running on multiple versions of Windows and Mac OS. It should have being kept just for that awesome feature.

On the other hand Win8/10 apps don’t run on anything than the OS they were released on. Which is totally laughable because it means choosing the MS stack allow one to target less Windows OSes than third party tools. So these SDK were doomed from the beginning as thay couldn’t leverage the existing Windows userbase.

> how do you [know] in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ?

If it is old, it will be supported for a long time. If it is new, the odds are mostly on it not surviving. Ever wondered why so many people insist on using outdated stuff?

You get a better deal from open source. But even there you may not like the possible consequences of using non-mainstream things.

They support the stuff they can't kill for a long time.

You can still run VB6 apps but try running a .net framework 1.0 app!

Easy, just get the runtime from here.

https://www.microsoft.com/de-de/download/details.aspx?id=162...

I'm not sure it requires a rewrite, the old stuff still works. The trouble is the constant churn is draining, I've pretty much abandoned the platform because of it. We keep hearing about new JavaScript frameworks but we had exactly the same from MS: win32 => MFC => WTL => VB => WFC => Winforms => WPF => Metro => UWP, no doubt there is something else just around the corner.

Calling that "constant churn" is a massive exaggeration. First, using WTL or WFC were just bad decisions because those were side-projects and MS never told companies to switch to that and definitely didn't encourage rewrites into that. They were not replacements of anything by any stretch of imagination. That's like complaining that MS made you rewrite your app in Lightswitch or IronPython. It is just a side-project, not something ever intended to become the main MS dev stack.

So realistically for most MS stack devs it was MFC -> VB -> WinForms -> WPF -> Metro -> UWP. And MFC was released 25 years ago. So they switched 5 times in 25 years. You could possibly add Silverlight in there (which is extremely similar to WPF so only half-counts for churn purposes).

Now, I agree that the Metro -> UWP part was unnecessary because they were doing the same thing twice so they should have gotten it right the first time (and I think the whole UWP concept is worthless anyway).

If we look at MFC -> VB -> WinForms -> WPF, all those technologies provided a lot of value to us and it was very useful to have them. Would you want to still be programming in MFC today? I am pretty sure you wouldn't. I do not feel any "churn" from this (note: I never switched to Metro/UWP because I considered it a step backwards, unlike the previous "switches", so I stopped at WPF when it comes to desktop), I can barely remember programming in VB 6.0 because it was such a long time ago.

Saying that's "exactly the same" as the situation with web is ridiculous.

Your 5 times in 25 years suggests an overhaul every 5 years. Context matters. WPF became mainstream in 2007

WPF, Metra, UWP, and Silverlight in 2007 -> 2017 is 4 overhauls in 10 years or an overhaul every 2.5 years.

Also not fixing bugs in earlier tech creates a compulsion to switch to the next tech.

metro/winrt -> uwp wasn't really an overhaul, it was just a new name for the next version of the same thing more or less.

Microsoft used to only make money selling software licenses. This has changed with Azure cloud stuff, but the majority of their incentives still don't align with their developer/customers.

With Azure they can bill you for the licenses and the computing platform, while also ensuring a pretty impressive degree of lock-in once the platform is sold.

Not only are their incentives still out of alignment, the massive consultant eco-system they maintain is still incentivized to push the same-old lock in in a new costume.

SOAs are like partners in bed... it's not just about who you're sleeping with, you gotta think about who they have slept with too.

Picking Apple as an example, other are possible.

Object Pascal, Powerplant, Quickdraw, Java Bridge, Quicktime, QuicktimeVR, Carbon, OpenGL, ...

Apparently only Microsoft does it.

This is exactly what made me quit desktop development on Windows. MFC, ATL, COM+ learning going to waste was a bridge too far.

There's a semi-contradiction in your post that I think speaks to some of the issues MS had:

"It started with windows phone 8 and the Metro UI. Bad Idea. The UI was too far away from Android/iPhone to be easily ported "

"half-baked half-assed phone plattform that at no point had even a single feature that wasn't available better on iOS and Android"

As someone who played around with WP7 when it first came out, I'd argue that the Metro UI was the best one available at the time. But the side effect of that is that it was different, and difficult to adapt an existing app to.

Essentially, MS needed to make a bold new platform with inventive new features, but also make the platform very compatible with the other major mobile platforms. You can't easily square that circle. Now, MS also messed up in a million and one ways (like my phone never getting a WP8 upgrade...) but I think their fundamental challenge was very, very difficult.

My wife had several Windows Phones in succession.

Her use of a phone is very practical: contacts, texting, weather information. All of this was available at a glance in a much much better way than either Android or the iPhone have. It was a better business UI.

It was harder to use if you had many apps. But seriously, having a phone open to the equivalent of Windows 3.1's Program Manager (which is what Android and iPhone deliver) is not great!

The iPhone opens to something like the Program Manager (but with little numbers showing which apps have active notifications).

Android opens to something like a Desktop, with some combination of Widget apps and/or app shortcuts. Mine is configured to show a clock, mini calendar, and weather. Incoming e-mails, SMSes, or other messages are visible in the notification bar. I could configure it to show me little previews of messages, but I chose not to.

Android has supported home screen widgets and activity shortcuts since forever. Live tiles are hardly better, they're just a very Metro-y approach to the same feature.

There used to be a homescreen replacement app for Android called SlideScreen [0] (homepage is active, but the app is abandoned) that would try to give you as much information at-a-glance as possible.

[0] http://slidescreenhome.com

Thats imo no contradictions. Metro did things different but in no way better and felt severly restricted compared to android/ios ui design at the time. They banked on having everything look the same in the whole OS but never considered that certain apps just straight up wouldn't work with the metro UI concept.

> that at no point had even a single feature that wasn't available better on iOS and Android

According to the dates[0] I found online says Windows was the first to have a feature that would automatically connect to your cellular connection if the Wifi didn't work. Most consumers don't care but it is something I was surprised iPhones[1] and Android[2] didn't have at least at the time. In addition continuum is unique/better in many ways although that is more recent. It has been a while since I have used a Windows Phone.

[0] Windows 8.1 definitely had it in 2014 according to this https://support.microsoft.com/en-us/help/10652/windows-phone... I'm pretty sure Windows Phones predating this also had it although documentation seems lacking.

[1] Wi-fi assist was introduced in iOS 9(2015). https://support.apple.com/en-us/HT205296

[2] There are apps for Android that do this but at least this one is 3rd party. No sources says it predates 2015. I have not experimented with this on Android. https://www.guidingtech.com/54831/get-ios-like-wi-fi-assist-...

> first to have a feature that would automatically connect to your cellular connection if the Wifi didn't work.

Huh? Maybe my memory if failing me, but that's how networking on iOS always worked.

Previously to iOS 9 if you had a solid WiFi connection but were stuck in the LAN for some reason (broken DNS or captive portal, no WAN connection, broken route or whatever not affecting the LAN segment) you were toast and had to turn WiFi off. WiFi Assist solves that.

Perhaps he is referring to the long-standing habit of iOS to NOT drop the wifi until way out of range which would lead to an awkward hang. I think they fixed that in the last year or two, but it was pretty damn annoying.

> According to the dates[0] I found online says Windows was the first to have a feature that would automatically connect to your cellular connection if the Wifi didn't work.

This is the most infuriating feature ever. Google implemented it in 2014 in Android, and you couldn't properly disable it. Not even today.

I frequently need to connect to intranets where Google services are blocked for security reasons, and it's infuriating to fight hundreds of times with the settings so you can get the WiFi to work.

Then in my opinion it sounds like it is still not "properly implemented" with a toggle. Thank you. I have always been curious about Android. I do agree it's probably better not to have this feature by default then to have without a toggle. Just depends on use case.

Oh, they have a toggle. They've just changed it every time, and broken it in subtle ways every time.

Now they've introduced this "Mobile data has run out" which stops me from accessing my telco's app to check my prepaid balance, because it completely cuts off all mobile data. Just as annoying.

> If I recall correctly Windows was the first to have a feature that would automatically connect to your cellular connection if the Wifi didn't work. Most consumers don't care but it is something I was surprised iPhones and Android didn't have at least at the time.

I remember having an app on android that did that long before windows phone had it. It was able to turn on/off your wifi based on your location. Great battery saver.

> In addition continuum is unique/better in many ways although that is more recent. It has been a while since I have used a Windows Phone.

Samsung cloned it for their S8 Series and it seems to be actually usable from the start compared to windows continuum. Though by the time continuum was available, wp was dead.

> I remember having an app on android that did that long before windows phone had it. It was able to turn on/off your wifi based on your location. Great battery saver.

That is technically different although similar. I have updated with dates. Windows Phone definitely appears to have been first in this scenario unless you count rooted devices which may have something I don't know about.

> I found online says Windows was the first to have a feature that would automatically connect to your cellular connection if the Wifi didn't work.

If the wifi doesn't work, no phone will use it. If the wifi is BAD, that is completely different.

I am implying an inconsistent wifi with speed or LAN issues. The wifi goes down all the time at my house because of Spectrum/time warner cable issues. My iPhone prior to Wifi Assist will use the network at my house if it has a good wifi connection regardless if was broken or just slow.

I had the same experience while working on WP in 2012-13.

In early 2013, I reported a bug when some of the elements inside LongListSelector would disappear randomly on scrolling. LongListSelector is WP’s counterpart for iOS’s tableView.

So I started a discussion on Microsoft forums on this bug. Someone from Microsoft confirmed this bug.

I tracked this bug for 9 months. And guess what they never fixed it. They never fixed a critical bug in the most used UI component of mobile apps.

> it finally looked like the UWP Plattform might do the trick. Well nope. The SDK is garbage. Scaling from phone to desktop is hidiously bad and afaik still not solved.

A lot people tell me Xcode is garbage, Eclipse is a nightmare, but these apps keep getting cranked out. The Android / iOS language and platform api's are SNAFU, but people get still get into the IDE and start making, without any promise for a set of conversion-frameworks + XML files that will make the app for All The Things. At the rate an app builder is adding features, the universal-platform paradigm is cognitive overload.

I think a No-XML based approach to app development, similiar to VB6 / VBA, would have been greatly appreciated. If MS gives me a stable API to an email client, a calendar, a shared drive, and a messaging or video chat service, I'd spend the 5 hours to automate a 5 minute inconveneince. A windows phone with a bunch of "lifehacks" apps would tremendously useful to much of the smartphone market, as long as they had the cant-live-without-apps too.

> A lot people tell me Xcode is garbage, Eclipse is a nightmare

Xcode is absolutely sits at the bottom of the IDE rankings, but Eclipse shouldn't even be a concern for Android devs.

Android Studio is a very nice IDE and no Android dev should touch Eclipse ever again. It's a shame it's tied to the Android platform, honestly.

I'd kill to have Android Studio's functionality when developing for iOS. (And no, AppCode doesn't make the cut)

> It's a shame it's tied to the Android platform, honestly.

It's not, it also supports Java, C++/C/ObjC, Go, Python, PHP, JS, and many more. Find the other Jetbrains IDEs at https://www.jetbrains.com/

Android Studio is a fork of InteliJ, you cannot use it as InteliJ, because the options are tailored for Android,

If you use InteliJ with Android plugin instead, then you will always be behind the curve of the actual Android development, as JetBrains catches up.

How is it a fork of a closed source product, and how is the developer of said closed source product behind the curve of their own product?

Ever heard about cooperation and developer agreements between companies?

IntelliJ isn't closed source, it's on GitHub, under an open license. As are most of the premium IDE plugins from JetBrains.

Only the community edition code.

Plus 90% of the addons.

Only a handful of them aren’t.

So how do you compile the add-ons that require the closed source part?

You don’t, you don’t need them, and Android Studio doesn’t include them either.

You can have all the features of Android Studio in all the languages I mentioned just with the open plugins.

No, because Google has changed the way wizards work, which means any plugin needs to be developed explicitly for Android Studio as well.

As proof of this, the Flutter team just released a version of their plugins for Android Studio.

https://groups.google.com/forum/#!topic/flutter-dev/D6pvqM09...

Android Studio also includes bits of CLion for example.

Are you deliberately trying to ignore what I’ve been saying?

My argument was that you can take IntelliJ’s open edition, with its plugins for C++/C, etc, slightly modify it, and get the same functionality as you’d have in Android Studio for more languages than just Android.

No you are the one ignoring what I am saying, as apparently you are not doing Android development.

1 - InteliJ Android plugin is not the same as Android Studio, it lags a few versions behind;

2 - The free C and C++ plugins are not the same as the parts from CLion that Google integrated into Android Studio;

3 - Additionally the mixed Java/Kotlin and NDK debugging is also taken from CLion

So if you want to be behind the curve of what Android developers use daily, by all means use pure InteliJ with the plugins you are suggesting.

> No you are the one ignoring what I am saying, as apparently you are not doing Android development.

Great, you could’ve checked my profile, or googled who I am, but apparently you didn’t. Spoiler: I do. A lot.

> 1 - InteliJ Android plugin is not the same as Android Studio, it lags a few versions behind;

Which is irrelevant, because Android Studio itself is also splittered into several versions, and many devs simply use the beta, and others use IDEA directly, and yet others simply copied the plugin over.

The plugin in IDEA Ultimate is up-to-date with the latest stable version of Android Studio, btw.

> 2 - The free C and C++ plugins are not the same as the parts from CLion that Google integrated into Android Studio;

No, but they differ insignificantly, I’ve been using both options daily, and both work just the same and fine.

> 3 - Additionally the mixed Java/Kotlin and NDK debugging is also taken from CLion

That’s something I don’t know anything about, as I mostly use a custom solution for that purpose.

Ok, fare enough. You win. :)

It’s true that there are major differences between 3.0.0-beta6 and IDEA-CE, but 2.3.4 and IDEA-CE are basically the same.

And the open C++ plugin is actually the same that powers CLion (if you have CLion installed, I recommend looking at the plugin list)

> Then came windows 8.1 and windows desktop 8 which was universally hated. The whole fullscreen apps debacle was just horrible and all the unnecessary restrictions on store apps for desktop made no one ever consider porting their desktop app to a store app. The whole phone and desktop app in one was a joke aswell since it was (and still is!) horrible implemented. Did I mention they broke compatibility from 8.1 to phone 8? I didn't even bother starting all over again for windows 8.1 i just straight up skipped it.

What was so horrible about it? I almost invested in a surface just off the strength of the UI; I rather liked that they were trying to merge desktop and tablet. Why was the experience so bad?

Windows 8 "metro" UI caused an uproar for many reasons, some of the biggest ones being:

- the start menu covered the whole screen

- applications could only run full screen, even the simplest ones. You literally couldn't have 2 applications on the screen at the same time.

- it was hard to close applications

- it was very difficult to find the shutdown/reset/etc options

- the metro versions of "default" apps looked bad and were vastly inferior to the "old" versions. A lot of system settings ones had this problem, too (not relevant to the average user, but I use a VPN that is impossible to set up to work in the simple "metro" VPN app, but if you find and start the old win7 app which still exists, you can set it up correctly and you can even connect to it from the "metro" VPN app after that)

- a lot of computer games that worked on 7 didn't work on 8 (likely unrelated to metro UI but still a reason for many people not to update)

Some problems were fixed in Windows 8.1. In Windows 10, most of these things are fine (although Win10 gets hate because of its update system and because it installs unwanted apps, but it seems to have much more acceptance overall).

Windows 8 basically offered nothing to the average user except annoyance so people didn't want to update. It had a very nice improvement for developers in the form of Hyper-V, which is the only reason I upgraded, and only after 8.1 was released.

The root problem with Windows 8 UI was that it was clearly not designed with the intention of being a better desktop UI. It was designed with the intention of forcing users to get used to the Windows Phone-style UI on their desktop computer, in hopes that they will then buy Windows Phones out of familiarity. Basically desktop Windows had to "take one for the team". We can see here how much that helped WP.

Personally I remember the biggest pull to windows 8 for me being Games that ran on both 7 and 8/8.1, seemed to perform alot better on 8.1; they didn't advertise that it was a preferred OS or that it was designed for it.

I suspect it was related to streamlining by removing the oldest backward compatibility features, as the only apps that broke were those that ran on windows XP, most frequently they were games that weren't programmed with Vista+ in consideration (often because it didn't exist when originally released).

I specifically remember a bunch of games capping at about 20 FPS on Windows 7 and going 60-100fps on 8 when it was new using my nVidia Quadro SLI setup at the time, and having no luck finding anyone else report this on google (likely because so many people weren't giving 8.x a chance so they didn't notice).

I actually loved 8 and thought that 8.1's gui was a step backwards, the gui was extra easy to use and originally had me going back and forth between windows 7 and 8 when the performance difference eventually won me over completely as my default environment. I still kept 7 installed on another drive for the infrequent use of incompatible apps.

The biggest frustration, to me, is that WPF was basically left on the vine while they pursued this WinRT stuff.

I think the evolutionary path connecting WPF and "this WinRT stuff" is extremely clear and if you've built WPF you can build UWP. UWP .NET/XAML is great to work with if you know WPF, it's truly a successor to WPF in every way. (It'll be even better soon [as in next month] thanks to .NET Standard 2.0.)

That may be so, but WinRT comes with a bunch of limitations, so there isn't really a no-brainer choice for application development, and also, considering how deeply it's associated with the unpopular Windows Store app and Windows phone, who wants to throw in their lot with it? Frankly it hasn't seemed worth investing that much time into any of them and I pretty much just end up reaching for yet another WinForms MVP app. But WinForms practically works against you in the effort to separate UI from behavioral code so that isn't that satisfying either.

Limitations change as API priorities shift. The platform has grown over time. Some inherent limitations are useful (to be a medium to creativity, to the user's control over their system overriding a developer's narcissism, to the idea that security and reliability are worth engineering for), and yes, unlikely to disappear entirely.

I can't dispute the unpopularity of Windows Phone, but from what I hear the Windows Store is fairly successful in Windows 10. Many consumers use it to install apps, which is a judge of popularity. However, if by popularity you instead mean sentiment, then I get the impression that currently most people are ambivalent about the Store in so far as it is a pragmatic tool that people neither love nor hate, just as most people neither love nor hate their toaster so long as it toasts. (Certainly there are haters, but volume of their voices is not necessarily an indication of their size/number/consumer spending activity per the first definition of a popularity, just a reminder of the passion with which they feel their sentiment.)

> from what I hear the Windows Store is fairly successful in Windows 10.

Here's one data point for you. Windows Store used to have an official Kindle app. It doesn't since the end of last year, because Amazon basically said they don't see the return on that investment. They now recommend their desktop Win32 app if you want to read Kindle books on Windows.

Needless to say, iOS and Android do have well-supported Kindle apps.

You can find all kinds of anecdotes on both sides. Facebook's app was built by Microsoft for years because Facebook had zero interest in Windows phone/mobile, but download counts in the Windows 10 store on PCs/desktops/tables pushed them to build React Native for Windows 10, they now officially control their own app, and it's been keeping decent pace with iOS and Android these days.

(As a kindle user, I too am extremely disappointed Amazon developers haven't yet build a modern kindle reader for Windows 10 and cling to their Windows 7-targeted Win32 apps for now. The Silverlight-based app they built for Windows 8.1 I still use sometimes, and it is woefully out of date with the features of most of their other apps.)

One of the key issues for me purchasing on the Windows Store is that my purchases my disappear at any moment. I have had half of my purchased apps disappear.

And it is next to impossible to get a refund.

Last week I noticed that my purchased music on Groove has disappeared ahead of the end of year termination of service.

This sort of happened to us at our work - a developer pulled an app from the store and we needed to install it on other machines internally, but there was no way to do so without going through the store. So it left us totally screwed after paying licensing fees.

I'm still maintaining a WinForms app, the only problem I've had is dealing with high dpi displays is really messy.

The biggest pitfall on a project you work on with other people is how much it tempts you to just put all the behaviors into the code-behind of the form.

The problem with UWP is that it requires Win10. This makes it a no-go for vast majority of developers targeting desktop Windows, given that Win7 is still dominant, and will be for a while to come.

Why MS didn't create a UWP emulator or wrapper for Windows 7 is beyond me. No Windows 7 compatibility is the main reason my company isn't bothering with UWP for our desktop software.

It's the same problem that you have, isn't it? You don't want to support two codebases, you just want to build your app once and have it run in two places. It costs time and development budget to maintain two different codebases, and you have to prioritize. Can you really blame Microsoft that they don't want to maintain both a modern codebase and a completely separate fork/back-port of it for a much older branch?

That said, it has been possible to share a lot of code (if not almost all of it) between a WPF and UWP app for a while now with PCLs, or after that targeting .NET Standard. That gets even easier once UWP support for .NET Standard 2.0 ships soonish. There's also been work recently on Xamarin.WPF for Xamarin's cross-platform code sharing, and the XAML Standard 1.0 work trying to converge much of the XAML across all the platforms Xamarin supports and UWP to get rid of a some of the dialectal nuances.

Maybe because Windows 7 lacks the sandbox features required?

That's a good argument for not having the app store on Win7, but APIs are a separate matter. If UWP API could be used to write something that is both a store app on Win10, but can also be deployed (let's say, in a manner similar to Electron apps, with the runtime packaged with the app) on Win7, I think we'd see a lot more of them. Even if you had to build it separately, so long as most of UI code could be shared, it's a boon.

As it is, it's easier to just target WPF.

All new APIs introduced since Windows 8 are mostly UWP ones, so basically you are asking for implementing Windows 10 on top Windows 7 kernel.

Yes.

And I know it's not an easy thing. But if e.g. the resources that went into Windows Mobile were spent there instead, I think the ecosystem would have been much further ahead, and we'd actually see more useful UWP apps.

It's a green field versus brown field problem. Windows Mobile was/is a green field where the only competition was exterior. Whereas UWP has to compete with Win32 on the desktop and tablet.

It's easy to armchair quarterback hindsight and wonder if they spent too much money in the green field, but it should be reasonable to see why the green field looked so appealing at the time.

It's also easy from 2017 to forget the real, hard, brown field battles that Microsoft did fight, particularly as Windows 8 and Windows 8.1 slowly become "forgotten" versions of Windows like Vista before them. Almost all of the missteps in Windows 8 that people yelled at Microsoft for direct consequences of building the UWP out and trying to make it competitive to Win32. Some of the features like the Charms were attempts to give the UWP some platform-wide features that would have really differentiated it from Win32, but found they added confusion because they weren't easily portable back to Win32, and that is just one example out of many. Brown field work is hard.

I don't get the impression that the green field work Microsoft tried in mobile ate resources that would have been better spent on the brown field work on the desktop. Win32 has such momentum at this point that had Microsoft thrown more resources at Windows 8, trying to bring UWP further ahead faster they might have only gotten more backlash from Win32 fans, and arguably there wasn't a much better plan for desktop than the uneasy truce between the two platforms/subsystems that Windows 10 is/has become.

If they had built a "UWP subsystem for Windows 7" at the time of Windows 8, people would have asked for it for the last remaining months of Windows XP. Asking for a "UWP subsystem for Windows 7" today is a bit like asking for that Windows XP subsystem. Windows 7 is feature complete; it may have security support for a bit longer, but it's out of support for new Windows features (it ended mainstream support in 2015; it ends extended support in 2020). It's now two released versions behind (8, 10) and more versions behind if you count "service packs" (8, 8.1, 10 (1506), 10 1511, 10 1607 (AU), 10 1703 (CU), and the new one (FCU) coming later this month/early next month).

Honest introspection: if you are a developer and someone asked for a feature to be backported to a version from 7 years ago that is 6 major versions back, would you support that or would you encourage them to pay for your hard work and upgrade to something more recent that already has that feature?

It's not just that the work is hard, it's ignoring years of hard work that you've already done.

It occurs to me that a lot of it is really the sunken cost fallacy.

(by the way, do check my HN profile...)

That's pretty much the summary of what I was trying to convey. It's fascinating how developers get stuck in it on one side ("we have to stick to this old version of Windows because IT has put so much work into getting it right"), but then get angry/fail to appreciate the other side ("why won't this cool new library support this old version of Windows I'm stuck in").

(The Python 2 versus Python 3 "war" is obviously very related. Sunk costs on developer/ecosystem side versus sunk costs on library/platform/language side. It's a fascinating dance that likely will always plague development.)

For what it is worth, to explore the other side, there probably were ways out of the development trap for Microsoft had they tried, and there probably are "Mexican stand-off" issues to blame and "throwing good money after bad". Silverlight (WPF/E) was meant to be a way around that standoff. I still think it was a mistake that the fork of Silverlight with desktop application support that Mesh had used to support XP and Vista was never productized. Silverlight was always meant to be a cross-platform bridge technology to WPF (and Avalon), and the .NET Core and UWP Stacks grew out of Silverlight in many respects.

The browser focus of Silverlight deployments may have been a mistake, and while Mobile realized it was exactly the transition tool they needed (using it for Windows Phone 7 and 8 while the proto-UWP was in development for 8.1 and 10), it probably was a mistake in hindsight that there wasn't a stronger "Silverlight for Desktop" option, even if it would have muddied the waters between WPF and eventually UWP. Because, yes Silverlight for Desktop could reach back to the developers stuck with sunk cost in XP or Die corporate environments (again, poor Mesh, RIP, being the poster child of that possibility), made code sharing between Mobile (Windows Phone 7) and Desktop possible/easy in the Windows 7+ transition period to Windows 8, etc.

Given Mobile seemed to recognize the importance of that transition, I'm inclined to believe that less money thrown at mobile wouldn't have helped in this particular case. Based on conversations I had at the time, my gut feeling is that some old guard C/C++ PMs had a lot more to do with the curmudgeonliness of Desktop through the transition era than the money thrown at Mobile. There certainly seemed to be a lot of distrust of any UI platform that wasn't directly developable from C/C++ and that sort of "COM or Die" Mexican standoff I feel (as mostly an outsider trying to make sense of crazy patterns, and some really bad, tangentially related interview feedback) had more to do with the rough transition to Windows 8 and UWP than Mobile did. Mobile at least tried to smooth that transition. (Arguably Mobile was in a better place to try to smooth that transition given the relative popularity of Compact Framework apps in WM 6.5, versus raw C/C++ development, but that's also a different argument.)

Anyway, armchair quarterbacking this is definitely fun, especially with hindsight and not having to actually fight any of the battles that were fought. I can very much appreciate why we are where we are at today, and yes can see some places where things could have been improved, but I also realize why they were such hard fought battles (the sunk cost fallacy is a big one that impacts most sides of all of these debates).

That was probably going to happen anyway because the zero-installation, easy-update, relatively upgrade-safe environment of Web apps is really attractive to businesses.

Good to hear from someone who was valiantly trying to create apps for this platform. I always wondered why developers never flocked to the MS platform since it always seemed wide open with not a lot of competition compared to the IOS and Android platforms.

Thanks for laying bare why it failed so badly.

This reminds me of a Timer app I downloaded when I had a HD8 that didn’t actually alert you when your time was up because of the way the native Alarm SDK was written (something to do with being unable to dispatch an alarm notification at exactly a given time). It made things...difficult.

> at no point had even a single feature that wasn't available better on iOS and Android

Not only is this untrue for years past, it's still untrue (See Continuum + UWP)