🚀 go-pugleaf

Well I investigated this some more, and came to a different conclusion than
Simon Lovatt.

The IO module does MS-DOS calls directly and thus does not suffer from this
problem. So you can do IO.WrLn where output is redirected to a file and not
get the lf -> crlf conversion.

On the other hand, the FIO module does io through the common language interface
(read *C-like interface*). Files can be opened in text (which translates) or
binary ("raw") mode. All the FIO procedures that open files use binary mode.

Unfortunately, the FIO.StandardInput and FIO.StandardOutput files (as well as
several others) are initially open, and the mode bit is
set to text! In a mixed language program, this would be required for C modules
to successfully write to the display.

Now, there are two solutions.

The first is to change the second entry in __openfd (in file r_mcore.a) from
4002H to 8002H, and recompile the libraries. Don't try to use the new library
if you have TS C.

A second less drastic solution is to import CLB and execute:
CLB._openfd[StandardInput] := CLB._openfd[StandardOutput] + CLB.O_BINARY - CLB.O_TEXT;

These bits are marked "read only", but in this case you gotta break the rules.

Of course, ideally one should be using the IO module, which doesn't have this 
problem. But I recognize that there might be some instances where one would
desire FIO so that routines can arbitrarily output to any device. Also, you 
can buffer file access with FIO (default is unbuffered, but I always specify
a buffer since it can make major differences in performance), while IO is
always unbuffered.

Simon's original fix has the problem that any file open for appending probably
won't work correctly as _write has the code to reposition the file at the end
while __write does not. Also _write has code to prevent a zero length write
(which truncates the file with MS-DOS).

Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply