Windows Management Instrumentation: International Support Overview

  • Article

This paper presents an overview of the Microsoft Windows Management Instrumentation (WMI) globalization model. Windows Management Instrumentation is an implementation of the Distributed Management Task Force (DMTF) Web-Based Enterprise Management (WBEM) initiative, which provides standards for accessing and sharing management information in an enterprise environment. This paper is intended for developers and administrators of multi-lingual Windows 2000 installations.

On This Page

Introduction Important Concepts Scenarios Problem Domain Localization Of Schema Objects Localization Of Property Values Schema Deployment Runtime Support Design Recommendations Conclusion For More Information

Introduction

The Microsoft Windows 2000 operating system has been globalized in preparation for its release in more than two dozen language editions. Each language edition supports the input and display of all languages that Windows 2000 supports, making the operation of multilingual networks and machines much easier.

With international support built into the system through the National Language Support API (NLSAPI), the Multilingual API (MLAPI), and Windows resource files, developers will find it easier to create globalized applications that support multilingual data and multilingual user interfaces (UI). Using these APIs, developers can create applications that can run on any language edition of Windows 2000 and allow for editing and display of multiple languages.

Windows Management Instrumentation (WMI) technology is an implementation of the Distributed Management Task Force (DMTF) Web-Based Enterprise Management (WBEM) initiative for Windows platforms. This initiative extends the Common Information Model (CIM) to represent management objects in Windows management environments. The CIM, also a DMTF standard, is an extensible data model for logically organizing management objects in a consistent and unified manner within a managed environment.

Microsoft's implementation of the data model includes a repository that stores metadata (classes and relationships in the model) and one that stores management data (instances of classes or relationships). Data, class, and event providers supply data to the repository, and management applications or scripts then access this data via WMI. Localization and globalization of management data must be taken into consideration.

This paper presents a model for globalizing management data in the Windows 2000 environment that is based on localization of CIM schema objects. It also provides guidelines for developing CIM schema extensions, WMI providers, and applications that can be localized and globalized readily.

Important Concepts

The following concepts are key to understanding international support in Windows:

Locale

A locale is a set of user-preference information related to the user's language and sub-language. For example, if the language were French, the sub-language could be standard French, Belgian, Canadian, Swiss, or Luxembourgian. Locale information includes currency symbol; date, time, and number formatting information; localized days of the week and months of the year; the standard abbreviation for the name of the country; and character encoding information. Each Windows 2000 system has one default system locale and one user locale per user. The user locale can be different from the default system locale, and both can be changed via the control panel. Applications can specify a locale on a per-thread basis when calling APIs.

Localization

Localization refers to the translation of strings into a format that is applicable to the locale and language of the user, and to the input and output of data (such as currency, date, and time) in such a format.

Globalization

Globalization refers to the ability of software components to support multi-lingual data simultaneously.

Master Language

Master language refers to the language of the core operating system (OS) components in the particular installation of Windows 2000. Some parts of the OS always remain in this language. The master language cannot be removed.

Multi-lingual User Interface (MUI)

MUI is the codename for a separate release of Windows 2000 called Windows 2000 Multilanguage Version. In this version of Windows 2000, the UI language can be changed according to the preferences of individual users. The user can then select the UI language or set it by using Group Policy for Organizational Units. It also allows users of different languages to share the same workstation: One user might choose to see system menus, dialogs, and other text in Japanese, while another user logging onto the same system could see the corresponding text in French.

Scenarios

An administrator runs a management snap-in on a Japanese Windows 2000 server. The snap-in uses WMI to retrieve data. All data is displayed in Japanese.

A French developer is working on a CIMV2 schema extension on the French version of Windows 2000 Professional Workstation. When browsing the repository with CIM Studio, the developer right-clicks the attributes. The correct French descriptions are displayed under Property Qualifiers.

An administrator in an international firm uses a German Windows 2000 Professional Workstation to monitor a Windows 2000 server with the MUI feature. The administrator monitors various OS statistics, which are displayed in German, via System Monitor. The administrator's assistant is Italian and uses an Italian workstation to monitor the same statistics. When the assistant brings up System Monitor, all the statistics show up in Italian.

Problem Domain

