NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/compress/4578

Internet Message Format | 1993-01-11 | 5.0 KB

Path: sparky!uunet!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!lugb!news
Newsgroups: comp.compression
Subject: Re: Diet v1.44
Message-ID: <[e-mail]>
From: [e-mail] (CROSS,Graeme)
Date: Tue, 12 Jan 1993 00:13:49 GMT
Sender: [e-mail] (USENET News System)
References: <[e-mail]> <[e-mail]>
Organization: La Trobe University
In-Reply-To: [e-mail]'s message of 10 Jan 93 17:54:21 GMT
X-News-Reader: VMS NEWS 1.24
Lines: 89

In <[e-mail]> [e-mail] writes:

> [e-mail] (Germain Leutwyler) writes:
> >I found few weeks ago the above utility in the well-known but anonymous
> >ftpsite nic.funet.fi under \pub\msdos\utilities\filutl.
>
> >I use it for all files on my HD but it is not an archiver !
>
> >All files could be made self-extractable (.EXE, .COM, .SYS) including
> >programs with overlays (!!!) and DATA files too.
>
> >This utility could be run in TSR mode, the memory space used is
> >minimal and speed is adequate (transparent for the user).
>
> >It is a good alternative versus complete subdirectories archivers for
> >people being short in space with their HD. Try it and let me know your
> >feelings afterwards !
>
>
> There is a few problems with diet 1.44 beware of this:
>
> 1: pkzip v1.93 and hpack0.78a0 doesn't work if some files are packed
>    with diet. Use arj instead.
> 2: Some games destroyed themself if they are diet-packed because
>    they write direct to their .exe files. E.g. twinpac
> 3: diet is very slow with some overlayed program. e.g. fractint 17.2
>    (very very slow).
>

I use DIET v1.44 quite happily on my system: I'm running MS-DOS 5 and use a
number of other TSRs and have found very few problems.

The advantages of DIET:
1. It's free.
2. You can select the degree of effect DIET has upon your system: you can
compress executables (no TSR), you can compress data files that are only ever
read (TSR on) or you can compress data files for both reading and writing (TSR
on). I run DIET as a TSR with all my on-line documentation compressed: so if I
want to read the 4DOS manual, I just use LIST to read it: the difference being
that 4DOS.DOC takes up about 20% of the space that it did before I compressed
it with DIET (it was about 1M big). I have had no problems running it in this
mode, and it's a valuable function that PKLITE and LZEXE don't support.
3. Your mileage may vary, but I found I got better compression on executables
from DIET than I did from LZEXE or PKLITE.
4. DIET is one program: you don't need a CHK4LITE program to see if your files
have been compressed: just DIET -L *.*
5. If you have EMS, DIET will occupy 1-2K in standard memory; it also loads
fine into UMBs if you have DOS 5.
6. You can compress executables with almost any sort of overlay (try doing that
with PKLITE. (You do need to be in TSR mode for this to work usually)
7. If you don't like DIET, you can easily remove it's compression: DIET -ra *.*
will remove it all for you. That makes it a *LOT* easier to remove than Stacker
or SuperStor. If you find that a certain program doesn't like DIET, just remove
the compression; with Stacker or SuperStor, I have to shift the program from
the compressed partition to an uncompressed partition (assuming I have one :-(
8. Compression is better than Stacker's or SuperStor's (though your mileage may
vary).

Disadvantages:
1. If you use DIET in read-and-write TSR mode, you will find that some programs
don't support automatic recompression. This requires you to experiment with the
different programs that you use, but it's worth trying. This is to expected
when you think about it: DIET is sitting on top of DOS, and hasn't replaced the
file system (a la Stacker) - some programs are bound to get around DIET, and
indeed, some do.
2. As mentioned by the previous poster, DIET can be slow with some overlaid
programs. True, but two replies: i) At least DIET (in TSR mode) will work with
virtually all overlaid programs - PKLITE and LZEXE usually refuse to compress
an overlaid program (in my experience anyway), and ii) DIET has two
decompression options: small and fast, and not-as-small but faster. If you asre
finding that DIET is compressing an overlaid program slowly, try the faster
option. You also have to remember that the example program given (FRACTINT) is
a very big program (700-800K last time I looked).
3. DIET seems to fail on compressing some very large Turbo Pascal programs that
I have written. I'm not too sure if this is just a quirk of my system, or if it
is a failing of DIET - I'm still exploring this problem, and will report my
findings back to comp.compression when I'm through.
4. The documentation isn't as clear as the PKLITE documentation: but it's not
too bad for a Japanese program!

Conclusion:
DIET is definitely worth the look, and IMHO the advantages outweigh the
disadvantages easily: I've been a satisfied DIET user now for a couple of
years.

-------------------
Graeme Cross                           No .sig today.
[e-mail]