CH> Turns out desqview is a -horribly- slow multitasker when
 CH> doing screen writes, in most cases much much slower writing
 CH> text to the screen than even 16 bit windows, so with a
 CH> typical 386/486 desqview setup, locking the baud at rates
 CH> higher than 38,400 really didn't make much difference in..
 JS> That's the truth also.  I ran DV (on a 486) for a 
 JS> couple of years and anything above 38400 was a useless 
 JS> endeavor, to say nothing of the problems I had with a 
 JS> couple of doors which, BTW, seemed to run/display fine 
 JS> under straight DOS with a port speed of 57600.
Well, to be clear, it shouldn't of mattered that the BBS was being run in DV 
-if- snoop wasn't turned on as the local screen wouldn't be written to. If 
one was using DV when dialing into a BBS (as many sysops, including myself 
did to "test" the effect of higher locked baud rates), because of the slow 
screen writes in DV, he probably wouldn't see much difference between having 
a locked baud at 38400 and 115200 as the data just wouldn't write to the 
screen in DV at much over 30-40,000 cps. Not to say that someone calling in 
with DOS, Windows, OS/2, NT, anything other than DV wouldn't see a difference 
in locked bauds rates on the terminal end, whether the BBS was being run in 
DV or not. Point being that the speed screens can be written can have a 
noticible effect. DV seems to allocate fewer resources to doing screen writes 
than other multitaskers do and more to multitasking. That may of been the 
trade off as DV did multitask in the background smoother and more 
efficiently, other than screen writes, than 16 bit windows. Windows, being 
GUI oriented, -had- to put more resources into screen writes, than DV, which 
was text oriented. More modern equipment, IE Pentiums, VLB/PCI accelerated 
video cards running DV wouldn't have the noticible screen slowdowns with Text 
software that older ISA 486 and 386 systems did, so I would expect locking 
the baud at a higher rate would make a difference.
 JS> Maximus/NT 3.01b1:
 JS> Now for a question.  I'm interested in running the 
 JS> above under Win95 but I've been told that it can't be 
 JS> done with a Win95 mailer.  I've also been told the 
 JS> reason for this concerns Win95's 16-bit command 
 JS> processor.  So the question is this: What do you think 
 JS> would happen if I installed a 3rd party 32-bit command 
 JS> processor under Win95 and tried it?
You have been told right. 95's command processor is 16 bit, so when control 
is passed from one program to another, the 16 bit command processor is 
loaded. This causes 32 bit comm software to drop DTR. Brian Woodruff has 
written WINFOSSIL for windows 95. If an only if the 32 bit comm software can 
be FOSSIL driven and has a special hook to WINFOSSIL, is it possible to pass 
off to another app without dropping DTR. Binkley 32 v 2.60 is the only 32 bit 
fidonet/bbs software that supports Winfossil. Maximus 3.01n doesn't and 
probably never will. I run Bink32 and MaxNT in Windows NT, not Windows 95.
--- Maximus/NT 3.01b1
---------------