Message-ID:	<004101c06d9c$8ff50860$0201a8c0@tim>
From:	"Tim Nicholson" <Tim AT gizzy DOT co DOT uk>
To:	<djgpp AT delorie DOT com>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1001224081539 DOT 7747E-100000 AT is>
Subject:	Re: Async COM managing
Date:	Sun, 24 Dec 2000 11:27:55 -0000
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4522.1200
Reply-To:	djgpp AT delorie DOT com

Is that what the problem is?

I perceived the problem as being that once the port had been accessed by
bioscom(). It could not be released again so that other programs to access
it. This, I thought, was why syco was asking:

> Can I use another functions able to *OPEN* / init / send / receive
/*CLOSE*
> the comm port and leave the things clean on exit ?

Dzcomm will definitely does open, initilise, send, receive and  free up the
port for other applications once it has finished with it. It does not allow
simultaneous use of the port, but I did think that is was an issue here.

I apologise it I got the wrong end or the thread!

Merry Christmas

Tim Nicholson

----- Original Message -----
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Newsgroups: comp.os.msdos.djgpp
To: "Tim Nicholson" <djgpp_mail AT gizzy DOT co DOT uk>
Cc: <djgpp AT delorie DOT com>
Sent: 24 December 2000 06:19
Subject: Re: Async COM managing


>
> On Sat, 23 Dec 2000, Tim Nicholson wrote:
>
> > > Is it another way to obtain the expected result, without bioscom() ?
> > > Can I use another functions able to *OPEN* / init / send / receive /
> > *CLOSE*
> > > the com port and leave the things clean on exit ?
> >
> > I use a library called dzcomm which is an allegro add-on. It will allow
you
> > to access up to eight com ports and supports shared interrupts. You can
> > implicitly open and close ports at any speed that your UART chip
supports.
>
> The problem in this thread was that using a COM port from a DOS box would
> disallow other (DOS?) programs running on Windows from accessing the
> port.  Those other programs are not DJGPP programs and were certainly not
> written using DZComm.
>
> AFAIK, this is Windows' ``feature'': when a DOS program accesses a COM
> port, Windows makes it unavailable to other DOS boxes.  This seems to be
> Microsoft's way to ``virtualize'' the port.
>
> Are you saying that you tried this configuration, and DZComm somehow
> avoids the problem of making the COM port appear to be busy to other DOS
> boxes?  If so, the way to do that should be seen by studying the DZComm
> sources.

- Raw text -