Mail Archives: djgpp/2000/12/27/03:13:50
On Tue, 26 Dec 2000, Peter Remmers wrote:
> > > 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.
I meant the above "Yes" for the case that the VM which Windows makes
current already started to use the COM port. Windows already handles
the case where the other VM isn't using the port.
> > 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.
You misunderstood me. The data rate coming from a COM port is
relatively low; if you feed the application in some small chunks, the
switch will be infrequent and invisible for the user.
> > 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.
The switch back away is automatic.
> > 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".
No, the point is "find the easiest way out of the problem, and screw
the users".
No matter how many misbehaving DOS programs are out there, an OS
should not punish a well-behaved program on behalf of the other kind.
> > 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).
Yes, when a feature benefits MS, it is introduced; but if a feature
benefits users, screw the users!
> Is the LFN API officially documented by Microsoft?
Yes. Although with Microsoft, it is hard to know what documentation
is ``official''. But you can find the LFN API documented on the MS
Web site, for example.
> > > 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.
I think that ``usability'' should be judged from users' point of
view, not from the vendor's one.
> > > 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.
I don't see any real difference. FYI, files and memory are not
handled by the OS (meaning the kernel) on Windows, they are handled by
layers above the kernel. COM ports are handled in similar ways.
> > 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.
We are talking about Windows, not about DOS. On DOS, all these
features should be no-ops anyway.
On Windows, since the OS catches all port accesses anyway (otherwise,
how can it prevent other VMs from accessing the COM port?), it could
implement this and make life easier for people who write well-behaving
DOS 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.
Yes, with Microsoft deciding what the consequences are, based on its
own interests. What a great deal!
> > > 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?
If the user so wishes, yes. Users are grown-ups sometimes, you know.
- Raw text -