• Yielding timeslices

    From David Noon@2:257/609.5 to Mike Luther on Saturday, May 19, 2001 12:16:48
    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)
  • From David Noon@2:257/609.5 to Lee Aroner on Monday, May 21, 2001 12:09:58
    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)
  • From Lee Aroner@1:343/41 to David Noon on Sunday, May 20, 2001 03:43:04
    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)
  • From Lee Aroner@1:343/41 to David Noon on Wednesday, May 23, 2001 09:59:06
    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)
  • From David Noon@2:257/609.5 to Lee Aroner on Monday, May 21, 2001 12:09:58
    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)
  • From Lee Aroner@1:343/41 to David Noon on Sunday, May 20, 2001 03:43:04
    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)