C++ DLL Compatability Hell! - C / C++ / MFC Discussion Boards

I know this is not a place to put an ActiveX question. But i couldn't find another group to post this question.

I am using the MS Mask Edit control in my program and for that i have included the following files in project.
1. msmask.cpp
2. msmask.h

Now i try to do a CoCreateInstance passing the Class ID of msmask as the 1st parameter.

I get an error saying the "Class is not registered".

I am not using the msmask32.ocx in my project or have it in any folder. But if i get a msmask32.ocx and register it using the regsvr32 command, the CoCreateInstance function works fine.

My question is, can i work with msmask cpp and h file without having to register the msmask32.ocx file?

Any help is welcome.

You can't use an OCX without registering it.

I'm learning how to build DLLs, and I've had some observations, and I was wondering if someone could provide me some insight. In Visual Studio 2005:

1) Created a new project
2) Using the project wizard created a MFC regular DLL using shared MFC DLL. (no other options selected)
3) Added a method to the default class generated by the wizard called "Execute"

void Execute();

4) Defined the method

void CTestApp::Execute()
{
return;
}

Added the method for export in the module definition file (.def)

LIBRARY "Test"

EXPORTS
Execute

When I compile I get a link warnings/error:

1>Test.def : warning LNK4022: cannot find unique match for symbol 'Execute'
1>Test.def : warning LNK4002: "public: void __thiscall CTestApp::Execute(void)" (?Execute@CTestApp@@QAEXXZ) defined in .\debug\Test.obj
1>Test.def : warning LNK4002: "public: void __thiscall CDaoDatabase::Execute(unsigned short const *,int)" (?Execute@CDaoDatabase@@QAEXPBGH@Z) defined in C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\mfc80ud.lib
1>Test.def : warning LNK4002: "public: void __thiscall CDaoDatabase::Execute(wchar_t const *,int)" (?Execute@CDaoDatabase@@QAEXPB_WH@Z) defined in C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\mfc80ud.lib
1>Test.def : warning LNK4002: "public: virtual void __thiscall CDaoQueryDef::Execute(int)" (?Execute@CDaoQueryDef@@UAEXH@Z) defined in C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\mfc80ud.lib
1>Test.def : error LNK2001: unresolved external symbol Execute
1>C:\Documents and Settings\fi507c\My Documents\Visual Studio 2005\Projects\Test\Debug\Test.lib : fatal error LNK1120: 1 unresolved externals

So I've come across two solutions

Solution 1: Instead of using a .def file, use __declspec(dllexport) to export.

This solution makes sense, since it automatically creates the .def file for me. But I'm not sure what the issue with the .def file was. Was it due to name decoration?

Solution 2: Instead of calling my method Execute, call it something different, like Axecute.

This is somewhat odd to me, just by renaming the method to something else, the .def file works to export the function. Does it have to do with the some of the linker warning/error information? Wouldn't name decoration still cause an issue?

You'd need to fully qualify the name in the def file (like "CTestApp::Execute")
because no Execute function exists in your project.

That will get rid of all the warnings but then the name mangling will still prevent the link.

Using __declspec(dllexport) is recommended over using the EXPORTS section of the def file.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

HA did I get hooked! I'm flopping around all over this boat[^]

led mike

Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP

*snicker*

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Hi,

I am working on a small game engine which is designed to work on multiple platforms when recompiled. At the moment I am targetting win32 and linux. Using Win32 with Visual C++ it is easily possible to create DLLs which export classes, objects, and functions. However I have some problems for which I would be really greatful if you guys advise me with.

The first problem is compatability with compilers:
I am told that DLL's compiled with Microsoft Visual C++ (without MFC) will not be compatible with other compilers such as Borland because of a technique called name decoration (or name mangling).

The second problem is compatability with platforms:
This is the first time I have attempted dynamic linking with linux/unix. I am fairly confident with dynamically accessing exported functions...but as far as classes and objects are conserned I think I am going to have a lot of problems with dynamic linking.

I have been searching extensively on the net, and I am gradually drowning in confusion Dead | X|

