1. Research Triangle Park, NC
Developing multilingual installation programs using InstallShield for Windows Installer
Developing multilingual installation programs using InstallShield for Windows Installer
David L. Cole
IBM Corporation
Research Triangle Park, NC
This presentation describes how to take advantage of the new features available with Microsoft’s Windows Installer and associated tools from InstallShield, Corp., to develop sophisticated multilingual installation programs.
Both overview material and detailed technical information are provided. The target audience is software developers and national language specialists who may or may not have experience writing installation programs.
Amsterdam, The Netherlands, March 2000

2. Why we’re here... The install program!
Developing multilingual installation programs using InstallShield for Windows Installer
Why we’re here...
No matter how good your application is,
Your customers’ first experience is...
Globalized
Software Application
The install program!
New technologies exist…
- The Windows Installer En De Fr Jp Ko It
Which enable sophisticated, multilingual install programs
No matter how good a job you’ve done globalizing your application, your customers’ first impressions will come when they try to install it.
Microsoft has recently introduced a new installation architecture, the Windows Installer, which changes the rules (and provides new features) for software installation programs.
Correspondingly, InstallShield Corporation has developed new tools for authoring Windows Installed-based installs. InstallShield for Windows Installer, or ISWI, provides sophisticated language features for localizing (that is, translating into different languages) installation programs and for installing applications which themselves have multiple language versions.
This presentation describes all of the above by addressing the following topics.
- Development tools (InstallShield)
That’s what we’re here to talk about!
Amsterdam, The Netherlands, March 2000

3. Topics A background on Microsoft’s Windows Installer service
Developing multilingual installation programs using InstallShield for Windows Installer
Topics
A background on Microsoft’s Windows Installer service
A description of the InstallShield for Windows Installer tool
Examples of multilingual install programs
Details on how to design and develop multilingual install programs
Explanation of how and where Unicode is used in the process
Hints, tips, and gotcha’s
References
These topics set the context for understanding a multilingual installation developed with InstallShield for Windows Installer.
We need to start with the Windows Installer service itself, since it sets the foundation for everything else.
Next we’ll look at InstallShield for Windows Installer and understand the types of functions it offers, especially with respect to language features.
Then we’ll see a demo of developing and running a simple multilingual installation program using ISWI so we can see what all this actually looks like.
Now we’re ready to delve into the details of the various types of multilingual installation programs and see how you would design each type.
We’ll look at how Unicode is used in the process.
We’ll review some headache-saving hints and tips.
And we’ll end with references where you can find additional information and resources.
Amsterdam, The Netherlands, March 2000

4. What is a multilingual installation program?
Developing multilingual installation programs using InstallShield for Windows Installer
What is a multilingual installation program?
English German ...
May support multiple languages
May have separate
language
versions
Installation Program
May support
multiple
languages
concurrently En De
...
Software Application
Product to be installed En De
...
Common CD,
separate Application
language Versions
Type II En De
...
Separate Language
Versions (CD & App)
Type I En De
...
Common CD & App,
multiple language resources
Type III
A multilingual installation program actually deals with two things: the language features of the installation program itself, and the language features of the software application being installed. “Language features,” in this case, includes the language of the user interface, and possibly language resources, such as various language dictionaries for a word processor.
Different language versions of an application may be packaged in various ways. In the case of using CD’s as your distribution media, you may have a separate CD per language, in which case you’d want the language of the installation program to simply match that of the application (Type I).
Or, you may have all the language versions of the application packaged together on a single CD, in which case you’d want to be able to select the language of the installation program and of the application to be installed (Type II).
Or, your application may support multiple languages concurrently, in which case you need to be able to select the language of the installation program and the set of languages to be supported (Type III).
The type of multilingual support you choose profoundly affects the resulting design of the installation program. Fortunately, InstallShield for Windows Installer works with all three types quite well, and this presentation will describe each type of multilingual installation program in detail.
Amsterdam, The Netherlands, March 2000

5. What is the Windows Installer?
Developing multilingual installation programs using InstallShield for Windows Installer
What is the Windows Installer?
Microsoft’s Windows Installer is a new installation service that consists of:
an operating system resident installation service
a standard format for component management
a management API for applications and tools.
Is a key component of Windows 2000, also available for other Windows versions (Windows 95, 98, and NT 4.0)
Also known as “MSI”
Not an authoring environment!
3rd party vendors (e.g., InstallShield, Wise) provide development tools
The Windows Installer is a new installation service from Microsoft that consists of three elements:
1. An operating system resident installation service
2. A standard format for component management
3. A management API for applications and tools
We’ll look at each of these elements in detail.
The Windows Installer represents a key component of Windows 2000 and of Microsoft’s effort to reduce customers’ Total Cost of Ownership - the accumulated costs of acquiring and using a given software product. The Windows Installer is native to Windows 2000 and is available as a self-installing redistributable for Windows 95, Windows 98, and Windows NT 4.0.
As is often the case, this new item is known by a variety of names. You often hear the Windows Installer referred to as “MSI.”
It’s noteworthy that the Windows Installer is an architecture (mostly) and not a development tool - a common misunderstanding. Tools for creating Windows Installer-based installation programs are available from vendors such as InstallShield and Wise. We’ll look at InstallShield Corp.’s InstallShield for Windows Installer in particular.
Amsterdam, The Netherlands, March 2000

