Use _wait_b.obj on fast pentium machines to slow it down.
The enclosed object file __WAIT_B.OBJ is used to fix a problem with
Clipper applications terminating at start up with either an "R6003
divide by zero" message or no error message at all. This problem has
recently reared it's head with the advent of new advanced design
microprocessors. These new design CPUs run "software timing loops" so
rapidly that a software timing loop module which is part of Nantucket
Tools II and CA-Tools III cannot work as designed. Not all Tools
functions use the software timing loop, but it appears to be linked
into your application if you're using either the CTUS.OBJ or CTUSP.OBJ
extended drivers. A few people have reported this problem without
having CTUS.OBJ or CTUSP.OBJ linked in.
The two processors currently exhibiting this condition are the AMD K5
and Cyrix 6x86. As of this writing, AMD apparently has no "fix" of
their own, while Cyrix has a "fix" posted on their web site at
http://www.cyrix.com . Their fix consists of an executable named
PIPELOOP.EXE that is run from the AUTOEXEC.BAT file and causes timing
loops to be slowed down. Another "fix" is to turn off the internal
cache, which will significantly degrade all performance. Please note
this problem is not caused by a defect in the CPUs.
Just add it to your link script ahead of the libraries and ahead of
the extended driver file, if used. PIPELOOP.EXE from Cyrix is no
longer needed. It's been tested on Clipper 5.2 and 5.3. It should work
on 5.01a as well, but no one has reported using it on that version.
There's no need to maintain a separate program version for Intel
processors. It works fine on all brands of CPUs. So far.
The file name itself isn't significant. It's just a new name to
differentiate it from earlier versions.