 |  |
Application Compatibility in Windows MUI
Before we discuss the application compatibility issues on top of Windows 2000 and XP MUI, we have to stress three basic points:
1. | All Windows 2000 and XP languages are based on the same single code base. The only differences between US English or a localized language OS is the resources for UI display are localized. The execution code is exactly the same across any language operating system. |
2. | The design of almost all of the in Windows is Unicode based. This means that all the languages supported by Windows are treated the same. Applications for all the supported languages will work exactly the same. |
3. | With the exception of how UI resources are stored, MUI and localized Operating Systems work the same way. |
For further information on the points above please check out the following link http://www.microsoft.com/technet/prodtechnol/winxppro/evaluate/muiovw.mspx.
In general, you can set up any localized version of Windows 2000 or Windows XP to work with any well written localized application. However if proper attention is not given to certain areas in the development of the application, the result will be that the application will only work on certain languages but not all.
|
On This Page
 | Running English and localized applications |
| Testing localized applications on top of MUI |
| Best practices for application development |
Running English and localized applications
Assuming the language related settings in Windows are set to match those of the application, you can run almost any localized application on top of any language version o f Windows 2000 or Windows XP. The most interesting scenario though, is running US-English and localized applications side by side on a localized version of Windows 2000 or Windows XP. For this reason, this scenario is covered by the test team and we have found that almost all US-English applications work well on top of any localized or MUI system. In relation to localized applications, our findings lead us to recommend only to use localized applications on their respective localized OS or MUI system. (for MUI, this means to set the user’s UI language to match the application language).
In general:
| • | Any well written Unicode application will run under any language setting. |
| • | Any non-Unicode application will be able to run only when the system locale (also called “Language for non-Unicode Programs” on XP) is set to match the application’s language. |
| • | Sometimes, a particular application could be designed to only work under certain language related settings. The other language related settings include User Locale (also called “Standard and Formats”), Default Input Locale (also called “Default Input Language” in XP), or Location. |
System locale controls the system wide default ANSI and OEM code page. It controls how the non-Unicode APIs (also known as _A APIs) process the character’s code points. For any non-Unicode programs, the program’s working ANSI or OEM code page must be set to match the system’s default ANSI and OEM code page.
To get maximum application compatibility, you can set all the language related settings to match the application’s language. This includes:
| • | System Locale |
| • | User Locale for both current user and DEFAULT user account |
| • | UI language for both current user and DEFAULT user account |
| • | Location for both current user and DEFAULT user account |
| • | Default Input Locale for both current user and DEFAULT user |
| • | Shell UI Font (this setting can only be set from XP MUI Setup and only applies to Japanese applications). |
If a service or program runs under a special user account that is different from the current user account, please also make sure that the above per user settings are set properly for the account.
In situations where you can use a program properly on a localized OS, but not on an MUI one this is most likely caused by language-related settings not set properly.
Testing localized applications on top of MUI
We strongly recommend ISVs to test their applications on top of MUI, besides testing on top of localized operating systems. We recognize any well-written applications should just work on top of MUI, but we also found that there are applications that depend on some non-standard settings or designs to work. These settings or designs might only exist on top of localized systems. We will discuss more about these issues in the following section. But sometimes, testing applications on top of MUI will allow us easily resolve these issues in application code.
Best practices for application development
The following sections include some best practices that developers should follow during the development time that could make the localized language applications run better on top of a MUI system. While these items are not specially designed for MUI and they are general Windows Logo compliance recommended practices, due to the differences between MUI and localized systems, they will normally expose issues on top of MUI instead of localized ones.
1. Setup and Installation – checking system language
As we mentioned, in general, any language applications should be able to run on top of any language Windows 2000 or XP. Any application should not restrict itself to be run on top of localized systems only. If the application is ANSI based and requires that the System Locale matches the language to run, it can check that the system locale is set right by calling GetSystemDefaultLangID or GetSystemDefaultLCID.
If the application wants to check if a particular language support is available from the system, it can call EnumLanguageGroupLocales
In most cases, the system locale should be the maximum requirement of the application.
An application can determine whether the system has the MUI add-on using the EnumUILanguages interface. If the enumerated result contains more than one language, then MUI is present. Please also note that an administrator may install the MUI add-on after your application. Inside the program, if it wants to check what the current user’s UI language is, it can call GetUserDefaultUILanguage.
The way to know if an OS is localized and in which language, is by calling GetSystemDefaultUILanguage on top of Windows 2000 and XP. We strongly advise against using this API and you should never limit your application to only install on top of a particular localized Windows 2000 or XP.
2. Writing MUI Applications
If you want your application to support a Multilingual User Interface like the system’s MUI, please refer to this document for more detail: Writing Multilingual User Interface Applications.
It normally makes sense to have your program’s UI language in sync with the system UI, you can call GetUserDefaultUILanguage to know the current user’s UI language and switch your applications’ based on it.
3. Location Changes and Hard-Coded Paths
The location of many folders and directories changes with each language version of Windows, but they remain in English on MUI machines.
The Windows functions SHGetFolderPath, GetWindowsDirectory, GetSystemDirectory and GetTempPath should be used to find directories used by Windows. Applications that use hard-coded paths to specific locations, may not work on MUI systems.
To find shell folders such as My Documents, use SHGetFolderPath to get the path. You can use it on Windows 95, Windows 98, or any Windows platform, and it will get you to the right place.
The following code example shows how to use SHGetFolderPath; it is a very straightforward API to use.
// SHGetFolderPath can work everywhere SHFOLDER is installed.
HMODULE hModSHFolder = LoadLibrary("shfolder.dll");
if ( hModSHFolder != NULL )
{
(*(FARPROC*)&g_pfnSHGetFolderPath = GetProcAddress(hModSHFolder, "SHGetFolderPathA"));
}
else
{
g_pfnSHGetFolderPath = NULL;
}
if (g_pfnSHGetFolderPath != NULL )
{
g_pfnSHGetFolderPath(NULL, CSIDL_SYSTEM, NULL, NULL, szSystem32);
}
else
{
szSystem32[0] = '\0';
OpenFileName.lpstrInitialDir = szSystem32;
}