UNIX Compressed Files From A PC

UNIX Compressed Files From A PC

[Marin D. Condic]

I'm looking for a package that can access UNIX compressed files and
unpack them for me. I'm in a situation where I've got to read these
files from a WinNT PC and the files will be resident either on the PC or
across the net on a Sun platform. I want to access them as any other
byte stream file - Open/Read/Write/Seek/Close operations are what I
need. Does anybody know of an Ada package that is generally available
that can do this?

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"Nothing in the world is more dangerous than sincere ignorance and
conscientious stupidity."

    -- Martin Luther King, Jr
======================================================================

Re: UNIX Compressed Files From A PC

[Don Yuniskis]

In article <3995C90A.E72C055F@acm.org>,
Marin D. Condic <mcondic-nospam@acm.org> wrote:
>I'm looking for a package that can access UNIX compressed files and

Are you looking for files that have been compress(1)-ed, freeze(1)-d,
zip(1)-ed, gzip(1)-ed, bzip2(1)-ed, etc.?  The algorithms used differ.

>unpack them for me. I'm in a situation where I've got to read these
>files from a WinNT PC and the files will be resident either on the PC or
>across the net on a Sun platform. I want to access them as any other
>byte stream file - Open/Read/Write/Seek/Close operations are what I

I assume you *really* mean a "package" and not some other solution
to your problem (i.e. unpacking them outside *your* application).
If you want to be able to *write* to the packed files, then you obviously
either want them to be unpacked before you access them or "wrap" the
open/close with unpack/pack...  ?

Or, was the reference to "write" an overzealous typo?  :>

>need. Does anybody know of an Ada package that is generally available
>that can do this?

The sources to all of the compressors/decompressors in popular use
are readily available (though almost always written in C)

--don

Re: UNIX Compressed Files From A PC

[Marin D. Condic]

Don Yuniskis wrote:
> Are you looking for files that have been compress(1)-ed, freeze(1)-d,
> zip(1)-ed, gzip(1)-ed, bzip2(1)-ed, etc.?  The algorithms used differ.
> 
I am told the files were compressed via "compress" and that it uses the
LZW compression algorithm.

> I assume you *really* mean a "package" and not some other solution
> to your problem (i.e. unpacking them outside *your* application).
> If you want to be able to *write* to the packed files, then you obviously
> either want them to be unpacked before you access them or "wrap" the
> open/close with unpack/pack...  ?
> 
Let me clarify. I want a package, as in "Ada package", that I can
compile and link to which does Open/Read/Write/Seek/Close for compressed
files. I could use a C++ class - possibly an extension of the MFC
"CFile" class - that would do the same.

I think you're confused about the "write" thing. If you are familiar
with the Win32.LZExpand package in the Win32ada bindings (or the same
stuff in the Win32api) these OS routines do *exactly* what I need - but
refuse to do anything with Unix ".z" files. They will work with files
compressed under NT just fine. The "write" of which I speak is a matter
of wanting to open a file for output, write bytes to it, close it and
have a compressed file when I'm done. I don't think it would be very
easy to do both reads and writes to a sequential file of bytes even if
it wasn't compressed and I can't imagine trying to do that with a
compressed file. :-)

> Or, was the reference to "write" an overzealous typo?  :>
> 
Nope. See above.


> The sources to all of the compressors/decompressors in popular use
> are readily available (though almost always written in C)
> 
A URL or two may come in handy. I can cope with it being written in C. I
can even cope with it being extremely badly written in C, provided I get
two things: A) The Open/Read/Write/Seek/Close functions I need where I
send it a file handle and get back a buffer full of bytes (or the other
direction) and B) It functions reliably so I don't have to debug it and
hammer on it to get it to work.

My problem in this case is time. I've got a program that is accessing
files through a bunch of standard issue Windows calls where
Open/Read/Write/Seek/Close are the functions being used. I need to make
a change to the software so it can pick up files across a network from a
Unix box where the files are compressed. I can't change the requirements
and I don't have a lot of time to get a solution in place, so I thought
if I had either an Ada package or C++ class that did the same things, I
could "leverage software reuse" by simply plugging in the new package
with maybe a little glue software around it. If you know of something
that fits this description, please let me know. Thanks.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going" 

        --  William McChesney Martin, Former Fed chairman, explaining 
            what a sound central bank must always do. 
======================================================================

Re: UNIX Compressed Files From A PC

[Don Yuniskis]

In article <3996B1FC.A5892C21@acm.org>,
Marin D. Condic <mcondic-nospam@acm.org> wrote:
>Don Yuniskis wrote:
>> Are you looking for files that have been compress(1)-ed, freeze(1)-d,
>> zip(1)-ed, gzip(1)-ed, bzip2(1)-ed, etc.?  The algorithms used differ.
>> 
>I am told the files were compressed via "compress" and that it uses the
>LZW compression algorithm.

OK.

>> I assume you *really* mean a "package" and not some other solution
>> to your problem (i.e. unpacking them outside *your* application).
>> If you want to be able to *write* to the packed files, then you obviously
>> either want them to be unpacked before you access them or "wrap" the
>> open/close with unpack/pack...  ?
>> 
>Let me clarify. I want a package, as in "Ada package", that I can
>compile and link to which does Open/Read/Write/Seek/Close for compressed
>files. I could use a C++ class - possibly an extension of the MFC
>"CFile" class - that would do the same.

Understood.

>I think you're confused about the "write" thing. If you are familiar
>with the Win32.LZExpand package in the Win32ada bindings (or the same
>stuff in the Win32api) these OS routines do *exactly* what I need - but
>refuse to do anything with Unix ".z" files. They will work with files
>compressed under NT just fine. The "write" of which I speak is a matter
>of wanting to open a file for output, write bytes to it, close it and
>have a compressed file when I'm done. I don't think it would be very
>easy to do both reads and writes to a sequential file of bytes even if
>it wasn't compressed and I can't imagine trying to do that with a
>compressed file. :-)