6. Why Windows Installer? Better management of shared resources
Developing multilingual installation programs using InstallShield for Windows Installer
Why Windows Installer?
Better management of shared resources
Consistent enforcement of installation rules
Easy customization by administrators
Facilitated selection of desired application features
Automatic repair of configuration problems
In essence:
reduced support costs for software providers
a much improved experience for administrators and end-users
So, what’s the point of all this?
Microsoft is candid in admitting that the Windows Installer was developed in response to the needs of the Microsoft Office suite of products, and its growing support costs. The benefits have become so compelling that it (the Windows Installer) became a cornerstone of Windows 2000.
Perhaps first and foremost, the Windows Installer manages shared resources at the operating system level, rather than depending on each product’s installation program to manage them. This is aimed at reducing “DLL Hell” and improving overall system stability.
The Windows Installer provides a specific set of installation-related operations so installation programs become more consistent and predictable. This is in contrast to the “anything goes” nature of today’s script-based installation programs.
A number of features are provided to simplify deployment and administration of software applications within an enterprise. In particular, administrators have the ability to easily modify an installation package (by creating a transform) to meet their particular needs.
In addition to “Install” and “Don’t install,” the Windows Installer provides new installation options, such as “Install on demand.” The result is that users need not know in advance which product features they need to install.
As a result of the tight coupling with the Windows Shell, the Windows Installer enables automatic installation and repair of product features, thus simplifying application deployment and again improving system stability (additional repair options are available via the add/remove programs applet in the Control Panel).
Hence, the Windows Installer is well positioned to reduce support costs for software providers (one of its original objectives). It also has the features to provide a much improved experience for both a systems administrator and the end user. Everybody wins.
Amsterdam, The Netherlands, March 2000

7. An operating system resident installation service...
Developing multilingual installation programs using InstallShield for Windows Installer
An operating system resident installation service...
Part of the operating system!
Enforces consistent installation rules
Service is “engine” for install program data
Manages shared components on behalf of an application
Can run at elevated privilege level on Windows NT/2000
e.g., non-administrators may install services
Built-in to Windows 2000, and available on Windows 95, Windows 98, and Windows NT 4.0
Use is required for new “Certified for Microsoft Windows” logo (except for server products, for the time being)
It’s significant that the Windows Installer is part of the Windows operating system, because this moves to a common, system implementation functions which were previously implemented (often inconsistently) by each application’s installation program, such as reference counting. In effect, with the Windows Installer, an installation program becomes simply the set of instructions and data for the installation service to operate upon. As a result, you get a consistent enforcement of well-defined installation rules.
The Windows Installer treats each component as a shared entity, and automatically tracks any products which uses it. Hence, install programs need not be concerned with whether uninstalling a file, or even a registry key, will break another application - the Windows Installer handles that!
One problem with conventional installation programs is that on Windows NT (or Windows 2000) common operations such as installing a service requires administrator privileges, which some users may not otherwise be entitled to. The Windows Installer service runs at an elevated privilege level on behalf of the user and thus corrects this problem.
The Windows Installer is built-in to Windows 2000 and is available for the other current Windows platforms (Windows 95, 98, and NT 4.0). (InstallShield for Windows Installer can load the Windows Installer service where needed, so it is very easy to create a Windows Installer-based installation program which will run on any of the Windows Platforms.)
Microsoft has publish specifications for their new “Certified or Microsoft Windows” logo (see references section) which require use of the Windows Installer. This requirement has been relaxed, at least temporarily, for server applications.
Amsterdam, The Netherlands, March 2000

8. A standard format... “Data” for operating system install “Engine”
Developing multilingual installation programs using InstallShield for Windows Installer
A standard format...
“Data” for operating system install “Engine”
Install program is actually a collection of data tables
Establishes product / feature / component hierarchy
Incorporates “standard” actions such as installing fonts
Extendable with custom actions
“.msi” file extension
May be opened and extended with development tools such as InstallShield for Windows Installer
With the Windows Installer, an installation program becomes quite literally a set of data tables. Inherent to the operation of these tables is the concept that a product is composed of selectable features, and that features are in turn composed of components - groups of installable entities such as files and registry keys. Within an installation program you simply set and test property values, and this controls what eventually gets installed.
The Windows Installer architecture defines numerous tables (and corresponding actions) for common installation-related functions, such as installing fonts and controlling services. These standard actions may be extended with custom actions, written in either VBScript, JavaScript, or as a DLL. (With ISWI1.1, InstallShield script may also be used with custom actions.) Custom actions effectively let you do anything you want, but should be used with caution, since they may also compromise some of the intended benefits of the Windows Installer, such as transacted installs.
A Windows Installer setup program, by definition, has the file extension of .msi. (.mst is used for transforms, and .msp is used for patches, and .msm for merge modules.) Windows installer “programs” are often called “Msi packages,” as they are in reality more data than code. Interestingly, .msi files may be opened and edited with development tools such as ISWI, thus enabling administrators to easily modify an installation program’s function. This is also a useful learning tool, as it lets install developers discover how given functions were implemented.
Amsterdam, The Netherlands, March 2000

