The bolded parts are pretty hard to misinterpret. Microsoft is basically saying (in a politically correct way) that the AMD VP is full of crap. Since then, DirectX has been updated to 11.2. It seems to me that AMD's uninformed VP of Global Channel Sales is the one playing with fire and MS got burned in the process. Which actually happens quite often. I really don't understand why you are blaming MS for this.
AMD folks would know if there was going to be a D3D12 (because they would be the ones designing the GPU support, which has a long lead time) and they said it is not in the cards. I haven't heard a peep out of MSFT regarding future GPU technology.
Since we are sharing links, here are a couple links to MSDN posts explaining why MS chose to make all file system APIs asynchronous in WinRT.
Opening Files from SkyDrive using .NET - .NET Blog - Site Home - MSDN Blogs
WinRT and .NET in Windows 8 | All Your Base Are Belong To Us
They didn't do it just to upset developers. In a nutshell they did it because WinRT apps are likely to be running on devices that primarily use cloud storage (i.e. SkyDrive) and might be accessing that storage through a slow cellular connection. If they had used synchronous IO, users would be dealing with a lot of apps that would appear unresponsive. For that reason, they felt that the WinRT framework should always use asynchronous IO to ensure what they consider to be best practices for that type of app. I can totally understand how it is annoying as a developer to have to rethink/recode something as common and simple as file system access, but I can also understand why MS decided to do that when considering the intended purpose of the WinRT framework.
Those links don't justify the Async pattern. Accessing a SkyDrive "placefile" is no different from accessing a file on a network, all of which is handled just fine in a Win32 thread calling blocking Win32 file APIs. My Win32 programs read hundreds of files per day, with some being 10-20 MB in size, from real time internet data sources using background threads. When people use my apps to load archived data already on their PCs (loading and parsing those 10-20 MB files takes a few seconds per file), I fire up a file loader thread and it posts messages to a covering dialog box for progress updates. I'll note that the real time data downloader doesn't affect my programs' UI thread, which maintains a smooth 60 FPS display rate in D3D,
because it uses Windows excellent multithreading support, the best of any OS out there. MSFT is throwing that battle tested, superior technology in the trash.
When using a Win32 thread your code is nice and sequential. You know where you are at all times. In Async you don't know where your code is executing at any moment and have to use all sorts of goofy syntax and boxing to keep variables alive for the lambda callback. Look at all the problems ISVs have with that issue. Looping on an Async callback, like you have to do in C++ to read an unknown length file, results in a vomit-inducing pseudo-recursive coding pattern. It's just stupid. There's a reason why all the C++ StreamSocket examples include a "length" field in front of the data -- it's so they don't have to include the grotesque pseudo-recursion in the example.
Couple of other notes:
1. Apparently this wonderful Async-is-required functionality is available for Desktop apps that use the Common File Dialogs (like mine):
Placeholder files (Windows)
How in the world did MSFT manage to do that in the ancient Win32 API???
2. And the wonderful Async pattern, as you might expect, requires special work to maintain performance (so much for "go Async and all your troubles disappear"):
Asynchronous Programming - Async Performance: Understanding the Costs of Async and Await
I found this to be the case when doing a simple test that added up the sizes of 2000 files in app local storage. Using the ancient Win32 FindFirst/FindNext APIs, my WinRT test app could perform the task in a single NT timer tick (15 ms). Using the wonderful WinRT Async directory functions, that same task took 3.75 seconds (
250X longer). Screwing up performance that bad requires effort (!), so I decided to dig deeper. I isolated the Async part from the dreadful FileBroker in WinRT by using Win32 to enum the files and the Async pattern to step through them. That reduced the overall task time to around 150 ms. So, in this simple operation, using the Async pattern only cost me
one order of magnitude perf hit! If I designed and implemented a system like that, I would expect to be fired ... and the people who approved the RT mess have already been canned (Ballmer and Sinofsky). That's a good start.