arhiveri.612mjova,
-> #607, darone>>> pkzip 2.04G. Nista znacajno nije promenjeno osim
> Ovi poŽeli ko ▒ez... ;)
je, sad ęe i shez87 ;)
arhiveri.613milan,
-> #611, ssokorac> Ja nisam skidao 'e', a bogami neęu ni ovaj, bar do ne dodju do 'z', tad
> nema dalje :). (2.05? ;).
C! Ondak sledi 2.041a.
Pl poz M
arhiveri.614vstan,
Pkz204g: u roku od trideset dana treca verzija
"najpouzdanijeg" arhivera ;>>
Pa sad neka dejanr prica bajke o doticnom ;)
( mislim na ono "arj je nepouzdan; zip je pouzdan")
Nadan se da toga nema u novim racunarima u umetku o
Pkz204c ;)
~
p.s.O ne, jos par Shez-ova :(
arhiveri.615dejanr,
-> #614, vstan>> Pa sad neka dejanr prica bajke o doticnom ;)
>> ( mislim na ono "arj je nepouzdan; zip je pouzdan")
MoČda su to bajke, ali to je i moje miźljenje o problematici.
Zasnovano na tome da sa PKZIP-om, koga intenzivno koristim veę
godinama, ni sa verzijom 0.92, ni sa 1.1, ni sa 2.04c ni sa
2.04e (za 2.04g ne znam jer se evo tek sad spremam da ga download-ujem)
nisam imao ni jedan jedini problem. Za razliku od toga, sa ARJ-om
koji sam tek umereno koristio (tj. tek bio poŽeo da ga ozbiljno koristim)
imao sam dva puta problem u vidu fajlova koji se ne mogu raspakovati, o
Žemu sam govorio u ovoj temi. I to u arhivama koje sam sam napravio,
ono źto nisam mogao da raspakujem arhive koje su mi drugi (uglavnom
banex :) snimali na diskete to i ne raŽunam, jer je problem veę stavljen
na duźu interakciji ARJ/cache (mada, ako sve drugo lepo radi sa cache-om,
onda je i ARJ bar delimiŽno kriv). Osim toga, PKZIP ima izvesne
redundantne podatke u arhivi koji olakźavaju oporavak fajlova posle neke
moguęe havarije, ARJ je na takve stvari mnogo osetljiviji. Zato je moj
zakljuŽak da je PKZIP pouzdan pa ga koristim (doduźe, uvek uradim i
jedno PKUNZIP -t kad zavrźim, ¬avo ne spava ;) a ARJ ne smatram dovoljno
pouzdanim i ne koristim ga, osim za ARJ E kada dobijem neki tako arhiviran
fajl. Sama Žinjenica da izlaze tri verzije ZIP-a u kratkom intervalu ne
govori baź mnogo o ozbiljnosti PKWare-a, ali opet, ako se na¬e neki bug
bolje da se ispravi nego da ostane.
Naravno, moČda ti imaź drugaŽije miźljenje, pa bi bilo lepo da ga
izloČiź i argumentujeź.
>> Nadan se da toga nema u novim racunarima u umetku o
>> Pkz204c ;)
Umetak se odnosi na PKZ204E - Žim je izaźao, tekst je povuŽen iz źtampe
i u potrebnoj meri dora¬en. Bilo je potrebno relativno malo dorada, ali
su one izvrźene.
arhiveri.616korvin,
-> #606, nenadb.
>> Aj lajk ARJ !!!
Apsolutno podrČavljam (reŽe Kradoman ) !! Kad iza¬e sledeęi ARJ ima da
źije ovu źaku jada, pa Dejanu neęe pomoęi ni milion izgovaranja na navodne
greźke ARJ-a :)
arhiveri.617ssokorac,
-> #614, vstan ─┼┤ Pkz204c ;)
Umetak je o PKZip 2.04e, tekst je o 'c', ali, ne brini, u sledeęim
RaŽunarima ęe biti 'Reply: Pet greźaka u pet verzija' ;) u kojoj ęe biti
spomenjen novi PKZip, koji, naravno, niko ne uzima za ozbiljno jer je 17.
uzastopna verzija za mesec dana...
arhiveri.618mjova,
-> #614, vstan> Pkz204g: u roku od trideset dana treca verzija
> "najpouzdanijeg" arhivera ;>>
Žuj, ide A, B, C, D, E, F pa tek onda G ;)) ima tu viźe od tri verzije
koje su stigle do nas ;))
ne znam źta ęe da rade kad 'potroźe' abecedu? moČda poŽnu ęirilicom? ;)
arhiveri.619ssokorac,
-> #615, dejanr ─┼┤ jedno PKUNZIP -t kad zavrźim, ¬avo ne spava ;) a ARJ ne smatram dovoljno
─┼┤ pouzdanim i ne koristim ga, osim za ARJ E kada dobijem neki tako
Zaźto ne bi onda i ARJ T pa bi i on bio 100% pouzdan?
arhiveri.620dejanr,
-> #618, mjova>> Žuj, ide A, B, C, D, E, F pa tek onda G ;)) ima tu viźe od tri verzije
>> koje su stigle do nas ;))
Nema, kaČe da su to neke interne revizije koje nisu izaźle van PKWARE-a.
InaŽe, od juŽe korisnica BIX-a mogu da download-uju PKZ204E.EXE, Žak
ga najaviźe i u ulaznom biltenu :) Kao da malo "kasne u fazi" ;)
arhiveri.621dejanr,
-> #619, ssokorac>> > jedno PKUNZIP -t kad zavrźim, ¬avo ne spava ;) a ARJ ne smatram
>> > dovoljno pouzdanim i ne koristim ga, osim za ARJ E kada dobijem
>> > neki tako
>>
>> Zaźto ne bi onda i ARJ T pa bi i on bio 100% pouzdan?
Hmmm... da znaź da ima neźto u tome źto kaČeź :)) Dakle, u skladu sa
onim vicem ("a źto ste vi istrebili Indijance?"): PKZIP brČe obavi posao :)
arhiveri.622korvin,
-> #615, dejanr>> na duźu interakciji ARJ/cache (mada, ako sve drugo lepo radi sa
>> cache-om, onda je i ARJ bar delimiŽno kriv). Osim toga, PKZIP ima
>> izvesne redundantne podatke u arhivi koji olakźavaju oporavak fajlova
>> posle neke moguęe havarije, ARJ je na takve stvari mnogo osetljiviji.
>> Zato je moj zakljuŽak da je PKZIP pouzdan pa ga koristim (doduźe, uvek
>> uradim i jedno PKUNZIP -t kad zavrźim, ¬avo ne spava ;) a ARJ ne
>> smatram dovoljno
Sa cache-om (i "programskim" kao źto je Hyperdisk i hardverskim IDE
sa cache-om mnogo toga ne radi kako treba :( ! Kada se radi sa arj-om,
najbolje je da se aruje na hard pa da se arhive bace na flopi i tada
sigurno (99,99%) neęe doęi ni do kakvih problema. Ako ARJ-u zadaź opciju t
on ęe da testira arhivu po zavrźetku i mirna bosna. meni se jedno 9-10 puta
desilo da mi rikne arhiva i to oko 70% sluŽajeva to je bila pkzip arhiva,
źto je izuzetno mnogo s obzirom da pkzip nisam skoro nikad do sada
upotrebljavao, osim kada sam raspakivao neki zabludeli fajl :) Kada sam tu
arhivu pokuźao da spasem sa PKZIPFIX redovno je pravio neke imbecilne
fajlove koji su navodno bili fiksovani (pre bih rekao nafiksani ;).
▒to se tiŽe novog PKZIP-a, njegova velika prednost je źto radi u 386 modu i
samim tim je izuzetno efikasan i brz, ali njegova veeelika mana je bilo i
ostalo cepanje arhiva... Kada u PKZIP budu ugradili opcije za seckanje
koje ima arj on ęe biti ubedljivo bolji, ali dotle ęe izaęi i arj koji ęe
da radi u 386 modu, tako da je malo verovatno da ęu ja Žesto upotrebljavati
PKZIP :))
arhiveri.623vvelisavljev,
Zna li neko kako se moČe odARJovati źifrovana ARJ datoteka?
arhiveri.624dejanr,
-> #63, adiklic>> Zna li neko kako se moČe odARJovati źifrovana ARJ datoteka?
Bojim se da to pitanje prevazilazi naźa "kriptoanalitiŽarska" znanja :(
Tj. garant to CIA ume da deźifruje, ali mi...
arhiveri.625vlad,
-> #623, vvelisavljev-> Zna li neko kako se moČe odARJovati źifrovana ARJ datoteka?
Lako, sa źifrom :)).
ARJ E -Gźifra ime_datoteke
Vladan
arhiveri.626ssokorac,
-> #621, dejanr ─┼┤ onim vicem ("a źto ste vi istrebili Indijance?"): PKZIP brČe obavi posao
A ARJ bolje ;). Pa, dobro, ne vredi raspravljati, niko ovde nikog neęe
ubediti... Dok ZIP ne poludi ;).
arhiveri.627vvelisavljev,
-> #625, vlad> Lako, sa źifrom :)).
>
> ARJ E -Gźifra ime_datoteke
Joź kad bi se setio źifreeeee. Problem je źto ne znam źifru.
arhiveri.628banex,
-> #615, dejanr>> ono źto nisam mogao da raspakujem arhive koje su mi drugi (uglavnom
>> banex :) snimali na diskete to i ne raŽunam, jer je problem veę
>> stavljen
Otkad banex koristi 2.39Beta ARJ nema viźe problema sa keźiranjem
flopija i pakovanjem multivolumena na isti. Sredili deŽaci :))
arhiveri.629vasic,
Ima li ko neźto u stilu dislite ili lzexe źto bi izaźlo na kraj sa
kompresovanim exe-om koji ima ovakav poŽetak?
> MZ.... ..5K...SEA-AXEInsufficient memory.
> $Invalid compressed file.
> $Invalid environment.
> $Unable to open file.
TaŽkama sam predstavio karaktere koji bi mogli da smetaju sezamu. A
ionako je to samo exe header. Nego, pogledajmo ostatak: SEA-AXE - da
nije to potpis arhivera?
arhiveri.630zorani,
-> #622, korvin## Sa cache-om (i "programskim" kao źto je Hyperdisk i hardverskim IDE
## sa cache-om mnogo toga ne radi kako treba :( ! Kada se radi sa
## arj-om, najbolje je da se aruje na hard pa da se arhive bace na
## flopi i tada sigurno (99,99%) neęe doęi ni do kakvih problema. Ako
## ARJ-u zadaź opciju t on ęe da testira arhivu po zavrźetku i mirna
## bosna. meni se jedno 9-10 puta =======
======
Pa da znaź, ako Jung uspe ono źto Vens i Oven ne uspevaju onda
ęe i najokoreliji zipovci promeniti dresove.
arhiveri.631bulaja,
-> #629, vasic│Nego, pogledajmo ostatak: SEA-AXE - da nije to potpis arhivera?
└───
Pretpostavljam da je u pitanju SEA ARC i verovatno je u pitanju self
extracting arhiva a ne kompresovani EXE. Njegov ARC format bi trebao da
je kompatibilan sa starim PKARC-om (mada nisam isguran kako sa SFX),
tako da pokusaj sa njime (\ibmpc\archiver\pkx35a35.exe).
arhiveri.632ndragan,
-> #615, dejanr/ govori baź mnogo o ozbiljnosti PKWare-a, ali opet, ako se na¬e neki
/ bug bolje da se ispravi nego da ostane.
«isto se pitam źta li ima od bagova u ARJu koje nismo pronaźli, a Jung
ęuti...
arhiveri.633vitez.koja,
-> #632, ndragan#=> Cisto se pitam sta li ima od bagova u ARJu koje nismo
#=> pronasli, a Jung cuti...
To onda i nisu bagovi... ali ce biti kad porastu :)
arhiveri.634mbole,
Da li neko zna Žime su spakovane datoteke na instalacionim disketama
Microsofta (one koje raspakuje expand), i gde bi to moglo da se na¬e.
arhiveri.635vasic,
-> #631, bulaja>│ Nego, pogledajmo ostatak: SEA-AXE - da nije to potpis arhivera?
>└───
> Pretpostavljam da je u pitanju SEA ARC i verovatno je u pitanju self
> extracting arhiva a ne kompresovani EXE.
Ali u pitanju JESTE kompresovani exe. Konkretno, igrica koju treba
'oduŽiti' od postavljanja glupih pitanja. :) TD-om sam naźao 'ono mesto'
ali sad ne mogu trajno da unesem izmene jer, naravno, ono źto je na
disku nema blage veze sa onime źto se na¬e u memoriji posle
raspakivanja. :(
arhiveri.636vcalic,
-> #635, vasic>> Ali u pitanju JESTE kompresovani exe.
Verovatno je da i SEA ima exe kompresor, ali s obzirom na njihovu
politiku on je verovatno komercijalan. Kad ih je PKWare razguzio na shareware
trČiźtu sa PKARC-om oni su se kompletno prebacili na komercijalno, pa je SEA
ARC sada komercijalni produkt, i verovatno da u sklopu tog paketa postoji i
EXE kompresor.
Samo, nisu mi jasni ti koji plaęaju silne pare za SEA arhivere i
kompresore kad su oni tri puta sporiji i dva puta slabije komprimuju od ZIP-a,
ARJ-a, LHArc-a i sl.
arhiveri.637dvidovic,
Uskoro novi arj. Verzija ęe imati oznaku 2.4x, a kako sad
stvari stoje neęe imati DPMI podrźku, poboljźana je multi
volume opcija, Jang razmiźlja o odvojenom arhiveru-dearhiveru
i o tome da ęe novi arj moęi da raspakuje arhive koje su pra
vljene nekim drugim arhiverima. ▒ta se Žeka? «eka se nova
'security enelope' na kojoj radi zajedno sa struletom za kri
ptovanje. Posao je, po reŽima samog RJ 'pri kraju'.
arhiveri.638darone,
-> #637, dvidovic>> Uskoro novi arj.
Jea :)
darone
arhiveri.639dejanr,
-> #637, dvidovic>> Uskoro novi arj. Verzija ęe imati oznaku 2.4x, a kako sad
>> stvari stoje neęe imati DPMI podrźku
Zanimljiva novost! ZnaŽi ne planira veęu reviziju (ona bi se
verovatno zvala 3.0). Sa jedne strane, moČda nije ni źteta za
DMPI jer ispada da i na ZIP-u ne radi sjajno, moČda se ni ne
moČe (joź) dobro napraviti :(
>> poboljźana je multi volume opcija
▒ta li tu ima da se poboljźava? :)
>> Jang razmiźlja o odvojenom arhiveru-dearhiveru
Od koga li je pokupio ovu ideju? ;)
>> Posao je, po reŽima samog RJ 'pri kraju'.
Bięe zanimljivo videti i uporediti sa ZIP-om. Ako je posao pri
kraju, poredięemo verovatno ARJ 2.40 i ZIP 2.04s ;)
arhiveri.640skoprivica,
-> #637, dvidovic│ vljene nekim drugim arhiverima. Sta se ceka? Ceka se nova
│ 'security enelope' na kojoj radi zajedno sa struletom za kri
│ ptovanje. Posao je, po recima samog RJ 'pri kraju'.
Sta ovo znaci? ( a sta je to strule? :)
arhiveri.641mjova,
-> #637, dvidovic> volume opcija, Jang razmiźlja o odvojenom
> arhiveru-dearhiveru
bljak, bolja je fora samo jedan fajl. moČda je brČa upotreba jer se ne
uŽitava ceo exe, ali kad bi mu dodao VROOM foru to bi reźilo i taj
problem.
> 'security enelope' na kojoj radi zajedno sa struletom za
^ (ko je to?)
arhiveri.642mjova,
-> #639, dejanr>>> Jang razmiźlja o odvojenom arhiveru-dearhiveru
> Od koga li je pokupio ovu ideju? ;)
meni nekako deluje da si suviźe pristrasan ;). pravo da ti kaČem, i u
tekstu u raŽunarima nahvali zip k`o da ti plaęaju reklamu, a tek na
kraju, sitnim ;) slovima, piźe kako zip ima problema i da postoji
moguęnost da raspakivanje zip-a neki put ne uspe. ;)
mene zip joź ni jednom nije zeznuo! moraęu da *poŽnem* da ga koristim ;).
sem toga, baź je hazard raspakivanje nepouzdanim arhiverom - uzmeź
kocu, smoki, grisine i ostalo, pa poŽneź ;))
arhiveri.643dejanr,
-> #642, mjova>> meni nekako deluje da si suviźe pristrasan ;).
Za razliku, pretpostavljam, od tebe? ;)
>> pravo da ti kaČem, i u tekstu u raŽunarima nahvali zip k`o da ti
>> plaęaju reklamu, a tek na kraju, sitnim ;) slovima, piźe kako zip
>> ima problema i da postoji moguęnost da raspakivanje zip-a neki put
>> ne uspe. ;)
Uvek se tako prikazuje softver. Najpre se opisuje ono źto softver nudi,
a onda i eventualni problemi pri njegovoj upotrebi. Slova nisu niźta
sitnija, i problemi su vrlo detaljno opisani, uz naglaźavanje da ih ja
liŽno nisam imao ali da su drugi prijavili da jesu. Mislim da je informacija
detaljna i korektno izloČena.
E sad, ako se tebi ne svi¬a tvrdnja da je ZIP 2.04 po svakom aspektu
superioran ARJ-u 2.20 i 2.39a osim po fleksibilnosti pri kreiranju
viźe-volumenskih arhiva, to je tvoje pravo. Ali ja viźe verujem u ono
źto pokaČu testovi brzine i duČine arhiva nego u argumente tipa "ja volim
ARJ/ZIP"
arhiveri.644vlad,
-> #639, dejanr->>> Jang razmiźlja o odvojenom arhiveru-dearhiveru
-> Od koga li je pokupio ovu ideju? ;)
Od koga god da je pokupio, meni se uopźte ne svi¬a. Mislim da je
princip "ceo arhiver u jednom fajlu" (zvuŽi li vam ovo poznato?)
bolji od rasparŽavanja na SAO ARJ-ove.
InaŽe jedva Žekam novi ARJ pa da lepo od ZIP-a kod mene ostane samo
PKUNZIP (iskljuŽivo koriźęen za REARJ :) ).
arhiveri.645dejanr,
-> #644, vlad>> > > Jang razmiźlja o odvojenom arhiveru-dearhiveru
>>
>> > Od koga li je pokupio ovu ideju? ;)
>>
>> Od koga god da je pokupio, meni se uopźte ne svi¬a. Mislim da je
>> princip "ceo arhiver u jednom fajlu" (zvuŽi li vam ovo poznato?)
>> bolji od rasparŽavanja na SAO ARJ-ove.
>> InaŽe jedva Žekam novi ARJ pa da lepo od ZIP-a kod mene ostane samo
>> PKUNZIP (iskljuŽivo koriźęen za REARJ :) ).
Je li, da ja moram na disku da drČim ceo ARJ da bi raspakivao ARJ
fajlove radi REZIP-a a ti da drČiź samo "manju polovinu" ZIP-a zvanu
PKUNZIP da bi mogao da radiź REARJ? :))
Neęe moęi, Jung radi za sve svoje verne korisnike pa i za mene, baź
kao źto je Katz radio za sve svoje verne korisnike pa i za tebe :)
arhiveri.646mjova,
-> #643, dejanr> E sad, ako se tebi ne svi¬a tvrdnja da je ZIP 2.04 po
> svakom aspektu superioran ARJ-u 2.20 i 2.39a osim po
> fleksibilnosti pri kreiranju viźe-volumenskih arhiva, to
> je tvoje pravo. Ali ja viźe verujem u ono
ma nije to, kreiranje viźe-volumenskih arhiva je zapoŽeo ARJ (o
tome nigde nisam video tekst) a to zipu smatraź glavnim novitetom.
ono źto je arj doneo pre nekoliko meseci (godinu?) je daleko viźe
nego źto je zip doneo sad.
no, nisam hteo to da kaČem, veę pitanje glasi: 'zaźto arj nije
opisan u R na ovaj naŽin?'. kad pogledaź moguęnosti jednog i drugog
arhivera vidiź da se neke stvari ne mogu ni porediti: brzina je
zaista na strani zip-a, ali pouzdanost ne viźe! sve ostalo (sem
brzine) je na strani arj-a - zato ga i koristim (Žak ga nisam ni
registrovao, respekta radi ;).
Žinjenica je da si pristrasan, i to moraź priznati ;).
arj je bolji! ;)))
arhiveri.647vstan,
-> #641, mjova> > 'security enelope' na kojoj radi zajedno sa struletom za
> ^ (ko je to?)
strule = strucnjak :))
arhiveri.648dejanr,
-> #646, mjova>> sve ostalo (sem brzine) je na strani arj-a - zato ga i koristim
Neęe biti, na svim testovima se pokazalo da PKZIP *viźe* arhivira.
Jedini izuzetak su arhive sa jako mnogo malih fajlova, gde su "tu
negde" ili je ARJ neźto bolji a i to, kako je neko na Sezamu lepo
objasnio, ide na raŽun pouzdanosti. Po meni, "glavne stvari" kod
arhivera su brzina i stepen kompresije, i po oba pitanja je
PKZIP 2.04 znaŽajno bolji. Ergo, ti ne koristiź ARJ zato źto je
*bolji* (jer nije) nego zato źto si navikao na njega *iz vremena*
kad je bio bolji (po oba aspekta!), zato źto ima fleksibilnije
reźen rad za viźestrukim arhivama ili iz nekih drugih iracionalnih
razloga :)
>> 'zaźto arj nije opisan u R na ovaj naŽin?'
Bięe prikazan, kada iza¬e nova verzija. Ne alfa/beta nego konaŽna.
Nema nikakve svrhe sada prikazati ARJ 2.20 iz jula '91, baź kao źto
nismo prikazivali ni ZIP 1.1 iz marta '90 - prikaz se uglavnom piźe
kada do¬e nova verzija.
Ako bude neźto stvarno dobro, moČda bude i umetak o njemu.
>> Žinjenica je da si pristrasan, i to moraź priznati ;).
Ne znam zaźto bi se testiranje uobiŽajenim i ponovljivim testovima
zvalo pristrasnost. Tebi je pristrasan svako ko ne misli kao ti.
>> arj je bolji! ;)))
Ako te Žini sreęnim da u to verujeź, samo napred. Jeste da Žinjenice
ne govore tako, ali tim gore po Žinjenice :)
Da te "uteźim", ja priliŽno verujem da ęe sledeęa verzija ARJ-a biti
bolja od PKZIP-a jer je inaŽe ne bi imalo mnogo smisla izdavati. A
onda ęe sledeęa verzija PKZIP-a biti bolja od te verzije ARJ-a. Od
te konkurencije ęemo samo imati koristi :)
arhiveri.649dcolak,
So, friends, BTW, kako se dobija onaj CRC checksum
koji ima svaki arhiver?
Treba drugu, pravi arhiver... Ex...
SLEDGE DAMMIR!
arhiveri.650prvul,
-> #649, dcolakŮ So, friends, BTW, kako se dobija onaj CRC checksum
Ů koji ima svaki arhiver?
Ů▄▄
PriŽali smo tome u nekoj od konferencija svojevremeno... kljuŽna
reŽ: polinom. InaŽe, ipak bih savetovao konsultovanje literature za
takve stvari, inaŽe se nema smisla baviti kompresijom. U krajnjem
sluŽaju, treba u literaturi proveriti da li je to źto ste izmislili
neko veę izmislio pre vas, a źto se jako Žesto deźava.
Usput, po direktorijumima ovde ima i sors za ZIP i za LHA, pa i za
ZMODEM protokol, a u svakom od njih sors za rad sa CRC-om...
arhiveri.651nboskovic,
-> #645, dejanr*> Je li, da ja moram na disku da drČim ceo ARJ da bi
*> raspakivao ARJ fajlove radi REZIP-a a ti da drČiź samo
*> "manju polovinu" ZIP-a zvanu PKUNZIP da bi mogao da radiź
*> REARJ? :))
Uzmeź UNARJ :))))
(c) klap
nikola
arhiveri.652vitez.koja,
-> #644, vlad#=> Od koga god da je pokupio, meni se uopste ne svida.
#=> Mislim da je princip "ceo arhiver u jednom fajlu" (zvuci
#=> li vam ovo poznato?) bolji od rasparcavanja na SAO
#=> ARJ-ove.
Da je postojao sao arj verovatno bi se padovi na sezamu pakovali njim...
Ovako je ostao jedinstven na celoj svojoj teritoriji, ali ne mozes da ga
pokrenes tamo gde nema dovoljno memorije.
arhiveri.653beast,
-> #648, dejanr>> Ako bude neźto stvarno dobro, moČda bude i umetak o njemu.
▒to govori da je novi zip stvarno dobar? :))
arhiveri.654dejanr,
-> #653, beast>> > Ako bude neźto stvarno dobro, moČda bude i umetak o njemu.
>>
>> ▒to govori da je novi zip stvarno dobar? :))
Da vidiź i jeste! Mnogo bolji od starog.
arhiveri.655darone,
-> #648, dejanr>> Nema nikakve svrhe sada prikazati ARJ 2.20 iz
>> jula '91
Samo da se zna: najnovija (novija? ima veę 6
meseci) verzija ARJa je 2.30 - naravno, zvaniŽna.
darone
p.s. kada je ARJ bio brČi od ZIPa?
arhiveri.656vlad,
-> #648, dejanr-> Nema nikakve svrhe sada prikazati ARJ 2.20 iz jula '91, baź kao źto
Zaźto stalno piźeź (i u RaŽunarima) o ARJ 2.20 kad i vrapci na grani
veę poodavno rade sa V2.30 (januar '92)? Neupuęeni ęe misliti da Jung
nije niźta radio od "jula '91", a u stvari Katz je spavao na
lovorikama malo duČe (skoro pune tri godine!).
Vladan
arhiveri.657vlad,
-> #645, dejanr-> Je li, da ja moram na disku da drČim ceo ARJ da bi raspakivao ARJ
-> fajlove radi REZIP-a a ti da drČiź samo "manju polovinu" ZIP-a
-> zvanu PKUNZIP da bi mogao da radiź REARJ? :))
I ja i ti drČimo na disku samo po jedan fajl "protivniŽkog" arhivera,
s tom razlikom źto ti moČeź i da ARJ-ujeź, a ja ne mogu da ZIP-ujem.
To je po meni jedna od negativnih posledica podele arhiver-dearhiver.
▒alu na stranu (a bilo je priliŽno duhovito), obrazloČięu detaljnije
zaźto mislim da poseban arhiver i dearhiver nisu dobra ideja:
1. Na disku mi stoji samo jedan fajl koji obavlja sve potrebne poslove
oko arhiviranja i dearhiviranja.
2. Nikada ne moČe da mi se desi da traČim gde mi je arhiver, a gde
dearhiver, a lakźe mi je da pamtim (i kucam) "ARJ e" i "ARJ a" nego
recimo ARJIVE i DEARJIVE.
2. Kada dajem arhivu nekom ko nema ARJ trudim se da pravim
self-extracting fajl, ili mu dam i (ceo) ARJ.
3. Pri svemu gorepomenutom, prostor koji mi arhiver zauzima na disku
uopźte mi nije vaČan.
Sve ovo su samo moji subjektivni utisci i uverenja (degustibus!).
Pozdrav, Vladan.
arhiveri.658dejanr,
-> #649, dcolak>> So, friends, BTW, kako se dobija onaj CRC checksum
>> koji ima svaki arhiver?
Ne znam koliko ęe ti ovo pomoęi, bojim se da nije neki naroŽit
checksum (16-bitni je) i da ga ne koristi ni jedan arhiver ali
ga sticajem okolnosti znam napamet pa ga upotrebi za neźto ako
budeź mogao :)
Ako te zanima poreklo, tako BBC raŽuna checksum programa koje
upisuje na trake:
AX je 16-bitni registar koji se sastoji od AH i AL, a C[1]...C[N]
su znaci Žiji se checksum raŽuna:
ah:=0
for i:=1 to n
ah:=ah xor c[i]
for x:=1 to 8
t:=0
if (bit 7 of ah)=1 then ax:=ax xor 0810h: t:=1
ax:=(2*ax+t) and 0FFFFh
next x
next i
arhiveri.659d.petrovic,
-> #651, nboskovicĂ> Uzmeź UNARJ :))))
A mi mu posle źaljemo .a01, a.02, ... ;))) Nek se pati kad hoęe da
koristi zip ;)))
P.S. Kad pravim neku temp. arhivu koristim zip, kad arhiviram podatke
koristim arj. Volim arj, ali koristim prednosti zip-a, źto su ljudi
ovde toliko konzervativni? PoŽeo jednom davno da koristi jedan pa
onaj drugi samo pljuje, neęe da vidi ima li tamo neŽeg lepog.
P.P.S. dejanr-e, zip ima veęu kompresiju, ali Žim pakujeź > 2 fajla
arj-ova je manja :)). A ja hoęu da mi manje mesta zauzme i da prenos
bude brČi, źta me briga kako je on to zapakovao :)
arhiveri.660dejanr,
-> #656, vlad>> > Nema nikakve svrhe sada prikazati ARJ 2.20 iz jula '91, baź kao źto
>>
>> Zaźto stalno piźeź (i u RaŽunarima) o ARJ 2.20 kad i vrapci na grani
>> veę poodavno rade sa V2.30 (januar '92)?
Jesam "kriv" za poruku 5.648 u kojoj jesam pomenuo ARJ 2.20 me¬utim u
"RaŽunarima" je testiran (tj. pore¬en sa ZIP-om) ARJ 2.30, a uz njega
ARJ 2.39a. To jasno piźe u zaglavljima tabele na strani 52 i na svim
slikama sa sledeęoj strani.
arhiveri.661dejanr,
-> #655, darone>> p.s. kada je ARJ bio brČi od ZIPa?
Verzija 2.30/2.39a je po brzini uporediva sa ZIP-om 1.1, pri Žemu
je ARJ u nekim sluŽajevima drastiŽno brČi, recimo kada se komprimuju
slike.
arhiveri.662dejanr,
-> #659, d.petrovic>> P.P.S. dejanr-e, zip ima veęu kompresiju, ali Žim pakujeź > 2 fajla
>> arj-ova je manja :)). A ja hoęu da mi manje mesta zauzme i da prenos
>> bude brČi, źta me briga kako je on to zapakovao :)
Ne bih bio tako siguran u to. Evo podataka za direktorijum od 87 (dakle,
nesumnjivo viźe od 2 :) fajla raznih tipova, ukupne duČine oko 1.2
megabajta:
ZIP204c ARJ230 ARJ239a
max kompresija 517021 517901 517828
stand. kompresija 520088 522605 518977
min. kompresija 563999 587530 581964
Kao źto vidiź, "zvaniŽni" ARJ je u sve tri konkurencije arhivirao loźije
od PKZIP-a dok je alfa verzija u jednoj od njih bila bolja a u dve loźija
(to je ujedno jedini put u mojim testovima da je ARJ bio bolji).
Situaciju u kojoj ARJ viźe arhivira od ZIP-a identifikovao je i objasnio
nkbog, moČeź da pogledaź starije poruke. Ukratko, ARJ moČe da bude neźto
bolji pri arhiviranju veęeg broja malih fajlova, ali na uźtrb sigurnosti
tj. to umanjuje moguęnost "oporavljanja" oźteęenih arhiva.
arhiveri.663d.petrovic,
-> #662, dejanrĂ> ZIP204c ARJ230 ARJ239a
Ă> max kompresija 517021 517901 517828
Ă> stand. kompresija 520088 522605 518977
Ă> min. kompresija 563999 587530 581964
Ne volim ovakve rasprave, ko li me je vukao za jezik? ;). Samo mi
reci koji su to bili fajlovi koje je pkzip -ex bolje spakovao od arj
a -jm ? Obeęavam da ti neęu replicirati O;)))
arhiveri.664dejanr,
-> #663, d.petrovic>> Ne volim ovakve rasprave, ko li me je vukao za jezik? ;). Samo mi
>> reci koji su to bili fajlovi koje je pkzip -ex bolje spakovao od arj
>> a -jm ? Obeęavam da ti neęu replicirati O;)))
Radi se o nizu fajlova razliŽitog sadrČaja (tekstovi, slike, programi,
arhive) koje sam pokupio iz mog "komunikacionog" direktorijuma. Uz ovu
poruku sam prikljuŽio spisak tih fajlova (koje sam, naravno, saŽuvao da
bi se test po potrebi mogao ponoviti), a sami fajlovi su raspoloČivi na
zahtev, malo ih je previźe za upload.
InaŽe, pri dizajniranju ovoga testa namerno sam bio "naklonjen" ARJ-u
pa sam ukljuŽio dosta relativno kratkih tekst fajlova. Naravno, bilo je
i par duČih arhiva.
Probaj i sam, ZIP-uj svoj SOR i DOWNLOAD dir, dobięeź da ZIP bolje
arhivira, obaźka źto je i brČi.
spisak.ziparhiveri.665mjova,
-> #649, dcolak> So, friends, BTW, kako se dobija onaj CRC checksum
> koji ima svaki arhiver?
nije to stvar arhivera, veę metoda za dobijanje źto pouzdanijeg i źto
kraęeg 'opisa' skupa bajtova radi provere ispravnosti...
izvorni kod ove funkcije (vrlo je kratka) imaź u datoteci snip*.* na
sezamu - malo potraČi, mislim da je u IBMPC\C diru.
arhiveri.666vlad,
-> #652, vitez.koja-> Da je postojao sao arj verovatno bi se padovi na sezamu pakovali
-> njim... Ovako je ostao jedinstven na celoj svojoj teritoriji, ali
-> ne mozes da ga pokrenes tamo gde nema dovoljno memorije.
▒ta ęeź, negde dobijeź, negde izgubiź. Da li je ARJ kriv źto Sezam
nema dovoljno memorije, pitanje je sad?
arhiveri.667peacock,
-> #648, dejanr#### Nece biti, na svim testovima se pokazalo da PKZIP *vise*
#### arhivira. ^^^^^^
To vise se meri sa par procenata. Necemo da ulazimo u
polemiku, nema potrebe, vreme ce da pokaze sta je bolje. No,
ovolike revizije necega sto se krckalo par godina i brze
ispravke uocenih nedostataka teraju me na pomisao da nas neko
oko ZIP-a zeza. Uzgred, mada nije mesto, tekst u Racunarima o
ZIP-u spada u najgore koje si napisao. Nesto si bio
indisponiran, znas ti to mnogo bolje.
arhiveri.668d.petrovic,
-> #667, peacockĂ> ovolike revizije necega sto se krckalo par godina i brze
Ă> ispravke uocenih nedostataka teraju me na pomisao da nas neko
Ranije smo se neźto kao pazili trojanaca? E, sad je pravo vreme da ga
neko poźalje kao 2.04h ;))), niko niźta neęe posumnjati ;)))).
Sumnjivo ęe biti tek kad stigne 2.05 :)
arhiveri.669dejanr,
-> #667, peacock>> > Nece biti, na svim testovima se pokazalo da PKZIP *vise*
>> > arhivira. ^^^^^^
>>
>> To vise se meri sa par procenata.
Dobro, par procenata, verovatno se u ovoj fazi razvoja arhivera
i ne mogu oŽekivati neke dramatiŽne razlike. Ali, makar i za Čilet,
PKZIP (osim u jednom sluŽaju) bolje arhivira. Uz to je znaŽajno
brČi. Ergo...
>> Necemo da ulazimo u polemiku, nema potrebe, vreme ce da pokaze
>> sta je bolje.
To je taŽno, samo źto je "problem" u tome źto ZIP i ARJ nemaju
iste poŽetne uslove. Ako malo proźetaź po USA BBS-ovima, videęeź
da je "sve" ZIP-ovano, ako nije ARC-ovano starim PKARC-om, a
ponegde se nai¬e i na neke totalno "leve" arhivere koje ovde
uopźte ni ne koristimo. ARJ kao ARJ postoji raspoloČiv za download,
ali je u slaboj upotrebi. Recimo na BIX-u (a mislim i u PC Magazine-u)
redovno odrČavaju listu "naj" PD/SW softvera, na kojoj prva mesta
obiŽno "uhvate" neki editori, ali PKZIP uvek drČi "jako" 3-4 mesto
(mene Žudi źto je recimo SCANV obiŽno 9-10 ili Žak ispadne sa liste,
oŽito se tamo koristi mnogo manje nego ovde). ARJ nikad na listi nisam
video. Prekasno se pojavio, a ZIP je bio "u pravo vreme na pravom
mestu". Ali je ARJ, po mom miźljenju, ipak odigrao (i igra) znaŽajnu
ulogu da malo "potera" autore drugih arhivera (a posebno PKZIP-a) da
se ozbiljnije potrude.
>> No, ovolike revizije necega sto se krckalo par godina i brze
>> ispravke uocenih nedostataka teraju me na pomisao da nas neko
>> oko ZIP-a zeza.
Sa ovim se potpuno slaČem, stvarno tako ne postupa ozbiljna firma.
Tj. ne mislim da je neozbiljno ispraviti bug ako se veę na¬e, ali
jeste neozbiljno posle tolikog silnog (kao) beta testiranja izbaciti
proizvod koji mora da se revidira 15 dana kasnije.
>> Uzgred, mada nije mesto, tekst u Racunarima o ZIP-u spada u
>> najgore koje si napisao. Nesto si bio indisponiran, znas ti
>> to mnogo bolje.
▒ta ti se ne svi¬a, tekst ili PKZIP? ;) ▒alu na stranu, takve pauźalne
kritike su ok, ali je od njih jako malo koristi, kao i od pauźalnih
pohvala. Bilo bi lepo da kaČeź źta ti se konkretno u tom tekstu ne
svi¬a - u njega je uloČeno mnogo viźe rada nego u standardan tekst poźto
je ura¬eno viźe veoma detaljnih testova (koji traaaaju) na raznim
konfiguracijama i za razne tipove datoteka. U tekstu su izloČeni
jasni argumenti koje, recimo u ovoj diskusiji u kojoj ZIP ima vrlo
jaku "opoziciju" (premda iz razloga koji su, sve mi se viźe Žini,
Žisto iracionalni), nisu negirani. Primeti da su ovde mnogi poŽeli
od "ARJ je po svemu bolji osim źto je sporiji" a evo sad smo veę,
argumentima (pored ostalog i iz reŽenog teksta) doźli do toga da su
i dotiŽni "oponenenti" "priznali" da je ZIP bolji *i* po brzini *i*
po procentu arhiviranja (doduźe, tek za par procenata :), dok je ARJ
fleksibilniji po pitanju rada sa viźe-volumenskim (nikako da na¬em
pravi za taj pojam :) arhivama. Uostalom, i to je reŽeno u tekstu.
arhiveri.670dejanr,
-> #666, vlad>> > Da je postojao sao arj verovatno bi se padovi na sezamu pakovali
>> > njim... Ovako je ostao jedinstven na celoj svojoj teritoriji, ali
>> > ne mozes da ga pokrenes tamo gde nema dovoljno memorije.
>>
>> Da li je ARJ kriv źto Sezam nema dovoljno memorije, pitanje je sad?
Nije, naravno. Ali ipak, PKZIP moČe da "u¬e" u to memorije koliko ima,
ARJ ne moČe. Plus za PKZIP, minus za ARJ (i Sezam ;)
arhiveri.671vasic,
-> #644, vlad> Od koga god da je pokupio, meni se uopźte ne svi¬a. Mislim da je
> princip "ceo arhiver u jednom fajlu" (zvuŽi li vam ovo poznato?)
> bolji od rasparŽavanja na SAO ARJ-ove.
MoČe to da ima i dobrih strana - manji exe, manji zahtevi za memorijom,
na kraju mogao bi joź i na sezamu da proradi. A onda do¬u prvi slobodni
viźestranaŽki izbori za zvaniŽni arhiver. ;)
arhiveri.672mbole,
-> #669, dejanr> viźe-volumenskim (nikako da
> na¬em pravi za taj pojam :) arhivama.
viźedelnim 8-)))
arhiveri.673vitez.koja,
-> #661, dejanr#=>>> p.s. kada je ARJ bio brzi od ZIPa?
#=> Verzija 2.30/2.39a je po brzini uporediva sa ZIP-om 1.1,
#=> pri cemu
Evo, sad su zamenili strane :)) Sad zagrizeni ZIPovac hvali ARJ, a ljuti
ARJovac mi ne veruje ;))) Svasta :)
arhiveri.674vitez.koja,
-> #657, vlad#=> I ja i ti drzimo na disku samo po jedan fajl
#=> "protivnickog" arhivera, s tom razlikom sto ti mozes i
#=> da ARJ-ujes, a ja ne mogu da ZIP-ujem. To je po meni
#=> jedna od negativnih posledica podele arhiver-dearhiver.
Probaj da drzis dva fajla protivnickog arhivera, ne boli mnogo ;)
arhiveri.676darone,
-> #661, dejanr>> >> p.s. kada je ARJ bio brČi od ZIPa?
>>
>> Verzija 2.30/2.39a je po brzini uporediva sa
>> ZIP-om 1.1, pri Žemu je ARJ u nekim sluŽajevima
>> drastiŽno brČi, recimo kada se komprimuju slike.
Ha!
▒teta źto nemam onu tablicu źto si je ostavio ovde,
pa moram sve da prekucavam :(((
TIFF slika duČine 1080186
vreme duČina arh. vreme raspak.
ZIP 1.10 max 0:55.5 54162 0:05.0
ZIP 1.10 min 0:06.0 44588 0:05.0
ARJ 2.30 max 2:18.5 40223 0:05.0
ARJ 2.30 min 0:09.5 59480 0:05.0
ARJ 2.39 max 1:32.0 40240 0:05.0
ARJ 2.39 min 0:08.5 58520 0:05.0
Ovo su podaci iz februarskih RaŽunara, svoj tekst.
E, sad, iz njega se mogu zakljuŽiti tri stvari:
1) ARJ *nigde* nije bio brČi od ZIPa
2) ZIP brČe i bolje pakuje TIF źrank metodom
nego implodeom.
3) Sva vremena raspakivanja su ista, źto mi
deluje malo 'nameźteno' (naravno, to ne
mogu niti Čelim da tvrdim), ne mogu da
verujem da je Žak vreme i ZIPa 2.04 isto!
Dakle, ovde ęe, izgleda, morati da se menja poneźto
:)
E sad, idem ja da napravim neki TIFF sliŽne duČine
i da ga ZIPujem i ARJujem, doduźe, nije ista
platforma, ali neki pokazatelj ęemo imati.
Tu bi kontinjud...
darone
arhiveri.677darone,
Last mesidČ voz... etc etc ajd sad da pogledamo
rezultate mog merenja :)
386/25Mhz, bez ikakvog keźa, maltene pjur vanila
plavi patlidČan dos (dakle nema QEMM i ostalo).
ELIZABET TIF 371127 02-23-93 2:07a
Ovo je fajl koji je komprimovan, najveęi TIFF koji
sam naźao. Koga zanima źta je, to je jedna fotka
koji je robert skenjirao.
veliŽina vreme_arh vreme_dearh
ZIP11MIN ZIP 136879 7.75 4.67
ZIP11STD ZIP 146674 26.03 4.17
ZIP11MAX ZIP 146674 25.60 3.79
ZIP20MIN ZIP 143132 7.69 4.34
ZIP20STD ZIP 127266 18.07 4.34
ZIP20MAX ZIP 125846 29.38 4.39
ARJ23MIN ARJ 155991 13.62 6.81
ARJ23STD ARJ 130040 30.82 6.43
ARJ23MAX ARJ 130040 31.25 6.97
Ovo je batch fajl kojim sam pravio arhive.
@echo off
pkzip11 -es zip11min elizabet.tif
pkzip11 zip11std elizabet.tif
pkzip11 -ex zip11max elizabet.tif
pkzip -es zip20min elizabet.tif
pkzip zip20std elizabet.tif
pkzip -ex zip20max elizabet.tif
arj a -m4 arj23min elizabet.tif
arj a arj23std elizabet.tif
arj a -m1 arj23max elizabet.tif
echo kraj :)
Izme¬u svake linije je bio, naravno, jedan
echo.|time >tajmerX
nemam ni jedan tajmer, a ovo je bilo najkraęe :)
X je cifra od 1 do a.
Dakle, standardna (difolt) metoda kompresije ARJa
je -m0 (źto i piźe kada se otkuca ARJ /?), dok je
Dejan dao neke tamo leve podatke za max i std
kompresiju kod ARJa :)
Nego, ARJ nije nigde brČi (jes, namuŽih se dok sam
to dokazao, ali :)) a nije ni bolji od 2.04.
Evo ga i batch za raspakivanje, da ne bude posle :)
@echo off
pkunz11 -o zip11min
pkunz11 -o zip11std
pkunz11 -o zip11max
pkunzip -o zip20min
pkunzip -o zip20std
pkunzip -o zip20max
arj e -jo arj23min
arj e -jo arj23std
arj e -jo arj23max
echo kraj :)
E sad, ja sam samo hteo da kaČem da vremena
dekompresija u RaŽunarima nisu taŽna i da je ARJ
*uvek* bio sporiji od ZIPa, bilo 11 ili 204. Eh da,
i joź neźto: ARJova standarnda i maksimalna
kompresija su jedno te isto (ja pod 'standardna'
mislim na 'podrazumevana', dakle bez parametara).
Poźto je ZIP tako teran na velikom testu, ja sam
tako terao i ARJ na svom.
Test ima i jednu veliku manu: nema ARJa 2.39 beta.
Zaźto? Ima jedan dobar razlog: ja ga nemam na
disku, a joź manje na disketama. Ajd ne zamerite.
darone
arhiveri.678dejanr,
-> #677, darone>> 3) Sva vremena raspakivanja su ista, źto mi
>> deluje malo 'nameźteno' (naravno, to ne
>> mogu niti Čelim da tvrdim), ne mogu da
>> verujem da je Žak vreme i ZIPa 2.04 isto!
Mereno je źtopericom (nekako slabo verujem u razne raŽunarske
tajmere... sem kad baź mora ;), dakle nije neka preciznost,
ali stvarno su se dobijala ista vremena. Sve je zaokruČivano
na pola sekunda.
>> Dakle, standardna (difolt) metoda kompresije ARJa
>> je -m0 (źto i piźe kada se otkuca ARJ /?), dok je
>> Dejan dao neke tamo leve podatke za max i std
>> kompresiju kod ARJa :)
>> ARJova standarnda i maksimalna kompresija su jedno
>> te isto (ja pod 'standardna' mislim na 'podrazumevana',
>> dakle bez parametara).
E da, i ja sam dok sam bio mlad i neiskusan mislio da je ARJ uvek
u modu max kompresije jer sam Žitao help, ali su me posle na Sezamu
nauŽili da postoji i switch -jm (ili tako neźto ;) koji stvarno
pravi maksimalnu kompresiju, veęu od -m0. Dakle, oni podaci u
tabeli za "maksimalnu kompresiju" su dobijeni sa ARJ -jm
E sad da li je to negde skriveno u helpu ili mora da se traČi u
uputstvu i zaźto je tako ... don't ask me :)
PS Poruka je, da izvineź na izrazu, malllkice konfuzna, prema tome sorry
ako neźto nisam dobro razumeo :)
arhiveri.679dusanp,
-> #670, dejanr=> Nije, naravno. Ali ipak, PKZIP moČe da "u¬e" u to
=> memorije koliko ima, ARJ ne moČe. Plus za PKZIP, minus za
=> ARJ (i Sezam ;)
Pitanje je vise upuceno ZZu, ali nema veze, mozda i Dejan
moze da mi odgovori:
Zasto ne biste ARJ (i druge ekstremne;) programe pozivali
pomocu spawnxxx biblioteke sa sezama. Sve i da nemate dovolj-
no memorije po nodovima (u sta sumnjam), potrebne za swap u
gornju memoriju, ova biblioteka moze da swapuje ceo program
na disk, ostavljajuci u memoriji parce od 208 bajtova. Mislim
da se ova biblioteka ne sudara sa mrezom i da moze fino da
zavrsi posao.
Ako ne bi moglo, zasto ne bi moglo?
arhiveri.680kuki,
-> #677, darone> Dakle, standardna (difolt) metoda kompresije ARJa
> je -m0 (źto i piźe kada se otkuca ARJ /?), dok je
> Dejan dao neke tamo leve podatke za max i std
> kompresiju kod ARJa :)
darone, nemoj da źiriź dezinformacije :)) difolt metoda nije m0, veę
m1. m0 sluČi da spakuje bez kompresije! sledi izvod iz pomenutog arj/?
m: with Method 0, 1, 2, 3, 4
m0: store (no compression)
m1: good compression (default)
m2: less memory and compression
m3: FAST! less compression
m4: FASTEST! least compression
dok se za max kompresiju koristi -jm (nije difolt)
Pozdrav, Vladimir
arhiveri.681darone,
-> #677, daroneNisam mogao da odolim a da ne napiźem odgovor na
svoju poruku ;) mnogo je zabavna :))))
>> Izme¬u svake linije je bio, naravno,
>> jedan echo.|time >tajmerX
Izme¬u svake dve linije, naravno :)
>> Nego, ARJ nije nigde brČi (jes, namuŽih se dok
>> sam to dokazao, ali :)) a nije ni bolji od 2.04.
E ovo nisam mogao bolje da odvalim :)))))
darone
arhiveri.682dvidovic,
-> #670, dejanr> Nije, naravno. Ali ipak, PKZIP moČe da "u¬e" u to memorije
> koliko ima, ARJ ne moČe. Plus za PKZIP, minus za ARJ (i
> Sezam ;)
Uz novi arj ęe ięi i nekakav arj_junior. Stvar neęe jesti
mnogo memorije.
arhiveri.683dejanr,
-> #679, dusanp>> Zasto ne biste ARJ (i druge ekstremne;) programe pozivali
>> pomocu spawnxxx biblioteke sa sezama. Sve i da nemate dovolj-
>> no memorije po nodovima (u sta sumnjam), potrebne za swap u
>> gornju memoriju, ova biblioteka moze da swapuje ceo program
>> na disk, ostavljajuci u memoriji parce od 208 bajtova. Mislim
>> da se ova biblioteka ne sudara sa mrezom i da moze fino da
>> zavrsi posao.
>> Ako ne bi moglo, zasto ne bi moglo?
Moglo bi, ako bi moralo. Ne u memoriju, jer na mreČi ima dosta
AT stanica sa 640 k ili megabajtom u kojima se gornja memorija
i ne koristi (a Žim ima jedna, kao da su sve takve jer su nodovi
ravnopravni) ali na disk bi moglo. Ali, za sada nema dovoljno
"jakog" razloga da se pribegava takvoj ipak potencijalno opasnoj
operaciji koja uz to poveęava "saobraęaj" po mreČi - ako do¬e
do nekog problema, node bi ostao bez osnovnog softvera pa mu se
verovatno ne bi ni moglo pomoęi. Dakle, samo pozivanje jednog
arhivera (kad veę drugi sasvim ok vrźi posao) nije dovoljan
motiv za takvu "avanturu".
Uzgred, novi Sezamov softver je mnogo "modularniji" i viźe oslonjen
na eksterne programe tako da ęe ostavljati znatno viźe slobodne
memorije. MoČda Žak dovoljno i za ARJ.
arhiveri.684prvul,
-> #676, daroneŮ3) Sva vremena raspakivanja su ista, źto mi
Ů deluje malo 'nameźteno' (naravno, to ne
Ů mogu niti Čelim da tvrdim), ne mogu da
Ů verujem da je Žak vreme i ZIPa 2.04 isto!
Ů▄▄
A, that one is easy... vremena su skoro ista zato
źto je i algoritam skoro isti... ARJ, implode i
deflate koriste u suźtini istu źemu: pakuju tako źto
zapiźu koliko bajtova unazad se treba vratiti i koliko
bajtova prepisati odatle... Tako, ako se neka sekvenca
bajtova ponovi, on samo zapiźe gde je prethodno pojavljivanje
te sekvence... e, algoritama za pakovanje na ovaj naŽin
ima puno, jer je problem brzo naęi gde je prethodno
pojavljivanje ako ga uopźte ima. Sa druge strane,
raspakivanje je trivijalno: treba samo Žitati ulazni
fajl i kada nai¬emo na oznaku "vrati_se_50_bajta_i_
prepiźi_12" to treba i uraditi...
arhiveri.685skoprivica,
-> #657, vlad│ dearhiver, a lakse mi je da pamtim (i kucam) "ARJ e" i "ARJ a" nego
bolje zapamti "ARJ x" (cisto dobronamerno)
arhiveri.686darone,
-> #678, dejanr>> Mereno je źtopericom (nekako slabo verujem u
>> razne raŽunarske tajmere... sem kad baź mora ;),
>> dakle nije neka preciznost,
Ja ipak prednost dajem raŽunarskom merenju vremena.
Zaźto koristiti reflekse kada to kanta moČe da
uradi za nas? Mnogo je preciznije.
>> E da, i ja sam dok sam bio mlad i neiskusan
>> mislio da je ARJ uvek u modu max kompresije jer
>> sam Žitao help, ali su me posle na Sezamu
Eh, ja nikada nisam bio neiskusan ;) jer sam jednom
od prvih prilika koristeęi ARJ, ubacio -jm u cfg
fajl. Eeee, otad proźlo vremena... zaboravi se :)
>> E sad da li je to negde skriveno u helpu ili
>> mora da se traČi u uputstvu i zaźto je tako ...
>> don't ask me :)
Ne mora, ima u ARJ /?
>> PS Poruka je, da izvineź na izrazu, malllkice
>> konfuzna, prema tome sorry ako neźto nisam dobro
>> razumeo :)
A da je malkice... Baź sam se ismejao :)) Pisana je
oko 3 izjutra, bio sam murtav umoran, pa nije ni
Žudo... nego ako treba, mogu ja i da ponovim ;)
darone
p.s. ne zakljuŽismo... arj negde brČi od zipa? ;)
arhiveri.687mbole,
-> #686, darone>>> Mereno je źtopericom (nekako slabo verujem u
>>> razne raŽunarske tajmere... sem kad baź mora ;),
>>> dakle nije neka preciznost,
>
> Ja ipak prednost dajem raŽunarskom merenju vremena.
> Zaźto koristiti reflekse kada to kanta moČe da
> uradi za nas? Mnogo je preciznije.
Zato źto je merenje źtopericom nezavisno od raŽunara. Nikad neznaź źta
moČe da uradi neki TSR ili sliŽno. ▒to se tiŽe preciznosti dalo bi se
izraŽunati da nakon odre¬enog broja ponavljanja operacije i merenja ukupnog
vremena (broj ne mora obavezno biti prevelik) źtoperica moČda da ispadne Žak
i preciznija, a u svakom sluŽaju greźka ęe biti dovoljno mala da se moČe
zanemariti
arhiveri.688dejanr,
U direktorijumu ARCHIVER je nova verzija SHEZ-a. Evo źta je novo u njoj:
Ň═══════════════════════════════════════════════════════════════════════════Ş
│ UPDATES/FIXES IN SHEZ Version 8.7 │
Ă═══════════════════════════════════════════════════════════════════════════Á
│ ************************************************************************ │
│ ************************************************************************ │
│ ************************************************************************ │
│ │
│ THE EXTERNAL CONFIGURATION FILE HAS CHANGED!!!!!!! TO CONVERT YOUR OLD │
│ SHEZ 8.6 CONFIGURATION FILE RUN THE CVTCFG.EXE PROGRAM. │
│ │
│ ************************************************************************ │
│ ************************************************************************ │
│ ************************************************************************ │
│ │
│ Additional corrections to identify PKZIP204E and G SFX files. │
│ │
│ Move now does a -w- when running PKZIP204. │
│ │
│ After converting archive, perform test, if test fails delete new archive │
│ and leave original intact. │
│ │
│ SHEZ can now process compressed files with a hidden and/or system │
│ attribute. │
│ │
│ When an error dialog box appears SHEZ will no longer pull keys from the │
│ recorded macro buffer to remove the dialog box. │
│ │
│ PKTMP environment variable will be set if not set already. │
│ │
│ ZIP2EXE program location is now specified in shezcfg. │
│ │
│ Added support for SQZ compression program, release 1.08.2 and 1.08.3 │
│ │
│ Added /C command line switch to specify a cfg filename on command line. │
│ │
│ Added /4 command line switch to activate 4DOS description display. │
│ │
│ Corrected screen scrolling problem when a compressed file contained │
│ exactly 39,59, or 79 etc, files. │
│ │
│ Corrected compressed file conversion routine to use a work drive when │
│ converting compressed files. │
│ │
│ Added item to SHEZCFG program to allow users to tell SHEZ the number of │
│ unique paths to handle inside compressed files. │
│ │
│ When converting from one compressed file type to another SHEZ can now │
│ convert nested compressed file with the following exceptions: │
│ │
│ 1) The nested compressed file MUST NOT HAVE A DIRECTORY associated │
│ with it. │
│ 2) Self extracting compressed files are not converted. │
│ 3) Only one level of nesting is handled. │
│ 4) The nested compressed file must be of a type that a compression │
│ program was specified for in the SHEZCFG setup. If a nested │
│ compressed file is an LHA file and the user did not specify the LHA │
│ compression program in the SHEZCFG setup then the LHA compressed │
│ file will not be converted. │
│ │
│ When copying or moving files F9 can now be pressed to bring up a │
│ directory tree to select the destination location. │
│ │
│ Corrected AV display when displaying ZIP compressed files created under │
│ PKZIP 204. │
│ │
│ Fixed 4DOS description display problem of sometimes showing the │
│ incorrect description for a file. │
│ │
│ Moved display of extract location to top line of compressed file window. │
│ │
│ Added ability to configure display color of the DOS window. │
│ │
│ (This one's for Owen and Barbara!!) │
│ This release allows you to use a different releases of PKZIP and │
│ PKUNZIP. I.E. You can use PKZIP release 110 and PKUNZIP release 204. │
└───────────────────────────────────────────────────────────────────────────┘
arhiveri.689peacock,
-> #654, dejanr>**<>> Sto govori da je novi zip stvarno dobar? :))
>**<
>**< Da vidis i jeste! Mnogo bolji od starog.
Najzad ti se ote prava rec(enica).
arhiveri.690peacock,
-> #669, dejanr Da ne quotiram prethodni deo poruke, bio si opsiran i u formi,
kako i treba da budes. I, sa njom se slazem. Ja sam se trudio
da u ovim diskusijama uvek gledam stvari sa funkcionalne
strane, ceneci maksimalnu pouzdanost. Nisam ortodoksni ARJ
fan, ali dok se novi zip dobro ne "ukrti", ne skidam novu
verziju. Meni je kod ARJ-a najznacajnija mogucnost arhiviranja
multivolumena na hardu, koje zatim kopiram. Brzo
(zadovoljavajuce) & prakticno.
>**< Sta ti se ne svida, tekst ili PKZIP? ;) Salu na stranu,
>**< takve pausalne kritike su ok, ali je od njih jako malo
>**< koristi, kao i od pausalnih pohvala. Bilo bi lepo da
>**< kazes sta ti se konkretno u tom tekstu ne svida - u
>**< njega je ulozeno mnogo vise rada nego u standardan
>**< tekst posto je uradeno vise veoma detaljnih testova
>**< (koji traaaaju) na raznim konfiguracijama i za razne
>**< tipove datoteka. U tekstu su izlozeni
Bio sam jasan, tekst u Racunarima. Cenim tvoj trud ulozen u
testiranja i merenja, ali je tekst lose napisan :( Kao sto
rekoh, znas ti i bolje. Jednostavno, bio ti je los bioritam
kada si ga pisao. Radio sam i ja taj posao, pa znam kako je.
Da ne bude nesporazuma, ti s jedan od autora cije pisanje
izuzetno cenim.
arhiveri.691janko,
-> #662, dejanr> Situaciju u kojoj ARJ viźe arhivira od ZIP-a identifikovao
> je i objasnio nkbog, moČeź da pogledaź starije poruke.
> Ukratko, ARJ moČe da bude neźto bolji pri arhiviranju
> veęeg broja malih fajlova, ali na uźtrb sigurnosti tj. to
> umanjuje moguęnost "oporavljanja" oźteęenih arhiva.
Tvrdnja, u ovom smislu, naČalost, ne stoji.
Postojanje centralnog direktorijuma u .ZIP arhivama NE poveęava
moguęnost oporavljanja oźteęenih arhiva.
I ja sam o ovome pisao ranije: PKZIPFIX program ne radi niźta
drugo do kreiranje centralnog direktorijuma arhivi u kojoj ne
moČe da ga na¬e. Kako dobija podatke za kreiranje centralnog
direktorijuma? «itajuęi fajl u ARC i ARJ stilu -- mora se
proŽitati redom fajl i traČiti lokalni hederi...
E sad, postojanje lokalnih hedera jeste, filozofski gledano,
redundantno, ali, da ih .ZIP arhiva nema, takve arhive bi bile
NESIGURNIJE za 'oporavljanje' od .ARJ arhiva. Ovako su JEDNAKO
sigurne kao i .ARJ arhive, bar źto se tiŽe informacija o
imenu fajla itd (informacijama koje se nalaze u hederima).
Ali, zlobnici ęe primetiti, sigurnost da su podaci spakovani
ispravno je VE»A kod .ZIP-a -- veęa verovatnoęa je da ęe se
ono źto izgleda uspeźno spakovano uspeźno proŽitati kod PKZIP-a
nego kod ARJ-a. Ako ne zbog drugih razloga, onda zbog toga źto
je pouzdanost PKZIP-a podvrgnuta daleko veęem testiranju. U
svetu sigurno postoji, po mojoj slobodnoj proceni, bar nekoliko
desetina puta viźe PKZIP korisnika nego ARJ korisnika. ARJ se
samo u nekim egzotiŽnim sredinama, kakva je npr. SEZAM
populacija, (ili, Žak, populacija nove Ju.) viźe raźirio. «ini
mi se, da se, ukupno, PKZIP viźe koristi. Ako moČete, pokuźajte
da saznate koliki je broj registorvanih PKZIP a koliki broj
registrovanih ARJ korisnika. Ili, u Žime je pakovana veęina
datoteka po svetskim BBS sistemima.
▒ta ęe PKZIP-u onda centralni direktorijum, kada smo videli da
ne donosi veęu pouzdanost nego kada ga ne bi bilo? Samo zato da
bi bio brČi u svakodnevnom radu. U raŽunarskoj tehnici, za sve
postoji tzv. 'tradeoff' ('krpi ovde, paraj tamo,' po naźki, ili
'ne moČe i vuk sit i ovce na broju') brzina -- prostor. U
trenutku kada je Kec dizajnirao PKZIP, jednostavno, toliko je
imao superiornije pakovanje da je sebi mogao da dozvoli luksuz
da doda i malo nekompresovanih podataka tipa direktorijuma.
Sada se, verovatno, i sam ponekad kaje, kada ga ARC-lajk
kompresori (ARJ je samo jedan od njih) izme¬u dve verzije
PKZIP-a 'uźiju' samo zato źto ostvare pribliČno jednak stepen
kompresije kao i on, ali se 'izvade' na to źto je Žitava arhiva
kraęa za koji bajt, jer nemaju centralni dir.
Na sreęu, postoji Žitava klasa sluŽajeva u kojoj ęe UVEK da
PKZIP bude brČi od ARJ-a, sve dok ARJ nema centralni
direktorijum. Npr. listanje sadrČaja arhive sa puno kratkih fajlova,
koje je ARJ, kao, efikasnije spakovao, ARJ ęe daleko
neefikasnije da izvede, jer radi na principu 'sile.' Ako hoęete
da se uverite u istinitost mojih tvrdnji, uvek moČete da
probate da merite ARJ V i PKUNZIP -v na fajlovima na disketi.
U istu klasu sluŽajeva spadaju i sva moguęa apdejtovanja veę
postojeęe arhive ili va¬enje samo odre¬enog fajla iz veęe arhive.
U oba sluŽaja ęe PKZIP biti primetno brČi.
Ukratko: PK proizvodi nisu dČabe u zaglavlju imali uvek 'FAST!' :)
arhiveri.692dusanp,
-> #687, mbole=> Zato źto je merenje źtopericom nezavisno od raŽunara.
=> Nikad neznaź źta moČe da uradi neki TSR ili sliŽno.
Hmm. Ja nikada ne bix dao prednost stoperici (i mojim
drhtavim rukama) u odnosu na tajmer. I sam Dejan kaze da
je kod stoperice tolerisao +-.5 sekundi. Ako se koristi
bilo koji interapt (pa cak i osmica), nek pogresi za dva
takta (2*16.2 deo sekunde), ali je preciznije od ruke&oka.
A kada se rade testovi, naravno da se iskljucuju svi moguci
tsrovi. Ostane samo files i buffers u configu...
Posto sam uvek zainteresovan za merenja, voleo bix da
cujem protivrazloge: zasto ne koristiti interapt tajmer?
ps:Bilo je nekada reci i o mnogo preciznijem interaptu od
osmice, nekom koji okida oko 1000 puta u sec. Tek tom
interaptu stoperica ne moze da priviri.
arhiveri.693dcolak,
-> #650, prvul│ Usput, po direktorijumima ovde ima i sors za ZIP i za LHA,
│ pa i za ZMODEM protokol, a u svakom od njih sors za rad sa
│ CRC-om...
Thanx. Pogledaęu. No, drug se izgleda oladio.
Sad se sprema za takmiŽenje 27. Ex...
SLEDGE DAMMIR!
arhiveri.694dcolak,
-> #658, dejanr│ Ne znam koliko ęe ti ovo pomoęi, bojim se da nije neki
│ naroŽit checksum (16-bitni je) i da ga ne koristi ni jedan
│ arhiver ali ga sticajem okolnosti znam napamet pa ga
│ upotrebi za neźto ako budeź mogao :)
Hvala. Kakav je da je, vaČno da se ima od Žega krenuti.
SLEDGE DAMMIR!
arhiveri.695dcolak,
-> #665, mjova│ izvorni kod ove funkcije (vrlo je kratka) imaź u datoteci
│ snip*.* na sezamu - malo potraČi, mislim da je u IBMPC\C
│ diru.
Thanx. Pogledaęu.
SLEDGE DAMMIR!
arhiveri.696peca.st,
-> #677, darone!-> arj a -m1 arj23max elizabet.tif
!!
Eh, darone, darone...
Maksimalna ARJova kompresija se dobija sa -jm a to kod tebe nigde nema...
P e C a
arhiveri.697dejanr,
-> #692, dusanp>> Hmm. Ja nikada ne bix dao prednost stoperici (i mojim
>> drhtavim rukama) u odnosu na tajmer. I sam Dejan kaze da
>> je kod stoperice tolerisao +-.5 sekundi. Ako se koristi
>> bilo koji interapt (pa cak i osmica), nek pogresi za dva
>> takta (2*16.2 deo sekunde), ali je preciznije od ruke&oka.
>> Posto sam uvek zainteresovan za merenja, voleo bix da
>> cujem protivrazloge: zasto ne koristiti interapt tajmer?
To je unekoliko pitanje razlike izme¬u apsolutne i relativne
greźke. ▒toperica je zaista neprijatan metod ako se meri neźto
źto traje par sekundi. Ali, recimo da podesimo bench test tako
da posao traje 5 minuta (a zaźto da ga ne podesimo ako ga ionako
sami izmiźljamo ;). Apsolutna greźka je i dalje 0.5 s, a relativna
greźka neźto kao (5*60 - 0.6)/300 = oko 2 promila. Dva promila je
veę toliko mala relativna greźka da je pore¬enje stvari koje se
mere i viźe nego dovoljno taŽno. To mu je otprilike kao kad neki
student na prvoj godini izmeri put od, recimo, 82 santimetra i
vreme od 19 sekundi (prvo merio lenjirom, drugo źtopericom) i
onda izraŽuna brzinu od 4.315789474 santimetra u sekundi. Time
je pokazao da ima digitron, ali i da ne zna fiziku, jer sve decimale
osim moČda prve nemaju nikakvog smisla.
Analogija nije naroŽito u vezi sa ovim o Žemu priŽamo (pominjem je
jer sam je upravo video u jednoj "ozbiljnoj" knjizi źto su je
pisali "ozbiljni" struŽnjaci ;( ) ali ipak pokazuje da nije sve
u apsolutnoj greźci - zapravo, ako bi dva programa koja rade neki
posao 5 minuta zavrźila tako da razlika bude ispod pola sekunda,
sa korisniŽkog aspekta bi to bila "jednaka" vremena tj. ne bi ih
ni imalo smisla porediti.
Sa druge strane, poznat je bar jedan sluŽaj programskog paketa
(doduźe ne za PC) koji je svesno falsifikovao rezultate na brzinskom
testu (za 15-tak posto) tako źto je menjao sistemsko vreme (svaŽeg
se ljudi dosete :( ). Sa te strane je moČda źtoperica sigurnija.
arhiveri.698pele,
-> #677, darone>=} Test ima i jednu veliku manu: nema ARJa 2.39 beta.
>=} Zaźto? Ima jedan dobar razlog: ja ga nemam na
>=} disku, a joź manje na disketama. Ajd ne zamerite.
«ini mi se da sam ga vido na Euklidu.Ako nisi znao to
je jedan mnogo fini BBS.Ako ti treba telefon,slobdno
pitaj :))
pele.
arhiveri.699petrovics,
-> #668, d.petrovic>> Ranije smo se nesto kao pazili trojanaca? E, sad je pravo vreme da ga
>> neko posalje kao 2.04h ;))), niko nista nece posumnjati ;)))).
>> Sumnjivo ce biti tek kad stigne 2.05 :)
Covek je potpuno u pravu!
Kako cemo biti sigurni da je "najnovija" pod verzija ZIP-a
ispravna?
arhiveri.700darone,
-> #687, mbole>> Zato źto je merenje źtopericom nezavisno od
>> raŽunara. Nikad neznaź źta moČe da uradi neki
>> TSR ili sliŽno.
Ni jednog TSRa nije bilo (źto sam i rekao u
poruci). U configu samo files i buffers, u
autoexecu path, prompt... i jedan echo, ako neźto
znaŽi ;)
>> ▒to se tiŽe preciznosti dalo bi se izraŽunati da
>> nakon odre¬enog broja ponavljanja operacije i
>> merenja ukupnog vremena (broj ne mora obavezno
>> biti prevelik) źtoperica moČda da ispadne Žak i
>> preciznija, a u svakom sluŽaju greźka ęe biti
>> dovoljno mala da se moČe zanemariti.
A jel sam ja pravio test za bog_te_pita_koga ili
samo da pokaČem neke stvari? Doduźe, kada bi pravio
hiper-ultra-super testiranje, onda bi napisao i
programŽię, pa bi sve poterao da radi celu noę...
Mislim da je merenje rukom prevazi¬eno. Odavno.
darone
arhiveri.701dejanr,
-> #699, petrovics>> Kako cemo biti sigurni da je "najnovija" pod verzija ZIP-a
>> ispravna?
Pa, "nesiguran" naŽin je da pogledaź onaj broj koji se dobija kada
sa postojeęim ZIP-om 2.04g otkucaź PKUNZIP -t PKZ204x.EXE. Ako se
na kraju pojavi Authentic files Verified! # PKW655 PKWARE Inc,
a pored svakog fajla piźe ono -AV, solidne su źanse da je program
autentiŽan.
"Siguran" naŽin je da skineź novu verziju sa njihovog BBS-a
(99 1 414 3548670) ili (uz "za Čilet" manji stepen sigurnosti)
sa nekog drugog veęeg sistema za koji se moČe smatrati da je
program skinuo sa PKWARE BBS-a. Recimo, sa Sezama :)
arhiveri.702ndragan,
-> #662, dejanr/ nkbog, moČeź da pogledaź starije poruke. Ukratko, ARJ moČe da bude
/ neźto bolji pri arhiviranju veęeg broja malih fajlova, ali na uźtrb
/ sigurnosti
Baźka sigurnost, jer sve to vreme izgubiź na osveČavanju ili Županju
neŽega iz arhive u kojoj ima mnogo malih fajlova. ARJ to sve Žita od
poŽetka do kraja, pa tek onda uhvati da neźto radi, ili izvadi fajl sa
poŽetka i za svaki sluŽaj proŽita sve do kraja. Zip zaviri u onaj svoj
direktorij i odmah zna źta treba da radi.
Koliko je vreme da ZIP i ARJ izbace poruku 'nothing to do' nad
direktorijem od par stotina fajlova (moČe i sa poddirektorijem)? Ajd'
nek neko izmeri, a ja ęu i dalje koristiti ARJ samo kad treba da
arhiviram do desetak veęih .DBF fajlova. InaŽe ZIP za sve ostalo.
arhiveri.703ndragan,
-> #666, vlad/ ▒ta ęeź, negde dobijeź, negde izgubiź. Da li je ARJ kriv źto Sezam
/ nema dovoljno memorije, pitanje je sad?
Ne, nego Bil Gejts ili neko iz IBMa.
arhiveri.704mbole,
-> #700, darone> samo da pokaČem neke stvari? Doduźe, kada bi pravio
> hiper-ultra-super testiranje, onda bi napisao i
> programŽię, pa bi sve poterao da radi celu noę...
Nemam niźta protiv tvog testa, Žak me cela priŽa oko toga koji je arh.
bolji i ne zanima preterano (koristim oba). Samo sam probao da dam odgovor
na pitanje zaźto bi merenje vremena źtopericom moglo da bude bolje.
> Mislim da je merenje rukom prevazi¬eno. Odavno.
Ovde greźiź. Osnovni cilj svakog merenja je da ono bude taŽno, precizno
idt. Ovo mnogo viźe zavisi od metode merenja nego od instrumenta kojim se
meri, naravno izuzimajuęi ekstremne sluŽajeve (od peźŽanog sata zaista ne
moČeź oŽekivati neku preciznost).
Upravo ovde leČi prednost źtoperice nad tajmerom raŽunara. U njenoj
potpunoj i sigurnoj nezavisnosti od onoga źto se meri. Metodom merenja
moČe se postięi taŽnost koja prevazilazi zahteve ovog testa.
Joź jednom. Ne sumnjam u rezultate tvojih testova, iz prostog razloga
źto se nalaze u granici greźke (ko razume shvatięe), samo pokuźavam da te
uputim na to da postoje i bolje metode merenja, bez obzira na to koliko
izgledale zastarele. Veruj mi o merenjima i greźkama znam jako mnogo jer mi
je zadnjih 6 godina upravo to bio posao.
arhiveri.705drpr,
-> #700, darone-> autoexecu path, prompt... i jedan echo, ako neźto
-> znaŽi ;)
Aaa, sad smo te ukebali ti misliź da ęe taj TSR "echo" lako da
nam promakne :))))
cope
arhiveri.706zolika,
-> #672, mbole>>> viźe-volumenskim (nikako da
>>> na¬em pravi za taj pojam :) arhivama.
>>
>> viźedelnim 8-)))
Mnogo-diskovitim ?
arhiveri.707darone,
-> #704, mbole>> Veruj mi o merenjima i greźkama znam jako mnogo
>> jer mi je zadnjih 6 godina upravo to bio posao.
Verujem ti! :)
darone
arhiveri.708vlad,
-> #685, skoprivica-> bolje zapamti "ARJ x" (cisto dobronamerno)
Zapamtih ja to odavno (imam "gadan" obiŽaj da dobro prouŽavam
uputstva). ARJ e stavih samo da ne zbunjujem neupuęene, pa da me
pitaju "źta ti je to X?". U svakom sluŽaju, hvala na dobroj nameri.
Vladan
arhiveri.709dr.grba,
-> #706, zolika>> >> visedelnim 8-)))
>> Mnogo-diskovitim ?
mnogocigrovite spremnice, a ne multivolumne arhive
arhiveri.710petrovics,
-> #701, dejanr>> program skinuo sa PKWARE BBS-a. Recimo, sa Sezama :)
Cini se da si me ubedio :)
arhiveri.711bulaja,
R:\IBMPC\ARCHIVER\*.*
----------------------
lha252 exe 47868 LHA (.LZH) arhiver v2.52 (japanska verzija)
Ovo "japanska verzija" znaci da prica samo japanski :). Ne bi bio neki
problem da se prevede (imam cak i japanski recnik kuci :) al' nemam
japanski VGA font. Ima unutra i neki spisak sta je promenjeno u odnosu
na verziju 2.13, al' nista ne razumem, sve same kuke i kvake :)
Verzija 2.13 se jos uvek u ARCHIVER dir-u i bice dok ne nabavimo neku
razmljiviju novu verziju :). Inace arhiver je dobar, u nekim slucajevima
pakuje bolje i od novog ZIP-a i cak :) i od ARJ-a. Testiracu ga ovih
dana malo detaljnije, javicu rezultate.
arhiveri.712bojt,
Bogami, kod mene ovaj ZIP204x ne źljaka pa bog.
Ustvari, on izgleda dobro radi ali se ekran svaki
put zablesavi (tj svaki karakter teksta koji se ispisuje
se ispiźe u po jednom redu, tako da samo "preleęe").
Ovo se deźava, utvrdjeno, samo kada je prisutan neki
memory manager (386MAX 6.0 ili QEMM 6.02). Ne pomaČe
nijedan troubleshooting sviŽ ;(((