DLLMain defined in .obj file?

georgeob

Does anyone know if when you use the wizard to create a dll in visual c++, it puts the definition of DLL_Main in the Project_Name.obj file I get an error when I add in a definition of it in the cpp file, saying its already defined in the obj file. It's not in the cpp file when I first create the workspace.

Mike Danes

Hmm... the wizard for DLL project automatically adds DllMain (it's DllMain and not DLL_Main) in a cpp file that has the same name as the project so obviously you'll end up having DllMain in an obj file that has the same name as the project. But you should easily see that cpp file, it's the only cpp file added by the wizard (except stdafx.cpp) and it's opened by default when the wizard ends. So what's the problem more exactly

georgeob

The wizard isn't creating the DLLMain entry point in the cpp file, but the calling program (in VB) still is able to call the dll function. I don't understand how this can work, and I am concerned that there will be problems with it down the road.

Viorel.

According to MSDN documentation, the DllMain function is "an optional entry point into a dynamic-link library (DLL)." [http://msdn.microsoft.com/library/default.asp url=/library/en-us/dllproc/base/dllmain.asp]. Therefore a DLL does not seem to need the DllMain function.

 

Mike Danes

"The wizard isn't creating the DLLMain entry point in the cpp file"

But what does the wizard add in the cpp file Are you sure you are using the DLL wizard

"but the calling program (in VB) still is able to call the dll function"

Do you mean that you are calling DllMain from VB explicitly ! You should not do this, it's the system's job to do it.

georgeob

The cpp file is as follows:

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

#include "stdafx.h"
#include "q.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.
//

/////////////////////////////////////////////////////////////////////////////
// CQApp

BEGIN_MESSAGE_MAP(CQApp, CWinApp)
//{{AFX_MSG_MAP(CQApp)
// 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()

/////////////////////////////////////////////////////////////////////////////
// CQApp construction

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

/////////////////////////////////////////////////////////////////////////////
// The one and only CQApp object

CQApp theApp;

int CQApp::summer(int num1, int num2)
{

}

Yes, I am definately using the wizard. No, I am not calling the DLLMain function from VB, just the summer function. It works fine without the DLLMain in cpp file and without the _stdcall decorations on the function declarations, but I am not sure if this is acceptable in the long run. I am told by another programmer, and various websites that you need them. I got onother version to work the other day, with the DLLMain function in the cpp file and it did have the _stdcall decoration on it, but the summer function declaration did not have the _stdcall decoration on it. This is more like what I expected to work, but not quite, without the decorations on both functions.

Mike Danes

Ah, the return of the summer function

This is a MFC DLL. It does not need DllMain, DllMain is provided by MFC.

And you say that you can call summer from VB !! I have no idea how come that it works. summer function here is a member of a class and for various reasons (calling convention is thiscall and not stdcall or cdecl and the name of the function is decorated) you cannot call this (easily) from any other language than C++.

And what version of Visual Studio are you using This does not look like what VS 2005 generates.

georgeob

version 6.0

Mike Danes

OK, another question to clarify this. You are using VBA in Office, not VB6 and not VB.NET

georgeob

Its Microsoft Visual Basic 6.0 in Micrsoft Visual Studios 6.0. I'm not sure if that answers your question. Does it

Mike Danes

In fact yes. I'm not much of a VB user (be it VB6 or VBA or VB.NET) but as far as I know in VB6 and VBA Integer is 16 bit, not 32 like in VB.NET so I was wrong in the other thread. You need to use Long on the VB part, not Integer. On the C/C++ you can use long or int, it does not matter because both are 32 bit in size.

So in the end the VB part shoud look like this:

Private Declare Function summer Lib "D:\Projects\Tests\Forums\geob\debug\geob.dll" (ByVal num1 As Long, ByVal num2 As Long) As Long

and for the C++ part do the following:

Create a new DLL (Win32, not MFC) and delete everything from the cpp file except the #include "stdafx.h" line if you have one. After that add this to the cpp file (after the #include "stdafx.h" line):

long __stdcall summer(long a, long b) // I'm using long to be consistent with the VB part but int should also work

{

long result;

result = a + b;

return result;

}

One more step for the C++ project, add a .def file with the same name as the project (probably geob.def) and put the following lines in that file:

LIBRARY geob

EXPORTS

summer

This is not much different from the answer you got in the other thread except that I'm trying to keep things simple about the cpp file, no DllMain, no exported classes or variables, it contains only the function that you need. I'd merge these 2 threads but last time I tried this the result was kind of messy so I'll let them be.

georgeob

Thanks Mike, that worked