1

Rozdział 18.
Instalowanie i aktualizowanie
oprogramowania

Simon Rutley-Frayne

J. Alan Brogan

Yoto Yotov

Instalacja i dezinstalacja oprogramowania

Pliki CAB i INF

Wersje, uaktualnienia i poprawki

System kontroli wersji TeamSource

Program InstallShield Express

2

Obecnie zajmiemy się narzędziami zapewniającymi możliwie bezkonfliktowe instalowanie i
konserwację oprogramowania, mającymi zastosowanie zarówno dla aplikacji komercyjnych, jak i
programów klasy shareware. Na techniczną stronę rozdziału złoży się omówienie programów Install
Maker i Patch Maker firmy ClickTeam, formatów CAB i INF oraz dostarczanego w pakiecie
C++Builder programu InstallShield Express. Zajmiemy się także kwestią konserwacji oprogramowania,
powiemy kilka słów na temat tworzenia i rozpowszechniania uaktualnień i poprawek oraz
przedstawimy wprowadzenie do systemu kontroli wersji TeamSource.

Instalacja i dezinstalacja oprogramowania

Skompilowanie i uruchomienie aplikacji nie jest bynajmniej ostatnim etapem jej tworzenia. Niezbędne
jest udostępnienie użytkownikowi narzędzia pozwalającego zainstalować wszystkie elementy programu
w systemie docelowym w sposób niekłopotliwy i zapewniający poprawną pracę aplikacji. Narzędziem
takim jest program instalacyjny (instalator), umieszczający w komputerze użytkownika odpowiednie
pliki i zmieniający ustawienia systemu. Program taki powinien oczywiście być łatwy w obsłudze,
działać możliwie automatycznie i wymagać od użytkownika minimalnych kwalifikacji.

Na rynku oprogramowania dostępnych jest kilka narzędzi do tworzenia programów instalacyjnych,
począwszy od prostych programików dostępnych za darmo, a skończywszy na zaawansowanych i
kosztownych „kombajnach”. Więcej informacji na ich temat, łącznie z adresami witryn WWW
producentów, zamieszczono na końcu tego podrozdziału.

Narzędzia do tworzenia programów instalacyjnych

Pod względem zasad obsługi narzędzia przeznaczone do tworzenia programów instalacyjnych są
zbliżone do C++Buildera, chociaż korzystanie z ich funkcji jest znacznie prostsze. Budowa programu
instalacyjnego sprowadza się na ogół do utworzenia skryptu sterującego instalacją, skompilowania go,
dołączenia i skompresowania plików wchodzących w skład instalowanej aplikacji oraz zdefiniowania
elementów interfejsu użytkownika. Wynikiem takiej procedury jest utworzenie pliku (lub kilku plików)
przeznaczonego do bezpośredniej dystrybucji.

Jak to działa?

Tworzenie programu instalacyjnego sprowadza się w większości przypadków do wprowadzenia
odpowiednich informacji (nazwy instalowanych plików, położenie katalogu docelowego, informacje
wyświetlane podczas instalacji, treść licencji itd.) w oknach kreatora. Dane te zapisywane są w postaci
skryptu, sterującego następnie kompilacją wszystkich elementów do postaci właściwego pliku
instalacyjnego.

Program instalacyjny może mieć postać pojedynczego pliku lub kilku plików. W obu przypadkach efekt
instalacji jest ten sam, jednak każde z rozwiązań ma swoje wady i zalety, o których powiemy teraz kilka
słów.

Jeden czy kilka plików?

Podstawową zaletą umieszczenia programu instalacyjnego w pojedynczym pliku jest wygoda – plik taki
łatwo jest umieścić np. na płycie CD-ROM. Z drugiej strony użycie tej metody utrudnia dystrybucję za
pomocą dyskietek, gdyż rozmiary plików instalacyjnych często przekraczają 1,44 megabajta. Rozbicie
programu instalacyjnego na kilka fragmentów niesie także ze sobą większe ryzyko zgubienia któregoś z

Komentarz:

pozwalam sobie

połączyć kolejne podpunkty w
całość

– w oryginale drugi jest

odwróceniem pierwszego (czyli
jest nadmiarowy), a poza tym
argumentacja podana przez autora
jest nonsensowna – uszkodzenie
jednego z kilku plików jest tak
samo groźne, jak uszkodzenie
jednego dużego pliku.

3

nich, co zwykle uniemożliwia poprawne zainstalowanie całości programu. Z drugiej strony warto
zauważyć, że uszkodzenie pojedynczego pliku może skutecznie uniemożliwić jakąkolwiek instalację
(nawet częściową), podczas gdy korzystając z kilku plików, można próbować wyeliminować
uszkodzony plik z procesu instalacji. Kilka mniejszych plików łatwiej też jest pobrać np. z Internetu.

Program Install Maker

Opracowany przez firmę ClickTeam program Install Maker jest dostępny w dwóch wersjach –
komercyjnej (odpłatnej) oraz bezpłatnej (freeware), uzupełniającej tworzony plik instalacyjny o
końcowe okno z reklamą producenta. Użytkownicy zainteresowani nabyciem wersji licencjonowanej
znajdą niezbędne informacje pod adresem http://www.clickteam.com.

Tworzenie instalatora za pomocą narzędzia Install Maker

Program Install Maker (w wersji freeware) można pobrać z witryny WWW firmy ClickTeam. Jest on
idealnym narzędziem do tworzenia prostych programów instalacyjnych, nie wymagających
manipulowania bardziej zaawansowanymi elementami systemu, jak sterowniki obsługujące dostęp do
baz danych lub rejestr systemowy (w razie konieczności skorzystania z bardziej złożonych funkcji
najlepiej użyć programu InstallShield). Install Maker wyróżnia się także dobrym współczynnikiem
kompresji, dzięki czemu tworzone przezeń pliki są stosunkowo niewielkie.

Przyjrzyjmy się zatem, w jaki sposób można utworzyć program instalacyjny za pomocą narzędzia
Install Maker. Kolejne etapy konstrukcji opiszemy poniżej.

1. Okno powitalne

Pierwszym oknem wyświetlanym po zainstalowaniu i uruchomieniu programu Install Maker jest okno
powitalne. Widoczne w dolnej części pole wyboru pozwala zrezygnować z usług kreatora i przejść
bezpośrednio do głównego okna programu. Nowicjuszom zaleca się raczej pozostanie w trybie kreatora,
który umożliwia łatwiejsze zapoznanie się z programem.

2. Ustalenie katalogu źródłowego

W kolejnym kroku należy określić położenie plików, które mają wejść w skład pakietu instalacyjnego.
Najlepszą metodą jest umieszczenie wszystkich plików w jednym katalogu (ewentualnie w jego
podkatalogach), np. MojaFirma\MojProgram. Install Maker odczytuje zawartość takiego katalogu
podczas kompilacji (zaznaczenie pola wyboru Include sub-directories nakazuje przeszukanie także
podkatalogów; opcja ta jest domyślnie włączona) i kompresuje ją do postaci jednego pliku
wykonywalnego. Uruchomienie tak utworzonego programu rozpakuje wszystkie pliki do zadanego
katalogu w komputerze docelowym.

3. Ustalenie tytułu aplikacji i języka programu instalacyjnego

Kolejne okno kreatora pozwala na wybranie języka programu instalacyjnego (ClickTeam jest firmą
francuską, dlatego też oprócz języka angielskiego mamy do wyboru także francuski). Drugim
parametrem ustalanym w tym kroku jest „długa” nazwa instalowanego programu, która będzie
wyświetlana podczas instalacji. Warto przy tej okazji zwrócić uwagę na przycisk

Preview (podgląd),

którego kliknięcie pozwala wyświetlić tworzone właśnie okno w postaci, w jakiej będzie je oglądał
użytkownik.

4. Definiowanie ustawień powłoki

Okno zatytułowane Shell (powłoka) pozwala wybrać plik, który będzie reprezentowany w postaci
ikony i polecenia w menu

Start|Programy, a także ustalić nazwę tego polecenia. Zaznaczenie pola

Komentarz:

wg oryginału

znajduje się on na płycie CD, ale
nic takiego na niej nie ma (jest
tylko PatchMaker). Na razie
usuwam odpowiedni fragment z
tłumaczenia (jeżeli wersja
freeware zostanie zamieszczona w
polskiej wersji, trzeba będzie o
tym wspomnieć).

Komentarz: wbrew
oryginałowi, w tym kroku nie
ustala się katalogu docelowego.

4

wyboru Add desktop shortcut nakazuje umieszczenie ikony skrótu na pulpicie, co jednak nie jest
zalecane, gdyż przyczynia się do jego zatłoczenia.

5. Informacje dodatkowe

Kolejne okno umożliwia wpisanie tekstu informacyjnego, wyświetlanego w trakcie instalowania
programu (np. umowa licencyjna, informacje o nowych elementach itp.). Tekstu nie da się co prawda
odczytać z pliku, jednak w razie potrzeby można wkleić do okna zawartość schowka skopiowaną np. z
okna Notatnika. Wklejony tekst należy także odpowiednio sformatować. Faktyczny wygląd okna
można w każdej chwili obejrzeć, klikając przycisk Preview.

6. Definiowanie ustawień ekranu i okna instalatora

W następnym etapie można zdecydować, czy program instalacyjny ma pracować jako zwykłe okno czy
w trybie pełnoekranowym. Znajdujące się w dolnej części pole edycyjne pozwala wpisać nazwę, która
w trybie pełnoekranowym będzie wyświetlana w lewym górnym rogu ekranu.

7. Wybór obrazków

Kolejne okno kreatora pozwala wybrać obrazek wyświetlany w lewej części okna programu
instalacyjnego oraz „tapetę” zastępującą standardowe gradientowe tło. Warto tu zachować
wstrzemięźliwość, gdyż dołączenie każdego pliku do programu instalacyjnego powoduje wzrost jego
rozmiarów. Nie jest to problemem, jeśli program ma zostać umieszczony na płycie CD-ROM, ale w
przypadku dystrybucji internetowej lub z wykorzystaniem dyskietek należy zadbać, by rozmiary
utworzonego pliku (lub plików) były jak najmniejsze – o ile oczywiście nie chcemy narażać się
użytkownikom.

Mapa bitowa wyświetlana w lewej części poszczególnych okien instalatora musi być zapisana w postaci
pliku BMP, mieć określone rozmiary (128 na 280 pikseli) i co najwyżej 256 kolorów. Wygląd okna po
wybraniu odpowiedniego pliku można podejrzeć, klikając przycisk Preview. Druga mapa bitowa
definiuje postać tła w przypadku pracy w trybie pełnoekranowym. Odpowiedni obrazek również musi
pochodzić z pliku BMP i zawierać nie więcej niż 256 kolorów, jednak jego rozmiary mogą być
dowolne, jest on bowiem układany sąsiadująco na całej powierzchni ekranu. Również i w tym
przypadku pomocny okazuje się przycisk Preview.

8. Ustalenie katalogu docelowego

Okno Installation directory umożliwia ustalenie domyślnej nazwy katalogu, w którym zostanie
zainstalowana aplikacja, np. C:\Program Files\FirmaKogucik\Kadry1.0. Kliknięcie przycisku Dalej
pozwala użytkownikowi zaakceptować wartość domyślną, zwalniając go z konieczności ustalania
docelowego katalogu aplikacji (oczywiście w razie potrzeby zawsze można to zrobić). Warto pamiętać,
że chociaż domyślna lokalizacja katalogu docelowego może być dowolna, użycie dysku innego niż C:
jest nieco ryzykowne (dysk ten jest obecny w praktycznie każdym systemie).

W razie potrzeby można też nakazać instalatorowi odczytanie nazwy katalogu docelowego z rejestru
lub pliku INI.

9. Zakończenie instalacji

Kolejne okno kreatora umożliwia określenie nazwy pliku, zawierającego istotne informacje (zwykle
Czytaj lub Readme) lub np. umowę licencyjną. Zawartość pliku jest wyświetlana w oknie Notatnika po
kliknięciu przycisku View…. Drugie z dostępnych na ekranie pól edycyjnych umożliwia podanie

5

nazwy programu uruchamianego po zakończeniu instalacji (zwykle jest to plik wykonywalny
instalowanej aplikacji)

1

.

10. Opcja dezinstalacji

Okno wyświetlane w kolejnym kroku zawiera tylko jedną opcję, której wybranie nakazuje kreatorowi
utworzenie programu dezinstalującego (ang. uninstall). Pole wyboru opcji jest domyślnie zaznaczone;
stanu tego najlepiej nie zmieniać, gdyż pozbawiłoby to użytkownika możliwości łatwego usunięcia
aplikacji z komputera.

Zaznaczenie pola wyboru Uninstall program powoduje utworzenie przez program instalacyjny małego
pliku wykonywalnego, którego uruchomienie automatycznie usuwa całą zainstalowaną aplikację.
Program dezinstalujący można uruchomić bezpośrednio (tj. przez kliknięcie jego ikony) lub pośrednio,
za pomocą apletu Dodaj/Usuń programy w Panelu sterowania.

11. Okno końcowe

Ostatnie z okien wyświetlanych przez kreatora również zawiera tylko jedną opcję, pozwalającą
wyłączyć kompilację pliku wynikowego instalatora. Jeśli informacje wprowadzone w poprzednich
krokach są poprawne, kliknięcie przycisku Dalej spowoduje utworzenie pliku programu instalacyjnego.
W razie wątpliwości zawsze można cofnąć się do poprzednich kroków, klikając przycisk Wstecz.

12. Kompilacja pliku wynikowego instalatora

Kliknięcie przycisku Dalej bez zaznaczania pola wyboru Do not build the Install program powoduje
wyświetlenie okna zapisania pliku, umożliwiającego ustalenie nazwy i lokalizacji tworzonego
programu instalacyjnego. Nie ma w tej kwestii żadnych ograniczeń, jednak należy pamiętać, by nie
umieszczać tworzonego pliku w katalogu zawierającym pliki źródłowe aplikacji – podczas ponownych
kompilacji powodowałoby to dołączanie pliku wykonywalnego instalatora do nowo tworzonych wersji.

Po utworzeniu pliku instalatora warto zapisać całość projektu (łącznie ze skryptem, zapisywanym w
pliku o rozszerzeniu .iit), co pozwoli na łatwe wprowadzanie poprawek i uaktualnień w przyszłości.

Do sprawdzenia działania nowo utworzonego programu najlepiej posłużyć się tą samą metodą, którą
zastosuje jego odbiorca, czyli uruchomić go z poziomu Eksploratora Windows. Po zakończeniu
testowania instalatora w systemie źródłowym należy zawsze sprawdzić jego działanie na innym
komputerze i upewnić się, że zainstalowana w ten sposób aplikacja będzie zachowywała się poprawnie.
W razie niepowodzenia wystarczy zmienić ustawienia skryptu i wykonać kolejny przebieg kompilacji i
testowania, pamiętając o uprzednim odinstalowaniu poprzedniej wersji.

13. Tworzenie dodatkowych skrótów w menu Start

Program instalacyjny zdefiniowany za pomocą kreatora można wzbogacić o funkcję tworzenia
dodatkowych skrótów w menu Start (oddzielną pozycję menu można np. utworzyć dla głównego pliku
pomocy aplikacji lub dokumentu Czytaj). Aby to uczynić, należy kliknąć zakładkę Files w głównym
oknie programu Install Maker i wybrać z listy plik, który ma zostać udostępniony w menu. W prawej
części okna, w polu File Options, znajduje się karta Start menu, zawierająca pola edycyjne Folder i
Name. Zawartość pierwszego z nich określa nazwę podmenu zawierającego dany skrót, zaś drugiego –
nazwę skrótu (polecenia) w podmenu.

1

Opcje te mogą nie działać prawidłowo w trybie testowania instalatora w programie Install Maker (wersja 1.2e).

Nazwy wpisywane w oba pola edycyjne muszą określać pliki istniejące w systemie źródłowym, dlatego też najlepiej
wybierać je za pomocą przycisków przeglądania – przyp. tłum.

6

Uwaga
Dodatkowe skróty najlepiej jest umieszczać w tym samym podmenu, co „główny” skrót do programu –
odpowiednią nazwę podmenu należy wpisać w polu Folder.

Dezinstalacja programu

Ponieważ nasza aplikacja może z różnych przyczyn nie znaleźć aprobaty użytkownika, wypadałoby
umożliwić mu łatwe, bezkonfliktowe i skuteczne usunięcie zainstalowanych plików (i innych
elementów programu) z komputera. Większość narzędzi tworzących programy instalacyjne, w tym
Install Maker, automatycznie dołącza odpowiednie składniki do tworzonego programu, co zwalnia nas z
zajmowania się szczegółami procesu dezinstalacji.

