On Sunday, 96/12/08, mark lewis wrote to David Noon about "Magic code
for DosSleep" as follows:

ml>  DN> This is correct. In 2.x it was the number of msec, but in 3.0 the
ml>  DN> AX register must be zero otherwise the call is ignored.
ml> 
ml> hummm... ok... when i type VER in a dos window and have 
ml> 2.30 returned, i _have_ to set AX >= 2 or i get 100% CPU 
ml> usage with the DOSSLEEP call... using 2 gives me 0% CPU 
ml> usage in a "repeat killtime until keypressed" loop... there 
ml> are NO fixpacks installed here...

Hi Mark,

I can only presume you are running the red spine version of Warp. I
use the blue spine version and it reports in as 3.0 in a VDM window.
However. the "get version" interrupt for VDM support returns 20.30 for
Warp 3.0. Since the first part should be divided by 10, this gives 2.30
for Warp 3.0.

ml> my killtime code (for os/2) now looks like this... yes, Turbo
ml> Pascal again :-)

Not all of us insist on C/C++. ... ;-)

ml> Procedure KillTime;
ml> begin
ml>   if in_os2 then
ml>     case hi(OS2ver) of        {os2ver returns 230 for v2.30}
                                                  ^^^^^^^^^^^^^
                            This really indicates version 3.0

ml>         MOV AX, 1680h    { use DPMI time slice call }
ml>         INT 2Fh

The simplest approach is just to issue the interrupt. Let the ISR
handle the gory details of which version of virtual DOS or DPMI
support is involved. It should also handle Windows DOS prompts (_NOT_
Windows apps) and DesqView too.

By using the interrupt you save carrying versions of the code that are
inapplicable to the user's system. It also saves you from having to
alter your code every time IBM changes the internal details associated
with the HLT setup. The only time you should need to be concerned is
when the IBM code goes wrong, and then code yourself a replacement
ISR. (Or get one from this echo.)

Regards

Dave


 * KWQ/2 1.2i * John Howard -- Australia's Dan Quayle.
--- Maximus/2 3.01