Proces instalacji – jak to wygląda od środka ?

Proces instalacji pakietu-msi składa się z kilku faz do których zaliczamy m.in. "fazę pozyskiwania" (Acqusition-Phase) podczas, której pozyskiwane są informacje potrzebne do przeprowadzenia instalacji,  "fazę wykonawczą" (Execusion-Phase) podczas, której przeprowadzany jest proces instalacji oraz "fazę powierzania" (Commit-Phase), uruchamianą po prawidłowej instalacji pakietu, podczas której przetwarzane są akcje typu "Commit", nie mające wpływu na poprawność działania zainstalowanego produktu. Istnieje również "faza odwracania" (Rollback-Phase), uruchamiana w przypadku wystąpienia błędu, po wywołaniu której przywracany jest stan systemu sprzed instalacji. 

Rys.8. Fazy instalacji

Faza pozyskiwania (Acquisition-Phase)

Podczas trwania "fazy pozyskiwania" (Acquisition-Phase) zbierane są informacje potrzebne do przeprowadzenia instalacji pakietu-msi, które są później przekazywane dalej do "modułu wykonawczego" (Execusion Engine). "Faza pozyskiwania" jest zawsze wykonywana z uprawnieniami aktualnie zalogowanego użytkownika. 

Pliki z rozszerzeniem .msi są standardowo powiązane z serwisem Windows Installera, przez co proces instalacji uruchamiany jest automatycznie. Po podwójnym kliknieciu na pliku-msi uruchamiany jest "proces kliencki" (Client process), który ładuje pakiet do pamieci operacyjnej. Następnie sprawdzana jest ilość dostępnej pamięci dyskowej oraz status poszczególnych "ficzerów" (Features) w pakiecie. Po czym uruchamiany jest graficzny interfejs użytkownika, pozwalający na interakcję z aktualnie zalogowanym użytkownikiem. Po zebraniu wszystkich parametrów ("przeklikaniu GUI") pakiet przechodzi do tzw. "procesu serwerowego" (Server process), któremu zostają przekazane wszystkie wcześniej zebrane informacje w formie listy poleceń. Ta operacja jest reprezentowana w logu instalacyjnym poprzez wpis "Switching to server" (przykład poniżej).

MSI (c) (DC:AC) [13:32:15:907]: Switching to server: ALLUSERS="1" TARGETDIR="c:\" INSTALLLOCATION="c:\Program Files\TestApp\" CURRENTDIRECTORY="c:\" CLIENTUILEVEL="0" CLIENTPROCESSID="3036" USERNAME="Tester" SOURCEDIR="c:\" ACTION="INSTALL" EXECUTEACTION="INSTALL" SECONDSEQUENCE="1" ROOTDRIVE="c:\" INSTALLLEVEL="1" WIXUI_INSTALLDIR_VALID="1"  ADDLOCAL=ProductFeature  

W przypadku instalacji z podstawowym GUI (Basic GUI) lub w trybie "cichym" (Silent), pomijany jest "proces kliencki" i uruchamiany bezpośrednio "proces serwerowy".

Podczas trwania instalacji zainicjowanej przez użytkownika z uprawnieniami administracyjnymi, wszystkie "ogólnodostępne właściwości" (Public properties) przekazywane są "procesowi serwerowemu". Natomiast, przy instalacji zainicjowanej przez użytkownika z ograniczonymi uprawnieniami, przekazywane są tylko właściwości umieszczone w rekordzie "SecureCustomProperties" tabeli "Properties" . Na podstawie danych przekazanych "procesowi serwerowemu" oraz dodatkowym informacjom o systemie generowany jest "skrypt instalacyjny" (Installation-Script). Przy przejściu z "Acqusiton-Phase" do "Execusion-Phase""menadżerowi konfiguracji" (Configuration manager) przekazywana jest informacja o położeniu "skryptu instalacyjnego".

Faza wykonawcza (Execusion-Phase)

