1
1
================================
2
For UnZip 6.0/6.1/who knows:
2
For UnZip 6.1/who knows:
3
3
================================
5
o implement handling of file sizes beyond the 32-bit limit of
6
2GByte (resp. 4GByte), using the new 64-bit extra field extensions
7
as defined by PKWARE (this will not get implemented for the present
8
16-bit ports - plain DOS and OS/2 1.x)
10
top of the list for 6.0!
11
UnZip 6.0 is now under development, first betas for Win32 and Unix
5
o add extraction support for other compression algorithms used by new
6
PKZIP, WinZIP, 7-Zip versions
7
- LZMA, compression type 14 (most important, because of its efficiency)
8
- PPMd, compression type 98 (maybe, less important)
9
- WavPacked, compression type 97 (maybe, less important)
11
LZMA is first-level priority for 6.1, other formats may be taken
14
o add support for reading AES encrypted archives
15
- WinZIP format (priority 1)
16
- PKZip format (priority 2)
18
top level item for 6.1
14
20
o add multi-part zipfile handling
16
major feature for 6.0!
22
major feature for 6.x!
18
could happen for 6.0 - 10/8/2004 EG
20
26
o better support for multilingual uses and different codepages;
21
27
support unicode (UTF-8 coded) filenames and comment texts
23
29
a requested feature getting more and more important,
30
- partially done for the Windows port in 6.0
31
(support restricted for chars of the current system codepage)
32
- partially done (beta state) for Unix
33
(requires native codepage to be UTF-8)
35
o complete support for UTF-8 coded entry names (and comments)
36
- add new "win32_wide" port to extend unicode support on Windows
37
beyond the restrictions of the current (ANSI) system codepage
38
- revise/extend the WinDLL interface to allow passing of "wide"
40
- add simple built-in character translation between UTF-8 and the
41
old (ISO-8851-1 / IBM850) code pages to allow old systems without
42
standard UTF-8 support to read UTF-8 encoded archives.
43
- extend the built-in translation tables to support other language
44
regions besides "Western_Latin1" (e.g. Russian-kyrillic, Japanese,
46
- streamline the multilingual codepage and UTF-8 support for the UNIX
47
port (standard codepage translation facility?, like WideChar<->AnsiCP
48
translation functions under MS Windows)
51
(there is internal alpha-state code for better "wide" support on
52
Windows available at the time of the 6.0 release)
54
o revise the "extended charcodes" handling in decryption password to
55
support UTF-8 encoding on Unicode-aware systems where the "native"
56
character coding is NOT UTF-8 (e.g. Windows).
58
o revise the command line interface for more compatibility with Zip'
60
- implement the versatile command parser from Zip 3.0.
61
- add "long option" definitions for all existing options; revise
62
the UnZip user manual to document the long-option alternatives.
63
- add support for reading the "process these entries" and the "skip
64
these entries" pattern lists from a file (or from separate files ?).
65
- add a (long) option to switch off UnZip's internal pattern matching
66
on filename arguments.
69
(first prototype of the revised command parser was available at the
70
time of the 6.0 release)
72
o add command line options for miscellaneous features requested by users
73
and/or development team members:
74
- display the Info-ZIP software license
75
- more fine-tuning for file attributes set/restored at extraction, like:
76
set/clear archive attribute on DOS/OS2/WIN32;
77
apply/skip standard or user-defined umask filter on UNIX (& Unix-alike)
78
- additional time-stamp related processing filters
79
- more listing display modifications
80
- overriding the default date-time display style
83
All these options are of minor importance and/or would collide with
84
existing "one-character" options. The current UnZip maintainer does not
85
want to reserve any of the few not-yet-occupied short option characters.
86
for one of these features. So, any implementation effort for items
87
of this feature wish-list has to be delayed until the "long option"
88
support of the revised command line parser becomes available.
90
some option may get implemented in 6.1
93
and/or development team members:
26
95
o add new low-level, binary API; rewrite "normal" (command-line) UnZip
29
98
maybe soon (maybe 6.1)
31
o use (simple!) configure script in combination with Unix Makefile
33
very soon (6.0 or 6.1)
35
may be needed in 6.0 to autodetect large file support - 10/8/2004 EG
37
o add precautions against extracting files outside the tree below
38
the current directory resp. the specified extraction folder.
39
(automatically remove absolute path specs from zip entries; emit
40
warnings when traversing outside the extraction tree...)
42
done as of version 5.51
44
100
o MSDOS/WIN32/others: detection of "reserved" names (= names of character
45
101
devices, or system extensions that look like a characters device driver)
46
102
at runtime; with the goal of emitting "meaningful" error messages and/or
129
185
o miscellaneous little stuff: whenever
130
186
--------------------------
132
- add support for setting directory time stamps to win32 port. This requires
133
a solution similar to the UNIX SET_DIR_ATTRIB optional code; maybe, it could
134
be combined with the delayed restoring of directory ACLs. Unfortunately,
135
the simple version used in the OS/2 case (setting dir time stamp just after
136
creating the directory) does not work, because WinNT updates directory
137
change times whenever the directory content gets modified (addition,
138
deletion, rename, file change), at least for NTFS file systems.
141
188
- change DOS -f/-u stuff to use DOS API for getting filetimes, not stat()
143
190
- add (-N?) option to lose all user input and/or switch to "(*input)()"