From: "Peter Remmers" Newsgroups: comp.os.msdos.djgpp Subject: Re: Async COM managing Date: Tue, 26 Dec 2000 16:52:09 +0100 Organization: T-Online Lines: 185 Message-ID: <92aemg$o2n$04$1@news.t-online.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: news.t-online.com 977845776 04 24663 E63fHSGS-Yh4R 001226 15:49:36 X-Complaints-To: abuse AT t-online DOT com X-Sender: 320094726121-0001 AT t-dialin DOT net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii 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