Re: [Freedos-user] tunz problems in freedos

[Roy T. <ro...@gm...>]

Hi,

2011/1/26 Rugxulo <ru...@gm...>:
> Hi again,
>
> On 1/25/11, Eric Auer <e....@jp...> wrote:
>>
>>> What did you use to create the .ZIP?
>>
>> Dunno, it was just the smallest ZIP in my temp dir,
>>
>> After using ZIP -d to remove the deflated ASM file,
>> I got a file which even unzips with any ZIP 1.0 or
>> newer, only containing the not compressed COM file.
>
> Wait, it's "stored" (uncompressed)? Weird. I mean, I get it, that way
> anybody can extract it manually if needed, but strange that TUNZ has a
> problem with it (bad CRC, corrupt file resulting). PKUNZJR works fine,
> though, go figure. I mean, it's hard to screw that up, just find the
> data offset and write it out, but apparently TUNZ has a bug! (But
> perhaps TUNZ is based upon older 2.04g's PKUNZJR???)
>
>>>   length of filename:                             9 characters
>>>   length of extra field:                          13 bytes
>
> copy /b blah.zip blah2.zip
> advzip -z2 blah2.zip
> tunz blah2.zip
> crc32 fdver.com
> unzip -Zv blah.zip
>
>  length of filename:                             9 characters
>  length of extra field:                          0 bytes
>
> So yes, apparently advzip "fixed" it, and I'm blindly guessing it has
> to do with the "extra field" info.
>
>> I know gmail cannot receive zips with com, but this zip is
>> so tiny that I can simply send it to you as the hex dump:
>
> A debug script is better and not hard to make (nor generate from your listing):
>
> n blah.zip
> rcx
> da
> a 100
> db 50 4b 03 04 0a 00 00 00 00 00 cf 25 9d 34 f3 07
> db 99 a1 44 00 00 00 44 00 00 00 09 00 15 00 66 64
> db 76 65 72 2e 63 6f 6d 55 54 09 00 03 85 d3 52 44
> db 8c d3 52 44 55 78 04 00 f4 01 64 00 b8 00 30 cd
> db 21 80 ff fd 75 20 b8 ff 33 cd 21 8e da 89 c6 fc
> db bf 36 01 ac 08 c0 74 03 aa eb f8 b0 0d aa b0 0a
> db aa b0 24 aa 0e 1f ba 36 01 b4 09 cd 21 b8 00 4c
> db cd 21 4e 6f 74 20 46 72 65 65 44 4f 53 0d 0a 24
> db 50 4b 01 02 17 03 0a 00 00 00 00 00 cf 25 9d 34
> db f3 07 99 a1 44 00 00 00 44 00 00 00 09 00 0d 00
> db 00 00 00 00 00 00 00 00 a0 81 00 00 00 00 66 64
> db 76 65 72 2e 63 6f 6d 55 54 05 00 03 85 d3 52 44
> db 55 78 00 00 50 4b 05 06 00 00 00 00 01 00 01 00
> db 44 00 00 00 80 00 00 00 00 00
>
> w
> q
>
>> Nice. However, I still do not understand why it would
>> work with MS DOS or DR DOS in that case. Maybe because
>> FreeDOS comes with INFO-ZIP while Roy used the original
>> old DOS-only PKZIP on the MS DOS computer instead?
>
> Unlikely. I'm not sure what PKZIP does regarding extra fields, but I
> know Info-Zip sometimes uses / adds it. It's unnecessary, though, for
> most people. It's just really old or quirky tools (TUNZ) don't always
> handle it well.
>
> Just FYI, here's a link to the latest .ZIP spec (APPNOTE.TXT):
>
> "
> File:    APPNOTE.TXT - .ZIP File Format Specification
> Version: 6.3.2
> Revised: September 28, 2007
> Copyright (c) 1989 - 2007 PKWARE Inc., All Rights Reserved.
> "
>
> http://www.pkware.com/documents/casestudies/APPNOTE.TXT
>
>> Interesting. You can try it with ADVZIP then and report
>> whether that one is more friendly to TUNZ now :-) Thanks!
>
> TUNZ can't handle even what PKUNZJR can, even though they're basically
> the same! Besides, it's shareware, so be prepared to pay up!  ;-)
> No, seriously, I'd drop TUNZ like a ton of bricks if I were you. (But
> often such bootdisks skimp on the legalities.)
>
>> However, people of course like running ancient soft
>> on new OS, so somebody should have noticed problems
>> with PKUNZJR or TUNZ long ago.
>
> Most people probably just use Info-Zip, PKunzip, or 7-Zip nowadays.
> The tiny tools aren't important to most (else they wouldn't use
> bloated OSes like Win64 or modern Linux/X11).
>
>> As you can see above,
>> one of the "known" problems is that deflate is not
>> supported, so only ZIP 1.0 compatible files work in
>> TUNZ.
>
> I seriously doubt this. Lemme prove it. Nope, you're wrong, Deflate
> works fine. I packed a single .ASM file with Info-Zip's ZIP 3.0 (zip
> -9Xm) and both TUNZ and PKUNZJR unpacked it correctly (same CRC-32).
>
> Apparently PKUNZJR only supports 512 files, no mutiple volume
> (spanned), must unpack all files (not just select ones), no LFN
> support, and only one option (-o) unless you count the optional
> "output_path" parameter. It seems to be basically a standalone util
> that uses the same stuff as (lousy, proprietary, can't redistribute
> without special separate license) PKSFX does.   :-P
>
>>> You can't be that tied to TUNZ. Sure, the small size is appealing
>>
>> Maybe Roy tried to use it to unzip some text to the screen
>> or to unzip some files to a ramdisk in a tiny DOS floppy?
>> Which other tiny unzippers would you suggest here, Rugxulo?
>
> As mentioned, for my own floppy uses, I use untar.exe, 7zdecode.exe,
> or even the full Info-Zip unzip.exe (but old 5.52 is smaller). I'm
> just saying, somebody hacking at puff.c would probably have better
> success at truly small size.
>

I wonder if someone can make minizip/miniunzip work in DOS.
http://www.winimage.com/zLibDll/minizip.html