Re: [hatari-devel] GEMDOS (HD) emulation does not intercept Ccon... => Input/output redirection not working

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 06/27/2016 09:26 PM, Christian Zietz wrote:
> in the Emutos-devel list I was asked to report the following to you.
> Please excuse if this is already widely known. (I didn't find an entry
> in doc/todo.txt, though.)
>
> Hatari's GEMDOS handler (used for HD emulation) does not intercept the
> Ccon... functions. Hence, input or output redirection to a file on the
> emulated HD fails when these functions are used instead of Fread/Fwrite.
> Steps to reproduce:
>
> * Fopen any file on the emulated HD. Hatari will return a handle h, e.g.
> h=64.
> * Use Fforce to redirect the standard input (Fforce(0, h)) or output
> (Fforce(1, h)) to said file.
> * Use any Ccon... input or output function such as Cconin() or
> Cconout('X'). No redirection occurs.

GEMDOS HD emulation Fforce() support is relatively new (2013) feature
in Hatari, because:
* It's very rarely used on plain TOS
* it requires tracking TOS processes in addition to just GEMDOS file
  operations, and anything else that might affect how TOS file handles
  are bound to processes and what's the process lifespan.

GEMDOS HD emulation can act only if it can replace the whole function,
not just part of it.  So, a thing like Cconrs():
"The GEMDOS routine Cconrs reads a string from the standard input
 stream (GEMDOS handle 0) - normally the keyboard - and echoes it
 to the standard output stream (GEMDOS handle 1) - normally the screen.
"

Has an issue that if oly of the input and output is redirected to file:
* How it can get the output to wherever TOS has the screen with the font
  that happens to be selected by TOS, when 68k emulation is pending on
  entry to the GEMDOS function?
* Or how it can get the input from TOS so that it can write it to
  a file?

I guess in those cases it can just output a warning that it's not going 
to work (and document that in Hatari manual).  At that point it's too
late to undo Fforce() / make it visible to to TOS.

This leaves using Cconrs() with both input and output redirected to
a  file.  This can naturally work only if both files are within GEMDOS
HD emulation as it doesn't know anything about TOS internal file
handles and how to interact with TOS internals for them.

-> I'm starting to feel that this is a rat's nest best not to be
   touched.  Maybe even the current [1] Fforce() support should
   be behind some command line option...

[1] Pexec/Pterm/Fwrite/Fread/Fclose/Fseek/Fdatime


Next problem with Fforce() and related functionality is that we're
lacking test-cases to test and validate GEMDOS HD emu against different
TOS versions.  E.g. running processes from each other with "random"
things being redirected [2], and then unwinding that back to top parent
process and making sure that everything still works as expected.

[2] Note, according to TOSHYP:
   "In all known GEMDOS versions (up to and including 0.19) errors
    occur if, after an Fdup, a program is started with Pexec."


If you you happen to have a ready-made test-case for the issue(s),
that would be nice.  Ideally, the test-case(s) should go in to:
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/file/tip/tests/tosboot/disk


	- Eero