Date: Tue, 26 Oct 1999 15:03:43 +0200
From: Laszlo Molnar <laszlo DOT molnar AT eth DOT ericsson DOT se>
To: Laurynas Biveinis <lauras AT softhome DOT net>
Cc: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>,
        Charles Sandmann <sandmann AT clio DOT rice DOT edu>, djgpp-workers AT delorie DOT com
Subject: Re: Read Me Third: A Short FAQ List (fwd)
Message-ID: <19991026150342.G4229@crater.eth.ericsson.se>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 991025140022 DOT 9200G-100000 AT is> <38159942 DOT D0BD0109 AT softhome DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <38159942.D0BD0109@softhome.net>; from Laurynas Biveinis on Tue, Oct 26, 1999 at 02:06:26PM +0200
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Tue, Oct 26, 1999 at 02:06:26PM +0200, Laurynas Biveinis wrote:
> I think that djp stub which uncompresses the program
> itself already requires DPMI services, but PMODE stub
> still is compressed at this point...
> Could this be true?

Djp compressed programs look like this:
section .text : the djp uncompressor
section .data : the compressed data

After the loader loads the coff image, djp decompresses the program
(without using any dpmi calls) then it jumps to the original entry
point of the program. So in theory djp compressed programs should work
just like uncompressed programs.

IIRC, the only 'trick' djp uses is that it loads the .text section to
virtual address 0xa8 (this works because only the djgpp startup code
protects that page and not the loader).

Laszlo