Yes, this is why I was noted wrapping the open/close with uncompress/compress
(to give the illusion of a regular file for R/M/W access)

>> The sources to all of the compressors/decompressors in popular use
>> are readily available (though almost always written in C)
>> 
>A URL or two may come in handy. I can cope with it being written in C. I
>can even cope with it being extremely badly written in C, provided I get
>two things: A) The Open/Read/Write/Seek/Close functions I need where I
>send it a file handle and get back a buffer full of bytes (or the other
>direction) and B) It functions reliably so I don't have to debug it and
>hammer on it to get it to work.

Here is the URL for the command line version (under UN*X) of a
compress/uncompress (same executable does both functions):

ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/usr.bin/compress

You'll have to peel out the getopts(3) related crap but the core
of the compressor and decompressor are present and have been
"working" for years... :>

Source is tiny -- about 9KB ... much of which you will discard.

Note that the URL places you in a source tree so if you need to
find other files (e.g., #include-d header files) you can navigate to
them using the "parent directory" link...

>My problem in this case is time. I've got a program that is accessing

Heh heh heh... s/My/Everyone/g    :>

>files through a bunch of standard issue Windows calls where
>Open/Read/Write/Seek/Close are the functions being used. I need to make
>a change to the software so it can pick up files across a network from a
>Unix box where the files are compressed. I can't change the requirements
>and I don't have a lot of time to get a solution in place, so I thought
>if I had either an Ada package or C++ class that did the same things, I
>could "leverage software reuse" by simply plugging in the new package
>with maybe a little glue software around it. If you know of something
>that fits this description, please let me know. Thanks.

Understood.  Sorry this won't "drop-in" without a bit of cobbling...

You might also explore the option of running a proxy process on the UN*X 
box that does the uncompress(1) for you "on-the-fly" -- *if* your
requirements will tolerate that -- and just makes the decompressed
file available to you WHILE YOU NEED IT (and then effectively
deletes it -- even if it only existed in VM at the time)

HTH,
--don

Re: UNIX Compressed Files From A PC

[Marin D. Condic]

Don Yuniskis wrote:
> 
> Understood.  Sorry this won't "drop-in" without a bit of cobbling...
> 
Yeah. That's a problem. The difficulty with cobbling something together
from someone else's code for a complicated algorithm like this is that
by the time you've figured out how it works well enough to make the
modifications you need, you might just as well have rolled your own.
You'd be sure to get what you wanted from it and, from what I've seen of
some of the C sources available to do this, I'd end up with something
much more readily understood and maintained.

Unless someone can point me at a package that provides the ops I need, I
think I'm going to get stuck rolling my own. Pity. :-(

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going" 

        --  William McChesney Martin, Former Fed chairman, explaining 
            what a sound central bank must always do. 
======================================================================

Re: UNIX Compressed Files From A PC

[E. Robert Tisdale]

"Marin D. Condic" wrote:

> Yeah. That's a problem.
> The difficulty with cobbling something together
> from someone else's code for a complicated algorithm like this is that
> by the time you've figured out how it works well enough to make
> the modifications you need, you might just as well have rolled your own.
> You'd be sure to get what you wanted from it
> and, from what I've seen of some of the C sources available to do this,
> I'd end up with something much more readily understood and maintained.
>
> Unless someone can point me at a package that provides the ops I need,
> I think I'm going to get stuck rolling my own. Pity. :-(

I suspect that you've been sent on a fool's errand.
The right way to do this is to write a UNIX shell script
which pipes the output from uncompress to a remote process on the NT
which filters the  uncompressed data then pipes it back to compress on UNIX.
I think you could do the whole thing with a single UNIX command
on two or three lines in the shell script.
Anyway, it's just the sort of assignment that an old UNIX programmer
with a sick sense of humor would give to a cocky young Windows programmer
to teach him a little something about UNIX and, of course, humility;-)

Re: UNIX Compressed Files From A PC

[Marin D. Condic]

E. Robert Tisdale wrote:
> I suspect that you've been sent on a fool's errand.
> The right way to do this is to write a UNIX shell script
> which pipes the output from uncompress to a remote process on the NT
> which filters the  uncompressed data then pipes it back to compress on UNIX.
> I think you could do the whole thing with a single UNIX command
> on two or three lines in the shell script.
> Anyway, it's just the sort of assignment that an old UNIX programmer
> with a sick sense of humor would give to a cocky young Windows programmer
> to teach him a little something about UNIX and, of course, humility;-)

I wish I were young - and a Windows programmer :-) Humility is not my
strong suit. It's hard to be humble when you're the best there is.

As I've said in a number of other posts: I cannot change the
requirement. The file *MAY-OR-MAY-NOT* live on a Unix box. Relying on
Unix to uncompress the file is NOT an option. The only thing I can count
on is that at some point in time, the file was compressed using the Unix
"compress" command (LZW algorithm, ".z" file format, whatever that
implies.) I cannot change the compression algorithm. I cannot rely on
the Unix operating system. I cannot use shell scripts or some other
stuff to unpack the file. I've got to *READ* the file in its compressed
format and get it decompressed on the fly.

This is not, in principle, a difficult thing to do - nor an uncommon
thing to do. Look at the Win32.LZExpand stuff provided by the
Win32ada/Win32api. Thats all I need. Just that - only for ".z" files
instead of Windows compressed files. As I understand it, Unix will just
do this for you automagically, when you open and start reading the file.
My only problem is an unsupported file format on Windoze. Why does it
seem that what I want to do is so unusual or oddball?

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going" 

        --  William McChesney Martin, Former Fed chairman, explaining 
            what a sound central bank must always do. 
