Mail Archives: djgpp/2000/12/26/11:16:11
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> schrieb...
>
> > Switch the VM and interrupt a possible ongoing transfer??
>
> Yes.
Oh really?
Personally, I as a user would expect the transfer to continue in the background
when I switch to another application.
> > 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
Why the application?
> way for a DOS program to prevent a VM switch if it needs, and there's
Oh yes, force the user to sit in front of a boring status screen of a
transfer which could possibly go on for hours...
That's multitasking.
> a way to request that Windows switches to a particular VM when a
> certain event happens. MS should give the programmers the freedom to
Like "Switch to my VM when a byte arrives, so I can process it"?
The user would hardly be able to switch away.
> write good code, instead of forcing them into good behavior by
> arbitrary restrictions.
The restrictions are not "arbitrary". They are with DOS programs in mind
that behave like DOS programs normally do, i.e. act like they are running
under a single tasking OS, and think they have the hardware for themselves.
The point is "compatibility".
> > > 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_.
Agree. But as I said above, Microsoft had compatibility in mind.
New software is supposed to be written for Windows....
Although this is one point, about which I have a different opinion.
> 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).
The LFN API was meant for Microsoft's own set of command prompt commands
(DOS 7 dir, copy, md and the like).
Is the LFN API officially documented by Microsoft? (I don't know)
> > 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''?
"Useless" in that it would not be used by the whole bunch of existing DOS
applications, of which only a few are applications that use a COM port,
anyways. And even the few new-written programs that would use it (which
should have been written for Windows :-), would not make it worth inventing
a new API....
Like I said, the LFN API was for MS's own set of DOS commands, which is
something completely different. Every decent graphic OS also has a CLI
which, of course, must support the long file names :-)
NT is different, because all CLI commands are Win32 console programs.
But then, NT does not have a DOS mode...
> Would you say that
> introduction of function 1680h of Int 2Fh (the one called by
> __dpmi_yield) was also a ``useless effort''?
No. Everything that's used by Microsoft's own programs is not useless.
> > 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?
There's no question "for whom".
DOS programs that only run under Windows are not really DOS programs.
They would more be something like 16 bit Windows console programs...
> 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.
Did I already say "compatibility"? And it's ONLY about compatibility.
Nothing more.
> 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.
Ok, perhaps it's also about leaving some backdoors open for MS's own
programs. MS likes to have undocumented features to stay ahead of the
competition.
> > 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're rght, it would be that easy.
> 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.
That's the usual way. The "why not" is explained above.
> > 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.
I don't quite agree. File handles and memory are not the same as a COM port.
Files and memory are handled by the OS (DOS), COM ports are not.
COM ports are "no man's land" as far as DOS is concerned.
> > 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.
Because COM ports are no-mans-land under DOS, DOS programs behave accordingly
and there's nothing Windows can do about it, if it wants to be backwards
compatible to the programs.
> 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%.
No punishment. If the user chooses to use such programs, (s)he has to live
with the consequences.
The story would be different, if there was such a function as closeport.
But there isn't, and there won't be. For the given reasons.
> > > 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.
And abandon every bit of contention management?
I don't think so.
Peter
- Raw text -