This article describes how DesqView works with XMS, but that implies a 286+ with 1Mb+ of memory. How did it perform task switching on an 8088 with 640Kb? I thought the MS-DOS task switcher was capable of swapping to disk, but that’s only feasible because it’s a full screen task switcher so having a noticeable delay while switching tasks is expected - a windowing environment presumably needs to be able to switch tasks in less than a second.
Good question… memory management options on DOS machines is a topic that deserves a full post (I’ve put it on my list), but I probably elided a little too much from this message. A quick rundown on the topic: the 8086 thru 80186 only had a 20-bit address bus and so could map 1MB, a good chunk of which was “reserved-ish” for hardware purposes, leaving 640k. The 286 had a bigger address bus and could support 16MB, the 386 even more so, but this matters less than you would think in practice because virtually all DOS software at this point ran in real mode without the ability to use any of that extra memory. The solution was (skipping some complexity here) a device driver that used the MMU to remap sections of the past-1MB memory down into the real mode address range for programs to use. And that’s what we usually call XMS, although there were other conventions as well.
That makes sense, but what about, say, the 8088? Well, it turns out the solution is basically the same: remap “extended” memory into the 640k standard range. But since the 8088 has only 20 address wires and no MMU, it can’t be done onboard. Instead, it was done off-die by an expansion card that basically intercepted the memory bus to remap different sections of expanded memory into a 64kb “window” in the real mode memory space. Running software had to hit specific interrupts to prompt the expanded memory card to change the mapping. Such controllers on ISA cards were pretty readily available in 4MB and 8MB sizes, and while I don’t know this for sure, I’m making a pretty confident assumption that DESQview on 8088 required one.
The standards for these get confusing due to competition and fast change… EMS (extended memory specification) is typically associated with these 8088 systems, but I think there were at least a few other less common standards, and IBM had XMA which you could say is the ancestor to XMS. In late pre-286 machines there was sometimes an on-motherboard EMS controller that almost felt like an MMU. But in short, an “expanded memory manager” defined broadly was software on the 80386 but hardware on the 8088. Further complicating things a lot of 80386 memory managers could emulate the old-style hardware memory page switching so that you could use software written against EMS. These didn’t play nicely with each other so you might have to manually choose to allocate certain memory ranges to either extended memory or expanded memory, and trying to keep “extended” vs “expanded” straight kind of typifies how annoying this must have been for users. I got a desktop technician certification on the very trail end of any of this being relevant and remember serious headaches over all this.
DESQview was also limited on non-80386, although I’m not sure of the exact issues. I know for example that later versions of DESQview were capable of windowing direct-drawing programs (e.g. vga raster programs) on the 386 by use of the MMU to remap the framebuffer, but could only run such programs full-screen on earlier processors.
For the top of the third paragraph, you mean expanded, right? (EMS == Expanded, XMS == Extended?)
XMS worked by throwing the CPU into protected mode so it could address more memory temporarily, then thunking back to real mode. That’s what HIMEM.SYS was for. No remapping is needed here. But as you suggest, this isn’t possible on an 8088, since it didn’t have physical addressing.
Remapping memory down into real mode was possible on the 386, which had something resembling an MMU. That’s what EMM386 was for, which could use the CPU to implement EMS. As far as I know the 286 didn’t have enough support for remapping, but still had protected mode so could still use pure XMS.
Hardware EMS existed but never seemed widespread. It was a way to upgrade an 8088 system without replacing it. But by the time 1Mb+ of memory started to be desirable, there was no reason to get an 8088, so at least in my neighborhood, these were rare. I had an 8088 laptop with 128Kb of EMS, but was never able to use it due to lack of a driver (sigh.)
The way I read their literature, DESQview supported a pure 640Kb 8088 environment, no EMS. Quarterdeck were the masters of PC memory management in their day, and they may have had a lot of tricks I don’t know about. Obviously it’s possible to physically copy memory around within 640Kb, but because that memory is effectively a stack, the only way I can imagine this working is to firstly reserve a swap area upfront then allow applications to run in the remainder, and applications can then be copied from the remainder to the swap area. But that means the size of this region has to be statically provisioned before any application can run, which seems gross. Putting the swap area at the other end of RAM is dangerous since DOS can’t describe it as allocated and an app would just grow into it. Since it’s already a TSR, perhaps they intercepted calls to query memory size and just lie, and hope that programs won’t inadvertently use unprotected but theoretically unavailable addresses?
Putting the swap area at the other end of RAM is dangerous since DOS can’t describe it as allocated and an app would just grow into it. Since it’s already a TSR, perhaps they intercepted calls to query memory size and just lie, and hope that programs won’t inadvertently use unprotected but theoretically unavailable addresses?
This doesn’t sound right. DOS must know both where the beginning and and of allocatable memory lies, otherwise, it might try to overallocate on a computer that has only 512KB instead of 640. I recall that if you had a VGA card, there was a way to convince DOS to use video RAM beyond 640KB all the way to b800h where text mode memory starts, for an extra 96KB of conventional memory.
DOS must know both where the beginning and and of allocatable memory lies, otherwise, it might try to overallocate on a computer that has only 512KB instead of 640.
Right, I agree - that’s what I was trying to say in the last sentence. It has to know the end of memory, but has no way to describe randomly allocated regions within the conventional area because it was single tasking so memory was allocated as a stack. I don’t know what this call looks like and what semantics it has though. Since application memory access isn’t really controlled by DOS, all this can be is a guideline though - a program can just access an address and see what happens, and if they do, they’d trash anything that’s there.
Edit: Another possibility - did DOS start allocating high addresses and work downwards? This would seem logical and would make using those addresses above 640Kb relatively straightforward by just loading DOS at the desired address and applications don’t change. But if that happened, it really would be impossible to allocate memory at the “other end”, since the end of memory is a well known value (zero.)
I recall that if you had a VGA card, there was a way to convince DOS to use video RAM beyond 640KB all the way to b800h where text mode memory starts, for an extra 96KB of conventional memory.
I didn’t know this was possible with VGA. I remember doing it with CGA under OS/2, even to the point of running real mode Windows with 700Kb of conventional memory, although CGA is … CGA.
Edit: Wikipedia suggest that this was possible on MDA/Hercules/CGA, but not with EGA; didn’t VGA include EGA compatibility?
Memory for Hercules graphics is at B000h, so you can safely map memory into A000h-AFFFh.
Color text mode memory is at B800h, so you can map memory below that as long as you stay out of graphics mode. That’s true for CGA, EGA, and VGA.
What I remember doing (and I could be mistaken on this; it was a long time ago and I was in high school) is using VGA video memory at A000h while in text mode. But maybe I remember wrong and just mapped memory there with EMM386.
To get DOS to use that memory as conventional memory you also have to relocate the 1KB EBDA.
Oh yeah, I definitely confuse expanded and extended memory at least a couple times every time I bring it up. That brochure is a great find, I too am surprised that it could run on an 8088 without an Intel Above card or something. I’m probably going to spend some time messing around with DESQview myself in the future because I want to understand the later features better, so maybe I’ll figure something out… I can see moving around in the 640kb but that would be really risky. It’s possible they relied only on disk swapping in that case. I previously wrote about Visi On for which disk swapping was arguably a major weakness, but this was a few years later and it was probably an easier sell.
This article describes how DesqView works with XMS, but that implies a 286+ with 1Mb+ of memory. How did it perform task switching on an 8088 with 640Kb? I thought the MS-DOS task switcher was capable of swapping to disk, but that’s only feasible because it’s a full screen task switcher so having a noticeable delay while switching tasks is expected - a windowing environment presumably needs to be able to switch tasks in less than a second.
Good question… memory management options on DOS machines is a topic that deserves a full post (I’ve put it on my list), but I probably elided a little too much from this message. A quick rundown on the topic: the 8086 thru 80186 only had a 20-bit address bus and so could map 1MB, a good chunk of which was “reserved-ish” for hardware purposes, leaving 640k. The 286 had a bigger address bus and could support 16MB, the 386 even more so, but this matters less than you would think in practice because virtually all DOS software at this point ran in real mode without the ability to use any of that extra memory. The solution was (skipping some complexity here) a device driver that used the MMU to remap sections of the past-1MB memory down into the real mode address range for programs to use. And that’s what we usually call XMS, although there were other conventions as well.
That makes sense, but what about, say, the 8088? Well, it turns out the solution is basically the same: remap “extended” memory into the 640k standard range. But since the 8088 has only 20 address wires and no MMU, it can’t be done onboard. Instead, it was done off-die by an expansion card that basically intercepted the memory bus to remap different sections of expanded memory into a 64kb “window” in the real mode memory space. Running software had to hit specific interrupts to prompt the expanded memory card to change the mapping. Such controllers on ISA cards were pretty readily available in 4MB and 8MB sizes, and while I don’t know this for sure, I’m making a pretty confident assumption that DESQview on 8088 required one.
The standards for these get confusing due to competition and fast change… EMS (extended memory specification) is typically associated with these 8088 systems, but I think there were at least a few other less common standards, and IBM had XMA which you could say is the ancestor to XMS. In late pre-286 machines there was sometimes an on-motherboard EMS controller that almost felt like an MMU. But in short, an “expanded memory manager” defined broadly was software on the 80386 but hardware on the 8088. Further complicating things a lot of 80386 memory managers could emulate the old-style hardware memory page switching so that you could use software written against EMS. These didn’t play nicely with each other so you might have to manually choose to allocate certain memory ranges to either extended memory or expanded memory, and trying to keep “extended” vs “expanded” straight kind of typifies how annoying this must have been for users. I got a desktop technician certification on the very trail end of any of this being relevant and remember serious headaches over all this.
DESQview was also limited on non-80386, although I’m not sure of the exact issues. I know for example that later versions of DESQview were capable of windowing direct-drawing programs (e.g. vga raster programs) on the 386 by use of the MMU to remap the framebuffer, but could only run such programs full-screen on earlier processors.
For the top of the third paragraph, you mean expanded, right? (EMS == Expanded, XMS == Extended?)
XMS worked by throwing the CPU into protected mode so it could address more memory temporarily, then thunking back to real mode. That’s what HIMEM.SYS was for. No remapping is needed here. But as you suggest, this isn’t possible on an 8088, since it didn’t have physical addressing.
Remapping memory down into real mode was possible on the 386, which had something resembling an MMU. That’s what EMM386 was for, which could use the CPU to implement EMS. As far as I know the 286 didn’t have enough support for remapping, but still had protected mode so could still use pure XMS.
Hardware EMS existed but never seemed widespread. It was a way to upgrade an 8088 system without replacing it. But by the time 1Mb+ of memory started to be desirable, there was no reason to get an 8088, so at least in my neighborhood, these were rare. I had an 8088 laptop with 128Kb of EMS, but was never able to use it due to lack of a driver (sigh.)
The way I read their literature, DESQview supported a pure 640Kb 8088 environment, no EMS. Quarterdeck were the masters of PC memory management in their day, and they may have had a lot of tricks I don’t know about. Obviously it’s possible to physically copy memory around within 640Kb, but because that memory is effectively a stack, the only way I can imagine this working is to firstly reserve a swap area upfront then allow applications to run in the remainder, and applications can then be copied from the remainder to the swap area. But that means the size of this region has to be statically provisioned before any application can run, which seems gross. Putting the swap area at the other end of RAM is dangerous since DOS can’t describe it as allocated and an app would just grow into it. Since it’s already a TSR, perhaps they intercepted calls to query memory size and just lie, and hope that programs won’t inadvertently use unprotected but theoretically unavailable addresses?
This doesn’t sound right. DOS must know both where the beginning and and of allocatable memory lies, otherwise, it might try to overallocate on a computer that has only 512KB instead of 640. I recall that if you had a VGA card, there was a way to convince DOS to use video RAM beyond 640KB all the way to b800h where text mode memory starts, for an extra 96KB of conventional memory.
Right, I agree - that’s what I was trying to say in the last sentence. It has to know the end of memory, but has no way to describe randomly allocated regions within the conventional area because it was single tasking so memory was allocated as a stack. I don’t know what this call looks like and what semantics it has though. Since application memory access isn’t really controlled by DOS, all this can be is a guideline though - a program can just access an address and see what happens, and if they do, they’d trash anything that’s there.
Edit: Another possibility - did DOS start allocating high addresses and work downwards? This would seem logical and would make using those addresses above 640Kb relatively straightforward by just loading DOS at the desired address and applications don’t change. But if that happened, it really would be impossible to allocate memory at the “other end”, since the end of memory is a well known value (zero.)
I didn’t know this was possible with VGA. I remember doing it with CGA under OS/2, even to the point of running real mode Windows with 700Kb of conventional memory, although CGA is … CGA.
Edit: Wikipedia suggest that this was possible on MDA/Hercules/CGA, but not with EGA; didn’t VGA include EGA compatibility?
Memory for Hercules graphics is at B000h, so you can safely map memory into A000h-AFFFh.
Color text mode memory is at B800h, so you can map memory below that as long as you stay out of graphics mode. That’s true for CGA, EGA, and VGA.
What I remember doing (and I could be mistaken on this; it was a long time ago and I was in high school) is using VGA video memory at A000h while in text mode. But maybe I remember wrong and just mapped memory there with EMM386.
To get DOS to use that memory as conventional memory you also have to relocate the 1KB EBDA.
Oh yeah, I definitely confuse expanded and extended memory at least a couple times every time I bring it up. That brochure is a great find, I too am surprised that it could run on an 8088 without an Intel Above card or something. I’m probably going to spend some time messing around with DESQview myself in the future because I want to understand the later features better, so maybe I’ll figure something out… I can see moving around in the 640kb but that would be really risky. It’s possible they relied only on disk swapping in that case. I previously wrote about Visi On for which disk swapping was arguably a major weakness, but this was a few years later and it was probably an easier sell.