======================================================================

Re: UNIX Compressed Files From A PC

[Don Yuniskis]

In article <3996DF0F.B35F1BDC@acm.org>,
Marin D. Condic <mcondic-nospam@acm.org> wrote:
>Don Yuniskis wrote:
>> 
>> Understood.  Sorry this won't "drop-in" without a bit of cobbling...
>> 
>Yeah. That's a problem. The difficulty with cobbling something together
>from someone else's code for a complicated algorithm like this is that
>by the time you've figured out how it works well enough to make the
>modifications you need, you might just as well have rolled your own.

I don't think I'd consider compress(1) "complicated"  :>

As for rolling your own, you then have to test the core of
the algorithm in addition to the "wrappings" you've placed around
it.  At least reusing some existing algorithm gives you the
benefit of *knowing* that it works and has worked for eons...

>You'd be sure to get what you wanted from it and, from what I've seen of
>some of the C sources available to do this, I'd end up with something
>much more readily understood and maintained.

You might want to look at the URL I posted previously.  I imagine you
could wrap it in a suitable preamble and have it up and running
in a day or so -- you might spend a day or more trying to "borrow"
an existing implementation ("package", "class", etc.) only to later
discover that it has limitations on file sizes or some other
unusual "bug" ^H^H^H^H features...

>Unless someone can point me at a package that provides the ops I need, I
>think I'm going to get stuck rolling my own. Pity. :-(

<shrug>  Best of luck!
--don

Re: UNIX Compressed Files From A PC

[E. Robert Tisdale]

"Marin D. Condic" wrote:

> Let me clarify.  I want a package, as in "Ada package",
> that I can compile and link to
> which does Open/Read/Write/Seek/Close for compressed files.
> I could use a C++ class -
> possibly an extension of the MFC "CFile" class -
> that would do the same.

Are you sure that this is the correct approach?
Wouldn't you be better off to download a copy of
the `compress' and `uncompress' programs for Windows
from the Simtel archives and make Win32 system calls
from your Ada program to execute uncompress
and leave the uncompressed data in a file
that you can open and read normally?

Re: UNIX Compressed Files From A PC

[Marin D. Condic]

E. Robert Tisdale wrote:
> Are you sure that this is the correct approach?
> Wouldn't you be better off to download a copy of
> the `compress' and `uncompress' programs for Windows
> from the Simtel archives and make Win32 system calls
> from your Ada program to execute uncompress
> and leave the uncompressed data in a file
> that you can open and read normally?

A) Please point me at the Simtel archives in the event that there is
maybe something useful there.

B) I can't change the requirements. The file is not to be uncompressed
into a regular old file sitting on a disk that I can easily read with
plain vanilla I/O. That would be too easy. Hell, I could have done that
by typing "uncompress <filename>" at the Unix command line. Where's the
sport in that? :-) For what they're paying me to do this, they could
have bought a dozen 100gigabyte drives and just left the data
uncompressed. Disks are cheap. Engineers cost money. Go figure. (If it
helps you understand it, know that this is a job for the government.)

I really have to do Open/Read/Write/Seek/Close - just like in the
LZExpand package in the Win32Ada binding. Sorry. That's the requirement.
Wish I didn't have to mess with this, but there you have it. Life is
hard, and *then* you die! If you can direct me to something that will
meet that requirement, I'd appreciate it. Thanks.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going" 

        --  William McChesney Martin, Former Fed chairman, explaining 
            what a sound central bank must always do. 
======================================================================

Re: UNIX Compressed Files From A PC

[E. Robert Tisdale]

"Marin D. Condic" wrote:

> A) Please point me at the Simtel archives
> in the event that there is maybe something useful there.

    http://www.simtel.net/simtel.net/

    http://sources.redhat.com/cygwin/

> B) I can't change the requirements.
> The file is not to be uncompressed into a regular old file sitting on a disk
> that I can easily read with plain vanilla I/O.  That would be too easy.
> Hell, I could have done that by typing "uncompress <filename>"
> at the Unix command line.  Where's the sport in that? :-)

UNIX?  I thought that you were doing this in Windows.
What about using a UNIX pipe?

> For what they're paying me to do this,
> they could have bought a dozen 100gigabyte drives
> and just left the data uncompressed. Disks are cheap.
> Engineers cost money.  Go figure.  (If it helps you understand it,
> know that this is a job for the government.)

You can get the source for the GNU versions of compress and uncompress.

> I really have to do Open/Read/Write/Seek/Close -
> just like in the LZExpand package in the Win32Ada binding.
> Sorry.  That's the requirement.
> Wish I didn't have to mess with this, but there you have it.
> Life is hard, and *then* you die!
> If you can direct me to something that will meet that requirement,
> I'd appreciate it.

Re: UNIX Compressed Files From A PC

[Marin D. Condic]

E. Robert Tisdale wrote:
> UNIX?  I thought that you were doing this in Windows.
> What about using a UNIX pipe?
> 
One more time. With feeling. :-) The program runs on a WinNT box. It
must open the file which (maybe) lives on a UNIX box somewhere down at
the other end of the hose. I've got to use the facilities that are on
the WinNT box because that's where I run and I may have to open the file
almost anywhere - including the WinNT box. Its a UNIX compressed file. I
can't count on UNIX to uncompress it for me. I've got to do the
decompression myself. I can't decompress the file and write it to
another file on a disk somewhere and then read it with plain, vanilla
I/O. Hence, I need a subroutine library that will perform the functions
I've outlined in previous posts.

