A buheráló kedvü Wayteq (és Wayteq klón) tulajdonosok biztosan találkoztak már ezzel a fájlal. Közismert tény hogy YFAPP.WZP tömöritett formában tartalmazza az alkalmazó felületet és ha reset után a kari gyökerében van, jóváhagyás után frissiti a RF2 tartalmát. Még azt is meg kell emlitenem hogy, habár a fájl neve ugyanaz, tipusonként más-más tárban (RF2-n belül) csomagolja ki a cuccot: YFAP20, YFAP30 vagy YFAPP. A tár neve gyorsan kiderithető ha egy hex szerkesztővel megnézitek a fájl elejét.

Mert hogy 2db Wayteq tulajdonosa vagyok, már régóta piszkálta a fantáziámat hogyan lehetne ezt a fájlt PC-n ki/be csomagolni. Töbször is nekifogtam de abba maradt mert mindig más jőtt közbe. Pár hete véletlenül rábukkantam egy Luigi Auriemma nevü úriember oldalára, akinek (látszólag) az az életcélja hogy minden létező PC játek tömöritett adatbázisát ki akar csomagolni. Írtak egy script értelmező programot (QuickBMS), amiben minden ismert tömöritő algoritmust és azoknak a kombinációjat lehet aránylag egyszerü scriptekből használni. A száz körüli script listájában találtam egy WZP kicsomagolót is, ami lényegében arra volt jó hogy rámutatott a WZP fájl szerkezetére viszont nem árult el semmit arrol hogy milyen algoritmussal tömöritették. Erre magamnak kellett rájőnnöm, sok-sok tesztelés után: zlib, közös erővel készült és nem utolsó sorban ingyenes! Ezek után írtam egy saját programot ami hibátlanul kicsomagol mindenféle WZP-t de jőtt egy ötletem: ha már ki tudom csomagolni, miért ne tudnék adott tár strukturából WZP fájlt késziteni? Végül ez is meg lett, de erről tőbbet a cikk végén.

Haladott buherátorok részére be szeretném mutatni a WZP fájl strukturáját. Első sorban tudnotok kell hogy 2 különálló részből tevődik őssze, tartalmuk bizonyos pontig eggyezik. Csak úgy lehet értelmes adatokhoz jutni ha mindkét szakaszt párhuzamosan olvassuk, ehez meg szügség van a 2-ik szakasz fájlon belüli címére. Nem nehéz megtalálni hex szerkesztő segitségével(*) : a WZP fájl vége felé meg kell keresnetek ezt a 4 bytos aláírást FF D9 03 04 (little endian*). Az aláírást követő 2 byte - a fájlok és a tárak ősszege, 4 byte- a fájlok őssz mérete majd 4 byte - a keresett cím. Értelemszerüen, az első szakasz címe 0x0.

* Ha másképp nem adott, minden modern proceszor a számértéket "little endian"(LE) rendszerben tárolja. Ez azt jelenti hogy ha a szám tőbb byte-ból tevődik őssze, az alsóbb rendü byte címe legalacsonyabb. Példa: 10.000 (tizedes) = 0x2710 (hex) 4 byte-ban mint 10 27 00 00 lessz tárolva. A hex szerkesztő alap helyzetben LE formában fogja mutatni a számokat mert a fájl tartalmát növekvő címek szerint írja ki. A következőkben 0x"szám" normál hex-et jelent nem pedig LE-t.

Szakasz fejlécek:

I szakasz
2 byte - aláírás, mindig 0xD8FF
2 byte - adat tipusa, mindig 0x0403
2 byte - verzió, eddig mindig 0x000A volt
2 byte - tömörités módja- ha 0x0000: a fájl nincs tömöritve, ha 0x0008 akkor zlib tömrités
2 byte - utolsó változás órája - nem használt, mindig 0x0000
2 byte - utolsó változás dátuma - nem használt, mindig 0x0000
4 byte - CRC - ha CRC=0x0000 akkor az adatok egy tárra mutatnak, másképp fájlra
2 byte - tár név vagy fájl név betük száma (ASCII, tartalmazza a lezáró 0x00 értéket is)
- ASCII fájl/tár neve

II szakasz
2 byte - aláírás, 0xD8FF
2 byte - tipus, mindig 0x0201
2 byte - jelen verzió, 0x000A
2 byte - szükséges verzió, 0x000A
2 byte - flag, nem használják, mindig 0x0000
2 byte - tömörités módja, mint feljebb
2 byte - idő, 0x0000
2 byte - dátum, 0x0000
4 byte - CRC, mint feljebb
2 byte - fájl név/tár név betük száma
4 byte - töredékek száma - 0x00 : tár bejegyzés, másképp fájl bejegyzés
- ASCII fájl/tár neve + záró 0x00

Abban az esetben ha a töredékek szama 1 vagy tőbb, a II-ik szakaszban minden töredékhez még tartózik:
4 byte - töredék valós mérete, byte-ban
4 byte - töredék tömöritett mérete, byte-ban
4 byte - attribútum (tőbbet erről a végén)

