> Since the anti-trust case in 1998, Microsoft have become more subtle in the way hurdles are laid out.
Microsoft learned that they have to play the 'big corporate' game of pay offs and supporting popular initiatives even if it means supporting corrupt-to-the-core stuff. (which is the vast majority of things).
> The lack of native support for OpenGL is one such subtle hurdle, yes you can circumvent it, but is is an annoyance and extra burden none the less
Hardware/drivers provide their own OpenGL stack anyways. This is the way it's always worked for OpenGL. The whole 'Second rate OpenGL' thing is a bit of a red-herring. By the time Microsoft Vista came out OpenGL already fell out of favor.
ID was the only company actually seriously using OpenGL long before Vista. Other game engines supported OpenGL back-ends, but it wasn't for mainstream gaming.. it was more a of a specialty item. (like some Arcade machines ran Linux OpenGL)
The problem with OpenGL is that each vendor gave their own OpenGL stack. Which means that as a game designer you are not targeting 'OpenGL API' you are programming for: Intel's OpenGL API, Nvidia's OpenGL API, ATI's OpenGL, etc etc. Each vendor had subtle differences and different bugs to work around. Not to also mention that in order to be 'cutting' edge you had to deal with all the vendor-specific proprietary extensions.
With ActiveX you only had one vendor to deal with. This means that you didn't have proprietary extensions. It is consistent and worked just about the same regardless of what video card the user happened to have.
This is exactly the same thing that Linux needs. A consistent API, which hopefully we will get with decent open source drivers. It's the only way to get OpenGL working consistently on all Linux machines. Nvidia's stack is so much better then the OSS one that anything OSS supports so will Nvidia. That is the only proprietary OpenGL driver for Linux that is worth a damn.