tw m installation read me

8/10/2019 Tw m Installation Read Me

http://slidepdf.com/reader/full/tw-m-installation-read-me 1/5

TWM Installation Package

Introduction The purpose of this document is to outline the structure, build process, installation

process, and discuss issues that contributed to the current structure of the install kit

for TWM.

Contents The install kit contains everything needed to install and run TWM on Windows XP,

ista, and Windows ! "#bit and $% P&s. Items necessary to install TWM include'

(. ) self e*tracting archive for encompassing the whole install kit and used to

distribute to users.#. ) .M+I installation le containing nearly all necessary information for

installing TWM and the Win-+ driver.". The /if*)pp -tility for installing the Win-+ driver package%. isual &00 #112 +P( redistributable installer that installs Microsoft runtime

libraries re3uired by TWM to run.2. )n additional application, named Install4elper, used to congure the .M+I le

to specically target the P& TWM will install on and run the runtime library

installer.

The install kit includes other les needed by TWM to run correctly on the target

machine including the TWM program itself, the Win-+ driver package, the Well

)naly5er rmware les, help documentation, and optional les such as e*ample wellles.

The self e*tracting archive contains the entire install kit and is what we distribute to

clients6users. It contains % les' the .M+I installation le, the runtime library

installer, Install4elper, and the setup program. )ll other les are contained within

the .M+I le.

The .M+I holds all of the information necessary for Windows to install TWM and the

Win-+ driver package. It supports clean installations and replacement6upgrade

installations. It is designed to install TWM on both "# bit and $% bit Windows.

The /if*)pp utility handles installing driver packages. It is the recommended

method for installing drivers when distributing them with an install kit of an

application. It is used by adding a merge module to an installation pro7ect in isual

+tudio, building the pro7ect, then running a post build script that modies the .M+I

le to designate driver packages to install.



The isual &00 #112 +P( redistributable installer installs runtime libraries and

conguration re3uired by applications created with isual +tudio &00 #112 +P( to

run on machines without isual +tudio installed. The runtime libraries are also

included in the .M+I as a merge module.

The Install4elper will congure the .M+I to specically target the operating systemarchitecture 8"#bit or $% bit Windows9 TWM will be installed on. It also acts as the

bootstrap for the runtime libraries installer and the setup program.

Build Processisual +tudio handles the ma7ority of the build process itself. )ll les added to the

installer pro7ect are added to the .M+I based on properties set within isual studio

for that le. It handles detecting dependencies and merging merge modules to the

M+I.

There are two tasks it is unable to perform. The rst is specifying Win-+ as a driverpackage to be installed with TWM. We have a post build script called :ditMsi.vbs

that adds an entry to the Msi/riverPackages table in the output .M+I for the Win-+

driver package. The entry references the inf le of the driver.

The second task is building the install kit into the self e*tracting archive. We do this

by running the I:*press utility in combination with a .sed conguration le to build

the archive.

Installation Process

The installation process starts out with the self e*tracting archive e*tracting itscontained les; in this case, the .M+I, Install4elper, setup, and runtime library

installer. It then e*ecutes the Install4elper application. Install4elper congures

the .M+I based on the P&s operating system architecture and runs the runtime

library installer for ista systems. Then it runs the setup program, which begin the

installation for TWM and the Win-+ driver.



Driver Installation Problem<ormally, Windows installers target only one specic operating system architecture,

either "#bit or $%bit Windows. Microsoft built two di=erent merge modules to addthe /if*)pp utility to .M+I les with this in mind. The $%bit merge module includes

the $% bit version of the /if*)pp utility and the "# bit merge module includes the "#

bit version of the /if*)pp utility. )s a result, two separate installers must be built to

support installation on both architectures.



Figure 1 – Standard DifxApp Merge Modules and te resulting installers

4owever, we wanted to support installing TWM on both architectures with 7ust one

install kit. We decided to create our own custom /if*)pp merge module that would

include both versions of the /if*)pp utility.

Figure ! " Custom DifxApp Merge module for a universal installer

This wasn>t as straightforward as combining the components of the two mergemodules. The /if*)pp utility is intimately tied with the .M+I it is merged with,

particularly with the use of custom actions. Three custom actions, Msi/riverinstall,

Msi/river-ninstall, and Msi/river?ollback, all originally hooked directly into /if*)pp

dll s for the target operating system architecture; i.e., when merging the /if*)pp

"#bit Merge Module to an .M+I, the custom actions hooked directly into a "#bit

/if*)pp dll, and likewise for the $%bit /if*)pp merge module the custom actions

hooked directly into a $%bit /if*)pp dll. ecause both "#bit and $%bit dlls are

included in the custom merge module, and the target operating system architecture

is not known at build time, the custom actions cannot be set. Instead, they must be

set at runtime. This is where the Install4elper application comes in.

The Install4elper application checks the operating system architecture and adds the

three custom actions, targeted to the appropriate dll, to the installer. This

guarantees the correct /if*)pp utility is used on the user>s P&. )fter the

Install4elper congures the .M+I, it runs the setup program which begins the

installation for TWM.



#ista Compatibilit$ issueWhen an application is built in isual +tudio that uses specic Windows runtime

libraries, such as M@& and )TA, the application needs to be distributed with those

libraries. Microsoft>s solution for this is to simply add merge modules for the

respective libraries to the installation pro7ect of the application. When the

application is installed, the libraries are installed and congured to be used with theapplication. @or the most part, this works. 4owever, due to a bug in

replacement6upgrade installations on ista that include the isual +tudio &00 #112

runtime libraries, the application is not congured correctly to use those libraries. )s

a result, a Bside by side congurationC error occurs.

+ide by side conguration errors do not occur if the runtime libraries are installed

independently from an application prior to the replacement install taking place.

Thus, our solution to this problem involves installing the runtime libraries separately

from the application prior to installation. To do this, the Install4elper runs the

installer for the runtime libraries prior to initiating the setup process. To simplify the

installation of the runtime libraries for the user, the installer is run in passive mode,

re3uiring no input from the user but allows them to see a dialog bo* displaying the

progress bar while installing the runtime libraries. If the runtime libraries are already

installed, the installer is smart enough to not reinstall and 7ust e*its.

)s a side note, the runtime library merge modules are still merged with the .M+I for

Windows XP and Windows ista.

tw m installation read me

Documents