MFC in Max External

    Jul 30 2013 | 4:10 pm
    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?

    • Jul 31 2013 | 2:19 pm
      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.
    • Jul 31 2013 | 3:49 pm
      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
    • Jul 31 2013 | 4:02 pm
      Thanks Rob. I've removed dllmain_win.c.
      Unfortunately I'm now getting:
      error LNK2005: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj)
    • Jul 31 2013 | 4:12 pm
      Interestingly for a release build I instead get:
      error LNK2005: _DllMain@12 already defined in maxcrt.lib(dllmain.obj)
    • Jul 31 2013 | 4:18 pm
      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:;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.
    • Jul 31 2013 | 4:20 pm
      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.
    • Jul 31 2013 | 4:51 pm
      OK, this seems like a non-Max related error now. Currently I am including stdafx.h first, so will have to investigate...
    • Jul 31 2013 | 5:09 pm
      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.