Windows Installer w systemach 64-bitowych

Różnorodność platform sprzętowych przyczyniła się do tego, że przy budowaniu pakietu wymagane jest określenie, dla której z nich jest on przeznaczony. Informacje te zapisywane są w pakiecie w polu „PID_TEMPLATE”  w „Summary Information Stream”. 32-bitowa platforma oznaczana jest poprzez wartość „x86”. W przypadku 64-bitowej platformy możliwości jest więcej, ze względu na różnorodność występujących tu architektur procesorów. Poniżej przedstawiono różnice pomiędzy poszczególnymi oznaczeniami: „x86”, „AMD64”, „IA64”, „EM64T” oraz „IA64„.

x86 – klasycznna 32-bitowa architektura procesora, gdzie 32- bitowe procesy wykonywane są wewnątrz 32-bitowego systemu operacyjnego.

AMD64 – opracowana przez firmę „AMD”, nazywana też architekturą „x86-64” – jest niejako rozszerzeniem archiektury „x86” o 64-bitowe rozkazy i rejestry, zachowując przy tym 32 oraz 16-bitowe tryby działania procesora. Oznacza to, że 32-bitowy system operacyjny, może funkcjonować na 64-bitowej maszynie bez użycia emulacji.

IA64 – opracowana przez „Intela” we współpracy z „HP” architektura procesorów „Itanium” i „Itanium 2”. 64-bitowy kod jest tutaj wykonywany natywnie, natomiast 32-bitowy („IA32”) emulowany. Wynika z tego, że na maszynie wyposażonej w tego typu procesor, niemożliwe jest zainstalowanie 32-bitowego systemu operacyjnego.

Intel64 – rozszerzenie wczesnej architektury „EM64T” o poleceia architektury „AMD64” i adresowanie więcej niż 4 GB pamięci operacyjnej. Architektura ta pozwala na wykonanie 32-bitowego kodu w trybie natywnym (podobnie jak ma to miejsce w „AMD64”).

x64 – skrót użyty przez Microsoft do opisu architektury procesorów, wykonujacych zarówno 32 jak i 64-bitowy kod natywnie, bez użycia emulacji.

W Windows Installer wsparcie dla poszczególnych platform oznaczane jest poprzez następujące wartości: „Intel”, „Intel64”, „AMD64” oraz „x64″. Począwszy od wersji 2.0 Windows Installer wspiera platformę „IA64”, a od 3.0 również „AMD64„. W wersji 3.1 dodano wparcie dla „x64”.

Szczególną uwagę należy zwrócić na:

– polu „PID_TEMPLATE” można przypisać tylko jedną wartość np. „x64”. Niezalecane jest używanie kilku wartości np: „Intel64, x64”.
– nie jest możliwe oznaczenie pakietu instalacyjnego, tak aby wspierał jednocześnie 32 i 64-bitową platformę. Użycie kombinacji „Intel, Intel64” lub „Intel, x64” jest zabronione.
– na 64-bitowej platformie, możliwe jest zainstalowanie 32 lub 64-bitowego pakietu, tylko wtedy gdy:

  • w skład 32-bitowego pakietu wchodzą wyłącznie 32 -bitowe komponenty
  • w skład 64-bitowego pakietu wchodzą 32 oraz 64-bitowe komponenty
  • 64-bitowy- pakiet zawiera wyłącznie 64-bitowe komponenty

Nazwa katalogu32-bitowy pakiet - platforma x8632-bitowy pakiet - platforma x6464-bitowy pakiet - platforma x64
CommonFilesFolder%ProgramFiles%\Common Files%ProgramFiles(x86)%\Common Files%ProgramFiles(x86)%\Common Files
Common Files64Folder-%ProgramFiles(x86)%\Common Files%ProgramFiles%\Common Files
ProgramFilesFolder%ProgramFiles%%ProgramFiles(x86)%%ProgramFiles(x86)%
ProgramFiles64Folder-%ProgramFiles(x86)%%ProgramFiles%
SystemFolder%WinDir%\System32%WinDir%\SysWOW64%WinDir%\SysWOW64
System64Folder-%WinDir%\SysWOW64%WinDir%\System32

