This could have been used for native apps. I'd much rather work with a sane, modern API like D3D11 than the 1980's-style mess of OpenGL. Doing the other portability work is still a big sink of time/money, but it's a hell of a lot better than trying to deal with GL in an app designed for D3D11. It's like porting an app from Qt to GTK+: they both work, but using the original is just way faster and easier to do the same things. I still say someone other than Khronos needs to do a NotStupidGL so the anti-Microsoft zealots won't freak out about seeing DirectAnything but people who want to get work done have a better API than OpenGL; I've heard rumblings of a few projects like this (and debated doing my own on Gallium) but nothing yet. I won't claim it would be easy; it won't. But it'd be a fun project that would do the world a lot of good. Google is likely to jump on it since OpenGL bindings in Java are... awful. GL wasn't designed for bindings or wrapping at all, compared to D3D which is pretty easy to bind or wrap.
Originally Posted by Kivada
A big sticking point for a pure D3D reimplementation is that the binary shader format for newer HLSL shader models is no longer documented, _and_ the d3dcompiler_xx.dll is no longer part of the "public" API. I took a DX developer to task over this at the bar last Wednesday; their excuses boil down to (a) they don't want to have to maintain compatibility, which is stupid (and I told them so), they have to maintain compatibility _anyhow_, and can continue to do so with binary DLLs on Windows, and (b) their division is massively understaffed for how critical DX is to all of Windows now and they don't have spare cycles to maintain any more documentation. As is no surprise here, interoperability is not at all the highest item on their list of priorities, or even on their list of priorities right now. Unfortunately, drunkenly berating core developers in a bar has no effect on managerial prioritization. The shader compiler thing isn't just for GL compatibility, though; it bars a lot of useful and cool kinds of apps from the app store because they can only use precompiled shaders. Shader development apps, toys, or user-modifiable graphcs pipelines are impossible on the app store without the ability to programmatically generate shaders. It's like banning all scripting languages, except for the GPU.
I also pointed out that if Win8 wants to make any inroads into tablets and phones, it's now in the unfortunate position where it has to acomomadate Khronos' crap. Which doesn't mean adding OpenGL|ES support necessarily, but making it easier to write complete wrappers would help. That means making the HLSL compiler part of the full API (it's barred on Win8 store apps as an internal-only feature) or documenting the binary interface, as well as adding configuration calls to make the few places where D3D and GL are incompatible (screen coordinates, depth buffer ranges, etc.) be able to be set to a GL-compatible mode. (It's completely stupid that Khronos, with the extensible GL, hasn't done the reverse already, especially since in a few cases the D3D approaches are quantitatively more correct, but MS either needs to play ball if they want to make it easy for devs to port their existing apps over quickly.) Maybe that argument will get up to a high-ranking PM and they'll act on it. Probably not, but here's hoping.