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
