Jump to content
  • Advertisement
Sign in to follow this  
RegularKid

GetProcAddress() question...

This topic is 4070 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

I've searched around but can't seem to find any info on type checking the function I get from GetProcAddress() before I call it to make sure it has the right parameters / return type. I am loading in a .dll dynamically at run-time and calling a function to run the AI in a small game I'm making. The problem is that I want these .dll's to be creatable by anyone. So, since they are prone to errors due to the fact that they are not compiled with my code, I want to be able to ensure that the function has the correct parameters / return type. Any ideas?

Share this post


Link to post
Share on other sites
Advertisement
There's no guarantee with plain old DLLs. If the function is broken, it's the plugin DLL's fault plain and simple.

Share this post


Link to post
Share on other sites
As taby said. A function returned from GetProcAddress() is just a pointer to a chunk of memory. There's no way to tell what the type of the parameters is, really.

The best you're likely to get is to have a GetAIVersion() function exported from the DLL, and if that returns a value other than you expect, you can assume the DLL is bad. Still doesn't help if someone's screwed up the parameters though.

Share this post


Link to post
Share on other sites
It's actually worse than that since you don't even have any guarantees that the return value of GetProcAddress() is even a function.

If you want a safer plug-in system you may want to consider using a different language/system for your plug-ins. For example, you can embed Python as an interpreter and run plug-ins as Python scripts rather than user created DLLs.

Share this post


Link to post
Share on other sites
With a decent dose of exception handling you should be able to safely load any DLL and call a function inside it.

The key idea here is to make sure that the DLL can't crash your program, something along the lines of SEH can probably handle the job.

Share this post


Link to post
Share on other sites
Exception handling alone can't guarantee that a malformed native DLL can't crash your program. You also have to vet all the interactions that DLL has with the state of your application for consistency. For example, a function call to a DLL may return a pointer to the stack. If your application later writes to that pointer you can get a big fat unhappy crash. And since exception handling information is read from the stack, that could include screwing up the exception handling mechanism.

Share this post


Link to post
Share on other sites
You can of course use IsBad*Ptr, in this case perhaps IsBadCodePtr to try and help determine if something is bad before trying to execute/read/write to it. There are also other methods of preventing things from destroying the stack. I can't remember how to do it off the top of my head and I can't find the log file where the guy told me about it.

I'm not saying you'll be able to prevent a hostile DLL from crashing your application, but one that has been poorly programmed shouldn't be able too.

I'm reasonably sure one can make it so that its safe and this is a really nice solution to te plugin problem because it allows for incredible amounts of power when it comes to wanting to do something.

Share this post


Link to post
Share on other sites
The bad pointer functions are coarse level memory access checks; they aren't magic. In this case, IsBadCodePtr() only checks if the process has read access to the given memory location. Giving it an address to committed memory in the stack will return false.

Share this post


Link to post
Share on other sites
Just thought I'd say that GetProcessAddress is, really, an incredibly crude tool. I recall that it basically just reads the export table of a dll or executable, and returns the pointer associated with a given function name. That's it.

And no, there is ABSOLUTELY no way to stop a hostile DLL from crashing your program. You cannot stop it from screwing with the stack, your SEH handler, anything. If it wanted to really give you the finger, it could even completely unload the original application, and still keep running. Not to mention that those IsBad*Ptr functions are pretty stupid too.

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!