MS-DOS:  try making zipinfo strings (and unzip ones) far pointers? --convert
 to msg() (stdout) and warn/err() (stderr) functions, and for MS-DOS small
 model, copy far strings into temporary local memory (slide[] buffer?) before 
 calling fprintf()

rewrite with fwrite/fseek/etc. (streams, not file descriptors) [see below]

replace EOL code, add automatic text/binary unpacking [see below]

add "distribution" text to COPYING:  archive naming conventions, text files
 to be included with executables distributions, etc. (update README approp-
 riately)

(?)nice to check for zipfile[.zip] in funzip

update PAKFIX message(?) (mention PKZIP 2.04c,e,g?)

test OS/2 extended-header code to make sure -a doesn't screw it up--always
 want "binary" mode, presumably (memextract())

___________________
set file perms to 644; make .zip, .zoo, .tar.Z archives

*** test on all systems ***


==============
For UnZip 5.2:
==============


==========================
For 5.1/5.2/6.0/who knows:
==========================

The Overall Plan [original 26 Jan 93; updated 8 Jul 93, mailed, updated more]:

To: cherborth@semprini.tdkcs.waterloo.on.ca, hanna@world.std.com,
        heath@ncrcae.columbiasc.ncr.com, jloup@chorus.fr,
        john.bush@east.sun.com, madler@cco.caltech.edu,
        mandrichenko@mx.ihep.su, paul.kienitz@f28.n125.z1.fidonet.org,
        rommel@informatik.tu-muenchen.de
Cc: goathunter%wkuvx1.bitnet@uchimvs1.uchicago.edu

In the meantime I can be working on the other long overdue unzip
projects, and you other zip-buggers with a specific OS in your
care can be working on the extract-to and wildcard stuff (the
latter is actually pretty easy), if you don't manage to do so
before 5.1.  Then 5.2 can be released with full fanfare, etc.

   o extract-to-dir capability (not hard, but distasteful, sigh...)

	DONE (for Unix, OS/2, MS-DOS), aside from bugs.  And it was
	harder than I thought--there are a lot of special cases with
	which to deal.  It should be easier for others with the existing
	versions as templates.

   o add wildcard zipfiles (not too hard or time-consuming, I don't
     expect)

	DONE for Unix (aside from getdents mess), OS/2, MS-DOS; not
	well tested yet (and it was as easy as I expected).

   o incorporate zipinfo (possibly moderate effort, but I haven't
     yet thought enough about it to know for sure)

	DONE (as of today), aside from moving code around and possibly
	renaming the now-irrelevant shared.c; I should have a new alpha
	ready in a day or two, in case any of you think you might want
	to change something in one of the non-OS-dependent files.  It
	turned out to be surprisingly easy (a day's work?), and it means
	zipinfo will be a lot easier to maintain and keep up to date.

   o "little stuff" like cleaning up unzip.h, etc.

	next? (with zipinfo code-shuffle?)

   o rewrite to use fwrite/no outbuf (moderately easy)

	next?

   o rewrite to use fread/fseek/no ReadByte/etc. (quite painful);

	next? (and it couldn't possibly be 9 months' painful... :-) )

*  o incorporate new backfill version of inflate()

	sometime after fread/fseek/ReadByte

   o replace EOL conversion code and make text/binary conversion automatic
     (fairly simple, except maybe where it collides with the fwrite change)

	later? (goes with fwrite change, I guess)

   o add multi-part zipfile handling

	way later

   o add case insensitivity to file matching on case-insensitive
     OS's (the whole bit with single quotes which we discussed a
     few months back)

	way later

   o rewrite to allow use as a filter

	way, way later...

   o add option to search zipfile contents for a string and print the
     results? ("zipgrep" option--e.g., unzip -g or unzip -S) (easy for
     fixed strings, hard for wildcards/true regex's)

	way, way later, if at all...

*  o add -y "display symlinks" option to zipinfo?

	who knows

*  o add "in-depth" option to zipinfo? (check local headers against
*    central, etc.)--make it a better debugging tool (or just create
*    zipfix)

	who knows