Tabela.1. Oznaczenia architektur w Windows Installer

Budowa systemu plików i rejestru

Różnica w budowie rejestru i strukturze katalogów w systemach 32 i 64-bitowych, ma swoje odzwierciedlenie, również w budowie pakietów. Poniżej zaprezentowano mechanizmy wbudowane w Windows, które mają wpływ na funkcjonalność pakietów.

Podsystem WOW64

Wszystkie 64-bitowe wersje systemu Windows posiadają wbudowany 32-bitowy podsystem „WOW64″ (Windows-on-Windows 64-bit) przy pomocy, którego można instalować i uruchamiać 32-bitowe aplikacje w 64-bitowym środowisku. Zadaniem „WOW64” jest izolacja 32-bitowych plików w postaci binarnej od 64-bitowych, zapobiegając przy tym, ich przypadkowemu nadpisaniu. Ze względu na wsteczną kompatybilność z 32-bitowymi systemami, w 64-bitowej wersji Windows wprowadzono szereg zmian, do których należą m.in. zmiana nazewnictwa katalogów oraz gałęzi rejestru. W przypadku stuktury katalogów, 64-bitowe komponenty zapisywane są pod„%SystemRoot%\System32”, natomiast ich 32-bitowe odpowiedniki pod „%SystemRoot%\SysWOW64”.

Podobnie sytuacja wygląda w przypadku „Assemblies” umieszczonych w „GAC” (Global Assembly Cache). Mamy tu 32 i 64-bitowe oraz neutralne „Assemblies”, które są kompilowane według zawartego w nich opisu (tzw. „MSIL”) – Rys.1.

Przynależność Assemblies do platformy sprzętowej

Rys.1. Przynależność Assemblies do platformy sprzętowej

Również rejestr podzielony jest na 32 i 64-bitowy obszar wyposażony w mechanizmy odpowiedzialne za prawidłowe przydzielanie zasobów. Do mechanizmów tych można zaliczyć m.in.:

„Registry Redirection” (przekierowywanie rejestru) – mechanizm ten polega na automatycznym przekierowywaniu rejestru w zależności od uruchomionego procesu, żądającego dostępu do danej gałęzi rejestru. Przykładowo podczas próby odczytu lub zapisu 32-bitowego procesu do gałęzi „HKLM\SOFTWARE” nastąpi jego automatyczne przekierownie do jej 32-bitowego odpowiednika „HKLM\SOFTWARE\WOW6432Node„.

„Registry Sharing” (współdzielenie rejestru) –  mechanizm ten opiera się na zasadzie współdzielenia wpisów rejestru. Zarówno 32 i 64-bitowe wpisy rejestru, posiadają wspólną przestrzeń, do której mają jednakowy dostęp 32 i 64-bitowe procesy . Do współdzielonych kluczy rejestru należą m.in.:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Driver Signing

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Non-Driver Signing

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Software\Microsoft\Shared Tools\MSInfo

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup

HKEY_LOCAL_MACHINE\SOFTWARE\Policies

„Registry Reflection” (lustrzane odbicie rejestru) – mechanizm ten opiera się na zasadzie duplikowania wpisów pomiędzy 32 i 64-bitowym obszarem rejestru. Wartość zapisywana w 64-bitowej gałęzi rejestru, jest automatycznie duplikowana w jej 32-bitowym odpowiedniku. Do duplikowanych kluczy rejestru należą m.in.:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc

HKEY_USERS\{SID}\Software\Classes

HKEY_USERS\{SID}_Classes

Struktura katalogów

