zIP's

I wish you good health, Sergey. Once in Tue on January 4, 2000 Sergey Kulkov spoke with Sergey Selev about zIP's... SS>> If I take out the compressor/decompressor from HRUM, then SS>> there will definitely be a TCZIP/UNZIP overlay. SK> Apparently you overcelebrated New Year ;) SK> Have you heard about compatibility? Dig out the algorithms SK> from the zip and make a normal interface - this is it SK> will be. Have you ever filled a file with crunch or crunch? Compare the speed with subjects. But then another file arrived, after which you can without a doubt to say that the subject is MAZDAI. The file took 5 minutes to unpack!!! After unpacking the file, I get a crunch and besides that it took up 700-800 bytes less and was also unpacked instantly. And in general Why does Spectrum need such buggy programs if you can ask Pyankov for a compressor? and write a normal archiver. ██████▓▓▓▓▒▒▒▒░░░░::::: Sergey aka Cyber ​​from Cobra Software. ███▓▓▓▓▒▒▒▒░░░░:::: ██▓▓▓▒▒▒░░░░::

Glad to see you Vladimir! Once, namely 04 Jan 00 Vladimir Klymus wrote to Sergey Selev: VK> =========== Cut and save =========== VK> int ZOpen(void) VK> { VK> long l; [skip] Do you happen to have the complete source code for ZXZIP/ZXUNZIP for PC? Or at least only ZXUNZIP? I would like to remake it for the Amiga. Tried to contact the author - silent :( [AMiGA] WBR, Denis Ognewsky

Reply-to: 500:8362/1.10@ZXNET Greetings, Sergey! Somehow Sun 9 Jan 2000 at 21:40:02 Vladimir Klymus and Sergey Selev discussed zIP's. Well, I decided to butt in... SS>> IMHO completely rewriting the zip/anzip shell will take even more SS>> time than creating a new archiver. VK> What if you just rewrite the archiver using the algorithm? Uh! I see cool people arguing about archivers ;) So, let me ask a hackneyed question: People!!! Who has pkunzip algorithms? We've had enough of the brakes of Spec's pkunzip! Now our coder is Alexey Porfiryev is dealing with this problem. By simply upgrading version 1.0 it was possible achieve a 1.8-fold increase in performance. And this is not the limit, because the program is built on the basis of is-dos' unzipa and has a nasty structure. Moreover the source code of the algorithm is somewhat abstruse or not completely disassembled, but in As a result, any attempt to optimize them ends in terrible glitches. It seems that if you write everything again, you can raise it quite significantly unpacking speed. All the best, Sergey! Alexander aka Arc of RLDG.

Let your enemies, Alexander, die without sons! Mon 17 Jan 2000 at 22:59, Alexander Araktcheew ═> Sergey Selev: AA> But I still don’t understand why you shouldn’t do pkzip, at least for a collection :) AA> If you don’t like it, write your own and get people to recognize it as a standard. this definitely won't happen. :) [censored] AA> I think the origin of the brakes of the Spectrum pkunzip has become clear and it doesn’t matter AA> compare it with the highly optimized hrust depacker. Moreover, depacker AA> hrust cannot unpack long files. not a fact. if we assume that in three years nothing has happened in this area cardinal changes, then the depacker has a byte stream as input, interpreting which receives the output. the input stream contains words of the state itself depacker and the data itself. accordingly, unpacking stops upon meeting in the states of some unique marker. AA> That's why I ask people again and again: Does anyone have anything about AA> packer/depacker algorithms pkunzip??? (except for Spectrum sources AA> pkunzip) You are asking in the wrong echo. :) There are no algorithms, there are sources, theoretically. [WBR, Oleg. ] [ 08:57 18 January XXXV A.S. ]

