Article View: alt.msdos.programmer
Article #613Re: QEMM/386
From: Steve Luzynski
Date: Mon, 09 Nov 1992 20:39
Date: Mon, 09 Nov 1992 20:39
95 lines
5678 bytes
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!sal8References:
<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