How to build the 7.1 MFC and the CRT DLLs with MSLU

by Michael S. Kaplan, published on 2004/12/07 00:10 -05:00, original URI:

The MSDN documentation generally recommends that you use the static versions of libraries like the C Runtime (CRT) or the Microsoft Foundation Classes (MFC). The reason for this is that the DLL versions have not been built for MSLU and thus have no knowledge of the need to use the Microsoft Layer for Unicode for Unicode APIs. However, many complex applications really need to use the DLL versions of these libraries. If you are the developer for one of these applications, you will need to rebuild them so they link with Unicows.lib. The following is a small guide on how to perform this task.

This document is divided into 3 parts

  1. How to build the C Runtime Library 7.1 with MSLU
  2. How to build MFC 7.1 with MSLU
  3. Switching between non MSLU builds and MSLU builds
The fine print

For more info on rebuilding MFC extension DLLs, see TN033: DLL Version of MFC, specifically the section entitled "Building the MFC DLL" towards the bottom of the article. Our steps here seem a lot nicer. :-)

All of these steps were used to build DLLs that were subsequently tested on Win98 SE. They are expected to work on all platforms.

Special thanks are owed to Ted W. for taking the time to do what we all knew was theoretically possible and making it technically possible for everyone. This document is mostly due to his efforts. Thanks, Ted!

In all instructions below, the assumption is a default install path and an en-US copy of Windows; if either is not the case, make sure you replace paths such as C:\Program Files\Microsoft Visual Studio 2003 with the appropriate install location.

Also, special thanks to Tim Dowty of Music Match for the great text of step #4 under the MFC build!

Before you start:

  1. Install Visual Studio .NET 2003 including all necessary files.

    The first thing you need to do is make sure that when you install Visual Studio .NET 2003 that you make sure both the Unicode MFC version and the CRT source code are installed.

  2. Identify the folders and files you will be modifying.

    If you installed to the default locations, all of the files we need to change are contained in the tree \Program Files\Microsoft Visual Studio .NET 2003\VC7. Find the ATLMFC\SRC folder and the CRT\SRC folder.

  3. Install the Platform SDK and copy the latest unicows.lib file to your VC7\PlatformSDK\LIB folder. Since VC7 comes with a unicows.lib, this step is optional, although it is good to be on the latest unicows.lib from the most recent Platform SDK.

How to build the CRT 7.1 with MSLU

The first thing we want to do is make a backup of our VC7\Lib folder. We will be replacing files in it, so if we need to go back (or switch between MSLU and non-MSLU version of the CRT) we can always do that.

Secondly, let's copy the VC7\CRT\SRC folder to a comfortable place so we can change it and build from it. For example, we'll copy it to the root of C: so we have a folder called C:\SRC, available for quick access from the command line.

When building the CRT we are actually building two DLLs: MSVCR71.DLL and MSVCP71.DLL. Since we are building both debug and release builds it makes a total of four DLLs we need to build.

In the SRC folder, there is a provided batch file bldwin9x.bat that will build the all CRT DLLs and an associated makefile.

Now we will open up the makefile in notepad. At the top of makefile there is a section that controls the naming of the two DLLs to build. For this purpose we will use the name MSLU as a prefix to all of the DLLs instead of the standard name MSVC. So the four names of the DLLs we will create are:


Warning: Since most people who follow these steps will probably use the exact names given here, please be sure to keep these versions of the DLLs in your own private directory when you use them.

The default names provided in the makefile are _SAMPLE_ and SAMPLE_P. There are associated RC and DEF files for each of these names, so we need to copy them to the new names, i.e.

copy Intel\_SAMPLE_.DEF Intel\MSLUR71.DEF
copy Intel\_SAMPLD_.DEF Intel\MSLUR71D.DEF

Next we need to change the LIBRARY name in each of the above DEF files to match the name of the DEF file. Open up each file in notepad to make the change.