9. Components and features
Developing multilingual installation programs using InstallShield for Windows Installer
Components and features
Components
Features
“Atomic” unit of installation
Collection of files, registry keys, etc. that are all installed together
Uniquely defined and automatically shared by OS
Not visible to the user
Typical method of distinguishing OS-specific and language-specific resources
Groupings of components
How groups of components are selected to be installed or uninstalled
Exposed to the user
Maintains “feature state”
Install locally
Run from source
Install on demand
Do not install
Here we compare and contrast the concepts of Components and Features.
Starting from the bottom-up, a component represents a grouping of installable entities, such as files and registry keys, that must be installed and uninstalled together. A component must have a single target destination and may have conditions (such as operating system or selected language) which control whether the component actually gets installed. By design, any given file should appear in one and only one component. Components are often quite small and may consist of a single file.
Each component is uniquely defined via a GUID, and all users of a given component are managed by the Windows Installer.
Definition of the components, and the associated conditions, is how a developer controls what gets installed where, and under what conditions.
A feature, on the other hand, represents a grouping of components. They are quite visible to the end user, where components are not. The list of features is what the user selects among when performing a custom install.
A feature maintains something called a “feature state,” which controls what is installed (or uninstalled). Interestingly, to the Windows Installer an uninstall is indistinguishable from an install; it’s just that the target feature states are different. This also lets you go back and selectively install or uninstall individual features as you choose, so that you may, say, remove a tutorial after you’ve completed it.
Features may have subfeatures, so that user choices may be reasonably nested. See the “Feature selection example” slides for an example from Microsoft Office 2000.
Amsterdam, The Netherlands, March 2000

10. Products, Features, & Components
Developing multilingual installation programs using InstallShield for Windows Installer
Products, Features, & Components
Product
(Office)
Feature 2
(Excel)
Feature 1
(Word)
Feature 3
(Word Speller)
Feature 4
(Excel Speller)
This slide depicts the product/feature/component hierarchy.
Starting at the top, a product (in this example, Microsoft Office) represents the highest level of organization. A Windows Installer product is uniquely defined by its own GUID and has a one-to-one relationship with its corresponding .msi file.
When installing the product, you may choose the features to be installed. In this case, where the product is a suite, your top level features are items such as Word and Excel, and you may select respective subfeatures such as a spell checker, in this case.
By selecting the features, you are in turn identifying the candidate components for installation. Components contain the installable resources which should be installed and uninstalled together. In this case, the speller component is shared by two features. This means it will be installed no more than once, and not be uninstalled until both containing subfeatures are themselves uninstalled.
Component 1
(WordCore)
Component 3
(ExcelCore)
Component 2
(MS Speller)
Resource
(Registry Key)
(winword.exe)
(excel.exe)
(Mssp.dll)
Entry Point
(.doc)
(Shortcut)
(.xls)
(CLSID)
Amsterdam, The Netherlands, March 2000

11. Products, Features, & Components
Developing multilingual installation programs using InstallShield for Windows Installer
Products, Features, & Components
Product
(MyProduct)
Feature 2
(Help)
Feature 1
(Executables)
In this example we see how multiple, related components may be associated with a feature.
Here, the Help feature has two language components - one for English and one for German - and these components in turn contain the various help files and such for each language. What’s different in this case is that the help components would include a Component Condition, which controls which components are actually installed when their associated feature is selected. In the Windows Installer, a condition is simply a test which evaluates to true or false, and usually tests for the existence of a property or for the value of a property. In this example the English Help component may have a condition such as ProductLanguage=1033, which indicates this component should only be installed when the selected install language is English. (1033 is the language id code for English.)
The user experience for this example is this: the user selects the install language (via a language selection dialog at the beginning of the install), and then selects the Help feature to be installed. Because of the component design and associated conditions, only the help files for the selected language are installed. The user does not select the components directly - they are not visible to the end user, only features are.
Component 1
(MyProductCore)
Entry Point
(.myp)
(Shortcut)
Resource
(Registry Key)
(myprod.exe)
Component 3
(Help - German)
Entry Point
(Shortcut)
Resource
(Registry Key)
(myprod.hlp)
Component 2
(Help - English)
(CLSID)
Amsterdam, The Netherlands, March 2000