. The only solutions I can find are pretty extreme:
- Convert all of my C++ libraries to ANSI C libraries. (defies some of my design objectives and generally not a good solution, but on the bright side some things would execute more efficiently)

- Find another low-level OOP language which does meet my needs. (makes my target audience smaller)

- Extend my scripting engine into a full-blown language by translating into assembly code and then assembling using a third-party assembler such as FASC. (a very big and complex task which i would rather avoid, but would stoop to if absolutely 100% necessary).

The ideal solution for me would be a standard name mangling convention (without the use of an interface which would seriously damage performance) which works across a wide range of platforms including win32 and linux/unix.

I look forward to hearing your ideas. Smile | :)

Lea Hayes

I've run into everything you're experiencing. Fun stuff....not!

lhayes00 wrote:
I am told that DLL's compiled with Microsoft Visual C++ (without MFC) will not be compatible with other compilers such as Borland because of a technique called name decoration (or name mangling).

Absolutely correct. To use you C++ DLL, you need to match compiler vendor (and probably version as well), in addition to having the same linkage model (i.e. whether or not you're linking the CRT statically or dynamically). Alternately you can use COM and completely get around this.

You will not be able to use a binary object (i.e. a dll/shared obj, etc) compiled on one platform on another. In other words, you can't use a DLL compiled on Windows and hope to link to it dynamically on linux. For a whole bunch of reasons.

Like I said one option is COM. Alternately the Mozilla project produces XPCOM which works on linux/Win32/OSX, etc. However you still can't share the binaries between platforms (if that's something you're hoping to do).

¡El diablo está en mis pantalones! ¡Mire, mire!

Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!

SELECT * FROM User WHERE Clue > 0
0 rows returned

Save an Orange - Use the VCF!
VCF Blog

I have just looked up XPCOM on the Mozilla website and it looks quite promising! My next task is definately to read through the PDF book provided on the XPCOM website.

Thank you very much! Cool | :cool:

Lea Hayes

As ur requirement is simple and just require to export a Class from DLL, i think the complete COM framework is not needed, use the basic stuff, export single c funtion to create an instance of class,

CYourDLLClass *pObjOfDllClass = NULL;
CreateDLLClassInstance((void **)&pObjOfDllClass); //exported C function.

then use pObjOfDllClass as normal Class object.

Hi,

If an object of a class is created from an exported function, surely all functionality would need to be exported using C style functions (where the object pointer is treated as a handle). If exported classes are used, DLL's compiled with a different brand/version of C++ compiler will be unable to import class members due to the problems with name mangling.

Appologies if I have missunderstood what you have said.

Thanks for your reply,
Lea Hayes

i meant u don't need to export class, only one C function to create an instance of the class object, COM does this. COM uses DLLGetClassObject to create an instance of the factory method interfaces.
say,

BOOL CreateDLLClassInstance(void **ppClassObj); // exported C function to create an instance note type is void ** and no class declaration is visibly exported.

lhayes00 wrote:
If an object of a class is created from an exported function, surely all functionality would need to be exported using C style functions

this exported function is not part of the class, the function is outside the namespace of the class.

lhayes00 wrote:
where the object pointer is treated as a handle

just typecast the HANDLE to your object class type.

Ahh rite now I see what you mean!

Thank you for clarifying, I am sure that I can put this to use Cool | :cool:

Lea Hayes

Depending on the design of your library, a good solution would be to make C entry points into it, using a technigue called "flattening[^]", thus exposing the C interface while keeping the C++ internal implementation.

Programming Blog

utf8-cpp

Cheers! this is an interesting solution, I have read through the page you linked me to and I think this is something which I can apply in areas of my application.

Thanks for your help! Cool | :cool:

Lea Hayes

hi, i have created three edit controls with that when i press tab for the first one the focus should go to the second and if the tab is pressed in the second edit control it should go to the thrid...
i can get the window on which the tab is pressed but i want to find the next control so that i can send the focus to that... i dont want to use more if's to get this... is there a function like getnextwindow or child window... ? Confused | :confused: