La începutul anilor 1980 arhitectura programelor era …stst.elia.pub.ro/PS/2010/Optimizare a...

Optimizare a instalarii aplicaţiilor in reţele de calculatoarefolosind utilitarul WPKG

Capitolul 1. Analiza instalării de aplicaţii în sisteme de operare Windows

1.1 Programe monolitice

La începutul anilor 1980 arhitectura programelor era mult mai simplă decât

cea actuală. Se folosea structura monolitică, executabilul nu utiliza resurse externe şi

nu se ţinea cont de aplicaţiile existente pe maşină in momentul instalării.

Calculatoarele au fost integrate într-un spectru din ce in ce mai larg de domenii,

uşurinţa utilizării programelor reprezentând un atu al adoptării noii tehnologii.

Folosirea intuitivă a programelor a devenit realizabilă o dată cu apariţia sistemului de

operare Windows 3.1x. Noutatea introdusă la acea dată era Interfaţa Grafică cu

Utilizatorul (Graphic User Interface), aceasta permitea accesul facil al persoanelor ce

nu erau familiare cu mediul Dos la capabilităţile calculatorului prin câteva

caracteristici noi printre care se numără: folosirea mouse-ului, a opţiunii “Drag and

drop”, asocierea extensiilor de fişiere cu anumite aplicaţii, astfel la dublul click pe un

fişier este deschisă aplicaţia corespunzătoare.

Răspândirea programelor ridică, bineînţeles, atât probleme legate de

instalarea, buna funcţionare şi dezinstalarea acestora, cât şi probleme legate de

stabilitatea sistemului de operare.

1.2 Programe multi-componente

Comparativ cu aplicaţiile de tip monolitic, o varianta mai avansata este aceea a

programelor formate din mai multe componente. Aceste componente pot fi create de

acelaşi producător, sau de producători diferiţi. Pentru un randament ridicat al

dezvoltării programelor se preferă folosirea modulelor deja existente in locul creării

acestora de la zero, astfel că se poate spune că eforturile programatorilor se îndreaptă

mai mult spre adaptarea unor module deja scrise decât spre crearea altora noi.

Un exemplu foarte bun în acest sens este sistemul de operare Windows.

Acesta include seturi API (Interfete de programare pentru aplicaţii) ce permit unui

program să folosească facilităţi furnizate de alte aplicaţii. Funcţionalitatea acestor API

se bazează pe nucleul de fişiere DLL ce aparţin Windows-ului. Rolul acestor DLL-uri

este acela de a realiza funcţiile centrale ale sistemului de operare cum ar fi :

deschiderea, dimensionarea, mutarea şi închiderea ferestrelor. Practic, orice

operatiune realizată in Windows trece prin acest nucleu de DLL-uri.

Pe lista programelor folosite de aplicaţii terţe, pe lângă aceste API-uri, se

numără multe alte software-uri furnizate atât de Microsoft, cât şi de alte firme de

software. Dintre acestea enumerez: Microsoft Data Access Components (MDAC),

Visual Basic Runtime, Microsoft Common Controls, Java Runtime, Adobe Acrobat şi

Macromedia Flash.

1.2.1 Conexiuni între programele multi-componente

Pentru corecta incărcare a biblotecilor este necesar ca dependinţele aplicaţiilor

să fie instalate pe sistem. În cazul în care acestea lipsesc sau sunt instalate versiuni

mai vechi decât cele cerute, aplicaţia curentă va genera erori în timpul rulării. Figura

următoare descrie legătura dintre aplicaţiile ce trebuie instalate şi dependinţele

acestora.

Pe lângă aceste componente redistribuite există şi update-urile sistemului de

operare, service-pack-uri, hotfix-uri ce updateaza fişierele DLL din nucleul Windows-

ului. Este foarte important ca versiunea acestor fişiere să fie cea corectă, deoarece in

momentul update-ului trebuie rescrise doar fişierele cu versiunea mai mica decât

noua versiune.

1.2.2 Tipuri de legături între componente

Instalarea programelor multi-componente nu ridică niciun fel de probleme cât

timp librăriile necesare pot fi folosite de aplicaţie, dar, în majoritatea cazurilor,

această condiţie nu este respectată – modulele necesare nu se află pe maşină sau, dacă

se află, versiunea acestora diferă de versiunea cerută.

Aflarea componentelor dependinţă este o sarcină dificilă, deoarece

executabilul poate apela o funcţie furnizată de unul dintre dll-uri fie folosind o

legătură statică, fie o legătură dinamică.

Legătura statică (Static Linking) este folosită atunci când se doreşte ca

aplicaţia să nu aibă dependinţe. Compilatorul integrează în executabil codurile tuturor

funcţiilor care vor fi folosite, executabilul rezultat înglobând toate resursele de care

are nevoie pentru a rula. Dezavantajele acestui tip de legătură sunt spaţiul mare de pe

hard-disk ocupat de mai multe executabile care folosesc un set comun de funcţii şi

upgrade-ul greoi al aplicaţiilor, fiind necesară rescrierea codurilor sursă.

Legătura dinamică (Dynamic Linking) implică realizarea conexiunilor cu

bibliotecile necesare în momentul rulării sau încărcării, nu în timpul compilării ca în

cazul legăturii statice. Executabilul conţine doar minimul de informaţii legate de

biblotecile necesare. Acesta include o tabelă cu adrese de import (Import Address

Table- IAT) în care fiecare apel către o funcţie dintr-un fişier dll este referenţiată.

Dacă două sau mai multe programe folosesc acelaşi dll, acesta va fi copiat o singură

dată în memoria RAM şi apoi adresa din memoria fizică va fi mapată către adresele

din memoria virtuală ale fiecărui proces. In acest mod se foloseşte mai eficent

memoria, update-urile se realizeaza mult mai uşor, fiind nevoie doar de înlocuirea

unui fişier pentru toate aplicaţiile care folosesc respectivul fişier dll.

1.3 Prezentare a modului obiect – COM

Component Object Model (COM) este o interfaţă binară standard pentru

componentele software. Este folosit pentru a permite comunicarea şi crearea dinamică

a obiectelor intr-o gama larga de limbaje de programare. Termenul COM este adesea

utilizat ca un termen generic care cuprinde OLE, OLE Automation, ActiveX, COM+

şi tehnologia DCOM.

Prin tehnologia COM se implementează obiecte care pot fi folosite în diferite

sisteme independente de limbajul în care au fost create. Esenţa COM este folosirea

unui limbaj neutru.

Programatorii COM îşi construiesc programele folosind componente COM.

Diferitele tipuri de componete sunt identificabile prin class ID (CLSID).

Funcţionalitatea fiecarei componeta COM se realizează prin implentarea uneia sau

mai multor interfeţe.Diferitele interfeţe suportate de catre o componentă se disting

între ele prin identificatorul interface ID (IID).

Toate componentele COM trebuie să implementeze interfaţa standard

IUnknown, astfel toate interfeţele sunt derivate din interfaţa IUnknown. Acestă

interfaţă este alactută din 3 metode: AddRef (),Release () şi QueryInterface () care

impleneteza numărul de referinţă, controlul de viaţă al interfeţei şi metoda prin care se

transmite IID prin care se obţine referinţe catre diferite interfeţe pe care componenta

le implenetează.

O clasă este un grup de obiecte asemanatoare sau este o reprezentare a unui tip

de obiect. In Windows clasele COM, interfeţele si tipurile de biblioteci sunt listate sub

un indentificator unic (GUID) în registrii sub cheile HKEY_CLASSES_ROOT\

CLSID pentru clase şi HKEY_CLASSES_ROOT\ Interface pentru interfete.

Bibilotecile COM folosesc registrii pentru a localiza corect bibloteca locala pentru

fiecare obiect COM sau locatia din retea pentru un servicu la distanţă.

1.4 Folosirea resurselor comune de către mai multe aplicaţii

Nucleul de biblioteci se află în directorul Windows\System32, intenţionând să

stocheze aici mare parte a fişierelor sistemului de operare. Pe de altă parte, aplicaţiile

îşi instalează fişierele share-uite tot în acest director pentru că sistemul de operare le

caută în Windows şi în System32.

Ordinea de căutare este:

1. Directorul de unde se încarcă aplicaţia.

2. Directorul Windows\System32.

3. Directorul Windows\System.

4. Directorul Windows.

5. Directorul curent.

6. Directoarele listate în variabila de sistem „PATH”.

1.4.1 Probleme care apar la instalarea aplicaţiilor

Problema care apare, legată de fişierele share-uite, este că diferite aplicaţii pot

instala versiuni diferite ale aceluiaşi fişier. De exemplu dacă un program necesită

fişierul „Comcat.dll” (modul redistribuit produs de Microsoft ce este necesar pentru

folosirea controalelor ActiveX) sistemul de operare îl va găsi în directorul Windows\

System32 şi aplicaţia va rula corect. Însă acesta este cazul cel mai favorabil; mai

există două variante cu probabilităţi foarte mari de realizare. Prima este aceea ca

fişierul să nu existe în niciun director în care este căutat de către sistemul de operare –

va fi generat un mesaj de eroare şi aplicaţia se va închide. A doua variantă este aceea

în care sistemul de operare găseşte fişierul „Comcat.dll” dar cu altă versiune decât

cea cerută de program. Aplicaţia poate funcţiona corect dacă funcţiile necesare sunt

conţinute în fişierul respectiv, iar în caz contrar pot fi generate o serie de mesaje de

eroare ce depind de conţinutul dll-ului şi de funcţionalităţile programului. Cum se

poate întâmpla ca pe maşină să fie prezente versiuni incompatibile ale fişierului

necesar aplicaţiei, cu toate că în momentul instalării versiunea corectă era prezentă ?

Răspunsul este: alt program a fost instalat între timp şi a suprascris fişierul existent,

versiunea nouă nefiind compatibilă cu cerinţele executabilui primei aplicaţii instalate.

Instalarea unei versiuni mai vechi sau mai noi a unuia dintre aceste fişierele

comune poate duce la nefuncţionarea tuturor programelor ce folosesc o anumită

versiune a fişierului respectiv.

1.4.2 Mecanisme pentru protecţia programelor in folosirea

resurselor comune de sistem la procesele de instalare-dezinstalare

Odată cu Windows Millenium, Microsoft lansează două sisteme care au rolul

de a ajuta la stabilizarea sistemului: Windows File Protection şi Side-by-Side

Component Sharing.

Windows File Protection (WFP) previne modificarea, înlocuirea sau ştergerea

fişierelor critice ale Windows-ului. Toate fişierele cu extensiile: sys, dll, exe, ocx,

precum şi câteva fonturi: micross.ttf, tahoma.ttf, şi tahomabd.ttf, ce sunt conţinute de

cd-ul de instalare sunt verificate periodic. Dacă acestea nu corespund cu cele instalate

odată cu sistemul de operare, sunt înlocuite cu fişierele originale copiate în directorul

Dllcache. Astfel se asigură back-up-ul fişierelor sistemului şi se evită rescrierea

acestora de către alte aplicaţii.

Acest mecanism nu împiedică realizarea update-urilor sistemului de operare.

Fişierele vechi sunt înlocuite cu cele noi, atât în directoarele cărora aparţin, cât şi în

directorul Dllcache. Update-urile sunt efectuate prin intermediul uneia dintre

metodele urmatoare:

Instalarea unui Service Pack

Instalarea unui Hotfix

Instalarea unui upgrade al sistemului de operare

Side-by-Side Component Sharing constă în izolarea fişierelor dll comune

necesare executabilului pentru a rula corect. Copii ale fişierelor izolate vor fi instalate

în directorul programului împreună cu un fişier ce va fi denumit „NumeEXE.local”,

unde „NumeEXE” este numele executabilului ce foloseşte fişierele dll comune.

Fişierul „NumeEXE.local” va îndruma sistemul de operare la lansarea programului să

căute bibliotecile necesare executabilului în directorul aplicaţiei.

1.5 Regiştrii

1.5.1 Definiţie. Rol

Regiştrii sunt o bază de date ierarhizată pe care sistemul de operare Windows

o foloseşte pentu setarea configurărilor. Aceleaşi informaţii care acum sunt stocate în

regiştrii, era conţinută de sistemele de operare Windows pe 16 biţi în fişiere text.

Organizarea acestora îngreuna accesul la informaţie, în contextul în care viteza de

lucru crescuse foarte mult. Aceste fişiere-„win.ini” şi „system.ini”- reprezintă baza

regiştrilor de astăzi.

Regiştrii sunt foarte importanţi deoarece datele pe care le conţin sunt folosite

continuu atât de sistemul de operare, cât şi de aplicaţii. Un set de funcţii API permite

programelor să acceseze rapid şi eficient aceste resurse.

1.5.2 Organizarea regiştrilor

Regiştrii sunt organizaţi în cinci secţiuni. Aceste secţiuni, numite „hives”

(„stupi”), sunt asemănătoare cu directoarele rădăcină de pe hard-disk. Fiecare secţiune

are propriul loc de stocare şi fişier log. Se poate realiza backup-ul unei hive, fără să

fie afectate si celelalte secţiuni.

Spuneam că regiştrii sunt o bază de date ierarhizată, aceasta decurgând din

structura acestora. Fiecare secţiune conţine chei, subchei şi valori. Valorile reprezintă

informaţiile, datele ce corespund unei chei. Acest lucru este asemănător cu fişierele ce

conţin date, informaţii.

O cheie sau o subcheie poate avea una sau mai multe valori, o valoare

presetată şi oricât de multe subchei. Fiecărei valori îi corespund un nume şi un tip de

dată. Numele este stocat ca şir de caractere Unicod, în timp ce tipul poate fi:

• REG_BINARY – reprezintă valori binare care pot fi editate sau

introduse în format hexazecimal sau binar.

• REG_DWORD – reprezintă o valoare numerică pe 32 de biţi introdusă

în format decimal sau hexazecimal.

• REG_EXPAND_SZ – folosit atunci cand cheia este o varaibilă de

sistem care trebuie sa ia valoarea ei extinsă înainte de a fi folosită.

• REG_FULL_RESOURCE_DESCRIPTOR – conţine o listă cu toate

resursele hardware pe care un dispozitiv le utilizează.

• REG_LINK – folosit pentru o legatură între o valoare a registrului şi o

data aparţind unei aplicaţii.

• REG_MULTI_SZ – folosită pentru a reţine mai multe şiruri de caracatere

intr-o singura cheie de registru.

• REG_NONE – folosit atunci cand nici o dată nu este reţinuta în cheia

de registru.

• REG_QWORD – folosit pentru reprezentarea valorilor numerice pe 64

de biţi.

• REG_RESOURCE_LIST – conţine valori folosite de catre dispozitivele

hardware.

• REG_RESOURCE_REQUIREMENTS_LIST – conţine o listă cu

resursele necesare unui driver.

• REG_SZ – folosit pentru valori care conţin şiruri de caractere.

• REG_UNKNOWN – folosit atunci cand nu se cunoaşte tipul de dată al

cheii.

Aplicaţiile pot accesa fiecare dintre aceste tipuri, pot stoca date de aceste tipuri

şi, în plus, pot realiza intrări de date în format propriu.

Cele cinci secţiuni sunt:

• HKEY_CLASSES_ROOT - HKCR

• HKEY_CURRENT_USER - HKCU

• HKEY_LOCAL_MACHINE - HKLM

• HKEY_USERS - HKU

• HKEY_CURRENT_CONFIG – HKCC

HKEY_CLASSES_ROOT reprezinta de fapt un alias catre

HKEY_CURRENT_USERS\Software\Classes si HKEY_LOCAL_MACHNE \

Software\Classes.Registrii din HKEY_CLASSES_ROOT au legatura cu asocieriile

de fisiere.Aceasta zona este predispusa la conflicte in registry care se pot produce

foarte usor.

HKEY_CURRENT_USER - Acesta hive contine setarile user-ului curent.

Cheile principale din HKCU sunt prezentate in tableul de mai jos:

HKEY_CURRENT_USER\AppEvents Aceasta cheie contine informatii despre

sunetele asociate evenimentelor(erori,

warrning-uri...etc)

HKEY_CURRENT_USER\Console Aceasta cheie face referire la command

line.

HKEY_CURRENT_USER\SessionInformation\

ProgramCount

Aceasta cheie enumereaza aplicatiile care

sunt deschise

HKEY_CURRENT_USER\Software\Microsoft\

Windows\Current Version\Applets

Cheia contine informatii despre instalarea

curenta si toate subcheile trebuie sterse .


Windows\Current Version\SessionInfo

Trebuie exclusa intrucat contine

informatii despre sistemul de operare.


Windows\Current Version\StreamMRU

Aceasta cheie se leaga de starea curenta a

sitemului pe care reimpachetezi.


Windows\Current Version\MountPoints\

Aceasta subcheie face referire la drive

mapping-ul masinii curente


Windows\Current Version\StartPage\

Aceasta subcheie afiseaza prima pagina

cand un utilizator deschide INTERNET

EXPLORER


Windows\Current Version\Prefetcher\

Se poate sterge pentru ca este legata de

sistemul de operare si nu de applicatie.


Windows\Current Version\Shell\BagMRU

Aplicabila numai pe Windows XP,

aceasta cheie contine cele mai recente

setari folosite ale utilizatorului.

HKEY_CURRENT_USER\Control Panel\

Keyboard\InitialKeyboardIndicators

Aceasta subcheie cotroleaza tasta

NumLock.Daca folosim aceasta cheie,

schimba setarile utilizatorului pe

computerul destinatie.


Internet Explorer\Toolbar\Shellbrowser

Aceasta subcheie controleaza tool bar-ul

din Internet Explorer.


Windows\Current Version\Explorer\RunMRU

Aceasta subcheie reprezinta ce mai

recenta lista pentru comanda RUN.


Internet Explorer\Toolbar\Explorer

Aceasta subcheie controleaza

configurarea tool bar-ului din Internet

Explorer.


Windows\Currrent Version\Explorer

Exista cateva subchei atasate acestei chei,

pe care le folosim pentru configurarea

Windows Explorer.


Windows\Current Version\Run

Daca aceasta cheie este populata, aplicatia

porneste dupa fiecare reboot.


Windows\Current Version\\RunOnce

Daca aceasta cheie este populata, aplicatia

porneste doar dupa primul reboot.

Aceste ramuri ale regiştrilor conţin informaţii duplicate. De exemplu, tot ce

este conţinut în „HKEY_CURRENT_USER” se găseşte şi în „HKEY_USERS”, dar

aceeaşi informaţie nu se află în ambele secţiuni, ci sunt două nume pentru aceleaşi

date. Microsoft a avut nevoie să facă astfel încât o parte a regiştrilor să pară că se află

în două locuri diferite. Nu au copiat informaţia în ambele ramuri, pentru că aceasta ar

fi pus probleme de corelare a datelor. Soluţia este folosirea de aliasuri pentru unele

componente ale regiştrilor, astfel aliasul desemnează informaţia din componenta

originală. Aceste nume, denumiri duble nu pot fi create de utilizatori, ci numai de

sistemul de operare.

Secţiunea „HKEY_CURRENT_USER” este un alias fie pentru utilizatorul

„.DEFAULT”, fie pentru utilizatorul curent din „HKEY_USERS”. Această ramură

conţine în afară de „.DEFAULT”, chei ale căror nume sunt şiruri lungi de caractere ce

poartă numele de „Identificatori de securitate” (SID - „security identifiers”), folosiţi

de Windows pentru identificarea utilizatorilor. Cheia corespunzătoare utilizatorului

curent este urmată de „_Classes”.

HKEY_LOCAL_MACHINE contine mai multe chei principale, care sunt

listate in tabelul urmator.Cheile din acest hive conţin informaţii pentru setariile

specifice facute pe masina curenta.

Registry Key Descriere

HKEY_LOCAL_MACHINE\Hardware Include aceasta cheie doar cand

reimpachetezi aplicatii care contin

hardware, cum ar fi soft-ul de inmprimanta

sau de scanner.Inainte de a se incepe

proiectul de reimpachetat se verifica daca

exista componente hardware in aplicatie.

HKEY_LOCAL_MACHINE\SAM Cheia SAM (security accounts manager)

contine informatie care se ocupa cu end

user si cu group accounts si aduce

autentificarea utulizatorului catre LSA(local

security authority)

HKEY_LOCAL_MACHINE\Security Aceasta cheie contine informatii ale

utilizatorului si ale grupului pentru

domeniu, cum ar fi drepturi si parole.Daca

nu exista un domeniu, aceasta cheie

stocheaza informatia de end user intr-un

workgroup.

HKEY_LOCAL_MACHINE\Software\Microsoft\

Windows\CurrentVersion\Run

Daca sub aceasta cheie se afla ceva, atunci

aplicatia porneste dupa fiecare restart.


Windows\CurrentVersion\RunOnce

Daca sub aceasta cheie se afla ceva,

aplicatia porneste doar dupa primul restart.

HKEY_LOCAL_MACHINE\Software Contine setari ale aplicatiei, care sunt

fisiere primare pentru instalatie.Vanzatorii