12. Feature selection example
Developing multilingual installation programs using InstallShield for Windows Installer
Feature selection example
We’ve talked about features and such, but lets see what they look like in practice.
Here we see the feature selection dialog from Microsoft Office You get here by choosing a Custom install. It is a Windows Explorer-type tree control, which can be expanded or collapsed by by clicking on the +’s or -’s. The product’s features and nesting of subfeatures are displayed.
The icon to the left of each feature controls its feature state, and this is described in the next slide.
Amsterdam, The Netherlands, March 2000

13. Feature selection example...
Developing multilingual installation programs using InstallShield for Windows Installer
Feature selection example...
Here we see the install options available for a feature.
Run from My Computer means that the feature should be installed on the local machine - your typical install option.
Run all from My Computer means that the feature and all subfeatures should be installed locally - a convenient way of selecting a group of features.
Run from CD indicates the source files should remain on the product media, and only the needed entry points (such as shortcuts or file associations) are to be installed locally. Note: both the install program and the application must be designed to support this option; it doesn’t just happen automatically.
Run all from CD, predictably, applies this install option to the feature and all subfeatures.
Installed on First Use is another term for “Install on demand” - the feature is not installed until one of its components is invoked. Implementing install on demand may require coding changes in the application (in particular, ShellExecute should be use to invoke executables).
Not available means simply do not install this feature (and by implication, any of its subfeatures).
Amsterdam, The Netherlands, March 2000

14. Developing multilingual installation programs using InstallShield for Windows Installer
Data table example
We’ve been saying that a Windows Installer package is simply collection of data tables, and this slide depicts that.
Microsoft provides a tool (via their platform SDK) called Orca that allows you to edit an msi package directly. The list of tables in the package is shown on the left, and the contents of the selected table is shown on the right.
In this particular case we see the InstallExecuteSequence table, which lists the various actions to be performed. Note that the service related actions, which are not applicable to Windows 9x, have the condition “VersionNT”, which means that they are ignored except when running on Windows NT/2000.
Amsterdam, The Netherlands, March 2000

15. A management API for applications and tools...
Developing multilingual installation programs using InstallShield for Windows Installer
A management API for applications and tools...
Tightly coupled with the Windows Shell
Manages file paths on behalf of an application
enables roaming user support
Ensures that requested applications/features are both installed and complete
enables install-on-demand (Advertising)
enables self-repair
Maintains an inventory of installed applications/features
Plays role in enforcing system policies
Now we’re finally to the third element of the Windows Installer - the management APIs.
The Windows Installer is tightly coupled with the Windows Shell. That is, when the Windows Shell attempts to run a program, it first calls the Windows Installer to locate the program. This interaction enables three important functions.
First, the Windows Installer ensures that the requested product is installed. In the install-on-demand scenario, the product installation is launched and the path to the newly installed product is returned to the Windows Shell. This is how an administrator “publishes” an application in a Windows 2000 network.
Second, the Windows Installer ensures that the application is installed correctly (that is, it ensures that the key files of each installed component may be found). In the event of an error, the install repair function is launched and the missing files are automatically reinstalled. This function enables applications to repair themselves.
Third, since the path to the application is managed by the Windows Installer, the location of the application may change and the Windows Shell is still able to access it. This enables roaming user support, where users may log onto different workstations within a Windows 2000 network, and they are still able to access their installed applications and data. (Note: roaming user support also requires proper separation of application and user data - see the Windows logo guidelines for details.)
Since the Windows Installer maintains an inventory of what’s been installed, this information is available to systems management tools. This enables a wide range of system management functions, so that, for example, an administrator could determine programatically whether a service upgrade is applicable to a particular user.
The Windows Installer is also coupled with system policy so that, for example, applications may be available to some sets of users but not others.
Amsterdam, The Netherlands, March 2000

16. InstallShield for Windows Installer (ISWI)
Developing multilingual installation programs using InstallShield for Windows Installer
InstallShield for Windows Installer (ISWI)
A development tool for authoring Windows Installer-based install programs
Creates data tables which compose the .msi file
Includes wizards for stepping you through
creating a standard project
compiling the .msi file and building the output media
creating custom action controls
creating components
adhering to best practices
Also includes support for creating multilingual installs!
Now we move from the Windows Installer service to the development tools you use to create Windows Installer packages, namely InstallShield for Windows Installer, or ISWI.
ISWI provides a development environment from which you can generate all the tables which compose an msi package. The tool handles most of the details, saving the developer from having to to know the meaning of every value of every field in the every table. If you’re developing a Windows Installer package, you really want a tool such as ISWI to work with.
Among other things, ISWI includes a number of wizards which step you through a set of otherwise complex tasks.
The Project Wizard creates an ISWI project file and lets you specify many of the project attributes such as the features, components, files, etc. For simple applications the Project Wizard may perform nearly all of what’s needed.
The Release Wizard collects the options to be used to compile the project into an .msi file and create the output media.
The Custom Action Wizard steps you through the choices available when creating a custom action.
The Component Wizard creates components and advanced settings by working with the files to be included in the components.
The Validate Project Wizard scans a project and reports any internal consistency errors, and thus helps to identify errors which may otherwise be difficult to isolate. (Note: the validation tools provided on the Microsoft Platform SDK are more current and complete than those provided with ISWI.)
ISWI also includes features which simplify the creation of all types multilingual installation programs. We’ll elaborate on those shortly.
Amsterdam, The Netherlands, March 2000

