Writing an MFC Dll Without Namemangling...

[SWilliams15]

I have a simple regular shared MFC DLL that I'm trying to compile and call routines from another language. The problem I'm having is that I can't get the dll to compile without mangling the names of the the exported class and class methods. I can compile a regular DLL (no mfc) without name mangling, but not using the same technique in a regular dll using MFC.

Does someone know how to eliminate name mangling in exported class and class methods in a shared MFC DLL?

Thanks,
Sean.

 

[Guest_imported]

use extern "c" your_dll_func_name(...)
and export this function

 

[palbano]

> call routines from another language.
> exported class and class methods.

I'm not sure I understand. You want to use the exported classes and methods in another language? That can't be done. An exported MFC C++ class can only be used in C++ code.

-pete

 

[SWilliams15]

Thank you both for responding. I tried the first suggestion (extern "C&quot and I was still getting the name mangling. I don't know if what I want can be done. I have a basic-like language (assume it's VB) and I want to call exported functions from an MFC dll (dynamically linked -- 2nd radio button in project setup list). The books, I think, say I can do this if the functions are exported correctly. So far, I haven't found how to do that.

So I thought I would include the code (cut and paste into a word processor -- ie wordpad -- to get a cleaner view). There is a .h and .cpp file. I am trying to call the SHOWIT function from VB with the code at the bottom of the this file. I am getting a BAD DLL CALL error when it runs.

Regards,
Sean

/**===============================================================**

// MFC_EL.h : main header file for the MFC_EL DLL
//

#if !defined(AFX_MFC_EL_H__9DEF8B8A_DCE0_11D4_BCA2_000102257065__INCLUDED_)
#define AFX_MFC_EL_H__9DEF8B8A_DCE0_11D4_BCA2_000102257065__INCLUDED_

#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000

#ifndef __AFXWIN_H__
#error include 'stdafx.h' before including this file for PCH
#endif

#include "resource.h" // main symbols

/////////////////////////////////////////////////////////////////////////////
// CMFC_ELApp
// See MFC_EL.cpp for the implementation of this class
//

class CMFC_ELApp : public CWinApp
{
public:
CMFC_ELApp();
int __stdcall CMFC_ELApp::SHOWIT(int t);

// Overrides
// ClassWizard generated virtual function overrides
//{{AFX_VIRTUAL(CMFC_ELApp)
//}}AFX_VIRTUAL

//{{AFX_MSG(CMFC_ELApp)
// NOTE - the ClassWizard will add and remove member functions here.
// DO NOT EDIT what you see in these blocks of generated code !
//}}AFX_MSG
DECLARE_MESSAGE_MAP()
};


/////////////////////////////////////////////////////////////////////////////

//{{AFX_INSERT_LOCATION}}
// Microsoft Visual C++ will insert additional declarations immediately before the previous line.

#endif // !defined(AFX_MFC_EL_H__9DEF8B8A_DCE0_11D4_BCA2_000102257065__INCLUDED_)


//**===============================================================**

// MFC_EL.cpp : Defines the initialization routines for the DLL.
//

#include "stdafx.h"
#include "MFC_EL.h"

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

//
// Note!
//
// If this DLL is dynamically linked against the MFC
// DLLs, any functions exported from this DLL which
// call into MFC must have the AFX_MANAGE_STATE macro
// added at the very beginning of the function.
//
// For example:
//
// extern "C" BOOL PASCAL EXPORT ExportedFunction()
// {
// AFX_MANAGE_STATE(AfxGetStaticModuleState());
// // normal function body here
// }
//
// It is very important that this macro appear in each
// function, prior to any calls into MFC. This means that
// it must appear as the first statement within the
// function, even before any object variable declarations
// as their constructors may generate calls into the MFC
// DLL.
//
// Please see MFC Technical Notes 33 and 58 for additional
// details.
//

/////////////////////////////////////////////////////////////////////////////
// CMFC_ELApp

BEGIN_MESSAGE_MAP(CMFC_ELApp, CWinApp)
//{{AFX_MSG_MAP(CMFC_ELApp)
// NOTE - the ClassWizard will add and remove mapping macros here.
// DO NOT EDIT what you see in these blocks of generated code!
//}}AFX_MSG_MAP
END_MESSAGE_MAP()

/////////////////////////////////////////////////////////////////////////////
// CMFC_ELApp construction

CMFC_ELApp::CMFC_ELApp()
{
// TODO: add construction code here,
// Place all significant initialization in InitInstance
}

/////////////////////////////////////////////////////////////////////////////
// The one and only CMFC_ELApp object

int __stdcall CMFC_ELApp::SHOWIT(int t)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());

t = t + 40;

return t;

}



VB CODE:

Declare Function SHOWIT Lib "c:\mfc_el.dll" (iItemNo As Integer) As Integer
'Rem

Sub Main()

Dim y As Integer
Dim T As Integer

y = 10

T = SHOWIT

Debug.Print (T)

End Sub

 

[Sans]

I've heard of them before, but I've never tried using them. Why not a namespace? I'm new to Visual C++, so if a namespace is obviously out of the question forgive me. Ignorance is the night of the mind
but without the light of a moon or star

 

[palbano]

> language (assume it's VB) and I want to call exported functions from an MFC dll

Well, I am not 100% sure but I don't think that an MFC dll can be used in any .exe besides an MFC .exe, however...

Even if it can you certainly can not do what you are trying, i.e.:

> int __stdcall CMFC_ELApp::SHOWIT(int t)
that is a member function of class CMFC_ELApp

Declare Function SHOWIT Lib "c:\mfc_el.dll" (iItemNo As Integer) As Integer
**** That VB code declares a function 'SHOWIT' that does not exist in the DLL because it only exists as a member function of class 'CMFC_ELApp'. VB code cannot create an object instance of 'CMFC_ELApp' or any other C++ class.

Furthermore the obvious test code in your C++ function CMFC_ELApp::SHOWIT is not even using MFC. Perhaps you need to create a standard DLL with exported global 'C' functions that can be called from languages that support 'C' parameter passing (VB). In that case you would use the 'extern' notation described in the previous post.

Hope this helps
-pete

 

[JimmyK]

Hi,

- To make sure that the EXPORT FUNCTION NAME exist, use tool "DEPENDS"

- To avoid mangling, plz export explicitly in.DEF file
EXPORTS
entryname[=internalname] [@ordinal[NONAME]] [DATA] [PRIVATE]


Hope this help

Jimmy mailto:nhan_tiags@yahoo.com

 

[JoshClark]

Palbano, I think he's talking about importing functions from DLLs in a language other than C++. (ie VB COM objects)