de aplicatii populeaza aceasta cheie pentru a

include controlul asupra versiunii aplicatiei,

informatii despre setari si informatii despre

calea catre fisiere.

Urmatoarele subchei verifica daca

informatia din chei ar trebui populata si in

restul instalarii.

HKEY_LOCAL_MACHINE\Software\Windows\ Acest fisier contine locatia programului

CurrentVersion\AppPath pentru software-ul pe 32 de biti.


Cryptography.

Aduce informatii despre semnatura digitala

de pe masina destinatie.


Event System

Contine informatii despre event-uri ale

Windows NT


SMS

Informatii despre SMS si despre masina

destinatie.

HKEY_LOCAL_MACHINE\System\

CurrentControlSet\SessionManager\Environment\

Aceasta cheie contine toate variabilele de

mediu de pe masina despre masina

destinatie


CurrentControlSet\Control\SessionManager\

KnownDLLs

Intotdeauna aceste chei se iau din calea

inregistrata in cazul in care nu sunt izolate


CurrentControlSet001\

Acest fisier contine un backup al fisierului

CurrentControlSet.


CurrentControlSet002\

Acest fisier contine un backup al fisierului

CurrentControlSet.


Windows\CurrentVersion\Syncmgr

Acest fisier detine informatii despre

configuratia fisierelor offline.

HKEY_LOCAL_MAHCINE\Software\Microsoft\

WBEM\

Acest fisier detine date pentru Web-based


Windows\CurrentVersion\GroupPolicy\

Acest fisier detine informatii despre

configuratia politicilor de grup


Rpc\UuidSequenceNumber

Acest fisier se refera la setarile de retea

Regiştrii sunt o resursă share-uită între sistemul de operare şi aplicaţii. Aşadar

este foarte important ca instalarea programelor să nu distrugă funcţionarea altor

aplicaţii prin modificarea intrărilor folosite de acestea. De aceea este necesară o

instalare efectuată de un program care să aducă pe maşină, sau să modifice numai

regiştrii ce ţin de aplicaţia curentă. De asemenea, la dezinstalare, aplicaţia trebuie să

şteargă intrările introduse şi să lase sistemul de operare în starea întâlnită la instalare.

1.6 API - Interfete de programare pentru aplicaţii

O interfaţă de programare a aplicatiilor (API) este o interfaţă implementata de

către un program software care îi permite să interacţioneze cu alte aplicaţii software.

Aceasta facilitează interacţiunea dintre diferite programe software similar cu modul în

care interfaţa cu utilizatorul facilitează interacţiunea între oameni şi computere. Un

API este implementat de catre aplicaţii, biblioteci, precum şi sistemul de operare

pentru a stabili modul de comunicare si conventiile necesare. Acesta poate include

specificaţii pentru rutine, structuri de date, clase obiect, şi protocoalele utilizate pentru

a comunica între consumator şi implementator de API.

Un API este o notiune abstracta care descrie o interfaţă pentru interacţiunea cu

un set de funcţii utilizate de componente ale unui sistem software.

Un API pot fi:

In mod general – un set complet de interfete de program pentru

aplicatii care este incorporat in biblioteciile unui limbaj de programare

(Java API)

In mod specific – API-urile sunt menite sa abordeze o problema

specifica , exemplu API pentru Google Maps

Dependente de un limbaj de programare – sunt disponibile numai

pentru utilizarea cu sintaxa si elemetele specifice limbajului respective

de programare

Independente de limbajul folosit – API-urile sunt scrise in asa fel incat

pot fi apelate de catre mai multe limbaje de programare diferite.

Aceasta este o caracteristică de dorit pentru un API orientat catre

servicu care nu este legat la un proces specific sau de sistem şi poate fi

prevăzut ca apeluri de proceduri la distanţă sau de servicii web.

1.7 Probleme care apar la dezinstalarea programelor

Până acum câţiva ani programele nu erau proiectate să se ocupe de

dezinstalare. Acest lucru se realiza de către utilizatori şi depindea de priceperea

acestora dacă erau înlăturate toate componentele instalate de aplicaţie şi dacă sistemul

de operare împreună cu celelalte aplicaţii continuau să funcţioneze după ştergerea

programului respectiv.

În continuare prezint procedura pe care trebuia să o urmeze un utilizator

pentru a dezinstala o aplicaţie care nu beneficiază de un program de dezinstalare, nu

este listată în „Control Panel\Add Or Remove Programs” sau, dacă este, nu

functionează dezinstalarea. Procedura constă în:

• Realizarea unui backup a directorului în care a fost

instalată aplicaţia urmată de ştergerea acestuia

• Realizarea unui backup a registrilor ce ţin de aplicaţie în

„HKEY_LOCAL_MACHINE\Software” şi

„HKEY_CURRENT_USER\Software”, apoi ştergerea acestor chei

• Ştergerea din „Start Menu” a programelor ce nu mai există

• Dacă aplicaţia apare în „Control Panel\Add Or Remove Programs”,

dar nu se dezinstalează, se şterg cheile programului din

„HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\

CurrentVersion\Uninstall”

• Dacă aplicaţia instalează servicii, trebuie şterse intrările din

„HKEY_LOCAL_MACHINE\System\CurrentControlSet\

Services”

Această metodă poate da de multe ori greş, pentru că se pot şterge componente

ale aplicaţiei ce erau dependinţe pentru alte programe cauzând nefuncţionarea

acestora. O altă greşeală care se poate face uşor este aceea de a înlătura o resursă

folosită de sistemul de operare împiedicând astfel rularea acestuia. Este de asemenea

nevoie ca la dezinstalarea aplicaţiilor să fie înlăturate toate resursele acestora. Pe

lângă aceste probleme, mai există un aspect al dezinstalării programelor foarte

important: o aplicaţie trebuie să lase maşina în starea de funcţionare de dinaintea

instalării programului. Aceasta semnifică faptul că, dacă aplicaţia a modificat resurse

existente pe sistem la momentul instalării, la dezinstalare acestea trebuie să se afle în

starea iniţială. Aceste lucruri sunt foarte greu de realizat fără un program care să se

ocupe de dezinstalare.

Pentru problemele enumerate până acum: fişierele share-uite, manipularea

regiştrilor, probleme ce apar la instalarea şi dezinstalarea programelor, Microsoft a

lansat technologia Windows Installer ce aduce, pe lângă soluţiile cerute de aceste

probleme, multe alte caracteristici noi în manipularea instalărilor aplicaţiilor.

Capitolul 2. Prezentare a tehnologiei Windows Installer

2.1 Definiţie

Windows Installer este un serviciu de instalat şi configurat aplicaţii. Acesta

administrează instalarea şi dezinstalarea programelor prin aplicarea unor reguli

predefinite în timpul procesului de instalare şi dezinstalare. Pe lângă aceste reguli ce

definesc instalarea şi configurarea software-ului, Windows Installer conţine

capabilităţi de a modifica, repara, ştergea unor componentele ale aplicaţiei,

monitorizarea conflictelor între fişiere şi în cazul unor instalări anulate din cauza unor

erori, revenirea sistemului în starea în care se afla înainte de începerea instalării.

2.2. Facilităţile folosirii Windows Installer-ului

Introducerea unui format standard

de pachet

Noul pachet cu extensia „.msi” reprezintă

standardul acceptat de tehnologia

Windows Installer.

Operaţiunile tranzitorii şi rollback-

up

Operaţiunile de instalare sunt tranzitorii,

ceea ce semnifică capacitatea Windows

Installer-ului de a restitui starea sistemului

de operare anterioară fiecărei operaţiuni.

Dacă în timpul instalării intervine o eroare

care impiedică realizarea restului

procesului, tehnologia Windows Installer

anulează schimbările realizate până în

momentul respectiv, restituind astfel

starea iniţială a sistemului de operare.

Auto-repararea („self-healing”,

„self-repair”)

La rularea aplicaţiei este realizată de către

Windows Installer o verificare a

componentelor. Dacă una dintre cheile

acestora este coruptă sau ştearsă, se va

relua procesul de instalare pentru

corectarea acestor erori. Acest subiect va

fi detaliat în continuarea lucrării.

Instalare la cerere Aplicaţiile împachetate folosind

tehnologia Windows Installer pot fi

folosite oricând. Instalarea acestora poate

avea loc imediat, sau atunci când

utilizatorul are nevoie de ele. De exemplu

corectarea gramaticală din „Microsoft

Office Word” poate să nu fie instalată

odată cu restul pachetului, ci numai când

utilizatorul doreşte să folosească această

funcţionalitate.

Instalări JIT (Just in Time) Programul poate fi pus la dispoziţia

utilizatorilor chiar nefiind instalat. Aceştia

sunt înştiinţaţi de disponibilitatea

aplicaţiei prin apariţia shortcut-ului

corespunzător. Programul se va instala la

rularea shortcut-ului. Această opţiune

diferă de „Instalarea la cerere” prin faptul

că până în momentul declanşării

procesului de instalare, pe maşină nu se

află instalată nicio componentă a

aplicaţiei.

Pachetele pot folosi fişiere de tip

„Transform”

O aplicaţie poate fi customizată facil prin

folosirea fişierelor „Transform” ce se

aplică peste pachetul iniţial în momentul

instalării.

Folosirea fişierelor de tipul

„Patch”

Odată ce programul este instalat se pot

aplica update-uri sau se pot corecta erori

prin aceste fişiere „Patch”. Utilizarea

acestor două tipuri de fişiere „Transform”

şi „Patch” va fi tratată într-unul din sub

capitolele următoare.

Drepturile de „Administrator” nu

mai sunt necesare pentru instalarea

programelor

Windows Installer permite utilizatorilor ce

nu au permisiunile corespunzătoare

grupului „Administrator” să instaleze

aplicaţii.

Uşurinţa manipulării pachetelor cu

ajutorul liniei de comandă

Comanda „msiexec” permite efectuarea

unui set de operaţii cu ajutorul

parametrilor folosiţi în linia de comandă.

Se poate realiza astfel instalarea,

dezinstalarea, repararea pachetelor sau

modificarea unei variabile folosite de

aplicaţie.

Dezinstalarea eficientă a

aplicaţiilor

Windows Installer asigură ştergerea

tuturor resurselor instalate fără

compromiterea altor programe.

Anularea restartului sistemului de

operare

Unele aplicaţii necesită după instalare ca

sistemul de operare să fie restartat pentru

a-şi definitiva configurările. Windows

Installer suprimă acest restart şi setează

corespunzător programele încă din timpul

instalării.

2.3 Tipuri de fişiere cu care lucrează Windows Installer

Tehnologia „Windows Installer” foloseşte următoarele tipuri de fişiere:

