You have posted this same rant in many other threads. Same example and everything. Often in situations where it's completely off topic. You seem to be obsessed with it. I won't bother to debate you on this topic again because it's clear to me that there is no rational discussion to be had.
I use the
AndContinue example because it's the most recent and best example of the ridiculous design decisions the WinRT/PRT team are making. These things aren't limited to just ISV woes but they surface in the UI that regular users encounter (e.g. abysmal file/directory performance in WinRT due to the FileBorker and Async patterns, which result in two orders-of-magnitude performance difference between Win32 and WinRT -- I'm not joking). That alone is appalling.
The last time you and I debated this you claimed that MS was abandoning all of their Win32 developers. I asked for an example and you said that MS had discontinued DirectX. You cited some unofficial quote from one non-technical guy at AMD. I pointed out that it was a rumor that MS has already stated was completely false in an official press release. However, you continued to insist that DirectX was dead and MS was killing off Win32 development. A month after that discussion MS announced DirectX 12 for Windows and Xbox One.
AMD/ATI announces Mantle then several months later MSFT announces D3D12, which won't be available until late 2015 (18 months, which means it wasn't being worked on officially until now). MSFT was forced to get back into D3D to save face. Kudos to AMD for providing competition.
I too am a developer (.Net mostly) and while you are entitled to your opinion about WinRT and it's design, your opinion is not shared by all developers. Microsoft is not stupid and I'm willing to bet you are not more talented than their entire army of developers.
I've worked on OS code and application code for a long time. I guarantee you that I *am* (and you are) better than the morons that designed and implemented the FileBroker and WinRT File/Directory APIs. If I released a OS component that took a two orders-of-magnitude perf hit I would expect to be fired. And why didn't the SDE-Ts scream bloody murder about it? That type of perf hit in a critical component is a Sev2/Pri1 bug (IIRC), meaning it has to be fixed before release.
Most people in the know would consider their development tools and frameworks to be the best in the world by a long shot.
No argument on that from me with regards to the dev tools. VS2012 is by far the best IDE and compiler ever made. I'd love to see MSFT somehow add Android as a target (I don't know enough about Android development to know all that's involved with producing binaries for it).
Their reasoning for designing WinRT as they have is sound in my opinion. WinRT is simply not targeting the type of devices that Win32 programming is typically targeting. As such, there is a need to build more asynchronous calls and safeguards into the framework.
That's great. You think those things were necessary and I don't. Look, I know that OS SDEs operate under constraints that aren't always visible to outside developers. My code had some weirdness due to backwards compatibility constraints and, of course, some purely stupid decisions on my part. I expect to see some of that in any OS. However, the design and implementation bugs in WinRT/WinPRT that I'm pointing out were made
by choice, not by underlying constraints. Those SDEs should not be writing OS code.