Subj : Re: converting coff libs to omf libs To : borland.public.cpp.borlandcpp From : "trevor Arsenault" Date : Thu Sep 18 2003 09:13 am Is BOOL WINAPI DllEntryPoint(HINSTANCE, DWORD, LPVOID) required? I can set the entry point in my Visual DLL by using the /ENTRY option in commandline but I don't think this will benefit me. I actually used Harold Howe's webpage already in an attempt to create the new lib files. The page is extremely useful in helping me design the dll for export, however, when using impdef to create the DEF file from my DLL all functions still have a ? in front of them which I am assuming is a misunderstood symbol because when I attempt the command: implib micro2borland.lib micro2borland.def optionally I include the dll file after the def file as well. this results in the following error Error micro2borland.def(4): invalid charactor in .DEF file the def file shows LIBRARY MICRO2BORLAND.DLL EXPORTS ?recieveCommand@@YGPAEXZ @1 //4th line including whitespace ?sendCommand@@YGXPAE@Z @2 ?usbWrapper@@YG_NHH@Z @3 I decided to scrap the class and just make three simple functions in my dll interface declared as __declspec(dllexport) bool _stdcall usbWrapperInit(int vendorId, int productId); __declspec(dllexport) void _stdcall sendCommand(unsigned char* command); __declspec(dllexport) unsigned char * _stdcall recieveCommand(); all attempts made failed... The final solution I used was offered to me by Mr. Bob Gonder, by wrapping my functions in an extern "c" command and using coff2omf.exe as implib and impdef failed (most likely I was using the wrong options). unfortunatly I could not preserve the class structure. I attempted to imitate your header file declaration of #if defined(DLL63_CPP) > __declspec(dllexport) > #else > __declspec(dllimport) > #endif but VS.NET ignored the declspec command to the left of class objects not allowing me to export the whole class. Thanks for all your help (you as well Mr. Gonder) Trevor "Ed Mulroy [TeamB]" wrote in message news:3f6839fe@newsgroups.borland.com... > 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(); > > > > }; > > .