Struktura katalogów w systemach 64-bitowych uległa również znaczącej zmianie. Poniższa tabela zawiera różnice w nazewnictwie katalogów w pakiecie instalacyjnym w odniesieniu do użytej platformy systemowej.

Nazwa katalogu32-bitowy pakiet - platforma x8632-bitowy pakiet - platforma x6464-bitowy pakiet - platforma x64
CommonFilesFolder%ProgramFiles%\Common Files%ProgramFiles(x86)%\Common Files%ProgramFiles(x86)%\Common Files
Common Files64Folder-%ProgramFiles(x86)%\Common Files%ProgramFiles%\Common Files
ProgramFilesFolder%ProgramFiles%%ProgramFiles(x86)%%ProgramFiles(x86)%
ProgramFiles64Folder-%ProgramFiles(x86)%%ProgramFiles%
SystemFolder%WinDir%\System32%WinDir%\SysWOW64%WinDir%\SysWOW64
System64Folder-%WinDir%\SysWOW64%WinDir%\System32

Tabela.2. Nazewnictwo katalogów w pakiecie instalacyjnym w odniesieniu do platformy systemowej

W pakiecie zawierającym komponenty 32 i 64-bitowe rozróżnienie pomiędzy nimi realizowane jest poprzez przypisanie im odpowieniej wartości (flagi) w kolumnie atrybutów w tabeli „Component”.

Komponenty w 64-bitowym pakiecie

Rys.2. Atrybuty komponentów w 64-bitowym pakiecie

Rozróżninie to polega na tym, że wartość atrybutu 64-bitowego komponentu jest zwiększana o „256”, co zaprezentowano na powyższym rysunku (Rys.2). Dodatkowo polu „Condition” przypisywana jest tzw. „kondycja” określająca rodzaj użytej architektury systemu (dla 64-bitowej jest to: „WindowsNT64”). Poniższa tabela zawiera znaczenie poszczególnych flag w tabeli „Component”.

Nazwa flagiFlagaOpis
msidbComponentAttributesLocalOnly0Ustawienie tej flagi powoduje to, że komponent nie jest uruchamiany bezpośrednio ze źródła instalacji lub udziału sieciowego lecz lokalnie.
msidbComponentAttributesSourceOnly1Ustawienie tej flagi powoduje to, że komponent może być uruchamiony tylko ze źródła instalacji.
msidbComponentAttributesOptional2Ustawienie tej flagi powoduje to, że komponent może być uruchamiany lokalnie lub ze źródła instalacji.
msidbComponentAttributesRegistryKeyPath4Ustawienie tej flagi powoduje to, że wpis w kolumnie "KeyPath" tabeli "Component" jest używany, jako klucz do rekordu tabeli "Registry".
msidbComponentAttributesSharedDllRefCount8Ustawienie tej flagi powoduje to, że podczas instalacji komponentu, zwiększany jest licznik referencyjny (Reference Counter) we współdzielonych zasobach DLL (Shared DLLs). Jeżeli flaga ta nie jest ustawiona, licznik referencyjny jest zwiększany tylko wtedy, gdy dany komponent jest już zarejestrowany w systemie.
msidbComponentAttributesPermanent16Ustawienie tej flagi powoduje pozostawienie komponentu w systemie po odinstalowaniu pakietu.
msidbComponentAttributesODBCDataSource32Ustawienie tej flagi powoduje to, że wartość umieszczona w kolumnie "KeyPath" jest traktowana jako wskaźnik do rekordu tabeli "ODBCDataSource".
msidbComponentAttributesTransitive64Ustawienie tej flagi powoduje to, że podczas reinstalacji pakietu analizowana jest ponownie kolumna "Condition" w tabeli "Component". W przypadku gdy, wartość w kolumnie została zmieniona z "False" na "True" następuje ponowna instalacja komponentu. W odwrotnej sytuacji tzn. przy zmianie wartości z "True" na "False" komponent jest odinstalowywany.
msidbComponentAttributesNeverOverwrite128Ustawienie tej flagi powoduje to, że komponent nie jest instalowany i odinstalowywany, jeżeli "Key Path" pliku lub rejestru istnieje w systemie. Niewskazane jest ustawianie tej flagi dla komponentów rejestrowanych przy pomocy tabel: "AppId", Class", "Extension", "ProgId", "MIME" oraz "Verb".
msidbComponentAttributes64bit256Ustwaienie tej flagi wskazuje na 64-bitowy komponent. W przypadku, gdy flaga ta nie jest ustawiona, komponent traktowany jest jako 32-bitowy.
msidbComponentAttributesDisableRegistryReflection
512Ustawienie tej flagi wyłącza mechanizm "Registry Reflection" (lustrzanego odbicia rejestru). Flaga ta jest dostępna w Windows Installer 4.0 i wyższej. W 64-bitowej wersji "Windows XP" oraz "Windows 2000" oraz nowszych systemach 32-bitowych jest pomijana.
msidbComponentAttributesUninstallOnSupersedence
1024Ustawienie tej flagi w pakietach aktualizacyjnych typu "patch" zapobiega pozostawieniu tzw. "osieroconych komponentów" w systemie. Flaga ta jest dostępna w Windows Installer 4.5 i wyższej.
msidbComponentAttributesShared
2048Ustawienie tej flagi powoduje to, że podczas instalacji współdzielonego komponentu (którego wersja jest wyższa od tej dostępnej już w systemie) następuje automatyczne przypisanie go do wszystkich pakietów zainstalowanych w systemie, zawierających ten właśnie komponent. W przypadku deinstalacji pakietu, w systemie pozostawiana jest najwyższa wersja komponentu, nawet wtedy, gdy deinstalowanym pakietem jest ten, który ją zawiera. Flaga ta jest dostępna w Windows Installer 4.5 i wyższej.

