From: "Peter Remmers" Newsgroups: comp.os.msdos.djgpp Subject: Re: Async COM managing Date: Sun, 24 Dec 2000 15:18:09 +0100 Organization: T-Online Lines: 43 Message-ID: <9250eb$a84$00$1@news.t-online.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: news.t-online.com 977667339 00 10500 WnLfEkTSeY-1n 001224 14:15:39 X-Complaints-To: abuse AT t-online DOT com X-Sender: 320094726121-0001 AT t-dialin DOT net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii schrieb... > > 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. Windows does contention management on the COM ports. This applies to Windows applications (which use a proper API with open and close) and to DOS boxes as well (which don't). As soon as a DOS program accesses the IO registers of the COM port, the port is blocked. > 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. Yes, it's a feature, no need for the quotes. The problem is that there's no way for DOS programs to tell that they're finished using the port - they just stop accessing the IO registers.... And there's no proper way for Windows to detect this. So the port stays blocked for all other DOS AND Windows applications for the life of the DOS box that uses/used the port. The idea was that DOS programs have a .PIF file. A DOS program is started with the PIF file, runs using the port, and when it's finished it's also finished using the port, and the DOS box is closed - freeing the port again. If you use the DOS box as a DOS session and start and quit programs without closing the DOS box, then the port will stay allocated to the DOS box until you close it. In the case of the DOS session "command.com" is the program that uses the port. When command.com exits the DOS session ends and the port is deallocated. > 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. This must be a mistake, since it is not possible. Peter