Kilka Słów o Pakerach

Właśnie, te packery, który wybrać, czym pakować? Takie i podobne pytania zadają sobie użytkownicy ATARYNY, gdy próbują cokolwiek spakować... Ale zacznijmy od początku...

Zaczęło się od tych najprostszych, właściwie to trudno nazwać je packerami, były to programy, które wczytywały program do bufora blok po bloku i usuwały zbędne zera, a do programu nagranego dodawały procedurkę czyszczącą pamięć lub jej nie dodawały, lecz to już inna sprawa. Ale dajmy spokój. Jeżeli ktoś tego nadal nie rozumie, to niech postara się zdobyć "Zagęszczacz" Dariusza Rogozińskiego lub program "Compress" (N. Hegeman). Efekty pracy takich programów były raczej śmieszne, jednak niektórzy do dziś ich używają.

Potem przez długi czas była cisza... Aż tu pewnego słonecznego dnia dotarł do mnie "Cruncher v2.69" autorstwa Magnusa. Od razu wziąłem go na warsztat i... okazało się, iż jest to tylko prosty "char-packer". Jednak w tamtych czasach dawał on zaskakujące efekty.

Program został podzielony na dwie części: packer i linker. Ten pierwszy był odpowiedzialny za wczytanie, spakowanie i zapisanie spakowanego programu na dysk z cruncherem. Drugi natomiast odczytywał spakowany program, dołączał do niego nagłówki, depacker i inne bajery. Tak spreparowany program można było zapisać na dysk w postaci strawnej dla DOS-u.

Niedługo jednak był on w użyciu, gdyż Mr. Magnus wypuścił na atarowską scenę (?) "Cruchera 4.64" - jest on bardzo podobny do poprzednika, podobny algorytm kompresji, poprawiona czołówka i parę innych szczegółów. Ogólny algortym kompresji poległ na tym, iż obieraliśmy następującą metodę:

    $81-$ff   - ile niespakowanych
    $01-$7f   - ile spakowanych
    $80 $xxxx - bajtów niespakowanych
    $00 $xxxx - bajtów spakowanych

(kreska "-" oznacza od - do)

I tu swego rodzaju ciekawostka, identyczny system kompresji stosuje program: Koala Microillustrator do kompresji rysunków...

Ale wracajmy do rzeczy, wszyscy zaczęli używać wspaniałego "Crunchera 4.64" i nagle jak z nieba spadł "Cruncher 5.0", to jak zwykle nasz niestrudzony Magnus. Nagle coś się zmieniło, z pewną taką nieśmiałością po niego sięgnąłem... Drżącymi rękoma włożyłem dyskietkę do stacji i odpaliłem nowo zdobyte cacko...

Na pierwszy rzut oka taki sam jak poprzednik (4.64). A może coś spakujemy? Wziąłem jakąś syfną gierę i zaczęło się. Bip, bip, bip - wczytało się, pytanie o "step" - eeee, pewnie to samo co 4.64, bums i wcisnąłem "1" - kolorowe paski ukazały się moim oczom...

Nagle zdębiałem: "Select offset 1-6"??? Co to do diabła ma znaczyć? Tym razem też wcisnąłem "jedynkę"...

Poczekałem jakieś 15 minut, aż dziwne cyferki znikną z przed moich oczu, odpaliłem linkera i o mało nie spadłem z krzesła... Program skrócił się ponad 50%, byłem w szoku, nie wiedziałem jak to jest możliwe (wtedy byłem młody i głupi...), wyczytałem z instrukcji, że jest to pierwszy cruncher sekwencyjno - bitowy na Atari. Zacząłem dokładniej przyglądać się jego działaniu...

Pierwszy przebieg to nic innego jak "Cruncher 4.64", drugi zaś to nic innego jak "Imploder". Stop! Stop! Po co pierwszy przebieg? I co to jest "Imploder"? Imploding (w bardzo wielkim skrócie) to taka metoda kompresji, która wyszukuje powtarzające się sekwencje i zastępuje je adresem tej znalezionej wcześniej.

A offset to nic innego jak obszar wstecz, od którego będą poszukiwane sekwencje. Jak go dobierać? Jeżeli zależy nam na szybkości, to jak najmniejszy, gdy mamy duuużo wolnego czasu możemy spróbować większego offsetu. Zbyt dużych nie opłaca się zbytnio wybierać, ponieważ "Cruncher 5.0" potrzebuje wtedy więcej bitów, aby określić adres wstecz, a najczęściej znajdują się sekwencje dwu, trzy lub cztero bajtowe. Myślę więc, że optymalnym rozwiązaniem jest offset 3 lub 4.

