I happened to notice an interesting reaction to the use of LPT1 and the Norman
IUD update by accident today. While printing a many page document on LPT1 to a
parallel port connected Epson LQ870, I accidentally hit the Norman Internet
Update Icon. Curiously, it just sat at the top of the screen, over and over
again alerting me that it was trying to connect to the Norman update server.
But it never did!

That started me thinking. I repeated the action. Same result a second time.
Thus this is either intentional or .. a bug. As I understand communicative
life in operating systems, yes, there has to be thread oriented, .. or process
oriented priority for certain tasks which involve communications. Yes IRQ
priority and ring level priority sure is involved, must be. If we are linked
to a data channel for TCP/IP from a satellite, for example, then either we take
at least the 'assigned' block of data when it is coming from the satellite, or
we lose a lot .. and can really barf up things. Especially with poorly written
applications, grin!

Sort of like cows coming down the chute from the cattle trailer into the pen.
The cows are running. If you yank the chute out from under them as they run,
the cows on the chute will fall down and break their legs. Bad for new calves,
but maybe still OK for steak. Who knows, grin? Specially when one is looking
through 'windows' at the data world, larger grin! Anyway ..

So .. is Norman refusing to connect for a possible update simply because the
IRQ process is running for the parallel port operations? And though I have not
tried this yet, is the same thread prioritization at work with Norman IUD
operations for serial port activity as well? Or .. maybe not .. and should be?

I've known for a very long time now that extensive very heavy comm port
activity in OS/2. concurrent with some applications and extensive hard disk I/O
at the same time OS/2 .INI file changes are required can throw errors which
lead to total lockups and disk damage. Especially where many megabyte size
files are involved in even non-comm port related activity done 'simultaneously'
as well. It is a VERY difficult debugging operation to trace all this, but
with many hours of special work and step by step process and file I/O flag
operations one can prove exactly where the failure and lockup occurs in the
OS/2 system actions even though at the time of failure there is no way to
examine the totally locked operating system. But I really don't want to go off
tracing this here .. and couldn't anyway unless I had access to the Norman
source code to insert the required disk I/O trace steps in the process.

But this is the first time I've ever seen an application which apparently
refuses to attempt TCP/IP connections or whatever like this, when heavy
parallel port I/O activity is involved.

Thoughts anyone?