Podczas trwania "fazy wykonawczej" dokonywane są fizyczne zmiany w systemie. W pierwszej kolejności "menadżerowi konfiguracji" (Configuration Manager) przekazywany jest "skrypt instalacyjny". Następnie uruchamiany jest "moduł wykonawczy" (Execusion Engine), który wykonuje operacje zawarte w "skrypcie instalacyjnym". Na tym etapie instalacji przeprowadzane są modyfikacje na plikach oraz na rejestrze systemowym. "Faza wykonawcza" wykonywana jest w kontekście konta systemowego, co zapewnia swobodny dostęp do każdego zasobu systemowego. 

Faza powrotu (Rollback-Phase)

Uaktywnienie "fazy powrotu" następuje w przypadku napotkania błędu podczas wykonywania "skryptu instalacyjnego" lub po przerwaniu procesu instalacji przez użytkownika. "Faza powrotu" ma na celu przywrócenie stanu systemu sprzed instalacji, przy czym obowiazuje tu reguła LIFO (last in – first out) przy przetwarzaniu "skryptu-powrotu" (Rollback-Script). Podczas trwania "fazy wykonawczej" każdej wykonanej "operacji" jest przypisywana "kontr-operacja", gwarantująca przy wystapieniu błędu, powrót do stanu systemu sprzed instalacji. Wszystkie "kontr-operacje" zapisywane są w "skrypcie powrotu" (Rollback-Script).

Faza powierzania (Commit-Phase)

Po prawidłowo przeprowadzonej instalacji produktu i przetworzeniu "skryptu instalacyjnego" uruchamiana jest "faza powierzania" (Commit-Phase). Akcje typu "Commit" wywoływane są zawsze ze "skryptu-powrotu" (Rollback-Script) i wykonywane bezpośrednio po instalacji produktu. Podczas wykonywania akcji typu "Commit" po napotkaniu błędu, często niemożliwym staje się przywrócenie stanu systemu sprzed jej wywołania. Inaczej wygląda to podczas trwania "fazy wykonawczej", gdzie po wystąpieniu błędu przywracany jest stan systemu sprzed instalacji. Typową akcją typu "Commit" jest instalacja assemblies do "GAC" (Global Assembly Cache). Windows Installer nie instaluje assemblies fizycznie w systemie, tylko zaznacza obiekty które mają być zainstalowane, a reszta jest wykonywana w trakcie trwania "fazy powierzania" przez moduł "CLR" (Common Language Interface).

Proces instalacji

Tak jak już wcześniej wspomniano podczas instalacji wykorzystywane są dwa główne procesy tzw. "kliencki" i "serwerowy". "Proces kliencki" odpowiedzialny jest za interakcje z użytkownikiem a "serwerowy" za fizyczną modyfikację systemu. Rozdzielenie obu procesów można zaobserwować podczas instalacji pod "Task Managerem". Oba mają tą samą nazwę "msiexec.exe", lecz różnią się tym, że "proces kliencki" jest wykonywany w kontekście aktualnie zalogowanego użytkownika, a "serwerowy" w lokalnego konta systemowego.     

Procesy ? kliencki i serwerowy podczas instalacji

Rys.9. Procesy – kliencki i serwerowy podczas instalacji

Podczas trwania instalacji można zauważyc też dodatkowe procesy identyfikowane przez wpis "msiexec.exe". Są to tak zwane "Custom Action-Server", które można zidentyfikować po argumencie "-Embedding" w lini poleceń.

Proces kliencki (Client process)

Po uruchomieniu instalacji pakietu, kontrolę nad dalszym jej przebiegiem przejmuje "proces kliencki". W pierwszej kolejności sprawdzany jest aktualny stan systemu oraz czy aktualnie instalowany produkt istnieje już w systemie. Jeżeli produkt jest już zainstalowany w systemie, to w dalszym procesie instalacji wykorzystywana jest kopia pakietu zapisana w katalogu "%windir%\Installer". W przypadku stwierdzenia braku kopii pakietu, następuje ponowne jej skopiowanie z oryginalnej lokalizacji instalacyjnej. Jeżeli podczas sprawdzania stanu systemu stwierdzony zostanie brak zainstalowanego produktu, to do tymczasowego katalogu aktualnie zalogowanego użytkownika "%temp%" kopiowane są pliki instalacyjne i uruchamiany jest proces instalacji.

