From:	mcastle AT cs DOT umr DOT edu
Subject:	Re: Serial port crash
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Date:	Sat, 12 Sep 92 1:02:58 CDT

Here are my observations with djgpp affecting comm ports under desqview.

If I run a djgpp app and any comm program, the comm program stops receiving.

My informal test indicate that it is still SENDING, just not receiving.


Here's an example session:
Run comm prog, and login.
Run djgpp app, comm prog locks up.
Kill comm prog, set djgpp NOT to run in background, restart comm prog.
Thankfully, some comm progs will not automatically reset the modem when 
restarting (dsz in term mode, and procomm to name 2).  As long as djgpp
program is not running, no prob.  
Let djgpp prog run again, comm locks up.  
Hit head against wall :->

I haven't looked to see if there is a correlation between the amount of 
memory a prog uses, and comm ports locking up.  All my djgpp apps use a lot
of memory for data.  I suppose I need to compile a small djgpp prog to test
it.

Was anything added to go32 to provide support for the async demo, or just 
necessary to load that tsr to run that demo??

Anyway, you can free up the comm prog by restarting it (provided the app
allows you to do that without hanging up the modem), and not letting the 
go32 prog run in background.  You can't do that under DV/X from what I 
understand, and it sorts of defeats the purpose of dv any way.

Maybe this info will help pinpoint the problem though.

Oh, I remember someone mentioning (either in email to me, or and 
comp.os.desqview (or whatever the name of the news group is), that go32 1.06
did NOT have this problem).

Any one have any ideas??

mrc

- Raw text -