• MSI (Microsoft Installer)- fişier care contine toate

informatiile necesare sistemului Windows Installer pentru a instala sau dezinstala o

aplicatie, precum si pentru a rula interfata utilizator a unui pachet.

Fisierul MSI reprezinta o baza de date relationala, continand mai multe tabele

inter-corelate legate prin datele din cheile primare sau externe ale tabelelor. Aceasta

reprezinta o modalitate eficienta de constructie a procesului de instalare si reflecta

cadrul general al aplicatiilor instalate (module disponibile, componente, configurari

necesare ale registrilor, interfata-utilizator a aplicatiei).

Structura fisierelor msi:

1. Tabelele nucleu - Aceste tabele descriu modulele si componentele

fundamentale ale aplicatiei.

Un modul (feature) reprezinta o parte a functionalitatii complete a aplicatiei,

pe care utilizatorul o recunoaste si poate alege sa o instaleze in mod independent,

modulele care alcatuiesc un pachet avand o structura ierarhica arborescenta.

O componenta este o parte a produsului de instalat. Componentele pot include

fisiere, grupuri de fisiere relationate intre ele, obiecte COM, chei de registri, shortcut-

uri, resurse sau bibloteci ale aplicatiei. In general, componentele se consistuie in

entitati invizibile din punctul de vedere al utilizatorului.

Serviciul Windows Installer instaleaza sau dezinstaleaza o componenta ca o

singura entitate. Fiecare dintre acestea este marcata printr-un ID (GUID) care permite

intotdeauna o singura instanta a unei componente sa fie instalata la un moment dat.

Din cauza faptului ca continutul componentele de multe ori este share-uit intre

aplicatii, se cere respectarea unor reguli stricte. Printre acestea se poate mentiona

faptul ca o componenta se instaleaza intr-un singur dosar (folder) sau aceea ca orice

fisier, cheie de registru, shortcut sau alta resursa trebuie livrata ca apartinand de o

singura componenta.

Tabelele “Feature” si “Component” descriu modulele si respectiv

componentele care alcatuiesc aplicaţia care se va instalal. Intrucat relatiile intre aceste

2 tabele sunt unele de tip “n – la – n” mai este nevoie de tabela suplimentara

“FeatureComponents”.

Tabela “Directory” listeaza directoarele care sunt necesare pe parcursul

instalarii. Una dintre cele mai importante tabele constituente este “Property” care

seteaza valori globale ale intregii aplicatii. Mai putem aminti tabela “Condition”

continand expresiile conditionale relevante la instalarea modulelor sau tabela

“Upgrade” folosita in timpul upgrade-ului intre versiunile aplicatiilor.

Legaturile între tabelele nucleu ale fisierului msi

2. Tabelele relevante la fisiere

Din acest grup cea mai importanta tabela este “File”. Aceasta contine in

intregime fisierele necesare instalarii, dar nu si pe cele disk (fisiere cab) care sunt

definite in tabela “Media”. Dintre celelalte tabele putem aminti:

- tabela RemoveFile – contine lista cu fisierele care trebuie sterse la

dezinstalarea aplicatiei

- tabela Font – listeaza fisierele de formatare (fonturile) inregistrate

- tabela DuplicateFile – specifica fisierele care vor trebui sa fie duplicate

(instalate in mai multe directoare) in timpul instalarii.

- tabela IniFile – contine fisiele de tip .ini si informatiile pe care aplicatia

trebuie sa le configureze in acestea.

- tabela Environment – se foloseste pentru setarea variabilelor de sistem sau

a modificarilor aduse fisierului autoexec.bat (pentru Windows 95)

- tabela MsiFileHash – folosita pentru stocarea unui cod pe 128 de biti al

fisierelor sursa

3. Tabelele relevante la registri

Grupul tabelelor referitoare la registri contine:

- tabelele “Extension” si “Verb” – contin extensiile instalate de catre

aplicatie, precum si actiunile asociate acestora.

- tabela “TypeLib” – furnizeaza metoda de inregistrare a librariilor de tip

(type libraries)

- tabela “Class” – permite inregistrarea Class ID-urilor si a altor informatii

ale obiectelor COM.

- tabela “Registry” – contine toate informatiile pe care aplicatia are nevoie

sa le scrie in registri. Aceste informatii includ configurari implicite, date

ale utilizatorului sau informatiile de inregistrare COM care nu sunt

suportate de tabelele specifice.

4 . Tabelele de secventa

Acest tip de tabele controleaza sarcinile care sunt indeplinite pe parcursul instalarii

sau dezinstalarii aplicatiei, precum si conditionarea acestora.

Aceste sarcini pot fi actiuni standard care sunt tratate de care serviciul Windows

Installer sau actiuni customizate de catre dezvoltatorul pachetului (custom actions).

Pentru flexibilitate, baza de date asigura suportul pentru definirea propriilor actiuni cu

ajutorul tabelei “CustomAction”.

Unele tabele din acest grup controleaza actinile, asigurand acestora o ordine de

executie, atat in ceea ce priveste interfata cu utilizatorul cat si la rularea in cadrul

instalarii propriu-zise (tabelele “InstallUISequence” si “InstallExecuteSequence”)

Mecanismul de instalare al pachetului msi

In cadrul mecanismului de instalare exista mai multe faze:

a) Faza de detectie

La inceputul acestei faze, aplicatia sau utilizatorul configureaza instalarea unui

modul sau a unei aplicatii. Installerul progreseaza apoi prin actiunile definite in

tabelele de secventa, interogheaza baza de date si genereaza scriptul de instalare care

ofera o procedura “pas cu pas” pentru efectuarea practica a instalarii.

b) Faza de executie propriu-zisa

În timpul fazei de executie, Installerul trece aceste informaţii unui proces cu

privilegii crescute (msiexec.exe) care rulează script-ul definit la pasul precedent.

c) Faza de rollback

In cazul in care instalarea nu se termina cu success, tehnologia Windows

Installer asigura restaurarea starii initiale a sistemului. La procesarea script-ului de

instalare, se genereaza automat si un script de rollback si se fac backup-uri succesive

tuturor fisierelor sterse in timpul instalarii. Aceste fisiere sunt sterse permanent in

cazul in care instalarea este finalizata cu suces.

• MST (Transform File)- O transformare este o colecţie de

modificări aplicate unei instalari. Prin aplicarea unei transformari asupra unui pachet

de instalare de bază, programul de instalare poate adăuga sau înlocui datele din baza

de date. Programul de instalare poate aplica fisierele transform numai în timpul

instalării.

O transformare poate modifica informaţii care se află în orice tabel existent în baza de

date sau poate adăuga sau elimina tabele care se afla in cadrul pachetului msi.

Fişierele transform sunt utilizate pentru:

- Personalizarea pachetelor de instalare de bază pentru anumite grupuri de

utilizatori.

- Localizarea aplicatiilor in mai multe limbi. Transformările sunt utile pentru

localizarea aplicatiei in mai multe limbi prin aplicarea unui fisier transformare

specific unei limbi asupra bazei de date initiale pentru a adapta aplicatia sau

interfata utilizator a acesteia la limba respectiva.

• MSP (Patch File) - sunt folosite, la fel ca MST-urile pentru

modificarea pachetului initial, dar spre deosebire de acestea,

patch-urile sunt utilizate pentru repararea/updatarea aplicaţiilor

deja instalate.

• MSM (MergeModule File) – fişierele MergeModule sunt

fişiere .msi simplificate. Acestea nu pot fi instalate

independent, deoarece le lipsesc tabele vitale din baza de date

dar care sunt prezente intr-un fisier .msi sau pot cuprinde, de

asemenea, tabele specifice. Pentru a instala informatiile

continute intr-un modul odata cu aplicatia, merge-modulul

trebuie unificat cu pachetul .msi principal.

• CAB (Cabinet File) - colecţie de mai multe fişiere folosite în

timpul instalării compresate şi înmagazinate ca un singur fişier.

Toate aceste fişiere pot folosi caracteristica „semnăturii digitale” (digitally

signed), folosită pentru a furniza informaţii despre producătorul fişierului respectiv,

dând astfel utilizatorului posibilitatea de a alege dacă să instaleze produsul sau nu.

Capitolul 3. Prezentare a procesului de reîmpachetare al

aplicaţiilor

3.1 Definiţie

Reîmpachetarea aplicaţiilor este procesul de captură a schimbărilor survenite

în urma instalării unui program, în scopul realizării unei noi instalări personalizate.

Noul program de instalare, denumit „pachet”, va fi proiectat pentru îndeplinirea

standardelor impuse de clienţi şi pentru a corespunde metodei de distribuţie folosite.

Procesul de reîmpachetare ajută la economisirea de efort, timp şi resurse materiale,

permiţând astfel administratorului de sistem să personalizeze instalările potrivit

cerinţelor companiei. De exemplu, administratorul poate reîmpacheta programele

pentru a se instala „silent”- fără apariţia dialogurilor. Astfel se înlătură erorile pe care

le-ar putea produce o alegere greşită a utilizatorului în procesul instalării aplicaţiei,

fapt ce ar necesita efort şi timp pentru reparare.

Motivul principal pentru care se reîmpachetează aplicaştile este crearea unei

instalări automate şi personalizate a acestora. Folosind acest tip de instalări se reduce

costul suportului pe care administratorul ar trebui să îl acorde utilizatorului în cazul

programelor clasice de instalare. Se obţine astfel o standardizare a instalărilor ce are

ca urmare benefică reducerea variabilităţii - utilizatorii nu pot instala aplicaţii pentru

uzul personal şi nu pot instala programele „de serviciu” în moduri care ar putea duce

la nefuncţionarea altor software-uri. Prin această standardizare administratorul ştie ce

programe sunt instalate pe fiecare sistem, lucru care este folositor pentru procesul de

depanare a problemelor de funcţionare.

3.2 Reîmpachetarea ca o forma organizată de instalare a

aceleaşi aplicaţii în medii diferite

Dezvoltatorii şi administratorii de sistem care se ocupa cu personalizarea şi

instalarea aplicaţiilor- packager-ii - crează programe de instalare, dar metodele şi

motivaţiile acestora diferă. Packagerii reîmpachetează aplicaţii deja existente pentru a

le personaliza conform standardelor de instalare în masă, iar programatorii crează

instalări corespunzătoare aplicaţiilor respective. Tabelul următor evidenţiază cerinţele

creării programelor de instalare atât pentru dezvoltatori, cât şi pentru packageri.

- Metoda creării instalării: instalare

conformă cu cerinţele aplicaţiei

- Dezvoltatorii crează instalări de la

zero

-Metoda creării instalării:

reîmpachetare