> 
> You can get the source for the GNU versions of compress and uncompress.
> 
Bzzzzzzzzzt! Wrong answer. Check prior posts. Even if the GNU stuff
would work, it's only going to do what I could have done by typing
"uncompress <filename>" at the Unix command line or done with PKZip or
Winzip or a thousand other utilities. See below:

> > I really have to do Open/Read/Write/Seek/Close -
      ^^^^^^
      |||||| And I'm NOT kidding!

I don't have time to sort through someone elses LZW algorithm, modify it
to have functions described above, debug it, etc. If I had time to do
that, I'd go get a book that described the thing itself and run off and
built my own. I'd probably do a better job of writing what I need than
I'd get by cobbling something together out of GNU code, etc. What I'm
hoping to find is an "off-the-shelf" answer that I can plug into the
code I've got, declare victory, collect my check and move on to
something a little less silly. If you know of a package that will do
what I've described, this would be helpful.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going" 

        --  William McChesney Martin, Former Fed chairman, explaining 
            what a sound central bank must always do. 
======================================================================

Re: UNIX Compressed Files From A PC

[E. Robert Tisdale]

"Marin D. Condic" wrote:

> > > I really have to do Open/Read/Write/Seek/Close -
>       ^^^^^^
>       |||||| And I'm NOT kidding!

I don't think you can do this
because, well, compressed files are compressed.
Generally, you can't simply modify the compressed file.
You must uncompress it, make the modification, then recompress it.
You can get an entirely different bit pattern in your compressed file
even if you are making very small changes.

Re: UNIX Compressed Files From A PC

[Marin D. Condic]

E. Robert Tisdale wrote:
> I don't think you can do this
> because, well, compressed files are compressed.
> Generally, you can't simply modify the compressed file.
> You must uncompress it, make the modification, then recompress it.
> You can get an entirely different bit pattern in your compressed file
> even if you are making very small changes.

Apparently everyone is reading my requirement to be able to read and
write compressed files to mean that I want Read/Write access to a
compressed file. I don't. I want to be able to open a sequential,
compressed file for read access and read the bytes getting them
decompressed from the read routine. I want to open a sequential,
compressed file for write access and write bytes to it, getting them
compressed by the write routine. I also want to be able to seek to a
specific byte position within a read-access file. (Yes, I know that
doing a seek backwards will be painfully slow, but I mostly need to seek
forward.) That's it. No more. This will be good enough. Thank you. And
that's all I need - and this paddle game! :-) (Look at Win32.LZExpand if
you want to see exactly what I need.)

I do not want read/write access to a sequential file. Most programming
languages and operating systems that I know of don't generally allow
this because it would be painful to do in a general way. I clearly
understand that attempting read/write access to a *compressed*
sequential file would be even worse.

I hope this clarifies.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going" 

        --  William McChesney Martin, Former Fed chairman, explaining 
            what a sound central bank must always do. 
======================================================================

Re: UNIX Compressed Files From A PC

[Thomas Quinot]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

Dans comp.lang.ada, Marin D. Condic �crit :