17. ISWI input and output I SWI
Developing multilingual installation programs using InstallShield for Windows Installer
ISWI input and output
Installation logic and user interface design
Application files, registry settings, shortcuts, etc.
Feature and component design
I SWI
Setup.exe
Windows Installer service
.msi file
Language transforms
Application files
Here we look at the basic inputs and outputs of InstallShield for Windows Installer.
The install developer must first understand what needs to go where on a target system. This includes what files in what directories, what registry keys, what shortcuts, etc.
Next, this collection of installable “stuff” needs to be refined into a feature/component hierarchy.
And third, any additional, special processing and user interface requirements must be identified.
With all this, ISWI can be used to develop a project file and build an installation program which yields
1. The .msi file itself
2. The application source files (may or may not be included in the .msi file)
3. A front end, setup.exe file
4. The Windows Installer service redistributables for Windows 9x and NT 4.0
5. Language transforms (.mst files) when the install program supports multiple languages.
Note: numerous build options exist. You may, for example:
- generate a compressed (everything packed into a self-extracting setup.exe) or uncompressed build
- include or exclude the Windows Installer service files for Windows 9x and/or Windows NT (1.2M each)
- display or suppress a preliminary language selection dialog
Note: numerous different build options exist
Amsterdam, The Netherlands, March 2000

18. Setup.exe function flow
Developing multilingual installation programs using InstallShield for Windows Installer
Setup.exe function flow
Determine default language (via user locale)
Display language selection panel
Query Windows Installer version
Install Windows Installer service, if needed
Launch Windows Installer service (msiexec.exe)
Apply selected language transform
Install product
Pass command line parameters
This chart describes the processing performed by the front end setup.exe utility.
Setup.exe is particularly useful with multilingual installation programs, as it presents a language selection dialog in the native language of the user (as determined by the Windows User locale). (Note: the id of the selected language is assigned to the ProductLanguage property, which may be useful later in the install package.)
Setup.exe then looks at the target system and determines whether the Windows Installer service is absent or down-level. If either is the case, then the Windows Installer service packaged with the application is installed.
With the prerequisites for installation in place, setup.exe then launches the Windows Installer - msiexec.exe - to install the product. In doing so, the transform of the selected language is applied so that desired language is displayed in the installation user interface. Also, any command line parameters specified with setup.exe’s /v option are passed.
Note: both setup.exe and msiexec.exe accept their own set of command line parameters. See the ISWI documentation for details by searching on “Command-Line Parameters.”
Amsterdam, The Netherlands, March 2000

19. A demo of ISWI Product (Demo) Feature 2 (DefaultHelpFiles) Feature 1
Developing multilingual installation programs using InstallShield for Windows Installer
A demo of ISWI
Product
(Demo)
Feature 2
(DefaultHelpFiles)
Feature 1
(DefaultProgram)
At this point we’ll pause to see a demo of InstallShield for Windows Installer. We’ll use ISWI to create a simple multilingual installation program, then run the program to see the installation’s user interface and system interactions.
In the demo, we’ll use the default features of the Project Wizard to create the product / feature / component hierarchy shown above. In this case, the application to be installed will be English only, and the installation program will support multiple languages.
Component 1
(Global_Default_Executables)
Component 3
(Global_Default_Help)
Component 2
(Global_Default_DLLs)
Entry Point
(Shortcut)
Resource
(sol.exe)
Resource
(cards.dll)
Resource
(sol.chp)
(sol.hlp)
Amsterdam, The Netherlands, March 2000

20. Localizing an install program
Developing multilingual installation programs using InstallShield for Windows Installer
Localizing an install program
Add entries to English (or default) string table for any translatable text used in messages or added to dialogs
Ensure that custom messages and dialogs reference string table entries
Export string table of default language and translate into supported languages
Import translated string table for each language
InstallShield-provided strings are already translated but may be edited
Verify controls on custom dialogs are properly sized
That’s it!!
We’ve touched on this as we’ve looked at ISWI’s language features, but let’s look in detail at how to localize (that is, translate) an ISIW project.
First, you need to make conscientious use of the string table in whatever your default language (English, by default). Any externally visible text you use, such as in messages or a dialogs, should be derived from a string table entry.
At some point then you will translate your strings. You do this by exporting your string table (could be English or a given language), translating it (typically by a third party), and importing it back into the project file.
Note: you need translate only the strings you added or changed. When you export a string table, all of the strings are there, including the ones InstallShield has already translated. This makes it easy to edit InstallShield’s translations, if you choose, but may cause unnecessary work if you, say, work just from your default language and translate strings which have already been translated. InstallShield will be adding functions to their automation layer which will allow you export only your added and changed strings.
Amsterdam, The Netherlands, March 2000