Hello, Alexander! Tue 18-Jan-2000 23:36, you (500:8362/1.10) wrote a letter to me: AA>>> But so far the best archiver on the Spectrum is hrust, VL>> You should first decide on the terminology and learn to distinguish VL>> archiver from the packer. AA> Solasen, it was a pun, but we were talking about packing algorithms as AA> such. And what do we know about crunch packing algorithms? Someone checked how they were doing will they lead to a bunch of files compressed into an archive? Lha, for example, with the usual average the degree of compression of postal packages is not higher than ~2:1 on a pack of similar pairs dozens of letters (from a robot) gives ~30:1 VL>> And the year was not 93rd, but 94th. Show me another archiver with a cooler one VL>> face. AA> The fact of the matter is that there are no archivers. Well why, I saw at least two more. Markovsky, something like a parody of pap, with a similar interface, presses only in solid, written either in tse or in galloped, which did not increase his speed. There is a link to it in the doc on zxzip - The archive with a bunch of zip fonts reaped by Markovsky has reduced almost twice as much. AA> Yes, and we weren’t talking about the face here. It’s just that for some reason people do their best AA> against the implementation of pkzip on the Spectrum. Even strange... Show these people. Write, they will erect a monument for you, everyone will use it. Yes, Also, let's just call it zip, pk is just pkware, for me, for example, zip is not theirs, I have info-zip, this does not make it non-zip. VL>> In addition, the frame nature of the interface is poorly reflected in 128K conditions VL>> on the quality/speed of packaging. AA> And it’s far from frame-based, it’s a terrible slowdown :) If you think that 128k is a lot and you can sculpt gooey faces, then this is not yes. BTW another "archiver" that got to me (lies somewhere in settling tank) - with windows, an arrow and a progress bar. Not on one archive, True, he couldn’t do zxzip, so what for do I need him, his windows, arrow and progressbar? In conditions of limited memory, the choice is usually known in advance: either checkers or go. With best wishes, Vladimir.

Reply-to: 500:8362/1.10@ZXNET Greetings, Vladimir! Fri 21 Jan 2000 at 16:41:32 Vladimir Larkov and Alexander Araktcheew were talking on the topic of ZIP's. VL> And what do we know about crunch packing algorithms? Someone checked how they were VL> will behave on a bunch of files compressed into an archive? Lha, for example, with normal VL> average degree of compression of mail packets is not higher than ~2:1 on a packet of VL> similar pairs of dozens of letters (from a robot) produces ~30:1 So let's release Lha on Spectrum :) The more different types of archivers there are, the easier it is to communicate with others platforms. As always, everything depends on the algorithm. VL>>> And the year was not 93rd, but 94th. Show me another archiver with a cooler one VL>>> face. AA>> The fact of the matter is that there are no archivers. VL> Why, I saw at least two more. Markovsky, something like a parody VL> on pap, with a similar interface, presses only in solid, written either in tse or VL> whether on a gallop, which did not increase his speed. There is a link to it in the doc VL> on zxzip - the zip archive compressed by Markovsky with a bunch of fonts is still almost gone VL> doubled. I haven't even seen help on zxzip :) AA>> And we weren’t talking about the face here. It’s just that for some reason people do their best AA>> against the pkzip implementation on Spectrum. Even strange... VL> Show these people. Write, they will erect a monument to you, everyone will use it. Hot info :) VL> Yes, also, let's just call it zip, pk is just pkware, for me VL> for example, zip is not theirs, I have info-zip, this does not make it non-zip. I agree. But there are just a lot of different zips. But wasn't zip developed by pkware? AA>> And it’s far from frame-based, it’s a terrible slowdown :) VL> If you think that 128k is a lot and you can sculpt gooey faces, then this is VL> not Fuck this guy... Don't you see that the interface there could have been It’s much easier to do and several times faster with a smaller code size. So memory excuses won't work :) VL> so. BTW another "archiver" that got to me (lies somewhere in VL> sump) - with windows, arrow and progress bar. Not in any archive VL> however, he couldn’t do zxzip, so what for do I need him, his windows, VL> arrow and progressbar? In conditions of limited memory, the choice, as a rule, VL> known Maybe the author just didn’t know better packaging algorithms? If you wish, you can press it in parts, swap the disk and something else. Imho not accidentally zxzip accesses the disk frequently. So this is not an argument either. Although the interface takes up most of the memory also perverted. VL> in advance: either checkers or go. One may not interfere with the other :) All the best, Vladimir! Alexander aka Arc of RLDG.