ml>>  DN> This is correct. In 2.x it was the number of msec, but in
ml>>  DN> 3.0 the AX register must be zero otherwise the call is
ml>>  DN> 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...

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

right... i simplified the above already in my startup code... it returns
the version number for whatever OS it is running under... the hi side of
the word is the major portion and the low side of that same word is the
minor portion... it was easiest to do that "over there" so i
could use the same style no matter what OS 

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

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

hehe, so true -=B-)

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

right... see above :-)

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

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

well, see... some systems seem to get better results with int 28h, some
with dossleep and others with int 2fh... in this case, the above code is
from one of my general use libraries... it is used in all my programs...

 DN> By using the interrupt you save carrying versions of the code that

the which interrupt? int 28h or 2fh?? see the "problem" ??

 DN> are inapplicable to the user's system. It also saves you from
 DN> having to alter your code every time IBM changes the internal
 DN> details associated with the HLT setup. The only time you should
 DN> need to be concerned is when the IBM code goes wrong, and then

that's what started all this... under warp4, int 2fh doesn't work... yet...
so i wanted to code "the best one" for the version in use and
later i'll add the ability for the enduser to force which ever one he wants
to use and let him suffer whatever consequences may befall him -=%-)

 DN> code yourself a replacement ISR. (Or get one from this echo.)

mmmmm... i like to try to stay pretty generic if i can... i've a few ISRs
running about but nothing major... my most common one hooks int 1ch for a
timer loop and releases it when done... hook, use, release... in this case,
my int 1ch replacement simply increments a counter and calls the original
int 1ch... like i say, nothing really fancy... are you saying that i should
write an ISR on "my own" int, code it to call the appropraite int
(kinda like the above) for giving up the time slices and call "my
own" all the time? hummm... i think i'd still end up with some kind of
"case statement" like routine that calls whichever int is
appropraite... like the above 

what am i missing?

)\/(ark