21. Designing a multilingual install program - Type I
Developing multilingual installation programs using InstallShield for Windows Installer
Designing a multilingual install program - Type I
Language chosen at product build time
Set of supported languages selected via Project Wizard or Project Properties
Language-dependent components identified via Languages field of each component (Setup Design view)
At build time (using the Release Wizard),
filter application by selected language (Filtering Settings dialog)
Include only the selected language and make default (Setup Languages dialog)
Result: single language version of application, with matching language of install program En De
...
Separate Language
Versions (CD & App)
Type I
Now that we’ve seen the language features of ISWI, we can go into detail about how each type of multilingual installation program is designed. You may wish to reference the dialogs shown in the preceding slides.
For a Type I program, where the language is chosen when you build the application, you‘d do the following:
1. You add the languages to be supported by the installation program to the project, using either the Project Wizard or preferably the Project Properties view. This is probably, but not necessarily, the same set of languages supported by the application.
2. You set the languages supported by the application by identifying the language-dependent components in the Setup Design view.
3. You build each language version of install program one-at-a-time. For each build, you filter the application per language (which controls the language version of the application) and include the same language for the install program.
Each build yields an installation program where the language of the installation program matches the language of the application being installed.
Note: Builds can be automated, thus eliminating the manual steps listed above.
Amsterdam, The Netherlands, March 2000

22. Designing a multilingual install program - Type II
Developing multilingual installation programs using InstallShield for Windows Installer
Designing a multilingual install program - Type II
Language chosen at product install time
Set of supported languages selected via Project Wizard or Project Properties
Language-dependent components identified via Conditions field (ProductLanguage property) of each component (Setup Design view)
At build time (using the Release Wizard),
do not filter application by language
Include all languages, and check “Display the Setup Languages dialog” (Setup Languages dialog)
Result: setup.exe’s language selection panel chooses language version of application and language of install program En De
...
Common CD,
separate Application
language Versions
Type II
For a Type II program, where the language is chosen when you install the application, you’d do the following:
1. You add the languages to be supported by the installation program to the project, using either the Project Wizard or preferably the Project Properties view (same as Type I).
2. For each language-specific component, add a component condition in the Setup Design view. A condition of ProductLanguage=nnnn will install the component only if the language id (nnnn) matches the language selected via setup.exe’s language selection dialog. (A condition of SystemLanguageID=nnnn will install the component only if the language id matches the system locale on the target machine.)
Note: search the ISWI help with the string ‘Language Identifiers’ to see the list of language id’s supported by ISWI.
3. When you build the project with the Release Wizard, do NOT filter the application by language, and DO select all languages listed in the Setup Languages dialog (also check the “Display the Setup Languages dialog” checkbox).
This yields an installation program that prompts for the language. The language chosen is used for the subsequent installation user interface AND determines the language version of the installed application.
Amsterdam, The Netherlands, March 2000

23. Designing a multilingual install program - Type III
Developing multilingual installation programs using InstallShield for Windows Installer
Designing a multilingual install program - Type III
Language chosen at product run time
Application’s user interface should include controls to choose language (good to couple with install on demand)
Set of supported languages (for install program) selected via Project Wizard or Project Properties
Design feature/subfeature tree to list supported languages (allows user to easily add or remove languages)
At build time (using the Release Wizard),
do not filter application by language
Include all languages, and check “Display the Setup Languages dialog” (Setup Languages dialog)
Result: setup.exe’s language selection panel chooses language of install program; user selects language version(s) of application to be installed. En De
...
Common CD & App,
multiple language resources
Type III
And for a Type III program, where the language is chosen when you run the application, you’d do the following:
1. You add the languages to be supported by the installation program to the project, using either the Project Wizard or preferably the Project Properties view (same as Type I).
2. Since multiple languages may be installed concurrently, you need to provide the choice of languages to the user. This means adding features/subfeatures for each language. Of course, the language-specific components would be grouped under the corresponding language feature. The components would not otherwise be designated as language-dependent or have language-related component conditions.
3. You build a Type III program the same as a Type II - do NOT filter the application by language, and DO select all languages listed in the Setup Languages dialog (also check the “Display the Setup Languages dialog” checkbox).
This yields an installation program that prompts for the language. The language chosen affects ONLY the subsequent installation user interface. The language version(s) of the application are selected by the user via the feature selection tree.
Note: you would probably want write a custom action that would set the default feature state so that, by default, the installed language version of the application would match the language selected for the install. The AddLocal property is used for this purpose.
Amsterdam, The Netherlands, March 2000