- Administratorii personalizează o

instalare deja existentă

- Instalare pe un singur computer

- Ţinta sunt calculatoarele individuale

- Instalare pe multe maşini

- Aplicaţiile pot fi distribuite în reţea,

eliminând necesitatea deplasării la

fiecare calculator şi a instalării

individuale

- Integrare minimă cu alte programe

- Preocupare minimă asupra

posibilităţii coruperii funcţionării

altor aplicaţii

- Integrarea cu alte aplicaţii este

esenţială

- Buna funcţionare a tuturor

programelor instalate este o cerinţă

imperativă

- Instalarea se poate realiza pe mai

multe platforme

- Nu se cunosc specificaţiile

sistemelor pe care urmează să se

instaleze programele, deci instalările

sunt proiectate să funcţioneze pe o

serie de platforme

- Instalarea are loc pe un număr

restrâns de platforme

- Se cunosc configurările

calculatoarelor ţintă, deci instalarea

trebuie să funcţioneze doar pentru

aceste cerinţe

- Instalări flexibile

- Utilizatorul decide unde să instaleze

aplicaţia

- Instalări inflexibile

- Utilizatorul nu poate schimba

destinaţia instalării

- De obicei aplicaţia se distribuie de

pe CD pentru fiecare utilizator

- Programele se instalează din reţea

pentru mai mulţi utilizatori

- Utilizatorii interacţionează cu

instalarea programelor, putând astfel

alege diferite opţiuni

- Nu este dorită intervenţia

utilizatorilor în procesul de instalare,

aceasta decurgând după caracteristici

setate de administratori

- Instalări executate de utilizatori

- Iniţierea instalărilor este realizată de

utilizatori

- Instalări executate de sistem

- Instalările au loc prin intermediul

reţelelor şi pot rula „silent” pe

calculatoarele utilizatorilor în timp ce

aceştia lucrează, în timpul nopţii, sau

când aceştia execută o aplicaţie

- Utilizatorii primesc mesaje ce

descriu progresul instalării

- Utilizatorii nu sunt deranjaţi de

mesajele legate de stadiul instalării,

acestea fiind îndreptate către sistemul

de distribuţie

3.3 Vendor msi şi aplicaţii clasice

Odată cu apariţia tehnologiei „Windows Installer” au început să fie furnizate

pachete folosind atât programul de instalare al fiecărui dezvoltator, cât şi instalări

bazate pe această tehnologie. Astfel, programatorii au putut opta pentru aceast nou

format de pachet „msi”.

Aplicaţiile împachetate în acest format beneficiază de toate capabilităţile puse

la dispoziţie de Windows Installer. În ceea ce priveşte reîmpachetarea programelor

aceste aplicaţii sunt „Vendor msi”, deoarece sunt deja furnizate în format „msi”.

Reîmpachetarea uni astfel de pachet diferă de cea a unei aplicaţii care

foloseşte un setup normal, prin aceea că nu se mai poate folosi metoda „capturii”

pentru personalizarea instalării, ci se va crea un fisier „mst” care să ajusteze pachetul

după cerinţele date.

3.4 Etapele reîmpachetării aplicaţiilor

Pentru realizarea acestui proces este necesară parcurgerea unor etape pre-

reîmpachetare:

a. Stabilirea unei persoane de contact reprezentând clientul

b. Stabilirea instrumentului cu care se va realiza pachetul, stabilirea

sistemului de operare pe care se va face instalarea

c. Realizarea unei convenţii privind numele ce vor fi folosite (cel al

programului, al producătorului şi al pachetului final), versiunea

aplicaţiei

d. Stabilirea tipului de cab folosit: intern sau extern

e. Dependinţele hardware

f. Dependinţele software

g. Formularea unor cerinţe clare cu privire la paşii ce trebuie urmaţi în

instalarea aplicaţiei. Este recomandată furnizarea a cât mai multor

amănunte pentru detalierea instalării

h. Stabilirea modului în care va fi distribuit pachetul final

Odată parcurse aceste etape, poate fi început procesul propriu-zis de

reîmpachetare. Acesta presupune:

i. Realizarea imaginii curate („clean machine”)

ii. Realizarea imaginii de bază

iii. Analizarea aplicaţiei

iv. Reîmpachetarea programului

v. Prelucrarea pachetului

vi. Testarea aplicaţiei rezultate

vii. Livrarea pachetului utilizatorilor

i. Realizarea imaginii curate - prin „clean machine” se înţelege un

calculator pe care este instalat doar sistemul de operare. Aceasta va reprezenta punctul

de pornire al procesului de reîmpachetare.

Dacă în mediul în care se va distribui pachetul final sunt instalate mai multe

versiuni ale aceluiaşi sistem de operare, la crearea imaginii curate se va folosi cea mai

veche dintre acestea. De exemplu, dacă unele calculatoare folosesc Windows XP SP1

şi altele Windows XP SP2, clean image-ul va fi realizat folosind Windows XP SP1.

Scopul reîmpachetării este acela de a crea o instalare la fel de eficientă ca

aceea a aplicaţiei originale. Dat fiind faptul că programele au dependinţe ce ţin de

sistemul de operare, folosind versiunea mai veche a acestuia aplicaţia va fi forţată să

instaleze toate fişierele necesare funcţionării corecte. Se asigură astfel că indiferent pe

ce platformă va rula, pachetul final va furniza aceleaşi caracteristici ca aplicaţia

originală.

Clean machine-ul este pregătit de funcţionare, dar nu trebuie neglijat un aspect:

această imagine va fi folosită de multe ori, iar pentru a economisi timp se recomandă

salvarea imaginii sistemului de operare.

ii. Realizarea imaginii de bază - presupune instalarea unui număr minim de

programe care se găsesc pe maşinile utilizatorilor. Această imagine este folosită

pentru a reproduce starea sistemelor pe care se va instala pachetul şi este folosită

pentru testarea acestuia.

Lista acestor programe care vor fi instalate peste imaginea curată variază în

funcţie de cerinţele clienţilor. Printre acestea se pot număra:

• Suita de programe Microsoft Office

• Adobe Acrobat

• Programe anti-virus

Din nou se recomandă salvarea imaginii sistemului de operare, deoarece

aceasta va fi necesară pentru realizarea testărilor repetate.

iii. Analizarea aplicaţiei - are drept scop familiarizarea packeger-ului cu

modul de instalare a aplicaţiei. Se verifică, în primul rând, dacă setările ce trebuie

făcute în timpul instalării coincid cu cele descrise în etapele de pre-reîmpachetare şi

dacă programul funcţionează. Apoi se urmăresc ce fişiere, regiştrii se instalează, dacă

apar shortcut-uri pe desktop şi se ţine cont de serviciile sau odbc-urile instalate.

Un alt aspect important este acela al testării aplicaţiei cât mai amănunţite

pentru observarea anumitor particularităţi ale acesteia.

Parcurgerea minuţioasă a acestei etape este foarte folositoare mai târziu, în

timpul procesului de reîmpachetare, pentru a verifica dacă pachetul rezultat se

comportă la fel ca aplicaţia originală.

iv. Reîmpachetarea programului. Această etapă reprezintă nucleul

întregului proces de reîmpachetare. Din punct de vedere al programului de instalare se

deosebesc două tipuri de aplicaţii- vendor msi-uri şi setup-uri clasice. Doar acestea

din urmă se vor reîmpacheta, deoarece aplicatiile in format msi respecta in mare parte

standardizare impusa de tehnologia Windows Installer, iar pentru personalizarea

vendorului msi se folosesc fisirele transform “mst”.

Pentru această etapă este nevoie de folosirea unui tool care să surprindă

schimbările ce decurg în urma instalării aplicaţiei originale. Tool-urile disponibile

pentru „captură” - Installshield AdminStudio, Wise Package Studio, etc.

Procesul de „captură” va crea un pachet ce va conţine schimbările pe care

instalarea aplicaţiei le-a produs, schimbări ce reprezintă diferenţa dintre stările

sistemului de operare înainte şi după instalarea aplicaţiei. Succesiunea paşilor este

următoarea:

a. Se foloseşte imaginea curată creată anterior.

b. Se începe procesul de captură - acesta presupune realizarea unei

scanări pentru a capta starea iniţială a sistemului.

c. Se instalează aplicaţia conform cerinţelor stabilite în procesul de

pre-reîmpachetare (completarea dialogurilor, restartarea

maşinii, setarea unor opţiuni la rularea aplicaţiei ş.a.m.d).

d. După ce s-au realizat toate setările şi aplicaţia funcţionează

corespunzător, se porneşte cea de-a doua scanare ce va conţine

starea finală a sistemului.

În timpul capturii este interzisă rularea oricărei alte aplicaţii, deoarece orice

operaţie realizată de sistemul de operare va fi considerată ca aparţinând programului

de împachetat şi inclusă în „msi”.

În acest moment pachetul este generat şi se poate salva, fiind disponibil

modificărilor ulterioare.

v. Prelucrarea pachetului

Deseori la captură sunt incluse fişiere şi regiştrii ce nu aparţin aplicaţiei dar au

fost modificaţi de procese ale sistemului de operare în intervalul dintre cele două

scanări.

Pe lângă excluderea resurselor ce nu aparţin aplicaţiei, această etapă se ocupă,

deasemenea, cu setarea denumirilor conform indicaţiilor specificate de către client

(numele aplicaţiei din meniul Add/Remove Programs, titlul msi-ului ş.a.m.d) şi cu

ultimele modificări aduse programului (structura directoarelor este corectă, shortcut-

urile sunt plasate şi denumite conform regulilor şi icon-urile corespund cu cele ale

aplicatiei originale).

O listă a câtorva fişiere şi directoare ce trebuie deseori eliminate din pachet

este următoarea:

Director/Fişier Descriere

Windows\Security Acest fişier conţine informaţii despre securitatea

NTFS specifice maşinii.

Windows\Debug Acest director conţine loguri de debug.

Windows\Temp Acest director conţine informaţii temporare

pentru utilizator.

Windows\Tasks Acest director conţine setăriile task scheduler.

Documents and Settings\[name]\Application Data\

Microsoft\SystemCertificates

Acest director conţine certificate scrise pe

utilizatorul curent in regiştrii sistemului de

fiecare dată când acesta se loghează.

Document and Settings\[Username]\Local

Settings\Temporary Internet Files\

Conţine informaţii de Internet ale istoriei end

user-ului.


Settings\History\

Acest director contine istoria navigării pe

internet a utilizatorului.


Settings\Temp\

Acesta este un folder temp al user-ului.

Document and Settings\[Username]\My Recent

Documents\

Conţine cele mai recente documente ale user-

ului.