Tabela.3. Znaczenie atrybutów tabeli „Component” 

Rozgraniczenie pomiędzy komponentami 32 i 64-bitowymi da się również zaobserwować w logu instalacyjnym. Podczas instalacji 64-bitowego pakietu, parametr „BinaryType” dla 32-bitowych komponentów przyjmuje wartość „0”, natomiast dla 64-bitowych „1”.

MSI (s) (EC:50) [13:48:50:430]: Executing op: ComponentRegister(ComponentId={0159CB71-D830-4135-ACD8-C15B5A188173},KeyPath=c:\Program Files (x86)\FreePDF_XP\freepdf.exe,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)

MSI (s) (EC:50) [13:48:50:446]: Executing op: ComponentRegister(ComponentId={3CEA29DD-1E61-4035-8FD0-4881035DF1D5},KeyPath=c:\Program Files\gs\gs9.04\bin\gsdll64.dll,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=1)

Właściwości (Properties)

Kolejną z możliwości dokładniejszego sprecyzowania platformy docelowej podczas instlacji jest zastosowanie „Właściwości” (Properties) – „WndowsNT” oraz „WindowsNT64”. Właściwość „WindowsNT”, może być stosowana na obu platformach, natomiast „WindowsNT64” ma sens tylko w przypadku platformy 64-bitowej. Na „Rys. 2.” zamieszczonym powyżej zaprezentowana została przynależność komponenu „gsdll64.dll” do 64-bitowej platformy sprzętowej. Zrealizowano to poprzez przypisanie komponentowi „gsdll64.dll”  – „kondycji” o wartości „WindowsNT64”.

Akcje użytkownika (User-CustomAction)

