From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.os.msdos.programmer
Subject: FAQ CORRECTION: there is no BC++ 4.0
Summary: Don't believe everything you read, even if I wrote it
Date: 23 Nov 92 23:19:07 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

The FAQ List Part 3 says:
>Q609. How can I access memory beyond 640K?
>    I'm outside my expertise on this one, but in November 1992 Jamshid
>    Afshar (jamshid@emx.utexas.edu) kindly supplied the following:
>    ...........................(begin quote)............................
>    [...]
>    3. Use a DOS extender.  This is definitely the best solution from
>    [...]
>    - Wait for Borland's DOS extender package (in BC++ 4.0) that is
>      supposed to be released at the end of this year.  I believe MS is
>      also doing the same.  [...]

The references to BC++ 4.0 and its release date were COMPLETE
SPECULATION on my part which I wrote up several months ago.  I
sincerely apologize for not editing the information I sent to Stan for
correctness and for not removing my speculations and personal bias.  I
honestly have no inside information about Borland's or MS's plans for
their future DOS products.  A Borland employee has recently posted
that BC++ 4.0 is not even a product.  I'm appending what I should have
sent to Stan.  Please ignore the answer in the current (Nov. 15) FAQL.

--Jamshid's answer to the FAQ "Is there any way to access over 640k in DOS?"--

You have several options.

1. Use XMS memory (don't bother with EMS).  There are some libraries
available at Simtel to access XMS.  The disadvantage is that you don't
allocate the memory as you would with malloc() (or `new' in C++).  I
believe it also requires that you lock this memory when in use. This
means your code is not easily ported to other (and future) operating
systems and that your code is more convoluted than it would be under a
"real" os.  The advantage is that the library works with compilers
since Turbo C 2.0 (I think) and that your program will easily run on
even 286s.

2. Program under MS Windows.  MS Windows functions as a 16-bit DOS
Extender (see #3).  Borland/Turbo C++ 3.x includes EasyWin which is a
library that automaticly lets you compile your current code using
C/C++ standard input or <conio.h> into a MS Windows program so your
code can immediately allocate many MBs of memory (Windows enhanced
mode even does virtual memory).  The disadvantage is that like any
16-bit Extender a single malloc() is restricted to 64K (unless you
want to mess with huge pointers in Windows).  Also, EasyWin's screen
output is significantly slower than a DOS character-mode program's
and you must of course run the program from Windows.

3. Use a 16-bit or 32-bit DOS Extender.  This is definitely the best
solution from the programmer's standpoint.  You just allocate as much
memory as you need using malloc() or `new'.  A 16-bit Extender still
has 16-bit 'int's and restricts arrays to 64K, but a 32-bit Extender
has 32-bits 'int's (which makes porting a lot of UNIX code easier) so
there are no 64K limits.  A 32-bit Extender requires a 32-bit compiler
and the program will not run on 286s.  Some Extenders also do virtual
memory.  Using an Extender doesn't require source code changes and
unlike option #1 your code is portable and not obsolete in a few
months.  Your options for this solution are:
   a. Buy PharLap's 16-bit Extender that works with BC++ 3.0+ and MSC
      (just requires a relink).  Note, the BC++ 3.1 upgrade came with
      PharLap "lite".  Pharlap's 32-bit Extender works with 32-bit
      compilers like [?]
   b. Get the GNU (free,copylefted) gcc 2.x compiler which DJ Delorie
      ported from UNIX and which uses his 32-bit Extender.  It supports
      C and C++, but the Extender is VCPI which means neither the compiler
      nor programs it produces will run in a DOS session under Windows.
      FTP to barnacle.erc.clarkson.edu and get pub/msdos/djgpp/readme.
   c. Get a 32-bit compiler or one that comes with a DOS Extender.
      Zortech comes with 16-bit and a 32-bit Extenders (no debugger for
      32-bit programs, but Flashtek sells one).  Watcom also makes a
      C [and C++?] 32-bit compiler.  [If anyone else has products or
      plans to announce, please let me know.]

4. This option doesn't really count since it's not a solution in DOS,
but you could switch to a full 32-bit operating system like OS/2 2.0
or UNIX (or NT when it comes out).  I believe Win32 will allow you to
write 32-bit Windows programs. [can someone fill me in on what exactly
Win32 is?]

Jamshid Afshar
jamshid@emx.utexas.edu

Newsgroups: comp.os.msdos.programmer,comp.sys.ibm.pc.programmer