Visual Basic, Calling 32-bit DLL function from 32-bit VB4 app

Calling 32-bit DLL function from 32-bit VB4 app

Author	Message
abhijit belapurk #1 / 5	Calling 32-bit DLL function from 32-bit VB4 app Hi, I have developed a Visual Basic application using 32-bit Visual Basic 4.0 Professional Edition installed on Windows NT 3.51. This application calls a function (call it test_func1) from a DLL (call it tst1.dll). The DLL has been developed using 32-bit Visual C++ 2.0 for Windows NT. The function prototype is : _declspec(dllexport) int _stdcall test_func1(LPSAFEARRAY FAR *p_invar); I do not have an EXPORTS section in my module definition file. Inside the VB application, the function declaration is as follows: Public Declare Function test_func1 Lib "tst1.dll" (p_arr() as string) as integer When I ran my VB application, an error "Specified DLL function not found" came. Upon running the dumpbin utility on my dll, I found that my function had been in my VB application and it ran smoothly. However, I do not want to keep aliasing my function names as a solution to my problem. Why is this happening and how do I get around it? Any help in this regard is welcome.TIA, Abhijit.
Fri, 18 Sep 1998 03:00:00 GMT

Lauren Vanderho #2 / 5	Calling 32-bit DLL function from 32-bit VB4 app Quote: >Hi, >I have developed a Visual Basic application using 32-bit Visual Basic 4.0 >Professional Edition installed on Windows NT 3.51. This application calls >a function (call it test_func1) from a DLL (call it tst1.dll). The DLL has >been developed using 32-bit Visual C++ 2.0 for Windows NT. The function >prototype is : >_declspec(dllexport) int _stdcall test_func1(LPSAFEARRAY FAR *p_invar); >I do not have an EXPORTS section in my module definition file. Inside the >VB application, the function declaration is as follows: >Public Declare Function test_func1 Lib "tst1.dll" (p_arr() as string) as integer >When I ran my VB application, an error "Specified DLL function not found" came. >Upon running the dumpbin utility on my dll, I found that my function had been >in my VB application and it ran smoothly. >However, I do not want to keep aliasing my function names as a solution to my >problem. Why is this happening and how do I get around it? Any help in this >regard is welcome.TIA, Abhijit, All you gotta do is, add extern "C" to your C function declaration: _declspec(dllexport) extern "C" int _stdcall test_func1(..) to prevent the C++ compiler from mangling the function name Cheers, lauren :}
Sat, 19 Sep 1998 03:00:00 GMT

Helge Sü #3 / 5	Calling 32-bit DLL function from 32-bit VB4 app Quote: [snip] > The DLL has >been developed using 32-bit Visual C++ 2.0 for Windows NT. The function >prototype is : >_declspec(dllexport) int _stdcall test_func1(LPSAFEARRAY FAR *p_invar); [snip] >I do not have an EXPORTS section in my module definition file. You encountered name mangling. A feature of C++ to distinguish methods in several generations. Declare a function extern "C" to avoid this effect. Helge ;-)=) ---------------------------------------------------------- (c) All Thoughts are Mine -- Genuine Genius ---------------------------------------------------------- ----------------------------------------------------------
Sat, 19 Sep 1998 03:00:00 GMT

Ron Rubl #4 / 5	Calling 32-bit DLL function from 32-bit VB4 app The change of name of the function is because C++ compilers change the names of functions to add stronger type checking. The easiest way to change this ( if you don't use C++ features) is to change your build options and define the function using extern "C" Also, any functions for Visual Basic use should be declared using Pascal to modify any return type (even void). Microsoft's Tech Support even recommends using a module definition file rather than declspec (dllexport) if you are writing DLL functions for VB. -- Ron Ruble Consulting Application Development Flames cheerfully ignored. Maximize bandwidth; teach a newbie the usenet
Thu, 24 Sep 1998 04:00:00 GMT

Simon Kea #5 / 5	Calling 32-bit DLL function from 32-bit VB4 app : The change of name of the function is because C++ compilers : change the names of functions to add stronger type checking. The : easiest way to change this ( if you don't use C++ features) is to : change your build options and define the function using : extern "C" : Also, any functions for Visual Basic use should be declared : using PASCAL to modify any return type (even void). Microsoft's : Tech Support even recommends using a module definition file rather : than declspec (dllexport) if you are writing DLL functions for VB. : : -- : Ron Ruble Consulting : Application Development : Flames cheerfully ignored. : Maximize bandwidth; teach a newbie the usenet I haven't read the original post but I think this info may be incorrect (along with the other postings regard C++ name mangling). When C program is written with the extension .c and utilising no C++ features it will be treated as a C file - C++ name mangling will NOT occur. The problem of name changing is because of the _stdcall specifier. So if you have a function foo declared as followed: DllExport void _stdcall foo(int i) {.....} OR DllExport void WINAPI foo(int i) {...} as a parameter and an int is _4_ bytes long. If foo took two integer _stdcall specifier. Just look up _stcall in the online documentation - it specificall says that it will add this to the end of the function names. If you dont' use _stdcall then your get bad calling convention so you really do need to specify it. The problem is that VB doesn't expect the functions to be named in such a way (Microsoft can't even get their programs to adhere to a standard!) so you have to alias the function as much difference. SImon
Sat, 26 Sep 1998 03:00:00 GMT

Page 1 of 1

[ 5 post ]