30 Jun
2000
30 Jun
'00
9:41 a.m.
Well, I never heared about the version you are
refering to, but
DOS was basicly starting from 2.0 able to do task switching.
All Informations necersary where contained within a series of
structures with a single root. The only missing thing was a
table of task pointers to switch between - and a service to
store and restore the screen content. There have been several
products offering this service. And with DOS 4 MS supplied the
infamous shell, capable of doing this. You could load several
applications and switch via a hot key combination. Windows is
still today (at least Win9x) based on this very same mechanism
for context switching. Also the functions for 'background'
applications/drivers where designed to support application
switching. The famous TSR mechanism was not only ment to steal
some memory for crude interrupt handlers, but also for true
serviceprovider tasks within the OS ... well, I guess most
programmers never realized the potential offered and kept
limited to a simple one programm state of mind.
All this was already available starting with DOS 2.x, just
it has never been 'official' until DOS 4.x
I'd have to differ with you a bit on this. A co-worker and I
spent 6 months writing a DOS 2.0-compatible file system for
our own application which contained its own home-rolled
multitasker; we had to write the file system because the
DOS file system calls were (and through at least 3.3) were
not serially-reentrant. Even then, the performance was so
poor (we had just moved to deploying on iAPX286 machines)
that we ditched the full-task model and created what we
today would call "threads", although we simply called them
lightweight processes back then.
The context switching you're referring to revolves around
switching some data structures, such as the file handle
table; but you have to wait until a file system call is
done before you can swap to the next task. Not useful
when (like us) you're developing real-time software.
As an aside, this was for the last firm for which I worked
as a programmer; I left in '90, and dropped in for a visit
in '95; at that time, they told me the system I'd designed
was running in a DOS box under the Alpha-release of Win95
and was beating a comparable application running on a VAX.
I felt very good that day...
-doug q
3 Jul
3 Jul
5:28 a.m.
> Well, I never heared about the version you are
refering to, but
> DOS was basicly starting from 2.0 able to do task switching.
> All Informations necersary where contained within a series of
> structures with a single root. The only missing thing was a
> table of task pointers to switch between - and a service to
> store and restore the screen content. There have been several
> products offering this service. And with DOS 4 MS supplied the
> infamous shell, capable of doing this. You could load several
> applications and switch via a hot key combination. Windows is
> still today (at least Win9x) based on this very same mechanism
> for context switching. Also the functions for 'background'
> applications/drivers where designed to support application
> switching. The famous TSR mechanism was not only ment to steal
> some memory for crude interrupt handlers, but also for true
> serviceprovider tasks within the OS ... well, I guess most
> programmers never realized the potential offered and kept
> limited to a simple one programm state of mind.
> All this was already available starting with DOS
2.x, just
> it has never been 'official' until DOS 4.x
I'd have to differ with you a bit on this. A
co-worker and I
spent 6 months writing a DOS 2.0-compatible file system for
our own application which contained its own home-rolled
multitasker; we had to write the file system because the
DOS file system calls were (and through at least 3.3) were
not serially-reentrant.
The context switching you're referring to revolves
around
switching some data structures, such as the file handle
table; but you have to wait until a file system call is
done before you can swap to the next task. Not useful
when (like us) you're developing real-time software.
Maybe I should have added some ** around core issues:
The system was designed for *application* switching.
Read: switch maual between lets say Wordstar and dBase.
Dos itself was never reentrant, a switch could only be
issued from outside of most functions - and a switch within
a (hardware) interrupt was close to impossible (one way to
make it was for example to check the IndosFlag (address
gathered by 21/34) and the critical error section flag)
If a task switch request occured while inside DOS you
had to postpone your switch until it was save. Other ways
include the Idle (int28) function of dos and simple DOS
warpers. Starting with 3.0 MS offered within the 21/5D
functions several additional hooks/Lists to allow easy
*application* task switching - and typicaly, with 4.x
almost all of these functions became 'official' counterparts -
just to be dropped again in 5.0...
As soon as you view DOS as a single critical section
your task switchhing should work fine - or you have to
dig into all hooks to allow a lower granuality of non
switching sections, and DOS offers quite a lot to do
so. The famous LoL (List of Lists) has always been
a good start - but even without this 'internal' info
multitasking can be done.
I did a lot of DOS hacking during the 80s ... starting with
DOS 2.11 - and I had to maintain 2.11 compatibility for a
long time since most installations around did use only 2.11.
(One of the first things I did was a (almost) 100% DOS
managed file buffer hack to use free mem as cache - some of
our machines where still in 1988 dual FD/no HD installations -
bu just adding a small buffer allocator/dealocator to the
File Buffer management).
Around 1990 I also did a pure real mode multitasking OS
for a very special setup - to replace a planned 150,000 USD
Unixsystem by a 8MHz 80286 :)
As an aside, this was for the last firm for which I
worked
as a programmer; I left in '90, and dropped in for a visit
in '95; at that time, they told me the system I'd designed
was running in a DOS box under the Alpha-release of Win95
and was beating a comparable application running on a VAX.
I felt very good that day...
:))
Gruss
H.
--
VCF Europa 2.0 am 28./29. April 2001 in Muenchen
http://www.vintage.org/vcfe
http://www.homecomputer.de/vcfe
6:53 a.m.
New subject: DEC VRT16 / 1660 monitor
Hi,
I decided to do some things with my poor neglected
DEC stuff this weekend and came up with quite a few
working (and cleaner) setups.
One thing I can't figure out without help is where a
Digital VRT16-A RGB monitor (?Sony GDDM? 1660)
is supposed to Go. Anyone have the facts on this
one? What is its resolution, and which systems is
it supposed to match?
John A.
8:02 a.m.
New subject: microVAX-II GPX. which monitor
Hi,
This weekend I was playing with a microVAX-II GPX
and had good luck using a spare console to do
Some things on it, most esp. booting it up fine.
However, It seems to be running VMUnix, and I
probably should get a monitor on to it to see what's
going on (headless right now). The console seems to
only control the low-level HW, not the O/S.
An old Apple mono NTSC monitor sorta-almost could
display the video, but it was a pretty sad affair.
Again, anyone out there know what monitor freq & scan
this guy wants to talk to? Mono BNC on the cable.
John A.
5 Jul
5 Jul
8:39 a.m.
New subject: microVAX-II GPX. which monitor
John:
I have a vaxstation 2000 hooked to a VRM17-AA monitor
which seems to be happy with the signal. The monitor
mode switch is set to "low scan", which, according to
http://www.monitorexpress.com/encyclopedia/digital.html
is 1024x768 @ 72Hz. I would not be surprised if this
worked on the microvax too.
Carlos.
John Allain wrote:
Hi,
This weekend I was playing with a microVAX-II GPX
and had good luck using a spare console to do
Some things on it, most esp. booting it up fine.
However, It seems to be running VMUnix, and I
probably should get a monitor on to it to see what's
going on (headless right now). The console seems to
only control the low-level HW, not the O/S.
An old Apple mono NTSC monitor sorta-almost could
display the video, but it was a pretty sad affair.
Again, anyone out there know what monitor freq & scan
this guy wants to talk to? Mono BNC on the cable.
John A.
--
Carlos Murillo-Sanchez email: cem14(a)cornell.edu
428 Phillips Hall, Electrical Engineering Department
Cornell University, Ithaca, NY 14853
7 Jul
7 Jul
2:21 p.m.
New subject: microVAX-II GPX. which monitor
This weekend I was playing with a microVAX-II GPX
Is there such a thing? I've only seen the VAXstation II/GPX.
Again, anyone out there know what monitor freq &
scan
this guy wants to talk to? Mono BNC on the cable.
Dunno the rate, but it works fine on my old Sony GDM-2036 multiscan.
I think the supported DEC monitor was the VR290; perhaps you can find
scan rate specs for that online somewhere.
3 Jul
3 Jul
8:04 a.m.
New subject: DEC VRT16 / 1660 monitor
Hi John;
I have a VRT16-DA on my Vaxstation 4000/60 with the 8-plane
hi-res framebuffer. It does 1280x1024 @ 66Hz; the VRT16-HA/H4
can do 66 or 72 Hz. In the manual of a Decstation 5000/33
that I have there is a list of turbochannel framebuffers that
work with the VRT16:
VRT16-DA/D4: PMAG-JA, PMAGB-BA, PMAG-CA, PMAG-DA, PMAG-EA,
PMAG-FA
VRT16-HA/H4: PMAG-JA, PMAGB-JA, PMAGB-BA, PMAGB-BC, PMAGB-BE,
PMAG-CA, PMAG-DA, PMAGB-DA, PMAG-EA, PMAGB-EA,
PMAG-FA, PMAGB-FA.
John Allain wrote:
Digital VRT16-A RGB monitor (?Sony GDDM? 1660)
Anyone have the facts on this
one? What is its resolution, and which systems is
it supposed to match?
John A.
--
Carlos Murillo-Sanchez email: cem14(a)cornell.edu
428 Phillips Hall, Electrical Engineering Department
Cornell University, Ithaca, NY 14853
8762
days inactive
8769
days old
6 comments
5 participants
participants (5)
-
cem14＠cornell.edu -
dhquebbeman＠theestopinalgroup.com -
eric＠brouhaha.com -
Hans.Franke＠mch20.sbs.de -
John.Allain＠donnelley.infousa.com