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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
<section><date> 20. July 2002 </date>
<h2> ZZIP API extras </h2> The check/init API description.
<!--border-->
<section>
<h3> Extras </h3>
<P>
The next requests circulated around other file-extensions to
automagically look inside filetypes that have zip-format too but
carry other fileextensions - most famous might be the ".PK3"
files of ID's Quake game. There have been a number of these
requests and in a lot of cases it dawned to me that those guys
may have overlooked the zzip_dir_open functions to travel
through documents of zipformat under any name - that is that the
"magic" was not actually needed but they just wanted to read
files in zipformat with the zziplib.
</P>
<P>
Other requests circulated around encryption but I did reject
those bluntly, always. Instead there have been always examples
for doing some obfuscation around the zip-format so that the
stock zip/unzip tools do not recognize them but a game
software developer can pack/unpack his AI scripts and bitmaps
into such a zipformat-like file.
</P>
<P>
After some dead-end patches (being shipped along with the
zziplib as configure-time compile-options - greetings to
Lutz Sammer and Andreas Schiffler), the general approach
of _ext_io came up, and finally implemented (greetings go
to Mike Nordell). The _open()-calls do now each have a
cousin of _open_ext_io() with two/three additional arguments
being a set of extensions to loop through our magic testing,
a callback-handler plugin-table for obfuscation-means,
and (often) a bit-mask for extra-options - this bitmask even
has "PREFERZIP" and "ONLYZIP" options to skip the real-file
test magic in those <code>zzip_*open</code> functions.
</P>
<table cellpadding=10 width=100%><tr><td><table border=1 width=100%>
<tr><td width=50%> zzip_open(name,flags) </td>
<td width=50%> zzip_open_ext_io(name,flags,mode,ext,io) </td></tr>
<tr><td width=50%> zzip_opendir(name) </td>
<td width=50%> zzip_opendir_ext_io(name,mode,ext,io) </td></tr>
<tr><td width=50%> zzip_dir_open(name,errp) </td>
<td width=50%> zzip_dir_open_ext_io(name,errp,ext,io) </td></tr>
<tr><td width=50%> zzip_dir_fdopen(fd,errp) </td>
<td width=50%> zzip_dir_fdopen_ext_io(fd,errp,ext,io) </td></tr>
<tr><td width=50%> zzip_file_open(dir,name,mode) </td>
<td width=50%> zzip_file_open_ext_io(dir,name,mode,ext,io) </td></tr>
</table></td></tr></table>
<P>
Oh, and note that the mode,ext,io extras are memorized
in the respecitive ZZIP_DIR handle attached, so each
of the other calls like <code>zzip_file_open()</code>
and <code>zzip_read()</code> will be using them. There
are a few helper routines to help setup a new io-plugin
where the init_io will currently just memcopy the
default_io entries into the user-supplied plugin-struct.
</P>
<table cellpadding=10 width=100%><tr><td><table border=1 width=100%>
<tr><td width=50%> zzip_init_io </td>
<td width=50%> the recommended way to do things </td></tr>
<tr><td width=50%> zzip_get_default_io </td>
<td width=50%> used internally whenever you supply a null
for the io-argument of a _ext_io()-call </td></tr>
<tr><td width=50%> zzip_get_default_ext </td>
<td width=50%> used internally but not exported </td></tr>
</table></td></tr></table>
<P>
And last some stdio-like replacements were build but these
happen to be actually just small wrappers around the other
posix-like magic-calls. It just offers some convenience
since wrappers like "SDL_rwops" tend to use a stringised
open-mode - and I took the occasion to fold the zzip-bits
for the _ext_io-calls right in there recognized via
special extensions to the openmode-string of zzip_fopen().
</P>
<table cellpadding=10 width=100%><tr><td><table border=1 width=100%>
<tr><td width=50%> zzip_fopen </td>
<td width=50%> convert stringmode and call zzip_open_ext_io </td></tr>
<tr><td width=50%> zzip_fread </td>
<td width=50%> slower way to say zzip_read </td></tr>
<tr><td width=50%> zzip_fclose </td>
<td width=50%> a synonym of zzip_close </td></tr>
</table></td></tr></table>
<P>
For some reason, people did need the full set of function-calls()
to be working on zzip-wrappers too, so here they are - if the
ZZIP_FILE instance did wrap a real file, then the real posix-call
will be used, otherwise it is simulated on the compressed stream
with a zip-contained file - especially <code>seek()</code> can be
a slow operation:
if the new point is later then just read out more bytes till we
hit that position but if it is an earlier point then rewind to the
beginning of the compressed data and start reading/decompression
until the position is met.
</P>
<table cellpadding=10 width=100%><tr><td><table border=1 width=100%>
<tr><td width=50%> zzip_rewind </td>
<td width=50%> magic for rewind() </td></tr>
<tr><td width=50%> zzip_tell </td>
<td width=50%> magic for tell() </td></tr>
<tr><td width=50%> zzip_seek </td>
<td width=50%> magic for seek() </td></tr>
</table></td></tr></table>
<P>
And last not least, there are few informative functions to
use function-calls to read parts of the opaque structures
of zzip-objects and their zzip-factory.
</P>
<table cellpadding=10 width=100%><tr><td><table border=1 width=100%>
<tr><td width=50%> zzip_dir_stat </td>
<td width=50%> a stat()-like thing on a file within a ZZIP_DIR </td></tr>
<tr><td width=50%> zzip_dir_real </td>
<td width=50%> check if ZZIP_DIR wraps a stat'able posix-dirent</td></tr>
<tr><td width=50%> zzip_file_real </td>
<td width=50%> check if ZZIP_FILE wraps a stat'able posix-file </td></tr>
<tr><td width=50%> zzip_realdir </td>
<td width=50%> if zzip_dir_real then return the posix-dirent </td></tr>
<tr><td width=50%> zzip_realfd </td>
<td width=50%> if zzip_file_real then return the posix-file </td></tr>
<tr><td width=50%> zzip_dirhandle </td>
<td width=50%> the attached ZZIP_DIR of compressed ZZIP_FILE </td></tr>
<tr><td width=50%> zzip_dirfd </td>
<td width=50%> the attached posix-file of ZZIP_DIR zip-file </td></tr>
<tr><td width=50%> zzip_set_error </td>
<td width=50%> set the last ZZIP_DIR error-code </td></tr>
<tr><td width=50%> zzip_error </td>
<td width=50%> get the last ZZIP_DIR error-code </td></tr>
<tr><td width=50%> zzip_strerror </td>
<td width=50%> convert a zzip_error into a readable string </td></tr>
<tr><td width=50%> zzip_strerror_of </td>
<td width=50%> combine both above zzip_strerror of zzip_error </td></tr>
<tr><td width=50%> zzip_errno </td>
<td width=50%> helper to wrap a zzip-error to a posix-errno </td></tr>
<tr><td width=50%> zzip_compr_str </td>
<td width=50%> helper to wrap a compr-number to a readable string
</td></tr>
<tr><td width=50%> zzip_dir_free </td>
<td width=50%> internally called by zzip_dir_close if the ref-count
of the ZZIP_DIR has gone zero</td></tr>
<tr><td width=50%> zzip_freopen </td>
<td width=50%> to reuse the ZZIP_DIR from another ZZIP_FILE so it does
not need to be parsed again </td></tr>
<tr><td width=50%> zzip_open_shared_io </td>
<td width=50%> the ext/io cousin but it does not close the old ZZIP_FILE
and instead just shares the ZZIP_DIR if possible</td></tr>
</table></td></tr></table>
</section></section>
|
