Hi all! 2011/1/26 Eric Auer <e.a...@jpberlin.de>: > > Hi! > >>> It is a cute tiny 2560 byte small unzipper by Lucho :-) >> >> Phil Katz, actually, but anyways ... ;-) > > Dunno, I assume it is a highly tuned implementation. > >> What did you use to create the .ZIP? > > Dunno, it was just the smallest ZIP in my temp dir, > containing the .asm and .com of some 68 byte FreeDOS > version string display tool... ZIPINFO says the file > is made with Info-ZIP 2.3 and can be unzipped with > any ZIP 2.0 or newer on DOS, OS/2, NT FAT or better. > > 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. > > > > (Please do NOT quote the following ZIPINFO output > completely in your reply, at most selected lines) > >> There is no zipfile comment. >> >> End-of-central-directory record: >> ------------------------------- >> >> Zip archive file size: 218 (00000000000000DAh) >> Actual end-cent-dir record offset: 196 (00000000000000C4h) >> Expected end-cent-dir record offset: 196 (00000000000000C4h) >> (based on the length of the central directory and its expected offset) >> >> This zipfile constitutes the sole disk of a single-part archive; its >> central directory contains 1 entry. >> The central directory is 68 (0000000000000044h) bytes long, >> and its (expected) offset in bytes from the beginning of the zipfile >> is 128 (0000000000000080h). >> >> >> Central directory entry #1: >> --------------------------- >> >> fdver.com >> >> offset of local header from start of archive: 0 >> (0000000000000000h) bytes >> file system or operating system of origin: Unix >> version of encoding software: 2.3 >> minimum file system compatibility required: MS-DOS, OS/2 or NT FAT >> minimum software version required to extract: 1.0 >> compression method: none (stored) >> file security status: not encrypted >> extended local header: no >> file last modified on (DOS date/time): 2006 Apr 29 04:46:30 >> file last modified on (UT extra field modtime): 2006 Apr 29 04:46:29 local >> file last modified on (UT extra field modtime): 2006 Apr 29 02:46:29 UTC >> 32-bit CRC value (hex): a19907f3 >> compressed size: 68 bytes >> uncompressed size: 68 bytes >> length of filename: 9 characters >> length of extra field: 13 bytes >> length of file comment: 0 characters >> disk number on which file begins: disk 1 >> apparent file type: binary >> Unix file attributes (100640 octal): -rw-r----- >> MS-DOS file attributes (00 hex): none >> >> The central-directory extra field contains: >> - A subfield with ID 0x5455 (universal time) and 5 data bytes. >> The local extra field has UTC/GMT modification/access times. >> - A subfield with ID 0x7855 (Unix UID/GID (16-bit)) and 0 data bytes. >> >> There is no file comment. > > > > 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: > > 0000000: 504b 0304 0a00 0000 0000 cf25 9d34 f307 PK.........%.4.. > 0000010: 99a1 4400 0000 4400 0000 0900 1500 6664 ..D...D.......fd > 0000020: 7665 722e 636f 6d55 5409 0003 85d3 5244 ver.comUT.....RD > 0000030: 8cd3 5244 5578 0400 f401 6400 b800 30cd ..RDUx....d...0. > 0000040: 2180 fffd 7520 b8ff 33cd 218e da89 c6fc !...u ..3.!..... > 0000050: bf36 01ac 08c0 7403 aaeb f8b0 0daa b00a .6....t......... > 0000060: aab0 24aa 0e1f ba36 01b4 09cd 21b8 004c ..$....6....!..L > 0000070: cd21 4e6f 7420 4672 6565 444f 530d 0a24 .!Not FreeDOS..$ > 0000080: 504b 0102 1703 0a00 0000 0000 cf25 9d34 PK...........%.4 > 0000090: f307 99a1 4400 0000 4400 0000 0900 0d00 ....D...D....... > 00000a0: 0000 0000 0000 0000 a081 0000 0000 6664 ..............fd > 00000b0: 7665 722e 636f 6d55 5405 0003 85d3 5244 ver.comUT.....RD > 00000c0: 5578 0000 504b 0506 0000 0000 0100 0100 Ux..PK.......... > 00000d0: 4400 0000 8000 0000 0000 D......... > > You can turn it back into a ZIP using xxd -r < file.txt > file.zip > > > >> Modern fancy-pants tools might've >> tried to add "extra info" crud to it, which could confuse a >> simplistic, slimmed-down interpretation like TUNZ. > > Good point! The "garbage" data indeed shows up as part > of the ZIP file, probably as part of the "extra field". > > 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? > >> Personally, I'd try >> reZIPping with either "zip -X" or run "advzip -z2" on it just to be >> "safe". I think even 7-Zip tries adding extra field info nowadays >> (UTF-8 friendly charset info?). > > Interesting. You can try it with ADVZIP then and report > whether that one is more friendly to TUNZ now :-) Thanks! > >
Thanks for your information! I did use 7-zip heavily in the past and now I'd give advzip a try. > >> Since PKUNZJR is from 1999, that was before FreeDOS had any momentum, >> so it surely wasn't tested there... > > No, so PKUNZJR could not be updated to fit FreeDOS. > However, people of course like running ancient soft > on new OS, so somebody should have noticed problems > with PKUNZJR or TUNZ long ago. 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. Version 2.0 compatibility is much more popular > and even newest zippers only use higher when they > really need extra features such as strong protection > or Unicode filenames or similar extensions AFAIR. > > > >>> check for example tiny demos/intros (Rugxulo, I think a >>> page on the 256b category exists, any idea where it is?) >> >> Disappeared. :-( But check here: >> >> http://board.flatassembler.net/topic.php?t=10707 >> http://asm4u.net/Archive/256b.com/ > > What do those pages say? > > > >> Jack Ellis pretty much said Lucho had some job issues, >> and since his various sites seem to be down ... > > Oh. I hope he and his family are okay apart from that. > >> 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 netbootdisk.com boot disk nature, it consists of 2-pass decompression. First, it decompress unuharcd.exe and command.com to RDISK-created ramdisk with INSTALL= in config.sys, point SHELL= to COMMAND.COM in ramdisk, and unuharc the network drivers archive(FILES.UHA) in autoexec.bat. At the beginning I even found that TUNZ give no output in INSTALL= line, but now I recrate it with a brand new floppy and it seems to be fine. > > Cheers, Eric > > Best regards, Roy ------------------------------------------------------------------------------ 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
