1) Coder will develop a customized Delphi ZLib decompression function which deflates a compressed data file compressed according to ZLib 1.1.3 specifications (with slight changes; see below). 2) Coder is encouraged to use the Borland ZLib library and its debugged modification by Davide Moretti ([login to view URL]). I may consider use of other off-the-shelf ZLib libraries such as ZLBArchive if coder feels they are more appropriate. 3) Function must ignore extraneous data that may be present at the beginning of the file. This entails examining the contents and discarding them until a ZLib header is found. No extraneous data will follow the compressed block. 4) The source data may use a $789C sequence to signal a new ZLib header. Function must account for this (see #6 below). 5) The Function call will be function DecompressFile(inputfilename, outputfilename : string) : err; where the above filenames are fully qualified paths and filenames, and err is a coder-defined error result. 6) An exact C port that accomplishes a nearly-identical decompression can be found at: [login to view URL] If you are good at porting C to Delphi, this project may take you about ten minutes! 7) Test data (comprising binary data) can be found at: Compressed file: [login to view URL] Decompressed: [login to view URL] 8) Code must compile and execute in Delphi 3 and run under Windows 2000. If you do not have Delphi 3 I will be willing to work with coder to report compilation errors, which the coder will need to help resolve to allow Delphi 3 compatibility. 9) This is only a decompression project. A compression counterpart will not need to be developed.
## Deliverables
1) Complete source code of all work done. The coder may instead supply the work in the form of a small, simple demo app, complete with source code. 2) Installation instructions for the platform(s) specified in this bid request. 3) Complete ownership and distribution copyrights to all work purchased.
## Platform
Must compile under Delphi 3 (Win 2000) ________________________________ OTHER NOTES: Here is some helpful info submitted by a skilled coder who did some preliminary investigative work on this project from the C side of the house. Hope this helps your bid! "ucnids.c mistakenly claims that it is looking for 789C in the input stream; I fell for this when writing ucrawnids.c, and it is not true. In reality, it is looking for a zlib control header, which is not necessarily unique over a compressed block. i.e. a perfectly valid zlib header can appear within a compressed block without actually indicating the start of a new block. I just verified this by trying to count the number of blocks in the file by only looking for zlib control headers. NIDS format. This is why ucnids.c and ucrawnids.c load [login to view URL] into memory either indirectly (by sliding-window buffering) or directly (into a single buffer) to extract the blocks."