Windows\Recycler Conţine informaţii care aparţin recycle bin.

Windows\CSC Reprezintă locul unde se stochează foldere

offline ale user-ului.

Windows\System32\WBEM Conţine informatii specifice maşinii pentru

WBEM(Web Based Enterprise Management)

Document and Settings\All Users\Application

Data\Microsoft\Crypto

Acest director conţine informaţii despre

semnătura digitală de pe maşina destinaţie.

Document and Settings\All Users\DRM Conţine informaţii criptate.

Windows\system32\appmgmt\[sid]\appmgmt.ini Acest director conţine informaţii despre

configurarea sistemului de operare.

Wise Share Point\ Creat de Wise , acest director conţine informaţii

despre user.


Settings\Temporary Internet Files\Content.IE5\

Acest director conţine informaţii temporare din

Internet Explorer.

Windows\MS\SMS Conţine informaţii SMS.

Windows\PreFetch Este folosit ca aplicaţia să pornească mai rapid.

Document and Settings\[Username]\Cookies Acest director conţine software cookies care sunt

scrise automat când utilizatorul acceseaza

website-uri.

Program Files\Wise Package Studio Acest director conţine informaţii ale aplicaţiei

Wise

Un aspect deloc de neglijat este izolarea coflictelor. Pentru stabilirea fişierelor

share-uite cu mai multe aplicaţii se pot folosi două alternative: fie se instalează

aplicaţia pe o imagine care cuprinde toate programele instalate până în momentul de

faţă pe maşinile clienţilor şi se identifică eventualele probleme de funcţionare a

celorlalte aplicaţii cauzate de modificarea unui fişier share-uit, fie se foloseşte un tool

de monitorizare a conflictelor. Prima variantă necesită o imagine updatată a

calculatoarelor ţintă - ceea ce este dificil de obţinut - şi presupune consumarea unui

interval mare de timp pentru realizare.

Aşadar, se foloseşte cea de-a doua metodă. Tool-urile disponibile

(ConflictManager- Wise Package Studio, Conflict Solver- AdminStudio) importă într-o

bază de date resursele instalate de fiecare aplicaţie, putând astfel să detecteze

eventuale conflicte.

Fişierele care se află în directoare share-uite şi ar intra în conflict cu versiuni

diferite instalate deja pe maşină, se izolează folosind tabelul „IsolatedComponent”.

Acest tabel cuprinde două coloane: „Component_Shared” şi

„Component_Application”. În coloana „Component_Shared” se trec componentele

care conţin fişierele share-uite şi în coloana „Component_Application” se trec

componentele care includ executabilele care folosesc aceste fişiere. Astfel în timpul

instalării, copii ale fişierelor share-uite vor fi instalate în directorul care conţine

executabilele, şi vor fi folosite de acestea în timpul rulării.

Tot în această etapă se creează, în funcţie de cerinţele clienţilor, o instalare

„Quiet” (instalarea are loc fără intervenţia utilizatorului - nu apar dialoguri,

utilizatorul este avertizat de procesul care se desfăşoară prin afişarea progresului

instalării), sau „Silent” (instalarea are loc fără înştiinţarea utilizatorului)

vi. Testarea aplicaţiei rezultate

Este o etapă foarte importantă în procesul de creare a unui pachet care se

instalează şi funcţionează corect. Testarea completă a aplicaţiei necesită două

abordări: testare pentru asigurarea calităţii („quality assurance”) realizată de echipa de

packagerii şi testarea de conformitate cu cerinţele utilizatorilor („user-acceptance”).

Scopul testării user-acceptance este acela de a confirma că pachetul corespunde

aşteptărilor clienţilor - funcţionarea acestuia este identică cu a aplicaţiei originale.

Testarea aigurarii calitaţii este foarte important ca procesele de reîmpachetare

şi testare a aplicaţiilor să fie realizate de echipe diferite. Acest proces se derulează pe

imaginea de bază care simulează sistemele pe care lucrează utilizatorii şi vizează:

• Instalarea pachetului conformă cu cerinţele clientului

• Funcţionarea corespunzătoare a aplicaţiei

• Respectarea standardelor stabilite în procesul de pre-

reîmpachetare

• Funcţionarea corectă a ODBC-urilor create în timpul instalării

• Rularea corectă a serviciilor instalate de aplicaţie

Testarea user-acceptance se realizează de către clienţi pe sisteme configurate

conform standardelor companiei şi are ca scop o ultimă verificare a pachetului inainte

de lansarea acestuia în producţie.

vii. Livrarea pachetului utilizatorilor

Odată cu trecerea testelor prezentate la punctul anterior, aplicaţia este

distribuită utilizatorilor.

3.5 Instrumente folosite la impachetarea aplicatiilor

Orca

După cum am arătat pe parcursul lucrării, fişierele msi sunt baze de date.

Orca, inclus în Windows Installer SDK, este un tool foarte util pentru a manipula

înregistrările din acestea. Simplitatea cu care se lucrează recomandă folosirea acestui

tool pentru o serie de operaţiuni nu foarte complicate: ştergerea fişierelor, denumirea

directoarelor, setarea de proprietăţi ş.a.m.d. Este dificilă realizarea custom action-

urilor, foarte mult folosite în timpul creearii pachetului.

În continuare am inclus un printscreen al acestui utilitar ce surprinde structura

msi-ului. În partea stângă se găsesc tabelele ce sunt legate între ele prin intermediul

cheilor primare şi secundare, iar în partea dreaptă sunt enumerate elementele tabelului

respectiv. Astfel, File cuprinde toate fişierele existente în pachet cu caracteristicile

acestora - numele intern folosit de Windows Installer pentru identificare - şi numele

extern cu care vor fi instalate, componenta pe care se află, mărimea, versiunea

ş.a.m.d.

Installshield AdminStudio

Pentru reîmpachetarea aplicaţiilor se foloseşte Repackager-ul. In continuare

voi exemplifica procesul de captura.

După alegerea opţiunii „Snapshot” se realizează scanarea iniţială a hard disk-

ului.

Pasul următor este rularea aplicaţiei şi scanarea finală a sistemului:

În acest moment nu este creat direct msi-ul, ci un pachet cu extensia „irp”,

care nu include fişierele şi celelalte resurse, ci doar le referenţiază. Este recomandat

ca excluderea resurselor care nu aparţin aplicaţiei, dar care au fost prinse la captură, să

se realizeze în această etapă. Pentru crearea msi-ului se foloseşte opţiunea Build.

Înainte de conversie se pot alege diferite opţiuni în ceea ce priveşte

caracteristicile pachetului:

• Fişierele ce aparţin unor module redistribuite („merge modules”) să fie

incluse în pachet- aceasta presupune ştergerea fişierelor din captură şi

adăugarea merge module-urilor.

• Componentele instalate în System32 sunt setate ca permanente

• Atributele componentelor instalate în Common Files indică faptul că

acestea sunt share-uite

• Regiştrii sunt mapaţi în tabelele corespunzătoare

Odată cu generarea msi-ului, se crează un fişier intermediar cu extensia „ism”.

Acesta poate fi folosit pentru setarea tipului de cab folosit. Se alege opţiunea Release

Wizard din meniul Build. Astfel se poate alege tipul de cab pentru msi-ul ce urmează

a fi creat:

Compress all files implică includerea fişierelor într-un cab intern msi-ului.

Leave files uncompressed and separate from the installation package

corespunde generării unui cab extern care include fişierele.

Custom creează cab extern şi oferă posibilitatea de a alege generarea unui cab

fie pentru fiecare feature, fie pentru fiecare componentă.

Pentru editarea atât a fişierelor ism cât şi a celor de tip msi, Installshield-ul

pune la dispoziţie meniuri cu interfeţe grafice „prietenoase” ce cuprind opţiuni şi

unelte eficiente în dezvoltarea pachetelor.

În partea stângă sunt listate resursele ce intră în alcătuirea pachetului, iar în

partea dreapta este prezentat conţinutul acestora.

În acest exemplu este detaliată secţiunea Custom Action ce cuprinde

secvenţele ne-standard executate la instalarea pachetului.

Pe lângă acest mod de a vedea secţiunile pachetului, mai este oferită şi

versiunea tabelară similară celei folosite de Orca Tools.

Mst- urile se creează cu utilitarul InstallShield Tuner:

După lansarea lansarea tool-ului se alege opţiunea Create a new transform, se

alege msi-ul care trebuie personalizat şi se bifează opţiunea Response Transforms ca

în figura precedentă. Apoi se va simula instalarea prin derularea dialogurilor şi

configurările setate în acest timp vor fi salvate în mst.

Conflictele fişierelor share-uite se detectează cu ajutorul uneltei

ConflictSolver. Acest tool este o bază de date în care se importă toate aplicaţiile care

se pot afla deja pe maşinile ţintă în momentul instalării pachetului. ConflictSolver-ul

semnalează fişierele care sunt instalate de mai multe programe în vederea realizării

procesului de izolare.

Wise Pacakge Studio

Realizarea capturii se realizează cu ajutorul opţiunii Setup Capture:

La începutul capturii se poate opta pentru realizarea clean build-ului în timpul

instalării aplicaţiei. Astfel se vor salva într-un director selectat fişierele pe care

programul le instalează şi un fişier wsi. Acesta este generat după procesul de captură

şi reprezintă o etapă intermediară până la crearea msi-ului.

Wsi-ul nu conţine numai referinţe la fişierele aplicaţiei, acestea urmând să fie

incluse în cab-uri (interne sau externe în funcţie de cerinţele clienţilor) la generarea

msi-ului.

Wise Pacakge Studio foloseşte în timpul capturii liste de excluziune a

fişierelor şi a regiştrilor modificaţi de obicei de sistemul de operare şi prinşi, prin

urmare în captură.

Fişier ObservatiiDesilu.isu Toate directoarele, exclude subdirectoarele da

desktop.ini Toate directoarele, exclude subdirectoarele da

Ffastlog.txt Toate directoarele, exclude subdirectoarele da

Fntcache.dat Toate directoarele, exclude subdirectoarele da

Install.log Toate directoarele, exclude subdirectoarele da

Lmscript.pif Toate directoarele, exclude subdirectoarele da

NTUSER.DAT Toate directoarele, exclude subdirectoarele da

Ntuser.dat.LOG Toate directoarele, exclude subdirectoarele da

Ntuser.ini Toate directoarele, exclude subdirectoarele da

Ntuser.pol Toate directoarele, exclude subdirectoarele da

pagefile.sys Toate directoarele, exclude subdirectoarele da

SchedLgU.txt Toate directoarele, exclude subdirectoarele da

Setupapi.log Toate directoarele, exclude subdirectoarele da

