thinstall használata
TRANSCRIPT
Hogyan készítsünk Portable-t
T h i n s t a l l segítségével
1
| 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.
2
| 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.
3
| 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.
4
| 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).
5
| 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.
6
| 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.
7
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.
8
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:
9
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 Ha azt szeretnénk, hogy a thinstallált programunk testreszabott beállításokkal induljon, akkor 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).
10
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.
11
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.
12
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.
13
| 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•
14
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.
15
| 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...
16
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.
17
Á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.
18
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.
19
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 ProcessorOriginalSnapshot=C:\PROGRA~1\TH~BUR4W.VS\{55881~1.SNADestinationSnapshot=C:\PROGRA~1\TH~BUR4W.VS\{4D2C5~1.SNACapturedUsingVersion=3.332OutDir=binSandboxName=Atlantis_beallitasokDisableTracing=1InventoryName=Atlantis Word Processor
VirtualDrives=Drive=c, Serial=12345678, Type=FIXED;
[Atlantis.exe]ReadOnlyData=bin\Package.ro.tvrSource=%ProgramFilesDir%\Atlantis\Atlantis.exeWorkingDirectory=%ProgramFilesDir%\AtlantisFileTypes=.adprShortcuts=%Programs%;%Programs%\Atlantis;%Desktop%
[Uninstall.exe]Shortcut=Atlantis.exeDisabled=1Source=%ProgramFilesDir%\Atlantis\Atlantis.exeWorkingDirectory=%ProgramFilesDir%\AtlantisCommandLine=”%ProgramFilesDir%\Atlantis\Atlantis.exe” -uiIcon=%ProgramFilesDir%\Atlantis\Atlantis.exe,7Shortcuts=%Programs%\Atlantis
[patch.exe]Shortcut=Atlantis.exeDisabled=1Source=%ProgramFilesDir%\Atlantis\patch.exe
[TCMADMIN.EXE]Shortcut=Atlantis.exeDisabled=1Source=%drive_c%\Total Commander\TCMADMIN.EXE
[TOTALCMD.EXE]Shortcut=Atlantis.exeSource=%drive_c%\Total Commander\TOTALCMD.EXE[cmd.exe]
20
Shortcut=Atlantis.exeDisabled=1Source=%SystemSystem%\cmd.exe
[regedit.exe]Shortcut=Atlantis.exeDisabled=1Source=%SystemRoot%\regedit.exe
[iexplore.exe]Shortcut=Atlantis.exeDisabled=1Source=%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 nincs kedvünk kideríteni, hogy milyen nevet adtunk meg, vagy adott meg a készítő (ha 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.
21
| 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.
22
| 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.
23
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.
24
| .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
25
| 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.
26
| 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.
27
| 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.