24. Use of Unicode Character strings within the .msi file
Developing multilingual installation programs using InstallShield for Windows Installer
Use of Unicode
Character strings within the .msi file
Exported string files (both Unicode and ASCII text)
License Agreement text (.rtf file)
MSI program interfaces
Windows 2000 (and NT 4.0 for that matter) are Unicode-based systems. Since the Windows Installer was designed as part of Windows 2000, it too uses Unicode for the encoding of the text strings within an .msi file. Since the Windows Installer service also runs on Windows 95 and 98, which are not Unicode based, there are some mixing and matching of Unicode and ASCII text in the process.
When you export a string file, two files are created - a Unicode text file and an ASCII text file (using the standard codepage for that language). You can work with (that is, translate) either file, and import either file back into the project.
InstallShield for Windows Installer defines a License Agreement dialog, which includes a scrollable text control for listing the license agreement text. The license agreement text MUST be in the form of a Rich Text Format (.rtf) file, but the .rtf file may include Unicode characters (if generated at the appropriate level, such as with WordPad on Windows 2000). This level of .rtf file also includes ASCII characters, which would be displayed on Windows 9x systems.
The Windows Installer service has numerous application program interface functions, such as MsiGetProperty, which have both Unicode and ASCII versions on Windows NT/ This enables you to work with the msi-related strings in Unicode on those systems. See ‘Unicode in the Win32 API’ in the Microsoft platform sdk for information working with interfaces in Unicode.
Amsterdam, The Netherlands, March 2000

25. Hints, tips, and gotcha’s
Developing multilingual installation programs using InstallShield for Windows Installer
Hints, tips, and gotcha’s
Must install Windows language resources
New Language Wizard
command syntax for logging
MsiZap
Additional tets scenarios
Multiple files of same name to same target directory
Filtering components with a property set in the UI sequence
Windows 95 bug re: dropdown list on language selection panel
Adding language packs to an existing project
When you include a setup language in the Release Wizard, the associated Windows resources must be installed. Use the Regional Settings applet in the control panel to install Windows language resources.
The New Language Wizard (Under “Tools”) allow you to add languages to ISWI beyond what InstallShield provides. See the ISWI documentation for details.
The log file generated by the Windows Installer can often be quite useful. The setup.exe command syntax to generate the log file is:
setup.exe msifile /i /v”/l*v c:\install.log”
Since Windows Installer-based installs are transacted, when they fail, the system rolls back to the prior state. This is also true for uninstalls, so that a failing uninstall will always remain on the system. To manually uninstall a Windows Installer product, you must clear the cached .msi package. The MsiZap utility, provided on the platform SDK, performs this function.
The Windows Installer introduces new test scenarios, such as run from source, install on demand, and administrative install. These should be included in your test plans.
If you have multiple files of the same name in different components that get installed to the same target directory, they can “collide” in an uncompressed build. You must use the directory table to ensure that the files are properly preserved in the build. Contact the author for details. (ISWI 1.1 provides a Source Location property which corrects this.)
On Windows 9x systems, you cannot filter components (via component conditions) using properties set in the UI sequence. You can, however, filter features.
A Windows 95 bug corrupts the drop-down list on the language selection dialog for some languages (Greek, Russian, and Norwegian(Bokmol)).
If you develop a project and then add the ISWI language packs, you must manually copy the language string tables to the proper directories. Contact the author for details.
Amsterdam, The Netherlands, March 2000

26. Developing multilingual installation programs using InstallShield for Windows Installer
Resources
The Windows Installer Service, a white paper from Microsoft, available at
"Roadmap to Windows Installer Documentation" in the Microsoft Platform SDK, and online at
Application Specification for Microsoft Windows 2000 for distributed applications Version 1.0, available at
InstallShield for Windows installer web page at
InstallShield Knowledge Base at
InstallShield for Windows Installer news groups at news server news.installshield.com
installshield.iswi.general
installshield.iswi.customaction
installshield.iswi.international
InstallSite web site at
Here are additional resources for information on both the Windows Installer and ISWI.
Microsoft has published a white paper, The Windows Installer Service, which provides a good introductory overview.
The nuts and bolts details of the Windows Installer are documented in the Microsoft Platform SDK, available via subscription and also available online. Search on the string “Roadmap to Windows Installer Documentation” to see an index of information.
The application specifications for the “Certified for Microsoft Windows” logo state detailed requirements for application installation, particularly with respect to component definition.
InstallShield’s web site, naturally, lists a variety of both detailed and overview information regarding their products. This includes their knowledge base, which lists numerous how-to articles. You can also download a free, 14-day evaluation copy of ISWI (English only).
InstallShield also has a number of newsgroups related to ISWI. These can be a real gold mine of information - they have worldwide participation and are monitored by InstallShield technical staff. The newsgroups are often your next best choice after the documentation and knowledge base for how-to type questions.
InstallSite is an independent web site devoted to providing resources to install developers. This is a site well worth becoming acquainted with and visiting often.
Amsterdam, The Netherlands, March 2000