W pierwszej kolejności sprawdzane są "zasady ograniczeń oprogramowania" (SAFER), które wraz z założonymi regułami zezwalają lub nie na instalację produktu w systemie. W przypadku stwierdzenia istnienia produktu w systemie procedura sprawdzania "zasad ograniczeń oprogramowania" nie jest wykonywana. 

Po pomyślnym przeprowadzeniu procedury "sprawdzania ograniczeń oprogramowania", kontrola nad instalacją pakieteu przekazywana jest do "modułu instalacyjnego" (Installation Engine), gdzie następuje przetworzenie argumentów linni poleceń. Przetwarzane są tam dodatkowo informacje zawarte we "właściwościach" (tabela "Property"), transformacjach i plikach typu patch (.msp). Następnie sprawdzana jest ilość dostępnej pamięci zarówno fizycznej jak i wirtualnej, typ procesora, katalogi systemowe, architektura systemu (32/64 bity) oraz wersja Windows Installera. Baza danych pakietu-msi otwierana jest tylko do odczytu, po to aby zapobiec przypadkowemu nadpisaniu. Następnie w pamięci operacyjnej tworzona jest tymczasowa kopia tabeli "Property" o nazwie "_Property" (do której zapisywane są przetworzone "właściwości" (Properties)). W kolejnym kroku "moduł instalacyjny" sprawdza czy są dostepne wymagane uprawnienia do instalacji produktu w systemie. W przypadku uruchomienia instalacji przez użytkownika z podwyższonymi uprawnieniami, tylko właściwości sklasifikowane jako "bezpieczne" (umieszczone w rekordzie "SecureCustomProperties" tabeli "_Property") przekazywane są "procesowi serwerowemu". Ustawienie właściwości "EnableUserControl" w tabeli "Property" na "1" powoduje przekazanie wszystkich "ogólnodostepnych właściwości" (Public Properties) "procesowi serwerowemu", bez względu na to, że instalacji pakietu została uruchomiona przez użytkownika z podwyższonymi uprawnieniami (nie mówimy tu o użytkowniku posiadajacemu lokalne prawa administracyjne). 

Akcje najwyższego poziomu (Top-Level-Actions)

Przebieg wykonania "akcji najwyższego poziomu" jest zależny od tego z jakim parametrem została uruchomiona instalacja. Każdemu rodzajowi wykonywanej instalacji  ("INSTALL", "ADMIN" czy "ADVERTISE") są przypisane poszczególne "tabele sekwencyjne" (Sequence tables), które zawierają opis kolejnych kroków instalacji oraz są odpowiedzialne za prawidłową obsługę graficznego interfejsu użytkownika. W trakcie trwania "procesu klienckiego" wykorzystywane są następujące tabele (w zależnosci od rodzaju uruchomionej instalacji): "INSTALL" (InstallUISequence), "ADMIN" (AdminUISequence), "ADVERTISE" (AdvtUISequence). W przypadku standardowej instalacji (typu "INSTALL") ilość dostępnej przestrzeni dyskowej wyliczana jest przy pomocy następujacych akcji: "CostInitialize", "FileCost" oraz "CostFinalize". Dodatkowo sprawdzany jest aktualny status komponentów i "ficzerów" oraz przyporządkowywany folder instalacyjny. 

Top-Level-Actions

Rys.10. Top-Level-Actions

Najwazniejszą akcją w tabelach typu "InstallUISequenze" oraz "AdminUISequenze" jest "ExecuteAction", która przełącza proces "kliencki" na "serwerowy". Należy tutaj dodać, że w przypadku instalacji opartej na anonsowaniu produktu ("ADVERTISE"), graficzny interfejs użytkownika nie jest brany pod uwagę, dlatego tabela "AdvtUISequence" jest pusta.

Umiejscowienie akcji w tabeli ?InstallUISequence?

Rys.11. Umiejscowienie akcji "CostInitialize", "FileCost"oraz "CostFinalize" w tabeli "InstallUISequence" (erytor ORCA) 

Poniższy wycinek logu pokazuje w jaki sposób zbierane i przetwrzane są informacje generowane przez akcje "CostInitialize", "FileCost" oraz "CostFinalize" (tebela: "InstallUISequence") podczas trwania "procesu klienckiego".

MSI (c) (78:7C) [12:27:19:832]: Doing action: CostInitialize

Aktion gestartet 12:27:19: CostInitialize.

