JdeBP.. 
 
 > JDBP: In OS/2 a COM device can be opened and treated just like a file. 
 > JDBP:  In DOS one can do the same, but the device driver doesn't support 
 > JDBP: interrupt driven use of the UARTs, which causes problems.  OS/2, 
 > JDBP: more specifically the COM.SYS device driver, *does* use interrupts, 
 > JDBP: however.  Serial comms in OS/2 using the device-as-file approach 
 > JDBP: is entirely interrupt driven. 
 
 
I assure you I don't pose to be an expert in C++, however there may be one 
more thing to note about the difference between DOS device drivers and OS/2 
in C++ applications.  DOS device drivers for COMM port use do not have to be 
non-interrupt driven.  There are many that are, at least to my way of 
thinking, such as the Greenleaf utilities and the Crystal utilities for COMM 
port use.  These, when used with OS/2 in DOS-VDM sessions, together with C++ 
COMM session utilities one may write, don't seem to drive the CPU nuts. 
However, if DOS-VDM session COMM applications are what we call 'polling' 
applications, they can totally max out the CPU while your C++ apps are loaded 
with them and running as multi-tasking work.  That goes for keyboard pollers 
and timer pollers as well..... 
 
 
This seems to be a way to get one's box in much more serious trouble than one 
might think at compile time with C++ tools!  At least it has for me, or so it 
seems.  Either Watcom C++ V11 or even the old Microsoft Bascom PD7 package, 
when run in the compile mode *during use of a polling program*, which 
maximizes the CPU on time, seems genuinely capable of trashing an entire 
Pentium Classic box with this oblique F0 bug! 
 
 
We have observed *MANY* hard system failures that are untrappable over the 
last months during program development work with WARP MERLIN 4.0 when used 
together with DOS-VDM telecommunications apps that have maxed out the CPU, 
for test purposes, and not supported by time-slicing release utilities like 
TAME and OSTSR..  The box just simply freezes, the keyboard is locked, you 
are staring at a frozen system. 
 
 
We can't cite enough of these hard lockups to state that TAME or OSTSR will 
prevent it, but can't recall ever seeing the lockup deal show up when CPU 
monitor activity in the PULSE utility on the WARP TOOLBAR is not maxed out! 
 
 
From what we have been able to glean, *ALL* Intel Classic Pentiums ever 
produced, including those with MMX, are vulnerable to this queer bug.  From 
what we have been able to glean, the Pentium Pro is not, nor is the Pentium 
II class CPU, which our industrial CPU card vendor now says is an adapted 
Pentium Pro, once the inside workings are de-frocked... :) 
 
 
I don't pose to be anywhere near good enough to advise one on what routines 
in C++ are truly OS/2 interrupt-driven COMM routines.  I do think I suspect, 
that if you are able to max out the CPU in C++ COMM routines on a Classic 
Pentium box, you will hit this F0 bug, at some time, even with fully 
interrupt-driven routines.  This is based on personal experience. 
 
 
My CPU vendor, MIS out of California, has hit this in solid OS/2 interrupt- 
driven telecommunications sites, per their statements to me, with RockWell's 
systems already.  IBM departed the consulting session without any fix for the 
massive problem, leaving the issue with the CPU board vendor and Intel. The 
only fix was to throw away the Classic Pentium CPU industrial cards and 
substitute Pentium Pro or Pentium II boards which solved the problem, per 
their statement to me. 
 
 
A good friend who is well placed in the Texas Agricultural Experiment Station 
operation in some 1200 networks in 252 counties in Texas has told me that 
they have had no trouble with the AMD K6 equivalent of the Pentium Classic 
over the issue.  He states that re-compiling a Linux Kernal can gain relief 
from it, as well as using the K6 chip, thus they could care less about the 
issues at stake.  The problem is not language specific, C++ or otherwise.  
There are suggested Intel 'fixes' for the issue, but I can't get him to tell 
me if they are fixes or 'fixes', given the gravity of the semaphore 
register's importance to thread manipulation... as I know it. 
 
 
My point in raising the issue in the C++ echo is that communications port 
routines that are used sure have to be fully interrupt-driven to avoid the 
problem.  Anyone attempting to use other than that here may well be inviting 
disaster if they try to code otherwise. 
 
 
In that file writes seem to be involved in it, we have seen some rather 
frightening disk corruption take place during these escapes into never-never 
land here so far during test work with Watcom C++.... 
 
 
Caveat Code-or.. :) 
 
 
Mike @ 117/3001 
--- Opus-CBCS 1.73a
---------------