Podczas instalacji „akcje użytkownika” nie są wykonywane w tym samym procesie, lecz w osobnym o nazwie Custom Action-Server”. W 64-bitowym śodowisku istnieje 32 jak i 64-bitowy „Custom Action-Server”. Rozróżnienie pomiędzy „Custom Action-Server”  w wersji 32 i 64-bitowej, nie jest wykonywane z poziomu konfiguracji pakietu, lecz poprzez informacje zawarte w nagłówku („PE-Header”) pliku użytego w „akcji użytkownika”. W przypadku plików nie posiadających nagłówka (np. plik skryptu) zalecane jest manualne przypisanie „akcji użytkownika”  do danego „Custom Action-Servera”. W przypadku 64-bitowego skryptu nie zawierającego nagłówka „PE-Header” odbywa się to, poprzez dodanie liczby 4096″ do wartości kolumny „Type”  w tabeli „CustomAction„.

Przy pomocy „Menadżera zadań” można w łatwy sposób określić, jaki „Custom Action-Server”  jest uruchamiany podczas instalacji pakietu. Jak już wcześniej wspomniano w rozdziale „Proces instalacji – jak to wygląda od środka?” podczas instalacji pakietu uruchamianych jest wiele procesów oznaczonych przez „msiexec.exe”. Procesy zawierające w nazwie sekwencję „-Embedding” są zawsze powiązane z „Custom Action-Server”. W 64-bitowych systemach, 32-bitowe procesy oznaczone są poprzez dodanie do nazwy procesu, sekwencji „*32” (Rys.3).

32-bitowy Custom Action-Server

Rys.3. Oznacznie 32-bitowego „Custom-Action Server” w 64-bitowym systemie

W logu instalacyjny zapisywane są również informacje dotyczące typu Custom Action-Server”, który został uruchomiony podczas instalacji pakietu. Można je rozpoznać po wpisie o treści: „Hello I’m your 32bit (64bit) Impersonated custom action server”.

MSI (s) (2C:88) [15:56:47:394]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIBB51.tmp, Entrypoint: SetProfilesFolder

MSI (s) (2C:6C) [15:56:47:441]: Generating random cookie.

MSI (s) (2C:6C) [15:56:47:441]: Created Custom Action Server with PID 432 (0x1B0).

MSI (s) (2C:38) [15:56:48:597]: Running as a service.

MSI (s) (2C:38) [15:56:48:597]: Hello, I’m your 32bit Impersonated custom action server.

MSI (s) (3A:88) [11:26:40:291]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIAB22.tmp, Entrypoint: SetProfilesFolder

MSI (s) (3A:6C) [11:26:40:332]: Generating random cookie.

MSI (s) (3A:6C) [11:26:40:332]: Created Custom Action Server with PID 225 (0xE2).

MSI (s) (3A:38) [11:26:40:415]: Running as a service.

MSI (s) (3A:38) [11:26:40:418]: Hello, I’m your 64bit Impersonated custom action server.

Błędy

Najczęściej wystepujące błędy, podczas instalacji 64-bitowych pakietów.

1633 „This installation package is not supported on this platform. Contact your application vendor”. Błąd wskazuje na nieodpowiednią platformę sprzętową, na której instalowany jest pakiet. Pojawia się przy próbie instalacji 64-bitowego pakietu w 32-bitowym środowisku lub instalacji 64-bitowego pakietu w niekompatybilnym 64-bitowym środowisku.

2401„64-bit registry operation attempt on 32-bit operating system for key”. Błąd ten jest generowany przy próbie wykonania 64-bitowej operacji na 32-bitowym rejestrze.

2943„This version on Windows does not support deploying 64-bit packages. This script is for a 64-bit package”. Błąd ten jest generowany w przypadku próby wykonania 64-bitowego skryptu w niekompatybilnym systemie (np. 32-bitowym).

Podczas kontroli poprawności budowy 64-bitowego pakietu (tzw. „walidacji”) musimy zwrócić szczególną uwagę na błąd „ICE80”, wskazujący na niepoprawny zapis 64-bitowych komponentów (tabela „Component”) lub „akcji” (tabela „CustomAction”).  Podczas „walidacji” kontrolowane są, również pola „PID_TEMPLATE”, względem poprawności zapisanej w nim wartości („x64” lub „Intel64”) oraz „PID_PAGECOUNT” względem wartości równej lub mniejszej od „200” (wersja 2.0 i wyższa ma wbudowane wspiercie dla 64-bitowych pakietów).

 

