Date: Fri, 4 Sep 92 08:53:45 EDT
From: DJ Delorie <dj AT athena DOT ctron DOT com>
To: pynq AT midway DOT uchicago DOT edu
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Stub answers & why 1.08 isn't 1.07 compatible

>	1) The minimum system is listed as being DJDEV107 (!),
>		DJGAS138, and DJGCC222
>		a) Should be 108
True.  A patch was posted.

>		b) Don't you also need DJGPO222 ?
Not if you just want to do C programming.

>	2) Because many of the doc files are duplicated among the files,
>	   the PKUNZIP instructions given should include "-o".
Will do.

>Also, observe:

>	TMAP_NEW EXE    16641   9-03-92   2:29p
>	TMAP     EXE    16675   9-03-92   2:46p
>	TMAP            10531   9-03-92   2:29p

>TMAP is my A.OUT, TMAP.EXE was created with AOUT2EXE, and TMAP_NEW.EXE
>was created by brute force concatenation of STUB.EXE (current version is
>6110 bytes) with TMAP.  Just out of curiosity, what is the difference?
>(Both .EXE's seem to work)  I looked at AOUT2EXE.C, and noted that it
>seemed to be doing some kind of padding of the bytes from STUB.EXE (I am
>also reasonably up-to-date on what BIN2BYTE does), but couldn't
>figure out exactly how or why AOUT2EXE was doing what it was doing.

I go through great hoops to ensure that the a.out file is sector
aligned to ensure greatest performance.  However, stub.exe isn't a
multiple of sector size.  In 1.08, aout2exe is smart enough to grow
the stub.exe image it uses to a sector boundary to ensure that all
disk accesses are sector-aligned.  This increased performance 10-50%
(depending on cache configuration) but also uncovered a math bug in
control.c dealing with the .exe size.  Thus, 1.07 can't load an .exe
built with 1.08's aout2exe.

The brute force copy will work with 1.07 but will be slower to page
in.