How is that an example of MS abandoning their other programming technology/frameworks? Direct3D 11.2 is still available and is considered cutting edge. It just got released with 8.1 a few months ago for god's sakes. Is there even a need for a major new release of Direct3D at this time? What advancements in GPU hardware would it take advantage of that Direct3D 11.2 isn't already making use of? This is a pretty poor example of MS abandoning their programming technology. At least pick something that hasn't been updated in the past few months.
Those are tweaks on existing releases and I'm not talking about D3D12 right now. According to AMD/ATI, MSFT has no plans for a Direct3D12. No plans -- meaning it is a dead end. As for future GPU innovation, I'd like to see Output Merger stage shaders. Most important are the things I can't even think of right now.
That is only part of the equation. Yes, I can write a traditional Win32 desktop program that just sits there idle and uses very little CPU power. However, it still uses memory which is a problem on mobile devices like ARM tablets and phones once you open a few too many apps. It also won't respond to being "tombstoned" (i.e. purged from memory) and then "rehydrated" (expected to startup in the same state it was in before it was killed) which are memory and power saving concepts used on ARM class devices. Those concepts and related APIs don't exist in Win32.
A Win32 program can certainly start up in its previous state. My Win32 apps start up in nearly the same state that they were in when closed. And look at WM_QUERYENDSESSION for information on how to know when your Win32 app is force-closed. Adding a few more messages would have been far easier than reinventing the wheel over and over again.
Most importantly, Win32 supports a ton of functionality that is not needed on a small mobile device and duplicating all of the underlying technology would be very wasteful for a phone or Surface RT style device. This is why WinRT was designed to provide a subset of Win32 functionality. You could argue that they should have just made a stripped down version of Win32 and then changed some things related to very low power hardware. I would argue that the result of that project would might be called "WinRT".
Yes, they should have produced a stripped down version of Win32. I would have completely supported a new Win32 subset that cut out old, obsolete stuff (especially insecure APIs and access) while adding a simple, scalable UI API. I also like the Store managing updates, etc. (though not the 30% cut, that should be no more than 10%). Take the good stuff from WinRT (scalable XAML, store, etc), repackage it for Win32, then
backport the damn thing to Win7 and they'd have a winner. I would have converted my Win32 programs over to this new Win32X platform instantly.
What I do *not* like is MSFT wasting their time reinventing file access, forcing ISVs to use the stupid Async pattern, etc. Basically nuking all existing Win32 code. The market has proven this to be the wrong course. Windows is dying right now. The MJF article on ZDNet says that MSFT has abandoned their plan to bring WinRT and WinPRT closer together in the upcoming Win81 update. Why? Because Win8's OEM sales dropped 20% in the latest quarter. That's a forward-looking number which means that OEMs expect sales to get even worse than they were in 2013. MSFT is panicking and tossing everything aside to try and fix the Win8 disaster. And note that this Win8 disaster is *not* independent of the WinRT development disaster. It's reflected in the lack of large selection of WinRT programs. Why would an ISV duplicate all their Win32 effort for a entirely new, critically limited, and poorly performing WinRT system? Do I even need to mention the orders-of-magnitude slower file access in WinRT?
You complain that MS has forced you into WinRT and abandoned Win32 (you specifically mention Direct3D as an example of this) and then you talk about using Win32 APIs and Direct3D in your own published WP8 app.
I'm talking about the future of Direct3D, not the present. See my comment above about MSFT not developing future versions of D3D.
First, I wasn't talking about the underlying implementation within the Windows OS, I was talking about from the developer perspective. In other words, it would be silly to complain that MS uses HTML, JavaScript, or ASP.Net as their web programming frameworks instead of sticking with Win32 APIs and C++ to write webpages. Those languages/frameworks are intended for completely different types of applications.
An OS is written C++ and I'm a C++ programmer. I don't care what framework goop other languages use to communicate with the OS. I want a clean, simple OS that I can access from C++. You do know that WinRT is written in C++, correct?
Second, you are again proving my point. You keep saying that MS has abandoned Win32 in favor of WinRT, but here you are saying that WinRT is an additional layer that has been added above Win32. You also said earlier that Win32 is still accessible (via "un-managed" code calls).
Very few Win32 APIs are available to WinRT programs. And even then they're inconsistent between WinRT and WinPRT. For example, WinRT only has the Windows.Socket APIs while a WinPRT program can use WinSock. The HTTP situation between the WinRT/WinPRT is even worse. I couldn't use XMLHttpRequest2 because of the differences in behavior between WinRT and WinPRT (e.g. both fail range-byte GET requests differently because they set the gzip flag on requests, both cache things differently, etc.). What's stupid is that XHR2 calls WinInet to do the actual work but my C++ programs can't access WinInet. To fix this, in Win81 MSFT wasted more time implementing an entirely new HttpClient API. Guess what, it turns around and calls Win32's WinInet. Why didn't they simply give C++ programs access to WinInet in the first place???
While you may see WinRT as unnecessary for your style of coding or your own needs, it really isn't any more "unnecessary" than any other abstraction layer. The .Net framework is an abstraction layer that runs on top of Win32 (on x86 Windows machines at least), but it has a lot of advantages and is a more reliable, efficient, and consistent development platform for most common applications. ASP.Net is an abstraction layer that ultimately runs as HTML/javascript and it has many advantages over traditional web programming for most web apps. Even your beloved Win32 and Direct3D are abstraction layers (although lower level) over internal OS specific implementations.
See my comments above about C++ and OS access. I don't care how many layers of goop MSFT wants to place between the OS and other languages/scripts.