Well, it was all about exploiting the memory management features of the 80386. DesqView was an interface to new hardware architecture that supported multi-tasking the old model, DOS with all it’s memory hacks, exceptionally well. It was a natural for running the hell out of current model, but it was doomed to fail to more sophisticated OS products that would exploit the same power.
DesqView/X was the same product bundled with some very good X server/client components. Think of it as an X client as well as a local system manager running any x86 component.
The shit was really ahead of it’s time.
Edit: Oh, you asked about resource requirements. Yes, and yes. Fortunately, DOS binaries aren’t large, but it’s all relative.
Around that time DOS programs were still being written to fit within 640KB of memory. However PC's were starting to be shipped with 2, 4 or even 8MB of RAM - memory really was a solution in search of a problem at that point. Windows 3.1 was the primary application for all that memory. But what if you didn't want, or need, to run Windows 3.1? Well that's where DESQview fit in. You could task switch between DOS programs instead using all that sweet memory (but not really, because DOS doesn't multitask, so 4 switchable ttys of DOS programs is a better description)
Several important DOS applications (spreadsheets, databases, CAD etc... even Doom required 4 Meg) were absolutely able to use more than 640k which was why you saw PCs with more memory: there were applications people cared about that needed it then. Granted, it was a painful business that had all sorts of limitations but the use cases were there. Anyone paying attention could look around and see that this problem had already been solved in better ways on other platforms and the various DOS multitaskers were just stop-gaps until a more universal solution (both OS and application) came along.
True, and I think Quarterdeck (and Pharlap, Rational, etc.) developed the VCPI specification that allowed those DOS extenders to work cooperatively. Some of the early DOS extenders took over the entire machine and did not allow that.
Far too much? IIRC the first version "technically" could run on a 286/2mb but they went to 386 only almost immediately. IIRC 4mb was pretty common by then among anyone who could be using it.
I remember telling the boss that Windows 95 really required 8MB of RAM, it was unusable at 4MB. Though MS supported it, it swapped like crazy. Most of our PCs didn't have 8 and would need to be upgraded.
Around that time I found a PC running NT in a lab with 20MB in it (cobbled together from two PCs) and thought it was astounding.
It required a 386sx or better with 4MB of RAM, and EGA or better graphics card.
This is quite reasonable for 1992, and the extra ram was likely needed only for the graphics. DESQView itself could run on an 8088 system and didn't even require EMS (although if you did have an EMS board, and configured the system so that the EMS board backfilled the latter 512K, it could multitask much larger programs at the same time as that enabled it to swap entire programs in/out of lower address space instantly).
I've been a low-level 8088 coding hobbyist for many years, and DESQView is still incredibly impressive to me, especially since I know what it has to do under the hood to work and be stable.
DesqView/X was the same product bundled with some very good X server/client components. Think of it as an X client as well as a local system manager running any x86 component.
The shit was really ahead of it’s time.
Edit: Oh, you asked about resource requirements. Yes, and yes. Fortunately, DOS binaries aren’t large, but it’s all relative.