Is MS-DOS, PC DOS and DR-DOS vintage enough to count?

[jim stephens]

On 7/31/2016 10:18 AM, Liam Proven wrote:
> DesqView: yes to multitasking, no to graphics.
>
> The only snag is that it is itself DOS based, so you don't get a lot
> of free RAM in your sessions. But it works, and it's much lighter and
> faster than even v3 of  Windows.
>
> If you want an actual graphical GUI, DV/X can do that.
I used Windows 95 for dos multitasking.  Windows 95 booted the 
processors into real mode dos, then ran the windows system out of that 
base dos much like Windows 3.1 had.  As such, the dos boxes all shared 
actual access to the real mode assets of the processor.

Windows 98 switched to protected mode almost immediately on boot, and 
all the dos boxes were synthesized in virtual 8086 mapped mode, and had 
no underlying booted dos environment.

I never used any of the dos extender products because none were open 
source and what I considered to be long term sustainable, though most 
have survived.  Just waited around till the windows protected mode tools 
did what I wanted, then later linux.

I'm not a fan of the mess that has been made of windows programming from 
the outset, just used basic c environment and some windows things such 
as dialog boxes.

As an example of what we were able to pull off, we had a product which 
was memory mapped, a SCSI development board.  In the original way it was 
deployed, we had a pc for one unit, and supporting software written in 
doc C running in a dos box.  It also could be run on dos w/o windows on 
dos 6 if you configured the system correctly.  One of these PC's would 
run the board set configured to be an initiator, and another system with 
a board set would run as device.

We used a commercial debugger which connected via a com port to debug 
the thing, so a second PC ran that with a serial line between the two.


With Windows 95 coming out with it booting more or less like Windows 3.1 
/ dos, it occurred to me that if we had some way of faking a com port, 
we could run a second dos box with the debugger on a box.

So I stole a 16 byte chunk of our mapped memory (which was in the are 
where the disk controllers mapped their shared memory), and wrote a com 
port driver which used that space as a mailbox to emulate a com port on 
each dos machine.  So one could now run the debugger on the same machine 
as the hosted adapter.

By reconfiguring the shared memory (which was 1k) window, one could run 
a second adapter set on a single machine as well.  By loading up a 
second shared com port, we could then run our setup with both adapters 
on one machine, with the scsi bus looped between both, and debug both 
software sets at once, with one machine.

Also for trade shows and demos the traveling setup went to one Toshiba 
3100sx and an external backplane box with two of our adapters.

Windows 98 would run one board, but not two because only one dos box got 
the "real" space, and that was the first one opened.  The subsequent 
ones couldn't map the I/O memory real space and our shared memory would 
not be visible, only synthesized space pointing at adapters with 
drivers, etc.

Since we never had or used device drivers, but directly addressed the 
space with our support programs, our adapters couldn't share access on 
one machine, sad to say, so we were limited to a single instance with 
windows 98.

I don't think NT supported us at all, but the product petered out around 
when NT came out, and we never wrote a driver for that environment either.

thanks
Jim