We help IT Professionals succeed at work.

Function can't locate DLL function

edmonds101598
on
180 Views
Last Modified: 2010-04-02
Why doesn't this calling function successfully invoke this DLL?

The calling function:

  Void Foo() {
     typedef void (*MYPROC)(double, double, unsigned char*, unsigned char*,
     unsigned char*);
     HINSTANCE hinstLib;
     MYPROC ProcAdd;
                                 :
     hinstLib = LoadLibrary("E:\\Source\\C\\ImageAdd");
     ProcAdd = (MYPROC) GetProcAddress(hinstLib, "AddImage");
     (ProcAdd) (DGain, DThreshold, CGray, CColor, COutput);
                                 :
     }

The DLL:
                                  :
  extern "C" __declspec(dllexport) void AddImage(double DGain, double DThreshold, unsigned char* CGray, unsigned char* CColor, unsigned char* COutput);
  extern "C" __declspec(dllexport) int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*);
                     
  int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*)  {
     return 1;
     }
                     
  void AddImage(double DGain, double DThreshold, unsigned char* CGray, unsigned char* CColor, unsigned char* COutput) {
                            :
   }


We compiled in Borland CBuilder4.  It appears that the "GetProcAddress" function does not successfully return a pointer to  the "AddImage" function in the DLL, leaving "ProcAdd" with a null value.  Is something wrong with the DLL?

Robert Edmonds, Jr.
Comment
Watch Question

Commented:
The rules tell you to always check the result of you function calls. You should check the hinstLib and ProcAdd after you call the functions to give them values.

It may be that you forgot to add the '.dll' extension in your call to LoadLibrary()...

Commented:
First check that the DLL exports functions with the right names.  The extern "C" will remove the C++ name decoration, but it might not remove the "standard call" decoration.  This is an "@" followed by some digits that express the size of the procedure's parameters.  If that is the problem, you will need to use a module defintion file (.def) to remove the standard call decoration.  Note you can use dumpbin.exe to view the exports from the DLL.
Commented:
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION

Commented:
Hi
U don't need a .def file if the function type is extern "C".
if this E:\\resource\\C.... is a network path then I think that is the problem
copy it to UR local disk and try again
check for return value of Load library.
if this all doen't make success then try loading it statically (just to check whether the exe is recognizing the dll or not).

Hope this helps

Commented:
>> U don't need a .def file if the function
>> type is extern "C".
It depends on the compiler/linker and the calling convetion, but in many cases you do need the .def.  Read why.

>> if this E:\\resource\\C.... is a network path
>> then I think that is the problem
Even if it is a network path it isn't a problem.
edmonds, in what compliler are you made
DLL? BCB don't like VC Dll: must special metod, as nietod wrote. Better make it with BC , make LIB file,
add in you project and you haven't problems.

Author

Commented:
Nietod hit it on the head.   Although Quickview was inexplicably not installed on my machine, when I went across the hall to try it I discovered immediately that, even with extern "C", something somewhere in the process was appending a "_" to the front of the function names, for no apparent reason other than to delay us a day and a half.  Quickview is a definite project-saver, we'll use it to check every DLL we create.  One question about the .def files, if we employ one, should the specified function name then be viewable in quickview?
RE    

Commented:
>> something somewhere in the process was
>> appending a "_" to the front of the function names
Forgot about that.  That is also part of the standard call decoration.  I'm surprised you didn't see a @xxx at the end to.  But all this varies from compiler to compiler.

>> no apparent reason other than to
>> delay us a day
Also to make it hard to use the competition's compilers and tools.

Actually I hav no idea why this decoration is done.  There may be a good reason.  I can't image what, althought the @xxx decoration protects you to some extang from linking to code that has differenent parameters.

>> One question about the .def files, if we
>> employ one, should the specified function
>> name then be viewable in quickview?
Yes it will still be viewable.  The .def file can be used to rename the name of a exported function.  ie. if a function was exported as "_function1@12".  you can change the name to just "function1" using

EXPORTS
  _function1@12=function1

(The name you change it to could be anything, just so long as it is unique-actually, that might not even be required.  So you could use it to change the name to function2 if you wanted.)   Now that is how the docs say to use it.  However, it seems that in many cases (this is linker specifc) you only need to have the name without decoration to get it exported without decoration, like

EXPORTS
 function1

is enough to remove the decoration.  

Also VC has a linker command-line option (/export) that allows you to do this without using a .def file.  BCB 4 may also have this same option.
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.