It’s not that difficult, the only thing you would need to change in your programs is that you don’t link to opengl32.lib, but instead call a simple init function.
A “simple” init function?
The only reason that pixel format stuff works on most OpenGL .dll’s is because Microsoft’s OpenGL32 mandates that implementers add this functionality. Voodoo1/2 mini-GL drivers probably don’t have these functions. And, even if they do, they could very well be different functions from the wgl* functions.
As such, the init function must somehow know whether the implementation is one that would fit into GL32, or whether it has separate pixel-format setup code, or otherwise know what functions it needs to pull out of the .dll in order to do initialization calls.
Though all GL libraries implement the same functions with (hopefully) the same .dll export names, they do not have to all implement the same extra functions (like wgl*, etc). Only those that would function under the OpenGL32.lib system are forced to do that.
And on the topic of 3dfx’s cards, you can’t say “OpenGL should not be pandering to dead cards like the Voodoo 1/2”. Because reality exists, and a lot of people who build real engines, need to make sure that these older cards are supported, even if only to a minor extent if at all possible. And I’m not saying OpenGL should be maintained for them, that’s impossible since the 3dfx implementation is closed source. But the point is, if you’re not dynamically loading the GL library, your engine WON’T support the vooodoo 1/2 cards because it will try to load the WRONG dll.
And my point still stands: who cares?
Nobody’s making games out of MesaGL (and those who are already are linking to it directly). SGI’s GL is very much unsupported. And, nobody really cares about 3DFx-GL support on Voodoo1/2’s. The low-end target card for most developers these days is, at worst, aTNT2.
If you linked to opengl32.lib, it will load opengl32.dll, I really hope you at least get that, I mean, this isn’t even OpenGL theory, this is basic C theory. If you link to a .lib it will use one specific dll, in your case, I’m guessing opengl32.dll (if you link to microsoft’s implementation).
It may load OpenGL32.dll, but, from that, it will eventually (when I request an appropriate pixel format) load my nvgl32.dll or whatever nVidia calls their OpenGL .dll. As such, it does indeed, “magically get the right one behind the scenes.” Whether that required OpenGL32.dll, ScrewYouGLUsers.dll, or whatever, it got what I wanted. Do I, as a programmer, really care that OpenGL32.dll was loaded? No. All I care about is that my code links itself properly to whatever implementation is correctly installed on the target system at runtime.
Let me ask you a question, have you ever dynamically loaded the functions from the GL library that you will be using? Like, glVertex3f() etc? Didn’t think so, how do I know? Because you keep getting your facts wrong. Please research the topic before posting more comments. It’s simple, open a web browser, go to google, and search for info on dynamically loading dll’s.
No, I have not dynamically loaded core OpenGL functions (because, surprise, OpenGL32.lib does it for me. Why should I waste my time?) Yes, I do understand .dll’s and dynamically loading them. Indeed, considering that I have written .dll-plugin apps (both the main apps and plugins), I would say I’m very familiar with dynamically loading .dlls.
This thread was aimed at people who have already dynamically loaded their dll’s or at least understand the basic C fundamentals as to why programmers would want to do this.
Most of the people who use OpenGL, on any level, do not dynamically load their .dll’s. Why? Because there’s no reason to. The OpenGL32.lib mechanism works for nVidia, ATi, 3DLabs, and most important other manufacturers.
I suppose I could go spend the time to do dynamic .dll loading. But, since the result, for the people I actually care about using my software, is exactly the same, what good does it do me?
Most (as in 99% of the) professional 3D game engines load the library dynamically instead of linking directly to a specific GL library.
These are engines, not users. By definition, they have to be versatile.
Also, it is a legacy feature. Once upon a time, the Unreal and Quake engines had to support old Voodoo 1&2 cards. Now, they don’t, but there’s no reason to throw away perfectly good code. So, that functionality still exists. Indeed, I would imagine that the core GL-loading functionality is so deep in the engine that they haven’t looked at it for years. It isn’t as though they intended to still support loading non-GL32 stuff; they just had more important things to do than take it out.
What you’re looking for is an alternative OpenGL32.lib that allows the person to select a .dll. If that’s all you wanted, why all the stuff about headers and other crap that is, ultimately, unimportant to the actual functionality of being able to select a .dll? Such a thing is way too large to go into a .h file anyway (especailly since it’d have to have special-case stuff to handle something like Voodoo1/2 GL .dll’s).
Your first post was rather cryptic in what you’re looking for if all you’re asking for is an OpenGL32.dll that takes a string parameter.