SMSCFG.ini Toate directoarele, exclude subdirectoarele da

St6unst.log Toate directoarele, exclude subdirectoarele da

Uninst.exe Toate directoarele, exclude subdirectoarele da

Unwise.exe Toate directoarele, exclude subdirectoarele da

Files with a .0 number extension Toate directoarele, exclude subdirectoarele da

Files with a .BAK extension Toate directoarele, exclude subdirectoarele da

C:\OS\IsUninst.exe [WindowsFolder], exclude subdirectoarele nu

C:\OS\Tasks\SA.DAT [WindowsFolder], exclude subdirectoarele nu

C:\OS\security\Database\secedit.sdb

[WindowsFolder], exclude subdirectoarele nu

C:\Data\Profiles\<current user>\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat

C:\Data\Profiles\<current user>\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat.LOG

C:\Data\Profiles\<current user>\Application Data\Microsoft\Internet Explorer\brndlog.txt

C:\Data\Profiles\<current user>\Application Data\Microsoft\Internet Explorer\brndlog.bak

C:\Data\Profiles\<current user>\Application Data\Microsoft\Internet Explorer\Desktop.htt

C:\Data\Profiles\<current user>\Cookies\index.dat

C:\OS\wiaservc.log [WindowsFolder], exclude subdirectoarele nu

C:\OS\system32\wpa.dbl [SystemFolder], exclude subdirectoarele nu

C:\Data\Profiles\<current user>\Local Settings\Application Data\IconCache.db

C:\Data\Profiles\<current user>\My Documents\My Pictures\Thumbs.db

C:\Data\Profiles\LocalService\Cookies\index.dat

C:\Data\Profiles\LocalService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat

C:\Data\Profiles\LocalService\

Procesul de captură presupune realizarea a două scanări a sistemului, înainte şi

după instalarea aplicaţia. Se captează astfel schimbările aduse de programul instalat

care sunt salvate, după cum am arătat mai devreme într-un fişier wsi. În acest moment

se ştie „ce” instalează aplicaţia, dar „cum” se realizează acest lucru rămâne în sarcina

packager-ilor să descopere.

Pentru generarea msi-ului se foloseşte opţiunea Compile. Prelucrarea

pachetului se realizează cu ajutorul tool-ului Windows Installer Editor. Acesta

cuprinde trei secţiuni.

Installation Expert- logica creării pachetului este prezentată sub forma unei

interfeţe grafice intuitive ce cuprinde, după cum ilustrează figura, în partea stângă

meniurile folosite în procesul de reîmpachetare, iar în partea dreaptă detalierea

acestora.

Msi Script- conţine toate secvenţele personalizate („custom actions”) executate

în timpul instalării aplicaţiei.

Setup Editor- logica de instalare a pachetelor prezentată în Installation Expert

sub aspectul meniurilor este aici conţinută în tabele ce formează baza de date

relaţională care stă la baza msi-ului. Este important de subliniat că ambele secţiuni,

atât Msi Script, cât şi Installation Expert sunt cuprinse în Setup Editor. Astfel, oricărei

modificări realizate în cele două secţiuni îi corespunde o ajustare a conţinutului în

Setup Editor, şi orice modificare în această secţiune implică setarea unor valori într-

una sau în ambele secţiuni enumerate mai sus.

Validarea pachetelor se realizează cu ajutorul uneltei Package Validation.

Astfel se rulează Internal Consistency Evaluators („ICE”) pentru detectarea erorilor

sau avertizărilor („Warnings”) din cadrul bazei de date.

ICE-urile sunt funcţii cuprinse în script-uri, în DLL-uri sau în EXE-uri. În

tabelul următor sunt detaliate cele mai importante Internal Consistency Evaluators:

ICE DescriereICE03 Validează datele şi cheile primare

ICE04 Validează numerele de secvenţă ale fişierelor comparându-le cu numerele ultimei secvenţe („LastSequence numbers”) din tabelul Media

ICE16 Validează faptul că ProductName-ul din tabelul Property nu are mai mult de 63 de caractere

ICE19 Validează tabelele advertise: Class, TypeLib, Extension, PublishComponents şi Shortcut

ICE30 Validează faptul că instalarea componentelor care conţin aceleaşi fişiere nu se realizează mai mult decât o dată în acelaşi director

ICE33 Verifică intrări din tabelul Registry care ar trebui incluse în alte tabele

ICE36 Validează faptul că icon-urile din tabelul Icon sunt incluse şi în tabelele Class, ProgId sau Shortcut

ICE39 Validează câmpul Summary Information din baza de date

ICE43 Verifică shortcut-urile advertise să aparţină componentelor cu chei regiştrii ale user-ului curent- HKEY_CURRENT_USER

ICE48 Verifică să nu existe directoare hardcode-ate cu adrese locale

ICE57 Validează faptul ca o singură componentă să nu aibă atât date per-machine, cât şi date per-user.

ICE58 Verifică numărul de rânduri din tabelul Media, acesta nu trebuie să depăşească 80

ICE61 Verifică tabelul Upgrade

ICE64 Verifică faptul că directoarele noi din profilul user-ului sunt listate şi în tabelul RemoveFile

ICE68 Validează faptul că toate tipurile Custom Action-urilor necesare instalării sunt valide

ICE71 Verifică faptul că tabelul Media conţine o intrare DiskId egală cu 1

ICE77 Verifică secvenţele Custom Action-urilor. Acestea ar trebui să fie situate între InstallInitialize şi InstallFinalize

ICE88 Validează coloana DirProperty din tabelul IniFile

ICE99 Verifică numele proprietăţilor; acestea nu trebuie să fie aceleaşi cu numele rezervate de Windows Installer

http://msdn2.microsoft.com/en-us/library/aa369535.aspx

Capitolul 4. Prezentarea WPKG – utilitar de instalare

automata in reteaWpkg este un produs software de instalare, upgrade şi şterge a aplicatiilor

pentru Windows. Este folositor pentru a instala aplicatiile de la un server central

(Active Directory sau Samba) pentru statile de lucru din retea.

Utlitarul este alcatuit din doua parti: parte de server şi parte de client. In

continuare voi prezenta configurarile necesare pentru parte de server cu Active

Directory şi paşi necesari pentru configurarea parti de cilent pe sistemul de operare

Windows Xp.

4.1 Configurarea partii de server a WPKGParte server a utilitarului este alcatuita din urmatoarele fisiere:

Wpkg.js – fişierul este inima intregului utilitar, el fiind cel care coordoneaza

tot procesul de conectare ale clientilor, de instalare si de stergere a aplicatilor

pe masinile client.

Config.xml – este fisierul in care diferite setari ale wpkg.js pot fi configurate.

Hosts.xml – este fisierul unde se definesc maşinile şi profilele asociate pe care

urmeza sa se instaleze aplicatiile dorite.

Profiles.xml – este fisierul unde se definesc pachetele care vor fi instalate pe

maşinile client

Packages.xml – este fisierul unde se defineşte modul in care se instaleaza,

upgradeaza sau se dezinstaleaza pachetele de pe maşinile client.

Pentru a functiona toate fişierele prezentate mai sus trebuie sa exista in acelaşi

director şi in plus mai sunt necesare cateva configuratii ale Active Directory:

Se dechide Active Directory User and Computers (Start->Administrative

Tools -> Active Directory User and Computers)

Se selecteaza grupul de computere (OU) si se alege Properties iar apoi Group

Policy

Se selecteaza butonul „New” şi se completeza numele politcii de grup

dupa care se selecteaza „Edit”.

Se selecteaza apoi Computer Configuration -> Administrative

Templates -> System -> Scripts şi se seteaza valori pentru „Run startup

scripts asynchronously” şi „Maximum wait time for Group Policy

scripts”

Run startup scripts asynchronously este necesar sa fie activata in

acestmod utilizatorul se poate conecta astfel exista riscul ca acesta sa

creada ca statia s-a blocat neputandu-se loga şi poate reseta sistemul

ducand la o functionalitate defectuaoasa a utilitarului de instalare.

Maximum wait time for Group Policy scripts – prin acesta politica se

determina timpul maxim de asteptare pentru a se aplica script-urile

politici de grup pe sistem, daca timpul este depasit atunci sistemul

opreste rularea scriptului şi inregistreaza o eroare in event log. Pentru

instlarea aplicatilor cu Wpkg este recomandata un timp de minim 30 de

minute.

Se selecteaza apoi Computer Configuration -> Windows Settings ->

Startup şi se seleteaza un script care v-a porni WPKG la pornirea

sistemului

Ultimul pas este crearea fisierului .bat care contine urmatoare linie de

comanda: cscript \\server\ calea catre directorul wpkg\WPKG\wpkg.js

/synchronize /quiet /nonotify

Pentru a functiona utilitarul WPKG este necesar ca directorul unde se gasesc

fisierele de configurare sa fie un director shared.

4.2 Configurarea partii de client a WPKGPe maşina client se instaleaza aplicatia client a utiliarului acesta venind cu

interfata grafica fiind astfel usor de configurat şi in acelasi timp si rapid. Instalerul

Wpkg va crea pe masina client un serviciu. Acesta va rula la initializarea sistemului si

va citi fisierele xml de configurare din folderul de pe server unde acestea se gasesc.

Servicul va rula cu permisiuni de user de System.

Wpkg file path – reprezinta locatia unde se gaseste fisierul care prin

care se va realiza instalarea aplicatiilor pe masinile client.

Wpkg parameters – reprezinta parametrii cu care se executa scriptul

Wpkg path user – este utilizatorul care cu care clientul Wpkg se va

conecta la fisierle de pe server. Este recomandabil sa se creeze un

utilizator special cu permisiuni minime doar pe directorul unde se afla

wpkg.js şi pe directorul unde se afla pachetele msi care trebuiesc

instalate pe masinile client.

Wpkg path password – reprezinta parola de autentificare a

utilizatorului definit in campul Wpkg path user

Wpkg execution context reprezinta contul de utilizator local care este

folosit de WPKG.

Wpkg variables. Aici se definesc varabilele pentru stabilirea locului

unde se gasesc pachetele msi care trebuiesc instalate pe masinile client.

In Additional action putem selecta programe sau scripturi care sa se

execute inainte sau dupa executarea lui wpkg.js.

4.3 Fişierele de configurare

Hosts.xml – este fisierul unde se definesc maşinile şi profilele asociate pe care

urmeza sa se instaleze aplicatiile dorite.

Structura fişierului este urmatoarea:

<wpkg>

<host name="gazda1" profile-id="profil1" />

<host name="gazda2" profile-id="profil2" />

</wpkg>