>Apparently everyone is reading my requirement to be able to read and
>write compressed files to mean that I want Read/Write access to a
>compressed file. I don't. I want to be able to open a sequential,
>compressed file for read access and read the bytes getting them
>decompressed from the read routine. I want to open a sequential,
>compressed file for write access and write bytes to it, getting them
>compressed by the write routine. I also want to be able to seek to a
>specific byte position within a read-access file. (Yes, I know that

Skimming through this thread I don't see a mention of zlib.
I think there are good chances that what Marin needs is mostly
an Ada binding to zlib.

See http://www.info-zip.org/pub/infozip/zlib/.

Hope this helps,
Thomas.
-- 
    Thomas.Quinot@Cuivre.FR.EU.ORG

Re: UNIX Compressed Files From A PC

[Ted Dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

In article <8ngpm8$tof$1@melusine.cuivre.fr.eu.org>,
  thomas@cuivre.fr.eu.org (Thomas Quinot) wrote:
> Dans comp.lang.ada, Marin D. Condic �crit :
>
> >Apparently everyone is reading my requirement to be able to read and
> >write compressed files to mean that I want Read/Write access to a
>
> Skimming through this thread I don't see a mention of zlib.
> I think there are good chances that what Marin needs is mostly
> an Ada binding to zlib.

No. As I mentioned previously, you'll have a tough time finding free
solutions to his problem. Zlib can not decompress files compressed with
the Unix "compress" command. Zlib is meant to be Free (capital F), and
thus does not mess with patented algorithms. It is built around
providing support for gzip (.gz) compression. It can also deal with .zip
files with a bit of work, I believe.

I built a zlib Ada binding once. Unfortunately the work I did on zlib
seems to be lost. But I may be getting ready to implement a binding to
libbzip2. Would anyone be interested in an OpenSource release of it?

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: UNIX Compressed Files From A PC

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]


"Ted Dennison" <dennison@telepath.com> a �crit dans le message news: 8ngto9$tge$1@nnrp1.deja.com...
> No. As I mentioned previously, you'll have a tough time finding free
> solutions to his problem.
You might be interested to read http://www.foolabs.com/xpdf/lzw.html
It describes how they circumvented the patent problem in Xpdf.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: UNIX Compressed Files From A PC

[Ted Dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

In article <8nh256$39g$1@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>
> "Ted Dennison" <dennison@telepath.com> a �crit dans le message news:
8ngto9$tge$1@nnrp1.deja.com...
> > No. As I mentioned previously, you'll have a tough time finding free
> > solutions to his problem.
> You might be interested to read http://www.foolabs.com/xpdf/lzw.html
> It describes how they circumvented the patent problem in Xpdf.

Short answer....by calling the Unix "uncompress" command in a
subprocess. Not too good of a solution if you want to make a Mac or
Windows version.

A further reading shows that the author isn't convinced that
decompression algorithms are allowed (which would make gzip illegal). As
if that weren't bad enough, he has a link to Unisys (
http://www.unisys.com/unisys/lzw/ ) where they claim that you need to
get a separate license from them to *use* any software anyone else wrote
that contains lzw, even if the author also had a license. They go on to
point out that GIF, Postscript, and PDF all use lzw. Yuk.

Of course Adobe has bribed...er..purchased the proper license for their
tools (http://www.adobe.com/support/salesdocs/f636.htm ). As the patent
issue prevents the creation of a free PDF tool, I dobut they are too
broken up over it.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: UNIX Compressed Files From A PC

[Tarjei T. Jensen]

Ted Dennison wrote:
>No. As I mentioned previously, you'll have a tough time finding free
>solutions to his problem. Zlib can not decompress files compressed with
>the Unix "compress" command. Zlib is meant to be Free (capital F), and
>thus does not mess with patented algorithms. It is built around
>providing support for gzip (.gz) compression. It can also deal with .zip
>files with a bit of work, I believe.


I don't think this is true since gzip decompresses .Z ("compress") files.
Decompression have never been an issue, but compression is. Otherwise netscape
and Micosoft would have had to pay licenses for their browsers.


Greetings,

Re: UNIX Compressed Files From A PC

[Tucker Taft]

"Tarjei T. Jensen" wrote:
> 
> Ted Dennison wrote:
> >No. As I mentioned previously, you'll have a tough time finding free
> >solutions to his problem. Zlib can not decompress files compressed with
> >the Unix "compress" command. Zlib is meant to be Free (capital F), and
> >thus does not mess with patented algorithms. It is built around
> >providing support for gzip (.gz) compression. It can also deal with .zip
> >files with a bit of work, I believe.
> 
> I don't think this is true since gzip decompresses .Z ("compress") files.
> Decompression have never been an issue, but compression is. Otherwise netscape
> and Micosoft would have had to pay licenses for their browsers.

I have heard from several sources that decompression is not covered
by the patent, despite Unisys' scare tactics.  So feel free to
decompress without getting a license from Unisys.  I think you can
also rely on the "small fry" effect.  Unisys won't bother going after
anyone who is a "small fry."  They realize that such a person has
insufficient assets to make it worth their while.  Of course, if some
"small fry" goes after Unisys for some unrelated patent reason, they
will probably get hammered. 

> 
> Greetings,

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

Re: UNIX Compressed Files From A PC

[James Moe]

"Marin D. Condic" wrote:
> 
> I'm looking for a package that can access UNIX compressed files and
> unpack them for me. I'm in a situation where I've got to read these
> files from a WinNT PC and the files will be resident either on the PC or
> across the net on a Sun platform. I want to access them as any other
> byte stream file - Open/Read/Write/Seek/Close operations are what I
> need. Does anybody know of an Ada package that is generally available
> that can do this?
> 
    Have you looked at GNU's gzip? It de-/compresses unix compressed
files as well as its own compression format (which is quite good, much
better than ZIP or PKZIP). If you need code, you could get the
source....

-- 
sma at rtd dot com

Re: UNIX Compressed Files From A PC

[Marin D. Condic]

James Moe wrote:
>     Have you looked at GNU's gzip? It de-/compresses unix compressed
> files as well as its own compression format (which is quite good, much
> better than ZIP or PKZIP). If you need code, you could get the
> source....
> 
From what I've been told, GNU's gzip will not handle Unix ".z" files
properly. Besides, I am in a situation where I have to solve this
problem quickly from the perspective of an Ada (or C++) package that
will do the Open/Read/Write/Seek/Close capabilities I mentioned. If I
have to glom onto some GNU code and cobble a solution together for
myself, this will take too much time. I've encountered some incredibly
badly written C code (why does that not surprise me?) that successfully
decompresses the files. The only problem is that it doesn't provide the
capabilities I need (if you give it a file it will decompress it for you
into another file - could have done that from the command line already.)
Because its so badly written and obfuscated, it could take weeks to
butcher it into something that would do the 5 functions I mentioned.

Thanks for the info. If you know of something a little closer to my
requirements, please pass that along.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going" 

        --  William McChesney Martin, Former Fed chairman, explaining 
            what a sound central bank must always do. 
======================================================================

Re: UNIX Compressed Files From A PC

[Tarjei T. Jensen]

Marin D. Condic wrote
>From what I've been told, GNU's gzip will not handle Unix ".z" files
>properly. Besides, I am in a situation where I have to solve this
>problem quickly from the perspective of an Ada (or C++) package that
>will do the Open/Read/Write/Seek/Close capabilities I mentioned. If I
>have to glom onto some GNU code and cobble a solution together for
>myself, this will take too much time.

I have used gzip to decompress .Z files for many years (.z is another older
format). As far as I know the gzip API will not allow you to create a .Z file.
You will have to create a .gz file. On the other hand, gzip compresses better
than compress.

Using the compress algorithm to compress may involve getting a license from
Unisys. They have the patent.


Greetings,

Re: UNIX Compressed Files From A PC

[Marin D. Condic]

Tarjei T. Jensen wrote:
> I have used gzip to decompress .Z files for many years (.z is another older
> format). As far as I know the gzip API will not allow you to create a .Z file.
> You will have to create a .gz file. On the other hand, gzip compresses better
> than compress.
> 
Thanks for that info. I'll have another go around with gzip to see if we
can do something with it. Unfortunately, I can't do anything about the
compression format. It is what it is and I can't change it because the
data is produced by another system/group. But if gzip will recognize the
LZW files and decompress them, that may provide an answer.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going" 

        --  William McChesney Martin, Former Fed chairman, explaining 
            what a sound central bank must always do. 
======================================================================

Re: UNIX Compressed Files From A PC

[Gautier]

Marin D. Condic:

> Thanks for that info. I'll have another go around with gzip to see if we
> can do something with it. Unfortunately, I can't do anything about the
> compression format. It is what it is and I can't change it because the
> data is produced by another system/group. But if gzip will recognize the
> LZW files and decompress them, that may provide an answer.

The file format is not completely linked to the algorithm to compress the
files. Some compressors for GIF avoid using LZW because of the patent - as
I've read in some sources you find on the Internet, anyway.
The 7-Zip compressor seems to use a recent algorithm to create .zip files
with much better compression but same file format - hence, unzippable normally.

If you can mimic the file format (Huffman tables etc.) for the .z (or .Z ?)
files by customising Unzip-Ada it could arrange things (just an idea of
course...).

______________________________________________________
Gautier  --  http://members.xoom.com/gdemont/gsoft.htm

Re: UNIX Compressed Files From A PC

[Ted Dennison]

In article <3995C90A.E72C055F@acm.org>,
  "Marin D. Condic" <mcondic-nospam@acm.org> wrote:
> I'm looking for a package that can access UNIX compressed files and
> unpack them for me. I'm in a situation where I've got to read these
> files from a WinNT PC and the files will be resident either on the PC
> or across the net on a Sun platform. I want to access them as any
> other byte stream file - Open/Read/Write/Seek/Close operations are
> what I need. Does anybody know of an Ada package that is generally
> available that can do this?

One issue that you should be aware of that I haven't seen mentioned: The
Sun Unix "compress" utility uses several *patented* LZW algorithms. That
is why you won't see any free utilities to perform LZW compression. If
you write such a routine yourself, *you* will be infringing on the
patents unless you or your customer makes some kind of arrangement with
the patent holders.

Apparently the patents do not prohibit uncompression, but I suspect
you'll have a hard time finding free solutions that just do
uncompression when there are better non-patented algorithms available
out there.

From what I've heard, it may be the case that you can write a utility to
just read the data from a compressed archive without violating the
patent. But If you will have a need to perform compression yourself, you
should make sure that your employers get permission to use the patented
algorithms before you write so much as a line of infringing code. If
they want to slide the issue under the rug, get their legal department
involved yourself. Once the true pain of using "compress" is made clear
to them, they ought to be much more amenable to alternative free
solutions.

For the FSF's take on this, see
http://www.gnu.org/bulletins/bull14.html#SEC13


--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: UNIX Compressed Files From A PC

[Marin D. Condic]

Ted Dennison wrote:
> Apparently the patents do not prohibit uncompression, but I suspect
> you'll have a hard time finding free solutions that just do
> uncompression when there are better non-patented algorithms available
> out there.
> 
Right now, I'd settle for read access only and leave the write access
for a later date. The *primary* mission is to read the data and get it
unpacked on the fly. If I get that far, the rest can wait for another
answer.

BTW: If in fact all of this falls under some kind of patent
restrictions, that is O.K. by me. If someone had a package that did what
I wanted it to do reliably, I'd be willing to pay for it. I've got to
get this solved quickly, so spending a few bucks for someone's DLL (or
whatever!) that provided the calls I need would make me happy.

As it is, it looks like my only real answer is to either cobble someone
else's badly written C code or roll my own. In the interest of
expediency, I'm going to get cracking on that route.... :-(

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going" 

        --  William McChesney Martin, Former Fed chairman, explaining 
            what a sound central bank must always do. 
======================================================================

Re: UNIX Compressed Files From A PC

[Ted Dennison]

In article <399839B0.F5A138F7@acm.org>,
  "Marin D. Condic" <mcondic-nospam@acm.org> wrote:

> BTW: If in fact all of this falls under some kind of patent
> restrictions, that is O.K. by me. If someone had a package that did
> what I wanted it to do reliably, I'd be willing to pay for it. I've
> got to get this solved quickly, so spending a few bucks for someone's
> DLL (or whatever!) that provided the calls I need would make me happy.

Understood. But who is going to have developed such a project, when
there are free alternative algorithms out there that are more efficient
and more commonly used, and don't require the developer to get all
chummy with a lawyer? (shudder)

> As it is, it looks like my only real answer is to either cobble
> someone else's badly written C code or roll my own. In the interest of
> expediency, I'm going to get cracking on that route.... :-(

That'd be my guess too. Good luck.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: UNIX Compressed Files From A PC

[Marin D. Condic]

Ted Dennison wrote:
> Understood. But who is going to have developed such a project, when
> there are free alternative algorithms out there that are more efficient
> and more commonly used, and don't require the developer to get all
> chummy with a lawyer? (shudder)
> 
As is all too often the case, I didn't make the problem. I'm just the
one who has to fix the problem. :-) If it were me, I'd have never
compressed the files in the first place - just bought more disk space.
Barring that, I'd have been flexible about the compression format so
that the most widely used method was employed. Barring that, I'd have at
least not established the rules of the game such that we couldn't
decompress the files to disk and read them as plain old files.
Unfortunately, none of this is the case. Its far more political than it
is technical.

One day when I get to be captain of the ship I'm going to enjoy issuing
arbitrary and capricious commands with a whimsical "Make It So, Number
One!" and let someone else sweat the details. :-)

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going" 

        --  William McChesney Martin, Former Fed chairman, explaining 
            what a sound central bank must always do. 
======================================================================

Re: UNIX Compressed Files From A PC

[E. Robert Tisdale]

"Marin D. Condic" wrote:

> One day, when I get to be captain of the ship,
> I'm going to enjoy issuing arbitrary and capricious commands
> with a whimsical "Make It So, Number One!"
> and let someone else sweat the details. :-)

