Date: Tue, 26 Dec 2000 11:12:45 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Peter Remmers cc: djgpp AT delorie DOT com Subject: Re: Async COM managing In-Reply-To: <928vm4$udo$02$1@news.t-online.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.