Powszechnie wiadomo, że wiele aplikacji nie potrafi odinstalować się całkowicie, dlatego też programy
„sprzątające”, jak np. CleanSweep, wciąż cieszą się popularnością. Nie zmienia to faktu, iż tworząc
program dezinstalatora należy w miarę możliwości zadbać, by aplikacja usuwana z systemu
użytkownika nie pozostawiła po sobie „bezpańskich” plików czy wpisów w rejestrze. Oczywistą
metodą sprawdzenia skuteczności dezinstalacji jest sporządzenie spisu wszystkich składników
instalowanych w systemie docelowym, zainstalowanie aplikacji, a następnie jej odinstalowanie i
sprawdzenie, czy wszystkie elementy zostały prawidłowo usunięte. Jakiekolwiek pozostałości powinny
wynikać co najwyżej z dodania przez użytkownika własnych plików i katalogów (zakładając, że
procedura dezinstalacji została wykonana i działa poprawnie). Automatyczne usunięcie wszystkich
plików jest praktycznie niemożliwe, bowiem program odinstalowujący „wie” tylko o komponentach
(plikach, wpisach do rejestru itp.) dodanych do systemu w czasie instalowania, nie śledzi natomiast
elementów utworzonych przez użytkownika w trakcie korzystania z aplikacji, a zatem nie może ich
usunąć. Efekt ten jest dość pospolity i przejawia się na ogół w wyświetleniu przez dezinstalator
komunikatu o niemożności usunięcia niektórych plików (komunikat Some elements could not be
removed). Przyczyną takiego stanu jest obecność w katalogu macierzystym aplikacji dodatkowych
plików, utworzonych poza kontrolą programu instalacyjnego (np. w wyniku działania samej aplikacji).
Może się także okazać, że któryś z zainstalowanych elementów powinien pozostać w systemie nawet po
usunięciu aplikacji, do której należy. Ma to miejsce głównie dla bibliotek dynamicznych, które mogą
okazać się niezbędne do poprawnej pracy systemu. W takiej sytuacji dezinstalator prosi zwykle
użytkownika o potwierdzenie zamiaru usunięcia pliku.

Install Maker nie jest jedynym dostępnym narzędziem do tworzenia programów instalacyjnych. Adresy
witryn internetowych kilku konkurencyjnych produktów podano poniżej.

Setup Factory – http://www.indigorose.com/

Inno Setup – http://www.jordanr.dhs.org/

Soysal Setup – http://www.soysal.com/ssetup

Wise Setup – http://www.wisesolutions.com/imakfeat.htm

Pliki CAB i INF

Pliki typu CAB oraz INF (plik informacji instalacyjnych, ang. information file) są popularnymi i
efektywnymi narzędziami dystrybucji oprogramowania oraz aplikacji internetowych. Ich ścisła
integracja z mechanizmami przeglądarki Microsoft Internet Explorer umożliwia automatyzację
procesów instalacji i kontroli wersji. Kilka kolejnych stron poświęcimy zatem tworzeniu plików CAB i
INF.

7

Pliki CAB

Nikogo nie trzeba przekonywać, że im mniejszy rozmiar pliku, tym łatwiej jest go przechowywać i
przesyłać. Remedium na przerośnięte pliki jest kompresja danych, polegająca z grubsza na wykrywaniu
pewnych regularności w sekwencjach bitów tworzących zawartość pliku i zastępowaniu takich
wzorców odpowiednimi kodami, zajmującymi znacznie mniej miejsca. Kompresję wykorzystuje
również opracowany przez firmę Microsoft format CAB (tzw. plik szafki, ang. cabinet file), oparty na
popularnym algorytmie Lempela-Ziva. W formacie CAB rozpowszechniany jest m.in. pakiet Microsoft
Office, a także sam system Windows (zobacz rysunek 18.1).

Rysunek 18.1. Pliki CAB zawierające system Microsoft Windows

W tym miejscu należałoby zadać sobie pytanie, czy i dlaczego warto używać akurat formatu CAB.
Oprócz skrócenia czasu przesyłania plików (co jest oczywistym celem stosowania kompresji), użycie
plików CAB jest obecnie najłatwiejszą metodą dystrybucji w Internecie komponentów ActiveX i klas
Javy. Programiści mają także do dyspozycji opracowany przez Microsoft pakiet Cabinet SDK, czyli
komplet narzędzi programowych obsługujących format CAB.

Uwaga
Jeden z elementów pakietu Cabinet SDK, program CABARC, wchodzi również w skład systemu
C++Builder. O pozostałe narzędzia należy niestety postarać się samemu, pobierając je np. ze strony
położonej pod adresem http://msdn.microsoft.com/workshop/management/cab/cabdl.asp.

Tworzenie i rozpakowywanie plików CAB

W skład pakietu Cabinet SDK wchodzą trzy programy narzędziowe, umieszczane w podkatalogu
CabSDK\Bin:

• EXTRACT.EXE – prosty program do rozpakowywania archiwów CAB;

• CABARC.EXE – prosty program do tworzenia, rozpakowywania i przeglądania archiwów;

• MAKECAB.EXE – zaawansowane narzędzie programowe, umożliwiające tworzenie,

konfigurowanie, rozpakowywanie, przeglądanie i zarządzanie plikami CAB w trybie wsadowym.

Jak widać, wachlarz możliwości jest dość szeroki, jednak tutaj ograniczymy się do programu CABARC,
zapewniającego wystarczający na nasze potrzeby zestaw funkcji (poza tym tylko on dostarczany jest
standardowo w pakiecie C++Builder).

Wykaz dostępnych funkcji najprościej uzyskać poprzez wydanie w oknie DOS-u polecenia

CABARC

.

Wywołanie programu ma ogólną postać

CABARC [opcje] polecenie plik-CAB [@lista] [pliki] [katalog]

zaś jego parametry zestawiono w tabeli 18.1.

Tabela 18.1. Parametry wywołania programu CABARC

Polece
nie

Znaczenie Przykład

l

Wyświetlenie zawartości pliku CAB

cabarc l test.cab

n

Utworzenie nowego pliku CAB

cabarc n test.cab *.c app.mak
*.h

x

Rozpakowanie (odtworzenie plików) pliku CAB

cabarc x test.cab prog*.c

Komentarz:

w oryginale jest

zrzut ekranu, którego cytowanie
nie ma sensu – każdy może sobie
go obejrzeć, a poza tym byłyby
kłopoty z tłumaczeniem. Zastępuję
zrzut tabelą opisującą polecenia i
opcje programu (uwaga – tabela
jest podzielona na dwie części).

UWAGA: pozostałe tabele
przenumerowuję o jeden w górę,
pozostałe wydruki
przenumerowuję o jeden w dół.

8

Opcja Znaczenie

Wartości

-c

Żądanie potwierdzenia dla poszczególnych plików

-o

Zastępowanie już istniejących plików bez
potwierdzenia (podczas odtwarzania)

-m

Wybór algorytmu kompresji

LZX:<15..21>

,

MSZIP

lub

NONE

domyślnie

MSZIP

-p

Zapisywanie pełnych ścieżek plików (dozwolone
tylko ścieżki względne)

-P

Usunięcie zadanego przedrostka z nazw plików

Przedrostek (np. nazwa katalogu)

-r

Przeszukanie katalogu wraz z podkatalogami
(podczas tworzenia archiwum, zob. też

-p

)

-s

Zarezerwowanie obszaru w pliku CAB na podpis
cyfrowy

Rozmiar obszaru, np.

6144

= 6 kB

-i

Ustalenie identyfikatora zestawu plików
(domyślnie zero)

Wartość identyfikatora

Umieszczenie na liście nazw plików znaku

+

(plus) podczas tworzenia archiwum (np.

cabarc n

test.cab *.c test.h + *.bmp

) wymusza spakowanie następujących po nim plików do nowego

katalogu. Nazwa katalogu docelowego podawana podczas rozpakowywania musi kończyć się lewym
ukośnikiem (np.

cabarc x test.cab prog*.cpp *.h d:\test\

). Wreszcie opcja

–P

(usunięcie

przedrostka) pozwala na usunięcie z nazw plików zadanego fragmentu ścieżki (np. polecenie

cabarc -

r -p -P projekty\ test.cab projekty\graf\*.*

usunie ze ścieżek fragment projekty\). Opcję

tę można wykorzystać kilkakrotnie do usunięcia kilku różnych fragmentów ścieżek.

Wskazówka
Źródłem informacji na temat narzędzi dostępnych w pakiecie Cabinet SDK oraz przykładów ich
użycia jest dokumentacja zawarta w podkatalogu Docs.

Tworzenie archiwów CAB (kompresja) i odtwarzanie ich zawartości (dekompresja) sprowadza się w
zasadzie do użycia odpowiednich parametrów wywołania programu CABARC. Na przykład do
spakowania wszystkich plików DLL zawartych w bieżącym katalogu służy polecenie:

cabarc n archiwum.cab *.dll

zaś aby rozpakować je do innego (istniejącego) katalogu, wystarczy wpisać:

cabarc x archiwum.cab *.dll c:\windows\system\

Ostrzeżenie
Rozpakowując archiwa CAB, należy pamiętać o zakończeniu nazwy katalogu docelowego lewym
ukośnikiem. Użycie w poprzednim przykładzie ścieżki c:\windows\system spowodowałoby

umieszczenie rozpakowanych plików w katalogu bieżącym.

Samorozpakowujące się pliki CAB

Jak widać, tworzenie plików CAB i ich rozpakowywanie jest w zasadzie banalne, o ile tylko mamy do
dyspozycji odpowiednie narzędzie (czyli program CABARC). Co jednak zrobić, gdy chcemy

9

rozpowszechnić zestaw plików w postaci archiwum CAB dostępnego poprzez Internet? Trudno w
końcu wymagać od użytkowników, by pobierali odpowiednie narzędzia ze stron Microsoftu, instalowali
je i uczyli się ich obsługi. Na szczęście istnieje inne rozwiązanie – wystarczy wyposażyć archiwum
CAB w możliwość samodzielnego rozpakowania. Nic prostszego:

copy /b extract.exe+archiwum.cab archiwum.exe

Uruchomienie tak utworzonego pliku archiwum.exe spowoduje automatyczne rozpakowanie zawartych
w nim plików.

Pliki INF

Pliki w formacie INF (ang. information file – plik informacji instalacyjnych lub skrypt instalacyjny) są
zwykłymi plikami tekstowymi, zawierającymi dyrektywy sterujące instalacją sterowników, programów
użytkowych, komponentów przeglądarek i innego oprogramowania. Zawartość pliku INF może być
bardzo złożona (np. instalacja obszernego zestawu sterowników) lub banalnie prosta (np. uzupełnienie
wpisu w rejestrze).

Struktura pliku INF przypomina znane użytkownikom Windows pliki INI. Treść pliku podzielona jest
na sekcje, te zaś zawierają dyrektywy zarządzające kopiowaniem plików, instalowaniem sterowników i
innymi operacjami. Omówieniu dyrektyw poświęcimy kolejny punkt.

Ostrzeżenie
Plików INF nie należy mylić z plikami INI. Co prawda oba rodzaje plików wykorzystują podobną
składnię, lecz przeznaczenie danych zawartych w plikach INI jest inne – definiują one informacje
konfiguracyjne, sterujące działaniem aplikacji.

Sekcje i dyrektywy w plikach INF

Sekcje pliku INF identyfikowane są nazwami, a kolejność ich zapisu nie ma znaczenia. Nazwa sekcji
zawarta jest w nawiasach kwadratowych i może zawierać do 28 znaków. Oto przykład:

[Strings]
Msg="Witamy"

Uwaga:
Wielkość liter w nazwie sekcji nie ma znaczenia. W przypadku wystąpienia w pliku kilku sekcji o tej
samej nazwie, ich zawartość łączona jest w jedną całość.

Najczęściej wykorzystywane w plikach INF nazwy sekcji i dyrektywy opisano w tabelach 18.2.i 18.3.

Tabela 18.2. Nazwy sekcji używane w plikach INF

Nazwa Przeznaczenie

zawartości

ClassInstall32

Instalowanie nowych klas urządzeń (zapis odpowiednich danych w
rejestrze)

ControlFlags

Sterowanie sposobem instalowania urządzenia za pomocą Kreatora
dodawania nowego sprzętu

DestinationDirs

Ustalanie docelowej lokalizacji kopiowanych plików

InterfaceInstall32

Instalowanie klas interfejsów urządzeń (zapis odpowiednich danych w
rejestrze)

Komentarz:

przenumerowuję

tabele o jeden w górę

Komentarz: brak opisu sekcji w
specyfikacji SDK/DDK

10

Manufacturer

Identyfikacja producenta urządzenia

SourceDisksFiles

Ustalanie źródłowej lokalizacji kopiowanych plików

SourceDisksNames

Ustalanie nazw identyfikujących dyski źródłowe

Strings

Definiowanie łańcuchów tekstowych używanych podczas instalacji (np.
dla różnych wersji językowych)

Tabela 18.3. Dyrektywy używane w plikach INF

Dyrektywa

Przeznaczenie

AddInterface

Instalowanie obsługi interfejsów urządzeń

AddReg

Modyfikowanie wpisów w rejestrze systemowym

AddService

Instalowanie usług systemowych

BitReg

Ustalanie wartości binarnych kluczy rejestru

CopyFiles

Kopiowanie plików z dysków instalacyjnych do katalogu docelowego

DelFiles

Usuwanie plików z katalogu docelowego

DelReg

Usuwanie wpisów z rejestru

DelService

Usuwanie usług systemowych

Ini2Reg

Kopiowanie wpisów konfiguracyjnych z plików INI do rejestru

LogConfig

Definiowanie sekcji pliku INF zawierających zestawy parametrów
konfiguracyjnych

RenFiles

Zmiana nazw plików w katalogu docelowym

UpdateIniFields

Definiowanie sekcji zawierających dyrektywy zmiany fragmentów
wpisów w plikach INI

UpdateInis

Definiowanie sekcji zawierających dyrektywy zmiany całych wpisów w
plikach INI

Przedstawione tu nazwy sekcji i dyrektywy to zaledwie fragment dostępnych możliwości. Szczegółowe
informacje na temat składni plików INF można znaleźć w dokumentacji pakietu Windows Driver
Development Kit (DDK), dostępnej pod adresem http://www.microsoft.com/ddk/.

