Hi Stephen,

You wrote to me:

SS>-> The best place to ask is over in OS2PROG (it gets rather
SS>-> off topic here). It
SS>-> depends on the version and fix level of OS/2, and what you are using to
SS>-> monitor processor usage. If it's the "pulse" applet,
that can give rather
SS>-> misleading results because of the way it works. If you repeat the test wi
SS>-> a processor/display intensive OS/2 application running, does your DOS
SS>-> program cause any slowdown to it? If not, the time
SS>-> slices are being given up
SS>-> and what you are seeing is just an artifact of the way the
"pulse" applet
SS>-> works.

SS>        Just to clarify, I noticed someone bring up the
SS>interrupt in a previous
SS>message and so didn't think I would be off topic for replying to it and aski
SS>a question about it.  Apologies if I was wrong.

I'm not the moderator, so I'm not due any apologies as it was just an
aside (and in fact my apologies to you if you thought it was a rebuke)
and I suggested the OS2PROG echo because there you'll find programmers
who know the insides of OS/2, some also monitor the OS2DOS echo.

SS>        But in any event, the program is causing quite a
SS>slowdown in other apps
SS>which is what drew my attention to it.  I normally do not run Pulse because
SS>it's somewhat subjective display.

That makes me think you may be using OS/2 Warp V4 GA. It had a problem
with giving up time slices as changes in the DOS sub-system from V3
broke that interrupt. It was fixed in one of the early fixpaks so if you
are running on the release version of Warp 4 it is worth getting a
recent fixpack and applying it.

According to Ralf Brown's Interrupt List if the idle sensitivity of a
DOS box is set to 100 the INT 2f 1680 call won't give up the time slice.

George

 * SLMR 2.1a * KEYBOARD - Used to enter errors int a computer.

--- Maximus/2 3.01