Aktion beendet 12:27:19: CostInitialize. Rückgabewert 1.

MSI (c) (78:7C) [12:27:19:832]: Doing action: FileCost

Aktion gestartet 12:27:19: FileCost.

Aktion beendet 12:27:19: FileCost. Rückgabewert 1.

MSI (c) (78:7C) [12:27:19:847]: Doing action: CostFinalize

Aktion gestartet 12:27:19: CostFinalize.

MSI (c) (78:7C) [12:27:19:847]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'.

MSI (c) (78:7C) [12:27:19:847]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'.

MSI (c) (78:7C) [12:27:19:847]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'.

MSI (c) (78:7C) [12:27:19:847]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'.

MSI (c) (78:7C) [12:27:19:847]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'.

MSI (c) (78:7C) [12:27:19:847]: PROPERTY CHANGE: Adding INSTALLDIR property. Its value is 'c:\Programme\Test\'.

MSI (c) (78:7C) [12:27:19:847]: Target path resolution complete. Dumping Directory table…

MSI (c) (78:7C) [12:27:19:847]: Note: target paths subject to change (via custom actions or browsing)

MSI (c) (78:7C) [12:27:19:847]: Dir (target): Key: TARGETDIR , Object: c:\

MSI (c) (78:7C) [12:27:19:847]: Dir (target): Key: INSTALLDIR , Object: c:\Programme\Test\

Aktion beendet 12:27:19: CostFinalize. Rückgabewert 1.

Proces serwerowy (Server process)

Przebieg "procesu serwerowego" jest podobny do "procesu klienckiego". Podstawowym elementem tego procesu jest "manager konfiguracji" (Confguration manager), któremu przekazywane są informacje dotyczące instalacji, bezpośrednio od "procesu klienckiego" – należą do nich m.in.: kod poduktu (ProductCode), "Top-Level-Actions", ustawienia parametrów instalacji, informacje do zestawienia protokołu instalacyjnego oraz "UI-Handler". Następnie uruchomiany jest "moduł instalacyjny" (Installation Engine) i startowany proces instalacji.  W kolejnym kroku analizowany jest pakiet oraz uruchamiana jest procedura sprawdzania "zasad ograniczeń oprogramowania" (SAFER). W przypadku stwierdzenia braku produktu w systemie, pakiet instalacyjny kopiowany jest do katalogu (%windir%\Installer). "Proces serwerowy" nie generuje żadnego GUI-użytkownika, dlatego wszystkie informacje wysyłane do klienta są przetwarzane przez "UI-Handler" i odpowiedio wyświetlane na ekranie. Przy instalacjach w trybie "cichym" (silent) informacje przekazywane klientowi nie są wyświetlane na ekranie. "Proces serwerowy"  podobnie jak "kliencki" wykorzystuje "Top-Level-Actions" i w zależności od typu instalacji są tu wykorzystywane następujące tabele: "INSTALL" (InstallExecuteSequence), "ADMIN" (AdminExecuteSequence), "ADVERTISE" (AdvtExecuteSequence). Podczas trwania standardowej instalacji (typu INSTALL) przetwarzana jest tabela "InstallExecuteSequence" i zbierane są m.in. informacje o wymaganiach systemowych (akcja: "LaunchCondition") , zależnościach od innych produktów (akcja: "AppSearch") oraz wymaganej minimalnej ilości przestrzeni dyskowej (akcje: "CostInitialize""FileCost" oraz "CostFinalize").

Umiejscowienie akcji w tabeli ?InstallExecuteSequence?

Rys.11. Umiejscowienie akcji "LaunchCondition", "AppSearch", "CostInitialize", "FileCost" oraz "CostFinalize" w tabeli "InstallExecuteSequence" (erytor ORCA) 

Poniżej zaprezentowano wycinek przykładowego logu wraz z umiejscowieniem poszczególnych akcji.  

Aktion 10:21:47: INSTALL. 

Aktion gestartet 10:21:47: INSTALL.

MSI (s) (1C:A4) [10:21:47:362]: Running ExecuteSequence

MSI (s) (1C:A4) [10:21:47:362]: Doing action: LaunchConditions

Aktion 10:21:47: LaunchConditions. Auswerten von Startbedingungen…

