FreeCOM bug in CTTY: Should not open O_BINARY (CR/LF issue)

Hi, in reply to a problem report by Bernd Blaauw:

CTTY CON will lead the CONsole device to be opened in O_BINARY mode.
The correct mode would be either O_RDWR without O_BINARY or some other
mode that includes O_TEXT. Otherwise, many FreeCOM parts will only print
newlines, but no carriage returns, when supposed to print both.

Example:
CTTY CON
SET
would output:
FOO=BAR
       AAP=NOOT
               MIES=OEPS
instead of:
FOO=BAR
AAP=NOOT
MIES=OEPS

Solution: I propose the following patch:

diff -u ctty.old ctty.c
--- ctty.old    Mon Apr  8 18:02:22 2002
+++ ctty.c      Tue Nov 12 03:29:19 2002
@@ -82,7 +82,7 @@
   devAttr(2);
 #endif
 
-  if((f = devopen(param, O_BINARY | O_RDWR)) < 0) {
+  if((f = devopen(param, O_RDWR)) < 0) {
     error_no_rw_device(param);
     return 1;
   }


Alternatively, you could detect the "CON" string and act in a special
way then, like f = open("CON", O_RDWR) (which is the way that the FreeDOS
kernel normally opens CON at bootup). I do not know why exactly you use
O_BINARY, maybe for Ctrl-C handling or so.

By the way, interesting effect in DOSEMU: When I do CTTY NUL at the
command line, FreeCOM will exit and I will fall back into the DOSEMU
command.com shell. Probably FreeCOM panics on not receiving any more
input. Do not try at home, as CTTY NUL will "turn off" your keyboard
and screen. Only useful for batch files. For example:
ctty nul
run program with annoying banner
echo Done > con
pause < con
run another program...
ctty con
now everything is back to normal (given the PATCH above is applied)

Whatever. Strange enough, the MS kernel seems to have an internal CR-LF
conversion, so in MS-DOS, opening CON in O_BINARY mode does not harm.
Not sure if I should like this feature.

To whoever wants to know: The kernel uses the CON device -> ConTable ->
CONSOLE.ASM -> int 0x29 ("fast console output") -> int 0x10.ah=0x0e.bx=7,
plus some more steps of abstraction between you doing "printf" and the
file I/O functions reaching CON. Surprising how layered even the DOS
architecture is. I bet that int 0x10 call is a "single point of failure"
where you could catch most DOS output (well, apart from the other two
popular int 0x10.ah=2 and int 0x10.ah=9). Let us read CHARIO.C and CONSOLE.ASM
-> BinaryCharIO or int 0x29 used... but hey, it seems to boil down
to the same int 0x29 -> int 0x10.0x0e !



Conclusion: Bart/Tom, correct me if I am wrong, but am I right that
FreeDOS -never- uses INT 0x10.2/9 for console output? Then I have
to tell all of you that my TURBO3.COM driver will NOT speed up the
output of FreeDOS. Probably it WILL speed up the output when NANSI.SYS
is used. Would be nice if some NANSI expert could tell me. When my
assumptions are all correct, then I should probably write a TURBOFD.COM
driver that speeds up INT 0x10.0x0e instead of INT 0x10.2/9 !?!?

Eric

PS: Using the source rules, Luke :-). I start liking to "grep" in the
kernel/freecom sources. BUT I would like if JHall made it to fix the
annoying FINDFIRST bug in FIND, then I would be able to use DOS FIND
instead of UNIX GREP. However, I have a DOS GREP around, so not THAT
important for me ;-)).