Xref: utzoo comp.sys.ibm.pc.misc:9298 comp.windows.ms.programmer:2214
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!netcomsv!wolf
From: wolf@netcom.COM (Buckskin Tech.)
Newsgroups: comp.sys.ibm.pc.misc,comp.windows.ms.programmer
Subject: Re: Using Borland C++
Message-ID: <1991May3.234740.21002@netcom.COM>
Date: 3 May 91 23:47:40 GMT
References: <1991Apr5.171426.28904@SanDiego.NCR.COM> <1038@stewart.UUCP> <1991Apr11.162855.10164@SanDiego.NCR.COM> <1991Apr12.154854.29070@SanDiego.NCR.COM> <1991May2.192124.26449@unlv.edu>
Sender: netnews@netcom.COM (USENET Administration)
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 19

whitney@sunnyland.cs.unlv.edu (Lee Whitney) writes:

>    Really!

>	Why is protected mode an excuse?  The Turbo C 2.0 linker was lightning fast in real mode, so obviously it's possible to avoid at least an unreasonable delay.  That kind of link speed is not even livable let alone likable.

The Turbo C linker was only designed to link DOS-mode apps.  When linking for
DOS mode, the Borland C++ linker is at least respectable.  However, this is
Borland's first linker for Windows (the NewEXE format), and believe me, the
NewEXE format is NOT easy to work out.  I would guess that Borland tries to
make sense of the convoluted NewEXE format by keeping tables of everything in
memory.  When running in Real mode, that's too much to store, so it tries to
do it piecemeal (and takes forever).  In Protected mode, it can store all the
tables in memory at once, so it can be reasonably fast.  

Again, this is only a guess.  I'm just waiting for the next revision of the
Windows linker, hoping it'll be faster in Real mode.

 - Wolf