Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!sdd.hp.com!hplabs!hpfcso!hpfinote!pnl
From: pnl@hpfinote.HP.COM (Peter Lim)
Newsgroups: comp.windows.ms
Subject: Re: Windows 3.0 Terminal app.
Message-ID: <18950049@hpfinote.HP.COM>
Date: 10 Oct 90 20:29:42 GMT
References: <4748@tuminfo1.lan.informatik.tu-muenchen.dbp.de>
Organization: Hewlett Packard CICD
Lines: 30

/ hpfinote:comp.windows.ms / jcmorris@mwunix.mitre.org (Joe Morris) /  8:15 am  Oct  9, 1990 /
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
----------