.

There are more settings that need to be asserted to get a locale specific resource build for each of the supported locales but we’ll put that off until after we take care of a more pressing issue, dry cleaners. No, wait, that’s not what I meant to say. I meant that we still only have the default MBCS configurations. We are going to need to come up with some Unicode variations.

 Bring up the Configurations dialog.

 We want to add a new configuration, Unicode Debug.

 Click on Add.

 When the dialog comes up, it displays a name in Configuration that is extracted from the selected value in the Copy settings from: combo box. Every time the combo changes selection, the value in the edit is updated. Remember this for later when you have a gazillion configurations out there and the names have gotten so long that you can’t tell from combo which one is actually selected.

 In this first case, it seems to have given us what we want. Prepend Unicode to the configuration name and click OK.

 Do the same to create a Unicode Release configuration and then close the Configurations dialog.

Add Unicode Settings to Configurations

We now have two new configurations but they are the same as the non-Unicode configurations upon which they are based. That won’t do. We will have to do something about that.

 Open the project settings and select the Unicode Debug configuration. There are a bunch of settings that will need changing and they aren’t going to change themselves. Let’s get cracking.

General Tab

Go to the General tab (Why isn’t there a Colonel or Major Tab as well?) The output directories most likely will need to be changed. For reasons that are not clear, these values will either be generated from the combination of a number of configuration factors and will turn into something ridiculously long or they will be the name of the configuration itself which, oddly enough, just happens to be incompatible with the execution of a build. What we want is <locale>_Unicode_<flavor> where <Locale> is French, German, Italian, Japanese or Spanish. <flavor> is Debug or Release. Oh, yes. Spaces are illegal. Use an underscore in place of a space. The English versions are going to be simply Unicode_Debug and Unicode_Release.

The example, when corrected, looks like this.

We may as well correct the Unicode Release configuration while we’re here as well.

C/C++ Tab

Click on the C/C++ tab and change the compile to Unicode by replacing the _MBCS define with _UNICODE,UNICODE.

Do this for all of the new configurations.

We can ignore debug settings and the like because there is no executable code to care about in this module.

Link Tab

Go to the Link tab and change then name of the DLL to be the name of the base module plus the configuration’s three letter code. In this case, that means getting rid of the ‘res’ and appending ‘ENU’ to the output name.  

There’s one other little thing to be concerned about while we’re here. Where will the output file be written? This is a matter of opinion, debate and conjecture and while it is certainly true that there is no right or wrong answer, anyone who doesn't agree with me is brain dead. I like to put all of my outputs in a single staging area, divided up so that like is with like and never shall the Unicode and MBCS shall meet. If you want to play with the big boys, that is how you will do it, too. So there.  In any case, where ever the main module ends up, that where the resource modules should go, too.

The manner in which the output path is specified is also a matter of some discourse. Some programmers like to define things by environmental variables. Others prefer to keep things completely encapsulated within the project so that any project just builds without doing anything special. Since I’m the one writing this, I get to recommend what I want and I want a relative path as opposed to environmental variables or hard coded paths like brain dead people have sometimes been known to advocate. 

In this example case, let's just assume that there are multiple main modules that are siblings of each other and that all of them put their output into a staging area that is under the parent directory that contains all of the main modules. Further, let's assume that this staging area is divided into a bin and a lib. Further, because we like the word 'further', let's assume that bin is further (there's that word again. Lovely.) divided into Debug, Release, Unicode_Debug and Unicode_Release. That makes the relative path to the output look something like this:

..\..\..\Stage\bin\

 so we will combine this with the output name to get

 ..\..\..\Stage\bin\Unicode_Debug/ConfigSOMAuthenticationENU.dll

 While we’re here, now would be a good time to do the other configurations’ output, too. Notice the plural positive on “configurations”? That’s because we also have to do the original two configurations as well. Even though we don’t plan on using the Release and Debug outputs in the future, we’re using them during the initial development so they need to be created in the same manner as the Unicode configurations.

Finally, this is a resource only DLL. It defaults to making a LIB but we don’t need one. No other project will ever include it so we may as well preclude the LIB’s production for all configurations.

Resources Tab

Click on the Resources tab. Here’s the other half of the resource compile. We need to add AFX_RESOURCE_DLL and a target. The AFX_RESOURCE_DLL will preclude the inclusion of all resources except for the one locale specified by the country target ID. In this first case, the country is the default, US, so the target ID is AFX_TARG_ENU. 

As always, now is a good time to do the other configuration as well. Don’t forget the Debug and Release configurations. 

Check Build

Now would be a good time for a reality check. See if the two MBCS and two Unicode configurations build.

Create Remaining Configurations

Now, assuming that reality was kind to us and things built correctly, it is time to complete populating the rest of the configurations. We need Debug and Release versions of French Unicode, German Unicode, Italian Unicode, Japanese Unicode and Spanish Unicode. These configurations are all identical with the exception of Debug and Release values, the output directories, the output names and the RC target define. Initially, we’ll just make copies of the existing Unicode Debug and Release configurations. That’s why we only made the two in the first place.

This is the order in which we want add the configurations: The order in which they are created is important only in the fact that Dev Studio doesn’t sort them. If the order in which they are entered is disordered then that makes it harder to deal with them in the future.

General Tab

Once the configurations exist, they will need to be tailored. Start up the Project Settings and modify the configuration values, starting with the General Tab. Expect to find something like

SomNIAPlugInRes___Win32_French_Unicode_Debug

Despite the fact that this is such a lovely string, replace it with one of the following:

C/C++ Tab

Because the original configurations were already set up in the C/C++ tab, there’s nothing more to be done there. We can skip that tab.

Link Tab

On the Link tab, the outputs of all the new configurations have to be adjusted. The base path is still correct but the output file name has a different locale code.

Resource Tab

The Resource tab, is where the country specific resources are specified. It is still set up to use the English resources and will require further adjustment to work for the various locales. Change the target equate.