MFC in Max External

David Butler's icon

I'm trying to implement some existing code into a Max external which uses MFC. I know that 'windows.h' is already included in the Max SDK, and these two aren't supposed to be used together.

Basically, am I wasting my time on this? I'm including 'stdafx.h' first to avoid errors due to use of 'windows.h', but am now getting the following error:

error LNK2005:_DllMain@12 already defined in dllmain_win.obj

Is there a fix for this? Will this ever work?

Peter Castine's icon

I'm not an MFC expert, but I understand that it provides some kind of default application framework. And any application framework is going to have a main(). But your external also has a main(). You can't have two functions named main() (which is what your linker is complaining about).

You may be able to avoid this by carefully selecting what libraries are linked in. Dunno.

Using MFC is likely to kill any chance of cross-platform compatibility, but you presumably don't care about that.

Rob Sussman's icon

MFC provides its own DllMain. The max externals in the SDK also provide their own DllMain. Hence, your external has two and you are getting this error.

The good news is that the DllMain provided in the max sdk samples doesn't actually do anything except for a small optimization that you probably don't even want if you are using MFC. So to fix this problem you can probably just remove dllmain_win.c from your project.

Hope that helps,
Rob

David Butler's icon

Thanks Rob. I've removed dllmain_win.c.

Unfortunately I'm now getting:

error LNK2005: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj)

David Butler's icon

Interestingly for a release build I instead get:

error LNK2005: _DllMain@12 already defined in maxcrt.lib(dllmain.obj)

Rob Sussman's icon

Sounds like the link order is not correct so there is a conflict between MFC and the MS CRT.

Googling the above error brings up plenty of articles that may be helpful for you including this MS KB article:
http://support.microsoft.com/default.aspx?scid=kb;en-us;q148652

But one page suggests this simple fix:

In most cases it its sufficent to place the #include as the first header file that is included in the stdafx.h.

And, once you go to get your release build working I suggest you add this preprocessor flag to your project settings:

#define MAXAPI_USE_MSCRT

This will cause your object to link to the standard microsoft CRT rather than the shared maxcrt.dll that we ship with max. You can see what that switch does by looking in ext_prefix.h.

Rob

Rob Sussman's icon

Our posts crossed in the air. You said:

Interestingly for a release build I instead get:

error LNK2005: _DllMain@12 already defined in maxcrt.lib(dllmain.obj)

Yes, my prior post anticipated this. :) Once you add MAXAPI_USE_MSCRT to your project you will get an error more similar to the debug one.

Rob

David Butler's icon

OK, this seems like a non-Max related error now. Currently I am including stdafx.h first, so will have to investigate...

David Butler's icon

Suppress default library for the offending .obj file. Use /Zl for the .cpp file: C/C++ Advanced | Omit Default Library Name – Yes (/Zl). The results in the .obj file without any default library records. Therefore, linker would follow default libraries and their order from other .obj files, and hopefully they are correct in the sense of an MFC application. If the offending .cpp file relies on other default libraries for its own right, if /Zl is used on it, we have to add back explicitly those libraries to linker options.