Mail Archives: djgpp/2000/12/25/10:01:50
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'').
- Raw text -