Re: [hatari-devel] Fforce() fails with GEMDOS drive emulation

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On lauantai 16 maaliskuu 2013, Thomas Huth wrote:
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > While the code should handle cases where redirected file handles
> > are inherited to child processes, I didn't have any test-case
> > for testing that.  Something to test that case would be appreciated.
> 
> Isn't this the default case when redirecting stdio from a shell? I.e.
> you could run a TTP program from a shell like MUPFEL or something
> similar and pipe its output to a file on the GEMDOS hard disk?

Mupfel seems to work fine:

GEMDOS 0x3C Fcreate("c:\test.tst", 0x0)
-> FD 64 (read/write)
GEMDOS 0x40 Fwrite(64, 1, 0x71cfa)
GEMDOS 0x42 Fseek(0, 64, 0)
GEMDOS 0x46 Fforce(2, 64)
.... pexec etc. ...
GEMDOS 0x4C Pterm(0)
GEMDOS 0x19 Dgetdrv()
GEMDOS 0x0E Dsetdrv(0x2)
GEMDOS 0x46 Fforce(2, 65535)
GEMDOS 0x42 Fseek(0, 64, 1)
GEMDOS 0x3E Fclose(64)


Gulam just creates a new file handle on each re-direction without
closing the redirected handle after redirected command has
completed.  And redirection worked with none of its internal
commands, not even on floppy image.


Any idea whether Fforce() on real TOS affect also BIOS output
functions, not just GEMDOS ones?  With all TOS versions?


	- Eero