Mail Archives: djgpp/2000/12/24/09:21:31
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> 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
- Raw text -