Aktion gestartet 10:21:47: LaunchConditions.

Aktion beendet 10:21:47: LaunchConditions. Rückgabewert 1.

MSI (s) (1C:A4) [10:21:47:502]: Doing action: AppSearch

Aktion 10:21:47: AppSearch. Suchen nach installierten Anwendungen…

Aktion gestartet 10:21:47: AppSearch.

MSI (s) (1C:A4) [10:21:47:502]: Skipping AppSearch action: already done on client side

Aktion beendet 10:21:47: AppSearch. Rückgabewert 0.

MSI (s) (1C:A4) [10:21:47:518]: Doing action: CostInitialize

Aktion 10:21:47: CostInitialize. Berechnen von Speicherplatzbedarf…

Aktion gestartet 10:21:47: CostInitialize.

Aktion beendet 10:21:47: CostInitialize. Rückgabewert 1.

MSI (s) (1C:A4) [10:21:47:518]: Doing action: FileCost

Aktion 10:21:47: FileCost. Berechnen von Speicherplatzbedarf…

Aktion gestartet 10:21:47: FileCost.

MSI (s) (1C:A4) [10:21:47:518]: Note: 1: 2262 2: MsiAssembly 3: -2147287038 

MSI (s) (1C:A4) [10:21:47:518]: Note: 1: 2262 2: Registry 3: -2147287038 

MSI (s) (1C:A4) [10:21:47:518]: Note: 1: 2262 2: Class 3: -2147287038 

MSI (s) (1C:A4) [10:21:47:518]: Note: 1: 2262 2: Extension 3: -2147287038 

MSI (s) (1C:A4) [10:21:47:518]: Note: 1: 2262 2: TypeLib 3: -2147287038 

MSI (s) (1C:A4) [10:21:47:518]: Note: 1: 2262 2: MoveFile 3: -2147287038 

MSI (s) (1C:A4) [10:21:47:518]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 

MSI (s) (1C:A4) [10:21:47:518]: Note: 1: 2262 2: ReserveCost 3: -2147287038 

Aktion beendet 10:21:47: FileCost. Rückgabewert 1.

MSI (s) (1C:A4) [10:21:47:533]: Doing action: CostFinalize

Aktion 10:21:47: CostFinalize. Berechnen von Speicherplatzbedarf…

Aktion gestartet 10:21:47: CostFinalize.

MSI (s) (1C:A4) [10:21:47:533]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'.

MSI (s) (1C:A4) [10:21:47:533]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'.

MSI (s) (1C:A4) [10:21:47:533]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'.

MSI (s) (1C:A4) [10:21:47:533]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'.

MSI (s) (1C:A4) [10:21:47:533]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'.

MSI (s) (1C:A4) [10:21:47:533]: Dir (target): Key: TARGETDIR , Object: C:\

MSI (s) (1C:A4) [10:21:47:533]: Dir (target): Key: INSTALLDIR , Object: C:\Programme\Test\

Aktion beendet 10:21:47: CostFinalize. Rückgabewert 1.

Przy wyliczaniu potrzebnej przestrzeni dyskowej brane są pod uwagę wszystkie możliwe scenariusze instalacji. Dodatkowo analizowane są informacje o statusie poszczególnych komponentów, takie jak:

  • Status instalacji (InstallState) – status komponentu zainstalowanego już w systemie
  • Status żądania (RequestState) – status komponentu, który powinien być utworzony po instalacji
  • Staus wykonania (ActionState) – akcja, która musi być wykonana, po to aby przestawić status komponentu ze "statusu instalacji" na "status żądania"

Następnie uruchamiana jest akcja "InstallValidate", sprawdzająca fizycznie dostępną ilość miejsca na dysku. W następnym kroku sprawdzane jest czy instalowane pliki są już w użyciu. Akcja "InstallInitialize" kończy proces pozyskiwania informacji o dostępnej przestrzeni dyskowej. Cały proces przedstawiony jest w logu poniżej.

Aktion beendet 10:21:47: CostFinalize. Rückgabewert 1.

MSI (s) (1C:A4) [10:21:47:549]: Doing action: InstallValidate

Aktion 10:21:47: InstallValidate. Bestätigen der Installation…

