When Windows XP was introduced in 2001, it came with the idea of "themes".  For your application to utilize these themes, you needed to add a manifest resource to your executable with the following contents:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
          manifestVersion="1.0"> 
  <assemblyIdentity version="1.0.0.0"
                    processorArchitecture="X86"
                    name="CompanyName.ProductName.YourApp"
                    type="win32" /> 
  <description>Your application description here.</description> 
  <dependency> 
    <dependentAssembly> 
      <assemblyIdentity type="win32"
                        name="Microsoft.Windows.Common-Controls"
                        version="6.0.0.0"
                        processorArchitecture="X86"
                        publicKeyToken="6595b64144ccf1df"
                        language="*" /> 
    </dependentAssembly> 
  </dependency> 
</assembly> 

This all seems to work well. 

About a year ago, after Vista came out, we wanted to introduce the manifest to our production executable to satisfy certification requirements.  We needed to include the following section in order to turn off Vista virtualization:

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
  <security>
    <requestedPrivileges>
      <requestedExecutionLevel level="asInvoker" />
    </requestedPrivileges>
  </security>
</trustInfo>

At the time, we were using Microsoft Visual C++ version 6.0 for our production code.  When we added the trustInfo section, we decided to also include the dependency section as well.  We figured that we might as well take advantage of new common controls where possible.

All was good for a while.  We got a bug report for Japan that some of our edit controls were losing half of their data.  For example, if the user entered 4 Japanese characters into the edit control, we were only saving 2.

Debugging the code, we determined that the problem was with an EM_LINELENGTH message.  Sending this message to the edit box would return back "4" as the length of the text.  For 4 Japanese characters, this was incorrect because our application is compiled using Multi-byte character set (ie. not Unicode), and thus, 4 Japanese characters should have been 8 bytes.

What was happening was EM_LINELENGTH was being sent to the Unicode handler for the message instead of the MBCS handler.  English characters were fine.  It appeared that all 2 byte characters were being returned as 1 byte (or 1 character).

Trying to figure out why this was happening was not an easy feat.  Basically, it was someone's suggestion to just remove the manifest completely just to see if it had any effect. 

It did.

As it turns out, including the above XP theme section in our manifest, while using Visual C++ 6.0, causes the issue.  There appears to be some compatibility issues between that compiler and the XP themed common controls.  There is no issue if our manifest only includes the execution level section.

Since then, we have migrated our application to the Visual Studio 2008 compiler, but we have not tried restoring the manifest section.  I'll update you when we give it a try.