Mail Archives: djgpp/2000/12/26/04:14:40
On Tue, 26 Dec 2000, Peter Remmers wrote:
> Switch the VM and interrupt a possible ongoing transfer??
Yes.
> 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?
This is something the application needs to bother about. There's a
way for a DOS program to prevent a VM switch if it needs, and there's
a way to request that Windows switches to a particular VM when a
certain event happens. MS should give the programmers the freedom to
write good code, instead of forcing them into good behavior by
arbitrary restrictions.
> > 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.
_Existing_ DOS programs don't, but programs written to take advantage
of these functions _will_. This is not unlike the new LFN API
introduced by Windows 95: DOS programs written before that didn't use
that API, and yet it _was_ introduced (and is used by many programs
nowadays).
> 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 ?
Why not, indeed? Compare with the FindFirst/FindNext/FindClose set of
functions in the LFN API: FindClose was introduced by the LFN API.
> Same problem, and too much useless effort for the guys in Redmond.
How can it be a ``useless effort'' if it helps programmers write
programs which are good ``Windows citizens''? Would you say that
introduction of function 1680h of Int 2Fh (the one called by
__dpmi_yield) was also a ``useless effort''?
> 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....
How do you mean ``there's no point''? ``No point''--for whom? for
Microsoft? That's exactly what I was saying: they didn't want DOS
programs to take advantage of nifty features offered by Windows, so
they didn't bother to make it easy to access the COM port from several
DOS boxes.
The fact is that DOS programs continue to be written and improved, and
offer some features that only work on Windows. DJGPP programs are a
notable example, with the LFN support. Several DJGPP programs support
the Windows clipboard, as well as access to Registry, window title,
etc.
> 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 same would be possible with CloseCOM: you just call it, and on
plain DOS it's a no-op.
You could also introduce a detection function, which fails if the
functionality is not available, like the LFN API does. Then the
application will know whether the advanced functions can or cannot be
used.
In sum, it's all solvable by simple programmatic means, if only the
vendor really wants to make its consumers happy.
> > 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?
That's an unreasonable thing to do, exactly as it is unreasonable to
leave files open for the next program, or allocate memory for it.
When a program exits, the OS closes all its files and frees all its
memory; it could do the same with COM ports.
> 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 always solve these problems by launching those batch files or
external programs as child programs. The parent opens the COM port
and initializes it, then the child inherits the connection, like with
files. When the parent, the program which started using the port,
exits, the port can be closed on its behalf.
Even if this doesn't solve all of the possible cases, it solves most
of them. It is unreasonable to punish 99% of users because of the
obscure 1%.
> > 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?
Stop Windows from catching the COM port accesses, and let the DOS
programs access the hardware directrly without any restrictions.
- Raw text -