I still think that you've been given a little test and you're failing badly.

A UNIX programmer might type

    localhost$ zcat file.Z | rsh remotehost filter | compress >> /tmp/file.Z
    localhost$ mv /tmp/file.Z file.Z
    localhost$

at the UNIX prompt to run compressed file file.Z through your filter
on the remote host (the NT in this case).
I don't understand why you wasted your weekend on this problem
and I don't understand why your employer permits you to continue
wasting time on it.

Re: UNIX Compressed Files From A PC

[Ted Dennison]

In article <39984E52.F8E3EB6B@netwood.net>,
  "E. Robert Tisdale" <edwin@netwood.net> wrote:
> I don't understand why you wasted your weekend on this problem
> and I don't understand why your employer permits you to continue
> wasting time on it.

"Understanding is a three-edged sword."
   - Delenn


--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: UNIX Compressed Files From A PC

[Keith Thompson]

Ted Dennison <dennison@telepath.com> writes:
[...]
> "Understanding is a three-edged sword."
>    - Delenn

I think that was Kosh.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: UNIX Compressed Files From A PC

[Ted Dennison]

In article <yec4s4n171i.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> Ted Dennison <dennison@telepath.com> writes:
> [...]
> > "Understanding is a three-edged sword."
> >    - Delenn
>
> I think that was Kosh.

