Hi, 2011/1/26 Rugxulo <rugx...@gmail.com>: > Hi again, > > On 1/25/11, Eric Auer <e.a...@jpberlin.de> 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 ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
