[comp.windows.ms] Screen Peace interferes with WinQVT file transfers.

gilmore@vax1.acs.udel.EDU (Scott Gilmore) (07/16/90)

My Platform:  IBM PS/2 Model 70-121 (20MHz)
              PC-DOS 4.01
              4 MB RAM
              Windows 3.0 in 386 Enhanced Mode
              Everex Evercomm II/2400 modem (2400bps internal) 
              Screen Peace (downloaded from cica.cica.indiana.edu on July 15)
              WinQVT 4.15

Hello...

     It seems that Screen Peace hogs most of the CPU when it takes 
over, causing my Zmodem transfers (I haven't tried other protocols) to lose
characters and then abort.  The transfer is between a BSD Unix machine and my 
PC running WinQVT.

     After looking through the docs, it doesn't appear that Screen Peace's
priority can be altered.  Of course, I can disable the saver before doing a
transfer and the problem goes away.  However, it is precisely during these
very long transfers that I want the screen to be blanked.  Part of the problem
is that Screen Peace blanks when there is no keyboard or mouse activity for
a specified time; it doesn't look at screen activity such as file transfer
status reports.

     Actually, WinQVT seems to have trouble transferring during any substantial
interruption, such as loading File Manager.  I have tried using both 
software and hardware flow control, but there seems to be no difference.
WinKermit does not have this problem, so I guess the real fault lies with
QVT.  By the way, this also happened when running in Win/386 version 2.11.
In the past I have just made sure to not do anything else during a QVT file
transfer.  Kind of silly though, because this is supposed to be an advantage of
using Windows.  Other than this problem, I've been a happy winQVT user for
well over a year.

     If anyone has a good suggestion, I'd love to hear about it.  I would use
WinKermit all of the time if it supported vt100 and wasn't so darn slow 
compared to Zmodem transfers (my host machines don't have Kermit versions 
supporting long blocks or sliding windows yet).

     Thanks for your time.
-- 
---
Scott Gilmore                                       gilmore@vax1.udel.edu
Mechanical Engineering and Center for Composite Materials, U. of Delaware