Aktion gestartet 10:21:47: InstallValidate.

MSI (s) (1C:A4) [10:21:47:549]: Feature: Complete; Installed: Absent;   Request: Local;   Action: Local

MSI (s) (1C:A4) [10:21:47:549]: Component: cibmrg32.exe; Installed: Absent;   Request: Local;   Action: Local

MSI (s) (1C:A4) [10:21:47:549]: Component: idfhook.dll; Installed: Absent;   Request: Local;   Action: Local

MSI (s) (1C:A4) [10:21:47:549]: Component: jhekthueb.aps; Installed: Absent;   Request: Local;   Action: Local

MSI (s) (1C:A4) [10:21:47:549]: Component: cib.dll; Installed: Absent;   Request: Local;   Action: Local

MSI (s) (1C:A4) [10:21:47:549]: Component: __cibmrg32.exe65; Installed: Null;   Request: Local;   Action: Local

MSI (s) (1C:A4) [10:21:47:549]: Component: __jhekthueb.aps65; Installed: Null;   Request: Local;   Action: Local

MSI (s) (1C:A4) [10:21:47:721]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'.

Aktion beendet 10:21:47: InstallValidate. Rückgabewert 1.

MSI (s) (1C:A4) [10:21:47:768]: Doing action: InstallInitialize

Aktion 10:21:47: InstallInitialize

Aktion gestartet 10:21:47: InstallInitialize.

MSI (s) (1C:A4) [10:21:47:768]: Machine policy value 'AlwaysInstallElevated' is 0

MSI (s) (1C:A4) [10:21:47:768]: User policy value 'AlwaysInstallElevated' is 0

Aktion beendet 10:21:47: InstallInitialize. Rückgabewert 1.

Na początku zamieszczonego wycinka logu wywoływana jest akcja "InstallValidate" sprawdzająca status "ficzerów" i komponentów (wpis "Feature: Complete; Installed: Absent;   Request: Local;   Action: Local"). Można tu zauważyć, że poszczególne komponenty mają swoje wirtualne odpowiedniki, nie wystepujące fizycznie w bazie danych pakietu. Przykładowo komponent "cibmrg32.exe65" ma swój wirtualny odpowiednik o nazwie "__cibmrg32.exe65". Tworzenie wirtualnych komponentów ma na celu sprawdzenie wymaganej przestrzeni dyskowej, w przypadku instnienia komponentów zawierających zasoby instalowane w wielu miejscach na dysku. Standardowo każdy komponent jest powiązany ze swoim katalogiem instalacyjnym co ma swoje odzwierciedlenie w tabeli "Components", gdzie każdemu komponentowi przyporzadkowany jest wskażnik do tabeli "Directory". Dlatego, aby wyliczyć wymagane miejsce dla wielu lokalizacji, tworzony jest tymczasowy komponent, którego nazwa zaczyna sie zawsze od dwóch podkreślników "__".  Na końcu nazwy każdego wirtualnego komponentu umieszczana jest liczba 65, która jest zwiększana o jeden w przypadku, gdy komponent posiada więcej zasobów instalowanych w rózne miejsca na dysku. Cały proces wyliczania miejsca na dysku zamykany jest przez właściwość "CostingComplete", której przypisywana jest wartość "1".

Skrypt instalacyjny (Installation-Script)

Podczas tworzenia skryptu instalacyjnego, "moduł instalacyjny" (Installation Engine) jest blokowany przez wprowadzenie do rejestru klucza "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\InProgress", mającego na celu blokowanie uruchomienia innych instalacji opartych na Windows Installerze. W tym samym czasie w katalogu "%windir%\Installer" tworzony jest plik o rozszerzeniu ".IPI" (In-Progress-Information), do którego zapisywane są informacje o stanie instalacji i ewentualnym restarcie systemu. 

Klucz "InProgress" zawieający informacje o pliki .ipi

Rys.12. Klucz rejestru "InProgress" zawierający informacje o umiejscowieniu pliku .IPI

Następnie budowany jest skrypt i zapisywane w nim instrukcje zawierające informacje oraz parametry wykonania poszczególnych akcji (np. "WriteRegistryValues"). Wycinek logu zamieszczony poniżej zawiera fragment typowej instrukcji podczas budowania skryptu instalacyjnego.

