MIOTŁA - opis (część 3)


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.


Copyright © by MiniMax 1997/2007. All rights reserverd!