🚀 go-pugleaf

I'm currently working on a problem with Windows 3 in which bad things happen
after running a DOS (non-Windows) communications program under Windows.  
When the DOS window is closed (by the EXIT command if you started the
normal DOS window icon, or by ending the program if started directly from
its own icon) then either the system crashes, or Windows abruptly terminates.

The problem was first seen with YTERM 3.0.1, but I've produced the same
symptoms using MSKERMIT 3.10 (ftp'ed directly from Columbia).  The error
occurs with no device drivers or TSR's other than those shipped with
PC-DOS 3.3 and Windows 3.0a.  The failure has been seen on NEC and IBM
boxes, VGA and EGA, Windows 3.0 and 3.0a, with and without a WD Ethernet
card installed.  The failure occurs only when running Windows in 386
enhanced mode.

The error is completely repeatable.  If it fails the third time you run 
KERMIT and has a particular failure mode, then every time you boot up
and try the script it will fail at the same point with the same symptoms.

Both the occurrence of the failure and its symptoms are VERY sensitive
to what is where in memory.  I built some dummy TSR's to force different
memory mappings and was able to affect the failures. 

Failure modes include:

 a - Following the EXIT command from the DOS screen, you see some of the
     desktop being rebuilt, then the screen blanks and you are presented
     with the normal DOS prompt.  A memory map shows that Windows is no
     longer in the machine.

 b - Same as (a) but the screen is left in a strange video mode and you
     can see only bars (if that much) where text ought to be.  Typing
     the command MODE CO80 blindly fixes the screen.

 c - Same as (a) but the screen you see was the one which was active in
     the DOS window when the EXIT command was issued.

 d - Any of the above, but if you re-invoke Windows the fonts used with
     icons are incorrect.

 e - The message 'INVALID COMMAND.COM, SYSTEM HALTED' (or something like
     that).

The fact that both YTERM and KERMIT are triggering the same failure mode
strongly suggests that the problem is in Windows, but so far I've not
gotten any indication from Microsoft tech support that the problem is
known.

A possible band-aid suggested by Microsoft was to check the EXCLUSIVE mode
box in the PIF editor for any DOS app which might be using a communications
program.  So far I haven't been able to break the system with this change,
but I'm uncomfortable with not knowing what went wrong...even if the failure
doesn't happen again.

Sure, we could go to some of the commercial packages but there are both
operational and financial reasons why YTERM and MSKERMIT are preferred.
(Thanks, Congress, for cutting the FFRDC funds in this year's budget...)

Does anyone recognize the symptoms, or have a suggestion?

Joe Morris