gak@INEL.GOV (Bonzai) (03/13/91)
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.) I am attempting to persuade him that there are better things out there for his application. If I am wrong in thinking that Windows will not be a wonderful platform to develop under... well I guess you can tell me. ;) As I see it, something else that provides true Multitasking and transparent networking (ie QNX) would be much better suited to meet the requirements. Has anyone attempted to network two PCs under windows. (make them communicate RS232)? ie... Send messages from a process on one machine to a process on another machine? How about Ethernet under Windows? Or does Windows come in a network version with which I can accomplish interprocess communication? Should I RTFM? How many processes can I launch under a session of windows without causing my Compaq386/20e to slow to a crawl and then barf on itself? My biggest problem is being able to prioritize I/O. Right now everyone waits his turn. Sometimes waiting your turn is just not the way I want to go. Time slices seems to be a much better idea to me... and I can implement priorities. I want to hear some experiences on how Windows works as an embedded I/O controller with a maintenance interface to the world. Or is this a ridiculous use for Windows like I think it is? Greg Kelley gak@inel.gov (internet?) - I work for a perfectly safe and wonderfully compliant company. For example, check out the disclaimer that they attach to my news postings without even asking me! ========== long legal disclaimer follows, press n to skip =========== Neither the United States Government or the Idaho National Engineering Laboratory or any of their employees, makes any warranty, whatsoever, implied, or assumes any legal liability or responsibility regarding any information, disclosed, or represents that its use would not infringe privately owned rights. No specific reference constitutes or implies endorsement, recommendation, or favoring by the United States Government or the Idaho National Engineering Laboratory. The views and opinions expressed herein do not necessarily reflect those of the United States Government or the Idaho National Engineering Laboratory, and shall not be used for advertising or product endorsement purposes.
bcw@rti.rti.org (Bruce Wright) (03/13/91)
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