STONECRACKER V4.10.2 PRO
StoneCracker (dále jen STC) verze 4.10.2 je executable / data / absolute
file packer, není to archiver (jako LhA). STC byl navrhnut tak aby byl
jednoduchý na ovládání, rychlejší a výkonnější než jeho konkurence (PowerPacker,
Imploder...).
STC pracuje s algoritmem založeném na principu LZ, nesoucí název S404. Dále
využívá ke kompresi stc.library a stc020.library (pokud máme mikroprocesor 68020
a vyšší, lze tak využít nové a rychlejší adresovací módy). K dekompresí pak lze
využít stc.library - pracuje podobně jako powerpacker a explode.library. STC lze
odstartovat ze CLI i z Workbenche a lze využít grafickou nadstavbu (GUI) nebo
příkazový řádek (user OS 1.3):
Při spuštění StoneCrackeru ze CLI můžeme vložením tzv. klíčových slov program
plně ovládat. Pokud napíšeme "stc ?", objeví se tato "nabídka":
" StoneCracker 4.10.2 pro " 1993 Jouni "Mr.Spiv" Korhonen (SWSW)
Usage: stc [-<options>] [sourcefile(s)] [destdir]
Where <options> are one or more of:
-fe Executable & normal decruncher -p0 Packmode 16K (14 bits)
-fel Executable & library decruncher -p1 Packmode 8K (13 bits)
-fa Absolute & normal decruncher -p2 Packmode 4K (12 bits)
-fap Absolute & plain decruncher -p3 Packmode 2K (11 bits)
-fak Absolute & killer decruncher -p4 Packmode 1 K (10 bits)
-fd Data file -L? Load address (?=hex)
-o0 Overwrite existing file -J? Jump address (?=hex)
-o1 Dont overwrite existing file -D? Decruncher address (?=hex)
-s? Security Length (?=dec) -U? USP address (?=hex)
-i? DataID (? ".something") -S? SSP address (?=hex)
-d Show interval defaults -R? SR after decrunching (?=hex)
* Multifile
Note! Default [destdir] is [sourcedir], not the dir you runned StoneCracker
from. All options are care sensitive! Following options have default values : -D
is $100 and -J is -L if not specified.
If you want to contact me : [email protected]
Majitelé OS 2.x+ dají jistě přednost ovládání pomocí špičkového grafického
interface.
STC si "pozná" dřívější i verzi S403 a tak lze tyto na rozdíl od CrunchManie
(v 1.0 1.6) pohodlně rozpakovat.
Všechny decrunchovací rutiny (DOS i NDOS) podporují CACHE a VBR. Pokud hodláte
používat STC graphics user interface pod OS 1.3, musíte si obstarat
reqtools.library pod OS 1.3 a gadtools13.library (ta je u nových Amig v ROMce).
Ke spuštění STC potřebujete jen:
1. Amigu (???)
2. 512 Kb CHIP
Testovány byly systémy 1.3, 2.04 i 3.0, vše OK. Součástí balíku je také zdroják
decrunchera pro kódery.
Co lze pakovat?
1. Libovolná data - obrázky, texty, hudební moduly
2. Execute soubory - STC "zná" tyto hunky:
hunk_header, hunk_code, hunk_data, hunk_bss, hunk_reloc32, hunk_symbol,
hunk_debug, hunk_external, hunk_name and hunk_end. Ostatní hunky budou označeny
za chybné. -> Bohužel nezná hunk_overlay, takže nelze spakovat například DPAINT
4.
3. Absolute soubory - pro NDOS. Tento typ programů nepodporuje multitasking, je
to specialita pro kódery, takže se tím zde nebudeme zabývat, protože je tento
článek určen i začátečníkům (a nejsme si jistí, zda je to zajímá). Upozorníme
vás jen, že STC neumí fixovat hunky na absolute, proto zde nelze nahrát execute
soubor ( -> GURU). Absolute decruncher podporuje VBR i CACHE (kóder ví, co to je
a pro ostatní to nemá význam).
Ovládání STC je díky perfektní grafice a reqtools library interface naprosto
jednoduché a perfektní; aniž bychom se museli zdržovat nějakou tvorbou scriptu,
jako je tomu u PowerPackeru, dosáhneme zpakování třeba stovek souborů najednou 3
(slovy: třemi) stisky klávesy na myši! !
TEST
Pro srovnání a vaši lepší představu jsme zapakovali 4.65 MB (přesně 4875142
bytů) hudebních modulů PowerPackerem (samozřejmě s využitím skriptu) a STC (zde
žádný skript není, ale reqtools.library umožňuje pohodlný multiselect - to je
výhodnější, vše na maximální účinnost, u PP s maximálním paměťovým bufferem
(konfigurace: Amiga 1200 68020/14 MHz bez FAST RAM).
STC:
pakovaná délka: 3.16 MB (přesněji 3311656 bytů)
doba pakování: 7 minut 48 sekund
doba depakování: 55 sekund
PP:
pakovaná délka: 3.19 MB (přesně 3345092 bytů)
doba pakování: 18 minut 10 sekund
doba depakování: 2 minuty 10 sekund
Jak je patrné z testu, STC je v pakování více než dvakrát rychlejší a je také
účinnější v kompresi. V depakování je, jak jinak, taktéž rychlejší STC více než
dvakrát, bezmála třikrát. Další podrobnosti o STC se dozvíte z originálního
manuálu dodávaného v balíku.
Varování (v originálním manuálu nenajdete):
Protože všechno má své chyby, i STC se bez nich neobešel, jsou však v porovnání
s výkonem zanedbatelné.
STC se tak docela nedrží zásad systémového programování a negeneruje mezi
hranami hunků END_HUNK symboly ( -> $000003F2), pro depakování si nevytvoří
buffer stylem BSS ale generuje tzv. dlouhý hunk, tzn. že hunk long je definován
jako delší, než ve skutečně (je vyhrazen při loadu větší memory blok) je a
pakovaná data jsou v tomto jediném hunku "roztažena". To má své výhody i
nevýhody. Mezi nevýhody paní především nemožnost použít takto pakované soubory
jako rezidentní (jak jsme již řekli, rozpakovaný soubor je z původního
pakovaného roztažen přes původní kompresovaný -> dojde ke korupci dat...) a dále
pak nemožnost spakovat systémové knihovny (v LIBS:) a zařízení, případně
přehrávací rutiny k Eagleplayeru 1.50. Další nevýhodou je to, že z výše
uvedených důvodů příkaz VERSION "nepřečte" ze spakovaného souboru verzi
spakovaného programu. (řetězec $VER: xx). Toto naštěstí u většiny kompresovaných
programů nevadí, ale přesto StoneCrackerem nedoporučujeme z důvodů kompatibility
se systémem (zjištění verze) pakovat WB, systémové příkazy ale třeba dlouhé
user-programy: PageStream, Scala, PPaint, Excellence, ProWrite... JEDINÝM 100%
systém respektujícím kompresorem je IMPLODER v3 a v4 (na PowerPacker
zapomeňte!). Vše, co bylo výše uvedeno u STC jako handicap, Imploder zpracovává
bezchybně, čistě (na depack si vyhrazuje BSS buffer apod.), takže jím lze
spakovat všechny příkazy WB (na rozdíl od PowerPackeru jdou pak kupodivu i
zpustit), zjistit verzi spakovaného souboru (version soubor) či knihovny
(version knihovna), spakovat lze tudíž i systémové knihovny v LIBS:
(nepotřebujete PPLoadSeq) (pozor! jelikož v tomto případě pro změnu zase
knihovny nemusí respektovat systémové programování, některé se po opětovném
depakování mohou stát nefunkčními (paradoxně opět viz STC library!), avšak kdo
by rozpakovával již spakovanou knihovnu?]. Ovládání Imploderu je ve srovnání se
STC primitivní a v neposlední řade neumí pakovat data.
Post Scriptum
Při příležitosti recenze nového packeru je vhodné uvést na pravou míru
ožehavý problém s tzv. "Efficiency" "Packmode" - "Crunchoffset" - "MaxDistance"
"Crunching Depth". Takto se nazývá ÚČINNOST KOMPRESE u různých pakovacích
programů, konkrétně u PowerPackeru, STC, CrunchManie, Imploderu Double Actionu.
Jelikož mají všechny jeden a tentýž význam, povězme si, co to pro nás znamená.
Princip komprese obecně spočívá v prohledání určitého paměťového bufferu, a
pokud jsou nalezeny stejné znaky, je jejich umístění a hodnota zaznamenána do
"tabulky" (ta je pak součástí archivu). A ÚČINNOST právě definuje VELIKOST,
resp. DÉLKU onoho paměťového bufferu, jelikož ten nemůže být "nekonečný". Pokud
by totiž byl buffer příliš velký, stalo by se, že zmíněná tabulka by "přerostla"
velikost vlastních pakovaných dat a to je pochopitelně nežádoucí.
STONECRACKER
- zde jsou k dispozici následující účinnosti:
1. BEST - 16 k
2. GOOD - 8 k
3. FAIR - 4 k
4. LEECH - 2 k
5. EHHEHE- 1 k
A co to pro nás znamená? BEST - neznamená paradoxně nejlepší, ale to, že je
prohledáván největší paměťový buffer a to konkrétně 16 Kb, což je 16 384 bytů.
Doporučujeme použít na data (exe a cokoliv) delší (stejná) než tato délka, pak
bude tato volba skutečně nejúčinnější. GOOD doporučujeme použít na data do 8 KB
délky, analogicky pak další "packmody" na odpovídající délky dat. Je nesmyslné
pakovat 1024 bytů dlouhý soubor volbou BEST, také to o něco málo (řádově pár
desítek bytů) prodlouží archiv; proč prohledávat 16 KB buffer, když pakujeme
pouze 1 KB?
POWER PACKER
- zde máme k dispozici "pouze" symbolické označení:
1. BEST - největší "range", bude prohledána max. velikost
2. VERY GOOD
3. GOOD
4. MEDIOCRE
5. FAST - nejmenší velikost bufferu
IMPLODER 4
1. 128 bytes
2. 256 bytes
3. 512 bytes
4. 1024 bytes
5. 1792 bytes
6. 3328 bytes
7. 5376 bytes
8. 9472 bytes
9. 18688 bytes
Stejný význam jako StoneCracker.
Crunch Mania v1.4 -1.6
Crunch Mania je v tomto směni "nejinteligentnější". Pokud nahrajete kratší
soubor, než je nastaven Crunchoffset, tak je Crunchoffset zkrácen na délku
souboru. Crunchoffset je implicitně (po spuštěni) nastaven na maximum, tedy
$4200 v hexa formě, což je decimálně 16896 bytů (buffer asi 16 Kb). Lze jej
nastavit jak hexadecimálně (uvedeme před znakem "$"), tak decimálně a to v
rozmezí $1-$4200 (při volbě 1 se nekompresuje, hádejte proč?). Systémový
decruncher CrunchManie není v těchto verzích ještě 100%, a tak některé soubory
nelze spakovat -> GURU...
Double Action 1.0
Stejné jako CrM, pouze pevně nastavené ofsety (až $11101 -~ 70 000 bytů).
Jinak je velmi pomalý a neDOSový...
Závěrem:
Nezáleží samozřejmě jen na velikostí prohledávaného bufferu, ale především
na pakovacím algoritmu toho kterého packeru. Žádný ze současných kompresorů
zatím nedosahuje účinnosti nejlepších archiverů, konkrétně LhA, je tedy co
dohánět. Ale nemyslete si, že lze jednoduše "vzít" LhA algoritmus a použít jej
na exe soubory...
Spoustu ušetřených bytů přeje autor.
Poznámka: StoneCracker je Gift-Ware (druh PD). Vytlačiť článok
Pozn.: články boli naskenované ako text a preto obsahujú aj zopár chýb. Taktiež neručíme za zdrojové kódy (Asm, C, Arexx, AmigaGuide, Html) a odkazy na web. Dúfame, že napriek tomu vám táto databáza dobre poslúži.
Žiadna časť nesmie byť reprodukovaná alebo inak šírená bez písomného povolenia vydavatela © ATLANTIDA Publishing
none
|