Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!jato!mars!kaleb
From: kaleb@mars.jpl.nasa.gov (Kaleb Keithley)
Newsgroups: comp.lang.c
Subject: Re: Expanded/Extended memory use in MSC 5.1
Keywords: expanded extended memory microsoft
Message-ID: <2581@jato.Jpl.Nasa.Gov>
Date: 16 Jan 90 17:27:08 GMT
References: <8559@stiatl.UUCP>
Sender: news@jato.Jpl.Nasa.Gov
Reply-To: kaleb@mars.UUCP (Kaleb Keithley)
Organization: Jet Propulsion Laboratory, Pasadena, CA.
Lines: 64

In article <8559@stiatl.UUCP> arw@stiatl.UUCP (Allan Watkins) writes:
>   1) Is it true (and impossible) that MSC cannot allocate memory into the 
>       expanded/extended range?

Yes and no.  While someone who knows the MSC docs better than I will surely
flame me, my knowledge of the MSC library functions suggests that there is no
function group providing direct access to ext/exp memory.  However, the BIOS
on 286 and up machines has a function to provide access to extended memory
which can be accessed through MSC's int86().  You can definitely plan to do
your own extended memory management.

>   2) From a friend of mine I was told the following blocks are usused by DOS
>       and therefore should be available to an application program.
>               C0000 - C7FFF  = 32k
>               D0000 - EFFFF  = 128k
>       Is it possible or safe to just start using this memory by declaring a
>       far pointer at a particular position and going to town?

This memory is unused by DOS because *there is no memory there* unless you have
something like QEMM on a 386 that relocates other memory into this area.  Don't
rely on any PC having memory at these locations.  You can write and read to
these locations, but don't expect to get anything back but junk.

>       Is there any way to tell MSC to allocate memory from those ranges, or 
>       add them into the heap by pointers (I'm really reaching, I know)? 

NO!.

>       I also read in the Advanced MS-DOS book the interrupt 67H along with
>       EMM (Expanded Memory Manager) can provide access to the expanded memory

YES!

>       Would this interrupt interfere with MSC's handling of the heap?

NO!.

>       Would the best solution be to write our own heap manager and bag the 
>       MSC stuff? 

Only if you want to do a *lot* of work.

>   3) What is the difference between "real" and "protected" mode when dealing
>       with extended memory?  What does an application/program lose or have to
>       deal with when the computer goes from real to protected mode?

In order to get at extended memory, the CPU has to switch into protected mode,
do its' thing with memory, then switch back.  This is all handled by the BIOS
function mentioned above.  The application gains lots of memory.  The
application loses a little speed (mode switching costs something) and the
ability to run on PC and XT machines.


>   4) WHEN IS SOMEONE GONNA MAKE IT EASY TO USE EXPANDED AND EXTENDED MEMORY
>       IN NORMAL MSC C LANGUAGE? (no violins please).
   
I have said this before, and while I'm not in any way endorsing them or their 
products, Microsofts' MS-DOS encyclopedia is one of the best resources around 
for DOS programming.  There are articles in there complete with code, that 
explain the care and feeding of ext/exp memory.
Chewey, get us outta here!
                 
kaleb@mars.jpl.nasa.gov             (818)354-8771
Kaleb Keithley