H ogyan készítsünk

P ortable -t
T h i n s t a ll
segítségével
 | Bevezetés
Az alábbi néhány oldalon egy egyszerű példán keresztül fogom bemutatni a portable programok
készítését Thinstall segítségével, a teljesség igénye nélkül. Ahhoz, hogy magunk is jól működő,
biztonságos portable-ket készíthessünk, nem szükséges semmilyen speciális számítógépes tudás, így
remélhetőleg sokan képesek lesznek követni és hasznosítani az itt leírtakat.

Ha eljutottál addig, hogy ezeket a sorokat olvasod, valószínűleg tudod, mit értek portable alatt.
Olyan programokat, amelyek futnak telepítés nélkül, és beállításaikat megtartják számítógépről
számítógépre hordozva is. A legtöbb program nem ilyen, de sokat közülük portable-vá lehet alakítani.
Ennek egyik módja a thinstallálás, amely egy ősi magyar szó, jelentése: ”az Thinstall által USB
konformmá tenni”.

A Thinstall program forradalmasította a portable ”ipart”, ami eleinte csak néhány megszállott hobbija
volt, mára viszont nagyon sokan készítenek és használnak ilyen programokat mindennapjaikban, akár
munkához is. A régi stílusú, úgynevezett indító exés (launcher-es) portable programok egyetlen előnye
a hordozhatóság volt, illetve az, hogy nem kellett telepíteni, hanem egyből használható volt. Sokan
kezdtek el ilyen programokat gyártani, és egyre több lett azoknak a száma, akik ugyan működő portable-
ket készítettek, viszont semmit sem törődtek azzal, hogy közben mi történik a gazda számítógéppel.
Jobb esetben csak sok szemét maradt a számítógépen, de olyannal is találkoztam, ami olyannyira
megváltoztatta a rendszert, hogy utána nem indult a számítógép. Jómagam mindig is próbáltam
törekedni arra, hogy amennyire lehet, tiszta maradjon a számítógép a portable használata után is,
és arra is, hogy lehetőleg minden felhasználói beállítás a portable-vel együtt utazzon számítógépről
számítógépre. Ezt a nézetet sajnos kevesen osztották a régi motorosok közül, de egyre nőtt az igény
a tiszta, biztonságos verziókra.

A Thinstall színre lépésével mindez alapjaiban változott meg. Lehetővé vált olyan portable-k készítése,
amelyek egyáltalán nem, illetve elhanyagolható mértékben szemetelnek a gazda számítógépbe.
Ráadásul olyan programokat is hordozhatóvá lehetett vele változtatni, amely a régi módszerrel
gyakorlatilag nem (elméletileg igen, de a megvalósítás annyira körülményes lett volna, hogy egyszerűen
nem volt értelme). Nem csoda, hogy ezek után az emberek figyelme a Thinstall felé fordult, amely az
újabb verziók megjelenésével egyre inkább bizonyította, hogy a legmegfelelőbb eszköz a portable-k
terén.

Ha ezeket a sorokat olvasod, bizonyára eltökélt vagy, hogy megtanuld az alapvető lépéseket.
Kedvcsinálónak csak annyit, hogy meglehetősen egyszerű a Thinstall-lal dolgozni, alapvető számítógépes
tudás/jártasság elegendő hozzá. Azonban nem árt eldönteni, miért akarsz kiokosodni Thinstall terén.
Ha azért, hogy birtokolj minél több portable programot, akkor nem biztos, hogy szükséged van erre
a tudásra. A neten rengeteg helyen találsz thinstallált portable programokat, és mára már nagyon
nehéz olyan programot mondani, ami thinstallálható, és még valaki nem készítette el. Sajnos ez csak
az angol nyelvű programokra vonatkozik, ha a magyar valóságot nézzük, akkor siralmas a helyzet.
Csak néhány magyar program részesült még abban a megtiszteltetésben, hogy thinstallált állapotba
kerüljön. Biztos vagyok benne, hogy a helyzet hamarosan javulni fog, és remélem, ennek a leírásnak
is lesz egy csekély szerepe ebben a folyamatban.

Ha készen állsz a thinstall tudományának befogadására, nincs más dolgod, mint leülni és olvasni,
valamint követni a leírtakat. Az oldalak száma ne tévesszen meg; az iromány akár egy-két óra alatt
kivégezhető. Megpróbáltam mindent a legjobb tudásom szerint, szájbarágósan magyarázni, akár
többször is, ha úgy éreztem, erre van szükség. A könnyebb követhetőség érdekében minden szükséges
programot és fájlt megtalálsz a csomagban.

1
 | A Thinstall bemutatása
A Thinstall egy virtualizációs megoldás, amely lehetővé teszi,
hogy programokat különálló exe fájlba csomagoljunk, és az így
keletkező állományt felhasználó módban futtassuk (vagyis nem
kernel-módban). Ezzel lehetővé válik, hogy olyan programokat
futtassunk különböző számítógépeken, amelyekhez egyébként
rendszergazdai joggal kellene rendelkeznünk. Másik fontos
tulajdonsága a Thinstall-nak, hogy mindezt úgy teszi, hogy
nem változtatja meg a gazdaszámítógép fájlrendszerét, illetve
registry-jét. A portable (hordozható) programok szempontjából mindkét tulajdonság előnyös, hiszen
olyan számítógépen is tudjuk programokat használni, amelyeken nem rendelkezünk rendszergazdai
jogokkal (pl. netkávézó, iskola, stb.), és nem hagyunk magunk után nyomokat. Nyomokat természetesen
mindenféleképpen hagyunk magunk után, de ezek elhanyagolhatóak (pl. legutóbb használt programok
listája a registryben, stb.). Meg kell jegyezni, hogy egy thinstallált program tisztasága - a megfelelő
működésen kívül - nagymértékben attól függ, hogy a készítő mennyire figyelt a részletekre. Ezért
csak olyan programot thinstalláljunk, amelynek működését kellőképpen ismerjük.

A Thinstall működését úgy kell elképzelni, hogy minden olyan kérést, amit az adott program küld az
operációs rendszer felé, átirányítja fájlba. Így a program ugyanúgy működik, mintha telepítve lenne,
és minden úgy tűnik számára, mintha a szokásos módon lenne telepítve. A különbség annyi, hogy
a registryből kért adatokat a virtuális registryből kapja, és ugyanez a helyzet a fájlok esetében is.
Ezek a fájlok a Sandbox-ban tárolódnak, de erről majd később. Ez a tulajdonsága teszi lehetővé, hogy
érintetlenül hagyja a gazda számítógép rendszerét, és azt, hogy különböző adathordozókon (pl. USB
kulcs) használhassuk, több számítógépen is.

A thinstallálás folyamata nagyon egyszerűen:

• az aktuális fájlrendszer és registry vizsgálata, az aktuális állapot mentése fájlba

• thinstallálandó program telepítése
• a fájlrendszer és a registry újbóli vizsgálata, az új állapot mentése fájlba
• a telepítés előtti és utáni állapotok összehasonlítása
• a tapasztalt változások mentése (fájlok, registry kulcsok)
• a thinstallálandó program tulajdonságainak testreszabása
• thinstallált program összeállítása

Talán kicsit érthetetlennek tűnik egy-két lépés, de nem kell aggódni, ezek nagy részét a Thinstall
végzi. A felhasználó dolga igazából csak a telepítés, és a thinstallálandó program tulajdonságainak
testreszabása. Mindezekhez nem kell programozói tudás, csak némi ini fájl szerkesztgetés. Ha a
kezedbe került ez a leírás, biztos vagyok benne, hogy ez nem fog gondot okozni.

