🚀 go-pugleaf

> The application we are developing has gotten to the point where the
> linking operation by itself takes more than 20 minutes due to
> extensive disk spooling.
> ... 
> Will additional RAM speed up the link operation?
> ...
> What RAM does the linker use? (640K only, Expanded, Extended?)
 
We had that same problem with Winfract.  In our case, we were taking 15
minutes *if* we used a RAM-Disk *and* we ran the link under MS-DOS with
Quarterdeck's VIDRAM package giving us access to 736K of "real" MS-DOS
memory *and* we weren't using the debugging [/CO] option - otherwise it
was taking a lot longer.  Microsoft's LINK program apparantly uses
only "real" MS-DOS memory and overflow disk files.
 
In our case, the solution was to switch to the ILINK (Incremental link)
version of the linker.  Once we got around the bug in ILINK that was
killing us, everything worked great.  Using ILINK, we can perform a
full link in under 2 minutes.
 
The ILINK bug that we ran into involved a FAR array that was dimensioned
60K bytes - LINK was handling it correctly, but ILINK was messing it
up, causing Winfract to UAE the as soon as it referenced that array.  We
changed our code to use a pointer and 'GlobalAlloc()', and now everything
works fine.