Did Microsoft just kill RT?

  • Merging into WP leaves us with a rather slim 1GB OS install without the desktop.
  • Merging into Windows RT leaves us with a 13GB install including two decades worth of legacy desktop functionality that is unnecessary if MS can provide a WinRT compatible version of MS Office.
Once office RT comes out then there's no need for win32 or the desktop so that can be removed. But a some of that 13GB are things like device drivers and other ancillary functionality that may be needed on a tablet even post-merge. Whether you view this as WP with extra features or Windows RT minus Win32 and the desktop seems rather immaterial, since WP is currently Windows RT plus silverlight minus Win32 and the desktop and the drivers and WinRT and the other cruft. Whether it's 2+1 or 5-2 you still get 3.
 
Once office RT comes out then there's no need for win32 or the desktop so that can be removed. But a some of that 13GB are things like device drivers and other ancillary functionality that may be needed on a tablet even post-merge. Whether you view this as WP with extra features or Windows RT minus Win32 and the desktop seems rather immaterial, since WP is currently Windows RT plus silverlight minus Win32 and the desktop and the drivers and WinRT and the other cruft. Whether it's 2+1 or 5-2 you still get 3.

I see you point. I guess I'd just prefer to discuss it from a more practical point of view, one that has some relationship to the actual development effort, rather than from a purely theoretical/mathematical point of view ;-)
 
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.
 

Trending Posts

Members online

Forum statistics

Threads
341,414
Messages
2,264,483
Members
428,833
Latest member
dksdjkdjkdsjkds