|
POKUSY I PUŁAPKI OPTYMALIZACJI REJESTRU
MIOTŁA, od początku była projektowana z myślą o całkowitym zautomatyzowaniu
procesu optymalizacji (w rozumieniu odchudzania) Rejestru, ale nie tylko zwykła
wygoda przyświecała genezie MIOTŁY.
Ważne, jeśli nie najważniejsze, były względy bezpieczeństwa Systemu - kwestia
szczególnie paląca w przypadku wszelkich operacji na bazie Rejestru
kondensującego całą konfigurację Windows. Odchudzanie Rejestru polega na jego
pełnej przebudowie - wszystkie klucze Rejestru zostają od nowa scalone w zwartą
strukturę, a puste pola po odinstalowanych kluczach (lub manualnie skasowanych
wartościach) po prostu znikają.
Brzmi to pięknie, lecz w praktyce nie wszystko musi pójść gładko. Przede
wszystkim proces scalania-odbudowy Rejestru daje się zbyt łatwo przerwać, a
niedokończony Rejestr jest tyle wart ile miejsce, które zajmuje na dysku (czyli
kilkadziesiąt groszy). Bez niego nie ma Windows, w których rola statycznego
jądra (vmm32.vxd) została ograniczona na rzecz konfigurowalnego Rejestru.
CO MOŻE PRZERWAĆ PRACĘ?
Choćby już wciśnięcie CTRL+C /Break, nie mówiąc o przerwie w zasilaniu
komputera. A skoro cały proces trwa dość długo, to o nieszczęście nietrudno.
Jeśli ktoś posiada sprawną (oraz aktualną) kopię awaryjną, to może przywrócić
Rejestr do stanu używalności. Ale umówmy się, że nie są to te czynności, które
chciałby wykonywać typowy fanatyk graficznego interfejsu. Jedynym sposobem
uczynienia tego procesu ze skrajnie ryzykownego całkowicie bezpiecznym jest -
jak należy sądzić - przeniesienie całej pracy poza katalog Windows (rzeczywista
nazwa nie ma tu znaczenia: MIOTŁA w ver.3.0 sama odnajduje właściwy).
POMOC W PODJĘCIU DECYZJI
W typowych warunkach większość wbudowanych w skrypt zabezpieczeń nie będzie
potrzebna. Właśnie utworzony, mniejszy (z reguły) Rejestr zostanie przeniesiony
do katalogu Windows, gdzie zastąpi dotychczasowy. Dodatkowo, aby użytkownik nie
tracił poczucia kontroli nad dość zautomatyzowanym w sumie procesem, skrypt daje
mu możliwość anulowania wszystkiego, co oznacza rezygnację z zastąpienia starego
Rejestru nowym. W podjęciu decyzji pomoże przygotowane przez skrypt zestawienie,
pozwalające porównać wielkość Rejestru (konkretnie plików system i user) PRZED i
PO optymalizacji. Jeśli rezultat uzna użytkownik za satysfakcjonujący (tak jest
najczęściej - zwłaszcza przy pierwszych uruchomieniach skryptu) może śmiało
pozwolić, aby procedura dobiegła końca. Natomiast ktoś bardziej doświadczony
(obeznany z systemami DOS i Windows) ma jeszcze jedną możliwość: na etapie
pytania o zastąpienie Rejestru może przerwać (na ogólnie przyjętych zasadach)
wykonywanie skryptu, po czym zapoznać się z zawartością katalogu TEMP.
Najlepszym sposobem radykalnego przyspieszenia pracy jest skierowanie
wykonywania procedury na dysk wirtualny, tzw. RAM-dysk. Co mógłbym powiedzieć
dużo dobrego o RAM-dyskach. Pozwalają nie tylko skrócić (kilkakrotnie!) czas
dowolnej operacji plikowej, ale i uniknąć fragmentacji dysku twardego. Także z
tych względów skrypt wymaga podania litery najszybszego w systemie dysku, na
którym zostanie założony katalog TEMP (jeśli już istnieje to etap ten zostanie
pominięty).
Wskazanie na RAM-dysk (gdy jest zainstalowany, co zostaje także sprawdzone)
naprawdę wydaje się nie mieć wad.
Byle było chociaż do dyspozycji z 15MB (co wynika z rozmiarów Rejestru).
Obecnie nie jest ważne, z jakiego miejsca na dysku procedura zostanie
uruchomiona. Mimo iż do działania wymaga opuszczenia Windows i uruchomienia w
trybie MS-DOS, można się z tym wstrzymać i najpierw z poziomu Windows przejrzeć
wbudowaną pomoc (klawisz P z głównego menu). Można też zajrzeć do środka skryptu
po dodatkowe informacje zawarte w licznych komentarzach, co należy jednak robić
ostrożnie, by nie zmodyfikować czegoś przypadkowo.
Najlepszym sposobem nabrania zaufania do możliwości procedury jest jej
uruchomienie. Wszystkie komunikaty są po polsku, a - wedle opinii nie tylko
mojej - skromny interfejs nie musi iść w parze ze skromnymi możliwościami.
Pozdrawiam i życzę sprawnych i niezawodnych systemów operacyjnych.
D.F.
|