Path: utzoo!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!cmcl2!sbcs!sbstaff2!altman
From: altman@sbstaff2.cs.sunysb.edu (Jeff Altman)
Newsgroups: comp.windows.ms
Subject: Re: Windows 3 and COM ports
Keywords: COM3 COM4
Message-ID: <9546@sbcs.sunysb.edu>
Date: 31 May 90 14:57:58 GMT
Article-I.D.: sbcs.9546
References: <1990May31.022051.27093@gpu.utcs.utoronto.ca>
Sender: news@sbcs.sunysb.edu
Organization: State University of New York at Stony Brook
Lines: 31

In article <1990May31.022051.27093@gpu.utcs.utoronto.ca> tj@gpu.utcs.utoronto.ca (Terry Jones) writes:

>Had some problems with Kermit communications package running under
>386 enhanced mode. I could talk to the device but the responses didn't
>come back to the screen (program). In real mode all was well (win /r).

This was true of the Windows 3.0 Beta but not of the release version.
Somehow Windows was blocking the Interrupts that state that a character
has been received by the UART.  It didn't block other interrupts such
as Overflow, etc.

I am currently writing this note with MS-Kermit 3.01 in a Windows
in Enhanced 386 mode.  And it works great!  Or at least as good
as a DOS App doing interrupt driven communication via a serial line
can be in a Multitasking Environment.

This is where a true Windows App can really shine, communications
in bcakground. 

>I looked through sysini txt files and found a reference to COMnBASE=xxxxh
>which specifies the base address of the com ports and the COM3 and COM4
>addresses were (I think) the IBM chosen ones not the ones that my modem
>uses (3E8 2E8) and when I set them correctly things worked fine. 

Okay, well this makes sense as well.  

>Just thought someone else might be interested!

me too.

- Jeff (jaltman@ccmail.sunysb.edu)