arw@stiatl.UUCP (Allan Watkins) (01/17/90)
Did you ever browse the news at work, learn a few things and then forget
what you really learned? Well, I have just been presented a problem with
memory allocation in Microsoft C 5.1 which I am kind of new to but have
read about it here before.
We are currently using the Huge memory model for our very large application
and have already overcome the memory fragmentation existing in MSC 5.1. What
we'd like to do is to use as much of the expanded memory as possible and even
the extended memory but I don't understand a few things. Two requirements
pertaining to the following questions is that any solutions will need to be
portable to a large number of (if not all) PC's and that we would like to not
have to install (or use) an outside packages to solve the problem. We would
also like to not have to write assembly code although we will if that is the
only way.
1) Is it true (and impassible) that MSC cannot allocate memory into the
expanded/extended range?
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? 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)?
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.
Would this interrupt interfere with MSC's handling of the heap? Would
the best solution be to write our own heap manager and bag the MSC
stuff? I'd be very interested in finding out what other companies have
done to solve this problem.
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?
4) WHEN IS SOMEONE GONNA MAKE IT EASY TO USE EXPANDED AND EXTENDED MEMORY
IN NORMAL MSC C LANGUAGE? (no violins please).
As a side note (whether it makes a difference or not), all of the displays
in our application are in standard extended ASCII codes, no graphics that
I know of.
Any and all comments are eagerly awaited. Thank you.kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (01/17/90)
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
Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (01/18/90)
In an article of <16 Jan 90 17:27:08 GMT>, kaleb@mars.jpl.nasa.gov (Kaleb Keithley) writes: >> 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. Zortech C/C++ 2.0 includes functions for directly working with extended and/or expanded memory. It also includes a new pointer type, supported at the compiler level, for handling almost any type of memory, including disk-based virtual memory. Note that the current release only supports extended and expanded memory, but the way it's written, full virtual memory support can't be too far off. Then, there's OS/2...
bright@Data-IO.COM (Walter Bright) (01/25/90)
In article <8559@stiatl.UUCP> arw@stiatl.UUCP (Allan Watkins) writes:
< 4) WHEN IS SOMEONE GONNA MAKE IT EASY TO USE EXPANDED AND EXTENDED MEMORY
< IN NORMAL MSC C LANGUAGE? (no violins please).
In Zortech C, there is direct compiler and library support for allocating
space in and having pointers into expanded memory. This is done with a
special pointer type, called a __handle pointer, that the compiler supports.
Accessing memory through a __handle pointer causes the appropriate EMS
page to be swapped in, etc., all transparently.
The current implementation does not support extended memory, though this is
a limitation of the library support for it, not the compiler.
This, of course, doesn't help you if you wish to use MSC! :-)rreiner@yunexus.UUCP (Richard Reiner) (01/25/90)
bright@Data-IO.COM (Walter Bright) writes: >In article <8559@stiatl.UUCP> arw@stiatl.UUCP (Allan Watkins) writes: >< 4) WHEN IS SOMEONE GONNA MAKE IT EASY TO USE EXPANDED AND EXTENDED MEMORY >< IN NORMAL MSC C LANGUAGE? (no violins please). >In Zortech C, there is direct compiler and library support for allocating >space in and having pointers into expanded memory. >This, of course, doesn't help you if you wish to use MSC! :-) The excellent shareware CXL library provide EMS handling for MSC (as well as other compilers). See PD:<MSDOS.C> on Simtel20 for a recent version. --Richard