Wskazówka
W plikach INF można także umieszczać komentarze. Komentarzem jest każdy ciąg znaków,
następujący po znaku średnika, o ile nie został ujęty w znaki cudzysłowu (").

Tworzenie plików INF

Spróbujmy obecnie utworzyć przykładowy plik INF (gotową postać pliku, test.inf, można znaleźć w
katalogu INF Files na dołączonej do książki płycie CD-ROM). Jak powiedzieliśmy wcześniej, plik INF
jest zwykłym plikiem tekstowym, toteż można go utworzyć za pomocą dowolnego edytora – w tym
także edytora kodu C++Buildera. Jeśli zdecydujesz się na użycie tej metody, uruchom IDE, wybierz

11

polecenie New z menu File i w oknie dialogowym New Items kliknij ikonę Text. Utworzony plik
zapisz pod nazwą test.inf.

Tworzony w naszym przykładzie plik powinien realizować następujące zadania:

• skopiować wszystkie pliki składowe aplikacji (w naszym przypadku program.exe i program.txt) do

katalogu Windows/;

• umieścić w rejestrze wpis, powodujący automatyczne uruchomienie programu program.exe

podczas uruchamiania systemu.

Jak zapewne wszyscy się już domyślają, do wykonania pierwszego etapu należy użyć dyrektywy

CopyFiles

. Jej składnia jest następująca:

CopyFiles=@nazwa-pliku | sekcja-nazw-plików[, sekcja-nazw-plików ...]

W celu skopiowania pojedynczego pliku wystarczy podać jego nazwę poprzedzoną znakiem

@

. Jeśli

mamy do czynienia z większą grupą plików, należy utworzyć w pliku INF nową sekcję, umieścić w niej
nazwy żądanych plików, a jej nazwę wpisać jako argument dyrektywy

CopyFiles

. Powinno to

wyglądać mniej więcej tak:

CopyFiles=Test.Copy
...

[Test.Copy]
Program.exe
Program.txt

Niestety, okazuje się, że brak tu jeszcze pewnej ważnej informacji – położenia katalogu źródłowego i
docelowego. Do określenia tych parametrów służą opisane w tabeli 18.1 dyrektywy

DestinationDirs

,

SourceDisksNames

i

SourceDisksFiles

.

[DestinationDirs]

Test.Copy=10
[SourceDisksNames]

1="Dysk instalacyjny 1",,,,
[SourceDisksFiles]
Program.exe=1

Program.txt=1

Uwaga
Do określenia lokalizacji katalogu docelowego można użyć jednej z predefiniowanych wartości, np.
24 (katalog główny dysku zawierającego katalog Windows), 11 (katalog System), 30 (katalog główny
dysku startowego) itd. W powyższym przykładzie użyto wartości 10, oznaczającej katalog Windows.
Opis poszczególnych wartości można znaleźć w dokumentacji DDK.

Na przykład w celu utworzenia na dysku startowym (zwykle C:) folderu o nazwie MojProgram
należałoby użyć zapisu:

Test.Copy=30,"MojProgram"

Aby nakazać automatyczne uruchomienie naszego programu wraz z rozpoczęciem pracy systemu
operacyjnego, należy dopisać ścieżkę do pliku program.exe do klucza rejestru

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

. Służy do tego

dyrektywa

AddReg

:

AddReg=sekcja-wpisów[, sekcja-wpisów ...]

gdzie sekcja-wpisów identyfikuje sekcję pliku INF o następującej postaci:

[sekcja-wpisów]
klucz-główny,[podklucz],[nazwa],[opcje],[wartość]

Parametr klucz-główny to skrótowy identyfikator jednego z głównych kluczy rejestru. Jego możliwe
wartości przedstawiono w tabeli 18.4.

Komentarz: w oryginale
Applications directory; podaję za
dokumentacją Windows DDK.

12

Tabela 18.4. Identyfikatory głównego klucza rejestru

Identyfikator

Klucz rejestru

HKCR

HKEY_CLASSES_ROOT

HKCU

HKEY_CURRENT_USER

HKLM

HKEY_LOCAL_MACHINE

HKU

HKEY_USERS

Parametry podklucz i nazwa uzupełniają klucz główny, określając wraz z nim dokładne położenie
modyfikowanego wpisu. Oto przykład zastosowania dyrektywy

AddReg

:

AddReg=Test.Reg

[Test.Reg]
HKLM,"Software\Microsoft\Windows\CurrentVersion\Run","ProgramTestowy",,"%10
%\Program.exe"

Warto zwrócić uwagę na zapis identyfikatora katalogu docelowego (

10

). Użycie znaków procentu

powoduje jego rozwinięcie do właściwej nazwy (w tym przypadku Windows).

Do kompletu brakuje jeszcze dwóch sekcji. Pierwsza,

[Version]

, zawiera sygnaturę platformy

docelowej. Domyślna wartość sygnatury,

$CHICAGO$

, oznacza system Windows 95 („Chicago” to jego

dawny kryptonim), co oczywiście nie wyklucza możliwości użycia skryptu w innych 32-bitowych
odmianach Windows (np. Windows NT). Druga sekcja,

DefaultInstall

, jest najważniejszym

elementem skryptu, bowiem to właśnie ona zawiera polecenia wykonywane w czasie instalacji. Pełną
zawartość przykładowego pliku INF przedstawiono na wydruku 18.1.

Wydruk 18.1. Kompletny skrypt instalacyjny TEST.INF

[Version]
Signature="$CHICAGO$"

[DefaultInstall]
AddReg=Test.Reg
CopyFiles=Test.Copy

[Test.Copy]
Program.exe
Program.txt

[DestinationDirs]
Test.Copy=10

[SourceDisksNames]
1="Dysk instalacyjny 1",Test,,,

[SourceDisksFiles]
Program.exe=1
Program.txt=1

[Test.Reg]
HKLM,"Software\Microsoft\Windows\CurrentVersion\Run","ProgramTestowy",,"%10
%\Program.exe"

Aby sprawdzić jego działanie, skopiuj go wraz z testowymi plikami PROGRAM.EXE i PROGRAM.TXT
na dyskietkę (lub do głównego katalogu dysku twardego, np. D:\). Kliknij ikonę pliku prawym
przyciskiem myszy i wybierz z menu kontekstowego polecenie Instaluj. Rysunek 18.2 przedstawia
zawartość rejestru po wykonaniu instalacji; jak widać, nazwa naszego programu została dopisana do
klucza

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

.

Rysunek 18.2. Zawartość rejestru uzupełniona o nowy wpis po wykonaniu instalacji

Komentarz: p

rzenumerowuję o

1 w dół, oryginalnego wydruku
29.1 już nie ma

13

Internetowe pakiety instalacyjne

Załóżmy, że właśnie napisaliśmy komponent ActiveX i chcielibyśmy udostępnić go przez Internet. Z
punktu widzenia użytkownika najwygodniej byłoby po prostu otworzyć odpowiednią stronę WWW i
pozwolić systemowi automatycznie zainstalować oprogramowanie. Możliwość taką dają internetowe
pakiety instalacyjne – rozwiązanie zaproponowane przez firmę Microsoft, łączące w sobie możliwości
archiwów CAB i skryptów instalacyjnych INF. Zasada działania pakietu jest prosta – wszystkie
elementy aplikacji pakowane są do postaci pliku (lub plików) CAB, zaś stowarzyszony z nim plik INF
zawiera polecenia informujące przeglądarkę o lokalizacji archiwów i sposobie instalowania ich
zawartości.

Uwaga
W chwili pisania książki internetowe pakiety instalacyjne obsługiwane były tylko przez przeglądarki
Internet Explorer w wersjach 3.0 i nowszych

.

Zasada działania pakietu internetowego

Dostępne w pakiecie C++Builder narzędzia dystrybucji internetowej (Web Deploy) i ich wykorzystanie
do dystrybucji komponentów ActiveX oraz formularzy omówiono już w rozdziale 22. Bogatsi o
wiedzę na temat plików CAB i INF, możemy obecnie wrócić do wspomnianych narzędzi i zastanowić
się nad zasadami działania pakietów internetowych. Jako przykład posłuży nam niewielki formularz
ActiveForm, przedstawiony na rysunku 29.3.

Bogatsi o wiedzę na temat plików CAB i INF, możemy obecnie zająć się narzędziami dystrybucji
internetowej (Web Deploy) i zastanowić się nad zasadami działania pakietów internetowych. Jako
przykład posłuży nam niewielki formularz ActiveForm, przedstawiony na rysunku 18.3.

Rysunek 18.3. Przykładowy formularz ActiveForm wyświetlany w przeglądarce Internet Explorer

W pierwszej kolejności zajmiemy się sposobem umieszczania zawartych w pakiecie komponentów
ActiveX na stronie WWW. Kod testowego dokumentu HTML wygenerowanego automatycznie
poleceniem Web Deploy przedstawiono na wydruku 18.2.

Wydruk 18.2. Dokument ActiveFormProj1.htm

<HTML>
<H1> C++Builder 5 ActiveX Test Page </H1><p>
You should see your C++Builder 5 forms or controls embedded in the form
below.
<HR><center><P>
<OBJECT

classid="clsid:EDE8CA15-4DC2-4E0D-95FE-F7974DAEFC42"

codebase="d:/temp/ActiveFormProj1.inf"

width=257

height=171

align=center

hspace=0

vspace=0

>
</OBJECT>
</HTML>

Komponenty ActiveX umieszcza się w dokumentach HTML za pomocą znacznika

OBJECT

. Oprócz

parametrów ustalających rozmiary i położenie komponentu posiada on dwa bardzo ważne atrybuty o

Komentarz:

Rozdział 22 jest na

CD – zakładam, że zostanie
przetłumaczony (jeśli nie, zdanie
trzeba będzie usunąć).

Komentarz: Ze względu na brak
rozdziału 22 przeredagowałem
cały akapit.

14

nazwach

CLASSID

i

CODEBASE

. Pierwszy z nich,

CLASSID

, określa identyfikator klasy użyty do

zarejestrowania obiektu (komponentu) w rejestrze Windows. Atrybut

CODEBASE

określa położenie

(oraz opcjonalnie wersję) pliku zawierającego kod obiektu.

Jak widać na wydruku 18.2, wartością atrybutu

CODEBASE

jest ścieżka do pliku INF. W razie potrzeby

można tu oczywiście używać innych plików – jeśli np. komponent nie wymaga instalowania żadnych
dodatkowych składników, atrybut

CODEBASE

może odwoływać się doń bezpośrednio:

codebase="C:\WINDOWS\Temp\ActiveFormProj1.ocx#version=1,0,0,0"

Jeszcze lepszym rozwiązaniem jest użycie w tym miejscu nazwy pliku CAB, zawierającego składniki
instalowanego komponentu (właściwy plik ActiveX, dodatkowe biblioteki itd.) oraz skrypt instalacyjny
INF. Oto przykład:

codebase="C:\WINDOWS\Temp\ActiveFormProj1.cab#version=1,0,0,0"

Gwoździem programu jest oczywiście plik INF (również generowany automatycznie), sterujący
procesem instalacji. Oto jego zawartość:

Wydruk 18.3. Plik ActiveFormProj1.inf

;C++Builder-generated INF file for ActiveFormProj1.ocx
[Add.Code]
ActiveFormProj1.ocx=ActiveFormProj1.ocx
VCL50.bpl=VCL50.bpl
[ActiveFormProj1.ocx]
file=D:/temp/ActiveFormProj1.cab
clsid={EDE8CA15-4DC2-4E0D-95FE-F7974DAEFC42}
RegisterServer=yes
FileVersion=1,0,0,0
[VCL50.bpl]
file=
FileVersion=5,0,6,18
DestDir=11

Jak widać, nie ma tu żadnych tajemnic. Cała zawartość pliku INF jest de facto wykazem instalowanych
plików, opisanych w oddzielnych sekcjach. Każda sekcja zawiera informację o położeniu
odpowiedniego pliku CAB, jego wersji oraz katalogu docelowym. Dla pliku VCL50.bpl identyfikator
katalogu docelowego wynosi 11, co, jak powiedziano wcześniej, oznacza katalog Windows\System.

Wersje, uaktualnienia i poprawki

W podrozdziale tym zajmiemy się zagadnieniami kontroli wersji oraz uaktualnieniami i poprawkami.
Pojęcia te wiążą się z modernizacją zainstalowanego oprogramowania oraz mechanizmami łatwego
aktualizowania aplikacji i usuwania wykrytych i poprawionych przez producenta błędów.

Kontrola wersji

Kontrola wersji (ang. version control) jest niezwykle istotnym elementem procesu projektowego.
Znajomość numeru wersji aplikacji daje użytkownikom orientację w jej możliwościach i ułatwia
dokonywanie aktualizacji. Jest ona również istotna w przypadku udzielania pomocy technicznej i
usuwania usterek – może się np. okazać, że wersja wykorzystywana przez użytkownika zawiera usterkę
usuniętą w wersji późniejszej lub nie dysponuje funkcją, którą wprowadzono w kolejnym wydaniu.

15

Kontrola wersji w praktyce

W najprostszym przypadku numer wersji aplikacji wystarczy po prostu wpisać w oknie wizytówki, co
jednak nie daje zbyt wielu możliwości (oprócz umożliwienia odczytania numeru wersji przez
użytkownika). Można też użyć w tym celu jednego z komponentów umożliwiających wyświetlenie
informacji o wersji na żądanie użytkownika, dostarczanych przez firmy trzecie.

Znacznie lepszym sposobem okazuje się wykorzystanie odpowiedniej funkcji samego C++Buildera. W
oknie opcji projektu, wyświetlanym poleceniem Options z menu Project, znajduje się karta Version
info, pozwalająca na zdefiniowanie informacji o wersji oraz umieszczenie jej w kodzie aplikacji.
Ustalany tu numer wersji składa się z czterech części – numeru głównego (ang. major version number),
pobocznego (minor version number), numeru wydania (release number) oraz numeru kolejnej
kompilacji (build number). Zaznaczenie pola wyboru Auto-increment build number pozwala ponadto
na automatyczną aktualizację ostatniego członu po każdej kompilacji. Pozostałe elementy karty
Version info umożliwiają wpisanie dodatkowych informacji o programie, jak: opis, nazwa firmy oraz
nota o prawach autorskich. Informacje te można znaleźć na karcie Wersja okna właściwości programu
(wyświetlanego poprzez kliknięcie ikony programu prawym przyciskiem myszy i wybranie z menu
polecenia Właściwości).

Ponieważ wyświetlenie okna właściwości programu wymaga nieco zachodu (wyszukanie ikony
programu w Eksploratorze i kilka kliknięć), można ułatwić użytkownikowi zadanie, umieszczając
numer wersji na wizytówce programu. W najprostszym przypadku robi się to ręcznie, wstawiając do
formularza wizytówki etykietę o treści np.

Uniwersalny Program do Wszystkiego
Wersja 1.1

Przed utworzeniem kolejnej wersji wystarczy zmienić drugi wiersz na

Wersja 1.2

i tak dalej

2

. Użycie

bardziej rozbudowanego numeru wersji pozwala na precyzyjniejsze określenie rodzaju dokonanej
zmiany. Jeśli np. w programie

Uniwersalny Program do Wszystkiego

Wersja 1.1.0.0

wykryjemy i usuniemy jakiś błąd, wystarczy zwiększyć o jeden ostatni element numeru wersji:

Uniwersalny Program do Wszystkiego
Wersja 1.1.0.1

Wprowadzenie takiego podziału pozwala łatwiej zapanować nad dokumentacją i nazewnictwem (co
oznacza mniejszy nakład pracy na tworzenie i aktualizację dokumentacji), a jednocześnie daje
użytkownikom dokładniejszą informację o programie (na przykład zmiana ostatniej cyfry oznacza
jedynie poprawkę, a nie wprowadzenie nowej funkcji).

Oprócz właściwego i konsekwentnego schematu numerowania bardzo istotnym elementem kontroli
wersji jest dziennik zmian. Na ogół wystarczy do tego celu zwykły plik tekstowy przechowywany w
katalogu macierzystym projektu i zawierający wpisy złożone z numeru wersji i opisu wprowadzonych
modyfikacji. Oto przykład:

1.1.0.0 Pierwsza wersja oficjalna
--------
1.1.0.1 Usunięcie błędu w wyświetlaniu nazwy pliku
--------

1.2.0.0 Zmiana logo programu

2

Operacja taka jest w praktyce dość uciążliwa, zwłaszcza jeśli numery wersji zmieniają się szybko. Warto

poświęcić nieco czasu na zaprogramowanie funkcji pobierającej numer wersji z zasobów aplikacji i wyświetlającej
ją w etykiecie w sposób automatyczny – przyp. tłum.

16

Solidny dziennik zmian, zawierający informacje o wszystkich dokonanych modyfikacjach i
poprawkach, pozwala w razie potrzeby odtworzyć historię projektu, nieoceniony zaś okazuje się w
przypadku dyskusji z użytkownikiem zgłaszającym błąd w działaniu aplikacji.

Uaktualnienia

Program komputerowy, jak większość wytworów nowoczesnej technologii, nie jest tworem statycznym
i podlega ciągłym modyfikacjom i rozszerzeniom. W niniejszym punkcie przedstawimy kilka sposobów
wprowadzania modyfikacji i rozpowszechniania zaktualizowanych wersji oprogramowania, czyli tzw.
uaktualnień (ang. update).

Co to jest uaktualnienie?

Z formalnego punktu widzenia jakakolwiek zmiana dokonana w aplikacji stanowi jej aktualizację. W
praktyce jednak nie każda aktualizacja dokonana wewnętrznie kwalifikuje się do upublicznienia w
postaci nowej wersji – może się okazać, że lepiej będzie poczekać na skumulowanie się kilku
modyfikacji i przekazać użytkownikom wersję oferującą więcej nowych możliwości. Z oczywistych
względów trudno tu podać jednoznaczne i oczywiste kryteria udostępniania zaktualizowanych wersji
oprogramowania; przykładem zmiany wymagającej możliwie natychmiastowej reakcji jest wykrycie i
usunięcie poważnego błędu, zanim przysporzy on kłopotów innym. Innym problemem, który należy
rozważyć, jest sposób powiadamiania użytkowników o dostępności uaktualnienia.

Powiadamianie o uaktualnieniach

W przypadku programów udostępnianych na zasadzie licencji shareware (lub rejestrowanych na drodze
elektronicznej) powiadamianie o uaktualnieniach jest stosunkowo proste, bowiem dane o
zarejestrowanych użytkownikach wystarczy na ogół pobrać z bazy rejestracyjnej i wykorzystać do
rozesłania powiadomień pocztą elektroniczną. To ostatnie zadanie można zrealizować za pomocą
wyspecjalizowanego programu lub komponentu, ewentualnie poprzez standardowy program do obsługi
poczty elektronicznej. Rozwiązanie pierwsze (na dłuższą metę prostsze i skuteczniejsze) sprowadza się
do utworzenia prostej bazy danych wyposażonej w komponent wysyłający pocztę elektroniczną i
umożliwiający grupową dystrybucję wiadomości. Przykładowa aplikacja może zawierać np. tabelę
klientów oraz drugą tabelę, zawierającą informacje o zarejestrowanych przez nich aplikacjach, datach
rejestracji, kodach dostępu itp. Do zredagowania tekstu wiadomości można wykorzystać komponent

TMemo

, zaś do ich wysyłania zatrudnić komponent

TSMTP

lub jeden z dostarczanych przez firmy trzecie

komponentów pozwalających przekazać wiadomość za pośrednictwem zewnętrznego programu do
obsługi poczty elektronicznej. Przykładem może tu być np. używany przez autora komponent autorstwa
firmy AHM Triton Tools (http://www.tritontools.com) lub liczne dostępne bezpłatnie komponenty
wykorzystujące zewnętrzne programy klientów MAPI lub SMTP, jak np. komponent

TEmail

, dostępny

pod adresem http://www.econos.de (w chwili wydawania polskiego przekładu nie był on dostępny w
wersji dla C++Buildera 5).

Sam proces rozesłania powiadomień sprowadza się do przeszukania tabeli klientów, pobrania adresów
poczty elektronicznej z poszczególnych rekordów, odczytania zawartości pola

TMemo

i wysłania tak

skomponowanych wiadomości. Gdyby to samo chcieć zrealizować „ręcznie”, należałoby wpisać adresy
poszczególnych klientów do pola

DW:

(

CC:

) lub też (co jest rozwiązaniem znacznie lepszym ze

względu na ochronę poszczególnych adresów przed oczami innych) pola

UDW:

(

BCC:

).

Alternatywną metodą wykorzystania poczty elektronicznej jest usługa ListBot (http://www.listbot.com)
lub jeden z pokrewnych serwisów, umożliwiających automatyczne rozsyłanie poczty do użytkowników
zarejestrowanych na liście dystrybucyjnej. Rozwiązanie to ma jednak tę wadę, iż zmusza użytkownika

Komentarz: nie mam pojęcia,
co autor miał na myśli pisząc „tab”
(pewnie interfejs użytkownika), ale
technicznie sprowadza się to do
dwóch tabel z danymi.

Komentarz: Nie ma
komponentu TEmail; jest TSMTP,
który robi mniej więcej to samo.

17

do dodatkowej rejestracji na liście prowadzonej w serwisie ListBot. Trzecim sposobem jest wreszcie
opublikowanie wiadomości o uaktualnieniu na widocznym miejscu firmowej witryny WWW (o ile taką
posiadamy). Również i tu jednak problemem pozostaje „pasywność” takiego rozwiązania – dopóki
klient nie zajrzy na naszą stronę, nie będzie miał pojęcia, że pojawiła się nowa wersja programu.
Jedynym w miarę pewnym sposobem dotarcia do każdego zarejestrowanego użytkownika jest
bezpośrednie wysłanie doń wiadomości.

Udostępnianie uaktualnień

Po dokonaniu odpowiednich zmian i ustaleniu sposobu dystrybucji należy wybrać formę, w jakiej
uaktualnienie zostanie przekazane użytkownikom. Może to być plik zawierający tylko poprawki, można
też udostępnić kompletny pakiet instalacyjny, zastępujący poprzednią wersję.

Poprawki czy wersja pełna?

Udostępnienie zaktualizowanej wersji aplikacji w postaci pełnego pakietu instalacyjnego okazuje się
często najlepszym rozwiązaniem. W takiej sytuacji należy zadbać, by pliki kopiowane podczas
instalacji zastąpiły poprzednie składniki, obecne już w systemie docelowym

3

.

Warto pamiętać, że odbiorca uaktualnienia ma już na ogół za sobą kontakt z poprzednią wersją
programu instalacyjnego, co zmniejsza nieco stres związany z obsługą nowej aplikacji. Jednym z
pospolitszych grzechów projektantów oprogramowania jest ignorowanie niewiedzy innych i zakładanie,
że przeciętny Kowalski wie o komputerach tyle samo, co autor programu. Dlatego też przygotowując
program instalacyjny, należy zawsze postawić się „po drugiej stronie barykady” i spojrzeć na swoje
dzieło oczami niedoświadczonego użytkownika.

Poprawki

Poprawki (ang. patch) stanowią alternatywną metodę aktualizowania oprogramowania. W odróżnieniu
od „pełnego” uaktualnienia użycie poprawki sprowadza się do programowego „nałożenia łat”, czyli
zmiany fragmentów jednego lub kilku plików bez naruszania istniejącej instalacji.

Utworzenie poprawki wymaga porównania pierwotnej wersji kodu wynikowego z wersją
zmodyfikowaną, a następnie zapisaniu różnic w pliku. Ostatnim etapem jest wygenerowanie skryptu
„nakładającego łaty”, czyli zmieniającego odpowiednie fragmenty kodu znajdującego się w systemie
docelowym.

Jednym z lepszych narzędzi służących do tworzenia poprawek jest Patch Maker wspomnianej już
wcześniej firmy ClickTeam. Jest on dostępny w dwóch wersjach, komercyjnej i freeware, przy czym tę
ostatnią można pobrać z witryny internetowej producenta (http://www.clickteam.com) lub skopiować z
dołączonej do książki płyty CD-ROM.

Tworzenie pliku poprawki

Po podjęciu decyzji o udostępnieniu nowej wersji w postaci poprawki należy przygotować odpowiedni
plik i przekazać go użytkownikom. Do utworzenia pliku poprawki z powodzeniem nadaje się wersja
freeware programu Patch Maker, którą omówimy za chwilę. Przygotowany w ten sposób program

3

Warto jednak pamiętać o drugiej stronie medalu: uaktualnienie rozprowadzane w postaci zestawu poprawek

zajmuje zwykle o wiele mniej miejsca (zamiast płyty CD-ROM może np. wystarczyć dyskietka, niebagatelne
znaczenie ma też skrócenie czasu transmisji pliku) – przyp. tłum.

Komentarz: w oryginale
niezrozumiały passus o ANSI code
(być może chodziło o ASCII, ale
nadal to jest nonsens)

18

najpierw sprawdza zgodność numerów wersji, a następnie modyfikuje fragmenty odpowiednich plików,
aktualizując je w ten sposób do nowej wersji. Kontrola wersji jest w tym przypadku szczególnie istotna,
gdyż (z dość oczywistych względów) poprawka daje się skutecznie (i bezpiecznie) zastosować tylko dla
wersji, dla której została przygotowana. Załóżmy np., że aplikacja dostępna jest w trzech kolejnych
wersjach:

1.0 – pierwsza wersja oficjalna,

1.1 – wersja poprawiona (poprzez usunięcie błędów),

1.2 – wersja zmodernizowana,

zaś poprawkę przygotowano w celu zaktualizowania wersji 1.1 do 1.2. Próba użycia jej dla programu w
wersji 1.0 zakończy się błędem i zaniechaniem aktualizacji, bowiem wprowadzenie modyfikacji
spowodowałoby najprawdopodobniej zmianę niewłaściwych fragmentów kodu.

Program Patch Maker

Po zainstalowaniu programu Patch Maker, a przed wygenerowaniem pliku poprawki, niezbędne jest
wykonanie kilku czynności przygotowawczych. Przede wszystkim należy utworzyć dwa oddzielne
katalogi, w których muszą znaleźć się odpowiednio oryginalny plik programu (wersja przed
modyfikacją) i plik poprawiony (wersja po modyfikacji). Etap ten jest konieczny, gdyż Patch Maker
wymaga istnienia obu katalogów w trakcie tworzenia pliku poprawki.

Co prawda Patch Maker jest w stanie utworzyć zbiór poprawek przeznaczony dla kilku plików, jednak
w praktyce rzadko modyfikuje się więcej niż jeden plik naraz. Dlatego też w naszym opisie
poprzestaniemy na przygotowaniu poprawki dla pojedynczego pliku (chociaż nic nie stoi na
przeszkodzie, by poeksperymentować na własną rękę).

Po utworzeniu nowej wersji aplikacji uruchom program Patch Maker. Na ekranie pojawi się okno
kreatora Patch Wizard.

1. Okno powitalne

Po uruchomieniu programu Patch Maker wyświetlane jest okno powitalne. Umożliwia ono
zrezygnowanie z usług kreatora i przejście bezpośrednio do głównego okna programu, jednak
nowicjuszom zaleca się pozostanie w trybie kreatora, który umożliwia łatwiejsze zapoznanie się z
podstawowymi funkcjami programu.

2. Ustalenie katalogów źródłowych

W kolejnym kroku określa się położenie katalogów, zawierających poprzednią wersję aplikacji (przed
zmianami) oraz wersję po modyfikacjach. Ponieważ w polach edycyjnych wpisuje się nazwy
katalogów, a nie pojedynczych plików, możliwe jest utworzenie zbioru poprawek dla więcej niż
jednego pliku. Widoczne w dolnej części okna pole wyboru Include sub-directories pozwala
przeszukiwać również podkatalogi. Ma to sens tylko w razie przetwarzania wielu plików, toteż w
naszym przypadku opcję tę należy wyłączyć.

3. Ustalenie tytułu aplikacji i języka programu instalacyjnego

Następne okno kreatora pozwala wybrać język programu instalującego poprawkę (angielski lub
francuski) oraz ustalić jego „długą” nazwę (będzie ona wyświetlana w głównym oknie programu, a
także w lewym górnym rogu ekranu, o ile nie zostanie zmieniona w kroku 5.). Zwykle używa się tu
nazwy modyfikowanego programu, uzupełnionej ewentualnie numerem wersji. Kliknięcie przycisku
Preview pozwala sprawdzić, jak będzie się prezentował ekran tworzonej aplikacji.

Komentarz: w tym kroku nie
ustala się katalogu docelowego!

19

4. Informacje dodatkowe

Okno wyświetlane w kolejnym kroku pozwala wpisać krótki tekst, zawierający np. informację o
wprowadzanych poprawkach. Tekstu nie da się co prawda odczytać z pliku, jednak w razie potrzeby
można wkleić do okna zawartość schowka. Po wpisaniu i sformatowaniu tekstu warto obejrzeć
końcowy wygląd okna, klikając przycisk Preview.

5. Definiowanie ustawień ekranu i okna instalatora

W następnym etapie ustala się wygląd ekranu roboczego programu (praca w zwykłym oknie lub
pełnoekranowa) oraz nazwę wyświetlaną w lewym górnym rogu ekranu.

6.

Wybór obrazków

Kolejne okno kreatora pozwala wybrać obrazek wyświetlany w lewej części okna programu
instalacyjnego oraz mapę bitową zastępującą standardowe tło w przypadku pracy pełnoekranowej.
Należy przy tym pamiętać, że użycie dodatkowych obrazków powiększa rozmiar tworzonego pliku.

Mapa bitowa wyświetlana w lewej części każdego z okien programu musi być zapisana w postaci pliku
BMP, mieć określone wymiary (128 na 280 pikseli) i co najwyżej 256 kolorów. Druga mapa, używana
jako „tapeta” w trybie pełnoekranowym, również musi pochodzić z pliku BMP i zawierać nie więcej niż
256 kolorów, może natomiast mieć dowolne wymiary, bowiem jest rozkładana na całej powierzchni
ekranu. Wygląd ekranu po wybraniu obrazków można podejrzeć, klikając przycisk Preview.

7. Ustalenie katalogu docelowego

Okno Installation directory umożliwia ustalenie lokalizacji modyfikowanego programu, tj. katalogu
zawierającego poprzednią wersję (np. C:\Program Files\Firma\JakisProgram). Należy pamiętać, że
plik poprawek musi znajdować się w tym samym katalogu, co modyfikowana aplikacja, w przeciwnym
razie nasz program nie będzie miał czego modyfikować i zakończy działanie z komunikatem

Nothing

to do

(Nie ma nic do zrobienia). Nie od rzeczy będzie także poinformowanie użytkownika o

wymaganej lokalizacji pliku.

W razie potrzeby można też nakazać instalatorowi odczytanie nazwy katalogu docelowego z rejestru
lub pliku INI. Kliknięcie przycisku Registry base wyświetla okno umożliwiające określenie
położenia danych w rejestrze, zaś przycisk INI file pozwala podać informacje lokalizujące nazwę
katalogu w wybranym pliku INI.

8. Ustawienia końcowe

Ostatnie okno kreatora zawiera tylko jedną opcję, której zaznaczenie zabrania utworzenia pliku
poprawek. Jeżeli wszystkie dane wprowadzone w poprzednich krokach są prawidłowe, nie pozostaje
nam nic innego, jak kliknąć przycisk Dalej i wygenerować plik. W razie wątpliwości można cofnąć się
do poprzednich kroków, klikając przycisk Wstecz.

9. Utworzenie pliku poprawek

Kliknięcie przycisku Dalej wyświetla okno zapisania pliku, umożliwiające podanie nazwy i lokalizacji
tworzonego pliku poprawek. Docelowa lokalizacja pliku może być dowolna, z jednym ograniczeniem –
nie należy umieszczać go w katalogach zawierających porównywane wersje aplikacji (ani ich
podkatalogach), bowiem może zostać wzięty pod uwagę przy tworzeniu kolejnych poprawek. Po
utworzeniu pliku warto zachować całość projektu (skrypt zapisywany jest w pliku o rozszerzeniu .uts)
na potrzeby przyszłych modyfikacji.

Aby sprawdzić działanie utworzonego programu, najlepiej uruchomić go tak, jak zrobi to użytkownik,
czyli np. z okna Eksploratora Windows, pamiętając przy tym, iż plik poprawek musi znajdować się w
tym samym katalogu, co modyfikowana aplikacja (położenie katalogu ustala się w kroku 7. kreatora).

Komentarz: w oryginale trochę
masło maślane, nieco zmieniłem.

20

Po „nałożeniu łat” należy oczywiście sprawdzić skuteczność tego procesu, uruchamiając poprawioną
aplikację. Jeśli efekty zmian nie są widoczne „gołym okiem” (modyfikacje polegają np. na usunięciu
błędu w obliczeniach), weryfikacji można dokonać poprzez sprawdzenie numeru wersji.

Wskazówki odnośnie uaktualnień i poprawek

Decydując się na udostępnienie uaktualnienia bądź poprawki, warto pamiętać o kilku praktycznych
wskazówkach.

• Pojawienie się nowej wersji należy anonsować możliwie jak najszerzej, np. za pomocą poczty

elektronicznej i informacji zamieszczonych na stronach WWW.

• Przekazując wiadomości pocztą elektroniczną, należy zachować umiar, bowiem zbyt częste i zbyt

obszerne listy mogą zostać uznane za niepożądaną reklamę (tzw. spam).

• Błędy w działaniu aplikacji należy usuwać jak najszybciej, a związane z tym uaktualnienia i

poprawki udostępniać natychmiast.

• Plików zawierających uaktualnienia i poprawki nie należy nigdy wysyłać pocztą elektroniczną

bezpośrednio do klientów, chyba że takie jest ich wyraźne życzenie.

• Mniej istotne zmiany i poprawki najlepiej skumulować w pojedynczym uaktualnieniu.

System kontroli wersji TeamSource

Wszelkie zmiany dokonywane w danych powodują utratę poprzednich informacji. Poszczególne wersje
kodu źródłowego można traktować jako „obrazy” pewnego zmiennego procesu (projektowania
aplikacji) uchwycone w określonych momentach. Mówiąc najprościej, systemy kontroli wersji
pozwalają na przechowywanie i zarządzanie obrazami stanu procesu projektowego. W terminologii
używanej w systemach kontroli wersji zapamiętanie takiego obrazu nosi nazwę umieszczenia projektu w
archiwum lub repozytorium (ang. checking in the archive).

Kod źródłowy – najcenniejsze dane każdego programisty – zmienia się w procesie projektowania
nieustannie. Zmiany te mogą przejawiać się w dodawaniu nowych elementów, jednak znacznie częściej
sprowadzają się do usuwania fragmentów kodu i zastępowania ich innymi, a to oznacza utratę
poprzednich zapisów. Właśnie w tym miejscu dochodzą do głosu systemy kontroli wersji,
umożliwiające zachowanie starszych wersji plików źródłowych i zarządzanie nimi. W tym podrozdziale
omówimy jeden z takich systemów – program TeamSource, wchodzący w skład pakietów C++Builder
Enterprise i Delphi, a także dostępny w postaci samodzielnej aplikacji. Chociaż TeamSource sprawdza
się najlepiej w połączeniu ze środowiskami programistycznymi firmy Borland (C++Builder i Delphi),
można go również stosować do zarządzania innymi projektami, które dają się zamknąć w obrębie
pojedynczego katalogu (i jego podkatalogów). Możliwości systemu TeamSource nie ograniczają się do
zarządzania plikami tekstowymi – pozwala on również nadzorować tworzenie dokumentacji zapisanej
w dokumentach Worda, witryn WWW złożonych z dokumentów HTML i plików graficznych (GIF,
JPG) i tak dalej.

21

Dla kogo przeznaczony jest TeamSource?

Jak sama nazwa wskazuje, system TeamSource został stworzony z myślą o zespołach projektowych
(ang. team). Nie oznacza to jednak, że nie mogą korzystać z niego również programiści pracujący w
pojedynkę.

Dlaczego używać TeamSource?

W najprostszym przypadku TeamSource umożliwia projektantowi aplikacji zachowanie całej historii
budowy projektu. Jaka stąd korzyść? Jeśli podczas pracy okaże się, że któraś z podjętych wcześniej
decyzji przyniosła niewłaściwe efekty, można będzie wrócić do momentu jej wdrożenia i skorygować
błąd. Daje to programiście większy komfort i swobodę podejmowania decyzji, minimalizując
konsekwencje błędów popełnionych w procesie projektowania. Przyczyną powrotu do starszej wersji
nie musi być zresztą błąd w planowaniu lub wykonaniu. Znacznie częściej okazuje się nią konieczność
powrotu do starszej wersji oprogramowania, wykorzystywanej przez użytkownika, który zgłasza
problemy z jego użytkowaniem, a jednocześnie z jakichś przyczyn nie chce lub nie może dokonać
aktualizacji.

Możliwości systemu TeamSource obejmują także zarządzanie kilkoma równoległymi wersjami tego
samego projektu. Przykładem może tu być sytuacja, w której różne komórki zespołu projektowego
pracują jednocześnie nad różnymi elementami tej samej aplikacji, np. aktualizacją struktury bazy
danych (poprzez dodanie tabel) i zarządzającego nią mechanizmu (poprzez migrację do architektury
klient-serwer). W przypadku „ręcznego” zarządzania projektem etapy te byłyby zapewne wykonywane
jeden po drugim, natomiast użycie systemu kontroli wersji, takiego jak TeamSource, pozwala
zrealizować je równocześnie i połączyć wyniki prac w jedną całość po ich dopracowaniu i
przetestowaniu.

Niektóre projekty oprogramowania okazują się być na tyle złożone i obszerne, że trzeba je podzielić na
elementy objęte niezależną kontrolą wersji. W skład projektu mogą np. wchodzić już dopracowane (a
przez to bardziej „statyczne”) biblioteki oraz kod nowych aplikacji, podlegający nieustannej
przebudowie i modyfikowany kilka razy dziennie.

Kiedy używać TeamSource?

Wykorzystanie systemu TeamSource powinno opierać się na przemyślanej strategii. W najprostszym
wypadku pliki wchodzące w skład projektu należy archiwizować raz dziennie, po zakończeniu pracy
nad nimi. Ponieważ dodawanie nowych elementów i funkcji zabiera zwykle więcej niż dzień,
rejestracja dat rozpoczęcia i zakończenia takich etapów pozwala stosunkowo łatwo powrócić do
poprzednich wersji.

Rozsądniejszą strategią jest zsynchronizowanie archiwizacji nie z kalendarzem, a z kolejnymi etapami
pracy nad projektem. „Etapem” nazywamy tu cały cykl zmian, mających na celu dodanie lub zmianę
określonej cechy aplikacji. Pojęcie „cechy” jest przy tym dość płynne i zwykle można je podzielić na
kilka poziomów hierarchii zadań, jednak dla konkretnych projektów, realizowanych przez konkretne
zespoły, daje się ono dość dobrze sprecyzować (na ogół pozwala to również na uściślenie
poszczególnych zadań w hierarchii).

22

Gdzie można używać TeamSource?

Oprogramowanie TeamSource może być wykorzystywane zarówno na pojedynczym komputerze, jak i
w sieci lokalnej. Można je z pewnym przybliżeniem traktować jako rozszerzenie narzędzia do
archiwizacji kodu źródłowego, co narzuca odpowiednie wymagania na lokalizację archiwów – powinny
one znajdować się na urządzeniu fizycznie wyodrębnionym i możliwie jak najbardziej odległym od
komputera używanego do pracy nad kodem. Rozdzielenie takie jest w systemie TeamSource jak
najbardziej możliwe.

O ile tylko prawidłowo opracujemy strategię archiwizowania plików, TeamSource może okazać się
znacznie skuteczniejszym narzędziem archiwizującym niż standardowo wykorzystywane systemy
tworzenia dziennych kopii zapasowych. W razie stwierdzenia błędu projektowego bardziej
prawdopodobna jest konieczność powrotu do wersji „przed dodaniem jakiejś funkcji”, aniżeli „sprzed
tygodnia”. Nie można oczywiście wykluczyć awarii katastrofalnych (np. uszkodzenia dysku serwera),
kiedy to zależy nam na odtworzeniu stanu projektu na etapie możliwie jak najbardziej zbliżonym do
momentu, w którym nastąpiła utrata danych. Jak widać, TeamSource jest czymś więcej niż tylko
alternatywą dla konwencjonalnych systemów tworzenia kopii zapasowych.

Jak używać TeamSource?

Podobnie jak sam C++Builder, system TeamSource opiera się na koncepcji projektów, przy czym za
projekt uznaje się tu zbiór plików zawartych w pojedynczym folderze (katalogu). Zależność od
lokalizacji jest w przypadku TeamSource bardziej ścisła, niż ma to miejsce dla C++Buildera – projekt
TeamSource może zawierać wyłącznie pliki zawarte w danym katalogu i jego podkatalogach, podczas
gdy C++Builder pozwala na dołączenie do projektu plików zewnętrznych (np. wspólnych dla kilku
projektów). Ograniczenie to może powodować konieczność reorganizacji struktury katalogów przed
wprowadzeniem kontroli wersji za pomocą systemu TeamSource.

Utworzenie projektu

Utworzenie projektu w systemie TeamSource wymaga większego wysiłku niż późniejsze nim
zarządzanie, jednak większy nakład pracy poświęcony na prawidłowe skonfigurowanie projektu
procentuje w późniejszym użytkowaniu, a to z kolei pozwala na ściślejszy i pełniejszy nadzór nad
realizowanymi projektami.

Przed rozpoczęciem pierwszej sesji TeamSource wymaga zidentyfikowania użytkownika poprzez
podanie nazwiska i adresu poczty elektronicznej. Po wprowadzeniu tych informacji można już
utworzyć nowy projekt za pomocą polecenia New Project z menu File. Wyświetla ono okno
dialogowe, pozwalające utworzyć projekt od podstaw lub zaimportować projekt już istniejący.

Importowanie istniejącego projektu

Projektanci pracujący w pojedynkę na ogół tworzą projekty samodzielnie, natomiast w pracy
zespołowej projekt tworzony jest przez jednego członka zespołu i udostępniany innym. Zaimportowanie
wcześniej utworzonego projektu sprowadza się do wybrania go w oknie otwarcia pliku i określenia
miejsca składowania go w systemie lokalnym (zobacz punkt „Ustalenie położenia katalogu lokalnego”
w dalszej części rozdziału). Po wykonaniu tych czynności następuje skopiowanie plików projektu do
katalogu lokalnego, którego zawartość będzie używana do aktualizacji projektu.

23

Tworzenie nowego projektu

Proces tworzenia nowego projektu składa się z następujących kroków:

• utworzenia projektu;

• określenia nazwy lokalnego katalogu projektu;

• zdefiniowania opcji projektu;

• przekazania projektu pozostałym członkom zespołu celem jego importowania.

Utworzenie projektu

Do utworzenia nowego projektu wykorzystywany jest kreator, realizujący tę procedurę w siedmiu
etapach. Opisane w poniższych punktach okna dialogowe pozwalają wprowadzić wszystkie informacje
definiujące postać projektu. Ich lista jest dość obszerna, ale wartości domyślne proponowane przez
kreator okazują się w wielu przypadkach wystarczające.

1. Opis tworzonego projektu. W kroku tym ustala się następujące informacje (wymagane):

• tytuł projektu (opisowy; można w nim używać znaków spacji);

• nazwę pliku projektu. Nazwa domyślna tworzona jest z tytułu poprzez usunięcie znaków

spacji; można ją dowolnie skracać i zmieniać, jednak nie należy dopisywać ścieżki, która
zostanie uzupełniona później;

• bibliotekę kontroli wersji. Domyślnie używana jest biblioteka Borland ZLib, jednak w razie

potrzeby można to zmienić.

2. Położenie głównego folderu projektu. Folder ten zawiera pliki projektu wykorzystywane przez

program TeamSource. Odpowiednią nazwę można wpisać z klawiatury lub ustalić, posługując się
przyciskiem przeglądania folderów (...). Folder główny powinien się na ogół znajdować na innym
komputerze (a przynajmniej na innym dysku) niż właściwy projekt C++Buildera. W przypadku
pracy w sieci lokalnej folder główny umieszcza się na ogół na serwerze.

Ostrzeżenie
Użytkownicy korzystający z folderu projektu muszą posiadać odpowiednie prawa dostępu.

3.

Położenie folderów podrzędnych. W skład głównego folderu projektu wchodzą foldery Archive

(archiwum poprzednich wersji), History (historia zapisów kolejnych wersji do archiwum) oraz
Locks (pliki blokad, zabraniające użytkownikom jednoczesnego modyfikowania plików projektu).
Podane tu nazwy domyślne można w razie potrzeby zmienić.

4. Katalog zapasowy (lustrzany) projektu. TeamSource umożliwia stworzenie aktualizowanej na

bieżąco kopii projektu, będącej dokładnym powieleniem wszystkich jego plików. Użycie tej opcji
wymaga zaznaczenia pola wyboru Enable Mirror tree i określenia katalogu, w którym zostanie
umieszczony folder z kopiami. Ten ostatni jest domyślnie lokowany w głównym folderze projektu,
ale warto zmienić to ustawienie, umieszczając kopie zapasowe na oddzielnym dysku lub innym
komputerze.

5. Ustawienia publikacji danych o stanie projektu. Kolejne okno pozwala określić nazwę pliku,

zawierającego komentarze do kolejnych wersji (ang. summary file), oraz pliku dziennika
aktualizacji (ang. check-in log file), zawierającego szczegółowe informacje o kolejnych wersjach
umieszczanych w archiwum (nazwa użytkownika dokonującego operacji, data operacji, lista

Komentarz:

zamieniam drugi

poziom wyliczenia na
wypunktowanie – kolejność
punktów nie ma w zasadzie
znaczenia, a ortograficznie jest
znacznie lepiej.

24

plików zapisywanych w archiwum, komentarze). Pole SMTP Server umożliwia określenie
serwera SMTP używanego do rozsyłania informacji o zmianach w projekcie drogą poczty
elektronicznej.

6. Adresy poczty elektronicznej. Jeśli w poprzednim kroku zdefiniowano nazwę serwera SMTP,

wyświetlane jest okno pozwalające na wprowadzenie adresów e-mail osób, które mają być
powiadamiane o zmianach w projekcie. Umieszczenie dowolnego elementu projektu w archiwum
może powodować rozesłanie do określonej grupy użytkowników następujących informacji:

• pliku komentarzy (zobacz punkt 5.);

• pliku dziennika aktualizacji (zobacz punkt 5.);

• listy zmodyfikowanych plików.

Adresatów wiadomości określa się poprzez wprowadzenie pojedynczych adresów lub ich list w
odpowiednich polach okna.

7. Zatwierdzenie konfiguracji. Ostatnie okno kreatora prezentuje podsumowanie wprowadzonych

danych i umożliwia ich zweryfikowanie. W razie konieczności wprowadzenia zmian wystarczy
powrócić do odpowiedniego kroku. Najistotniejszymi elementami, na które należy zwrócić uwagę,
są:

• nazwa projektu;

• położenie głównego folderu projektu;

• nazwa serwera SMTP;

• adresy poczty elektronicznej używane do rozsyłania powiadomień.

Innymi słowy, do utworzenia prawidłowego projektu wystarczy zdefiniowanie powyższych ustawień i
zaakceptowanie pozostałych wartości w postaci domyślnej. Programiści pracujący samodzielnie mogą
ponadto pominąć elementy związane z powiadomieniami, czyli nazwę serwera SMTP i adresy poczty
elektronicznej.

Ustalenie położenia katalogu lokalnego

Bezpośrednio po zakończeniu definiowania projektu TeamSource umożliwia określenie położenia
katalogu lokalnego, zawierającego kopie plików źródłowych. Krok ten można pominąć (klikając
przycisk Nie), jeśli np. pliki źródłowe znajdują się na innym komputerze (zobacz punkt „Katalogi
lokalne” w dalszej części rozdziału), jednak na ogół udziela się w tym miejscu odpowiedzi twierdzącej.
Powoduje to wyświetlenie okna służącego do zdefiniowania listy katalogów (poszczególne nazwy
można wpisywać z klawiatury lub ustalać za pomocą przycisku przeglądania

...). W przypadku

zdefiniowania kilku katalogów, kopie plików projektu są umieszczane w każdym z nich.

Kolejnym etapem jest uruchomienie kreatora zawartości (Content Wizard), pozwalającego ustalić
zawartość katalogów lokalnych. Również i tę operację można odłożyć na później, jednak na ogół
wykonuje się ją od razu. Kreator zawartości przegląda katalogi lokalne i wyświetla drzewo wszystkich
znajdujących się w nich plików i podkatalogów. Kliknięcie ikony podkatalogu rozwija odpowiednią
gałąź drzewa i wyświetla listę rozszerzeń nazw plików zawartych w danym podkatalogu. Lista ta
identyfikuje wszystkie pliki objęte kontrolą wersji i na ogół wymaga „przycięcia”, czyli usunięcia
rozszerzeń plików pośrednich (.obj, *.il*), kopii zapasowych (.~cpp) i innych plików o charakterze
tymczasowym (.tmp, .cgl itd.). Przycisk Delete Directory umożliwia usuwanie z drzewa całych
katalogów, o ile nie zawierają one potrzebnych plików.

25

Po skonfigurowaniu lokalnych i zdalnych elementów projektu można powrócić do głównego okna
programu TeamSource, prezentującego skrótowe zestawienie informacji o projekcie.

Opcje projektu

Użytkownik będący twórcą projektu, jest jednocześnie jego administratorem i posiada związane z tym
uprawnienia. Przed przystąpieniem do korzystania z projektu warto poświęcić nieco czasu na
zapoznanie się z opcjami sterującymi jego wykorzystaniem – o ile dla indywidualnego programisty jest
to przydatne, w pracy zespołowej staje się niezbędne. W tym ostatnim przypadku konieczne jest
ustalenie co najmniej jednej opcji – nazw użytkowników uprawnionych do korzystania z projektu.

Zmiana opcji projektu wymaga przede wszystkim jego zablokowania przez administratora (zobacz
punkt „Ustanowienie blokady” w dalszej części rozdziału), a następnie wybrania polecenia Options z
menu Project. Wyświetlone w ten sposób okno dialogowe zawiera cztery karty o nazwach General,
Directories, Users i Publishing.

Karta General

Elementy zawarte na karcie General pozwalają zmienić następujące parametry:

• Nazwę pliku zawierającego informacje o wersji. TeamSource może przechowywać numer wersji

projektu w specjalnym pliku, umieszczonym w głównym katalogu archiwum projektu.

• Tryb automatycznego wykrywania nowych katalogów lokalnych. Zaznaczenie pola wyboru Detect

new local directories nakazuje programowi TeamSource automatyczne sprawdzanie, czy w
lokalnym katalogu projektu nie pojawiły się nowe podkatalogi. Jeżeli przewiduje się taką
możliwość, a zawartość katalogów ma być wykluczona z kontroli wersji, opcję tę należy wyłączyć.

• Szczegółowość informacji wymaganych podczas umieszczania plików w archiwum. Zaznaczenie

pola wyboru Require summary comments pozwala używać zbiorczych opisów dla całych grup
plików, natomiast włączenie opcji Require file comments wymaga wprowadzania opisów dla
poszczególnych plików w grupie. Zaznaczenie obu opcji narzuca na osobę umieszczającą kod w
archiwum obowiązek utworzenia opisu zbiorczego oraz opisania poszczególnych archiwizowanych
plików.

• Początkowy numer wersji projektu. Możliwość ta jest szczególnie przydatna dla istniejących

projektów, dla których numeracja jest już prowadzona. Schemat numerowania wersji używany w
programie TeamSource jest identyczny ze stosowanym w C++Builderze – pełny numer wersji
składa się z: numeru głównego (np. 1), pobocznego (np. 3), numeru wydania (np. 23) i numeru
kolejnej kompilacji (np. 8), co w naszym przykładzie dałoby 1.3.23.8.

Karta Directories

Karta

Directories umożliwia zmianę położenia katalogów, zawierających pliki projektu (definiowane

w trzecim i czwartym oknie dialogowym kreatora projektu, zobacz punkt „Utworzenie projektu”
powyżej).

Karta Users

Karta Users zawiera listę użytkowników uprawnionych do dostępu do projektu. Przycisk Add User
pozwala na dopisanie do listy nowego użytkownika i ustalenie jego praw dostępu. Te ostatnie mogą
obejmować:

• dostęp tylko do odczytu (Read-Only) – użytkownik może pobierać pliki z archiwum, nie może

jednak modyfikować jego zawartości (w szczególności nie może umieszczać plików w archiwum);

26

• dostęp do odczytu i zapisu (Read-Write) – użytkownik może pobierać pliki z archiwum i je w nim

umieszczać;

• uprawnienia administratora – użytkownik może pobierać pliki z archiwum, modyfikować jego

zawartość oraz zmieniać opcje projektu (np. nadawać uprawnienia dostępu innym użytkownikom
za pomocą karty Users okna opcji). Nadanie uprawnień administratora wymaga uprzedniego
przydzielenia użytkownikowi prawa do odczytu i zapisu.

Wpisy na liście użytkowników można modyfikować (poprzez zmianę nazwy użytkownika i praw
dostępu) oraz usuwać, jednak użytkownik nie może zmienić wpisu dotyczącego jego samego.

Wskazówka
Nazwa użytkownika w systemie TeamSource jest identyczna z nazwą zarejestrowaną w Windows.

W dolnej części karty Users znajduje się pole wyboru zatytułowane Allow Guest Access to This
Project. Jego zaznaczenie udostępnia projekt wyłącznie do odczytu wszystkim użytkownikom. Warto
tu zauważyć, że w przypadku utworzenia projektu przez użytkownika anonimowego (co jest możliwe w
systemach Windows 9x), pełne uprawnienia administratora będzie miał każdy użytkownik, który nie
zaloguje się w systemie.

Karta Publishing

Opcje dostępne na karcie Publishing zarządzają powiadamianiem użytkowników o zapisywanych w
archiwum zmianach w projekcie. Ich znaczenie opisano podczas omawiania piątego i szóstego okna
kreatora projektu (zobacz punkt „Utworzenie projektu”).

Katalogi lokalne

Używana w terminologii systemu TeamSource nazwa „katalog lokalny” (local directory) odnosi się w
najprostszym przypadku do katalogu znajdującego się w lokalnym systemie plików i zawierającego
pliki źródłowe projektu C++Buildera. Okazuje się jednak, iż w bardziej złożonych okolicznościach
„katalog lokalny” może znajdować się na innym komputerze lub składać się z kilku katalogów.

Pierwszy przypadek dotyczy projektów opracowywanych przez kilka osób, korzystających z różnych
komputerów. Kierownik zespołu roboczego może np. utworzyć nowy projekt tylko dla celów
administracyjnych – pliki źródłowe będą rezydowały na komputerach poszczególnych programistów,
którzy w miarę postępów prac będą umieszczali kolejne wersje w archiwum. W takiej sytuacji jest
prawdopodobne, iż kierownik zrezygnuje z przechowywania poszczególnych projektów na swoim
komputerze, a tym samym nie będzie definiował położenia katalogu lokalnego.

Nazwa „katalog lokalny” może odnosić się również do całej grupy katalogów. TeamSource umożliwia
obsługę takich sytuacji, o ile wszystkie katalogi w grupie mają wspólny katalog główny, tj. należą do tej
samej gałęzi drzewa katalogów. Jeśli np. w skład projektu utworzonego w C++Builderze wchodzi
zawartość katalogów D:\programy\projekty\mailprog\form1.cpp i
D:\programy\biblioteki\internet\email.cpp, katalogiem lokalnym należy uczynić D:\programy\.
Ponieważ najprawdopodobniej zawiera on także inne podkatalogi, nie będące częścią naszego projektu,
należy usunąć je z drzewa wchodzącego w skład projektu TeamSource; podobnie należałoby uczynić z
elementami podkatalogu D:\programy\biblioteki\internet\ niezwiązanymi z projektem mailprog.
Operację tę należy wykonać w dwóch etapach – najpierw włączając do projektu wszystkie pliki, a
następnie usuwając niepotrzebne.

Alternatywnym rozwiązaniem mogłoby być utworzenie dwóch archiwów, zawierających odpowiednio
pliki projektu mailprog oraz biblioteki zawartej w katalogu internet. Rozwiązanie takie upraszcza
tworzenie samych projektów TeamSource, jednak utrudnia zarządzanie nimi. Załóżmy np., że
programista odpowiedzialny za projekt mailprog dokonał jego modyfikacji i umieścił nową wersję w

27

archiwum (czynność ta jest dość oczywista i trudna do przeoczenia). Jeśli jednak w trakcie modyfikacji
zlokalizowano i poprawiono niewielki błąd w pliku email.cpp, istnieje szansa, że aktualizacja drugiego
archiwum ujdzie uwadze programisty.

Ostrzeżenie
TeamSource umożliwia korzystanie z kilku równoległych katalogów lokalnych, przechowując w
każdym z nich pełną kopię archiwum projektu. Jeśli projekt aplikacji (utworzony w C++Builderze) jest
rozproszony w kilku katalogach, nie należy dodawać ich wszystkich do listy katalogów lokalnych.

Widoki projektu w programie TeamSource

Zawartość archiwum może być prezentowana na jeden z trzech sposobów, zwanych w terminologii
TeamSource widokami (ang. view). Odpowiadające im okna noszą nazwy:

Remote View (widok

archiwum), Local View (widok lokalny) oraz History View (widok historii). Jak można się domyślać z
nazw, widok archiwum przedstawia pliki zawarte w centralnym archiwum projektu; widok lokalny
obrazuje różnice pomiędzy zawartością archiwum a lokalną kopią projektu (pozwala to określić
zmiany, których należy dokonać w celu „zsynchronizowania” obu wersji); wreszcie widok historii
prezentuje zapis zmian dokonanych w zawartości archiwum.

Widok archiwum

W celu wyświetlenia widoku archiwum można nacisnąć klawisz F7, kliknąć ikonę widoku archiwum
(Remote View) w lewej części okna programu lub wydać polecenie Remote Project z menu View.
Widok archiwum wykorzystuje sposób prezentacji znany z Eksploratora Windows – obszar roboczy
okna podzielony jest na dwa panele, z których lewy zawiera drzewo folderów, zaś prawy – listę plików
opisanych numerami wersji i datami.

Zmiana właściwości folderu

Kliknięcie prawym przyciskiem myszy wybranego elementu drzewa folderów wyświetla menu
kontekstowe, umożliwiające przeglądanie ustawień wybranego folderu, a w przypadku posiadania
uprawnień administratora – również usuwanie, dodawanie i zmianę parametrów folderów. Okno
właściwości folderu, wyświetlane po wybraniu polecenia Properties, zawiera informacje
identyfikujące używany system kontroli wersji, listy rozszerzeń plików włączonych i wyłączonych z
projektu oraz tzw. reguły przetwarzania (ang. production rules). Te ostatnie informują system kontroli
wersji o zależnościach pomiędzy plikami źródłowymi i wynikowymi o tych samych nazwach (np.
reguła postaci

.cpp -> .obj

oznacza, że w wyniku skompilowania pliku o rozszerzeniu .cpp

powstaje plik pośredni o tej samej nazwie i rozszerzeniu .obj). Dzięki temu TeamSource „wie”, że
przechowywanie wersji określonych plików (w tym przypadku plików pośrednich) nie jest konieczne, o
ile tylko zachowa się odpowiednie pliki źródłowe. Niestety, reguły przetwarzania należy definiować
oddzielnie dla każdego folderu (TeamSource nie umożliwia zdefiniowania globalnego zestawu reguł
dla całego projektu).

Operacje na plikach

Kliknięcie prawym przyciskiem myszy nazwy pliku wyświetlanej w prawym panelu okna wyświetla
menu kontekstowe, umożliwiające wykonanie kilku operacji. Najczęściej wykorzystywane jest tu
polecenie Compare Revisions (porównanie wersji). Dostępne w menu polecenia przedstawiono
poniżej.

• View Tip Revision – wyświetlenie najnowszej wersji pliku;

28

• View Any Revision – wyświetlenie wybranej wersji pliku;

• Save Revision As – zapisanie wybranej wersji pliku na dysku;

• Delete

from

Project – usunięcie wszystkich wersji pliku z projektu (wymaga uprzedniego

ustanowienia blokady);

• View

Archive

Report – wyświetlenie informacji o umieszczeniu poszczególnych wersji w

archiwum (kiedy, przez kogo itd.);

• Compare

Revisions – porównanie dwóch wersji pliku. Po wybraniu porównywanych plików za

pomocą odpowiedniego okna dialogowego i kliknięciu OK program wyświetla wyniki porównania,
wyróżniając fragmenty dodane lub usunięte w stosunku do starszej wersji. Włączenie opcji Ignore
spaces in files during compares w oknie Preferences (polecenie Options|Preferences)
nakazuje pomijanie znaków spacji podczas porównywania.

Widok lokalny

Wyświetlenie widoku lokalnego następuje po naciśnięciu klawisza F8, kliknięciu ikony widoku
lokalnego (Local View) lub wybraniu polecenia Local Project z menu View. Okno programu
podzielone jest na dwa panele, zawierające sugerowany przez program wykaz plików przeznaczonych
do zmodyfikowania (po lewej stronie wyświetlana jest zawartość systemu lokalnego, po prawej –
archiwum).

Omawiany widok prezentuje archiwum z „lokalnego punktu widzenia” i jest prawdopodobnie
najczęściej używaną przez programistów metodą przeglądania projektu. Umożliwia on umieszczenie w
archiwum lokalnie zmodyfikowanych elementów projektu, znajdujących się w lewym panelu, a także
aktualizację kopii lokalnej poprzez skopiowanie z prawego panelu elementów zmodyfikowanych przez
innych programistów. W polu

Action opisu każdego pliku znajduje się opis czynności, którą

TeamSource sugeruje dla zachowania aktualności archiwum. Jeśli np. zawartość lokalnej kopii danego
pliku uległa zmianie, w kolumnie Action prawego panelu pojawi się tekst Check in, zalecający
umieszczenie nowej wersji pliku w archiwum.

Wykorzystanie widoku lokalnego do zapisywania plików w archiwum

Najczęściej stosowaną w praktyce funkcją programu TeamSource jest umieszczanie plików w
archiwum. W odróżnieniu od innych programów realizujących zarządzanie wersjami, TeamSource nie
wymaga każdorazowego blokowania plików i pobierania ich z archiwum – programista może dokonać
zmian na własnej, lokalnej kopii i przekazać ją do archiwum później. Przebieg typowej operacji zapisu
plików wygląda następująco: po wyświetleniu widoku lokalnego i ustaleniu, które pliki mają być
umieszczone w archiwum (pliki takie oznaczone są w prawym panelu tekstem Check in) należy
ustanowić blokadę, zaznaczyć odpowiednie pliki i kliknąć przycisk Do it! (wykonaj). Jeśli
umieszczenie pliku wymaga uzupełnienia komentarza, odpowiedniego wpisu w pliku można dokonać
przed wprowadzeniem zmian w oknie

Check In Comment, wyświetlanym kliknięciem przycisku

Comment.

Operacje na plikach w widoku lokalnym

W kolumnach Action obu paneli widoku lokalnego wyświetlane są opisy i ikony operacji, których
wykonanie jest zalecane dla zachowania aktualności archiwum (lub kopii lokalnej). Zalecenia dla
lokalnych kopii plików prezentowane są w prawym panelu, zaś dla kopii znajdujących się w archiwum
– w lewym panelu okna. Pliki nie wymagające żadnej akcji nie są wyświetlane.

Zalecenia oparte są na podstawie porównania znaczników czasu oraz numerów wersji plików
lokalnych, ich zarchiwizowanych odpowiedników oraz wersji bazowych. Jak powiedziano wcześniej,

29

wersje lokalne znajdują się w systemie plików komputera lokalnego (używanego przez daną osobę), zaś
wersje zarchiwizowane rezydują w archiwum zarządzanym przez system TeamSource. Nazwa „wersje
bazowe” oznacza wersje plików aktualne w chwili ostatniej synchronizacji (umieszczenia w archiwum
lub pobrania z archiwum). Podczas każdorazowego umieszczenia pliku w archiwum system zapisuje
jego nazwę, numer wersji oraz datę i czas do specjalnego pliku o nazwie NazwaProjektu.tsl
(„NazwaProjektu” to nazwa odpowiedniego projektu TeamSource), umieszczonego w głównym
katalogu projektu.

Proponowana przez system operacja zależy od różnic pomiędzy obiema wersjami. Poszczególne
możliwości opisano krótko poniżej.

• Copy. Wersja zawarta w archiwum jest nowsza, co oznacza konieczność zaktualizowania kopii

lokalnej poprzez skopiowanie pliku z archiwum do katalogu lokalnego. Zastąpienie poprzedniej
wersji pliku wymaga potwierdzenia.

• Merge. Wersja zawarta w archiwum jest nowsza niż ostatnia umieszczona w nim wersja lokalna,

jednak ta ostatnia została zmodyfikowana od czasu ostatniego zapisania w archiwum. Standardowy
mechanizm zarządzania wersjami wykorzystywany w systemie TeamSource (biblioteka ZLib
firmy Borland) nie umożliwia automatycznego scalania plików, toteż odpowiednich aktualizacji
należy dokonać ręcznie. W przypadku użycia innego mechanizmu, np. PVCS, możliwe jest
automatyczne uaktualnienie kopii lokalnej.

• Merge by Hand. Automatyczne scalenie plików jest niemożliwe; operację tę trzeba wykonać

ręcznie.

• Correct by Hand. Stwierdzono nieprawidłowość uniemożliwiającą podanie jakiegokolwiek

zalecenia. W większości przypadków porównanie wersji lokalnych, zarchiwizowanych i bazowych
daje systemowi wystarczające przesłanki do określenia zalecanej czynności, jednak w pewnych
okolicznościach może się to okazać niemożliwe. Jeśli np. plik lokalny datowany jest na ostatni
wtorek, zaś wersje zarchiwizowana i bazowa noszą datę czwartkową, system nie będzie w stanie
podać żadnego zalecenia, gdyż kopia lokalna jest starsza od obu swoich odpowiedników, co może
oznaczać problemy z datą.

W przypadku pojawienia się zalecenia Correct by hand najlepiej jest wyświetlić informacje o
podejrzanym pliku, klikając go prawym przyciskiem myszy i wybierając z menu polecenie View
File Info. Pozwoli to zweryfikować znaczniki daty i czasu wersji lokalnej, zarchiwizowanej i
bazowej, co może ułatwić usunięcie problemu. Źródłem zaleceń Correct by hand są na ogół
czynniki zewnętrzne, jak np. przypadkowe skopiowanie poprzedniej wersji pliku do katalogu
lokalnego. Inną pospolitą przyczyną tego rodzaju błędów mogą być niezgodności w obsłudze czasu
przez poszczególne komputery wchodzące w skład sieci lokalnej. Sytuacja taka znana jest autorowi
z praktyki – wykorzystywana przez niego kopia lokalna zawierała kilka plików oznaczonych
komunikatem Correct by hand, natomiast na innym komputerze ten sam projekt zawierał ich
znacznie więcej. Winne okazało się ustawienie strefy czasowej – zegar komputera autora
ustawiony był na czas Wschodniego Wybrzeża (EST), zaś pozostałe stacje robocze
wykorzystywały prawidłowe ustawienie GMT.

• Delete. Plik został usunięty z projektu; aktualizacja wymaga usunięcia również kopii lokalnej.

• Remove. Plik został usunięty z katalogu lokalnego; aktualizacja wymaga usunięcia go z

archiwum.

• Touch. Data i czas modyfikacji pliku uległy zmianie, ale jego zawartość pozostała niezmieniona.

Konieczne jest uzgodnienie daty i czasu obu wersji.

30

Pozostałe operacje wykonywane w widoku lokalnym

Dostępne w widoku lokalnym menu kontekstowe zawiera kilka innych poleceń operujących na plikach.
Niektóre z nich dostępne są również poprzez klawisze skrótu. Polecenia menu kontekstowego opisano
krótko poniżej.

View Local Changes. Polecenie to wyświetla różnice pomiędzy lokalną kopią pliku a wersją bazową,
tj. najnowszą wersją pobraną z archiwum.

View All Changes. Polecenie to wyświetla różnice pomiędzy kopią lokalną a najnowszą wersją
znajdującą się w archiwum (wersją zarchiwizowaną).

View Remote Changes. Polecenie to wyświetla różnice pomiędzy wersją zarchiwizowaną i bazową.

View File Info. Polecenie to umożliwia porównanie znaczników daty i czasu oraz numerów wersji
lokalnej, zarchiwizowanej i bazowej.

Revert. Polecenie to zastępuje lokalną kopię pliku wersją pobraną z archiwum.

Change the Comments for the Selected File. Polecenie to umożliwia przejrzenie i zmodyfikowanie
komentarzy związanych z danym plikiem.

Change the Recommended Action for the File. Polecenie to pozwala wybrać dla danego pliku akcję
inną niż zalecana; najczęściej służy ono do zmiany operacji ręcznego scalenia plików (Merge by hand)
na kopiowanie (Copy) lub umieszczenie w archiwum (Check in).

Move Files from One Pane to the Other. Polecenie to przenosi plik do drugiego panelu;
wykorzystuje się je w razie konieczności wykonania operacji niedozwolonej w kontekście danego
panelu.

Widok historii

Podobnie jak poprzednio, również w widoku historii obszar roboczy okna programu podzielony jest na
dwa panele. W lewym panelu wyświetlany jest wykaz zapisów plików do archiwum (każda pozycja
opatrzona jest datą i godziną zapisu oraz nazwą użytkownika, który go dokonał). Prawy panel zawiera
szczegółowe informacje na temat wybranego zapisu (treść komentarza oraz listę umieszczonych w
archiwum plików).

Mechanizmy kontroli wersji

System TeamSource wykorzystuje standardowo opracowaną przez firmę Borland bibliotekę kontroli
wersji ZLib. Umożliwia on także bezpośrednie użycie mechanizmu PVCS firmy Merant, chociaż
teoretycznie jest w stanie korzystać z dowolnego mechanizmu kontroli wersji.

Do wyboru biblioteki implementującej konkretny mechanizm kontroli wersji wykorzystuje się
polecenie Controllers z menu Project. Sam plik biblioteki, noszący rozszerzenie .tsx (TeamSource
Extension), jest zwykłą biblioteką dynamiczną, zawierającą definicje odpowiednich funkcji oraz
interfejsów umożliwiających komunikację pomiędzy aplikacją TeamSource a właściwym
mechanizmem kontroli wersji.

Zakładki

Obsługa historii wersji w systemie TeamSource umożliwia definiowanie tzw. zakładek (ang.
bookmark). Utworzenie zakładki powoduje zapamiętanie bieżącego stanu wszystkich składników

31

projektu, „utrwalając” jego stan i umożliwiając łatwy powrót do niego w przyszłości. Użyteczność
zakładek przejawia się zwłaszcza w przypadku powiązania ich z opublikowanymi wersjami
oprogramowania. Łatwo wyobrazić sobie sytuację, w której klient korzystający ze starszej wersji
programu (opublikowanej np. rok temu) natrafia na problem i zgłasza go działowi pomocy technicznej.
Odwołanie się do zakładki (o ile ją stworzono) pozwala szybko odtworzyć pliki źródłowe wersji
używanej przez klienta, co bez wątpienia przyspiesza proces lokalizacji i usunięcia błędu.

W celu zdefiniowania zakładki należy wydać polecenie Bookmarks z menu Project. Powoduje to
wyświetlenie okna dialogowego, umożliwiającego tworzenie (

Add), modyfikowanie (Edit) i usuwanie

(Delete) zakładek. Utworzenie nowej zakładki sprowadza się do nadania jej nazwy i określenia zasięgu
za pomocą pól wyboru w grupie Scope. Zasięg lokalny (Local) oznacza, że zakładka będzie dostępna
tylko dla użytkownika, który ją utworzył; użycie zasięgu globalnego (Global) udostępnia ją wszystkim
użytkownikom projektu, wymaga jednak uprawnień administratora.

Odtwarzanie projektów z archiwum

W normalnym cyklu produkcyjnym zawartość katalogu lokalnego jest zwykle bardziej aktualna niż
zawartość archiwum, bowiem bieżące zmiany dotyczą zawartości plików lokalnych, a dopiero później
przenoszone są do archiwum. W niektórych przypadkach, np. gdy nad danym projektem pracuje kilka
osób lub w razie awarii (utrata plików zapisanych na komputerze lokalnym), może się jednak okazać,
że pliki przechowywane w archiwum są nowsze od kopii lokalnych. W takiej sytuacji może zajść
potrzeba odtworzenia całego projektu z archiwum (ang. pulling), czyli zwykłego skopiowania plików
na komputer lokalny.

Do odtworzenia projektu służy polecenie Pull To... z menu Project. Dostępna w oknie dialogowym
Pull opcja Fast Pull pozwala na pominięcie odtwarzania plików, których bardziej aktualne
odpowiedniki znajdują się już na komputerze docelowym. Jej wyłączenie powoduje bezwarunkowe
skopiowanie wszystkich plików z archiwum. Możliwe jest również odtworzenie wersji plików
określonych zakładką. W takiej sytuacji można się spodziewać, że niektóre (lub wszystkie) odtwarzane
pliki będą starsze niż wersje obecne na komputerze lokalnym, toteż przed wykonaniem operacji warto
zachować kopie bieżących plików, umieszczając je w archiwum.

Blokady

Zmiana zawartości archiwum przez któregoś z użytkowników projektu wymaga ustanowienia tzw.
blokady (ang. lock). Najczęstszym powodem blokowania archiwum jest aktualizacja zawartych w nim
plików; blokady wykorzystywane są również podczas definiowania i zmiany ustawień projektu przez
administratora.

W odróżnieniu od kilku innych systemów kontroli wersji, TeamSource nie umożliwia blokowania
wybranych plików, a jedynie całego archiwum. Ponadto zablokowanie archiwum konieczne jest tylko
na czas umieszczania w nim nowej wersji, nie zaś, jak w przypadku wielu innych systemów, na cały
czas przetwarzania danego pliku (od momentu pobrania go z archiwum aż do umieszczenia tam nowej
wersji).

Ustanowienie blokady

W celu zablokowania archiwum należy wydać polecenie Request Lock z menu Project lub nacisnąć
klawisz F4, a następnie podać orientacyjny czas trwania blokady (domyślnie wynosi on 5 minut).
Upłynięcie zadanego czasu nie oznacza usunięcia blokady, ale pozwala innym użytkownikom zgłaszać
żądania jej zniesienia. Posiadając uprawnienia administratora, można także ustanowić tzw. blokadę
administracyjną (ang. administrator lock), nie pozwalającą na zgłaszanie żądań usunięcia i możliwą do

32

utrzymania nawet po zakończeniu pracy systemu. Ustanawianą blokadę można wreszcie opatrzyć
komentarzem, wyjaśniającym jej przeznaczenie.

Żądanie zniesienia blokady

Lista blokad dla bieżącego projektu wyświetlana jest w dolnej części okna programu. Jej zawartość
stanowią blokady aktywne, oczekujące oraz zatwierdzane. Kliknięcie wybranej blokady prawym
przyciskiem myszy wyświetla menu kontekstowe, umożliwiające zwolnienie, przedłużenie lub zmianę
komentarza blokady, a także przekazanie jej oczekującemu użytkownikowi (Yield to) oraz żądanie
zniesienia blokady (polecenie Verify Current Lock).

Zgłoszenie żądania zniesienia blokady (ang. challenging a lock) przed upływem przydzielonego jej
czasu powoduje jedynie wyświetlenie ilości pozostałego czasu. Po upływie terminu ważności operacja
ta powoduje wyświetlenie okna proszącego właściciela blokady o jej przedłużenie lub zwolnienie.
Nieudzielenie odpowiedzi w czasie do dwóch minut powoduje automatyczne zniesienie blokady.

Program InstallShield Express

W ostatniej części rozdziału zajmiemy się dostarczanym w pakiecie C++Builder 5 programem
InstallShield Express, służącym do tworzenia programów instalacyjnych. Ilość miejsca nie pozwoli nam
co prawda omówić wszystkich jego aspektów, jednak przedstawione tu informacje powinny dać
Czytelnikom solidne podstawy do dalszej pracy. Podstawowe metody tworzenia programu
instalacyjnego są w większości przypadków takie same, jednak w razie potrzeby można skorzystać z
dodatkowych funkcji oferowanych przez program InstallShield, rozszerzając możliwości tworzonego
instalatora.

Instalacja programu InstallShield

InstallShield znany jest – przynajmniej z widzenia – wszystkim użytkownikom C++Buildera, wchodzi
on bowiem standardowo w skład wszystkich wersji pakietu C++Builder, począwszy od wersji 1.0. Aby
zainstalować go na komputerze, wystarczy umieścić płytę CD pakietu C++Builder 5 w napędzie CD-
ROM i poczekać na automatyczne uruchomienie programu instalacyjnego. Jeśli to nie nastąpi,
konieczne będzie przejście do folderu ISxpress na płycie CD i ręczne uruchomienie odpowiedniego
instalatora, czyli programu Setupex.exe.

Wersja programu InstallShield dostarczana w pakiecie C++Builder nie jest wersją pełną. Została ona
specjalnie przygotowana do współpracy z C++Builderem, a jednocześnie pozbawiona niektórych
funkcji dostępnych w wydaniu komercyjnym. Nie zmienia to faktu, iż posiada ona praktycznie
wszystkie funkcje niezbędne do tworzenia programów instalacyjnych dla dowolnych aplikacji.

Pierwsze kroki

Przed uruchomieniem programu InstallShield Express i rozpoczęciem budowy programu instalacyjnego
warto zastanowić się przez chwilę nad niektórymi aspektami procedury instalacyjnej. Jeżeli np. podczas
tworzenia aplikacji wybrano opcję konsolidatora Use Dynamic RTL (nakazującą dynamiczne
dołączanie standardowej biblioteki C++Buildera do kodu aplikacji), program instalacyjny będzie musiał
zawierać kod odpowiedniej biblioteki DLL. Dołączenie dodatkowych pakietów będzie konieczne także
w przypadku wybrania opcji Build with Runtime Packages. Przeoczenie któregoś z dodatkowych

33

plików może uniemożliwić uruchomienie aplikacji na komputerze użytkownika. Określenie sposobu
tworzenia kodu wynikowego bywa kłopotliwe – jawne włączenie wszystkich bibliotek do pliku
wykonywalnego powoduje znaczny wzrost jego rozmiaru, zaś użycie oddzielnych plików dołączanych
dynamicznie wiąże się z koniecznością ich dystrybucji (pominięcie któregoś składnika może
uniemożliwić działanie programu – przyp. tłum.). Dlatego też po zakończeniu prac nad właściwą
aplikacją należy dokładnie określić skład zestawu plików wymaganych do jej uruchomienia,
uzupełniając go o inne pliki pomocnicze, jak np. dokumentację elektroniczną, przykładowe dane itp.
Tak skonstruowany zestaw warto umieścić w oddzielnym katalogu, co pozwoli łatwo przygotować
program do dystrybucji.

Bezpośrednio po uruchomieniu InstallShield wyświetla okno dialogowe, umożliwiające utworzenie
nowego programu instalacyjnego lub załadowanie jednego z uprzednio stworzonych projektów. W
naszym przypadku utworzymy nowy projekt, wybierając opcję Create a new Setup Project. Kolejne
okno pozwala na ustalenie nazwy projektu i jego lokalizacji (nazwę katalogu zawierającego projekt
należy wpisać w polu

New subdirectory, co pozwoli oddzielić pliki projektu od innych danych).

Wpisanie odpowiednich danych i kliknięcie przycisku OK przenosi nas do głównego okna programu
InstallShield. Opcje kontrolujące zawartość i wygląd tworzonego programu zorganizowane są w postaci
listy czynności, „odhaczanych” w miarę wykonywania (stąd używana w programie nazwa Setup
Checklist). Główne okno programu i wyświetlaną w nim listę czynności przedstawiono na rysunku
18.4.

Rysunek 18.4. Główne okno programu i wyświetlana w nim lista czynności

Ustalenie wyglądu instalatora

Tworzenie programu instalacyjnego rozpoczyna się od ustalenia postaci, w jakiej będzie się on
prezentował użytkownikowi. Związane z tym opcje skupione są na liście pod nagłówkiem Set the
Visual Design.

Kliknięcie przycisku z ikoną strzałki położonego obok pozycji

Application Information wyświetla

okno dialogowe zawierające trzy karty. Pierwsza z nich, App Info, pozwala ustalić opisową nazwę
instalowanej aplikacji (będzie ona wyświetlana m.in. w oknie apletu Dodaj/Usuń programy).
Wybranie pliku wykonywalnego aplikacji (poprzez kliknięcie przycisku przeglądania położonego obok
pola Application Executable) powoduje automatyczne dodanie jego nazwy do grupy aplikacji
Program Files w oknie grup (Groups and Files) oraz umieszczenie ikony programu na karcie
General okna ustawień folderów ikon (Specify Folders and Icons). Odpowiednie ustawienia można
też zdefiniować oddzielnie.

Numer wersji aplikacji ustalany jest na podstawie informacji o wersji zawartej w zasobach pliku (a ta z
kolei definiowana jest w ustawieniach projektu C++Buildera). Numer ten pozwala zabezpieczyć się
przed przypadkowym zastąpieniem pliku programu przez starszą wersję. Pole Company pozwala na
wpisanie nazwy producenta programu. Nazwa ta nie jest tylko i wyłącznie ozdobnikiem – jest ona
używana do tworzenia ścieżek, opcji menu Start i niektórych wpisów w rejestrze, a także, co łatwo
zauważyć, domyślnej nazwy katalogu docelowego. Ten ostatni parametr nie musi nam odpowiadać,
toteż można rozważyć możliwość jego zmiany. Nie zaleca się przy tym usuwania z nazwy członu

<ProgramFilesDir>

, którego obecność nakazuje zainstalowanie programu w katalogu aplikacji

(Program Files) na komputerze użytkownika. Ponieważ katalog ten może znajdować się na dysku
innym niż C:, podczas instalacji użytkownik ma możliwość zmiany domyślnej lokalizacji katalogu
docelowego.

Zawartość karty Main Window określa wygląd ekranu programu instalacyjnego. Wyświetlany w
lewym górnym rogu ekranu tytuł aplikacji (w postaci tekstu lub mapy bitowej) określa się w polu

Main

Title, zaś logo producenta – w polu Logo Bitmap. Co prawda InstallShield dopuszcza użycie w obu

Komentarz: w oryginale
nonsens, tu nie ma mowy o
żadnym wyborze typu projektu.

34

przypadkach wyłącznie map 16-kolorowych, jednak w praktyce można zignorować to ograniczenie, o
ile tylko możemy założyć, że ustawienia ekranu wykorzystują paletę co najmniej 256 kolorów (co jest
praktycznie stuprocentowo bezpieczne – przyp. tłum.).

Karta Features zawiera tylko jedno pole wyboru, umożliwiające włączenie lub wyłączenie funkcji
automatycznej dezinstalacji programu. Jej omawianie wykracza poza ramy naszej dyskusji, toteż
domyślnego ustawienia (włączone) najlepiej po prostu nie zmieniać.

Opcje specyficzne dla C++Buildera 5

Kolejna grupa opcji, zatytułowana Specify InstallShield Objects for Borland C++Builder 5, pozwala
określić elementy specyficzne dla aplikacji tworzonych za pomocą C++Buildera w wersji 5. Karta
General wyświetlanego okna dialogowego zawiera listę składników programowych, z której należy
wybrać komponenty używane w danej aplikacji. W określeniu zawartości listy pomocne jest ustalenie
spisu plików wymaganych do pracy aplikacji (o czym mówiliśmy na stronie 32).

Zaznaczenie opcji BDE lub SQL Links wymaga wybrania także pozycji BDE Control Panel File. W
pierwszym przypadku najrozsądniejsze jest zresztą uzupełnienie tworzonego pliku o pełną instalację
systemu BDE, w przeciwnym razie bowiem ryzykujemy konflikt, jeśli w systemie docelowym znajdują
się już inne aplikacje bazodanowe. W takiej sytuacji po zaznaczeniu na liście opcji BDE należy kliknąć
przycisk Settings, co uruchomi kreator instalacji BDE, umożliwiający utworzenie odpowiednich
aliasów na potrzeby instalowanej aplikacji. Procedura tworzenia aliasów jest następująca:

1. Kliknij przycisk New i wpisz nazwę aliasu (dokładnie w tej postaci, w jakiej zdefiniowano ją na

komputerze źródłowym).

2. Zdefiniuj parametry konfiguracyjne wprowadzonych aliasów (ścieżki, typy, dodatkowe

parametry). Ze względów praktycznych pliki baz danych najlepiej umieszczać w podkatalogach
katalogu macierzystego aplikacji, co wymaga uzupełnienia podawanej tu ścieżki przedrostkiem

<INSTALLDIR>

. Na przykład jeśli pliki bazy przechowywane są w podkatalogu bazy katalogu

macierzystego aplikacji, należałoby użyć zapisu

<INSTALLDIR>\bazy

.

3. Kliknij przycisk Zakończ. Kreator wygeneruje polecenia, zmieniające odpowiednie wpisy w

rejestrze na komputerze docelowym i dołączy właściwe pliki do instalatora.

Pozostałe opcje dostępne na karcie General pozwalają dołączyć do pliku instalatora pakiety
wykorzystywane przez aplikację (wykorzystuje ona dynamiczne łączenie pakietów). Szczegółowe
informacje o dołączonych plikach znajdują się na karcie Advanced.

Wybór instalowanych składników i plików

Pliki wchodzące w skład instalatora podzielone są na „grupy tematyczne”, identyfikowane w projekcie
wewnętrznymi nazwami. Z oczywistych względów nazwy takie powinny być czytelne i adekwatne do
funkcji opisywanych elementów – innymi słowy użycie nazwy

B1

jest jak najbardziej możliwe, jednak

jej zrozumiałość za dwa miesiące może okazać się problematyczna. Warto podkreślić, że nazwy grup
nie są widoczne dla użytkownika.

Pliki zawarte w danej grupie są zawsze instalowane w określonym katalogu. Sposób aktualizacji plików
(istotny w przypadku obecności poprzednich wersji w systemie docelowym) można ustalić za pomocą
opcji grupy File update method, dostępnych w oknie właściwości grupy (przycisk Properties),
jednak najczęściej wykorzystuje się ustawienie domyślne (aktualizacja tylko starszych wersji).
Najważniejszą grupę stanowią pliki tworzące aplikację; pozostałe grupy mogą obejmować dodatkowe
składniki wybrane w poprzednim etapie. Utworzenia oddzielnej grupy wymagają także pliki baz danych

Komentarz:

uwaga, odsyłacz do

zakładki

Komentarz: w oryginale Next

35

(o ile mają zastosowanie w aplikacji), przy czym katalog docelowy dla grupy powinien być identyczny
z określonym w ustawieniach aliasów BDE (zobacz poprzedni podpunkt).

Pliki „systemowe”, tj. biblioteki DLL, komponenty ActiveX itp., umieszcza się zwykle w katalogu
Windows\System, symbolizowanym przez ciąg

<WINSYSDIR>

. Przy okazji warto jeszcze raz

zweryfikować kompletność zestawu dołączanych do projektu plików bibliotecznych.

Do umieszczania plików w odpowiednich grupach najprościej jest wykorzystać technikę „przeciągnij i
upuść”, przeciągając odpowiednie ikony wprost z okna Eksploratora Windows. Szybkie uruchomienie
tego ostatniego umożliwia przycisk Launch Explorer, dostępny na karcie Groups i będący miniaturową
kopią systemowej ikony Eksploratora (zobacz rysunek 18.5). Potem wystarczy już tylko odpowiednio
ułożyć okna na ekranie, wybrać właściwy folder i przeciągnąć pliki do właściwej grupy.

Rysunek 18.5. Karta Groups okna instalowanych składników – dwa spośród instalowanych plików
znajdą się grupie aplikacji, trzeci w grupie Dane

Aby utworzyć nową grupę, należy kliknąć przycisk

New Group, wpisać nazwę tworzonej grupy i

wybrać katalog docelowy lub zaakceptować lokalizację domyślną.

Opcje dostępne na karcie Components pozwalają na definiowanie grup składników umożliwiających
instalację wariantową. Zagadnienie to jest dość złożone i nie będziemy się nim tutaj zajmować.

Elementy interfejsu użytkownika

Wybranie z listy czynności pozycji Dialog Boxes wyświetla okno dialogowe, pozwalające określić
wygląd i zachowanie instalatora w trakcie pracy. Jest to zapewne najbardziej atrakcyjny etap
projektowania instalatora, a bogactwo możliwości pozwala projektantom rozwinąć swoją inwencję.
Nawet nie wdając się w definiowanie własnych okien dialogowych i obrazków, warto zadbać, by
wyświetlane informacje odpowiadały instalowanej aplikacji – domyślne wartości proponowane przez
program InstallShield mogą okazać się zbyt ogólnikowe lub w ogóle nieodpowiednie.

Przywitanie użytkownika atrakcyjną winietką (ang. welcome bitmap) bez wątpienia dodaje aplikacji
blasku, jednak odbywa się kosztem powiększenia objętości pliku, co w przypadku dystrybucji poprzez
Internet jest czynnikiem bardzo istotnym. Oczywiście jeśli zamierzamy rozprowadzać aplikację na
płytach CD-ROM, wielkość plików staje się zagadnieniem marginalnym i można bez problemu
pozwolić sobie na artystyczne szaleństwa.

Opcje Software License Agreement i Readme umożliwiają wyświetlenie okien zawierających treść
licencji oraz pliku z najważniejszymi informacjami (Readme lub Czytaj). Dystrybutorzy
oprogramowania klasy shareware i freeware zalecają przy tym, by treść umowy licencyjnej wyświetlać
nie tylko w programie instalacyjnym, ale także udostępniać w postaci oddzielnego dokumentu (np.
pliku tekstowego). Co prawda użytkownicy rzadko zadają sobie trud czytania umów licencyjnych i
plików Readme, jednak nie należy im tego dodatkowo utrudniać. Warto także pamiętać, że długość
wierszy tekstu wyświetlanego w obu wspomnianych oknach nie powinna przekraczać 65 znaków, w
przeciwnym przypadku sposób jego wyświetlenia może nie odpowiadać pierwotnej postaci. Może to
wymagać przeformatowania tekstu, np. za pomocą Notatnika (przy wyłączonej opcji zawijania
wierszy).

Kolejne dwie opcje, Choose Destination Location i Choose Database Location, pozwalają ustalić
położenie katalogów, zawierających pliki samej aplikacji, oraz wykorzystywanej przez nią bazy
danych. Opcje Setup Type i Custom Setup umożliwiają wyświetlenie okien dialogowych,
sterujących instalacją wariantową; stosuje się je tylko w przypadku wcześniejszego zdefiniowania grup
składników w oknie Specify Components and Files. Okno dialogowe Select Program Folder
pozwala użytkownikowi określić docelowe położenie ikon aplikacji. Wreszcie opcje Start Copying
Files i Progress Indicator pozwalają wyświetlić okno podsumowania (pozwalające na sprawdzenie

Komentarz:

W oryginale ten

akapit jest w następnym punkcie,
ale logicznie i fizycznie należy do
tego.

Komentarz: związek plików Zip
z tym wszystkim jest dość słaby;
nie mam pojęcia, o co mogło
autorowi chodzić? jest dobrze tak
jak napisano.

Komentarz: Z jakichś przyczyn
pominięto to w oryginale, a
pierwsze okno jest dość ważne

36

wybranych ustawień) oraz okno postępu, informujące o przebiegu procesu instalacji. Wygląd każdego
okna można podejrzeć, klikając przycisk Preview (wyświetlany na ekranie przykład nie uwzględnia co
prawda zmian wprowadzonych w projekcie, ale pozwala zorientować się w ogólnym układzie okna).

Atrakcyjnym sposobem przekazywania użytkownikom informacji o instalowanym programie i innych
produktach firmy są plansze reklamowe (ang. billboard), czyli obrazki przechowywane w sekwencyjnie
ponumerowanych plikach BMP (nazwa pliku składa się ze stałego przedrostka, np.

Setup

, oraz numeru

kolejnego, czyli np. setup1.bmp, setup2.bmp itd. – przyp. tłum.). Kolejne plansze wyświetlane są
automatycznie w trakcie instalacji. Decydując się na wykorzystanie tego mechanizmu, warto wziąć pod
uwagę dwa czynniki:

• Rozmiar pliku. Im więcej obrazków będziemy wyświetlać, tym większa będzie objętość

skompilowanego pliku instalatora.

• Czas trwania instalacji. W przypadku prostych aplikacji, dla których cała instalacja zajmuje kilka

do kilkunastu sekund, używanie plansz reklamowych mija się z celem – użytkownik nawet nie
zdąży ich przeczytać.

Ostatnie okno, Setup Complete, ma zastosowanie tylko w przypadku instalowania plików, których
poprawne zainstalowanie lub aktywacja wymagają ponownego uruchomienia komputera (np. biblioteki
dynamiczne, komponenty ActiveX).

Modyfikacja wpisów w rejestrze

Dwie pozycje skupione w grupie Make Registry Changes umożliwiają tworzenie lub modyfikowanie
wpisów w rejestrze, wymaganych do poprawnej pracy aplikacji. Mogą to być np. ustawienia domyślne
(wymagane podczas pierwszego uruchomienia), informacje o położeniu plików itd.

W celu zmiany określonego wpisu należy przede wszystkim zlokalizować klucz rejestru,
przechowujący odpowiedni parametr aplikacji (nazwa klucza i wartość parametru wynikają z
konstrukcji programu). W tym celu wystarczy wybrać odpowiednią pozycję drzewa wyświetlanego na
karcie

Registry – Keys, a następnie kliknąć przycisk Add Key i wpisać pełną nazwę klucza w polu

New Key. W naszym przypadku nazwą tą jest

CBUILDER\TEST\INSTALL

, zaś cały klucz to

oczywiście

HKEY_CURRENT_USER\CBUILDER\TEST\INSTALL

, co pokazano na rysunku 18.6.

Rysunek 18.6. Definiowanie nazwy klucza rejestru w oknie Make Registry Changes

Ewentualne pomyłki można skorygować, klikając przycisk Modify Key lub usuwając błędnie
utworzony klucz. Zaznaczenie pola wyboru Uninstall Key nakazuje automatyczne usunięcie klucza
podczas dezinstalacji programu.

Właściwą wartość wpisu ustala się na karcie Registry - Values po uprzednim wybraniu
odpowiadającego jej klucza. Kliknięcie przycisku Add Value wyświetla okno umożliwiające
zdefiniowanie nazwy i wartości wpisu oraz typu tej ostatniej (String – tekst; Binary – blok bajtów;
DWORD – podwójne słowo, podawane w zapisie szesnastkowym lub dziesiętnym). W większości
przypadków definiowane wartości są typu tekstowego, chociaż aplikacja może narzucać w tej kwestii
inne wymagania.

Ustawienia menu Start

Okno dialogowe Specify Folders and Icons pozwala na ustalenie parametrów uruchomienia i
wybranie ikon oraz folderów wykorzystywanych przez program. Wartości domyślne dla głównego
pliku wykonywalnego aplikacji ustalane są na podstawie informacji wprowadzonych w pierwszym
etapie projektowania (okno Set the Visual Design). Ikony pozostałych składników aplikacji

Komentarz: w oryginale jest
„DWORD He”, hm...

37

(wyświetlane w menu Start) muszą zostać dodane ręcznie. W tym celu należy kliknąć przycisk
przeglądania (...) znajdujący się obok pola Run Command (zobacz rysunek 18.7), wybrać z
wyświetlonego drzewa odpowiedni plik, wprowadzić ewentualne parametry jego wywołania (Run
parameters) oraz tekst opisu wyświetlanego w menu Start (Description) i na koniec kliknąć przycisk
Add Icon. Czynności te powtarza się dla każdego elementu aplikacji, który ma być reprezentowany w
menu Start. Warto pamiętać, że dla większości plików (np. dokumentów tekstowych, plików pomocy)
standardowe ikony zapewnia system operacyjny.

Rysunek 18.7. Definiowanie ikon składników aplikacji

Karta

Advanced pozwala na zdefiniowanie dodatkowych ustawień wybranego składnika aplikacji.

Opcje grupy Folder określają położenie skrótu; najczęściej wybierana jest opcja Programs Menu,
nakazująca umieszczenie skrótu w menu Start|Programy. Alternatywą jest użycie opcji Start Menu
(umieszczenie ikony bezpośrednio w menu Start) lub Desktop (na pulpicie). Tej ostatniej możliwości
warto używać z umiarem, chociaż umieszczenie ikony skrótu na pulpicie Windows ułatwia życie
początkującym użytkownikom. Pozostałe dwie opcje, Startup i Send To, pozwalają umieścić skrót w
menu Autostart (co powoduje automatyczne uruchomienie aplikacji w chwili rozpoczęcia pracy
systemu) lub w folderze

Wyślij do.

Pole Start in umożliwia określenie katalogu roboczego aplikacji. Do zatwierdzenia wprowadzonych
ustawień służy przycisk Modify Info.

Utworzenie pliku instalatora

Wybranie z listy pozycji Disk Builder wyświetla okno, umożliwiające skompilowanie całego projektu
do postaci pliku instalacyjnego (lub kilku plików). Pole Disk Size umożliwia wybranie rodzaju
nośnika, który posłuży do dystrybucji plików. Przykładowo, wybranie opcji 1.44 MB powoduje
wygenerowanie tzw. obrazów dyskietek instalacyjnych (zestawów plików mieszczących się na
pojedynczych dyskietkach) i zapisanie ich w oddzielnych folderach. Możliwe jest też spakowanie
wszystkich elementów do pojedynczego pliku przeznaczonego do dystrybucji na płytach CD-ROM.

Po wybraniu rodzaju nośnika pozostaje już tylko kliknąć przycisk Build. Raport z przebiegu kompilacji
wyświetlany jest w polu Feedback; w przypadku wystąpienia błędów wystarczy skorygować
odpowiedni element projektu i ponowić kompilację.

Ukończony projekt najlepiej zapisać na dysku, co pozwoli wrócić do niego w przyszłości, dokonać
zmian (np. uzupełnić o nowe pliki) i skompilować ponownie, przygotowując w ten sposób kolejną
wersję instalacyjną aplikacji.

Przeniesienie plików na nośnik

Ostatnie okno dialogowe programu InstallShield, wywoływane poleceniem Copy to Floppy, pozwala
skopiować utworzone obrazy dysków instalacyjnych na fizyczny nośnik, czyli dyskietki. W tym celu
należy wybrać docelowy napęd (lub ścieżkę sieciową) w polach grupy Destination

,

a następnie kliknąć

przycisk Copy All Disk Images. Warto zauważyć, że kopiowanie można też wykonać „ręcznie”, np. w
Eksploratorze Windows, przeciągając zawartość odpowiedniego katalogu na ikonę dyskietki (obrazy
dyskietek tworzone są już w poprzednim etapie). Przed kopiowaniem należy oczywiście zaopatrzyć się
w odpowiednią liczbę dyskietek i zaetykietować je.

Wersja programu InstallShield Express dostarczana w pakiecie C++Builder 5 nie pozwala na tworzenie
pojedynczych, samorozpakowujących się plików instalacyjnych. Funkcję tę zapewnia dostępne
odpłatnie narzędzie InstallShield Package for the Web (zobacz http://www.installshield.com).
Alternatywą jest użycie programu archiwizującego, jak np. PKZIP czy WinZip Self Extractor,
umożliwiającego utworzenie tzw. pliku SFX, czyli samorozpakowującego się archiwum,

Komentarz: tego nie ma w
oryginale, dlaczego? te informacje
są równie ważne, co opis
lokalizacji skrótu.

38

umożliwiającego uruchomienie wybranego pliku po zakończeniu rozpakowywania (należy pamiętać, że
pliki SFX utworzone za pomocą bezpłatnych wersji tych programów można rozpowszechniać
wyłącznie na zasadzie niekomercyjnej). Metoda ta jest praktycznie jedynym wyjściem w przypadku
dystrybucji internetowej, w której liczy się każdy bajt objętości pliku.

Testowanie programu instalacyjnego

Po utworzeniu programu instalacyjnego należy sprawdzić poprawność jego działania. Metoda używana
przez autora polega na uruchamianiu programu na komputerze źródłowym (na którym został
utworzony) i dokonywaniu ewentualnych zmian i poprawek aż do momentu uzyskania zadowalającego
efektu. Wprowadzanie wszelkich modyfikacji i ponowna kompilacja programu nie nastręcza większych
problemów, należy jedynie pamiętać o odinstalowaniu poprzedniej wersji przed kolejną instalacją.

Po osiągnięciu satysfakcjonujących wyników można już spróbować zainstalować program na innym
komputerze. W idealnym przypadku konfiguracja testowego systemu powinna być możliwie „czysta”,
tj. nie zawierać żadnych składników, mogących wpływać na działanie instalowanej aplikacji, co
zapewniłoby obiektywność testu. W praktyce jest to mało prawdopodobne, chociaż w przygotowanie
konfiguracji testowej warto włożyć nieco wysiłku.

Niepowodzenie instalacji testowej nie jest oczywiście niczym strasznym – w takiej sytuacji wystarczy
powrócić do komputera źródłowego, zmienić ustawienia będące źródłem problemu, ponownie
skompilować projekt i powtórzyć testowanie. Kilkakrotne powtórzenie takiego cyklu powinno
zaowocować usunięciem wszystkich usterek. Po udanym zainstalowaniu aplikacji można przystąpić do
bardziej wymagających testów, np. instalacji na innych dyskach i w innych folderach, instalowania
tylko wybranych składników itd. Ten etap testowania może okazać się czasochłonny, jednak lepiej
chyba włożyć nieco wysiłku w przygotowanie prawidłowo działającego programu, niż narażać się na
pretensje ze strony użytkowników, którym nie udało się zainstalować aplikacji mozolnie „ściągniętej” z
Internetu.

Praktyka czyni mistrza, a tworzenie programów instalacyjnych nie jest tu wyjątkiem. Dlatego też przed
stworzeniem pierwszego „prawdziwego” pakietu instalacyjnego najlepiej zapoznać się
wykorzystywanym narzędziem i nabrać nieco wprawy. Nabyte w ten sposób umiejętności z pewnością
zaprocentują w warunkach rzeczywistych projektów i związanych z nimi ograniczeń czasowych.

Podsumowanie

Zagadnienia poruszone w niniejszym i poprzednim rozdziale stanowią podstawy niezbędne do
opanowania zasad instalowania, dystrybucji, konserwacji i promocji oprogramowania. Mimo iż nasza
dyskusja osadzona była silnie w kontekście C++Buildera, przedstawione tu techniki stosują się w
równym stopniu do oprogramowania tworzonego za pomocą innych narzędzi. Ich właściwe stosowanie
może w znaczący sposób poprawić wydajność pracy i jakość tworzonych produktów, a co za tym idzie
– zadowolenie ich użytkowników.

W rozdziale tym omówiliśmy zasady instalowania i konserwacji oprogramowania oraz różne metody
tworzenia plików instalacyjnych, począwszy od konstrukcji plików CAB i INF, a skończywszy na
wyspecjalizowanych narzędziach – programach Install Maker firmy ClickTeam oraz InstallShield
Express. Kilka stron poświęciliśmy także kontroli wersji i realizującemu ją programowi TeamSource,
wchodzącemu w skład pakietu C++Builder 5 Enterprise.