DVSI 2.00 Bug Fix -- Distribute with DVSI2_00.ZIP

July 19, 1993

This is a patched version of DVSIXDI.COM 2.00 which fixes a rather
obscure bug I recently found.  The symptoms of this bug are not
repeatable.  Basically, the bug can cause unexplicable system crashes
which (could) tend to happen after about an hour of DV operation,
but could just as well happen at any time.  Crashes may disappear
after loading DVSIXDI.COM after other XDI's (not many exist, anyway,
except for DV's internal XDIs which are loaded after DVSIXDI.COM).
DESQview/X is probably more susceptible to this bug that plain old
DV, because it loads many more XDIs -- the built-in DOS extender uses
an XDI.

Anyway, replace your copy of DVSIXDI.COM with this one and it should
work.  Registered users will see that this claims to be an
"Unregistered copy," don't worry about it. There is no functional
difference and it doesn't nag you about registering.

Technical description of the bug:

DV calls DVSIXDI's RESTORE_STATE routine just before a task gets the
CPU.  The task's handle is passed in DX, and its mapping context in
BX.  Upon completing its work, DVSIXDI passes the BX and DX values
onto the next XDI's RESTORE_STATE routine.

The XDI must not change these values of BX and DX.  Unfortunately,
DVSIXDI would replace the handle that was in DX with the upper
word of the DWORD that contained the number of clock ticks that
occurred since DV started up.  The result was that all XDIs loaded
after DVSIXDI (including DV's internal XDIs) would
see a task handle of 0 passed to the RESTORE_STATE routine during
about the first hour of DV operation.  After that, the approximate
number of hours of DV operation would be passed as the handle.

This did not reliably cause a system crash because
 (1) not all XDIs necessarily have to use the RESTORE_STATE call,
     so some may not care what handle is being passed;
 (2) some XDI's may use the mapping context in BX to identify the
     process;
 (3) An XDI may be written to ignore handles that it doesn't recognize,
     in which case SAVE_STATEs occur on tasks, but never RESTORE_STATEs.
     This may not cause a crash but may waste resources.  On the other
     hand, this may cause a crash; depending on the XDI.

This new version pushes the DX value before modifying it, and then
pops it before passing control to the next XDI.

The Future of DVSI:

I discovered this bug while working on DVSI 3; a project that I've
wanted start work on for the past 14 months.  I've finally started.
It's a little early to discuss details yet, but I have plans for
significantly more process monitoring and process "spying."
Hopefully, DVSI will be something that no serious DV user can be without...

Send me your suggestions and comments; I always like to hear from
DVSI users.  My new address is

danb@bunt.sps.mot.com

(512) 891-6437 days
711 W 32nd #102
Austin, TX 78705

Dan Bodoh
