Neither method (static-linking .lib vs win32 getprocaddress) is better. Well, static linking is a wee bit faster, not that it matters:
“call xxxPatchedAddress” // some older compilers make this a jmp+call, though.
vs
“call dword ptr [xxxDynLoadedAddr]”
Although it should probably contain a readme file with a little explanation or something. Or you could just add a readme.txt with a link to this thread.
@ijc12:
Is it correct to use GetProcAddress instead of wglGetProcAddress. I read somewhere that depending on pixelformat, active rendering context can return different entry points when you use wglGetProcAddress.
Long time ago I made similar tool (parse glext.h and wglext.h) and generate cpp file (glExtMap.h & glExtMap.cpp). Generated code is almost the same as yours except I added flags structure for checking extensions (collect all known extensions and add flag in big bit-field structure).
But… I lost parser source code and all I have is parser executable Today, Im too lazy to write new parser, so I’ll use your work. Thank you very much.
GetProcAddress returns null for funcs the opengl32.dll doesn’t export. (use Dependency Walker to see the list of exports) . It is not hooked, as the set-in-stone static linking easily renders that useless. Instead, the exported funcs are hooked by design, (note: the funcs’ addresses stay the same). For example, in opengl32.dll, this is glBindTexture():
mov eax,dword ptr fs:[00000018h]
jmp dword ptr [eax+0A08h]
wglGetProcAddress is also hooked in a similar way by the video-driver and returns context-dependent func-addresses. For funcs that are not already on the static-lib’s exports-list.
Is it correct to use GetProcAddress instead of wglGetProcAddress. I read somewhere that depending on pixelformat, active rendering context can return different entry points when you use wglGetProcAddress.
I don’t know if it’s strictly correct but it’s the only way to get function pointers to certain functions since wglGetProcAddress won’t return them. In any case GetProcAddress is only used for gl3 and only when wglGetProcAddress fails. Maybe using function prototypes instead of function pointers would be more correct for these implicitly linked functions, I don’t know.