Są oczywiście programy, które o wiele lepiej spakują sie na większym offsecie, jednak ja nigdy się w to nie bawię... Niech spakowany program będzie nawet o kilkaset bajtów dłuższy, a ja nie będę musiał czekać godziny albo dłużej.

Minęło trochę czasu, powstało CODE3. Pewnego dnia Soused Teat coś pakował i zaczął się denerwować czasem działania "Crunchera 5.0". Więc postanowił napisać własnego crunchera, szybszego oraz efektywniejszego... Zaczęło się, powstała ich cała seria: Code3 CRUNCHER; 1.0, 2.0, 3.0, 2.2D.

Crunchery te pracowały tylko z rozszerzoną pamięcią, bo spakowany program zapisywały do dodatkowej pamięci (a nie na dysk tak jak "CRUNCHER 5.0"), z pewnością przyspieszyło to ich pracę, ale niektórym to się nie podobało i powstał ostatni z nich "Code3 Cruncher 2.2D" - miał być on dołączony do "Music ProTrackera", który miał być sprzedawany w Mirage'u, ale pan Tomasz M. zawalił sprawę i prawdopodobnie nie wyda tego programu...

Wszystkie te crunchery też posiadają paker wstępny (podobny jak w "Cruncherze 5.0") oraz linker...

Więc czym się różnią?

      CODE3 CRUNCHER         CRUNCHER 5.0
               Pakowane obszary:
        $0480-$06ff          $0480-$06ff
        $0a00-$cfff          $0c00-$cfff
        $d800-$ffff          $d800-$ffff
    Nie może zachować       Może zachować
           stosu.         niespakowany stos.

Poza tym "Code3 Cruncher" jest szybszy od "Crunchera 5.0", posiada szybszy depacker, wersje 2.2D i 3.0 posiadają licznik przy depackingu (zamiast pasków). Rozpoznaje wszystkie formaty dysków: single, medium, double, 360 KB, a nawet 720 KB. "Cr. 5.0" rozpoznaje tylko single i medium. Przez zastosowanie specjalnego drzewa binarnego do oznaczania długości sekwencji znacznie wzrosła efektywność pakowania.

Najwolniejszy ze wszystkich jest "Code3 Cruncher 3.0", ale to dlatego, że pakuje on tylko na offsecie: $8000, a potem adresy sekwencji wysyła metodą Shanon-Fano, co daje większą efektywność w niektórych przypadkach. Wszystkie packery z serii "Code3 Cruncher" posiadają tylko jeden "INIT" podczas wczytywania, natomiast "Cruncher 5.0" posiada ich aż trzy.

Walety i zady, czyli zalety i wady...

Nie wszystkim przypadło do gustu, iż wszystkie przedstawione tu crunchery zmieniają strukturę pliku i nie da się jej po spakowaniu odzyskać. Wszystkie te crunchery niszczą też obszar DOS-u po rozpakowaniu (oprócz 4.64), co uniemożliwia pakowanie programów współpracujących z DOS-em. Posiadają packer wstępny, który pogarsza wyniki kompresji tego drugiego, a czasami wręcz uniemożliwia to spakowanie programu, ponieważ nie mieści się on w wyznaczonym obszarze pamięci.

Szto dziełać?

Gdy pakowany program nie zmieści się we wstępnym, to możemy próbować pakować go "APC Packerem"... Niestety, ten program też ma swoje wady... (Sorry APC, mam nadzieję, że nie zabijecie mnie za tę krytykę)

  1. Nie działa z moim rozszerzeniem pamięci 192 KB.
  2. Jako algorytmu kompresji używa algorytmu takiego jak "Crun. 4.64".
  3. Program musi kończyć się nagłówkiem: $2e0 - $2e1, gdyż loader nie wie kiedy skończyć wczytywać, gdy nagłówek $2e0 - $2e1 znajduje się na początku lub w środku pliku loader kończy wczytywanie na tym nagłówku.
  4. Gdy ktoś nie posiada systemu QMEG lub Freezer, nie może używać tego programu, ponieważ po spakowaniu, aby wyjść do linkera należy zresetować komputer, aby wczytać packer jeszcze raz. Niestety program po resecie skacze "w maliny" i na tym możemy zakończyć swoją działalność. Komputera nie możemy wyłączyć, ponieważ spakowane dane zostają zapisane do dodatkowej pamięci.
  5. Więcej nie potrafię powiedzieć o tym programie, ponieważ nic nie udało mi się nim spakować...

Więc co nam pozostało?