MSI (s) (1C:A4) [10:21:49:344]: Executing op: SetTargetFolder(Folder=C:\Programme\Test\)

MSI (s) (1C:A4) [10:21:49:344]: Executing op: SetSourceFolder(Folder=1\Progra~1\Test\|Program Files\Test\)

MSI (s) (1C:A4) [10:21:49:344]: Executing op: ChangeMedia(,MediaPrompt=Legen Sie die CD ein: [ProductName] LABEL,MediaCabinet=Cabs.w1.cab,BytesPerTick=32768,CopierType=2,ModuleFileName=

C:\WINDOWS\Installer\224c4.msi,,,,,IsFirstPhysicalMedia=1)

MSI (s) (1C:A4) [10:21:49:344]: Executing op: FileCopy(SourceName=JHEKTH~1.APS|jhekthueb.aps,SourceCabKey=jhekthueb.aps,

DestName=jhekthueb.aps,Attributes=0,FileSize=1536,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,,,

InstallMode=58982400,HashOptions=0,HashPart1=-147834690,HashPart2=1678438295,

HashPart3=-757673411,HashPart4=876756744,,)

MSI (s) (1C:A4) [10:21:49:344]: File: C:\Programme\Test\jhekthueb.aps; To be installed; Won't patch; No existing file

MSI (s) (1C:A4) [10:21:49:344]: Source for file 'jhekthueb.aps' is compressed

InstallFiles: Datei: jhekthueb.aps 

W trakcie tworzenia skryptu operacje dotyczące poszczególnych akcji umieszczane są w tymczasowym pliku (z prefiksem "MSI") zapisywanym w katalogu "%windir%\installer".

Tymczasowy plik skryptu

Rys.13. Umiejscowienie tymczasowego plik skryptu

Typ skryptu zapisywanego pod "%windir%\Installer" jest zależny od rodzaju uruchominej instalacji. W pierwszej kolejności w skrypcie zapisywany jest nagłówek (Header) zawierający podstawowe informacje o pakiecie (przykład poniżej).

Header(Signature=1397708873,Version=405,Timestamp=1064260280,LangId=1031,Platform=0,

ScriptType=1,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)

MSI (s) (1C:A4) [10:21:49:157]: Executing op: ProductInfo(ProductKey={EA6A441F-8D25-4BFD-9B44-F364677111C4},

ProductName=Test,PackageName=Test.msi,Language=1031,Version=135725056,Assignment=1,

ObsoleteArg=0,,,PackageCode={3874A03E-BCCC-488E-9DD2-0622FE61B228},,,InstanceType=0,LUASetting=0,RemoteURTInstalls=0,ProductDeploymentFlags=3)

Nagłówek skryptu zawiera m.in informacje o: sygnaturze (Signature), wersji Windows Installera (Version), stemplu czasowym (Timestamp), języku (LangId), platformie systemowej (Platform), typie skryptu (ScriptType), kompatybilności skryptu (ScriptMinorVersion, ScriptAttributes) oraz dodatkowym ustawieniom skryptu (ScriptAttributes).

Poniżej nagłówka zapisywane są informacje o instalowanym produkcie, m. in. o: nazwie produktu (ProductName), nazwie pakietu (PackageName) czy chociażby kodzie pakietu (PackageCode). W dalszej kolejności przetwarzane są kolejne akcje wykonywane według kolejności ich umieszczenia w tabeli sekwencyjnej. Podczas wykonywania tych operacji "moduł instalacyjny" (Installation Engine) otrzymuje informacje o obiektach wraz z przypisanymi do nich "warunkami" (Conditions). W przypadku gdy, po przetworzeniu warunku zwrócona zostanie wartość "True", do skryptu instalacyjnego zapisywana jest instrukcja wraz z parametrami jej wykonania. W podobny sposób przetwarzana jest większość akcji zapisanych w tabeli sekwencyjnej, za wyjątkiem niektórych umieszczonych pomiedzy "InstallInitialize" i "InstallFinalize", które są wykonywane na bieżąco. 

