Xref:	news2.mv.net comp.os.msdos.djgpp:4859
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	DJP (was Re: Why are they so fat?)
Date:	Tue, 11 Jun 1996 17:24:25 CDT
Organization:	Rice University, Houston, Texas
Lines:	20
Message-ID:	<31bdf219.sandmann@clio.rice.edu>
References:	<31BD8A3B DOT 18441825 AT laden DOT ilk DOT de> <4pk0ea$q12 AT rs18 DOT hrz DOT th-darmstadt DOT de>
Reply-To:	sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host:	clio.rice.edu
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

> I expect DJP to decompress and load the executable into memory at startup, 
> so the user will not notice any difference (except maybe a minor delay).

This is exactly how DJP works.  It currently uses a modified stub to do
the loading.  I have a development version which I will eventually release
which also supports putting the decompression code in the 32-bit image
and uses the standard stub (so you can combine use of the PMODE stuff
and DJP stuff).  The CC1.EXE image from V2 is compressed to around 650Kbytes
and takes an extra 1/2 second or so to load on a 486/33 with a fast disk.
If you have a fast processor and a slow disk, loading DJP images may actually
be FASTER than running the defaults, since it requires less disk cache.

Future versions will have a little tighter compression (and standard stub
compatibility as an option), but Laszlo's work is very impressive and I
wouldn't hesitate to give it a try right now.  Markus Oberhumer who
developed the compression algorithm also deserves a big congrats too.

> PS. anyone have a site for DJP? I seem to have missed the announcement.

Try ftp.simtel.net:/pub/simtelnet/gnu/djgpp/v2misc/mlefp103.zip

- Raw text -