Windows Management Instrumentation: International Support Overview

Operating System

Windows Management Instrumentation:

International Support Overview

White Paper

Abstract

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 Windows2000 installations.

© 1999 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation.

Other product or company names mentioned herein may be the trademarks of their respective owners.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA

1199

Contents

Introduction

Important Concepts

Scenarios

Problem Domain

Localization Of Schema Objects

Priorities

Non-priorities

Solution

Example

Localization Of Property Values

Schema Deployment

Runtime Support

Design Recommendations

Defining Localizable Schema Objects

Designing Globalized WMI Applications

Designing Globalized WMI Providers

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 Windows2000 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 Windows2000 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 Windows2000 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. (For a more complete list, see Developing International Software for Windows 95 and Windows NT). Each Windows2000 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 Windows2000. 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 Windows2000 called Windows2000 Multilanguage Version. In this version of Windows2000, 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 Windows2000 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 Windows2000 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 Windows2000 Professional Workstation to monitor a Windows2000 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

Windows2000 is being marketed for worldwide distribution. To meet the demands of the world market, Windows2000 will be available in localized versions or with an MUI feature that can be installed on the US version of Windows2000. 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 Windows2000. 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 classis 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 amendmentis 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 xxxis 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 DisplayNameis 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 Descriptioncontain the property name and description text in German.

Further, the locale qualifier is set to 0x407 to indicate the locale of the DisplayNamevalue 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 files—basic 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.