Bardzo ważnymi z punktu widzenia przetwarzania sktyptu są dwie akcje: "ScheduleReboot" oraz "ForceReboot" odpowiedzialne za restart systemu. Pierwsza z nich "ScheduleReboot" wymusza restart systemu po przeprowadzonej poprawnie instalacji, druga "ForceReboot" wykonywana jest natychmiastowo. W zależności od tego w jaki sposób została uruchomiona instalacja wyświetlane jest lub nie okienko informujące użytkownika o restarcie systemu. W przypadku instalacji typu "silent" restart systemu jest przeprowadzany automatycznie bez interakcji z użytkownikiem. Podczas wykonywania akcji "ForceReboot" w rejestrze pod kluczem "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" umieszczany jest wpis z kodem produktu oraz dodatkowymi parametrami wywołania pakietu.

Klucz ?HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnce?

Rys.14. Klucz  "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" 

Dodatkowo w kluczu rejestru "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\RunOnceEntries" zapisywane są dodatkowe parametry, które po restarcie systemu wraz z plikiem ".IPI" używane są do kontynuowania instalacji produktu.

Klucz ?HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInstallerRunOnceEntries?

Rys.15. Klucz  "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\RunOnceEntries" 

Wykonanie skryptu i modyfikacja stanu systemu

Po prawidłowym przetworzeniu wszystkich akcji i utworzeniu skryptu, sterowanie przekierowywane jest do "modułu wykonawczego" (Script Executor), któremu przekazywane są następujące argumenty:

  • wskaźnik na plik skryptu
  • wskaźnik na obiekt obsługujący wyświetlanie okienek z informacjami podczas instalacji
  • wskaźnik do obiektu zarządzającego katalogami
  • logiczny argument do sprawdzania ustawienia funkcji powrotu (Rollback)

Następnie "moduł wykonawczy" sprawdza czy instalacja ma być wykonana z podwyższonymi uprawnieniami oraz analizuje atrybuty zawarte w nagłówku (Header) skryptu. W kolejnym kroku wykonywane są operacje zawarte w skrypcie i modyfikowany jest system. Miejsce w którym uruchamiany jest skrypt instalacyjny, można znaleźć w logu instalacyjnym (przykład poniżej).

Aktion 15:42:01: InstallFinalize. 

Aktion gestartet 15:42:01: InstallFinalize.

MSI (s) (20:C8) [15:42:01:855]: Running Script: C:\WINDOWS\Installer\MSI22.tmp

MSI (s) (20:C8) [15:42:01:855]: PROPERTY CHANGE: Adding UpdateStarted property. Its value is '1'.

MSI (s) (20:C8) [15:42:01:855]: Executing op: Header(Signature=1397708873,Version=405,Timestamp=1064271169,LangId=1031,Platform=0, ScriptType=1,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)

MSI (s) (20:C8) [15:42:17:026]: Executing op: End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=120560860)

Po prawidłowo przeprowadzonej instalacji i utworzeniu skryptu-powrotu (Rollback-Script), wykonywane są akcje typu "Commit" (tylko gdy, właściwość "DISABLEROLLBACK" nie jest ustawiona). Następnie odblokowywany jest "moduł instalacyjny", poprzez usunięcie klucza rejestru "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\InProgress" oraz pliku ".IPI". W następnym kroku "moduł instalacyjny" jest ponownie blokowany, aż do momentu, wykonania wszystkich akcji użytkownika zdefiniowanych jako asynchroniczne. Dodatkowo sprawdzane jest czy, wymagany jest restart systemu. Jeżeli tak, to polecenie restartu przekazywane jest "procesowi klienckiemu" i wyświetlany jest komunikat informujacy o restarcie systemu. W przypadku, gdy instalacja została uruchomiona w trybie "cichym" (silent), restart systemu wykonywany jest automatycznie (tylko gdy, właściwość "REBOOT" nie jest ustawiona na pomijanie restartu, "REBOOT=Suppress" lub "REBOOT=ReallySuppress"). Na samym końcu z systemu usuwane są wszystkie tymczasowe pliki instalacyjne oraz skrypt instalacyjny. 
Be Sociable, Share!
  • avatar
    You may use these HTML tags: <a> <abbr> <acronym> <b> <blockquote> <cite> <code> <del> <em> <i> <q> <s> <strike> <strong>

  • Comment Feed for this Post
Go to Top