blob: e116429abb1de9ef475e0afc9f1884d114c3bb2b (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
<?xml-stylesheet type="text/css" href="sdocbook.css" ?>
<section> <date> 15. July 2002 </date>
<h2> ZZIP Future </h2> What next to come.
<section><!--border-->
<h3> ZIP-Write </h3>
<P>
Anybody out there who wants to program the write-support for the
zziplib? Actually, I just do not have the time to do it and no
real need to but I guess it would be nice for people as for
example to spit out savegame files in zipformat. The actual
programming path is almost obvious - start off with the zziplib
as it is, and let it open an existing zip-file. This will parse
the central directory into memory - including the file-offsets
for each file. Then, truncate the zip-realfile to the place that
the central-dir was found (identical with the end of the last
file). If a datafile is opened for writing, either add a new
entry or modify the start-offset of the existing entry to the
end of the zip-realfile - the old data is simply junk. Then
init zlib to do the deflation of the data and append it to the
current zip-realfile. When the zipdir-handle is getting closed
from write-mode, the zip's central-directory needs to be appended
to the file on disk. This coincides with creating a new zip-file
with an empty central-directory that can be spit out to disk.
During development, do not care about creating temp-files to
guard against corruption for partial writes - the usual application
will use the zziplib to create zip savegames in one turn, no
"update"-operation needs to be implemented like exists in the
standalone zip command utilities.
</P>
</section><section>
<h3> readdir for subdir inside zip magicdir </h3>
<P>
See the notes in the first paragraphs of <a href="zzip-api.html">
ZZIP Programmers Interface</a> description. It would add some
complexity for something I never needed so far. The question
came up with using zziplib as the backend of a dynamic webserver
to store the content in compressed form possibly through the
incarnation of a php module - and some scripted functionality
that walks all directories to index the files hosted. I'm not
going to implement that myself but perhaps someone else wants
to do it and send me patches for free.
</P>
</section><section>
<h3> obfuscation example project </h3>
<P>
A subproject that shows <b>all</b> the steps from a dat-tree
to a dat-zip to an obfuscated-dat along with build-files and
source-files for all helper tools needed to obfuscate and
deobfuscate, plus a sample program to use the obfuscated
dat-file and make some use of it. Along with some extra
documentation about 20..40 hours. Don't underestimate the
amount of work for it! (otherwise a great student project).
</P>
</section><section>
<h3> zip/unzip tool </h3>
<P>
The infozip tools implement a full set of zip/unzip routines
based on internal code to access the zip-format. The zziplib
has its own set of zip-format routines. Still, it should be
possible to write a frontend to the library that implements
parts (if not all) of the options of the infozip zip/unzip
tools. Even without write-support in zziplib it would be
interesting to see an normal unzip-tool that does not use
the magic-wrappers thereby only going off at plain zip-files.
On the upside, such a tool would be smaller than the infozip
tools since it can use the library routines that are shared
with other tools as well. Again - don't underestimate the
amount of work for it, I guess 40..80 hours as there is a lot
of fine-tuning needed to match the infozip model.
</P>
</section>
</section>
|
