Message-ID: <004101c06d9c$8ff50860$0201a8c0@tim> From: "Tim Nicholson" To: References: Subject: Re: Async COM managing Date: Sun, 24 Dec 2000 11:27:55 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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" Newsgroups: comp.os.msdos.djgpp To: "Tim Nicholson" Cc: 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.