On Thu, 5 Aug 2004, Bart Oldeman wrote:
Hello Bart,
But back to the question: "HOW DOES FREECOM KNOW THAT THE CURRENT STANDARD OUTPUT IS THE DEVICE DRIVEN BY THE BIOS?" Is it save / useful to use BIOS functions. Or how can FreeCOM ensure the human sitting on the other side of the line is seeing the results.
The only reliable way is to trap int10, write a character using int21 and
Yeah, that's what I thought of. And there is also some nice try for stdin ;-).
That said. In practice a console driver will have the "FAST int29" bit set, and a COM driver won't. As int29 will surely write a character to the console. This isn't waterproof in theory but ... I simply don't know of
When I saw your mail I had this "deja vu" feeling we get here on this list much more often ;)
Well, this thread deals with CLS in particular.
However, my reasoning goes further than that, e.g. the enhanced input
needs to position the cursor all over the line, which probably spans multiple physical lines. And Cursor_Left (ASCII 0x08) does not necessarily
wrap to the previous (physical) line.
Matthias once wrote a long mail saying how other DOSes deal with this.
Hmm. I'm curious. He writes that DR DOS issues ANSI escape sequences. Actually they are fine, as long as you have a VT100 provider installed, as I wrote. But it is impossible to detect such provider across a line on another computer.
Also, in http://marc.theaimsgroup.com/?l=freedos-dev&m=101717593306186&w=2 he writes "/If/ an ANSI (or another extended console) driver is installed and detected (which is not trivial, if it should work with all known ANSI drivers), the command processor will send an ANSI-ED sequence "<[2J" to STDOUT (whereby"<" stands for ESC (1Bh) here)." Then: "Only if no such driver is around and the console is attached to the physical screen (not redirected, no CTTY),"
in http://marc.theaimsgroup.com/?l=freedos-dev&m=101742333130155&w=2 "If STDOUT does correspond with a device (bit 7) which does *not* supporting INT 29h (bit 3 cleared), it will use a method partially similar to the DR-DOS INT 10h/AH=00h method to clear the screen, in all other cases it will simply issue the ANSI ED-sequence. The INT 10h method used appears to work more" So, if STDOUT == COM3 (no Fast Output bit) and the shell does not know about a CTTY COM3 (where should it get the info about it unless the CTTY command was invoked in the shell itself?). it uses the BIOS.
My claim is:
a) you cannot detect an ANSI driver across the line **), and b) you do not know for sure what CTTY is in place, except the shell itself has invoked it ***).
So, what is described there means:
if the server computer has ANSI installed locally, it will send ANSI tokens to your client, regardless if your client has ANSI or not; if the shell on the server has not executed the CTTY command itself, it will clear the server's screen through the BIOS.
This is what I wrote and what I asked about.
When I now move the issue away from CLS toward the enhanced input, I have the problem to freely position the cursor in a long line wrapping upon several physical lines.
Actually I seem to be stuck in a problem that cannot be solved automatically, but by the user only, e.g. by setting environment variables or some flags as it is common in Unix shells (TERM=, ROWS=, LINES=, setterm). If one could assume that a VT100 parser is present, the problems would be less.
just follow the whole thread (prev and next), there's nothing I can add here, but I assumed you had already looked this up?
No, I have no luck using any search engine in conjunction with any FreeDOS archive.
Bye,
===
**) No sample in the messages list a possibility to detect an ANSI driver on the other end of a COM line.
***) Only the hint about device/stdout/fastput.
--
Steffen Kaiser
------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
