NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/os/msdos/programm/11862

Text File | 1993-01-07 | 5.7 KB | 118 lines

Newsgroups: comp.os.msdos.programmer
Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast!brown
From: [e-mail] (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: <[e-mail]>
Followup-To: comp.os.msdos.programmer
References: none
Lines: 106

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 [e-mail].  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 ([e-mail]) and incorporates comments from Duncan
Murdoch ([e-mail]).

    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: [e-mail] (Michael Malak)
Message-Id: <[e-mail]>

    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: [e-mail] (Duncan Murdoch)
Message-Id: <[e-mail]>

    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                      [e-mail]
Cleveland, Ohio, USA