> >We use polled and interrupt driven serial i/o routines that are written
> >in C and go directly to the hardware; these work fine in dos and (in a
> >dos box) in Win3.11 and Win95. Win-NT is a different beast, but if my
> >experience with real operating systems (which NT is getting to be one
> >of) is any predictor, the problems should be lessened, not made worse.
> >Our routines are compatible with various flavors of Unix once the C code
> >is translated. Dealing with the serial hardware is pretty straight
> >forward and pretty universal at that level, including the use of
> >interrupts. We haven't found any hardware our stuff doesn't work on yet.
> >
> >You should be able to get exactly the same results by just following
>
> I noticed you said "polled and interrupt driven serial i/o." This
> discussion was only on polled i/o not interrupt driven. I don't know how
> much of what you are saying applies as you haven't given details on what
> was applicable to your polled i/o routines.
>
> Never the less, I believe you are confirming what I said. Sure, Windows 3.1
> and Win95 can be straight forward enough but win95 can also cause great
> problems on slower boxes. I have customers using my equipment with win95 on
> a 25Mhz 486 and I can tell you it is not always as straight forward as you
> would hope. Polled i/o still requires a "friendly environment" to work
> properly.
>
> You have conceded NT which is one I had upper most in mind, nothing about
> OS/2 or windows for work groups though. OS/2 Warp uses a "virtual uart" and
> while you think you are directly accessing the hardware, you are not in
> fact. Therefore you are relying on OS/2 to be kind to your requirements.
> Not always the case. I have no shortage of email here to demonstrate this
> point.

If you want your comms to be reliable, the first step is to ensure that the
remote device will not send more than one byte of information in response
to each byte which is sent to it.  If the remote is half-duplex, this may
produce about a 50 percent performance hit in some cases, but in many cases
the performance hit will not be nearly that much.  Note as well that if the
remote device can use "dedicated polling" for its serial I/O, it may be
possible to use very high baud rates reliably.

The key to the reliability lies in this fast: if the protocol allows at most
one character "in the pipe", and if it won't allow another one until the
first is processed (subject to timeout in the failure case) then it doesn't
matter how long the PC takes to process a byte--every byte will get where
it's going.

Aside from making the protocol robust even in environments where an operat-
ing system such as Win95 may steal clock cycles or even swap the application
to disk, using such a machanism eliminates the need for interrupts; while it
is not hard to get interrupts working 'most' of the time, using polled I/O
eliminates interrupt conflicts between COM1 and COM3, and between COM2 and
COM4; and it prevents the crashes that can occur when trying to use the ser-
ial port "opposite" the mouse port [i.e. the one that shares the same IRQ
line].

This approach of polled I/O will work on any operating system that allows
port reads/writes; it does not care about how long such port operations take
(though the longer such operations take the slower the program will run) nor
about the possibility of the program being swapped out at interrupt time.
The ONLY problem polled I/O has is usually that systems like Windows NT do
not let programs poke around with the hardware directly.  Even there, how-
ever, I have read [not tested] that adding 0x8000 to the port address of the
serial port will 'usually' work to access the port directly.