Subj : Re: converting coff libs to omf libs To : borland.public.cpp.borlandcpp From : "Ed Mulroy [TeamB]" Date : Wed Sep 17 2003 07:39 am Yes you can use __stdcall with class member functions. However they still have mangled public names. Here is an example. I made up temp62.cpp as a main program and dll63.cpp to be a DLL thatit uses. None of the functions are inline and all are __stdcall (except constructor and destructor of course). From the screen capture below you can see that it built, linked and ran. (You may not like console mode progams or building from the command line, but I defy you to capture and place the build from within the IDE and the output of a GUI program into a text mode newsgroup message.) As I do not have Borland C++ mounted on this machine, I did the build with C++ Builder but the results for this should be the same. ----------------- C:\Lookat\temp >make -B -fmake62 MAKE Version 5.2 Copyright (c) 1987, 2000 Borland bcc32 -WCR -v -c temp62 Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland TEMP62.CPP: bcc32 -WDR dll63 Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland DLL63.CPP: Turbo Incremental Link 5.64 Copyright (c) 1997-2002 Borland implib -c dll63.lib dll63.dll Borland Implib Version 3.0.22 Copyright (c) 1991, 2000 Inprise Corporation impdef dll63.def dll63.dll Borland Impdef Version 3.0.22 Copyright (c) 1991, 2000 Inprise Corporation ilink32 /Tpe/ap/Gn/c/x/v c0x32 temp62,temp62,, dll63 import32 cw32i Turbo Incremental Link 5.64 Copyright (c) 1997-2002 Borland C:\Lookat\temp >temp62 0 5 C:\Lookat\temp > ----------------- However the exported functions are still mangled as you can see from the contents of the DEF file shown below (whitespace trimmed to fit in a message without word wrap). ----------------- LIBRARY DLL63.DLL EXPORTS @abc@$bctr$qv @1 ; abc::abc() @abc@$bdtr$qv @2 ; abc::~abc() @abc@GetVal$xqqsv @4 ; __stdcall abc::GetVal() const @abc@SetVal$qqsi @3 ; __stdcall abc::SetVal(int) ___CPPdebugHook @5 ; ___CPPdebugHook ----------------- The sources which show the class, implementation and use are below. I wrote it to demo for this and do not offer it as any kind of "professional quality" program. ----DLL63.H------ #if !defined(DLL63_H) #define DLL63_H #if defined(DLL63_CPP) __declspec(dllexport) #else __declspec(dllimport) #endif class abc { private: int int_val; public: abc(); ~abc(); void __stdcall SetVal(int i); int __stdcall GetVal() const; }; #endif ----------------- ----DLL63.CPP---- #include #define DLL63_CPP #include "dll63.h" BOOL WINAPI DllEntryPoint(HINSTANCE, DWORD, LPVOID) { return 1; } abc::abc() : int_val(0) {} abc::~abc() {} void __stdcall abc::SetVal(int i) { int_val = i; } int __stdcall abc::GetVal() const { return int_val; } ----------------- ----TEMP62.CPP--- #include #include "dll63.h" #include using std::printf; int main() { abc a; printf("%i\n", a.GetVal()); a.SetVal(5); printf("%i\n", a.GetVal()); return 0; } ----------------- ----MAKE62.MAK--- ..autodepend temp62.exe : temp62.obj dll63.lib ilink32 /Tpe/ap/Gn/c/x/v c0x32 temp62,temp62,, \ dll63 import32 cw32i temp62.obj : temp62.cpp bcc32 -WCR -v -c temp62 dll63.lib : dll63.cpp bcc32 -WDR dll63 implib -c dll63.lib dll63.dll impdef dll63.def dll63.dll ----------------- I think you have little choice but to write some tagging code into the various functions which you cannot tell apart so that running a test program will see the tagging (tagging==showing a message box or write to the screen or something like that to id the function) and therefore decipher which symbol refers to what function. You can remove the tagging after identifying the public symbols. If I were you I would look through Harold Howe's site http://www.bcbdev.com/ for his views on linking with Microsoft's compilers. I remember an article by him about getting around the differences in name mangling and remember it as involving more than just aliases in a module definition file but do not remember the details and am hoping that he has placed that article on his site. (Note: Harold is a member of TeamB) .. Ed > trevor Arsenault wrote in message > news:3f6798fb$1@newsgroups.borland.com... > > You are right that mangling occurs so I attempted to use the > _stdcall param in my export class, but I don't think it's > supported with class' only functions. The same goes for the > extern"C" command to prevent mangling, it would work fine if > I was just exporting functions, however, I'm exporting a > class which isn't supported in C. I tried to modify the Def files > as you sugested (making aliases for the mangled functions, but > I have two constructors and a destructor with quite similar names > I can't tell which alias goes with which. Plus the class itself has > a mangled name in the DEF file. I would really like to keep the > class structure but I can arrange it so they are only functions > and then I can follow your methods. Do you know of anyway > I can construct the def file and lib file while maintaining a > class structure? > enclosed is the def file created from imp def ... guess' labeled > with > // > LIBRARY MICRO2BORLAND.DLL > > EXPORTS > > ??0usbWrapper@@QAE@HH@Z @1 //class structure > > ??0usbWrapper@@QAE@XZ @2 //constructor no params > > ??1usbWrapper@@QAE@XZ @3 //constructor params > > ??4usbWrapper@@QAEAAV0@ABV0@@Z @4 //destructor > > ?recieveCommand@usbWrapper@@QAEPAEXZ @5 //recieveCommand > > ?sendCommand@usbWrapper@@QAEXPAE@Z @6 //sendCommand > > and the class def is > > class __declspec(dllexport) usbWrapper > > { > > public: > > usbWrapper(); > > usbWrapper(int vendorId, int productId); > > ~usbWrapper(); > > void sendCommand(unsigned char* command); > > unsigned char * recieveCommand(); > > }; .