27. Developing multilingual installation programs using InstallShield for Windows Installer
Supplemental Slides
The following slides show the language features of InstallShield for Windows Installer, and the accompanying text explains how these features are used to create the different types of multilingual installation programs.
Amsterdam, The Netherlands, March 2000

28. Language features of ISWI
Developing multilingual installation programs using InstallShield for Windows Installer
Language features of ISWI
Here we begin a detailed look at the language features of InstallShield for Windows Installer.
But first… ISWI is available in English, and then language packs (East and West) may be purchased separately and applied. The following slides presume that both the East and West language packs have already been applied.
When you first create a project using the Project Wizard, you are able to choose the languages which the installation program itself will support. For each language you select, the appropriate string tables and dialogs will be created.
It is often useful to develop your installation program initially in your default language, then add the languages later, which is easy to do. This speeds up your build process while you are developing and debugging your install.
Amsterdam, The Netherlands, March 2000

29. Language features of ISWI...
Developing multilingual installation programs using InstallShield for Windows Installer
Language features of ISWI...
Once a project has been created you have a number of views in the development environment to work with. Here we see the Project view.
To add languages to an existing project, you go to the Project view and select Project Properties. When you click on ‘Setup Languages’ you are presented with a list of languages to choose from. Selecting a language immediately adds the corresponding string tables and languages to the project, and deselecting a language removes them.
Adding languages here has the same effect as having added languages when the project was created with the Project Wizard.
Note: the strings and dialogs which InstallShield provides are already translated into the various languages. You will need to translate any strings or dialogs which you add to the project - this process is described in a later chart.
Amsterdam, The Netherlands, March 2000

30. Language features of ISWI...
Developing multilingual installation programs using InstallShield for Windows Installer
Language features of ISWI...
Still in the project view, if we expand the ‘String Tables’ node we see the list of languages currently included in the install. By selecting a given language, we see the set of string identifiers and values for that language. If we right-click on a language, we are presented with the option to import or export that language’s string table.
When you export a string table, you create two tab-delimited text files. One is ASCII text and the other is Unicode text. Both contain the set of identifiers, values, and comments for the strings defined in the project for that language. (Adding a string in your default language automatically adds the string to the string tables of all the other languages.)
When you import a string file, you replace the values of any existing strings and add any new strings defined in the import file, for the given language.
Note: a string table value is a formatted text field, which means it may include font specifications, property values, and other expressions. See the Microsoft Platform SDK for details by searching on the string ‘Formatted’.
Amsterdam, The Netherlands, March 2000

31. Language features of ISWI...
Developing multilingual installation programs using InstallShield for Windows Installer
Language features of ISWI...
There are some cases where you want to identify a component as language-dependent. This is typically when you want to be able to filter by language at build time. That is, create a single-language version install program from a project file that supports multiple languages (i.e.. a Type I multilingual installation).
To mark a component as language-dependant, you go the the Setup Design view and select the component in question. When you click on the Languages property you are presented with a list of languages to select from. In the above example we have designated the Executables_De component as being German.
Note: You would typically NOT designate a component as language-dependant for Type II and Type III multilingual installation programs, unless you also wanted to be able to build language-unique versions of the product (i.e., a Type I program).
Amsterdam, The Netherlands, March 2000

32. Language features of ISWI...
Developing multilingual installation programs using InstallShield for Windows Installer
Language features of ISWI...
We’ve been saying then when you add a language you automatically add that language’s string table and dialogs to the project. We’ve seen the string tables; now here’s the dialogs.
When you edit a dialog in the default language, those changes are automatically replicated to the dialogs of the other languages. This is very useful, because it makes translation of your dialog changes (when string tables are used correctly) almost effortless.
Amsterdam, The Netherlands, March 2000

33. Language features of ISWI...
Developing multilingual installation programs using InstallShield for Windows Installer
Language features of ISWI...
When you’re ready to build your project - create your .msi package - it’s useful to initially use the Release Wizard to choose from among the various build options. (You can re-build later using the same set of options without have to step through the Release wizard again.)
Anyway, if you want your resulting installation program to support a subset of the languages included in your ISWI project (think Type I program, here) then you would select the languages to be supported in the ‘Filtering Settings’ dialog of the Release Wizard.
When you filter by language, then only the language-independent and matching language-dependent components are included in the build. This is exactly the mechanism by which Type I multilingual installation programs are built.
Note: you’re really working with the set of languages which have language-dependent components here, which could conceivably be different from the user interface languages supported by the installation program. We see how to select the language of the install program next.
Amsterdam, The Netherlands, March 2000

34. Language features of ISWI...
Developing multilingual installation programs using InstallShield for Windows Installer
Language features of ISWI...
Further along in the release wizard we get to choose which setup languages the installation program will support, and whether we want to display the Setup Languages dialog (if we don’t then the language defaults to match the user locale, or if no match there, then to the designated default language for the install).
For Type I programs you’d probably choose a single language here to match that of the application. For Type II and III programs you’d probably choose all the languages.
Amsterdam, The Netherlands, March 2000