From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Newsgroups: comp.os.msdos.djgpp,comp.lang.perl.misc
Subject: Re: djgpp, Win98, Perl, and serial port
Date: Sun, 22 Aug 1999 10:24:25 +0300
Organization: NetVision Israel	
Lines: 31
Message-ID: <Pine.SUN.3.91.990822101855.6405A-100000@is>
References: <37b4a540 AT news5 DOT newsfeeds DOT com> <37bb1289 AT news5 DOT newsfeeds DOT com> <37bc52c7 AT news5 DOT newsfeeds DOT com>
NNTP-Posting-Host: is.elta.co.il
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.netvision.net.il 935306603 16142 199.203.121.2 (22 Aug 1999 07:23:23 GMT)
X-Complaints-To: abuse AT netvision DOT net DOT il
NNTP-Posting-Date: 22 Aug 1999 07:23:23 GMT
X-Sender: eliz AT is
In-Reply-To: <37bc52c7@news5.newsfeeds.com>
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Thu, 19 Aug 1999, David Christensen wrote:

> |>   The middle level functions I wrote are;
> |>
> |>  comopen()   open a serial port
> |>  comclose()  close serial ports
> |>  comsetprm() set transmit parameters of a serial port
> |>  comgetprm() get transmit parameters of a serial port
> |>  comwrite()  write to a serial port
> |>  comread()   read from a serial port
> |>  comsetmcr() set MCR (modem control register) of a serial port
> |>  comgetmsr() get MSR (modem status register) of a serial port
> |>
> |>   I feel the set of these functions is incomplete. Because
> simple binary level transmfer can be executed by using comwrite()
> and comread(), but text level transmfer requires many cares.

If this is for the DJGPP port of Perl, then I don't think you need to 
care about the text/binary nuisance, and possibly not about some of the 
details of the functions mentioned above.  DJGPP provides the so-called 
Filesystem Extension feature, whereby you can install a handler for 
low-level I/O operations, such as open, read, write, close, etc.  This 
handler is called when the library is about to call a DOS or Windows 
function to handle the request.  The handler gets a chance to recognize 
handles and file names that reference the special devices or streams 
emulated by the extension, and handle the call instead of DOS/Windows.

This approach relieves the extension from handling the gory details such 
as text/binary conversion, buffering, etc., which are done by the library 
as usual.