Hi Mike,

Replying to a message of Mike Luther to Lee Aroner:

In warp 3 and warp 4 beyond FP 6, the call is AX = 1680h Int =
2fh. Note that the call was broken in the warp 4 GA version up
till FP 6 was released. You can also use the slightly less
effecient DOS IDLE Int = 28h.

I didn't know the FP 6 part of this!

Various parts of VDM support were seriously broken in early iterations of Warp 4. Fixpack 6 was the first one where DOS programs worked reliably once more. This FP brought much of the code common with Warp 3 back into line, as it seems
to share a code base with FP 36 for Warp 3/Connect.

I have a pascal unit that encapsulates all this and a lot more,
such as OS detection, for every Intel based OS, drop an email to
leea@psynet.net if you want a copy.

would you mind if I got it from you and posted in the source tidbits
for the PowerBASIC crew? There have been a fair number of discussion threads on time releasing in that group, which always goes back to
things which don't of course, include OS/2!

Posting it there, and/or, perhaps, adapting it to in-line assembler
might be worth a lot to folks...

There was a TSR called TAME that could be added to your VDM's AUTOEXEC.BAT that
did a lot of this for you, without needing to add it to the application code. IIRC, one simply tripped INT 28H and TAME did the rest, issuing the appropriate
hardware instructions (mostly HLT with some "magic cookie" after it) for various surrounding operating systems (OS/2, NT, even Win16 in enhanced mode). There were other TSR's besides TAME that did the same thing (SLICER was another
name I seem to remember). All of these were available on Pete Norloff's BBS, Hobbes, Leo, etc.

Of course, well written native OS/2 code eliminates this timeslicing problem completely.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

Hi Lee,

Replying to a message of Lee Aroner to David Noon:

Of course, well written native OS/2 code eliminates this

>> timeslicing problem completely.

Just as well written native DOS code will as well. My DOS apps barely register on any of the various utilization checkers, and
this despite using a polling type scheme for keyboard input.

If your program is polling, it is not as well designed as a native OS/2 program. The yielding of timeslices repeatedly is not as satisfying a solution as blocking completely within a device driver.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

There was a TSR called TAME that could be added to your VDM's AUTOEXEC.BAT

> that did a lot of this for you, without needing to add it
> to the application code. IIRC, one simply tripped INT 28H
> and TAME did the rest, issuing the appropriate hardware
> instructions (mostly HLT with some "magic cookie" after it)
> for various surrounding operating systems (OS/2, NT, even
> Win16 in enhanced mode). There were other TSR's besides
> TAME that did the same thing (SLICER was another name I
> seem to remember). All of these were available on Pete
> Norloff's BBS, Hobbes, Leo, etc.

Of course, well written native OS/2 code eliminates this

> timeslicing problem completely.


Just as well written native DOS code will as well. My DOS apps
barely register on any of the various utilization checkers, and
this despite using a polling type scheme for keyboard input.


LRA


-- SPEED 2.01 #2720: White dwarf seeks red giant for binary relations.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Of course, well written native OS/2 code eliminates this

>> timeslicing problem completely.

Just as well written native DOS code will as well. My DOS apps barely register on any of the various utilization checkers, and
this despite using a polling type scheme for keyboard input.

If your program is polling, it is not as well designed as a native OS/2

> program. The yielding of timeslices repeatedly is not as
> satisfying a solution as blocking completely within a
> device driver.

Of course it is not as well designed as an OS/2 application would
be, it's built to run under a lowest common denominator
cheeseball interrupt handler swiped from a guy who copied it from
someone else!

And in this case, the polling serves other purposes...the routine
that surrenders timeslices also has an installable call of it's
own which allows the dynamic insertion of a chain of secondary
tasks that provide internal multitasking. All my apps can print
in background, for example. Not as neat and nifty as OS/2
certainly, but not bad for DOS.

And, for DOS apps, my proggys are *very* well behaved, and that,
in the end, is what counts.

LRA


-- SPEED 2.01 #2720: "He created OLD fossils!" "Riiiigghht!"

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Hi Lee,

Replying to a message of Lee Aroner to David Noon:

Of course, well written native OS/2 code eliminates this

>> timeslicing problem completely.

Just as well written native DOS code will as well. My DOS apps barely register on any of the various utilization checkers, and
this despite using a polling type scheme for keyboard input.

If your program is polling, it is not as well designed as a native OS/2 program. The yielding of timeslices repeatedly is not as satisfying a solution as blocking completely within a device driver.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

There was a TSR called TAME that could be added to your VDM's AUTOEXEC.BAT

> that did a lot of this for you, without needing to add it
> to the application code. IIRC, one simply tripped INT 28H
> and TAME did the rest, issuing the appropriate hardware
> instructions (mostly HLT with some "magic cookie" after it)
> for various surrounding operating systems (OS/2, NT, even
> Win16 in enhanced mode). There were other TSR's besides
> TAME that did the same thing (SLICER was another name I
> seem to remember). All of these were available on Pete
> Norloff's BBS, Hobbes, Leo, etc.

Of course, well written native OS/2 code eliminates this

> timeslicing problem completely.


Just as well written native DOS code will as well. My DOS apps
barely register on any of the various utilization checkers, and
this despite using a polling type scheme for keyboard input.


LRA


-- SPEED 2.01 #2720: White dwarf seeks red giant for binary relations.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)