DLL Calling Question

This is a discussion on DLL Calling Question within the Windows Programming forums, part of the Platform Specific Boards category; I am using LoadLibrary and GetProcAddress in a VC++ 6.0 app I have made to call a dll function in ...

DLL Calling Question

I am using LoadLibrary and GetProcAddress in a VC++ 6.0 app I have made to call a dll function in a VC++ 6.0 dll I made.

I can call the function successfully. However, I would like to make the code as error-resistant as possible. Is there anyway to determine what parameters a dll expects? In VB, when you declare a dll function and then call it with the incorrect parameters, it raises error 49 to indicate the calling protocol is incorrect. Can I somehow accomplish this from my c++ application as well to ensure that when I call a dll, I am calling it with proper parameters and not corrupting the memory space by using incorrect ones?

you can link the dll in the regular way. In this case a compiler will check for you all function prototypes consistency.
If you need to be able to run the application when the dll is not present - use delayload of the dll...

The program won't start in that case; the Windows loader will attempt to resolve all statically-linked imports before your program is ready to run. If something's missing, a handy message box pops up and it aborts.

Dynamic linking will allow you to have some control over the situation, but there's not really way you can determine what parameters an unknown DLL function will expect. I mean, there is, but it would involve a partial disassembly of the DLL to work out what it pulls off the stack, which is a pretty major undertaking.

I'm not sure how VB works, but it's either doing type-checking of what you're passing to it (which C and C++ do at compile time) or it notices that a bad call breaks the stack (C and C++ programs would usually crash at this point).

What happens with static linking when the dll is not present? I thought it causes the program to error out in a way that cannot be handled.

When you use deleyed load of the dll during linkage - you call the functions as if the library is linkage the regular way, but the dll is loaded in the memory on the first call to the function from the dll

So you can use for example LoadLibrary call to determine if the dll is present and then avoid calling functions from this dll if not. this makes code much simplier to support.

The real issue for me though is what happens in the case where you delay load the dll, and the dll on the other end has different parameters than the one you statically linked against? The LoadLibrary call would successfully report the DLL existed. A GetProcAddress would successfully return a function address. But when you went to call the function, what would occur?

The real issue for me though is what happens in the case where you delay load the dll, and the dll on the other end has different parameters than the one you statically linked against? The LoadLibrary call would successfully report the DLL existed. A GetProcAddress would successfully return a function address. But when you went to call the function, what would occur?

5 min reading and you already come with the new question? I thought it will take a little bit more time...

VB only checks a single thing: whether the stack after the call looks as expected. You can do that with some platform-specific code, but it's unreliable and doesn't prevent the thing from crashing first. (Nor does the VB method, really.)

Of course with COM DLLs, VB might be able to look up a type library and check - but nobody guarantees that the typelib is actually correct for the given DLL.

At the bottom line, what you want to do is not possible in native code. Use Java or C# or some other language that provides extensive runtime reflection instead.

Vart: Haha sorry. I guess it was just good timing when I checked back in before I went to sleep. Thank you for the suggestions, but I think Corned Bee is correct on this one. I just wanted to make sure there was not some trick I was missing.

CornedBee: The stdcall-ing convention VB must use when calling a DLL requires the function to specify how many bits of input it expects to receive. I imagine VB checks against that to at least ensure that the size of the input parameters passes in match the expected size. I do not know for certain however.

I was hoping there might be another calling convention like stdcall that existed prior to .NET that gave more robust function parameter info. I believe .NET dlls have the capability for full function descriptions. However, I was trying to stick with VC++ 6.0, so it seems very likely that I will not be able to achieve what I intended.

Thank you all very much for the help. If anyone knows something I am missing, please feel free to share.

Here's a page with information on the finer points of calling conventions. Note that stdcall functions in particular rebalance the stack themselves. So if they were expecting 3 int-sized parameters then it will add something like 12 to the stack pointer. If you only passed 2 parameters... welcome to the twilight zone.

VCornedBee: The stdcall-ing convention VB must use when calling a DLL requires the function to specify how many bits of input it expects to receive.

No, it doesn't. That's just a convention. When using a .def file in creating the DLL, you can override the exported name of the function with whatever you want.
Thus, VB can't use that byte count for checking.