Nie martwcie się, powstało bowiem parę prostych packerów znacznikowych, które zachowują strukturę pliku. Ja posiadam tylko trzy:

  1. Power Packer/Linker 64kb version
  2. Fpack
  3. Super Packer 1.0

Na początek zajmiemy się pierwszymi dwoma. Na pierwszy ogień pójdzie...


PPlink 64kb

Prosty algorytm kompresji (RLE -€“ Run Length Encoding), np. Ciąg "AAAAABBCCCCDDDDDDEEEEfghi" zostanie zakodowany jako: (@=znacznik)

            ile
            #
            @5ABB@4C@6D@4Efghi
            # #
     znacznik czego

Proste? Jak pęczek drutu w kieszeni! Jakie mamy możliwości?

Przy zapisie możemy nawet zrelokować depacker. No właśnie, depacker jest trochę za długi jak na RLE! Niestety w wypadku tego programu mamy ograniczony bufor na pakowany program. Packer ten zawiera kilka błędów, co w niektórych przypadkach uniemożliwia jego zastosowanie.


A co może Fpack?

Program ten ma, przede wszystkim, nieograniczony bufor, ile wczyta tyle spakuje, potem wypluje i znów doczyta... Dość krótki depacker ($50 bajtów). Możemy wybrać, który blok mamy spakować, a który nie (czasami zaleta, a czasami wada, bo gdy mamy 652 nagłówki do spakowania, to co?).

Co do wad to:

  1. Brak możliwości relokowania depackera (zawsze: $400 - $44f). 2."Kwasi się" przy niektórych programach.
  2. Bardzo prosta metoda kompresji, jakieś zmutowane RLE...

Co to jest "Super Packer"?

Jest to program niejakiego BeweSofta, dość dziwnego czeskiego programisty... Metody kompresji: Aż trzy: RLE, LZ77, Static Huffman

O ile RLE i Huffman działają dość szybko, to LZ77 (Lempel Ziv 1977 r.) jest tak kosmicznie wolny, że szlag może człowieka trafić. (wolniejsze od "Crunchera 5.0" na offsecie 4!). Jak zwykle metoda najwolniejsza jest najbardziej skuteczna, ale to już inna sprawa... Na szczęście autor umożliwił wybór metody kompresji użytkownikowi...

Program ma wspaniałe możliwości edycji pliku binarnego (dodawanie bloków, init-ów, runów, procedurek przepisujących). Niestety, moim zdaniem, zbyt mały bufor!

Bewe założył słownik dla LZ77 wielkości 4 KB, ale niestety nie wykorzystuje pamięci pod systemem operacyjnym... Mamy więc około 30 KB bufora (od MEMLO do $97dc)... To trochę mało... Autor wspomina o możliwości dzielenia pliku na kilka częci i pakowaniu oddzielnie każdej z nich, potem należy usunąć z każdej depacker z wyjątkiem pierwszej... Dla mnie trochę za dużo zabawy...

Program ten jednak posiada wiele zalet i myślę, że mimo kilku drobnych wad nadaje się do użytku... Oczywiście możliwość relokowania depackera gdzie się chce...


To wszystkie packery do programów binarnych, które posiadam... Jeżeli nic nikomu nie odpowiada, a ma Amigę, może próbować swych sił w pakowaniu "Power Packerem" na Amidze... Jest to dość prosty "Imploder".

Jak to robili inni?

Swego czasu Mr. Magnus pakował "Cruel Cruncherem" na Commodorku. Skąd ten wniosek? Niedowiarków proszę o zerknięcie na oryginały firmy SONIX, został nawet SYS 2059, program jest ulokowany od $0801, skąd my to znamy?

Our-5oft uparcie używa "Power Packera" na Amidze ("Toms Copier" czy "Intel Outside").

Czy można pakować tylko pliki binarne? Nie! Można pakować wszystko, od tekstów zacząwszy na samplach skończywszy... Co? Jak? Gdzie? Jak pakować sample? Jeśli Cię to interesuje to przeczytaj artykuł pt. "SFDN Packer".

W kolejnych numerach tego zinu postaram Wam się przybliżyć wszelkie znane mi metody kompresji danych... Od RLE zacząwszy na Explodingu skończywszy...

Powodzenia w pakowaniu danych życzy
Seban

Nota redakcyjna: Jeszcze w zamierzchłych czasach doszły do mnie informacje o powstaniu nowego produktu ("PackMania"), który miał być owocem współpracy dwóch członków grupy WFMH (Magnus & Tori). Rezultatami kompresji program ów miał przewyższać osiągnięcia słynnego "Power Packera". "PackMania" miała być programem komercyjnym. Niestety, jak dotychczas, nie posiadam owego crunchera.

- P.W. -