Terjedelmi és lustasági okokból kifolyólag csak a folyamat egyszerű leírására vállalkoztam. Akit
komolyabban érdekel a téma, és valamennyire tud angolul, annak erősen ajánlom a Thinstall súgójának
tanulmányozását, amelyben nagyon sok kérdésre megtalálhatja a választ. Ha mégsem találná, akkor
érdemes szétnézni a neten, mert egyre több helyen foglalkoznak a témával. A thinstall saját oldalát is
érdemes böngészgetni (http://thinstall.com/).

A https://thinstall.com/sales/demo.php oldalon több előregyártott thinstall programot tölthetünk le,

illetve demó videókat is megnézhetünk.

2
 | A Thinstall korlátai
Sajnos a Thinstall sem mindenható, bizonyos korlátokkal rendelkezik.

Driver (service) telepítést igénylő programok

Néhány program drivert telepít, amelynek emulálására a Thinstall nem képes. Ilyen pl. a Daemon
Tools, amely virtuális dvd meghajtót telepít a számítógépre. A service-ek esetében már több esély
van arra, hogy működni fog a programunk, de személyes tapasztalatom az, hogy általában nem
lesz használható a végeredmény. Ha egy program telepítés után újraindítást kér, és nem is hajlandó
működni újraindítás nélkül, akkor valószínű, hogy drivert (vagy service-t) telepített a gépünkre.

Hardverhez kötött licenc

Néhány program csak azon a hardveren (vagy hardverkombináción) hajlandó elindulni, amelyikre
telepítve lett. Ilyen pl. a 3d Studio Max, vagy a Soundforge. Ha átvisszük őket másik gépre, ott nem
fognak indulni, vagy visszaállnak próbaverziós módba. Ha találunk olyan ”okosságot” hozzájuk, amelyek
kiküszöbölik a hardver check-et, akkor tudunk belőle teljes értékű portable-t készíteni (Soundforge
9, vagy ABBYY Finereader 9 esetében pl.). A legtöbb esetben azonban erre nincs mód. Ilyenkor is
érdemes lehet Thinstall-lal egy portable verziót készíteni, és az aktivációs keygen-t a programmal
együtt magunkkal hordozni, mivel egyszerűbb egy aktiválási ceremóniát gyorsan lezavarni, mint
nulláról kezdve az installálást (ami után ugyanúgy kell az aktiválási ceremónia). Ez a megoldás nem
túl elegáns, de működik, és pár másodperc múlva már a saját igényeinkre szabott programkörnyezet
fogad bennünket, nem pedig a program alapállapotbeli környezete. Ráadásul olyan számítógépen is
tudjuk használni őket, ahol nincs lehetőségünk telepítésre.

Ez a két legfontosabb korlát, ami felmerülhet a Thinstall esetében. A harmadik az ára, amely
meglehetősen borsos: 4995 USD. Szerencsére erre a legkönnyebb megoldást találni.
Általában a programok fajtája határozza meg, hogy lehet-e, vagy egyáltalán érdemes-e portable-t
készíteni belőle, és azt is, hogy a Thinstall-e a legmegfelelőbb megoldás. Fájlkezelő esetében pl.
nem igazán ajánlom a Thinstall-t, mert gondot okozhat (és okoz is) az, hogy a Thinstall virtuális
fájlrendszerben ”gondolkodik” a valós helyett. Ugyanígy nem a legjobb a Thinstall a tömörítő
programokra sem (pl. WinRar), mert végeredményben azok is fájlkezelőnek tekinthetők. Nem nagyon
érdemes erőltetni a vírusirtókat és társaikat sem. Lehet, hogy az újabb Thinstall verziók az ilyen
programok esetében is használhatók lesznek, de addig inkább maradjunk a normális telepítésnél,
bármennyire is viszolygunk tőle.
Előfordul, hogy olyan programmal találkozunk, amelyik elvileg simán thinstallálható lenne, de mégsem
tudjuk ”működésre bírni”, mert a thinstallált verzió már induláskor lefagy, nem jól működik, stb. Sajnos
a thinstall újszerű megoldása sokszor nem várt problémákat hoz magával, így a végeredményt mindig
tüzetesebb tesztelésnek kell alávetni még akkor is, ha elsőre minden jónak tűnik. Ezt párválasztásnál
is tudom tanácsolni.

3
 | Sandbox
Ha erről a szóról egy játszótéri homokozó jut eszedbe, akkor
ki kell, hogy ábrándítsalak. A sandbox azt a mappát jelenti,
ahová a thinstallált programok beállításaikat mentik.

A thinstallált programok természetesen nem tudnak

önmagukba írni, ezért fájlokban tárolják a beállításaikat. A
beállítások mentése egy normális program esetében vagy
fájlokban történik, vagy a registryben, illetve általában
vegyesen. A thinstall a registry felé irányuló lekérdezéseket
és írásokat átirányítja fájlba, így a gazdaszámítógép registry-
je érintetlen marad. Ugyanez a helyzet a fájlok esetében is.
Ez az átirányított registry-fájl (illetve fájlok, lásd később), és
a működés során a program által létrehozott vagy módosított
fájlok egy külön mappában tárolódnak. Ezt nevezik sandbox-
nak. A thinstallált program induláskor megnézi, hogy
van-e a saját könyvtárában sandbox, és ha nincs, akkor a
”C:\Documents and Settings\FELHASZNÁLÓNÉV\Application
Data\” könyvtárban létrehoz egy ”Thinstall” mappát, és ide
fogja ezeket a fájlokat menteni. Ha talál a saját mappájában
egy ”Thinstall” mappát, akkor viszont abba fog dolgozni.

Készítéskor megadhatjuk, hogy automatikusan hozzon létre egy meghatározott nevű sandbox-ot egy
meghatározott helyen, de erről majd később.

A portable programok szempontjából ez szintén egy nagyon jó tulajdonság, hiszen a thinstallált

programjaink bármelyik számítógépen ugyanolyan beállításokkal fognak indulni, ahogy utoljára hagytuk
őket. Ez nem elhanyagolható dolog, gondoljunk csak bele egy levelezőkliens esetébe, amelyben több
email fiók is be van állítva. Nem lenne kellemes félórákat azzal tölteni minden új számítógépen, hogy
beállítsuk fiókjainkat, illetve testreszabjuk a levelezőkliens beállításait (nem beszélve arról, hogy
korábbi leveleinkkel mi történne).

4
 | A Thinstallálás előfeltételei
Van néhány feltétel, amelyeknek eleget kell tenni ahhoz, hogy a jól működjön a portable
programunk.

• tiszta Windows
Ez a legfontosabb feltétel, és most nem a MS legalizációs programjára gondolok. A gyakorlatban ez azt
jelenti, hogy egy ”szűz” Windows-t használjunk. Ezt többféleképpen is elérhetjük. Az egyik megoldás
a hagyományos ”visszaállítom az elmentett szűz rendszert”, amihez az kell, hogy rendelkezzünk
egy elmentett tiszta Windows-zal. Erre a célra nem ajánlom az XP beépített rendszervisszaállítóját,
sokkal inkább az Acronis TrueImage-t, vagy Ghost-ot. Ezekkel 5-10 perc alatt visszaállíthatjuk
rendszerünket. Az elmentett rendszer akkor a legjobb, ha azt közvetlenül a Windows telepítés után
készítettük. A lényeg az, hogy egy teljesen fapados operációs rendszer legyen előttünk, mert így tud
a Thinstall minden olyan változást észrevenni, amit az adott program telepítője végez a rendszerben.

A másik megoldás a virtualizáció, pl. vmware használata. Ezzel sokkal rugalmasabban tudunk
dolgozni, mert a virtuális operációs rendszert bármikor alapállapotba tudjuk tenni, megspórolva
így sok időt. Ez főleg tesztelésnél jön jól. A legtöbben szerintem ezt a megoldást választják. Hogy
melyik a jobb megoldás, az kérdéses. Találkoztam olyan esetekkel, amikor a vmware-es megoldás
használható eredményt produkált, míg a ”hús-vér” operációs rendszeren történt thinstallálás nem,
és ennek az ellenkezőjével is. Elvileg mindkét megoldás megfelelő, nagyon ritkán van ezzel gond.

Harmadik megoldásként szóba jöhetnek még azok a programok, amelyek újraindításkor, vagy
kijelentkezéskor alapállapotba állítják az operációs rendszert. Ilyen pl. a DeepFreeze, amit jómagam
sokat használtam. Aki idegenkedik a vmware-es megoldástól, annak tudom ajánlani ezt.

• rendelkezzünk mindennel, ami egy sikeres telepítéshez szükséges

Ebbe beletartozik a program telepítője, elegendő hely a merevlemezen, ”okosság”, stb. Azon a
meghajtón is elegendő hellyel kell rendelkeznünk, ahová menteni szeretnénk majd a projektet -
ehhez még egyszer annyi hely kell, mint a feltelepített program mérete. Ahhoz, hogy megfelelően
működő programot készítsünk, ismernünk kell a programot, annak működését, milyen fájlokban
tárolja a beállításait, milyen mappákra van szüksége működés közben, stb. Sok program esetében
érdemes néhány alapbeállítást megváltoztatni, hogy a kész portable már ezekkel a beállításokkal
induljon. A virtuális fájlrendszerben való fájlkezeléshez szükség van egy fájlkezelőre, amit
beleintegrálunk a csomagba.

• türelem
Ha valami nem sikerül elsőre, majd sikerülni fog másodszorra. Vagy harmadszorra. Vagy nem fog,
de ettől még nem kell ön- vagy számítógépgyilkos gondolatokat generálnunk.

Ha mindezek megvannak, indulhat a thinstallálás.

5
 | Az Atlantis 1.6.1.8 thinstallálása
Az Atlantis Word Processor egy egyszerű szövegszerkesztő, amit - ha minden jól megy - thinstallálni
fogunk. Lépésről lépésre fogunk haladni, illetve képről képre, a nagyothallók kedvéért.

SetupCapture
A Thinstall valójában nem egy program, hanem több program összefogó neve. Ha megnézitek a
Thinstall mappáját, látni fogjátok, hogy 9 exe is található benne. Ezek közül az egyik a SetupCapture.
exe, amely azért a folyamatért felelős, amely megfigyeli a telepítést, és rögzít minden változást,
amit a program telepítője a gépünkön végez. Fontos, hogy tiszta Windows-zal fogjunk hozzá, és ne
futtassunk semmilyen programot közben.

Miután elhelyezkedtünk jól fotelünkben, indítsuk el a SetupCapture.exe programot a Thinstall

könyvtárából. Ez a kép fogad bennünket, remélhetőleg:

Egy ilyen ablaknak kell előjönnie, csak zöld keret nélkül, mert az csupán a minimáldizájn része.
Kattintsunk a Start gombra.

6
Ebben az ablakban tudjuk megadni a Thinstall-nak, hogy melyik meghajtót vizsgálja meg. Ide azt
kell bejelölnünk, ahová telepíteni fogjuk a programot, illetve a registry ágakat is itt választhatjuk ki.
Mindent hagyjunk úgy, ahogy alapállapotban szerepelnek, és kattintsunk a Pre-Install Scan gombra.

Ezek után ez az ablak fogad bennünket, amely a rendszer vizsgálatának folyamatát mutatja.

7
Ha befejeződött a folyamat, ezt az ablakot kapjuk. Ebben az esetben nem kattintunk egyik gombra
sem, hanem a tálcára minimalizáljuk az ablakot. Innentől fogva bármi, amit másolunk (vagy telepítünk)
a C: meghajtóra, azt a Thinstall árgus szemmel figyelni fogja, és a folyamat végén összehasonlítja
azzal az állapottal, amit az első vizsgálatban talált. Ugyanez vonatkozik a registry-re is, tehát minden
változtatás feljegyzésre kerül.

A következő lépés az Atlantis telepítése. Ehhez indítsuk el a Files\Atlantis.Word.Processor.v1.6.1.8\

atlantis1618.exe fáljt, és a szokásos módon telepítsük. Egy kivétellel minden esetben változtatás nélkül
a Next gombra kell kattintani, ez pedig az az ablak, amikor a fáljasszociációkról kérdez bennünket:

8
Ebben az esetben vegyük ki a pipát mindenhonnan. Erre azért van szükség, mert ha a kész portable-t
szeretnénk asszociálni a programon belül, a változások valószínűleg nem a valós registryben, hanem
a virtuálisban történnének meg. Emiatt nem működne a dupla klikkel való megnyitás az asszociált
fájltípusok esetében.

A telepítés végén ne indítsuk a programot a telepítőből, hanem vegyük ki a pipát az indításra vonatkozó
kérdés elől, és kattintsunk a Finish gombra. Ezután jöhet a patch alkalmazása. Ehhez másoljuk a
Files\Atlantis.Word.Processor.v1.6.1.8\patch.exe fájlt a feltelepített könyvtárba (alapbeállításban ez
a C:\Program Files\Atlantis könyvtár), és indítsuk el, és alkalmazzuk a patch-t. Miután remélhetőleg
sikeresen megvolt a védelem kiiktatása, elindíthatjuk a programot (Atlantis.exe). A főmenü Help-jében
találunk egy About menüpontot, itt megnézhetjük, hogy valóban sikeres volt-e a törés:

Jobb esetben ennek kell látszódnia. Nem baj, ha véletlenül nem Bokiv-nak hívnak, ettől még lehet jó
a dolog. Ha viszont Bokivnak, akkor gratulálok, és köszönet a patch-ért!

Hátra van még a Total Commander berakása a csomagba, aminek a miértjéről majd később. Ehhez
másoljuk a Files könyvtárban lévő Total Commander könyvtárat a C: meghajtóra. Ez egy ”okosított”
verzió, ráadásul portable, most nem is kell vele többet foglalkozni.

A programot tehát telepítettük, patch-eltük, a Total Commandert is átmásoltuk, és mindezt a figyelte

a háttérben futó SetupCapture.exe. Lépjünk ki az Atlantisból, és váltsunk át a SetupCapture-re.
Kattintsunk a Post Install Scan gombra. Ekkor megkezdődik a rendszer újbóli átvizsgálása, amelynek
az eredményét összehasonlítja az előző vizsgálat eredményével. A kettő különbsége azok a fájlok és
registry kulcsok, amelyeket az Atlantis telepítője hozott létre. Lehet, hogy, kicsivel több is, de inkább
legyen több, mint kevesebb.

Tipp akkor
Ha azt szeretnénk, hogy a thinstallált programunk testreszabott beállításokkal induljon,
rögtön a telepítés utáni első indításkor végezzük el ezeket a beállításokat (felhasználói
felület, mértékegységek beállítása, billentyűkombinációk, stb, esetleg plugineket, skineket, nyelvi
fájlokat is integrálhatunk a csomagba, stb).

9
Itt választhatjuk ki azt azokat az exe-ket, amelyek megjelennek majd a végén thinstallált formátumban.
Most az Atlantis.exe-t és a Total Commander.exe-t jelöljük be felül. Lent azt az exét válasszuk ki,
amelyik a fő programunk - ebből lesz készítve egy nagy exe, és a többi (jelen esetben a Total
Commander) csak egy link lesz, amely erre az exére mutat. Első hallásra biztosan értelmetlenül
hangzik, de majd később egyértelműbb lesz. Már akinek persze.

10
Az összehasonlítás után ebben az ablakban adhatjuk meg, hova mentse a Thinstall a talált változásokat.
Alapállapotban a Thinstall könyvár Captures almappájába kínálja fel a mentést. Ezt javallott elfogadni,
mert így a végső csomag összeállításakor tudni fogja, hol keresse a Thinstall programokat a build.bat
kötegfájl (aminek semmi köze a testépítéshez vagy a denevérekhez, bővebben majd később).

Egy ilyen ablakkal is találkozhatunk, ilyenkor csak kattintsunk a Continue gombra.

11
A folyamat végét jelzi az utolsó ablak, ahol kattintsunk a Quit gombra. Ezzel befejeződött a SetupCapture
folyamat.

Most már minden olyan fájl rendelkezésre áll, amelyek a portable összeállításához kellenek. Mielőtt
azonban ezt megtennénk, meg kell ismerkednünk néhány alapvető fogalommal.

12
 | Izolációs módok
A Thistall háromféleképpen tudja a könyvtárakat és a registry kulcsokat izolálni. Az izolálás azt jelenti,
hogy a virtuális fájlrendszerben hogyan vannak a könyvtárak elkülönítve. Ez nagyon jól le van írva a
Thinstall súgójában, de azért néhány mondatban itt is bemutatom.

A Thinstall alapállapotban olyan módon izolálja a könyvtárakat és a registry kulcsokat, hogy a kész
program zárolt számítógépen is fusson. Ez a legtöbb esetben nem is igényel manuális változtatást,
de néha szükség lehet erre is. Az Asztal, a Dokumentumok mappa és a cserélhető meghajtók
alapbeállításban írható beállítást kapnak. Ez azt jelenti, hogy ha pl. mentjük a dokumentumot a
thinstallált programból ezekre a helyekre, akkor az a valós fájlrendszerben fog mentésre kerülni -
azaz pontosan úgy, ahogy egy normál program esetében. Ha viszont a sima C: gyökérbe próbálunk
menteni, akkor az át lesz irányítva a sandbox-ba. Ez a gyakorlatban úgy néz ki, hogy a thinstallált
programunk látja a C: meghajtón lévő mentett fájlt, de ha egy külső fájlkezelővel, vagy akár a
windows explorer-rel nézzük meg a C: meghajtót, a fájl nem lesz ott. Ehelyett a sandbox-ban lesz egy
%drive_C% mappa, és ott fogjuk találni a fájlt. Ez az alapbeállítás a portable programok esetében
általában nem jó, de szerencsére nem kell minden könyvtárnak külön megadni, hogy másképpen
viselkedjen, mert ezt megtehetjük egy központi helyről is - ez pedig a Package.ini fájl. Ez tartalmaz
minden olyan beállítási lehetőséget, ami globális, tehát az egész programra vonatkozik. Ezeket a
beállításokat felülbírálják az egyes könyvtárakban lévő ##Attributes.ini fájlok.

Most nézzük meg, milyen izolációs módok állnak rendelkezésünkre.

WriteCopy
• a thinstallált program számára a rendszerelemek láthatóak
• ha ugyanaz az elem (fájl, registry kulcs) létezik a valós és a virtuális fájlrendszerben is, a thinstallált
program a virtuálisat látja
• a virtuális elemeken végzett változtatások a sandbox-ba kerülnek
• a rendszerelemeken végzett változtatások a sandbox-ba kerülnek
• új elemek a sandbox-ban kerülnek létrehozásra

Merged
• a thinstallált program számára a rendszerelemek láthatóak
• ha ugyanaz az elem (fájl, registry kulcs) létezik a valós és a virtuális fájlrendszerben is, a thinstallált
program a virtuálisat látja
• a virtuális elemeken végzett változtatások a sandbox-ba kerülnek
• a rendszerelemeken végzett változtatások a rendszerbe kerülnek
• új elemek a rendszerben kerülnek létrehozásra

Full
• a thinstallált program számára a rendszerelemek láthatatlanok
• a virtuális elemeken végzett változtatások a sandbox-ba kerülnek
• a rendszerelemeket nem lehet olvasni vagy változtatni
• új elemek a sandbox-ban kerülnek létrehozásra

13
Amint az látható, a két szélsőség a Merged és a Full izolációs módok. A Merged a legmegengedőbb,
a Full pedig igyekszik minden változtatást házon, azaz sandbox-on belül tartani. Vagyis előfordulhat,
hogy ha a Windows könyvtárat Full izolációs módra állítjuk, akkor hiába van egy olyan dll a valós
Windows könyvtárban, amire szüksége van a thinstallált programnak, mert ha az nincs a thinstallált
programunkba építve, nem fogja tudni használni. De ez előnyös is lehet, mert biztosítani tudjuk,
hogy egy dll vagy más fájl esetében csak a beépített verziót használja a thinstallált programunk, így
elkerülhetőek bizonyos kompatibilitás problémák. A Merged viszont enged létrehozni fájlokat a valós
fájlrenszerben, és enged írni a registry-be, így ezt olyan helyeken tiltanunk kell, ahol ezt el szeretnénk
kerülni, és engedni ott, ahol erre szükség van. A registry esetében pl. tiltani javasolt a program
beállításokat, regisztrációs adatokat tartalmazó kulcsokat; ellenkező esetben könnyen előfordulhat,
hogy miután futtattuk a thinstallált programunkat, a program normál módon telepített verziója nem fog
működni, vagy azokkal a beállításokkal, amelyeket a thinstallált program írta registrybe. Szerencsére
ezt könnyű elkerülni, mert alapbeállításban ez tiltva van. Ha viszont szeretnénk elkerülni, hogy a
programból mentett fájljaink ne a sandbox-ba kerüljenek, hanem oda, ahová mentettük - ami erősen
javasolt, kivéve, ha jó okunk van az ellenkezőjére - , akkor a Merged módot kell használnunk.

Mint írtam korábban, az izolációs módok manuális változtatására csak akkor van szükség, ha valami
nem működik úgy, ahogy szeretnénk, kivéve az alapértelmezett könyvtárizolációs módot, amelyet
portable programok esetében át kell tenni Merged-re (a Package.ini fájlban).

Fontos még megjegyezni, hogy ha egy könyvtárban nincs ##Attributes.ini fájl, vagy abban nincs
megadva a könyvtárizolációs mód, akkor a Thinstall automatikusan a szülő könyvtárban lévő izolációs
módot fogja alkalmazni. Vagyis pl. ha a C:\mappa\almappa könyvtárnál nincs megadva izolációs mód,
valamint a mappa könyvtárban sem, viszont a C: meghajtónál igen, akkor mindkét könyvtár izolációs
módja a C: meghajtónál megadott mód lesz. Ha viszont A C: meghajtón sincs megadva, akkor a
globális beállítás fog érvényesülni, amelyet a Package.ini fájlban tudunk beállítani.

Szerencsére a registry izolációs beállításokat csak nagyon ritkán kell változtatnunk, általában nincs
rá szükség.

A virtuális fájlrendszer a sandbox-ban jön létre, ahol különböző mappák

jelentik a különböző rendszermappákat. Erre azért van szükség, mert
nem biztos, hogy minden felhasználó esetében a C: meghajtóra van
telepítve a Windows, egyes nyelveknél más a neve a Program Files-nak
(pl. spanyol, német Windows-okon), stb. Ezért nem lehet pl. a Windows
könyvtárat úgy megtalálni a sandbox-ban, hogy %drive_C%\Windows. Ez
működhet nagyon sok esetben, de akinél a D: meghajtón van a rendszer,
ott problémák fognak adódni. A meghajtók jelölése, mint már láttuk,
%drive_X” formátumban történik, ahol az X jelenti az aktuális meghajtó
betűjelet. A Windows könyvtárat pl. a %SystemRoot% jelöli, a Program
Files könyvtárat pedig a %ProgramFilesDir%. A virtuális mappák makrói
megtalálhatóak a Thinstall súgójában (Virtual Filesystem -> Folder
Macros).

Ezeket akkor kell tudnunk, ha telepítő nélküli programot szeretnék

thinstallálni, vagy utólag szeretnénk a csomagba egy olyan könyvtárat
tenni, amit kihagytunk a SetupCapture során. Utóbbi esetben ne felejtsük
el ##Attributes.ini fájlt is betenni ezekbe az új könyvtárakba, ha azokban
a Package.ini-ben megadottól eltérő izolációs módot szeretnénk használni.
A sandbox-ban természetesen ugyanilyen elven jönnek létre a könyvtárak.
Az alsó képen láthatjuk a sandbox-ban lévő registry fájlokat is.

14
 | Package.ini
Mint korábban írtam, ebben tárolódnak a thinstallált program összeállításához szükséges beállítások.
Nos, ez ebben a részben is igaz. A Package.ini fájl automatikusan létrehozódik a SetupCapture folyamat
során, és általában elég csak egy-két beállítást módosítani benne.

A végső exe összállítását egy build.bat nevű fájl végzi, amely kiterjesztése ellenére nem vírus. Ebben
tudjuk megadni, hogy milyen legyen az alapértelmezett könyvtárizolációs mód, a tömörítés mértéke,
az exe neve, a sandbox neve és elérési útvonala, stb. Készíthetünk msi telepítőt is a Thinstall
segítségével; ennek a beállításait is itt tudjuk megadni. Ezeken kívül sok olyan opciós lehetőség van,
amely alapállapotban nem kerül bele ebbe az ini fájlba, viszont néha szükség lehet rájuk. Ezek a
Thinstall súgóban mind le vannak írva, külön nem térek ki mindegyikre.

A fontosabb beállítási lehetőségeket az aktuális példa Package.ini fájljának elemzésével fogom bővebben
kifejteni. Ehhez keressük meg azt a könyvtárat, ahová a SetupCapture folyamat eredményét mentettük
(általában a Thinstall könyvtár Captures mappájában található, hacsak nem máshova mentettük). Itt
optimális esetben megtaláljuk az Atlantis Word Processor mappát, és benne a Package.ini fájlt.

Mielőtt azonban bármit is tennénk, az egész Atlantis Word Processor mappáról készítsünk egy
biztonsági mentést (azaz csináljunk belőle egy másolatot). Ezzel biztosítjuk azt, hogy ne kelljen még
egyszer az egész thinstallállási folyamatot megismételni, ha valami olyan csinálnánk, amit nem tudunk
visszavonni.

Az én Atlantis capture könyváram így fest:

Valami hasonlót kell neked is látnod, de lehetnek eltérések. A szemfülesebb olvasók észrevehetik,
hogy ezen a képen más meghajtón van nálam az egész projekt. Nem baj. Elárulom azt is, hogy egy
teljesen másik számítógépen is. Ráadásul vonaton - nem könnyű a Thinstall leírást készítők élete...

15
A Package.ini fájl tartalmában is lehetnek eltérések, de ez reményeim szerint nem fogja befolyásolni
a követhetőséget.

Nyissuk meg a Package.ini fájlt egy valamirevaló editorral (valamirevaló alatt azt értem, hogy van
benne syntax kiemelés, tehát notepad kiesik; word-öt pedig felejtsük el). Jómagam notepad++-t
használok, de ha nagyon nincs semmi kéznél, megteszi a beépített notepad (jegyzettömb) is.

Az első sorokban ilyet látunk:

[Compression]
CompressionType=None
;CompressionType=Fast

Itt a tömörítés mértékét tudjuk beállítani. Háromesélyes a dolog: None (nincs tömörítés), Fast (gyors
tömörítés), és Small (kicsire tömörítés). Az utolsó sor ki van kommentezve (pontosvessző van a sor
előtt), ez azt jelenti, hogy vehetjük úgy, hogy nincs ott, és a build.bat is figyelmen kívül fogja hagyni.
Akkor miért hagyták benne? Mert könnyebb kivenni előle a pontosvesszőt, mint átírni az egészet. Jelen
esetben nem sokkal, de a későbbiekben sok kommentezett rész lesz majd, ott jelentős segítség lehet.
Ráadásul így látni lehet, hogy milyen más lehetőségek vannak még.

Ha None-ra állítjuk a tömörítést (azaz változatlanul hagyjuk), akkor körülbelül ugyanakkora lesz a végső
exe, mint az egész projekt könyvtár mérete. Ezzel tudjuk a leggyorsabban elkészíteni a thinstallált
programunkat. Fast tömörítés esetén jóval tovább fog tartani a build folyamat. Hogy mit kapunk ezért
cserébe? Körülbelül 50%-kal kisebb méretet. A mellbőséggel ellentétben ez nagyon jó dolog. Egy kis
kompromisszumot kell kötnünk az indítási idővel, mert Fast tömörítés esetén kicsit lassabban indulnak
a thinstallált programok. Ez a gyakorlatban csak néhány másodpercet jelent, így ajánlatos mindig
ezt használni. Most mégis hagyjuk változatlanul, mert előfordulhat, hogy az először összeállított exe
nem lesz jó, ezért nincs értelme hiába izzasztani a gépünket. Ha a legvégén, amikor mindent rendben
találunk, akkor törölhetjük a CompressionType=None sort, és kivehetjük a pontosvesszőt a következő
sorból, majd jöhet a végső build. Small tömörítést azért nem érdemes használni, mert nem sokkal
jobban tömörít, mint a Fast, viszont sokkal lassabban indul majd a programunk. Az arany középút
ebben az esetben a Fast opció.
[Isolation]
DirectoryIsolationMode=WriteCopy
;DirectoryIsolationMode=Merged

A következő részlegben láthatjuk az izolációs mód beállítását. Ez a globális beállítás, tehát minden olyan
könyvtár, amelynél nem adtuk meg külön az izolációs módot ##Attributes.ini fájllal, ott ez a beállítás
fog érvényesülni. Ez az a beállítás, amelyet meg kell változtatnunk portable készítés esetén, hogy a
thinstallált programunkból mentett fájlok ne a sandbox-ba kerüljenek, hanem a valós fájlrendszerbe,
mint azt korábban már tárgyaltuk. Állítsuk tehát Merged-re az izolációs módot WriteCopy helyett.

A következő rész a [BuildOptions]. Ennek az első felében lehet beállítani, ha szeretnénk msi telepítőt is
létrehozni - de mivel most nem szeretnénk, ezért ezt most úgy ahogy van, átugorhatjuk.

A kommentezett sorok után találunk egy olyat, hogy SuggestedName. Ez az a név, amit a Thinstall
talált az Atlantis.exe leírójában. Ezt átírhatjuk másra, ha nem egyezne meg azzal a névvel, ami a fő
exénk - mivel azonban a végső exe nevét máshol tudjuk megadni, így ennek a beállításnak sok értelme
nincsen. Ahogy az OriginalSnapshot és a DestinationSnapshot soroknak sem. Akit érdekel, keresse
meg a Help-ben. Jó keresőnek kell lenni hozzá, mert én nem találtam. A CapturedUsingVersion sor
is hasonló fontossággal bír, úgyhogy ugorhatunk a következőre.

Az OutDir azt a könyvtárat adja meg, ahová a Thinstall a végeredményt fogja tenni. Alapállapotban
ez ”bin”, ami azt jelenti, hogy a build.bat könyvtárban fog létrehozni egy bin könyvtárat, és ott fogjuk
találni a végső exe fájlt vagy fájlokat. Ezt megváltoztathatjuk, ha akarjuk, de sok értelme nincsen.

16
Átírhatjuk a bin-t másra, jelen esetben pl. ”Thinstalled Atlantis”, de ha más helyre akarjuk tenni ezt
a könvtárat, akkor azt is megtehetjük. Használhatjuk a relatív elérési útvonalat is erre a célra; ha
a szülő könyvtárba akarunk kerülni, akkor írjuk a bin helyére azt, hogy ”..\bin”, ha két könyvtárral
feljebb, akkor ”..\..\bin”, stb. Természetesen megváltoztathatjuk a nevet és az útvonalat is egyszerre,
tehát a ”..\Thinstalled Atlantis” is működni fog. Most hagyjuk változatlanul a bin-t.

A SandoxName nagyon furfangos jószág, pont azt jelenti, amire a nevéből következtethetni lehet: a
sandbox nevét adhatjuk itt meg. Ez alapbeállításban a program neve, amit akár hagyhatunk így is. Én
meg szoktam változtatni PROGRAMNÉV_beállítások, PROGRAMNÉV_sandbox, stb. módon. A program
működése szempontjából ez teljesen mindegy, de azért érdemes valami találó nevet adni neki.

Mielőtt továbbmennénk, most jött el az ideje annak, hogy néhány olyan opciót is beírjunk, ami az alap
Package.ini fájlban nincs benne. Az egyik a DisableTracing=1, amely letiltja a Thinstall automatikus
.trace fájlokat készítését, ha a Log Monitor fut. Ezt bonyolult lenne elmagyarázni, még akkor is, ha
teljesen érteném, úgyhogy maradjunk annyiban, hogy ez portable esetén jó, ha benne van.

A másik opció a SandboxPath, amely megadja, hogy hová kerüljön a sandbox. Ezt sokan használják,
általában a ”SandboxPath=.” formában. A pont (.) jelzi, hogy a sandbox ugyanabban a könyvtárban
van, ahol az exe található. Ez portable programok esetében hasznos, mert így biztosítva van, hogy
a sandbox arra az adathordozóra kerül, amelyikről a a portable futtatva van. Ha ezt nem adjuk
meg, és úgy indítunk egy thinstallált programot, hogy nincs mellette a sandbox-ja, akkor a ”C:\
Documents and Settings\FELHASZNÁLÓNÉV\Application Data\Thinstall” mappába fognak kerülni a
beállítások és a módosított programfájlok. Ezt pedig kerülni érdemes. Habár a SandboxPath hasznos
dolognak tűnik (és az is), óvatosan kell bánni vele. Ha pl. cd-n szeretnénk használni a programot, ahol
a sandbox könyvtár nem írható, valószínű, hogy nem fog futni a program, mert nem tudja létrehozni
a működéséhez szükséges fájlokat a könyvtárban. Ilyen esetekben jobb, ha kihagyjuk ezt a beállítási
lehetőséget.

Ha valamilyen oknál fogva valamilyen kapcsolóval szeretnénk indítani egy programot, arra is lehetőség
van. Ezt a CommandLine teszi lehetővé. A CorelDRAW-t pl. lehet úgy indítani, hogy ne jelenjen meg
az indítási képernyő (splash screen). Ehhez a ”-nosplash”-ot kell hozzácsapni az exe mögé:

CommandLine=”%ProgramFilesDir%\...\CorelDrw.exe” -nosplash

Nincs ugyan benne a Thinstall súgójában, de fontosnak tartom megjegyezni, hogy villany- és hasonló
kapcsolókkal nem fog menni a dolog.

Az InventoryName dologra igazából akkor van szükség, ha egy programnak több verzióját használják.
Ilyenkor eltérő sandbox névvel a különböző verziók változatait külön tudják szedni, viszont az
InventoryName lehet ugyanaz (különböző nyilvántartásokhoz). Ennyit elég is erről tudni. Ha nem
egyezik meg az InventoryName a thinstallált programmal, akkor átírhatjuk arra.

A kommentezett részek közül a RemoveSandboxOnExit lehet érdekes, illetve a

VirtualizeExternalOutOfProcessCOM. Az előbbi RemoveSandboxOnExit=1 esetén üríti a sandbox-
ot kilépéskor. Ennek nagyon egyszerű programok esetében van létjogosultsága, ahol nincsenek
beállítási lehetőségek, vagyis mindig ugyanúgy indul a program. Ilyenkor nincs értelme feleslegesen
fájlokat létrehozatni a sandbox-ban. A VirtualizeExternalOutOfProcessCOM=0 azt mondja a
thinstallált programnak, hogy ha .com objektumot akar a rendszerbe tenni, akkor azt ne a virtuálisba,
hanem a valós rendszerbe tegye. Nagyon ritkán előfordulhat, hogy ennek az engedélyezésével egy
program működésre bírható Thinstall-lal, de tudni kell, hogy ez a valós rendszerben fog változásokat
eredményezni.

17
 VirtualDrives= Drive=C, Serial=12345678, Type=FIXED; Drive=d, Serial=23456789, Type=FIXED

A virtuális meghajtók arra valók, hogy megmondjuk a thinstallált programnak, hogy az általa látott
X meghajtó fix/cserélhető/cd-rom/ramdisk, és hogy milyen sorozatszámú. Ennek segítségével pl. azt
mondhatjuk a thinstallált programnak, hogy az M: meghajtó egy 12345678 sorozatszámú cd-rom, ami
azért jó, mert vannak olyan programok, amelyeknél szükséges lehet a cd jelenléte. Azt a meghajtót,
amire telepítettük a programot, érdemes meghagyni a virtualdrives sorban, sorozatszámmal együtt,
hogy elhitessük a programmal, ugyanazon a gépen van. Jelen példában tehát hagyjuk meg ezt a sort,
a sorozatszámmal együtt: VirtualDrives= Drive=C, Serial=12345678 (a sorozatszám természetesen
mindenkinél más lesz).

A következő részben azokat az exe fájlokat találjuk felsorolva, amelyeket a Thinstall a telepítés során
talált. Az egyes exe fájlok esetében a Disabled opció adja meg, hogy a build.bat lefuttatása után
rendelkezésre álljon-e. Ha Disabled=1, akkor az az exe nem lesz elérhető. Ha nincs az exe alatt a
Disabled feltüntetve, akkor az rendelkezésre fog állni. Most csak az Atlantis.exe és a Total Commander.
exe programokra van szükségünk, de mint látjuk, ennél sokkal több exe van felsorolva. Ha biztosak
vagyunk benne, hogy a többire nincs szükségünk, akár törölhetjük is ezeket a blokkokat, de elegánsabb,
ha a Disabled=1 sorral iktatjuk ki őket. Így, ha később mégis kellenének ezek a programok, csak át
kell írni az 1-est 0-ra, vagy törölni ezt a sort.

Mivel a fő exének az Atlantis.exe fájlt választottuk, ezért ez lesz az az exe, amely magában foglalja az
összes projekt fájlt. Így ennek a mérete nagy lesz, míg a többi exe csak egy shortcut (parancsikon)
lesz, amelyek erre az Atlantis.exe fájlra mutatnak. A ReadOnlyData=bin\Package.ro.tvr mutatja,
hogy melyik a fő exe fájlunk. A többi exe fájlnál láthatjuk a Shortcut=Atlantis.exe sort, amely azt
adja meg, hogy melyik exe fájlra mutasson a parancsikon. Vegyük észre, hogy a Shortcut után lévő
Atlantis.exe a fő exe neve, amit a [Atlantis.exe] sor ad meg. Ha akarjuk, átírhatjuk az [Atlantis.exe]
sort mondjuk [Thinstalled Atlantis.exe] sorra, de akkor az összes Shortcut=Atlantis.exe hivatkozást is
át kell írnunk Shortcut=Thinstalled Atlantis.exe sorra. Most azonban maradjunk az eredeti névnél.

A Source az exe helyét adja meg a virtuális fájlrendszerben. Ezt sem kell bolygatnunk, csak akkor, ha
változtattunk a projekt könyvtárszerkezetében (ami kezdőknek nem ajánlatos).

A WorkingDirectory az adott exe könyvtárát jelöli. Ezt sem kell változtatnunk.

Az Icon az exe ikonját adja meg. Ezt nem muszáj külön megadnunk, de ha más ikont szeretnénk
az exéhez rendelni, megtehetjük vele. Akár új ikont is tehetünk a csomagba, ekkor módosítjuk úgy
az Icon sort, hogy erre az új ikon fájlra mutasson. Ha viszont töröljük az Icon sort, a build folyamat
végén ellenőrizzük, hogy az adott exének van-e ikonja. Előfordulhat ugyanis, hogy nincs, ilyenkor
nekünk kell manuálisan megadnunk. Ez főleg akkor következhet be, ha a Thinstall az ikont egy olyan
telepítő fájlból eredezteti, amelyet helytakarékosság miatt töröltünk a projekt fájlok közül.

Találunk még egy Shortcuts szóval kezdetű sort is. Ennek az msi generálásánál van szerepe, ez
adja meg, hogy az msi telepítő hol hozzon létre parancsikonokat. A Filetypes is az msi részhez kell,
ezzel tudjuk beállítani, hogy milyen fájlokkal asszociálja a telepítő az adott exét. Portable programok
készítésénél ezekre nincs szükségünk, de nem okoz problémát, ha benne hagyjuk ezeket a sorokat a
Package.ini fájlban.

18
Most, hogy kiveséztük a legfontosabb opciókat a Package.ini fájlban, készen állunk arra, hogy
összeállítsuk első thinstallált programunkat. Felhívnám a figyelmet arra, hogy rengeteg olyan opció
van a felsoroltakon kívül a thinstallált programunk testreszabására, amelyekkel befolyásolhatjuk a
program működését; ezek mind megtalálhatók a Thinstall súgójának Package.ini ágában.

A biztonság kedvéért itt a helyes Package.ini (eltérések természetesen előfordulhatnak, a lényeges

változtatásokat kiemeltem):
[Compression]
CompressionType=None
;CompressionType=Fast

[Isolation]
DirectoryIsolationMode=Merged

[BuildOptions]
SuggestedName=Atlantis Word Processor
OriginalSnapshot=C:\PROGRA~1\TH~BUR4W.VS\{55881~1.SNA
DestinationSnapshot=C:\PROGRA~1\TH~BUR4W.VS\{4D2C5~1.SNA
CapturedUsingVersion=3.332
OutDir=bin
SandboxName=Atlantis_beallitasok
DisableTracing=1
InventoryName=Atlantis Word Processor

VirtualDrives=Drive=c, Serial=12345678, Type=FIXED;

[Atlantis.exe]
ReadOnlyData=bin\Package.ro.tvr
Source=%ProgramFilesDir%\Atlantis\Atlantis.exe
WorkingDirectory=%ProgramFilesDir%\Atlantis
FileTypes=.adpr
Shortcuts=%Programs%;%Programs%\Atlantis;%Desktop%

[Uninstall.exe]
Shortcut=Atlantis.exe
Disabled=1
Source=%ProgramFilesDir%\Atlantis\Atlantis.exe
WorkingDirectory=%ProgramFilesDir%\Atlantis
CommandLine=”%ProgramFilesDir%\Atlantis\Atlantis.exe” -ui
Icon=%ProgramFilesDir%\Atlantis\Atlantis.exe,7
Shortcuts=%Programs%\Atlantis

[patch.exe]
Shortcut=Atlantis.exe
Disabled=1
Source=%ProgramFilesDir%\Atlantis\patch.exe

[TCMADMIN.EXE]
Shortcut=Atlantis.exe
Disabled=1
Source=%drive_c%\Total Commander\TCMADMIN.EXE

[TOTALCMD.EXE]
Shortcut=Atlantis.exe
Source=%drive_c%\Total Commander\TOTALCMD.EXE
[cmd.exe]

19
 Shortcut=Atlantis.exe
Disabled=1
Source=%SystemSystem%\cmd.exe

[regedit.exe]
Shortcut=Atlantis.exe
Disabled=1
Source=%SystemRoot%\regedit.exe

[iexplore.exe]
Shortcut=Atlantis.exe
Disabled=1
Source=%ProgramFilesDir%\Internet Explorer\iexplore.exe

Emlékezzünk rá, hogy a legelső blokkban a tömörítés típusát None-on hagytuk, mert így gyorsabban
elkészül a thinstallált program. Ha a programunk jól működik, ezt javasolt átállítani Fast-ra, és újra
futtatni a build.bat-ot, így sokkal kisebb méretű lesz a végeredmény.

Találunk még olyan exéket is felsorolva az ini fájlban, mint cmd.exe, regedit.exe, és iexplore.exe.
Ezek haladó felhasználóknak nyújtanak segítséget. A cmd.exe például a virtuális fájlrendszerben
való parancssoros buheráláshoz szükséges, a regedit.exe a pedig a virtuális registry kezeléshez.
Hasonlóképpen, az iexplore.exe is a virtuális környezetben futtatott böngészőt jelenti.

Miután mindent tisztáztunk, jöhet a build. Ez egy nagyon bonyolult, haladó felhasználót igénylő
dolog: kattintsunk duplán a build.bat fájlra. Ha minden rendben van, egy parancssoros ablak fog
előbukkanni, ahol láthatjuk a build folyamatát. Ha az ablak bezáródik, a bin könyvtárban fogjuk találni
az Atlantis.exe és a Total Commander.exe fájlokat. Ha a parancssoros ablak csak felbukkan és hirtelen
eltűnik, akkor nagy valószínűséggel nem a Thinstall könyvtár Captures alkönyvtárában van az Atlantis
könyvtárunk, és emiatt a build.bat nem találja a szükséges Thinstall fájlokat. Ennek megoldásához
helyezzük át a projekt mappáját a Captures mappába.

Ha minden rendben ment, és elkészült a két thinstallált programunk, következhet az első, de legfontosabb
teszt: az indítás. Azonban indítás előtt hozzuk létre a sandbox-ot, hogy ide kerüljenek a thinstallált
program által létrehozott vagy módosított fájlok, és a virtuális registry. Mivel én a SandboxName-hez
Atlantis_beallitasok nevet adtam meg, így létre kell hoznom egy Atlantis_beallitasok nevű mappát a
bin könyvtárban.

Tipp (ha
Ha nincs kedvünk kideríteni, hogy milyen nevet adtunk meg, vagy adott meg a készítő
nem mi készítettük a portable-t), hozzunk létre egy Thinstall mappát a thinstallált
program mellett. Ezt bármikor használhatjuk, ha thinstallált programot indítunk, ahol nem találunk
az exe mellett sandbox-ot, ugyanis a Thinstall ezt fogja használni sandbox-ként. Ebben fog létrejönni
egy mappa, amelynek neve meg fog egyezni a készítő által megadott sandbox névvel. Ezt a mappát
áthelyezhetjük egy szinttel feljebb, és törölhetjük az előbbiekben létrehozott Thinstall mappát.

Nos, nálam az első indítás sikeres volt, ami nagyon megnyugtató dolog, mert ez egyben azt jelenti,
hogy amit eddig írtam, az nem volt hiábavaló, és egyben azt is, hogy nem landol az egész projekt a
kukában. A jól működő thinstallált program készítéséhez azonban további tesztelések szükségesek,
erről bővebben a következő részben írok.

20
 | Nagy teszt, nagy élvezet
Ne bízzuk el magunkat túlzottan, ha az első teszt sikeres volt. Ettől még lehet, hogy hiába fáradoztunk.
De az első sikeres teszt jó jel, mert azt mutatja, hogy valószínűleg nincs olyan kritikus hiba, ami miatt
aggódnunk kellene. Ha viszont olyat hibaüzenetet kapunk, hogy ”A program szabálytalan műveletet
hajtott végre, és leáll”, vagy egyáltalán nem történik semmi, akkor kezdhetjük vakarni a fejünket.
Vannak olyan esetek, amikor hiába próbálunk meg mindent, nem tudjuk a thinstallált programot
működésre bírni. Ilyenkor nincs más, mint a monitor fölé nézni, egy egészségeset káromkodni, és
más örömök után nézni.

Mivel úgy teszteltük a thinstallált Atlantis-t, hogy az fel volt telepítve a gépünkön, ezért most telepítsük
le a gépről. Ezután ürítsük ki a sandbox-ot (csak a tartalmát töröljük, a könyvtár maradjon meg).
Ezzel nulláztuk a programot, azaz alapbeállításokkal fog indulni. Ha ez a teszt is sikeres, jöhet a
következő lépés.

Ez pedig a program megfelelő működésének tesztelése. Első körben nézzük meg, hogy a fájlok
megnyitása-mentése rendben történik-e. Gondolok itt arra, hogy nem fagy-e a program, hibaüzeneteket
kapunk-e, illetve a fájlok a valós fájlrendszerbe mentődnek, nem pedig a sandboxba. Ha valamilyen
hibát észlelünk, próbáljuk meg kijavítani, majd futtassuk újra a build.bat-ot, ürítsük a sandox-ot, és
teszteljük újra a programot. Mentésnél nézzük meg, hogy a már mentett fájlra való újbóli rámentés
is működik-e; sajnos találkoztam már olyan programmal, ami ezen hasalt el.

A hibátlan működés kiderítéséhez nem elég néhány perc. Ajánlatos legalább 1-2 napig használni a
programot, és ha nem találunk semmilyen problémát, megfelelőnek bélyegezhetjük a portable-t. De
a puding próbája az evés, és annál biztosabb a siker, minél éhesebbek vagyunk.

Most másoljuk a bin könyvtárat a thinstallált programokkal egy usb-re, és másszunk át egy másik
gépre, és ott is próbáljuk ki. Ha vmware-ben dolgozunk, állítsuk vissza a virtuális operációs rendszert,
és ott is indítsuk el. Ha DeepFreeze-t használunk, nyomjunk egy restartot, és utána teszteljük. Másik
gépen való tesztelés sokkal megbízhatóbb, mert ott új hardver- és szoftverkörnyezetben tesztelhetünk.
Ha lehetőségünk van rá, próbáljuk ki különböző operációs rendszereken is (XP, Vista, esetleg Windows
2000). Ha a többi gépen is sikeres a teszt, kezdhetünk bizakodni, de minél több gépen teszteljük,
annál biztosabb a dolog.

A másik gépen való tesztelés a törés ellenőrzése szempontjából is fontos. A patch-ok általában úgy
törik fel a programokat, hogy deaktiválják a program védelmét, így nagy valószínűséggel másik gépen
sem fog problémánk lenni vele. A sorozatszámok és license fájlok azonban lehetnek hardverfüggők,
így ilyen esetekben erre is figyelnünk kell. Ha ilyennel találkozunk, akkor alkalmazzuk a Thinstall
korlátai c. részben leírtakat.

Tesztelésnél meg kell azt is vizsgálnunk, hogy miután kiléptünk a thinstallált programból, az valóban
bezáródik-e. Sajnos vannak esetek, amikor nem, és ez azért nem jó, mert ha USB-ről futtatjuk a
programot, akkor az sérülhet, ha kihúzzuk a gépből. Ezt úgy tudjuk tesztelni, hogy kilépés után
üríteni próbáljuk a sandbox-ot. Ha nem sikerül a törlés, nézzük meg a Feladatkezelőben (Ctrl-Alt-Del,
második fül), hogy konkrétan melyik program problémázik (és lőjjük is ki, ha már itt vagyunk - jobb
klikk a listában a programra, és válasszuk a Folyamatstruktúra leállítása menüpontot). Szerencsére
a Thinstallhoz tud visual basic scripteket futtatni, amit fel tudunk használni ennek a problémának a
megoldására. Erre a problémára íródott az vbscript, amelyet megtaláltok a Thinstall könyvtárban,
close.vbs néven. Mindössze annyi a dolgotok, hogy a benne található XXXXX.exe részt átírjátok a
bezáródni nem kívánó program nevére, és ezt a vbs fájlt a build.bat mellé teszitek. A fájl neve nem
lényeges. Sajnos vannak esetek, amikor ez sem segít. De legalább megpróbáltuk.

21
 | A méret a lényeg
Ha minden nyúzás után is úgy tűnik, hogy nem találunk fogást a thinstallált programunkon, átállíthatjuk
a tömörítési fokot None-ról Fast-ra. Nálam 7 Mb-ról 5,7-re csökkent a thinstallált Atlantis.exe
mérete, ami jelen esetben nem túl nagy változás, viszont sok esetben ennél sokkal jobb tömörítést
tapasztalhatunk (~50% körülit).

Készítsünk egy biztonsági mentést a projektről - másoljuk a Captures könyvtárban lévő projekt
mappát egy másik könyvtárba. Erre azért van szükség, mert a kisebb méret érdekében néhány
fájlt el fogunk távolítani a projektből. Olyan fájlokat töröljünk, amelyek nem feltétlenül szükségesek
a működéshez. Ilyen lehet pl. a Sample (minta) fájlok, Súgók, Readme.txt, License.txt, Uninstall.
exe, különböző log fájlok, stb. Ezek mindig az adott program struktúrájától függnek. Főleg nagy
programoknál van értelme a minél kisebb méretre törekedni, jelen esetben a kb. 6 megás méret elég
kicsi ahhoz, hogy ne kelljen ezzel vesződni. Egy többszáz megás program esetében viszont nagyon
sok helyet spórolhatunk, de nagyon vigyázzunk arra, hogy lehetőleg egyetlen kritikus összetevőt
se töröljünk. Ha egy program template-alapú (pl. egy webgaléria-generáló program), akkor hiába
tudnák rengeteg helyet spórolni a template-ek törlésével, mert a program használhatatlanná válik.
Ha viszont tudjuk, hogy mire van, vagy lehet szükségünk, akkor nyugodt szívvel eltávolíthatjuk a
számunkra felesleges részeket. Azonban, ha a végeredményt másokkal is meg szeretnénk osztani,
akkor óvatosan hámozzuk le a felesleget, mert nem tudhatuk, másnak mi a fontos.

Jelen példánkban a következőket távolíthatjuk el különösebb lelkiismeret-furdalás nélkül:

• Uninstall.exe
• Install.log
• Vendor.txt
• Readme.txt
• File_id.diz
• License.txt
Ha tartjuk magunkat annyira műveltnek, hogy az Atlantis súgója már nem tud nekünk újat mondani,
akkor törölhetjük ezt a fájlt is (Atlantis.chm). A Spellcheck és a Templates mappákat is üríthetjük, ha
nincs szükségünk a helyesírás-ellenőrzőre és a template-ekre. Mivel a thinstallált program hozhat
létre fájlokat ezekben a könyvtárakban, ezért érdemesebb meghagyni a könyvtárakat és bennük
az ##Attributes.ini fájlokat, vagy egyszerűbb megoldás, ha az Atlantis főkönyvtárban hozunk létre
egy ##Attributes.ini fájlt Full könyvtárizolációval. Az elválasztásért felelős Hyphenation.dat fájl
is törölhető, ha nincs, és valószínűleg a jövőben sem lesz rá szükségünk. A Samples mappától is
megválhatunk, ha csökkenteni akarjuk a végső méretet. A feltöréshez használt patch.exe fájlt is
töröljük, ha még a könyvtárban lenne. A Clip Library könyvtár olyan szövegrészleteket tartalmaz,
amelyeket felhasználhatunk dokumentumainkban. Sajnos ezek angol nyelven íródtak, így akár ezektől
is megszabadulhatunk.

Ha mindezeket töröltük, nagyjából 1,8 Mb-ra fog csökkenni az Atlantis könyvtár mérete a
%ProgramFilesDir% mappában, a végső exe pedig 3,5 Mb lesz (a Total Commander miatt). Nézzük
meg, hogy rendben működik-e a programunk. Sajnos amint elkezdünk írni a programban, a helyesírás-
ellenőrző visítani kezd, hogy nem találja a szükséges fájlokat. Ezeket letilthatjuk ugyan, ha a No-ra
kattintunk (két esetben is), de ez mindig idegesíteni fog bennünket, ha ürítjük a sandox-ot. Úgyhogy
javaslom, hogy állítsuk vissza ezt a könyvtárat a mentett backup könyvtárból.

Tipp Elég, ha a Lex könyvtárat töröljük a Spellcheck könyvtárból. Így a méret csökkenni fog, de
nem fog kérdéseket feltenni a helyesírás-ellenőrző, amint elkezdünk írni.

22
Vannak esetek, amikor úgy a program vizsgálja, hogy megvan-e egy fájl, de igazából nincs rá
szüksége (azaz inkább nekünk nincs rá szükségünk, a portable verzióhoz). Ilyenkor a fájl törlése
nem jó megoldás, de ha megnyitjuk egy text editorral (vagy notepad-del), és töröljük a tartalmát,
akkor ugyanazt az eredményt érjük el. Vagyis egy 0 Kb méretű fájlt fogunk a projektbe építeni, ami
általában nem növeli jelentősen a végső méretet.

Felmerülhet a kérdés, hogy mi szükségünk van a Total Commander-re. Nos, ezt inkább csak a példa
kedvéért tettem bele, mert nagy szükség nincs rá az Atlantis esetében. De ha találunk hozzá később pl.
egy magyar helyesírás-ellenőrzőt, vagy mintafájlokat, amelyeket szeretnénk belerakni a programba,
azt megtehetjük ezzel a Total Commanderrel. Ha ezt a Total Commandert használjuk, az a virtuális
környezetben fog működni, azaz látni fogja azokat a fájlokat, amelyek a thinstallált Atlantisban vannak
(azaz önmagában). Tehát ezzel látni fogjuk a Program Files-ban az Atlantis könyvtárat, holott nincs
ilyen könyvtár a valós rendszerben. Így ezt használva fáljokat tudunk másolni az Atlantis könyvtárba,
beletehetjük a csomagba a magyar helyesírás-ellenőrzőnket, stb. A másolt fájlok természetesen
nem a valós Program Files mappába fognak kerülni, hanem a sandbox Program Files megfelelőjébe,
a %ProgramFilesDir% mappába. Az a kérdés is felmerülhet, hogy miért nem egyből ide másoljuk
a szükséges fájlokat - nos, megtehetjük, de a thinstallált program sajnos ezeket nem fogja látni,
és nem is fogja használni. Kérdés lehet az is, hogy miért Total Commandert használtunk? Ez sem
szentírás, a legtöbb fájlkezelő használható erre a célra (XYplorer, A4 File Manager, stb.). Példánkban
az a helyzet állt elő, hogy nagyobb helyet foglal a fájlkezelő, mint maga a fő program. Ilyenkor indokolt
lehet egy sokkal kisebb fájlkezelő használata. Ha viszont tudjuk, hogy utólag biztosan nem fogunk
fájlokat beletenni a thinstallált programunkba, nyugodtan ki is hagyhatjuk a beépített fájlkezelőt
(ha jelen példánkban is így döntünk, akkor távolítsuk el a Package.ini fájlból a Total Commanderre
vonatkozó blokkot). Én azért szoktam Total Commandert használni, mert kétablakos, sokan ismerik,
és a regisztrációja sincs túlbonyolítva (elég egy .key fájl). Ráadásul, ha jól van beállítva, akkor csak
a saját könyvtárába menti a beállításait, így környezetkímélőnek is tekinthető.

Jelen esetben 2,1 Mb-ra tudtam csökkenteni a thinstallált Atlantis méretét. Nem olyan rossz eredmény
egy olyan programtól, ami 3,7 megás telepítővel érkezik, ugye? Persze az igazsághoz hozzátartozik az
is, hogy sok dolgot eltávolítottunk a programból.

További méretcsökkentést érhetünk el, ha az exe és a dll fájlokat upx tömörítővel összenyomjuk. Ez
önmagában kb 50%-ra tudja tömöríteni ezeket az állományokat, amin a thinstall tömörítője már
nem sokat tud csökkenteni, de összességében kisebb méretet kaphatunk. Azonban óvatosan az
upx-szel: előfordulhat, hogy a program nem tudja használni az upx-szel tömörített fájlokat, emiatt
használhatatlan lesz a program. Ha valamilyen okól mégis erre vetemednénk, mindenképpen készítsünk
biztonsági másolatot a projektről. Aktuális példánkban nekem nem sikerült upx-szel tömöríteni sem az
Atlantis.exe, sem az unicows.dll fájlt (nem minden exét lehet), így további méretcsökkentési sikerről
sajnos nem tudok beszámolni. A thinstallált exe fájlt sajnos nem lehet tovább tömöríteni upx-szel.
Ha viszont sikeresnek tűnik az upx-es akciónk, újra teszteknek kell alávetni a végeredményt, hogy
megbizonyosodjunk róla, a tömörített fájlok megfelelően működnek.

Vannak programok, amelyek telepítőket másolnak a gépre telepítéskor. Ezek olyan funkciót hivatottak
a telepítés után ellátni, amelyre csak bizonyos esetekben van szükség, vagy egyszerűen csak azt
biztosítják, hogy a program meghibásodása esetén rendelkezésre álljanak a telepítő fájlok a javításhoz.
Ezek gyakran elég sok helyet foglalnak, és legtöbbször nem okoz problémát, ha eltávolítjuk őket.
Ezeket általában az Appdata mappában, vagy a C:\Windows\Installer, stb. helyeken találhatjuk, és
kiterjesztésükből vagy nevükből azonnal kiszúrhatjuk őket. Ha úgy döntünk, hogy ezeket is töröljük,
akkor szánjunk több időt a tesztelésre, főleg a program speciálisabb funkcióinak kipróbálására.

A józan paraszti (akarom mondani kocka) ész legyen a támpont abban, hogy mit töröltök a csomagból,
és hogy mit hagytok benne. Ha kérdéses esethez értek, ahol csődöt mond minden tudomány, akkor
inkább hagyjátok meg ezeket a fájlokat. Néhány plusz megabájt senkinek sem árt.

23
 | .NET, Java és társaik
Vannak olyan programok, amelyek működéséhez szükséges a .NET keretrendszer, vagy a Java
jelenléte a fogadó számítógépen. Ha biztosra szeretnénk menni, hogy a thinstallált programunk
minden számítógépen fusson, akkor ezeket is integrálnunk kell a thinstallált programba. Ezt nagyon
egyszerűen meg tudjuk oldani; a SetupCapture folyamán telepítsük a .NET-et vagy a Java-t, így ezeket
is be fogja építeni a Thinstall a végeredménybe. Természetesen olyan rendszeren kell ezt a telepítést
végezni, ahol ezek még nincsenek a rendszerben. Olyan rendszeren, ahol ezek telepítve vannak, nem
segít az uninstall, mert maradhatnak olyan fájlok és/vagy registry kulcsok a rendszerben, amelyek
megakadályozzák azt, hogy a Thinstall új elemekként azonosítsa őket. Így más számítógépeken
előfordulhat, hogy a portable programunk nem fog futni. Tisztaság fél egészség, jelen esetben fél
siker.

A megoldás hátránya, hogy elég nagy programot fogunk végül kapni, már ami a méretet illeti.
Véleményem szerint inkább legyen nagy, mint működésképtelen, ezért jobban örülök egy nagyobb,
de működő verziónak, mint amelyik hibaüzenettel leáll.

A Thinstall hivatalos oldaláról letölthetőek a különböző .NET verziók capture könyvtárai. Ezek jelentős
segítséget nyújthatnak, mert annyi csak a dolgunk, hogy a .NET nélküli projekt könyvtárunkat
összefésüljük a megfelelő .NET verzió könyvtárával.

http://thinstall.com/examples/dnet11_captured.zip
http://thinstall.com/examples/dnet20_captured.zip
http://thinstall.com/examples/dnet30_captured.zip

24
 | Sbmerge
Ez a Thinstall segédeszközeinek egyike, amelynek segítségével a már meglévő sandbox-ot tudjuk
a fő exébe beépíteni. Miért lehet erre szükség? Nagyon sok esetben, ha pl. kifelejtettünk valamit a
thinstallált programból, és már töröltük az adott program capture könyvtárát (amit illik megőrízni
legalább 1 hónapig), vagy valamely beállítást szeretnénk megváltoztatni úgy, hogy az sandbox ürítés
után is benne legyen a programban. A program neve a sandbox és a merge szavak összefésüléséből
keletkezett, ami kb. sandbox egyesítést jelent.

Használata egyszerű, de parancssort igényel:

sbmerge.exe Print [opcionális paraméterek]

sbmerge.exe Apply [opcionális paraméterek]

A Print-tel kiírathatjuk a sandbox-beli változásokat, az Apply segítségével pedig egyesíthetjük a

thinstallált programot a sandbox-szal. A sandbox az Apply alkalmazása után törlődni fog. Az opcionális
paraméterekért lapozd fel a Thinstall súgóját.

Valószínűleg az sbmerge-re csak nagyon ritkán lesz szükséged, ha lesz egyáltalán. A ThinReg nevű
segédprogramot sem nagyon kell portable programok készítéséhez használni. Ennek segítségével a
thinstallált programot tudjuk a számítógépen regisztrálni, konkrétan parancsikonokat tudunk vele
létrehozni, fájltípusokat asszociálni, uninstall információkat rakni a Programok telepítése és törlése
vezérlőpult-elemhez, meglévő hozzárendeléseket megszüntetni. Ezek portable programok esetében
nem létfontosságú elemek, és mivel a ThinReg valós fájlrendszerben és registryben eszközölnek
változtatásokat, így fennáll annak a veszélye, hogy miután elhagyjuk a gazda számítógépet az USB
kulcsunkkal együtt, nyomok maradnak ténykedésünk után, illetve megváltoztatjuk a már meglévő
beállításokat, stb. A ThinReg használatához ugyancsak a Thinstall súgóban találsz bővebb infót.

25
 | Linkek
Igen, ezek már az utolsó sorok, amint azt a szakasz címe is mutatja. Két fórumot tudok ajánlani
azoknak, akiket jobban érdekel a portable világ - az egyiken portable programok tömkelege vár
felfedezésre, a másikon pedig ezen felül hasznos tanácsokat, (lóverseny)tippeket is találhatunk.

FileCatchers fórum portable topikja:

http://www.filecatchers.com/forum/index.php?showforum=80

ProjectPortables fórum:
http://projectportables.org/forum

Utóbbi oldalon ráadásul olyan zseniális moderátorokkal is összefutthattok, mint pl. ezen sorok írója
(feltéve, hogy még nem moderálta ki önmagát). Mindkét oldalon az angol a beszélt nyelv, és regisztrálni
is kell.

Ha a fenti oldalakon sem találnánk meg a hőn áhított portable programot, forduljunk bizalommal a
Google-hoz. De csak óvatos bizalommal, mert az ismeretlen oldalakról letöltött portable veszélyes
is lehet - nem kimondottan a vírusokra/trójaikra gondolok, inkább azokra a portable-kre, amelyek
teleszemetelik a rendszert, megváltoztatnak fontos beállításokat, stb. Az ilyen esetek miatt ajánlatos
valamilyen módon tesztelni a letöltött portable-t. Ezt megtehetjük virtuális operációs rendszeren,
vagy olyan programok segítségével, amelyek összehasonlítják a rendszer két állapotát - jelen esetben
a rendszer állapotát a portable indítása előtt és a portable bezárása után. Erre tudom ajánlani a Total
Uninstall nevű programot, amely külön kilistázza a fájlrendszerbeli változásokat a registry változásokat,
illetve azt is, hogy milyen driver vagy service települt a gépünkre. A Total Uninstall így arra is nagyon
jó eszköz, hogy megnézzük, van-e driver vagy service ”akadálya” a tervezett thinstallálásnak.

Ha pedig végképp sehol sem találnánk meg a még hőbben áhított portable-t, akkor nincs más
hátra, mint hogy magunk készítsük el. Ehhez tudom ajánlani a ”Hogyan készítsünk Portable-t
Thinstall segítségével” c. művet.

26
 | Utószó
Remélem, sikerült némi betekintést nyújtanom a Thinstall-lal készített portable programok témájába.
Eredetileg kisebb lélegzetű ”művet” terveztem közkézre bocsátani, de bízok benne, hogy a
bőbeszédűségem senkinek sem fog különösebb problémát jelenteni.

A ”profi thinstalláló” szint eléréséhez ennek az irománynak az elolvasása édeskevés. Ha már

otthonosan mozogsz a Thinstall súgójában, és a neten se tudnak sok újdonságot mondani a Thinstall-
szakértők, akkor már jó úton jársz a siker felé. De ehhez a szinthez sok gyakorlás, problémamegoldás
szükséges, illetve az igazán profik esetében az ízes magyar káromkodások könyv nélküli ismerete is
elengedhetetlen.

Ez az egész Thinstall-dolog viszonylag új még, de egyre többen vesznek részt

benne. Nemcsak felhasználók, hanem cégek is - a Thinstall csak egy a sok
közül, amelyik virtualizációs megoldást kínál (a Microsoft is betette a lábát erre
a piacra, bár amit eddig mutatott, azzal nem fényezte csillogóbbra hírnevét).
A Thinstall ismertsége abból ered, hogy ezt az igényt a lehető legegyszerűbb
módon elégíti ki, illetve abból, hogy jól használta ki az ”underground”
hirdetési lehetőségeket is. Itt konkrétan arra az esetre gondolok, amikor a
portable-forradalom egyik korai úttörőjét (ha nem a legkoraibbat), mikicun-t
felhívta Jonathan Clark, a Thinstall vezére (lásd tenyérbemászó kép), és
megállapodtak abban, hogy mindaddig nem fog problémát csinálni abból,
hogy warez programok készítésére használjuk a programjukat, amíg feltüntetjük, hogy az Thinstall-
lal készült. Persze mindez nem lenne elegendő a sikerhez, ha maga a program nem lenne elég jó. Erre
pedig, azt hiszem, elég bizonyíték az a nem olyan régi bejelentés, miszerint a vmware felvásárolta a
Thinstall-t. Hogy ennek pozitív vagy negatív hatása lesz-e a portable-k terén, az még a jövő zenéje. A
vmware-t ismerve viszont minden esély megvan arra, hogy jó irányba fog továbbfejlődni a program.

27