Maga a tömöritett töredék az I-ő szakaszban, rögton az ASCII név + záró 0x00 után található. Ha tőbb van belőllük, ezek szép sorjában követik egymást az I-ő szakaszban.

Jó szokásomhoz híven, minden cikkez egy saját keszitményű PC programot csatolok, ami innen tölthető le. Használata aránylag eggyszerü. Inditás után ki kell választani hogy mit is akarunk: WZP-ből kimásolni a fájl állományt vagy fájl állományból WZP-t csinálni. Ha ki akarjátok bontani, a program csinálni fog egy uj tárat abban a tárban ahol YFAPP.WZP van. A tár neve potosan az lessz mint ami magában a WZP fájlban jelenik meg: YFAPP, YFAP20 vagy YFAP30. Erre az al-tárra a következőkben mint "gyökér"-re fogok utalni.
Vigyázat: ha utólag, esetleges menü változtatásokat követően vissza szándékoztok csomagolni WZP formába és ezt másokkal meg akarjátok osztani, sem a győkér nevet sem pedig annak al-tár neveit ne változtassátok hacsak a menü módositások nem követelnek más al-tár neve(ke)t is. Úgy kell felfogni a dolgot hogy ha az adott WZP másik gépre kerül akkor az működőképes kell hogy legyen.
Becsomagoláskor a gyökeret kell betallozni. Ezek után meg fog jelenni egy attribútum választási lehetőség. Mit is jelent ez a bizonyos attribútum? Őszintén szólva fogalmam nincs! Látszólag egy belső jelzés ami szerint a gyártó meg tudja külömböztetni a verziókat, mert semmi más jelentőséget nem találtam. Lényegében teljesen mindeggy hogy mi van ott. A listában megjelenő értékeket statisztikai szempontok szerint tettem be, úgy hogy csomó WZP-t néztem meg és a bennük talált attribútumokból listát csináltam. A lista elsőként megjelenő értéke volt leggyakrabb adott "gyökér" név esetében, ajánlom hogy ezt választjátok, de elvileg lehet a listában levő értékek bármelyike mert ezek mind valódi, létező, gyári értékek.

Egyéb programmal kapcsolatos tudnivalók:
1. Bele van épitve a ki/be-tömöritő dll, ennek neve zlibwapi.dll. Induláskor ellenőrzi hogy lékezik-e a dll abban a tárban ahonnam inditották és ha nem találja, "kiböki" magából. Ezzel a megoldással meg akartam kimélni a felhasználót attol a kíntol hogy ide-oda másolgassa a dll-t.
2. Nagy tőbbsége az általam ellemzett YFAPP.WZP fájloknak a "gyökér" bejegyzéssel kezdődik, ezért a program is így fogja tömöriteni az állományt. De... találtam pár régi tipusú WZP-t is, ezek OS17 és korai OS32(C) gépekből származnak, melyek egyenesen az első fájlal kezdődnek. Ezen esteket a progim (talán) nem fogja szeretni de ha ki is bontja, visszarakni már csak a "gyökér" kezdő bejegyzéssel fogja.
3. Ha bármilyen rendelleneséget tapasztalnátok (hiba üzenet, stb.), jelezzétek. Ilyen esetekben jó lenne ha feltennétek valahová azt a WZP fájl ami a hibaüzenetet váltotta ki.
4. Megtörténhet az hogy egy kibontott állományt semmi módositás nélkül visszacsomagoltok és az eredő fájl nem tökéletesen eggyezik az eredetivel. Ez nem hiba és azért van mert eredetileg a tárak/fájlok nem ABC sorrendben hanem ki tudja milyen logika szerint kerültek bele. A program viszont az al-tárakat és fájlneveket abban a sorrendben csomagolja őssze ahogy a PC oprendsere azokat ki adja, általában ABC sorrendben, akár tár név, akár fájl név, keverve, adott szinten. A gyökér után 1 szintel lejebb megy, az első al-tárba, stb. Programozói szemszögből egy ismeretlen méretü törzs-ág-levél tipusú struktura (ilyen a PC fájl szerkezete) bejárásának módja érdekes téma, nem is itt akarom ezt fejtegetni, viszont erre a célra a legkézenfekvőbb eljárás egy jól megirt rutin ami saját magát hívja (rekurens). A programban ezt használtam: lényegében végig jár egy adott szintet (ágak+levelek), majd az első ágon(tár) lemegy, leltároz mindent, első ágon lemegy, stb., addig amig nincs több ág(tár). Visszatérve a külömbségekre, azok abbol (is) adódhatnak hogy milyen eljárással lett bejárva az adott fájl struktúra, de ez abszolut nem érdekes kicsomagolás szempontjából mert az eredmény(kicsomagolt tárak és fájlok) mindig ugyanaz lessz.