Jump to content
  • Advertisement
Sign in to follow this  
Desperado

Writing an interceptor/wrapper library to an existing library

This topic is 957 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Good evening,

 

I have been tasked to do the following:

 

I'm supposed to write an "interceptor"  library for OpenGL. That means, I'm supposed to write a shared library that imports the opengl headers and libraries and wraps around their functions. Then the shared library exposes the wrapping functions which are supposed to look exactly the same as the original functions so they can take their place in existing code. So basically I'm implementing an OpenGL lib that internally uses the original opengl lib.

 

For example the library shall expose a glBufferData function with the original signature. This function internally calls a wrapper function which itself calls the original glBufferData from the OpenGL API.

 

My problem with this is that it basically means that within the library you have a set of functions with the same name in the same global namespace (the original gl functions and their respective wrapper functions).
I'm not allowed to put the exposed functions into a namespace so the api users do not have to change their code.

 

Any ideas on how to solve this problem?

 

Regards

Share this post


Link to post
Share on other sites
Advertisement

What do you mean the same "function" exactly?

 

Typically when you write a wrapper library to a graphics API, you are not writing for the entire library, but only for the set of functions that is actually important for your use case. Also, OpenGL makes heavy use of flags, which reduces some of the redundancy of multiple functions. Just abstract the flags as well.

As well as some abstracted low level items for textures, shaders, uniforms, etc.

Share this post


Link to post
Share on other sites
Which platforms? I've only done this kind of thing on Win32 by hijacking import address table entries after both DLLs have been loaded (which has the advantage of not being forced to export all the functions the original DLL exports, but the disadvantage that you require a loader to inject the interceptor DLL and has a really good chance of pissing off your virus scanner).

Making a completely transparent library that you can actually compile and then drop right in seems difficult and tedious. I'm not sure if you can use the trick of namespace-around-#includes for this scenario or not. I don't know of any other easy tricks that might help, other that writing a code generator to do the tedious stuff for you.

Worst case, you could be stuck with LoadLibrary and GetProcAddress (or whatever the equivalent is on other platforms) to look up addresses of the original functions. Edited by Nypyren

Share this post


Link to post
Share on other sites
There's a bazillion of these for OpenGL already (GLEW being the most popular). I'd look at those.

Note that OpenGL is _weird_ and you don't wrap it the way you would any other library. Depending on platform, you may or may not link against a function. In many cases, you would just call glGetProcAddress with a string. Even if the function is apparently linked directly, the function may be a macro, or it may be a global function pointer, or so on.

Hooking GL on a generic level generally requires per-platform hooks. On Windows, you'd hook the paltry few functions in OpenGL32.dll and the glGetProcAddress in there. On Linux, you'd hook libGL.so and the glGetProcAddress there... and remember to account for vendor drivers that just overwrite libGL.so because Linux is a rinky-dink pile of garbage (libglvnd will de-rinky-dink-ify things to a degree, but that's years off from being something you can use).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!