The provided makefile needs some minor changes to get it to work properly and link with Unicows.lib.

  1. Change the top block of defines to the following:
  2. The VCTOOLS path should be changed to point to the path where you installed Visual Studio .NET 2003, e.g.

    VCTOOLS=C:\Program Files\Microsoft Visual Studio .NET 2003\VC7

  3. We want to link to unicows.lib before any other lib files.

    line 1216, 1268, 1315, 1364 change kernel32.lib to:

    unicows.lib kernel32.lib advapi32.lib user32.lib gdi32.lib shell32.lib comdlg32.lib version.lib mpr.lib rasapi32.lib winmm.lib winspool.lib vfw32.lib oleacc.lib oledlg.lib 
  4. Once we make these changes, we are ready to build the DLLs. It's simple – launch a Visual Studio .NET 2003 command prompt (start menu-programs-Visual Studio .NET 2003 – Visual Studio .NET 2003 tools – Visual Studio command prompt) and then go to the C:\SRC folder and type:

    set VCTOOLS=C:\Program Files\Microsoft Visual Studio .NET 2003\VC7 

    Once the DLLs finish building they will be in a subfolder called BUILD\INTEL. The Libs, PDBs, and Maps are also in that folder.

  5. Now we've got 4 libs (2 debug, 2 release) we can link to. Let's copy those new libs back to the original names of the libs, e.g.

    The reason we do this is so we can link our existing apps (and build MFC) without having to change the libraries that they link to. The Libs still point to the newly named DLLs, even though they don't share the same names as the new ones anymore.

  6. Now copy the 4 MSVC libs to the VC7\Lib folder (overwriting the existing ones)

  7. Repeat step 4. This step is necessary to rebuild MSLUP71(D).DLL again so it links to our newly created MSVCRT(D).LIB (which points to our new MSLUR71(D).DLL).

The CRT build is now done.

Before proceeding any further we need to close the command prompt that we used to build the CRT because it created certain environment variables that will cause compile errors in the next step, building the Unicode version of MFC.

Building MFC 7.1 Unicode version with MSLU

First we will make a backup of the following folders (and all subfolders of): VC7\ATLMFC\LIB, and VC7\ATLMFC\SRC so we can restore them later if necessary.

Building the Unicode version of MFC is slightly easier than building the CRT. The Unicode version of MFC is 2 different DLLs (unlike the 5 different DLLs that we had to worry about when building MFC 6.0):

There is also a static component to even a DLL build of MFC, named as follows:

To build MFC, there is one master Makefile in the VC7\ATLMFC\SRC folder named:

