crazy idea.............. ?
-
Hello, I have an idea from my work that use computer for process something in realtime. But Windows9x or WindowsNT does not support all access to hardware and OS kernel get all time for its works. Could I use MS-DOS for real time problem? Or write new own OS simply like MS-DOS. But writing new OS kernel is very difficult. If it is rather than, where does it start? how does it start? Please help me. Thank you very much! :confused: Nguyen Le Nam
-
Hello, I have an idea from my work that use computer for process something in realtime. But Windows9x or WindowsNT does not support all access to hardware and OS kernel get all time for its works. Could I use MS-DOS for real time problem? Or write new own OS simply like MS-DOS. But writing new OS kernel is very difficult. If it is rather than, where does it start? how does it start? Please help me. Thank you very much! :confused: Nguyen Le Nam
Realtime processing within MSDOS was always a tricky thing, less so in Windows. The solution depends on what size of time you need to be within. For example a realtime process that only has to react per minute would be fine in any OS, since the time slice is much less than a minute. In DOS you are not in timeslices. Your program is called, and that is the only program running until your program ends. Except of cause drivers (TSRs - transient-stay-resident) running on interrupts. So, in this case you would want a driver that triggers a call in your program. A typical one would be on receiving data at a serial port. You would write software to buffer incoming data and trigger a software interrupt which calls a callback function in your main code. This is realtime with loss of driver-time, your programs reaction time and your own process-time (about as real as it gets in DOS). Direct access to the IRQ (interrupt controller) is no longer available in Windows, though it is not so much needed. In Windows (after Win3.x that is since 3.x was still a DOS machine), 98/NT/2000, you actually have it better since the port stream is for the most part handled for you. You only need to capture it then set a callback. As you are in timeslices your main program can carry on working on its data, then on a call from incoming data you collect and process. How real the time is depends on how much processing you need to do on the data and the speed of your machine. If the processing is longer than the time between receiving new data then obviously you are not in realtime and have to account for this in the processing itself. Carefull use of threading can increase your programs response time. But the speed of modern machines are generally fast enough to give you 'effective' realtime. On a worst case instance with Win95, I had to effectively crash Windows. I let my code take all time from the machine in order to keep up with the incoming data. The same project on a proper timeslice OS runs without problem (other than the standard bugs we all write). We do it for the joy of seeing the users struggle.