Xref: utzoo comp.windows.ms:11892 comp.sys.ibm.pc.misc:8985 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!ugle.unit.no!nuug!ulrik!oivindt From: oivindt@bio.uio.no (Oivind Toien) Newsgroups: comp.windows.ms,comp.sys.ibm.pc.misc Subject: Re: OS/2 2.0 is here! READ THIS, you'll be impressed Message-ID: Date: 24 Apr 91 13:23:48 GMT References: <1991Apr21.135534.724@jarvis.csri.toronto.edu> <1991Apr21.194928.8267@ux1.cso.u iuc.edu> <1991Apr21.175529.2386@jarvis.csri.toronto.edu> <1991Apr23.180427.15016@gpu.utcs.utoronto.ca> Sender: news@ulrik.uio.no (USENET News System) Distribution: comp Organization: University of Oslo, Norway Lines: 67 In-Reply-To: barry@gpu.utcs.utoronto.ca's message of 23 Apr 91 18:04:27 GMT Nntp-Posting-Host: darwin.uio.no In article <1991Apr23.180427.15016@gpu.utcs.utoronto.ca> barry@gpu.utcs.utoronto.ca (Barry Lay) writes: > There was a suggestion that real time hardware management should not be done > with a multi-tasking operating system. While I perhaps understand the reasons > for this (mainly to do with interrupt performance and timeliness), I would like > to point out that there are cases where real time stuff is useful under a > multi-tasking system, and in fact is already being done. > There is a company called Inotek which markets CIMple Data, a real time data > collection program which interfaces with an ARTIC card in the PC that in turn > interfaces with a variety of data collection terminals such as the IBM 7527. > This program runs under OS/2 and will communicate with other programs such as > Excel and SAS via DDE. This last facility allows for the user to create data > handling scripts in a familiar language. By the way, I don't work for these > guys, I just saw a demo at the last SUGI. > My understanding of the way that device drivers are dealt with in OS/2 is that > you can install them at different levels depending on your requirement. If > all you want to do is take over port n and use it in a single program (even > under DOS compatiblity), you can issue a MODE command which will give you > exclusive control and do whatever you want with it. If you want to provide > many simultaneous programs with access to the device, you will have to write > a driver which lives a little closer to the kernel. One thing to remember > while evaluating OS/2: it is much better than Windows at interrupt handling > and task switching because it doesn't need to switch back to real mode every > time it needs DOS-like facilities. As for allowing OS/2 to step out of the > way when games are being played, if the game will absolutely not run in > compatibility mode one can always install dual boot and switch back to > native DOS (or boot from a floppy :-). > Barry The kind of application I am presently considering porting to windows (and which later may then run under OS2) uses *one* real-time procedure; an interrupt procedure that reads an A/D converter and stores the data in a buffer. It is the triggering of this interrupt procedure that needs to have priority in real-time. I am here talking about sampling rates of 1-200 Hz, but in a few instances up to 2000Hz for short periods of time. The rest of the program then do the data-processing, graphic display, and input of comments. This part do not need to be real time, it only needs to catch up with the actual sampling over a time period of a few seconds to prevent overrun of the data-buffer. The little I have seen of windows-programming up to now, gives me too the impression that this latter part can work better with an object-oriented graphic interface. The data then could be processed in different ways in different windows. One window could calculate and display averaged data, while another could display graphics of each sampled point. And the program would be much easyer to use. What concerns me a little is that the timer-ticks in windows in some cases stops (for instance when pressing the title-bar to move a window). So it may be risky (and to slow) to use these. If interrupt procedures works under OS2 and windows, the whole thing might be possible. If high-resolution timers which could be given priority exists in OS2, it would be even better. From the foregoing discussion it seems to mee that Unix is not the environment to do this kind of stuff (except the Next). Oivind -- Oivind Toien Div. of General Physiology, Dept. of Biology, Univ. of Oslo P.O. Box 1051, N-0316 Oslo 3, NORWAY Phone+47-2-454732 Fax+47-2-454726