Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!xanth!mcnc!ramona!bdrc!rti!bcw
From: bcw@rti.rti.org (Bruce Wright)
Newsgroups: comp.windows.ms.programmer
Subject: Re: Windows as an Embedded I/O control platform?
Summary: Windows as multitasking operating system
Keywords: Multitasking
Message-ID: <1991Mar13.024252.28886@rti.rti.org>
Date: 13 Mar 91 02:42:52 GMT
References: <1991Mar12.221248.2431@inel.gov>
Distribution: na
Organization: Research Triangle Institute, RTP, NC
Lines: 99

In article <1991Mar12.221248.2431@inel.gov>, gak@INEL.GOV (Bonzai) writes:
> 
> I have a question about Window's ability to truly multitask.
> 
> Windows is touted as a Multitasking OS for DOS computers.  What I
> want to know is if anyone has had a good experience with this.  I
> understand that Windows uses a non-preemptive scheme of giving 
> tasks time to accomplish their jobs.
> 
> What I need to do is Real Time(tm) I/O.  Unfortunately the
> customer has a big woody for Windows.  (Another victim of a 
> ruthless marketing scheme.)

Windows doesn't do too bad at user-level multitasking, by which
I mean allowing the user do several things "at once" on the machine.
It's significantly better at it than the old-fashioned Sidekick-type
TSR hack that was sometimes (wrongly) called multitasking by some of
the marketing types.  It doesn't even do too bad at some types of
low-performance real time multitasking (such as uploading/downloading
files in the background).  I'd be very suspicious of it for high
performance real-time multitasking, though.

It really depends on the level of performance you require, how much
overhead the interactive component of the system will take (since
Windows doesn't have the concept of priority based multitasking 
schemes, any time that the interactive program is running the real-
time component won't be getting any CPU unless it's on the interrupt
stack), and that sort of thing.  Some things to consider:

    1.	If you are going to be doing I/O to hardware such as analog
	or digital I/O cards, Windows won't be providing any help
	for you directly like it will on serial comm lines or network
	cards.  If your application requires very tight timing on 
	these cards, you will have to allow for this to be done at
	interrupt level by the driver (either one that comes with the
	card or one you write).  You _may_ find problems with Windows
	having too high an interrupt latency for your purposes - it
	wasn't written with this sort of thing in mind and may keep
	interrupts disabled too long sometimes.

    2.	Windows does buffer characters from a serial I/O line, so
	you don't have to worry about getting there as soon as the
	character arrives in the UART.  You can increase the buffer
	size, which may be necessary at high baud rates, and you can
	also get some special serial cards that have a bigger silo
	than the typical PC serial port.  Whether this will be good
	enough for your purposes is hard to say without knowing more
	about the performance specs you are trying to hit.  Windows
	terminal emulation programs are notorious for not being able to
	keep up with constant high-speed output (9600 baud or higher)
	without running on very high-performance systems.  But most
	of this is because of the time needed to draw the characters
	on the screen and to do scrolling, which presumably you won't
	be doing.

    3.	Since Windows likes memory, and memory shortages can lead to
	swapping, you probably want to put as much memory on the
	system as you can to avoid it as much as possible.  You may
	have to disable any disk cache - if you have problems with
	interrupt latency and if you still hit the disk at times.

    4.	The network cards will have some similar considerations to
	those mentioned with the serial I/O cards.  

That's off the top of my head.  Different people mean different things
by real-time, depending on how demanding their application is;  it can
mean "well, we have to react to - or at least know about - what's 
happening within a few seconds or so" or it can mean "we have to analyze
the inputs and generate a response to certain conditions in well under
a millisecond in the worst case".  Windows may be able to do the first -
and even do it well, especially on a fast machine;  but I don't think 
there's any hope of using it to do the second.

If they like Windows, you might also consider OS/2 and XWindows, but 
neither of these is compatible with Microsoft Windows as far as their 
programming environment goes - I don't know how important that is.
But both OS/2 and most implementations of X are written on top of a
real multitasking kernel, and probably won't have as many problems as
Microsoft Windows would have if you require really high-performance
real-time I/O.  Both OS/2 and X look _very_ similar to Microsoft
Windows at the user level, which may be all that's required.  But if
they're hoping to run Microsoft Windows apps at the same time on the
same platform, you're out of luck.  There are similar apps to many of
the Microsoft Windows apps, but they're different and there aren't as
many choices.  Also, if the project is supposed to be a fairly short
one and nobody connected with it knows OS/2 or X, and if there's any
significant amount of programming, you'll have problems because even
though OS/2 and X are both "conceptually similar" to Microsoft Windows
at the programming level, they are sufficiently different to require
a significant learning curve.  Not as bad as if you don't know any
windowing system at all though.  OS/2 is more like Microsoft Windows 
than X is and may be a reasonable compromise.

It wouldn't be my system of choice for real-time work either, but if
it's not a high performance application you may be safe.

Good luck -

						Bruce C. Wright