unde gazda1 şi gazda2 sunt numele calculatoarelor din retea la care li se asociaza un

profil de instalare.

De asemenea se poate asocia unui singur gazda mai multe profile.

<wpkg>

<host name="gazda1" profile-id="profil1" >

<profile id="altprofil1"/>

<profile id="altprofil2"/>

</host>

</wpkg>

Profiles.xml – este fisierul unde se definesc pachetele care vor fi instalate pe

maşinile client


<profiles>

<profile id="general">

<package package-id="acrobat" />

<package package-id="firefox" />

</profile>

<profile id="suplimentar">

<depends profile-id="general " />

<package package-id="thunderbird" />

</profile>

</profiles>

Daca o statie este definita in host.xml şi are asociat profilul general atunci pe

statia respectiva se vor instala cele doua aplicatii definete de identificatorul package-

id. Daca insa statie este definta in host.xml si are asociat profilul suplimentar atunci

pe statia respectiva se vor instala trei pachete:acrobat, firefox si thunderbird deoarce

profilul suplimentar are integrat si profilul general.

In acest mod se pot creea foarte usor grupuri de pachete care se pot instala pe

toate statiile din retea şi se creeaza si profile impartite dupa necesitatile definite de

administrator (impartirea pe departamente, impartinrea pe camere, etc)

Packages.xml – este fisierul unde se defineşte modul in care se instaleaza,

upgradeaza sau se dezinstaleaza pachetele de pe maşinile client.


<packages>

<package

id="wpkg1"

name="Pachet 1"

revision="1"

reboot="false"

priority="0">

<check type="registry" condition="exists" path="HKLM\Software\wpkg\

cheie " />

<check type="file" condition="exists" path="%PROGRAMFILES%\wpkg\

wpkg.bat" />

<check type="uninstall" condition="exists" path="WPKG" />

<install cmd='msiexec /i (cale catre fisierul msi)'>

<exit code="0" />

</install>

<remove cmd='msiexec /x (cale catre fisierul msi)' />

<upgrade cmd='msiexec /i (cale catre fisierul msi)' />

</package>

</packages>

Fiecare pachet are urmatoarele atribute:

Id – indicatorul care corespunde cu valoarea package-id din fisierul

profiles.xml

Name – numele aplicatiei care se va instala

Revision – reprezinta versiunea pachetului de instalat, se incrementeaza atunci

cand apare o noua versiune a pachetului

Reboot – indica faptul daca sistemul se va restartarea sau nu dupa instalarea

respectivului pachet.

o Valoarea True – va duce la restartarea sistemului dupa instalarea

pachetului

o Valoarea Postponed – va duce la restartarea sistemului dupa ce toate

pachetele au fost procesate

o Orice alta valoarea – nu va restarta sistemul, alt pachet insa poate face

acest lucru.

Priority – determina ordinea de instalare a pachetelor, cu cat numarul este mai

mare cu atat pachetul se va instala mai devreme decat celelalte.

4.4 Modul de funcţionare al WPKG

Utilitatarul Wpkg este construit pe relatia client server.La intializarea

sistemului client chiar inainte de executarea etapei de log in a utilizatorului uman,

partea client a aplicatiei interogheaza partea de pe server si anume wpkg.js. Primul

pas care este facut este verificarea numelui masini daca corespunde cu numele aflate

in fisierul hosts.xml.Daca numele masinii client exista in acest fisier se trece la pasul

urmator daca nu se inchide conexiunea catre server. In pasul urmator se verfica

fisierul profiles.xml pentru a se identifica pachetele care corepund profilelor asociate

masini client. In pasul urmator se trece la verficarea fiserului pacakges.xml pentru a

verfica ce aplicatii trebuiesc instalate sau la care este necesare upgrade sau care

aplicatii trebuiesc sterse de pe masina client. Daca se gaseste de instalat o aplicatie

atunci executa conditia de instlare si se porneste pe masina client servicul windows

installer logat cu cont de system. Dupa terminarea instalarii controlul este preluat din

nou de catre wpkg.js care va face verificarile ulterioare instalarii pachetului si daca nu

mai este nimic de instalat va inchide conexiunea client-server.

Capitolul 5. Reîmpachetarea unei aplicaţii şi instalarea ei automată într-o reţea

În continuare voi exemplificarea aspectelor teoretice enunţate în această

lucrare legate de personalizarea unui program în scopul obţinerii unei instalări

automate ce corespunde cerinţelor impuse de către client.

Etapa pre-reîmpachetare:

a. Stabilirea tool-ului cu care se va realiza pachetul

- Install Shield

b. Stabilirea sistemului de operare pe care se va face instalarea

- Windows XP

c. Realizarea unei convenţii privind numele ce vor fi folosite

-Numele msi-ului, mst-ului şi cel al cab-ului vor fi de forma:

NumeProducator_Nume_Aplicaţie_Versiune_Aplicaţie_Limba_Versiune.pachet.exte

nsie

Exemplu: Oracle-BI-10.1.3.4.1-EN-R1.msi

d. Stabilirea tipului de cab folosit

- Pentru Vendor-msi nu se opereză modificări

- În cazul setup-urilor clasice cab-ul va fi extern

e. Dependinţele hardware:

- Nu are

e. Dependinţele software:

- Sun-JavaDB versiunea10.4.2.1

- Sun SDK versiunea 1.6.0.140

- Microsoft-VisualC++Redist versiunea 8.0

In urmatoarea etapa se instaleaza aplicatia pe imaginea de baza pentru a se

monitoriza modul de instalarea: daca setup-ul instaleaza si alte aplicatii necesarea

bunei functionari a aplicatiiei Oracle Business Inteligence, daca aplicatiile sunt

vendor msi sau setup-uri clasice. Pentru acesta se foloseste tool-ul PrcView cu care se

monitorizeaza toate programele lansate pe sistem din momentul poriniri acestui tool.

Se lanseaza executabilul „setup.exe”:

Se selecteza “Next” unde se introduc directoarele de instlare al aplicatiei: C:\OracleBI\OracleBI C:\OracleBI\OracleBIData si se selecteza optiunea Basic.

Se alege apoi Oracle Business Intelligence Disconnected Client

Se introduce locatia de instalare al Java Development Kit (JDK):

Iar la urmatoarele dialoguri pentru instalarea aplicatiei se selecteza “next”

pana la ultimul dialog unde se selecteza optiunea de a nu restarata sistemul dupa

apasarea butonului Finish.

In urma monitorizari cu PrcView se constata ca premergator instalarii Oracle

Business Inteligence se instaleaza de asemnea si Sun-JavaDB versiunea10.4.2.1 si

Microsoft-VisualC++Redist versiunea 8.0 (aceste doua aplicatii fiind vendor msi). Se

constata ca Oracle Business Inteligence este instalata cu ajutorul unui setup clasic deci

pentru a o putea reimpacheta trebuie instalata pe o masina curata iar modificarile

survenite in sistemul de operare se vor capta cu ajutorul utilitarului Install Shield,

acesta fiind etapa de reimpachetare al programului.

In urma acestei etapa avem generat un fisier .irp in care sunt prinse toate

modificarile sistemului. Din acest fisier se vor exclude fisierele si registri care nu tin

de aplicatie, fisierele de dezinstalare generate de setup-ul aplicatiei. De aceste fisiere

de dezinstalare nu mai avem nevoie deoarece dezinstalrea aplicatie se va face prin

intermediul Windows Installer.

Se genereaza apoi fisierul .ism prin selectarea tab-ului Build.

Etapa urmatoare este prelucarea pachetului. Prin steregerea la pasul anterior a

fisierelor si directoarelor de care nu avem nevoie in acesta etapa nu mai este nevoie sa

intervenim in modificarea tabelei “File” si “Directory”, acestea fiind populate corecte

cu informatiile necesare.

Se trece apoi la analiza registrilor. Se constata ca aplicatia instaleaza doua

servicii si pentru buna functionarea a aplicatiiei acestia trebuiesc introdusi in tabelele

“Service Install” si “Service Control”

Se verifica modificarile aduse variabilor de sistem. Se observa ca aplicatia

modifica variabila de sistem PATH si creearea de alte trei variabile de sistem proprii

aplicatiei. Se constata ca in afara de caile catre directoarele aplicatiei nostre sunt

incluse si cai proprietare sistemului pe care a fost facuta captura. Acesta se sterg din

pachetul nostru. Pentru valorile varabilei PATH definte de aplicatia nostra se verifica

ca acestea sa se seteze la instalare, sa se adauge la inceputul sau la sfarsitul varabilei

PATH fara a sterge restul de valori si la dezinstalarea aplicatiei sa se stearga.

Pasul urmator este validarea pachetului ism si corectarea cu Internal

Consistency Evaluators („ICE”) pentru detectarea erorilor sau avertizărilor din cadrul

bazei de date. Dupa corectarea erorilor din pachet ultimul pas este construirea

pachetului msi si testarea acestuia.

La testarea aplicatiei pe cont cu drepturi limitate (cont user) la lansarea short-

cutului aplicatie acesta nu se lanseaza.

Pentru ca aplicatia sa poate fi lansata de pe cont de user acesta are nevoie si de

permisiuni de executie si de scriere pentru directoarele aplicatie. Acest lucru se

realizeaza prin introducera scriptului “rights.vbs”. Acest script este introdus in

pachetul msi prin custom action “_rights”. Acum utilizatori care apartin grupului User

pot folosi aplicatia si pot opri sau porni serviciile create de Oracle Business

Intelligence Disconnected Client.

La dezinstalarea aplicatiei pentru a sterge toate urmele lasate pe sistem de

instalarea aplicatiei se executa urmatoarele custom action: “_deleteinstalldir”,

“_deleteservice”, “_killprocesssadis”, “_killprocesssawjava”, “_stoporacle”.

- stoporacle – prin acest script opreste serviciul “Oracle BI

Server”.

- Killprocesssadis si killprocesssawjava opresc procesele

sadis.exe si sawjavahostsvc.exe pentru a perminte

dezinstalarea sau repararea daca este cazul a aplicatiei.

- Deleteservice – se opreste si se sterge serviciul

sawjavahostsvc

- Deleteinstalldir – prin acest script se sterg si ultimile

fisiere si foldere ale aplicatiei la dezinstalarea.

Prin folosirea acestor scripturi ne asiguram de faptul ca aplicatia se

dezinstaleaza corect, fara erori inlaturand astfel toate resursele instalate.

La începutul anilor 1980 arhitectura programelor era …stst.elia.pub.ro/PS/2010/Optimizare a...

Documents

Transcript of La începutul anilor 1980 arhitectura programelor era …stst.elia.pub.ro/PS/2010/Optimizare a...