Article View: comp.os.msdos.programmer
Article #7494How to access memory above 640K
From: Stan Brown
Date: Thu, 07 Jan 1993 14:07
Date: Thu, 07 Jan 1993 14:07
106 lines
5985 bytes
5985 bytes
Last-modified: 1993 Jan 3
Part of the following material originally appeared in the FAQ list for
comp.os.msdos.programmer. However, subsequent email revealed that the
answer is not really settled. Since the FAQ list should contain
"canonical best answers", I have created this separate article. One of
my rainy-day projects is to investigate this area myself. Until then,
I'm simply appending the emails and posted articles that seem relevant.
If you want your comments to be appended to this file, please be sure to
email me at brown@ncoast.org. I try to follow the newsgroup, but I may
miss posted articles because c.o.m.p gets heavy traffic.
The following appeared in the December 1992 FAQ list. It is by Jamshid
Afshar (jamshid@emx.utexas.edu) and incorporates comments from Duncan
Murdoch (dmurdoch@mast.queensu.ca).
1. Use XMS or EMS memory. XMS is preferable in most cases, but
some machines won't provide it. There are some libraries available
at Simtel to access XMS or EMS. 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 [and
Microsoft C/C++ 7.0 has QuickWin --ed.] which is a library that
automatically 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 ints and restricts arrays to 64K, but a
32-bit Extender has 32-bits ints (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:
- 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 [?]
- 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.
- 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.]
- Buy Borland Pascal 7.0. It includes a 16 bit royalty-free DOS
extender using the same interface as MS Windows. It functions
under a DPMI server like Windows or QDPMI from Quarterdeck, and
also provides its own server which you can distribute with your
programs.
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?]
Date: Mon, 21 Dec 92 08:36:50 -0500
From: malak@grebyn.com (Michael Malak)
Message-Id: <9212211336.AA02279@daily.grebyn.com>
You should also mention the Intel 386/386 C Code Builder Kit. It is
a 32-bit C compiler, linker, and 32-bit DOS extender. It is the
_only_ 32-bit DOS extender that allows you to link in 32-bit MASM
6.0 modules, thus obviating the need to buy Phar Lap's assembler and
be stuck with its archaic MASM 4.x syntax. All for a list price of
$595.
Date: Thu, 24 Dec 92 13:45:40 EST
From: dmurdoch@mast.QueensU.CA (Duncan Murdoch)
Message-Id: <9212241845.AA23280@mast.mast.QueensU.CA>
I don't know anything about the Intel package, but certainly
wouldn't object to putting the information in. I'd delete the claim
that it's the only package to link MASM code; that may be true, but
isn't likely to last for long.
--
Stan Brown, Oak Road Systems brown@Ncoast.ORG
Cleveland, Ohio, USA
Technical Details
Message-ID:
<C0HLx8.IAL@NCoast.ORG>Path:
arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast!brownReferences:
noneShow Full Headers
Complete Article Headers
Newsgroups: comp.os.msdos.programmer Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast!brown From: brown@NCoast.ORG (Stan Brown) Subject: How to access memory above 640K Organization: Oak Road Systems, Cleveland Ohio USA Date: Thu, 7 Jan 1993 14:07:55 GMT Message-ID: <C0HLx8.IAL@NCoast.ORG> Followup-To: comp.os.msdos.programmer References: none Lines: 106