Multitasking in DOS
Mike McNair
on an HP workstation running under UNIX. We now have a need to
port this software to a DOS machine. We are considering two
approaches in this port: either run under a PC/UNIX environment or
port the software to run directly under DOS. The software is
written in C - we do not have a strong preference for C compilers
on the PC, just something that will satisfy our requirements.
The following questions need help from the experts here:
1. Does DOS (of some version) support multitasking?
2. Does some 80x86 processor (maybe 386 or 486) support
multitasking?
3. Is there a C compiler that will support multitasking?
4. assuming the answers above lead to the possibility of
multitasking, does anyone have 'lessons learned' they
can share?
Excuse my novice approach - I'm new to programming under DOS
(even though I have been a user for years).
Mike McNair
m...@srs.loral.com
"These opinions are mine and not of Loral Corp'
--
----------------------------------------------------------------
Mike McNair m...@srs.loral.com
"These are my opinions and not those of Loral Corp"
ari kuchinsky
> A colleague of mine has written a multitasking, real-time system
> on an HP workstation running under UNIX. We now have a need to
> port this software to a DOS machine. We are considering two
> approaches in this port: either run under a PC/UNIX environment or
> port the software to run directly under DOS. The software is
> written in C - we do not have a strong preference for C compilers
> on the PC, just something that will satisfy our requirements.
>
> The following questions need help from the experts here:
>
> 1. Does DOS (of some version) support multitasking?
> 2. Does some 80x86 processor (maybe 386 or 486) support
> multitasking?
> 3. Is there a C compiler that will support multitasking?
> 4. assuming the answers above lead to the possibility of
> multitasking, does anyone have 'lessons learned' they
> can share?
>
> Excuse my novice approach - I'm new to programming under DOS
> (even though I have been a user for years).
>
Well, DOS doesn't support much of anything, or any current versions of it.
DOS is a bare bones system with just the major things a OS needs, infact,
DOS runs in Real Mode, has a 640k limit. So you are going to need a 32-bit
compiler plus a DOS Extender. And after you do that, Your program is still
not going to multitask well. The way I see it, IF Microsoft can't get
Windows to multitask good, I dought anybody else can.. Or atleast any small
guy.
(Not a big company).
You might want to work on DOS/90 with me any some others, a New character
based enviornment that will use DOS to run on top of and take control of the
system. Email me at Egob...@cybernet.cse.fau.edu or Ma...@agora.rain.com
Steve Goodrich
Perhaps I'm biased, but DESQview (R) from Quarterdeck has been multitasking
under MS- and PC-DOS for years. It's character-based and _F_A_S_T_! (our
DESQview/X product has built-in X-Window support). If you're interested,
e-mail to in...@qdeck.com to get more information.
--
| o | -- Steve G. (good...@qdeck.com) | o |
| o | Employed at (but not speaking for) Quarterdeck Office Systems | o |
| o | | o |
| o | In case of rapture, this terminal will be unmanned | o |
ari kuchinsky
> >Well, DOS doesn't support much of anything, or any current versions of it.
> >DOS is a bare bones system with just the major things a OS needs, infact,
> >DOS runs in Real Mode, has a 640k limit. So you are going to need a 32-bit
> >compiler plus a DOS Extender. And after you do that, Your program is still
> >not going to multitask well. The way I see it, IF Microsoft can't get
> >Windows to multitask good, I dought anybody else can.. Or atleast any small
> >guy.
> >(Not a big company).
> >
> >You might want to work on DOS/90 with me any some others, a New character
> >based enviornment that will use DOS to run on top of and take control of the
> >system. Email me at Egob...@cybernet.cse.fau.edu or Ma...@agora.rain.com
> >
>
> Perhaps I'm biased, but DESQview (R) from Quarterdeck has been multitasking
> under MS- and PC-DOS for years. It's character-based and _F_A_S_T_! (our
> DESQview/X product has built-in X-Window support). If you're interested,
> e-mail to in...@qdeck.com to get more information.
>
Well DOS/90 will be more than just a multitasker, it will contain many
things that would make DOS more of a OS. DesqView is just a multitasker.
DOS/90 should be much bigger, if you know what I mean.
Neil McCracken
I haven't personally used it, but it's worth a look.
COHERENT is a UNIX clone for the PC and it comes with a C compiler (I think).
List price is about $100 US - take a look at the Newsgroup on it.
--
----------------------------------------------------
Neil McCracken mccr...@chem.canterbury.ac.nz
Electronics Workshop, Chem Dept, Univ of Canterbury
Christchurch New Zealand
Andy
UNIX on it I guess... try Linux or bsd386(?), well then you have to
skip the dos idea. Just a hint that there exists FREE un*x for PC`s
and its a possibility if it is a really good system, worth the
multitasking and such stuff:)
--
--------------------------------------------------------------------------
Bill Gates should limit his salary to the | PI9...@pt.hk-r.se is:
number of bytes addressable by the latest | Andy Eskilsson
version of MS-DOS, and be taxed based on | Tranbaersv. 25:12
the number of bytes of RAM needed by the | s-372 38 Ronneby
latest version of MS-Windows | SWEDEN
--------------------------------------------------------------------------
"Hey, it's Unix! I know this!"
Lex, Jurassic park.
Apples has been a problem ever since eden.
Don't walk in front of me, I might be unable to follow you.
Don't walk after me, I might be unable to lead you.
Just walk by my side and be my friend.
Michael Hermann
|> >DOS is a bare bones system with just the major things a OS needs, infact,
|> >DOS runs in Real Mode, has a 640k limit. So you are going to need a 32-bit
|> >compiler plus a DOS Extender. And after you do that, Your program is still
|> >not going to multitask well. The way I see it, IF Microsoft can't get
|> >Windows to multitask good, I dought anybody else can.. Or atleast any small
|> >guy.
|> >(Not a big company).
|> >
|> >You might want to work on DOS/90 with me any some others, a New character
|> >based enviornment that will use DOS to run on top of and take control of the
|> >system. Email me at Egob...@cybernet.cse.fau.edu or Ma...@agora.rain.com
|> >
|>
|> Perhaps I'm biased, but DESQview (R) from Quarterdeck has been multitasking
|> under MS- and PC-DOS for years. It's character-based and _F_A_S_T_! (our
|> DESQview/X product has built-in X-Window support). If you're interested,
|> e-mail to in...@qdeck.com to get more information.
|>
Desqview is a task swapper, not a multitasker.. I guess this makes a big
difference for someone with a UNIX background..
-Mike
John English
: A colleague of mine has written a multitasking, real-time system
: on an HP workstation running under UNIX. We now have a need to
: port this software to a DOS machine. We are considering two
: approaches in this port: either run under a PC/UNIX environment or
: port the software to run directly under DOS. The software is
: written in C - we do not have a strong preference for C compilers
: on the PC, just something that will satisfy our requirements.
If you don't mind going to C++, have a look at mtl110je.zip on a good
Simtel mirror near you (in the msdos/cplusplus directory). It's a
class library which lets you define concurrent threads as classes
derived from class DOSthread. Then declare instances of these classes,
call run() for each instance, and hey presto -- multiple threads
timeslicing away like anything.
--
-------------------------------------------------------------------------------
John English | "There are basically two types of dicks,
Dept. of Computing | hard dicks and floppy dicks."
University of Brighton | -- from a student essay on storage media
E-mail: j...@unix.brighton.ac.uk | "Disks are divided into sex & tractors."
Fax: 0273 642405 | -- from one of my lectures (on a bad day)
-------------------------------------------------------------------------------
Steve Goodrich
Mike --
It depends on how you define multitasking. If you define multitasking as
being able to have one task/program running in the foreground, accepting
input from the keyboard, and displaying output to the monitor while having
other programs running (like serial-port communications, spreadsheet recalcs,
and other DOS-based programs running) at the same time without interruption,
then: YES, DESQview _DOES_ multitask. DESQview (and DESQview/X) allow you
to run off-the-shelf DOS programs (they don't have to be specially
constructed to allow the to run under DV or DV/X, but they _can_ be to take
advantage of special features).
A lot of BBS's run DV as their operating environment to allow multiple
instances of the BBS software to give more-than-one user access to the
BBS. A simple task swapper couldn't do that, unless the sysop was willing
to sit there and force task swapping as fast as he could.
If I understand correctly: A task under UN*X will work for a bit (a few
milliseconds) and then get put aside so another task can get some CPU time.
Under DV and DV/X, a task will work for a bit (a few milliseconds) and then
get put aside so another task can get some CPU time. Sounds like the same
thing to me. The only difference is that we have to work on top of a
Microsoft product. Even so, we're not just task swapping... it's real
multitasking for DOS.
Andrew M Langmead
>Desqview is a task swapper, not a multitasker.. I guess this makes a big
>difference for someone with a UNIX background..
I don't know what your definitions of multitasking and task switching are.
The definitions that I've been most comfortable with are
Task Swapping: Systems like DOS Shell bundled with DOS 5&6
that will allow more than one program to be loaded, allowing one to
run and swapping the inactive ones to disk or some non process space area
of memory.
Co-Operative Multitasking: Systems like the Macintosh or Windows
in which each process has to explicitly relinquish control of the system
to allow other process to run. (Many people refer to these as task swapping
but that leaves out what to call the systems that work under the previous
model. Besides, the process becoming inactive doesn't swap to anywhere.)
Pre-emptive multitasking: Systems that will allow each program
to run for a certain amount of time, and when either its time slice is
over, or the program explicitly relinquishes control, moves to the next
program.
Using these definitions, DESQview is a Pre-emptive multitasking system.
It will allow a program a certain period of time to execute. (The exact time
is under user control, there are values for how many ticks to give the
foreground process, and how much to give all of the background processes.)
If the program does something to tell DESQview to give up time sooner, it
will. (things like DESQview calls key_read() and mal_read() if keys or
mailbox messages are not pending, a DESQview api_pause(), or even DOS or BIOS
read a key commands) If the program has not made some sort of blocking
DESQview or DOS call, and the number of ticks have passed, DESQview will
still stop that process, and start on the next non-blocking one.
One source of confusion of not thinking of DESQview as a pre-emptive
multitasking system might be that it has the api_pause() call. If one sees
it they might think that a program NEEDS to call api_pause() to allow the
other programs to execute. That is not true. api_pause() is only a hint
to the scheduler that execution time might be better spent elsewhere. If
I made a program that did the following:
int main()
{
while(1)
{
/* kill time */ ;
}
}
and ran it, in one DESQview window, the other windows would still
get execution time. (Actually just to prove a point, I cut the
program out of my telecom window, pasted it into a text file, then
compile and ran it. As you can see I'm still typing. (If I changed
the program to continuously print something out on the screen, I could
set up the programs windows so that I could see the kill time program
running while I was typing, proving that it was still running.)
api_pause() improves performance of the system, it does not the source
of the multitasking behavior.
If one wanted to be belligerent, they could start arguing that
programs if they want to can still take over the machine with
DESQview calls like api_beginc() which tells the scheduler not
to pass the control of execution to another task. (different from
process, DESQview is multi-threaded. Each process starts with one
thread of execution but can start additional ones.) Another thing
that a process could do is to call tsk_stop() on any process other
than its own. Besides some technical drawbacks to these ideas
(api_beginc() will temporarily end your critical region if you
make any blocking DESQview or DOS call. You need a task handle to
call tsk_stop(), and there is no way in the standard DESQview API
to find out others task handles.) I would really consider these
issues a lack of process security (that a process can be threatened
by the deliberate attempt by another process) rather than a
lack of pre-emptive multitasking.
--
----
Andrew Langmead / a...@world.std.com / BIX a.langmead / CIS 72411,1560
Brian Sandlin
run several dos apps simultaneously. Many BBS operators use it
to run more than one node on a single PC. Of course, the individual
dos tasks don't get to do any fancy multitasking unless they use
DesqView's API which is rich with multitasking features. I had a
little ad brochure from them a while back that listed all the
functions, and it seemed to be quite complete.
If you were porting a Unix app to a PC, it would still be a pain
to redo it in DOS when free Unix flavors are floating around on the
net (look for SLS Linux at tsx-11.mit.edu).
--
bsan...@netcom.com
-----------------------------------------------------------------------
Robert Wiegand
>A colleague of mine has written a multitasking, real-time system
>on an HP workstation running under UNIX. We now have a need to
>port this software to a DOS machine. We are considering two
>approaches in this port: either run under a PC/UNIX environment or
>port the software to run directly under DOS. The software is
>written in C - we do not have a strong preference for C compilers
>on the PC, just something that will satisfy our requirements.
>The following questions need help from the experts here:
>1. Does DOS (of some version) support multitasking?
>2. Does some 80x86 processor (maybe 386 or 486) support
> multitasking?
>3. Is there a C compiler that will support multitasking?
>4. assuming the answers above lead to the possibility of
> multitasking, does anyone have 'lessons learned' they
> can share?
DOS dos not multitask and would be a poor choice.
My suggestion would be to look into OS/2. It runs on 386/486/Pentium PCs
and supports full multitasking.
--
------------------------------------------------------------------------------
Robert Wiegand - Motorola Inc.
wie...@rtsg.mot.com
Disclamer: Sometimes I don't even represent myself.
ari kuchinsky
> |> >Well, DOS doesn't support much of anything, or any current versions of it
> |> >DOS is a bare bones system with just the major things a OS needs, infact,
> |> >DOS runs in Real Mode, has a 640k limit. So you are going to need a 32-bi
> |> >compiler plus a DOS Extender. And after you do that, Your program is stil
> |> >not going to multitask well. The way I see it, IF Microsoft can't get
> |> >Windows to multitask good, I dought anybody else can.. Or atleast any sma
> |> >guy.
> |> >(Not a big company).
> |> >
> |> >You might want to work on DOS/90 with me any some others, a New character
> |> >based enviornment that will use DOS to run on top of and take control of
> |> >system. Email me at Egob...@cybernet.cse.fau.edu or Ma...@agora.rain.com
> |> >
> |>
> |> Perhaps I'm biased, but DESQview (R) from Quarterdeck has been multitaskin
> |> under MS- and PC-DOS for years. It's character-based and _F_A_S_T_! (our
> |> DESQview/X product has built-in X-Window support). If you're interested,
> |> e-mail to in...@qdeck.com to get more information.
> |>
>
> Desqview is a task swapper, not a multitasker.. I guess this makes a big
> difference for someone with a UNIX background..
>
> -Mike
No, DesqView Multitasks with QEMM386 loaded on 386 and higher CPUS. It can
even multitask badly on 8088's and 286's i have heard with the right stuff
on the machines. But normally on 8088's and 286's, DesqView is a
Task-Swapper.
Multitask : Run two tasks or more at the same time
Task Swap : Stop app without quitting and goto other one, then flip back and
stop other app and comeback to it..
^^^^ Simplified Terms.
Brian Clancey
>> If I understand correctly: A task under UN*X will work for a bit (a few
>> milliseconds) and then get put aside so another task can get some CPU
time.
>> Under DV and DV/X, a task will work for a bit (a few milliseconds) and
then
>> get put aside so another task can get some CPU time. Sounds like the same
>> thing to me. The only difference is that we have to work on top of a
>> Microsoft product. Even so, we're not just task swapping... it's real
>> multitasking for DOS.
So therefore there is no really true multi-tasking unless one is running
concurrent CPU's ??
--
-------------------------------------------------------------------
STAT Publishing, Box 8110-361, Blaine WA 98230 USA
Brian_...@mindlink.bc.ca
-------------------------------------------------------------------
Jon Arnold
>So therefore there is no really true multi-tasking unless one is running
>concurrent CPU's ??
Not true. There is a product on the market called ICHOST by Envyr Systems
that will allow an MS/DOS PC to run as a multi-user and/or true multi-tasking
machine. We've been testing it, and one of the really nice things is that
code compiled under their runtime & development system is binary compatible
(ie, will run with no changes or re-compilation) under Unix; specifically, Sun
Solaris (as well as other operating systems that I can't recall offhand
because I wasn't really interested at the time...)
Jon
----------------------------------------------------------------------------
Jon Arnold newcomer to Melbourne, Florida
"If you ain't the lead dog, the view never changes."
Disclaimer: The views & opinions expressed here are my own, and have no
necessary relevancy to the views & opinions of my employer.
----------------------------------------------------------------------------
Charles William Hubbard
>difference for someone with a UNIX background..
No I don't think that is quite true. Although Desqview works quite well
as a task swapper it will also run mulitple programs concurrently. When
I used Desqview I often let one or more programs running in the
background (transferring file say) while working on something else.
Stephen Clover
aside from all the debate on whether or not
desqview is a taskswapper or not..
i have used a couple of libraries previously
which support co-operative nonpreemptive
mulititasking on a pc..
they are on the net - i don't know of ftp
sites but you should be able to use archie to find
them.
they are: mtask (pascal)
rmaxtask (c)
i have also recently downloaded a library in pascal
called multi020.zip, but i haven't tried it out yet.
it was announced on comp.lang.pascal recently, and is
available at garbo.uwasa.fi.
hope this is of help..
steve/
--
-------------------------------------------------------------------------
Oh.. HURRAY HURRAY. The VELVET UNDERGROUND have REUNITED. Yes, the ROCK
GODS who made FOUR ALBUMS and NO MONEY have got back together to make
NO ALBUMS and SOME MONEY... AlRIGHT!
Brian Sandlin
When you run a _plain_ DOS app under desqview, then it is just a fancy
task swapper. I have seen many posts rebutting this, and although it
is true that you can start several applications and have them run
simultaneously, it doesn't escape the fact that each _individual_ task
isn't doing any multitasking. This is a DOS limitation of course,
since there is no DOS system call to let your program start its own
threads to do background processing, etc., but DesqView has an API that
will let you call on some fairly good multitasking, inter-task
communication, and other things that DOS didn't come with.
It seems to me that the original poster had a UNIX application that
makes use of UNIX's ability to let a program fork off its own
processes, and that he was looking to port this app to DOS without
loosing this threading capability. I think he would do as well with
DesqView's API which would open up this app of his to doing some
internal multitasking. He might also be able to work with one of the
many add-in tasking libraries out there for DOS apps to use when they
need some multithreading. In fact, I am using a terminal program right
now (telemate) that will let me download a file, edit another file, and
possibly load a little pseudo-command.com that lets me use the internal
DOS commands, with out ever interrupting a download. It uses a
multitasking lib to great effect, and it is a pleasure to use because
of it.
[!blurb!]
I think DesqView is a Good Thing, and it is _very_ convenient to be
able to switch between apps at will without halting the others. I just
wish microsoft had realized this after the hardware became capable of
decently fast multi-tasking, and should have added it to dos by now without
tacking on that 12 mb of extraneous code. ;)
Hmmm....
--
bsan...@netcom.com
-----------------------------------------------------------------------
Carlo Baffa
> Stuff deleted
I Agree, DV and DVX do some form of multitasking. More, we are building
a (near) Real Time acquisition based on DVX with simultaneous
capability of data reduction and dyisplay for images. This is not easily
done under Un*x for lack of real time capability, nor windows for
lack of preemption (correct word?) and POOR performance. The majority
of problems we have are due to underling Dos ....
Carlo Baffa Osservatorio Astrofisico di Arcetri
ba...@arcetri.astro.it Largo Fermi 5
astrfi::baffa I-50125-Firenze ITALY
Rich Mulvey
> In article <29...@mindlink.bc.ca> Brian_...@mindlink.bc.ca (Brian Clancey
> ) writes:
>>So therefore there is no really true multi-tasking unless one is running
>>concurrent CPU's ??
>
> Not true. There is a product on the market called ICHOST by Envyr Systems
> that will allow an MS/DOS PC to run as a multi-user and/or true multi-tasking
>
> machine. We've been testing it, and one of the really nice things is that
> code compiled under their runtime & development system is binary compatible
> (ie, will run with no changes or re-compilation) under Unix; specifically, Su
> n
> Solaris (as well as other operating systems that I can't recall offhand
> because I wasn't really interested at the time...)
>
Jon: That's nice, but you still can't multitask two processes
simultaniously on single CPU systems that dont include multiple ALU's,
fetch mechanisms, and scratchpads. :-) Sure, you can perform process
*switching*, serially, but not in parallel.
- Rich
--
Rich Mulvey Amateur Radio: N2VDS 787 Elmwood Terrace
ri...@mulvey.com Rochester, NY 14620
Rich Mulvey
Not quite. The term 'Task swapper' refers to the ability to have multiple
processes in memory, with only one active at a given time. Multitasking
( on a single CPU system ) refers to the ability to rapidly switch back and
forth between multiple processes.
And DESQview most definately allows that. :-)
Todd Walk
> Jon: That's nice, but you still can't multitask two processes
>simultaniously on single CPU systems that dont include multiple ALU's,
>fetch mechanisms, and scratchpads. :-) Sure, you can perform process
>*switching*, serially, but not in parallel.
Note, this is not multitasking, but parallellizing, because you still
are running only one processes. Multiprocessing requires multiple CPUs.
I think that the big problem here is definitions.
These are approx. definitions given from 3 different OS books:
task swapping: multiple processes allowed, user switches between them.
multitasking: same as task swapping, but the OS switches between
processes and user focus doesn't shift during the process change.
multiprocessing: multiple processes running concurrently, requires
multiple CPUs.
Todd Walk
wa...@mrcnext.cso.uiuc.edu
Andrew M Langmead
>If you were porting a Unix app to a PC, it would still be a pain
>to redo it in DOS when free Unix flavors are floating around on the
>net (look for SLS Linux at tsx-11.mit.edu).
You are right, since DOS, even with some multitasking add on will probably
not follow Unix's fork()/exec() model of multitasking, porting it will be
difficult. The advantages would be that the system could be used for other
applications easier, and that it would probably run in less memory than
the Unix based counterpart.
Kendall Bennett
>her...@kirk.fmi.uni-passau.de (Michael Hermann) writes:
>>Desqview is a task swapper, not a multitasker.. I guess this makes a big
>>difference for someone with a UNIX background..
>I don't know what your definitions of multitasking and task switching are.
>The definitions that I've been most comfortable with are
> Task Swapping: Systems like DOS Shell bundled with DOS 5&6
>that will allow more than one program to be loaded, allowing one to
>run and swapping the inactive ones to disk or some non process space area
>of memory.
> Co-Operative Multitasking: Systems like the Macintosh or Windows
>in which each process has to explicitly relinquish control of the system
>to allow other process to run. (Many people refer to these as task swapping
>but that leaves out what to call the systems that work under the previous
>model. Besides, the process becoming inactive doesn't swap to anywhere.)
> Pre-emptive multitasking: Systems that will allow each program
>to run for a certain amount of time, and when either its time slice is
>over, or the program explicitly relinquishes control, moves to the next
>program.
From a UNIX standpoint, multi-tasking means the ability for you to have
multiple _threads_ running within a single program (athought under
UNIX these threads are heavyweight processes). You cannot do this
with DV or Windows. OS/2 2.x on the other hand has full multithreaded
capabilities (in fact, the OS/2 2.x threads are lightweight rather
than being heavyweight processes).
Under UNIX you would write something like this:
main ()
{
if (fork() == 0) {
/* We are no running in the child process */
....
}
else {
/* We are now running in the parent process */
}
}
Thus you have two threads of control running in the same code space. The
threads can communicate using shared memory, semaphores or named pipes.
DOS, DV and Windows have no concept like this.
+------------------------------------------+-------------------------------+
| Kendall Bennett | Internet: |
| RMIT Advanced Computer Graphics Centre | k...@citri.edu.au |
| CITRI Building, 723 Swanston Street | rc...@minyos.xx.rmit.oz.au |
| Carlton Victoria 3053 AUSTRALIA. | |
+------------------------------------------+-------------------------------+
Jeremy Mathers
>...
>From a UNIX standpoint, multi-tasking means the ability for you to have
>multiple _threads_ running within a single program (athought under
>UNIX these threads are heavyweight processes). You cannot do this
>with DV or Windows. OS/2 2.x on the other hand has full multithreaded
>capabilities (in fact, the OS/2 2.x threads are lightweight rather
>than being heavyweight processes).
>Thus you have two threads of control running in the same code space. The
>threads can communicate using shared memory, semaphores or named pipes.
>DOS, DV and Windows have no concept like this.
... but thank you for playing.
DV does of course have multi-threading. I don't know about the others.
************************************************************************
After an instrument has been assembled, extra components will be found
on the bench.
- py...@quads.uchicago.edu, who is still costing the net
hundreds, if not thousands, of dollars, every time he posts -
************************************************************************
rwvpf wpnrrj ibf ijrfer
David Hough
>A colleague of mine has written a multitasking, real-time system
>on an HP workstation running under UNIX. We now have a need to
>port this software to a DOS machine. We are considering two
>approaches in this port: either run under a PC/UNIX environment or
>port the software to run directly under DOS. The software is
>written in C - we do not have a strong preference for C compilers
>on the PC, just something that will satisfy our requirements.
>
>The following questions need help from the experts here:
>
>1. Does DOS (of some version) support multitasking?
>2. Does some 80x86 processor (maybe 386 or 486) support
> multitasking?
>3. Is there a C compiler that will support multitasking?
>4. assuming the answers above lead to the possibility of
> multitasking, does anyone have 'lessons learned' they
> can share?
>
have some sort of multitasking kernel in it and should be out 'real soon now'
:-)
Failing that, investigate Desqview as a possible solution because this manages
to multitask multiple DOS programs. It may not be suitable for your application
though.
While not specifically supporting multitasking, the 386/486 processors make it
a lot easier to do (you can run Unix on such a processor after all) than an
8086 or even an 80286.
Dave
--
*****************************************************************************
* G4WRW @ GB7WRW.#41.GBR.EU AX25 * Start at the beginning. Go on *
* da...@llondel.demon.co.uk Internet * until the end. Then stop. *
* g4...@g4wrw.ampr.org Amprnet * (the king to the white rabbit) *
*****************************************************************************
Andrew M Langmead
>From a UNIX standpoint, multi-tasking means the ability for you to have
>multiple _threads_ running within a single program (athought under
>UNIX these threads are heavyweight processes). You cannot do this
>with DV or Windows. OS/2 2.x on the other hand has full multithreaded
>capabilities (in fact, the OS/2 2.x threads are lightweight rather
>than being heavyweight processes).
[example of fork() call deleted]
>Thus you have two threads of control running in the same code space. The
[note:wrong, this is two threads running in identical copies of the code space]
>threads can communicate using shared memory, semaphores or named pipes.
>DOS, DV and Windows have no concept like this.
Almost. DOS and Windows has no concept like this. DESQview does allow the
programmer to create multithreaded applications. I pointed this out in my
previous post.
I wrote:
>DESQview calls like api_beginc() which tells the scheduler not
>to pass the control of execution to another task. (different from
>process, DESQview is multi-threaded. Each process starts with one
>thread of execution but can start additional ones.)
In the DESQview API there is a call named tsk_new(). When tsk_new() is called
a new thread of execution is started in the same address space. (one of
the arguments passed to tsk_new() is the address of a function in which
the thread should start executing) Each thread gets its own pre-emptive
time slice (A note to anyone reading this that actually uses DESQview:
Each thread gets the full amount of foreground or background ticks specified,
so the more time you want to give your application in total, the more threads
you should create.) The different tasks can communicate with each other
using DESQview's feature called mailboxes, which can be used as either a
semaphore, or to pass data between tasks. Tasks can also communicate
through memory since all memory is "shared" between tasks.
Quarterdeck Office Systems has some brouchures explaining their API in detail.
You might consider calling them up and asking them to send you one.
Robert Wiegand
Steve Goodrich <good...@qdeck.com> wrote:
>>Desqview is a task swapper, not a multitasker.. I guess this makes a big
>>difference for someone with a UNIX background..
[stuff deleted]
> If I understand correctly: A task under UN*X will work for a bit (a few
>milliseconds) and then get put aside so another task can get some CPU time.
>Under DV and DV/X, a task will work for a bit (a few milliseconds) and then
>get put aside so another task can get some CPU time. Sounds like the same
>thing to me. The only difference is that we have to work on top of a
>Microsoft product. Even so, we're not just task swapping... it's real
>multitasking for DOS.
The difference is that under a system like Unix a single program can have
multiple tasks running at the same time. Under Deskview each program
has only a single task. DV can unly multitask different programs, Unix
can multitask both different programs, and different tasks within a program.
Gary Rich
>In article <1993Sep10.1...@qdeck.com>,
>Steve Goodrich <good...@qdeck.com> wrote:
>
>>>Desqview is a task swapper, not a multitasker.. I guess this makes a big
>>>difference for someone with a UNIX background..
>
>[stuff deleted]
>
>> If I understand correctly: A task under UN*X will work for a bit (a few
>>milliseconds) and then get put aside so another task can get some CPU time.
>>Under DV and DV/X, a task will work for a bit (a few milliseconds) and then
>>get put aside so another task can get some CPU time. Sounds like the same
>>thing to me. The only difference is that we have to work on top of a
>>Microsoft product. Even so, we're not just task swapping... it's real
>>multitasking for DOS.
>
>The difference is that under a system like Unix a single program can have
>multiple tasks running at the same time. Under Deskview each program
>has only a single task. DV can unly multitask different programs, Unix
>can multitask both different programs, and different tasks within a program.
Um, no. Sorry. DESQview can indeed multitask different tasks within a
program as was explained in depth in another fragment of this thread. All
you need to do is make the call.
Gary Rich | Quarterdeck Office Systems, Santa Monica CA
gary...@qdeck.com
Nobody listens to my opinions, so why I should bother disclaiming them?
Duncan Murdoch
>Um, no. Sorry. DESQview can indeed multitask different tasks within a
>program as was explained in depth in another fragment of this thread. All
>you need to do is make the call.
I believe this (I've read it several times), but I can't think of a single
example of a program I've seen that actually appears to make use of this
feature (other than the DV core itself). Do any of the utility programs
that ship with DV or DVX use multiple threads? Are there any pd, shareware
or commercial examples that you know of?
Duncan Murdoch
Ralf Brown
}Well DOS/90 will be more than just a multitasker, it will contain many
}things that would make DOS more of a OS. DesqView is just a multitasker.
}DOS/90 should be much bigger, if you know what I mean.
DESQview is also more than just a mere DOS multitasker. Its API
supports inter-process communication, event-driven programming (block
until some event of interest occurs), shared memory, process
creation/destruction, window creation and management, preprocessed
keyboard input, etc. Check out the API in the interrupt list or the
DESQview-specific extract DVINT36, both available on SIMTEL20 and
mirrors.
In a sense, DESQview is too good a DOS multitasker, so there aren't all
that many programs which make more than minimal use of the DESQview API
because they can get by without.
--
Internet: ra...@telerama.pgh.pa.us -=- FIDO: Ralf Brown 1:129/26.1
Disclaimer? | Gilb's First Law of Computer Unreliability: Computers
What's that? | are unreliable, but humans are even more unreliable.
Ralf Brown
}>1. Does DOS (of some version) support multitasking?
}
Depends on just what level of multitasking you need. If you just need
to run multiple threads where all DOS calls are limited to a single one
of those threads, implementing multitasking under DOS is almost
trivial--just save/restore all the CPU registers. I wrote such a
specialized multitasker way back under DOS 1 (yes, before PRINT) so that
a TSR of mine could get 27ms time-slices as needed while a user program
ran in the foreground (the TSR did not need DOS access).
Ralf Brown
}No, DesqView Multitasks with QEMM386 loaded on 386 and higher CPUS. It can
}even multitask badly on 8088's and 286's i have heard with the right stuff
}on the machines. But normally on 8088's and 286's, DesqView is a
}Task-Swapper.
Only when running today's multi-megabyte memory hogs. I used to run
three or four programs simultaneously on an 80286 with only one meg of
RAM. I started using DESQview on a floppy-only 512K 8088, where I
normally had two programs running concurrently.
Ralf Brown
}From a UNIX standpoint, multi-tasking means the ability for you to have
}multiple _threads_ running within a single program (athought under
}UNIX these threads are heavyweight processes). You cannot do this
}with DV or Windows. OS/2 2.x on the other hand has full multithreaded
Sure you can with DV (the threads there are called tasks, and are also
heavyweight processes as in Unix). Check out the demo program in DV-GLUE
for a multi-threaded example including interprocess communication (DV
provides mailboxes, shared memory, and semaphores for IPC, or you can
busy-wait on a memory location for communicating between threads of a
single program).
John English
: In article <wiegand.747672385@midnight1>, wie...@rtsg.mot.com (Robert Wiegand) wrote:
: }>1. Does DOS (of some version) support multitasking?
: }
: }DOS dos not multitask and would be a poor choice.
:
: Depends on just what level of multitasking you need. If you just need
: to run multiple threads where all DOS calls are limited to a single one
: of those threads, implementing multitasking under DOS is almost
: trivial--just save/restore all the CPU registers. I wrote such a
: specialized multitasker way back under DOS 1 (yes, before PRINT) so that
: a TSR of mine could get 27ms time-slices as needed while a user program
: ran in the foreground (the TSR did not need DOS access).
Also, check out mtl110je.zip (from Simtel or Garbo) for a C++ library
which enables you to write multithreaded C++ programs...
--
-------------------------------------------------------------------------------
John English | "There are basically two types of dicks,
Dept. of Computing | hard dicks and floppy dicks."
University of Brighton | -- from a student essay on storage media
E-mail: j...@unix.brighton.ac.uk | "Disks are divided into sex & tractors."
Fax: 0273 642405 | -- from one of my lectures (on a bad day)
-------------------------------------------------------------------------------
Adrian Ho
multi-tasking/-threading debate, while hardly anyone seems to have
gone back to the original post. I say this because
Mike McNair (m...@scf16.scf.loral.com) wrote:
: A colleague of mine has written a multitasking, real-time system
: on an HP workstation running under UNIX. ^^^^^^^^^
What kind of "real-time" are we talking about here, Mike? Are you
processing in milliseconds or minutes? (For the uninitiated, Plauger
defines a "real-time system" as "one that must respond to its inputs
soon enough to make a difference"[*], as good a definition as any.)
[*] "A Preoccupation with Time", Programming on Purpose: Essays on
Software Design, Ch. 18. P. J. Plauger, Prentice-Hall, 1993. IMHO, a
must-read for any self-proclaimed "software engineer".
For rapid, *regular* events, I'd strongly advise going with one of the
commercial multitasking DOS kernels/libraries available on the market.
(A good place to look for such products is in "Embedded Systems
Programming", I think.) I wouldn't recommend any x86 Unix products if
millisecond response time is important to you...unless you're willing
to embed your code in the kernel. IMHO, most commercial multitasking
DOS kernels and libraries have been optimized to the point when
guaranteeing such response times is quite feasible. (You could try
the non-commercial libraries suggested by a couple of netters in
previous posts if your budget (or time-to-product) is tight. 8-)
--
- Adrian Ho
sco...@solomon.technet.sg
David Hough
windows for users as they connect, rather than leave them open all the time.
Quite good to see it in operation.... and no, I didn't write it.