🚀 go-pugleaf

In article <1992Dec20.153543.537@doc.bmd.trw.com> nickgill@doc.bmd.trw.com writes:
>Hello,
>
>I am looking for any information on DOS in a real-time enviroment.
>Please e-mail me if you know of any leads on problems that occured
>in a real-time environment or on embedded computers as a result of DOS.
>Thanks,
>Nick

I once supported a real-time monitoring system in a factory that was
on a [MS]DOS system.  The whole thing was written in Turbo Pascal, and
used a non-standard graphics display (NEC PC-8000), most of the
comments in the code were in japanese, as were some of the function
names (jikan=time).

Bascially there was a central launcher program that would fork off the
actual working tasks.  The one task would read the inputs, and put the
values in a shared memory area.  The next task would process this
fresh data.  The next task was based on the current display desired,
and would put the appropriate information on the screen.  I think this
task would also poll the touch screen (another mess in itself).

The main screen would show a summary of the factory.  The next screens
would show the 5 individual areas.  Then there was an individual item
display showing status.  There was also some end of month reports, and
end of year reports.

The biggest problem with this whole system was the polled nature.
There were no event driven interfaces (although I suppose there could
have been.  The touch screen processor (yup, a whole processor
dedicated to the screen), queued about 10 actions (touch, release 2
actions, although drag didn't work, and my japanese wasn't good enough
to figure out if it were possible).  The actual problems were reported
down a serial line, and that had a huge buffer also.

Also if there were any loops, or any of the modules launched never
came back, nothing got serviced.  The display looked like everything
was working, but something else would report that error.

Tommy