Windows 2000 is being marketed for worldwide distribution. To meet the demands of the world market, Windows 2000 will be available in localized versions or with an MUI feature that can be installed on the US version of Windows 2000. The first option requires that the management instrumentation be localizable. This means that WMI produces management data in the system locale of the host computer on international versions of Windows 2000. The second option requires that WMI be capable of supporting clients configured with any language or locale, if the language or locale is added to the host machine using the MUI feature. In other words, it must be capable of producing management data in multiple languages simultaneously.

The globalization model of WMI needs to provide methods of doing the following:

  1. Localizing CIM schema objects.

  2. Localizing property values.

  3. Designing localizable providers.

  4. Designing globalized WMI clients.

  5. Deploying localized instrumentation.

Localization Of Schema Objects

Localization applies to the displayable aspects of the schema objects, and not to the actual class or property identifier strings. Since the displayable aspects are contained in qualifiers, the localization model is centered on organizing these types of qualifiers in a rational way.

Priorities

  • To permit any schema class to be created in any language.

  • To provide a general-purpose mechanism for translation from one locale into any other, entirely through CIM objects.

  • To permit qualifier values to be localized if required.

  • To achieve better performance through providing a mechanism for decoupling lengthy descriptive text from the class to which it applies.

  • To provide a mechanism for localizing schema objects without altering them, after they have been introduced.

  • To require only minimal changes in the existing WMI application in order to access the localized schema objects.

  • To be compatible with the language translation process used by the localization team for other OS components.

  • To be compatible with the MUI requirements. This means that multi-lingual versions of the same schema object can be installed on a platform and accessed simultaneously.

Non-priorities

  • Providing a mechanism for localizing names of classes, properties, methods, or qualifiers.

  • Providing a mechanism for localizing values of dynamic properties.

  • Providing a mechanism for localizing instance qualifiers.

Solution

The globalization model is founded upon the idea that the complete definition of a class can be generated dynamically at runtime as a union of two separate class definitions: basic class and amendment*.* Both classes are subsets of the same master class.

A master class is a complete definition of a class that includes the full set of properties and qualifiers required for the class.

A basic class is a subset of the master class that includes the full set of properties and a subset of qualifiers. The localizable qualifiers are not included in the basic class.

An amendment is an abstract class that has the same name as the corresponding basic class and includes a subset of properties with localizable qualifiers. No other properties of the master class are included in the amendment. The class definition always resides within a child namespace of the namespace that contains the basic class definition.

Each child namespace contains the amendment classes for a particular locale. The result of this design is that multiple language-specific child namespaces can be added to the repository, thus allowing multi-lingual class definitions.

The child namespaces are named MS_xxx, where xxx is the hexadecimal value of the Win32 Local ID (LCID). The MS_ prefix is required so that other non-Microsoft localization schemes can be accommodated using the same general technique, and because namespace identifiers may not begin with a digit.

For example, under typical WMI installations, the hierarchy of the namespaces containing the English and German amended-class definitions for CIMV2 is as follows:

ROOT\CIMV2
ROOT\CIMV2\MS_409
ROOT\CIMV2\MS_407

The preceding model implies that the WMI runtime dynamically merges the two class definitions before it returns metadata to the client. The merge, however, must be explicitly requested by the client code, using a special flag (see the Runtime Support section later in this paper).

Example

For the following illustration of this idea, assume the basic class definition resides in ROOT\DEFAULT:

[uuid(12446666-1230-4400-AAC1-AAAABBBBCCCC"), locale(0x409)]
class MyClass
{
[key]  sint32 KeyProp;
string Name;
uint64 Timestamp;
};

For the American English locale (0x409), the amended class definition would be located in the child namespace ROOT\DEFAULT\MS_409 and could appear as follows:

// Descriptions show up in the localized "English" version
[amendment,
description("Localized version of MyClass for American English"):amended,
locale(0x409), help_url("http:\\blah\myclass_def"):amended]
class MyClass
{
[DisplayName("Key Property"):amended,
Description("This is a big description"):amended, help_url(""):amended]
sint32 KeyProp;
[DisplayName("User Name"):amended,
description("This is a bigger description"):amended,
string Name;
};

Note that the class name and property names are identical for the amendment class and the basic class definition. The amendment class definition, however, includes other qualifiers that add reference material to the basic class definition, and it does not include all the properties of the basic class. The amendment qualifier on the class definition is required so that a client that obtains this class via some method other than browsing can identify it as being an amended class definition. Also note that amendments can have no instances and only exist to add information to the basic classes. In creating instances, the object manager treats amendment classes as abstract. However, the abstract qualifier should not be used with the amendment classes unless the basic class is abstract. This will cause an error if the parent basic class is abstract with DisableOverride flavor.

Notice that the key qualifier is missing from the amendment, but present in the basic definition. This is because the basic class definition is already implied in the amended class definition.

The DisplayName qualifier indicates how the class and property names should be displayed in GUI applications. If DisplayName is absent, it implies that the class or property names are already intrinsically displayable.

We recommend that any new qualifiers that define property source information, property constraint information, help URLs, help context ids, and so on appear only in the amendment class. As an example, consider the qualifier Description, whose value is typically long enough to add a good deal of overhead to the class definition. Most users never have to deal with the overhead when they place this qualifier only within the amended class definition.

Within the schema, the combination of basic definition and amendment constitute the complete class definition.

To localize this class into German, the German version of the amendment class needs to be created in the child namespace ROOT\DEFAULT\MS_407. The class definition could appear as follows:

[amendment, locale(0x407), description("Meine Klasse auf
Deutsch"):amended,
DisplayName("Meine Klasse"):amended ]
class MyClass
{
[DisplayName("Schlusseleigenshaft"):amended,
Description("Diese ist eine Schlusseleigenshaft"):amended]
sint32 KeyProp;
[DisplayName("Benutzername"):amended,
Description("Jemand Namens"):amended]
string Name;
}

Note that the class, property, and qualifier names are still in English, for example MyClass, KeyProp, and Name. This is because class and property names in the amended class definition must have the same locale as the basic class definition. Thus, only qualifier values are translated. In this case, DisplayName and Description contain the property name and description text in German.

Further, the locale qualifier is set to 0x407 to indicate the locale of the DisplayName value and any other localizable strings. This is necessary so that objects obtained via object paths, rather than by browsing, can be successfully analyzed to find out what language the DisplayName strings are in.

Localization Of Property Values

The CIM-schema localization model provides a mechanism for localizing qualifiers. It does not support direct localization of property values.

In many cases, however, the string properties values in the static instances can be replaced by an enumerated integer type, and a value map can be defined for the property in the class definition. In these cases, the values qualifier should be localized. The principal mechanism of localizing property values involves using enumeration qualifiers. Any other forms of property value localization are not supported.

The semantics of enumeration can be extended to accommodate the cases where only a subset of values of a property is known at design time. You can define the ValueMap qualifiers that include strings defining groups of values. The definition of such group can be as simple as a range of values or as complex as a matching scheme defined via a script. A user-defined ValueMapSyntax qualifier can be introduced to specify the group definition syntax. Partial value map can be defined both for numerical and string properties.

The following example demonstrates how static properties can be localized using partial value maps with regular expressions. Note that the pre-defined subset of values in this example is initialized in the schema using static instances. The rest of the values are provided dynamically.

[abstract]
class DataGroup
{
[key] string GUID;
[Description ("data group display name")]
[ValueMapSyntax("LEX"),
ValueMap{"Logical Disk",
"CPU Utilization",
".+"},
Values{{"Logical Disk",
"CPU Utilization",
"User-defined"}:amended]
string GroupDisplayName;
[ValueMapSyntax("LEX"),
ValueMap{"Monitors percentage of disk free space",
"Monitors percentage CPU utilization",
".+"},
Values{"Monitors percentage of disk free space",
"Monitors percentage CPU utilization",
"User defined data group"}:amended]
string GroupDescription;
}
[static, Description ("pre-configured parameters") :amended]
class InitialGroup : DataGroup {
}
[dynamic, provider("HMProvider"), Description ("user-defined parameters")
 :amended]
class UserDefionedGroup : DataGroup {
}
instance of InitialGroup {
GUID = "abc";
GroupDisplayName = "Logical Disk";
GroupDescription = "Monitors percentage of disk free space";
}
instance of InitialGroup {
GUID = "def";
GroupDisplayName = "CPU Utilization";
GroupDescription = "Monitors percentage CPU utilization";
}

The implication of this design is that each string value is used as a lookup id; therefore, it cannot be localized itself. When defining this scheme, you have to make sure that the value the provider assigns to the property is locale independent.

Note that WMI does not currently provide runtime support for mapping values to strings that are defined via qualifiers. The application must interpret the suggested syntax and perform the value lookup.

Schema Deployment

The schema-deployment solution has to meet the following requirements:

  • The localizable parts of the schema are separated so that they can be easily translated into other languages.

  • Additional international versions of the localizable schema can be added without re-installing the entire schema.

The WMI team has adopted the following deployment strategy in order to meet these requirements:

Each master MOF file installed as part of the product is maintained in the source tree as a singe file. Every class in the master MOF includes all qualifiers with the text attributes in English. The localizable qualifiers are marked with the flavor amended.

The build process creates a production version of each schema, which consists of a pair of MOF filesbasic MOF and amendment MOF. Basic MOF is the original namespace with all amended qualifiers removed. By default, the basic MOF inherits the name of the master MOF. The amendment MOF contains the child namespace. By default, it has the same name as the master MOF, with the extension MFL.

To generate the production files, you need to run the MOF compiler (mofcomp.exe) with the following syntax:

mofcomp amendment:<namespace> [-MOF:<mof>] [-MFL:<mfl>]
yourfile.mof

The <namespace> is the localization id. It defines the child namespace in the MFL file. For example, the <l namespace> to create the US English MFL is MS_409. By default, the MOF compiler will create yourfile.mof and yourfile.mfl in the current directory. Note that this will result in replacing the master MOF with the basic MOF of the same name (yourfile.mof). You can change the default by supplying different .mof and .mfl names.

To ensure consistency between base and amended classes you should never modify these files. All modifications should be made in the master MOF.

As an alternative to the amendment option, new pragma syntax has been added to MOF:

#pragma amendment ("<namespace>")

The pragma has the same effect as the command line option.

To illustrate the process of creating production MOFs, let's assume that yourfile.mof contains the following schema:

#pragma autorecover#pragma amendment ("MS_409")#pragma
namespace ("\\\\.\\root\\cimv2")
[singleton, dynamic, vendor("Microsoft"), locale(0x0409)]class
A
{
[key] string Name;    [description ("this property contains the
timestamp of"
"instance creation") :amended ]
uint64 Timestamp;    ...
}

The MOF compiler will create the basic MOF yourfile.mof with the following content:

#pragma autorecover#pragma namespace ("\\\\.\\root\\cimv2")
qualifier description:amended;
[singleton, dynamic, vendor("Microsoft"), locale(0x0409)]class A
{
[key] string Name;    uint64 Timestamp;    ...
}

Notice that the pragma amendment and description qualifier disappeared. The former is no longer applicable because it is a base file. The latter is moved to the child namespace because all description qualifiers are marked as amended in the master MOF.

Yourfile.mfl will include the following elements:

#pragma autorecover#pragma namespace ("\\\\.\\root\\cimv2")
instance of __Namespace
{
Name = "MS_409";
};
#pragma namespace ("\\\\.\\root\\cimv2\\MS_409")
qualifier description:amended;
[amendment, locale(0x0409)]class A
{
[description ("this property contains the timestamp of"
"instance creation") :amended]
uint64 Timestamp;    ...
}

Notice that the MOF compiler has created a new namespace and left only the properties, which had the amended qualifiers in the master MOF.

The MOF and MFL files together contain all the schema elements that are defined in the original master MOF, but they allow for easy translation and deployment of localized elements of the schema because they are separate.

The WMI Windows 2000 in-the-box install includes a number of providers accompanied by respective schema files. The schema for each provider is installed as a pair of files, as described above. Examples of these pairs of files would be cimwin32.mof and cimwin32.mfl or msi.mof and msi.mfl. The MOF file includes the basic class definitions and the US English amended namespace MS_409. The MFL files represent the localized namespaces for different languages. On the US English version of Windows 2000, these files are simply duplicates of the classes in the MS_409 namespace that are already included in the MOF files. On the international versions of Windows 2000, the MFL files are translated into the respective language. As a result, each international platform includes a pair of amended namespaces for each root namespacethe US English namespace MS_409 and the localized namespace MS_xxx, depending on the master language of the platform. The MS_409 namespace is used as a fallback by the object manager in cases where the namespace for the client's LCID is not found on the server.

For example, the structure of the CIMV2 namespace on the Japanese version of Windows 2000 looks like this:

.\root\cimv2  - defined in cimwin32.mof
.\root\cimv2\MS_409  - defined in cimwin32.mof
.\root\cimv2\MS_411 - defined in cimwin32.mfl

To produce the localized schema for an international version of Windows 2000, the localization team translates the MFL files into the master language of the platform. The WMI team provides the localization team with a LocStudio parser for MOF. This makes the translation process seamless and requires no MOF-specific skills to do the job. The parser automatically replaces the namespace suffix and all the locale qualifiers of all amended classes with that of the target language. The resulting MFL is distributed in place of the US English MFL in %SystemRoot%/System32/Wbem.

The MUI feature includes, as part of the setup, international copies of the MFL files to be installed for each additional language. The files are placed to %SystemRoot%/System32/Wbem/MUI/<LCID>, in accordance with the MUI naming convention.

Runtime Support

WMI runtime includes new functionality to accommodate the schema-based globalization model. The API has not been changed, however, and we expect minimal impact on the existing client application and provider code, but you need to be aware of the following changes:

  • SWbemLocator.ConnectServer and IWbemLocator::ConnectServer no longer ignore the strLocale parameter. If you specify the value, the object manager assigns this locale to your session context and retrieves localized data from the repository, provided the respective language is installed on the server. If not, the master language of the remote host is used as a fall back. If you don't specify the value for strLocale, the client's default locale is assumed. Note the localized data (amendment classes) are only retrieved if requested.

  • IWbemServices::GetObject, SwbemServices.GetObject, IWbemServices:: ExecQuery, and SWbemServices.ExecQuery have a new flag, WBEM_FLAG_USE_AMENDED_QUALIFIERS, to request class amendment data along with the basic definition. The flag calls an internal helper function that queries the localized child namespace for a class with the same name, based on the session locale, and merges the latter with the class definition. If the localized namespace for the client LCID is not found, the US English namespace is used as a fallback. As a result, the full class specification is returned. Be aware that some amendments may be quite large, and additional overhead will be incurred. We anticipate that the full class specification is required only in functions that produce displayable values using value maps or display descriptions or other amended qualifiers. Such cases will be a relatively small subset of all calls to GetObject or ExecQuery, so additional editing effort should be very limited.

It should be noted that runtime only supports automatic merging of the amendment classes during read operations. Automatic modification or deletion of amendment classes is not supported. If your application dynamically creates or modifies classes, it has the responsibility of propagating the operation to the amendment classes. The same applies to the delete operation. We believe that this scenario is unlikely because it is not practical for an application to dynamically create or modify multi-lingual qualifiers. In most cases, this should be accomplished by translating MFL files.

Design Recommendations

Defining Localizable Schema Objects

This section provides guidelines for developing localizable schema extensions.

Move the localizable qualifiers to the amendment classes in the repository.

Decide which qualifiers you want to translate or move to the child namespace in order to reduce operational overhead. Mark these qualifiers as amended*.* You can then split the master MOF into two files using the MOF compiler as described in the previous sections. This will move the amended qualifiers to the amendment classes in the localization namespace. We strongly recommend that at least the Description and Values qualifiers be marked as amended. You can use the following global settings to minimize modification effort:

Qualifier Description :amended;
Qualifier Values :amended;

Define value-map qualifiers where applicable.

Enumeration is the principal means of localizing property values. Therefore, you need to determine if your property represents enumerated values. These values are easily localized using value-map qualifiers. Note that you should be careful when defining value maps for string-type properties. ValueMap has language-neutral strings and is not localizable. If those properties are populated with data obtained by the provider from the OS or from another application, their resources are typically localized. This will result in mismatch between the property value and the string specified in ValueMap*.* Typically only partial value maps should be used for string properties (see next rule). In all other cases, numeric property is strongly recommended.

Use partial value maps for localizing string properties.

If you have a set of static instances in your schema, you can localize them by using a partially defined set of mapping values. This is done by specifying ranges of values in ValueMap*.* The syntax can use regular expressions or another matching method. See the Localization of Property Values section for details.

Define DisplayName to localize property or class names.

If you need to localize the names of properties or classes in the schema, you should define the DisplayName qualifier with the name of the property and mark it amended. The client UI should use this qualifier's value instead of the actual class or property name. For example:

class DMAClass {
[DisplayName("DMA Channel"):amended]
uint32 DMAChannel;
...

In some cases, the new properties you introduce may need to be displayed as composite strings that include the property name and value. Because composition rules may differ for different languages, you may want to extend the syntax of DisplayName to include a format specification. Another qualifier, DisplaySyntax, should be defined to specify the type of the format syntax. This way, you ensure that the order of tokens in the string will be adjusted as necessary in the process of language translation. The following example illustrates this idea:

class IRQClass {
[DisplayName("IRQ%d"):amended, DisplaySyntax("C")]
uint32 IRQNumber;
...
}

Designing Globalized WMI Applications

Use amended qualifiers for the application's UI.

In general, amended qualifiers are translated into the master language of the host OS in the repository. In the remoting scenarios, the data arrives in the client's locale, if the remote host supports MUI and provided the corresponding language is installed on the host.

Use the DisplayName qualifier, if defined, for displaying class or property names.

Be aware that the names of schema objects are language immutable. They remain in the language in which they were defined. This is specified in the schema by the locale qualifier assigned to the class. If you need to display property or class names in localized form, use the DisplayName qualifier, if defined.

Using local value mapping is occasionally acceptable.

If the remote host does not support MUI, and your application must present data in the client locale, the only way to do this is to map numeric values from the remote host to strings stored in the local resource tables. This will guarantee that the strings are always localized to the client's locale. The downside of this approach is that the local resource table is decoupled from the schema and can get out of synch with actual values generated by the providers or set in the schema, in the case of static instances.

Do not display values of key properties, if possible.

Key properties of string type are language neutral. If displayed on UI, they will appear as non-localized text. Avoid using these strings, if possible, unless the text is expected on the UI in native form, for example, URL text.

The same applies to the string properties with a partial value map. In this case, the values are treated as language neutral and are used to determine a lookup id for a string specified in Values*.* You should use that string on the UI.

Be aware that localized data may be non-printable in remoting scenarios

In general, the data coming from WMI is translated into the master language of the remote host. If the client locale is different from the remote system locale, the strings that arrive from WMI may be non-printable (for example, a Japanese server and US client machine). If data you display are retrieved from the repository, you can ensure localization by installing multiple localized namespaces. If you display string values of non-key properties, such as caption or description, they always appear in the master language of the remote host.

Designing Globalized WMI Providers

All key property values must be independent of locale.

The keys are a fundamental mechanism for uniquely identifying instances within namespaces. Localization of key values will result in breaking various queries used by management application, applets, or scripts accessing machines. Therefore, you should never use strings from a resource table to populate these properties. Similarly, you should be very careful when using OS-supplied strings for key properties. You must make sure that those strings are locale neutral before you use them as keys.

Some non-key property values must be language neutral and cannot be localized.

The same locale-neutrality requirement applies to values of non-key string property that have a value map defined. If populated from a localized resource table or obtained from the OS, it may result in a mismatch between the value and the strings defined in ValueMap. Note that, in general, we do not recommend specifying value maps for string properties, except for partial value maps. The partial value map can be used when a subset of instances is statically initialized. You can then define the value map for that subset, thus making it localizable. The rest of the instances are generated by the provider and cannot be localized.

Avoid creating strings to populate dynamic instances.

In most cases, values of string properties should be obtained from the managed object (for example, OS component or application). In rare cases, when the provider has to produce strings, they should be defined in the provider's resource table. The resource table should be translated into the system locale of the managed platform. However, such a decision must be well justified because in most cases a string property generated from a resource table can be replaced by a numerical property with a value map.

Conclusion

The localization model for CIM schema objects, combined with runtime support and clearly defined deployment strategy, offers a flexible and powerful facility for globalizing management data in Windows 2000. The development guidelines in this paper are designed to help developers migrate the existing management instrumentation and applications to the globalizable form. The guidelines should also ensure that the future schema extension and providers meet the globalization requirements of Windows 2000.

However, the schema-based localization solution only provides for localization of a subset of management data. Most of the dynamic data supplied by various WMI providers cannot be localized using this model. In general the localization of the dynamic data is fully dependent upon the localization of the respective managed objects.

For More Information

See the article on WMI SDKs on the MSDN website at https://msdn.microsoft.com/downloads/default.asp?URL=/code/topic.asp?URL=/MSDN-FILES/028/000/015/topic.xml.