Mail Archives: djgpp/2000/12/25/21:36:42
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> schrieb...
>
> > 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?
Of course it's annoying, but there's no (practical) way around it.
> 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?
This wouldn't be too hard, but... Switch the VM and interrupt a possible
ongoing transfer?? Say, a DOS terminal program is connected to somewhere
and the user switches to another program. Why is the other program suddenly
supposed to talk to the other end the terminal program was connected to?
Switching the VM does not switch the physical connection of the port.
> 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.
That's correct. But DOS programs would have to use it, and they don't.
In fact, if there was a function to free the port, why not make a
complete API with a decent open, close, send and receive, etc ?
DOS prgrams wouldn't have to poke the hardware...
Same problem, and too much useless effort for the guys in Redmond.
> 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...
Adding such a functionality would produce DOS programs that would only run
under Windows. There's no point in writing DOS programs that only run under
Windows.... And the DOS programs would have to use two different "APIs"
within the same program. A dpmi_yield() is different, in that you just call it
or not, that's easy.
> > 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.
Who knows for sure that the program is finished with the port when it exits,
and not leave it initialized for the next program? Say, you have a batch file
with one program that does a dial-in, and the next program does a transfer?
What's with DOS terminal programs that use external file transfer programs?
You can't assume the program is finished using the port, just because it exits.
> > 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?
You're right - it even changes the window title,
but the problem is explained above.
> 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,
What's this setting supposed to do?
> exactly like there is a setting which prevents Windows from interfering
> with clock reprogramming by DOS programs (another Windows ``feature'').
This is a different story, but I agree with you in that point.
Peter
- Raw text -