Date: Mon, 25 Dec 2000 16:55:34 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Peter Remmers cc: djgpp AT delorie DOT com Subject: Re: Async COM managing In-Reply-To: <9250eb$a84$00$1@news.t-online.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 24 Dec 2000, Peter Remmers wrote: > > 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. I cannot see how could anybody see this other than as a MISfeature. See below. > 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. Isn't it obvious that the above-described situation would annoy users immensely? What kind of ``multitasking OS'' is this, anyway? Why couldn't Windows provide a better virtualization of the COM ports? Is it that hard to stash away the exact way the COM port was programmed by each VM and reprogram the hardware when VMs are switched? At the very least, they should have given a way for a well-behaved DOS program to announce that it has finished using the COM port. There's nothing new in introducing special DOS interrupts which are only functional on Windows; for example, __dpmi_yield uses one such function. Most probably, someone at Redmond simply decided that it wasn't worth the hassle to add such functionality: let the DOS programs rot. So much for the ``consumer benefit'' propaganda... > 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. IMHO, this is another case of leaving the users out in the woods, without any real technical reason: Windows knows very well when a DOS program running in a DOS box exits. It could deallocate the COM port when that happens, instead of insisting that the entire VM be killed before the COM port can be used again. > 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. This is simply not true: Windows is well aware which program opened the port. Otherwise, how can it pop up a message with the program's name when that program GP Faults? > > 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. Maybe you know something about Windows internals that I don't (which would be a small wonder, since the internals have no official documentation). But it strikes me that there might be some hidden setting, in the Registry or in SYSTEM.INI, which changes this behavior, exactly like there is a setting which prevents Windows from interfering with clock reprogramming by DOS programs (another Windows ``feature'').