You're right. A group of tall people wearing robes and strange helmets
came to my house last night and 'splained it to me.

Never misquote a Vorlon....

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: UNIX Compressed Files From A PC

[Marin D. Condic]

E. Robert Tisdale wrote:

> I still think that you've been given a little test and you're failing badly.
> 
What part of "I can't guarantee that the file will be on UNIX" are you
not hearing? What part of "Its a political issue - not a technical
issue" is not getting through here? I really don't see how much more
plain I can make it. I keep saying that the answer *MUST BE* one that is
built into the program and can't be any sort of shell script or
temporary file or pipe anything of the sort. Yet you keep coming back
with that response. Are you just trying to bait me?

I am not some kind of inexperienced, wet-behind-the-ears fresh-out who
is having his chain jerked by his superiors to see if he can figure it
out. I am not being sent on a snipe hunt nor being asked to find a
left-handed smoke bender. The problem here is very specific and I have
tried to outline precisely what my need is. If you have some information
that will help me out here, I'd appreciate it. But the answer has to be
some sort of package that does basically what Win32.LZExpand does. If
you know of something like this, please pass that info along.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going" 

        --  William McChesney Martin, Former Fed chairman, explaining 
            what a sound central bank must always do. 
======================================================================

Re: UNIX Compressed Files From A PC

[Bill Dale]

"Marin D. Condic" wrote:
> 
> E. Robert Tisdale wrote:
> 
> > I still think that you've been given a little test and you're failing badly.
> >
> What part of "I can't guarantee that the file will be on UNIX" are you
> not hearing? What part of "Its a political issue - not a technical
> issue" is not getting through here? I really don't see how much more
> plain I can make it. I keep saying that the answer *MUST BE* one that is
> built into the program and can't be any sort of shell script or
> temporary file or pipe anything of the sort. Yet you keep coming back
> with that response. Are you just trying to bait me?
> 

[snip]

I don't think your chain is being jerked but political requirements need
to be dealt with politically.

Show the customer the technical risks and give him a cost and schedule
for doing it his way.  The more ridiculous the better.  Then give him
the right way to do it.  Otherwise - walk away.   Most of the time,
management will not learn even when they keep hitting their head against
the wall -- but it is amusing to see from the outside.

Not speacking for LM,SSO but just for myself ...

William L. Dale
"If we spend all of our time in ADM's talking about TLA's we'll be SOL!"
Lockheed Martin, Space Systems Company,
Missiles & Space -Sunnyvale Operations
mailto:william.dale.jr@lmco.com

Re: UNIX Compressed Files From A PC

[Larry Kilgallen]

In article <399973CA.8EEC6B38@lmco.com>, Bill Dale <william.dale.jr@lmco.com> writes:
> "Marin D. Condic" wrote:
>> 
>> E. Robert Tisdale wrote:
>> 
>> > I still think that you've been given a little test and you're failing badly.
>> >
>> What part of "I can't guarantee that the file will be on UNIX" are you
>> not hearing? What part of "Its a political issue - not a technical
>> issue" is not getting through here? I really don't see how much more
>> plain I can make it. I keep saying that the answer *MUST BE* one that is
>> built into the program and can't be any sort of shell script or
>> temporary file or pipe anything of the sort. Yet you keep coming back
>> with that response. Are you just trying to bait me?
>> 
> 
> [snip]
> 
> I don't think your chain is being jerked but political requirements need
> to be dealt with politically.

He is a big boy, and knows all about political solutions.
He came here asking for a technical solution giving rather
specific requirements.  Given his experience in aerospace
I am sure he understands the nature of requirements.

Re: UNIX Compressed Files From A PC

[Marin D. Condic]

Larry Kilgallen wrote:
> He is a big boy, and knows all about political solutions.
> He came here asking for a technical solution giving rather
> specific requirements.  Given his experience in aerospace
> I am sure he understands the nature of requirements.

Thanks. You're right. I can handle the politics. The technical approach
was a decision to do something that would give the customer what they
want at a reasonable cost, if at all technically possible. I'll work it
out. I was just hoping to get something I could plug in and be done with
it. Apparently, it will be a little more involved than all that.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Take away the punchbowl just when the party gets going" 

        --  William McChesney Martin, Former Fed chairman, explaining 
            what a sound central bank must always do. 
