Turning a legacy MFC DLL project into EXE

Recently I had to convert a MFC DLL project to EXE. At first, this appears to be an easy task, since MFC abstracts the entry point of the application, right? The answer, as always with MFC is an awkward “yeeeaah…. but”. In this post I’m detailing all the steps that need to be taken to successfully convert your DLL into a EXE project, possibly saving some hairpulling if you need to do the same.

During this project I used Microsoft Visual Studio 2010, but the steps most likely apply to later versions as well (and possibly older ones, too).

The obvious

The most obvious step is changing the configuration type of the project from DLL to EXE. To do this, open its properties (right click in the Solution Explorer -> Properties), then go to Configuration Properties -> General.

config_type

In the linker settings you will (probably) need to set the subsystem to Windows. I’m saying probably, because if you have an MFC DLL project there is a good chance it has some sort of GUI^(if not, it might be a good idea to evaluate the cost of ditching MFC).

To change the subsystem, (in the same dialog as above) go to Linker -> System and change the SubSystem setting:

subsystem_type

So far, so good. In an ideal world, this would be all. Unfortunately, there are some additional steps.

The not-so-obvious

Remember how I mentioned in the introduction that MFC hides the application entry point? That is true and it does so by selecting the proper entry point in its source via preprocessor macro. That means if your project defines _AFXDLL or _WINDLL, you have to get rid of them; otherwise your exe will be linked with a DLL entry point and be impossible to run. In the configuration properties, look at C/C++ -> Preprocessor -> Preprocessor Definitions. I also suggest searching through all project files for these strings and dealing with any instances individually.

Secondly, there is a good chance that you MFC DLL project does not have a main window. But now that it’s a normal application, it will need one. If you don’t have a main window, many MFC functions will crash/fail an assertion or kill a puppy. However, often you don’t really want to create a main window, you just want to run your application-like DLL without a host process. Perhaps only displaying GUI when something special happens.

There are some ways to circumvent this. Unfortunately most of these ways involve writing lots of boilerplate due to the questionable design of MFC. My suggestion is to create and use an invisible window, something like this:


BOOL CMyMFCApplication::InitInstance()
{
    CWnd* mainWindow(new CWnd);
    mainWindow->m_hWnd = NULL;
    if (!mainWindow->CreateEx(0, AfxRegisterWndClass(0),
	_T("Hidden Window of MyMFCApplication"), WS_OVERLAPPED, 0, 0, 0, 0, NULL, NULL))
    {
	logError("Could not create hidden window :(");
    }
    m_pMainWnd = mainWindow;

    return TRUE;
}

One word of advice: make sure that you have a way of exiting your application. From here on, the application runs as long as the main window is open, which is hard to close when it’s hidden.

An optional step

Just to be sure, check the Linker -> General -> Output File setting. It might be hardcoded to a DLL filename. This is an error that the compiler does not report (it happily says that that your exe output is build with a particular filename when in fact it is not). The correct value is $(OutDir)$(TargetName)$(TargetExt) which you only need to change in rare cases.

The hairpulling

Now comes the fun part. If you did all of the above, your application will be built as an exe. However, when you try to run it, you will get an “Access Denied” or “invalid win32 executable” error. If you inspect the output of dumpbin /headers you will be horrified to learn that your EXE is still, in fact a DLL!

Dump of file MyMFCApplication.exe

PE signature found

File Type: DLL

FILE HEADER VALUES
             14C machine (x86)
               8 number of sections
        55BF7F4D time date stamp Mon Aug 03 16:48:45 2015
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
            2102 characteristics
                   Executable
                   32 bit word machine
                   DLL

OPTIONAL HEADER VALUES
             10B magic # (PE32)
           10.00 linker version
          B47600 size of code
          F7AC00 size of initialized data
               0 size of uninitialized data
          5841D6 entry point (105841D6) @ILT+61905(__DllMainCRTStartup@12)
            1000 base of code

What happens here? After copious amount of debugging I found that this is a Visual Studio 2010 bug (other versions might be affected, too). The problem is that even though the configuration type was changed in the project properties, there is still a flag that remained unchanged. To change it, you need to open your .vcxproj file in your favorite text editor and look for the XML tag <LinkDLL>. Change its value in all configurations where you want to build an EXE:


    <Link>
      <SuppressStartupBanner>true</SuppressStartupBanner>
      <LinkDLL>false</LinkDLL>
    </Link>

And that’s it! Now you should be able to run your application that was created from a DLL.

Emulating the static initialization blocks of Java in C++

What is a static initialization block?

In Java, there is a language construct called a static initialization block. The static initialization block will be called the first time the class is loaded by the Java runtime. For example, consider the following code snippet1:

Continue reading


  1. The highlighting in this code snippet is different because highlight.js had problems with this rarely used construct. As a workaround, I used a GitHub Gist for displaying this snippet. 

Rarely known C++ constructs (part 1): Function try blocks

C++ has some language constructs that are rarely seen in use. These constructs have their own, valid uses, but should be used sparingly. As the now adage-status quote from The Old New Thing says:

Code is read much more often than it is written, so plan accordingly

In this series we will take a look at different instances of unusual C++ language constructs, shortly explaining their use-cases, syntax and pitfalls.

UPDATE: the series was moved to Dr. Dobbs! The rewritten, expanded first part is available here.

Implementing a code generator with libclang

[DOI: 10.5708/szelei.2014.A.1]

Introduction

Click here to skip the introduction and see the code.

The following article covers the process of implementing a practical code generator for C++ in detail. You can find the full source code for the article on GitHub.

A code generator is a very useful asset in a larger C++ project. Due to the lack of introspection in the language, implementing the likes of reflection, script binding and serialization requires writing some sort of boilerplate that essentially keeps the data which is otherwise thrown away by the compiler. These solutions are either intrusive (heavily macro-based, thus hard to debug and require weird syntax in declarations) or fragile (the boilerplate must be constantly updated to follow the actual code, and might break without warning). One way to improve the robustness is to automate writing this boilerplate. In order to achieve this, we need to parse the code somehow, in other words, understand what information to keep. However, parsing C++ is an extremely complex task, and with the copious amount of weird corner cases, we are in for quite a ride if we attempt to do so. Continue reading