And there is one Makefile in the VC7\ATLMFC\SRC\MFC folder named

  1. First, we will change the MFCDLL.MAK file to link to Unicows.lib. In each file, after the line that states:
    link @<<

    insert the following lines:

    /nod:kernel32.lib /nod:advapi32.lib /nod:user32.lib /nod:gdi32.lib /nod:shell32.lib /nod:comdlg32.lib /nod:version.lib /nod:mpr.lib /nod:rasapi32.lib /nod:winmm.lib /nod:winspool.lib /nod:vfw32.lib /nod:secur32.lib /nod:oleacc.lib /nod:oledlg.lib /nod:sensapi.lib 
    unicows.lib kernel32.lib advapi32.lib user32.lib gdi32.lib shell32.lib comdlg32.lib version.lib mpr.lib rasapi32.lib winmm.lib winspool.lib vfw32.lib oleacc.lib oledlg.lib

    They must go in that position, if we don't do this then a library reference will be included causing unicows.lib to be linked after kernel32.lib (which will then cause the unicows.dll load to fail). Other DLLs in the wrong order will simply cause APIs in those specific DLLs to not be called.

    The line number to insert the above two lines after is line 273.

  2. Now, we will decide what to name our new DLL. We do not want to use the standard name(s) for the same reasons we did not use the standard names for the CRT. So we will come up with a simple naming convention: we'll add an "L" to the name. So the new names will be:

    • MFC71LU.DLL
    • MFC71LUD.DLL

  3. Now we're ready to build the versions of MFC:

    From a Visual Studio .NET 2003 Command Prompt, create a new batch file called buildmfc.bat in the ATLMFC\SRC folder with the following content:

    nmake -f atlmfc.mak MFC libname=MFC71L

    This will build all MFC libraries, not just the Unicode DLLs, but it will save us the effort of figuring out how to use the MFCDLL.MAK makefile.

    Run the batch file. If you need to rebuild any time in the future you now have a convenient batch file to do so. The DLL and PDB files will be created in the VC7\ATLMFC\SRC\MFC\INTEL folder. The LIB files will be created in the ATLMFC\LIB\INTEL folder.

  4. There is one crucial step missing from the supplied MFC makefiles. If you take a look at line 425 of …vc7\mfc\makefile, you’ll see that one of the options passed to the compiler is /Zc:wchar_t, which causes wchar_t to become an implicit type. This may be what you want, but if the application you’re linking the lib to wasn’t compiled with this same option (and -- therefore -- has wchar_t #defined to unsigned short), you will get unresolved externals when you link. Your program is looking for function signatures with unsigned shorts in them, but the lib only exports wchar_t in the function signatures.

    You could remove the /Zc:wchar_t from the makefile, but this solution isn’t universal; it would still prevent linking with programs compiled with the /Zc:wchar_t switch.

    A better solution is to do what Microsoft did in the original mfc71 libraries: include alias records in the library so that you can link both implicit wchar_t and unsigned short programs. Alias records allow a library to export multiple function signatures that resolve down to the same object code.

    So how do you add alias records to your newly-built MFC libraries?

    For both the debug and release MFC library libraries you need to do the following:

        a) Extract all of the alias records from the corresponding retail MFC library

        b) Create a new library comprising only these alias records

        c) Merge your new Unicows-compliant MFC library with the associated alias-record library

    Step A)

    This one requires a small detour because lib.exe only allows you to extract one object at a time. We want to automate this step by creating a batch file to do all of the extractions.

    First, get a command prompt and make …\Vc7\atlmfc\lib your current directory. Next, create a list of all of the alias records in both debug and release MFC libs using the following two command lines:

    lib /LIST mfc71ud.lib > mfc71ud.lib.lst
    lib /LIST mfc71u.lib > mfc71u.lib.lst

    You should now have the two .lib.lst files that each contain a list of library objects, one per line.

    Now, we will create a perl script to build a pair of batch files from the .lib.lst files (if you don’t already have perl, it’s freely available from several sources. You can find Perl here).

    Start up a text editor and enter the following text:

    # builds a batch file to extract all alias records
    # in the input file (input file created with lib.exe /LIST)
    $targetLib = "mfc71ud.lib"; $outDir = "_aliasRecordsD";
    print "md .\\$outDir\n";
    while (<>) {
    # find alias record name if (/_alias[0-9]+\.obj/) { chop;
    print "LIB /EXTRACT:$_ /OUT:.\\$outDir\\$_ $targetLib\n"; } }

    Save the text as

    Now edit the text so that the $targetLib variable is changed as follows:

    $targetLib = "mfc71u.lib";

    also change $outDir as shown:

    $outDir = “_aliasRecords";

    Save the edited text as

    Now run the two perl scripts as follows from the command prompt:

    perl mfc71ud.lib.lst > BuildAliasExtractD.bat
    perl mfc71u.lib.lst > BuildAliasExtract.bat

    At this point you have two batch files, one of which will extract the alias records from the debug library and one that will extract from the release library.

    To complete step a) all that’s left is to run the batch files. Note that there are about 2000 alias records in each MFC library, and extracting them one by one is a slow process; each library extraction took about 4 hours on a fast PC.

    At the completion of this step, you will have two new directories under …\vc7\atlmfc\lib each of which contains extracted alias records. Each extracted alias record is a file with a name of the form _alias*.obj where * is one to four decimal digits.

    Step B)

    For Step b), we want to create a new library from the extracted records. Fortunately, this can be done in two simple steps; in contrast to Step a) we can use a response file with lib.exe to simplify our operation.

    First, we create a pair of perl scripts that will build the response files.

    Use your favorite text editor to enter the following text:

    # builds a response file for lib.exe to build a library of
    # alias records. (input file created with lib.exe /LIST)
    $outLib = "mfc71udAlias.lib";
    $aliasDir = "_aliasRecordsD";
    print "/OUT:$outLib";
    while (<>) {
    # find alias record name if (/_alias[0-9]+\.obj/) { chop;
    print " .\\$aliasDir\\$_"; } }

    Save the file as

    Now edit the variable declarations so they read:

    $outLib = "mfc71uAlias.lib";
    $aliasDir = "_aliasRecords";

    and save the file as

    Run the perl scripts from the command line. Note that we reuse the .lib.lst files we created in Step A) as input here:

    perl mfc71ud.lib.lst > mfc71udAlias.rsp
    perl mfc71u.lib.lst > mfc71uAlias.rsp

    With the response files made, we now use them with lib.exe to create the alias libraries:

    lib @mfc71udAlias.rsp
    lib @mfc71uAlias.rsp

    At the completion of this step you will have two new libraries: mfc71udAlias.lib and mfc71uAlias.lib. They will each contain their respective alias records.

    Step C)

    In this step, we simply merge our custom-built MFC libraries with the alias libraries we just made. While we’re at it, we’ll also rename the libraries so they’ll replace the original libraries. Note that we get our custom-built libraries directly from their output locations.

    lib /OUT:mfc71ud.lib .\Intel\MFC71LUD.lib mfc71udAlias.lib
    lib /OUT:mfc71u.lib .\Intel\MFC71LU.lib mfc71uAlias.lib

  5. After the building is done, we need to copy the rest of the created LIBs in the VC7\ATLMFC\LIB\INTEL folder back to their original names in VC7\ATLMFC\LIB (overwriting what's there) so that any of our apps that we link will use the new DLLs. i.e.
    copy MFC71LSU.LIB MFCS71U.LIB 

    The reason we do this is the same as for the CRT: we don't have to worry about changing any linker options in our projects to link to the new version of MFC. We should also copy the PDB files back from the LIB\INTEL folder back to the LIB folder.

    Now we're ready to do a test build of an application. Create a new SDI MFC application using the AppWizard, choose dynamic MFC, create a Unicode Debug and Release build, change the settings to link to unicows.lib, copy the newly created CRT and MFC DLLs to your DEBUG or RELEASE build folder(s) and then run the application. It should all work.

    Use dependency walker to make sure that everything is getting linked properly and the proper DLLs are being loaded (run a profile in dependency walker). No references to the old names of the DLLs for both the CRT or MFC should be there.

    Switching between non MSLU builds and MSLU builds

    Because we have done all of the above, any Unicode build on your machine will now link to MSLU. We may not want this necessarily, or we may want to link back to the original CRT and MFC DLLs. This is what we made the backups for. To restore the system, simply restore your VC7\LIB and VC7\ATLMFC\LIB folders. You could even make a simple batch file that copies older or newer versions of the LIBs back to the LIB folders depending on what you want to build.

    # Uwe Keim on 27 Dec 2004 10:35 PM:

    Very interesting read!

    # Uwe Keim on 28 Dec 2004 11:50 PM:

    Another suggestion: Would it be possible (i.e. legally ALLOWED) that someone (maybe I can do it by myself) prebuilds the library and makes it available for others to download as a single package so that one would just set up the correct source-, binary- and library paths?

    # Michael Kaplan on 29 Dec 2004 12:09 AM:

    Well, I am not a lawyer, but as far as I know this is not allowed (I made a similar request once when the issue first came up).

    But I can always ask again -- it would really make sense, and be easier for everyone.

    # Uwe Keim on 29 Dec 2004 4:45 AM:

    Thanks, Michael, this would be great!

    I would volunteer to sacrifice some nights/weekends for doing the builds (at least for MFC 7.1) :-)

    Please consider a donation to keep this archive running, maintained and free of advertising.
    Donate €20 or more to receive an offline copy of the whole archive including all images.

    referenced by

    2007/12/24 The 9.0 instructions for building MFC and the CRT to use MSLU?

    2007/01/11 Having problems with MSLU?

    2006/04/15 MFC/CRT build instructions tweaklets

    2006/03/26 Non-default paths and instructions....

    2004/12/07 Rebuilding the CRT and MFC for Unicode on Win9x....

    go to newer or older post, or back to index or month or day