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

 DN> I am suprised that INT 28H seems to work well. It is, I believe,
 DN> the one that OS/2 uses for idle detection and so must be called
 DN> repeatedly before any effect is seen.

right... one of the reasons why i don't use it when i detect OS/2 or windows ;-)

 DN> This would indicate to me that the INT 2FH is broken on those
 DN> systems.

hummm...

 DN> The DosSleep() API in DOS mode should simply be the HLT instruction
 DN> that is used inside the ISR for INT 2FH.

ok...

 DN> Simply to yield the remainder of the current timeslice you should
 DN> use INT 2FH, function 1680H.

right, the DPMI slice...

ml>>  DN> By using the interrupt you save carrying versions of the
ml>> code that
ml>>
ml>> the which interrupt? int 28h or 2fh?? see the "problem" ??

 DN> INT 2FH.

ahhh...

 DN> If your current version is broken you can replace the ISR with one
 DN> of your own assemblage. Just fiddle with the AX register until it
 DN> works.

 DN> There is at least one on Hobbes, called TAME.COM. It was written a
 DN> few years ago by Peter Fitzsimmons. It could provide you with a code
 DN> template if you want.

i don't want to have to use those really... that's why i'm doing it in my
code... maybe i'm doing it too lowlevel and need to bring the case
selection up to a higher point... nah... it'd still be the same... i guess
i'll just have to select one and stick with it no matter what. then if
there are problems, recommend the user to use one of those
"shims"...

ml>>  DN> are inapplicable to the user's system. It also saves you
ml>>  DN> from having to alter your code every time IBM changes the
ml>>  DN> internal details associated with the HLT setup. The only
ml>>  DN> time you should need to be concerned is when the IBM code
ml>>  DN> goes wrong, and then...
ml>>
ml>> that's what started all this... under warp4, int 2fh doesn't
ml>> work... yet...  so i wanted to code "the best one" for the
ml>> version in use  and later i'll add the ability for the enduser
ml>> to force which ever one he wants to use and let him suffer
ml>> whatever consequences may befall him -=%-)

 DN> But by putting them all in the one block of code your program
 DN> carries a great deal of redundant logic. If you have the
 DN> AUTOEXEC.BAT add the appropriate ISR (i.e. appropriate to the
 DN> current system)

ISR in this case being a "shim" list TAME...

 DN> then you need only use the DPMI interrupt no matter what the
 DN> environment. This removes the selection logic and all the
 DN> inapplicable code sections from your program.

true... but i still don't like the idea of using a "shim"... they
feel so much like kludges >

ml>> nothing really fancy... are you saying that i should  write an
ml>> ISR on "my own" int, code it to call the  appropraite int (kinda
ml>> like the above) for giving up the  time slices and call "my own"
ml>> all the time? hummm... i  think i'd still end up with some kind
ml>> of "case statement"  like routine that calls whichever int is
ml>> appropraite... like the above 

 DN> I'm not suggesting you create your own INT function. Just override
 DN> INT 2FH when it is broken, or use the one already in place when it
 DN> works.

HA!! i just figured it out! when my program starts up, it'll look to see
what OS it is running under. in this situation, i'll capture the interrupt
with my own routine that makes the appropraite call as needed... then i'll
just use INT 2fh ... errr... hummm... use 2fh all the time...
 uh oh... i smell smoke and my head has gotten warm...
-=B-)

 DN> The selection should be made when the AUTOEXEC.BAT is prepared. The
 DN> line in AUTOEXEC.BAT to install the ISR should remain unchanged for
 DN> the life of the particular operating system. If the "native"
 DN> version of the DPMI interrupt works then this is trivial -- you
 DN> don't bother installing your own ISR.

 DN> There should be no 'case' logic required at run time.

gotcha... i think the above will do it... only do it at program startup and
then just use the call...

)\/(ark