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 ...

  1. #1
    Registered User
    Join Date
    Nov 2005
    Posts
    88

    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?

    Thank you for any help you can give.

  2. #2
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,424
    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 first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  3. #3
    Registered User
    Join Date
    Nov 2005
    Posts
    88
    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.

  4. #4
    Registered /usr
    Join Date
    Aug 2001
    Location
    Newport, South Wales, UK
    Posts
    1,255
    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).
    Last edited by SMurf; 01-08-2007 at 06:19 PM.

  5. #5
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,424
    Quote Originally Posted by mercury529
    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.

    http://msdn2.microsoft.com/ru-ru/lib...90(VS.80).aspx
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  6. #6
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,424
    Quote Originally Posted by SMurf
    The program won't start in that case;
    You missed my suggestion to you delayload
    The program will start. The message box will appear only if the dll is missing and you still call functions from it... That can be easely prevented
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  7. #7
    Registered User
    Join Date
    Nov 2005
    Posts
    88
    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?

  8. #8
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,424
    Quote Originally Posted by mercury529
    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...
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  9. #9
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    It would totally crash.

    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  10. #10
    Registered User
    Join Date
    Nov 2005
    Posts
    88
    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.

  11. #11
    Registered /usr
    Join Date
    Aug 2001
    Location
    Newport, South Wales, UK
    Posts
    1,255
    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.
    Last edited by SMurf; 01-09-2007 at 10:46 AM.

  12. #12
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    Quote Originally Posted by mercury529
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. DLL Question
    By Longie in forum Windows Programming
    Replies: 2
    Last Post: 06-22-2005, 03:27 AM
  2. DLL question
    By vcguy in forum C++ Programming
    Replies: 1
    Last Post: 06-21-2005, 07:25 AM
  3. dll communicating between each other
    By cloudy in forum C++ Programming
    Replies: 5
    Last Post: 06-17-2005, 02:20 AM
  4. Calling App Functions from DLL
    By johnnie2 in forum Windows Programming
    Replies: 3
    Last Post: 03-19-2003, 12:08 AM
  5. how slow is calling a dll?
    By Andrewthegreen in forum C++ Programming
    Replies: 5
    Last Post: 09-15-2002, 10:33 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21