Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!holos0!lbr
From: lbr@holos0.uucp (Len Reed)
Newsgroups: comp.compression
Subject: Re: Problems running compress from perl on MS-DOS
Keywords: compress, perl, MS-DOS
Message-ID: <1991May13.141633.18059@holos0.uucp>
Date: 13 May 91 14:16:33 GMT
References: <991@camco.Celestial.COM>
Organization: Holos Software, Inc., Atlanta, GA
Lines: 52

In article <991@camco.Celestial.COM> bill@camco.Celestial.COM (Bill Campbell) writes:
 [script deleted]
 
>This works fine on Xenix/Unix systems, but the MS-DOS version has
>one of two problems:
>	1.	It frequently says that it is out of memory compressing
>		from stdin.  I have recompiled compress for 12-bit
>		compression and it does this less frequently, but it
>		still does it.

It's tough to run *any* subprocess from non-swapping perl.  I distributed
an enhanced 3.041 version in the fall that swapped perl to disk or RAM-disk
when running a subprocess.  (Perl takes over 300K before it even starts
mallocing.)

Tom Dinger was folding swapping code into 4.x last I heard.  I've been
meaning to write to him.  In the meantime you should be able to find
the swapping version any place that archive comp.binaries.ibm.pc.

>	2.	The compressed file is longer than it should be.  It
>		appears that it might be created as a text file rather
>		than binary when the standard output is redirected to the
>		file.

Your diagnosis is surely correct.  Your compressed file will be hopelessly
corrupt, since 0xA will become {0xD, 0xA}.  The problem is in compress
itself, which is writing "text" mode.  (BTW, it's probably also reading
in text mode: if you're reading a binary file this, too, is a problem.)

You must alter compress so that it handles the output file in binary.
The can be done at output time by ORing in O_BINARY along with
the usual assortment of O_ flags.  For already-open files (e.g., stdout),
use "setmode (handle, O_BINARY)".  Key this all on "#ifdef MSDOS" and
you're all set.

BTW, binmode() in perl simply executes setmode(handle, O_BINARY).

>I'm using compress,v 4.3d compiled with Xenix cc -dos in large model.
>
>I don't know much about MS-DOS (by choice), and don't understand
>why this should fail in this manner.  Compressing in-place works
>fine under MS-DOS.

I don't have 4.3 source.  Perhaps the open() call has O_BINARY but
there's no setmode() call to handle the case of writing to stdout?


-- 
Len Reed
Holos Software, Inc.
Voice: (404) 496-1358
UUCP: ...!gatech!holos0!lbr