======================================================================

Re: UNIX Compressed Files From A PC

[Don Yuniskis]

In article <399944F9.57D5B942@acm.org>,
Marin D. Condic <mcondic-nospam@acm.org> wrote:
>If you have some information
>that will help me out here, I'd appreciate it. But the answer has to be
>some sort of package that does basically what Win32.LZExpand does. If
>you know of something like this, please pass that info along.

I passed you a URL to the compress(1) sources.  The file is 9KB.
Almost 2KB of that is the UCB copyright statement, etc.
Another ~2K is the typical overhead required to write anything
in C (i.e. all the #includes, etc.).

Another chunk is the command line interface -- something that could be
reduced to a set of #define-d variables and removed in a matter of
*minutes* (LITERALLY!!).

I doubt there is 5K of code there that you would have to port.
It is reasonably clear (assuming you have even a rudimentary
understanding of C and <stdio.h> -- and has no bizarre or
undocumented timing/performance criteria that could bite you
by hiding some critical aspect of the algorith.

The time spent looking for a "drop in" solution could have
finished this task...  :-(

--don

Re: UNIX Compressed Files From A PC

[E. Robert Tisdale]

Don Yuniskis wrote:

> In article <399944F9.57D5B942@acm.org>,
> Marin D. Condic <mcondic-nospam@acm.org> wrote:
> >If you have some information
> >that will help me out here, I'd appreciate it. But the answer has to be
> >some sort of package that does basically what Win32.LZExpand does. If
> >you know of something like this, please pass that info along.
>
> I passed you a URL to the compress(1) sources.  The file is 9KB.
> Almost 2KB of that is the UCB copyright statement, etc.
> Another ~2K is the typical overhead required to write anything
> in C (i.e. all the #includes, etc.).
>
> Another chunk is the command line interface -- something that could be
> reduced to a set of #define-d variables and removed in a matter of
> *minutes* (LITERALLY!!).
>
> I doubt there is 5K of code there that you would have to port.
> It is reasonably clear (assuming you have even a rudimentary
> understanding of C and <stdio.h> -- and has no bizarre or
> undocumented timing/performance criteria that could bite you
> by hiding some critical aspect of the algorith.
>
> The time spent looking for a "drop in" solution could have
> finished this task...  :-(
>
> --don

Homer Simpson campaigned for and won
the Sanitary Engineer's office in Springfield
using the slogan, "Can't someone else do it?"
I don't know why I thought of that;-)

Re: UNIX Compressed Files From A PC

[E. Robert Tisdale]

"Marin D. Condic" wrote:

> What part of "I can't guarantee that the file will be on UNIX"
> are you not hearing?
> What part of "Its a political issue - not a technical issue"
> is not getting through here?
> I really don't see how much more plain I can make it.
> I keep saying that the answer
> *MUST BE* one that is built into the program
> and can't be any sort of shell script
> or temporary file or pipe anything of the sort.
> Yet you keep coming back with that response.
> Are you just trying to bait me?
>
> I am not some kind of inexperienced,
> wet-behind-the-ears fresh-out
> who is having his chain jerked by his superiors
> to see if he can figure it out.
> I am not being sent on a snipe hunt
> nor being asked to find a left-handed smoke bender.
> The problem here is very specific
> and I have tried to outline precisely what my need is.
> If you have some information that will help me out here,
> I'd appreciate it.
> But the answer has to be some sort of package
> that does basically what Win32.LZExpand does.
> If you know of something like this, please pass that info along.

I used mu GoTo search engine to search for

    +Windows +compress +uncompress

and I found

    http://www.ncdc.noaa.gov/ol/misc/software.html

Re: UNIX Compressed Files From A PC

[Stefan Skoglund]

"Marin D. Condic" wrote:
> BTW: If in fact all of this falls under some kind of patent
> restrictions, that is O.K. by me. If someone had a package that did what
> I wanted it to do reliably, I'd be willing to pay for it. I've got to

That someone must have a license from unisys if the package
is doing LZW compression !!

Or your customer must get that license by themself !!

Re: UNIX Compressed Files From A PC

[Gautier]

Marin D. Condic:

> I'm looking for a package that can access UNIX compressed files and
> unpack them for me. I'm in a situation where I've got to read these
> files from a WinNT PC and the files will be resident either on the PC or
> across the net on a Sun platform. I want to access them as any other
> byte stream file - Open/Read/Write/Seek/Close operations are what I
> need. Does anybody know of an Ada package that is generally available
> that can do this?

1st solution: (re-)compress your files with 'zip' that exist on all
              platforms: http://www.info-zip.org/pub/infozip/ ,

    then use my Unzip.Streams package - link below. It has Open/Read/Close,
    Seek can be easily added, but Write is a nonsense for compressed files...

2nd solution: adapt the C code for .Z files by customizing 
              Unzip.Streams. But I guess it would take big
              time * person resources...

HTH
_________________________________________________________
Gautier  --  http://members.xoom.com/gdemont/unzipada.htm

Re: UNIX Compressed Files From A PC

[Stefan Skoglund]

"Marin D. Condic" wrote:
> 
> I'm looking for a package that can access UNIX compressed files and
> unpack them for me. I'm in a situation where I've got to read these
> files from a WinNT PC and the files will be resident either on the PC or
> across the net on a Sun platform. I want to access them as any other
> byte stream file - Open/Read/Write/Seek/Close operations are what I

Look for zlib (ftp.gtk.org/pub/gimp/libs/zlib-1.1.2.tar.gz)

zlib implements the gzip algorithm in a library.