Podsumowanie

Różnorodność platform sprzętowych oraz różnice wynikające z budowy 32 i 64-bitowych systemów, nie ułatwiają zadania przy tworzeniu pakietów opartych na Windows Instaler. Jednak przestrzeganie zestawionych poniżej podstawowych reguł, może zaoszczędzić sporo czasu, zainwestowanego w poszukiwanie i korygowanie błędów popełnionych podczas budowania pakietu. Oto one:

– należy pamiętać o określeniu architektury procesora, dla której budowany jest pakiet. Odpowiada za to pole „PID_TEMPLATE” w „Summary Information Stream”. W zależności od użytej architektury sprzętowej przyjmuje ono następujące wartości: platforma „IA64” – wartość „Intel64”, platforma „EM64T i AMD64” – wartość „x64”.

– zabronione jest używanie w pakiecie zapisu odnoszącego się do wielu platform sprzętowych np. „Intel,x64”.

– należy zawsze używać schematu bazy danych Windows Installera, równego lub większego od „200”. Wartość ta jest zapisywana w polu „PID_PAGECOUNT” „Summary Information Stream”. Liczbą „200” oznaczona jest wersja Windows Installera o numerze 2.0 zawierająca wsparcie dla pakietów 64-bitowych.

– w przypadku 64-bitowych komponentów, należy ustawić odpowiednią flagę w kolumnie „Attributes”  tabeli „Component”.

– przy sprawdzaniu architektury systemu, należy korzystać z właściwości „VersionNT64”. W systemach 32-bitowych właściwość ta jest pomijana.

– kiedy zachodzi potrzeba sprawdzenia, czy w systemie znajdują się 64-bitowe pliki lub wpisy rejestru, należy skorzystać z tabel „AppSearch” oraz „RegLocator”, pamiętając o ustawieniu odpowiedniej flagi (64-bitowej) w kolumnie „Type”  tabeli „RegLocator„.

– w przypadku komponentów zawierających te same zasoby, ale w wersjach przewidzianych na różne platformy sprzętowe, należy użyć różnych IDs.

– należy pamiętać o użyciu poprawnego nazewnictwa przy określaniu katalogu, do jakiego instalowane są pliki. Dla systemów 64-bitowych są to: „ProgramFiles64Folder, System64Folder, CommonFiles64Folder” oraz ich 32-bitowe odpowiedniki: „ProgramFilesFolder, SystemFolder, CommonFilesFolder”.

– w przypadku istnienia dwóch identycznych plików „INI” różniących się tylko platformą sprzętową, należy pamiętać o ich poprawnym przyporządkowaniu względem komponentu (rozróżnienie pomędzy 32 i 64-bitami)

– 32-bitowe patche mogą aktualizować tylko 32-bitowe pliki, natomiast 64-bitowe ich 64-bitowe odpowiedniki.

– 32-bitowe aplikacje uruchomiane w 64-bitowym środowisku wykorzystują mechanizm „odbicia lustrzanego rejestru” (Regisrty Reflection), gdzie 32 i 64 -bitowe wpisy, są ze sobą synchronizowane, tak aby zachować spójność zapisu w obu gałęziach rejestru. Istnieje możliwość wyłączenia tego mechanizmu w pakiecie, poprzez ustawienie odpowiedniej flagi (o wartości 512) w kolumie „Attributes”  tabeli „Component”. Flaga ta ma jedynie sens, dla pakietów instalowanych w 64-bitowych systemach, w których wersja Windows Installera jest równa lub większa od 4.0. W 32-bitowych systemach flaga ta jest ignorowana.

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