Path: utzoo!attcan!uunet!world!decwrl!shelby!agate!linus!linus!mwunix.mitre.org!jcmorris
From: jcmorris@mwunix.mitre.org (Joe Morris)
Newsgroups: comp.windows.ms
Subject: Re: Windows 3.0 Terminal app.
Message-ID: <122655@linus.mitre.org>
Date: 9 Oct 90 14:15:40 GMT
References: <4748@tuminfo1.lan.informatik.tu-muenchen.dbp.de>
Sender: usenet@linus.mitre.org
Reply-To: jcmorris@mwunix.mitre.org (Joe Morris)
Organization: The Mitre Corporation
Lines: 28

In a recent article rommel@lan.informatik.tu-muenchen.dbp.de writes:

>Did anyone already notice than you can't select 8 bits with even/odd
>parity in the terminal application? When one tries to set 8 bits and then
>even parity, Terminal resets bits to 7 and when you now select 8 bits
>again, it resets parity to none. But the PC hardware can do 8 bits with
>parity checking. 

Are you sure that this isn't a problem of nomenclature?  A continuing problem
in the comm world is that half the population counts the parity bit in the
bit count and half doesn't: this means that if I say "8 bits even parity"
some people will read this as meaning a total of eight data elements between
the start and stop elements (8 bits *including* parity) while others will
interpret it as meaning a total of nine elements (8 bits *plus* parity).  
Also, not all asynchronous interfaces can accommodate the 9-element 
configuration.  (PC BIOS doesn't seem to support it, but I've never needed
to actually try it on the hardware.)

TERMINAL seems to be quietly enforcing a limit of 8 elements in the comm
character frame, and is interpreting the parity bit as an addition to the
bit count.  Thus, if you specify 8 bits and even parity Windows is
changing it to 7E in order to not exceed the 8-bit limit.  It's a pure
design blunder that it isn't posting an error message when it does this.

Getting back to your problem: just what character frame configuration are
you really looking for?  8 bits *including* parity, or 8 bits *plus* parity?

Joe Morris