🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: alt.msdos.programmer
Article #613

Re: QEMM/386

#613
From: Steve Luzynski
Date: Mon, 09 Nov 1992 20:39
95 lines
5678 bytes
In article <4141@bcstec.ca.boeing.com> silverm@bcstec.ca.boeing.com (Jeff Silverman) writes:
>From: silverm@bcstec.ca.boeing.com (Jeff Silverman)
>Subject: QEMM/386
>Summary: What is QEMM 386 actually doing and how does it do it?
>Keywords: QEMM memory management 80386
>Date: 9 Nov 92 05:44:05 GMT
>
>I am a VAX/VMS guru in the process of becoming an MS-DOS guru.  If these
>questions sound naive, it is because I am coming at these from a strange
>perspective.

Not naive actually - more like questioning the lack of common sense 
involved in DOS programming. Most of us have been asking the same things for 
years. It's because DOS was written way back when no one could imagine 
needing more than 64K of memory. To this day DOS is still configured to run 
on an 8086.

>In the VAX/VMS operating system, programs execute in their own virtual address
>space, which gets mapped on a page by page basis into physical memory.  2 VMS
>programs can be running at the same virtual address yet address different
>pages of physical memory, because the mapping is done on a per-process basis
>and the OS handles all that transparently.  The programmer sees 1, big pool
>of RAM.

Sounds like OS/2. :)
[I am a certified OS/2 addict. I admit it.]

>What does QEMM/386 do, from a programmers point of view?  It appears to move
>things around in both physical and virtual memory.  How is this possible?
>If something, say, a TSR, is moved out of low memory and into either High
>Memory (By high memory, I mean the region between 640K and 1 Mbyte) or extended
>memory, how does it keep working?  All of the destinations for jump instructions
>would change.  Or does the 80386 have additional memory relocation?
>How does QuarterDeck's OPTIMIZE program work?  Please don't say it works well,
>I KNOW it works well, I've been playing with it, I can see that it works, but
>don't know what it's doing or how it does it.  Well, I do know what its doing,
>it's modifying CONFIG.SYS to free up more RAM in the lower 640K region.

A program like a TSR would have been written from the start to execute no 
matter where it gets loaded - i.e. no absolute jumps. You'd use branches if 
you could or a jump table that you fill in at loadtime if not. (I'll 
admit there are probably more sophisticated ways to do that. Different 
strokes...I first did the jump table thing on my Apple //e... [ugh])

>Why does DOS have a 640Kbyte limit?

Ask Bill Gates. :)
Seriously, it's because DOS was written for the 8086 which had a physical 
address limit of 1M. (20 address lines - 2^19 = 1M.) Of this, the last 384K 
was designated as for use by the operating system and by system ROMs by the 
designers. (Like I said, they never dreamed people would actually have 64M 
of RAM in their _desktop_ machines.) This was a convenient number since 
640K = 10 64K segments, each of which can be addressed directly with 16 
bits. 

>Why would anybody ever want to use expanded RAM if extended RAM is available?

You wouldn't. It just hangs around since some older programs used it because 
at the time (pre-386) it was the only option. And there _are_ still people 
with big expanded memory cards in their machines that would whine 
incessantly if they were told to join the late 80's and chuck them.

>If I have a "C" program which runs properly under VMS, but needs, say, 3 Mbytes
>of RAM to store all its data structures, what is the best way to run it under
>DOS?  Under Windows?

Under DOS I would go for overlays. Either to XMS or to disk, depending on 
what's available and how nice of a pre-built overlay manager you use.

Under Windows all you have to do is ask the Windows memory manager for the 
memory. It does the virtual remapping thing you were talking about.

Under OS/2 you also just ask for it. You can get all the physical RAM you 
want plus as much virtual as the user has room for on their HD. Plus you 
don't have to deal with segmented addressing (which is really irritating to 
have to deal with under DOS and, to some extent, Windows.).

Really the nicest thing that QEMM does for the DOS user is pool all physical 
memory and reallocate whatever is needed to running programs as whatever 
type they want. In theory all of the other features are already in DOS 
(except for the stealth feature) - they're just better implemented under 
QEMM. (or 386Max for that matter)

Good luck with your quest. If you need more I'm sure someone else (or me for 
that matter) can fill in the gaps.

----------------------------------------------------------------------------
Steve Luzynski @ Case Western Reserve University in Cleveland, OH
sal8@po.cwru.edu             | voice calls cheerlessly accepted at x2153.
----------------------------------------------------------------------------
current mental status: more or less at peace with the world, all things 
considered.
----------------------------------------------------------------------------
this post was written while i should have been doing homework. therefore,
you are indirectly responsible for my current gpa, such as it is.
Technical Details
Message-ID: <sal8.154.721341573@po.cwru.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!agate!usenet.ins.cwru.edu!b61442.STUDENT.CWRU.Edu!sal8
References: <4141@bcstec.ca.boeing.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!agate!usenet.ins.cwru.edu!b61442.STUDENT.CWRU.Edu!sal8
From: sal8@po.cwru.edu (Steve Luzynski)
Newsgroups: alt.msdos.programmer
Subject: Re: QEMM/386
Date: Mon, 9 Nov 1992 20:39:33 GMT
Organization: Case Western Reserve University
Lines: 95
Message-ID: <sal8.154.721341573@po.cwru.edu>
References: <4141@bcstec.ca.boeing.com>
NNTP-Posting-Host: b61442.student.cwru.edu
Summary: What is QEMM 386 actually doing and how does it do it?
Keywords: QEMM memory management 80386