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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

(Moving the technical discussion from users to devel where everybody is.)

On keskiviikko 13 maaliskuu 2013, Eero Tamminen wrote:
> On keskiviikko 13 maaliskuu 2013, Eero Tamminen wrote:
> > Redirecting the handle is easy, but when Hatari should stop
> > redirecting it?
> > 
> > When program calls something else (what?)?
> 
> On Fclose() redirection should be removed.  This is easy.
> 
> Attached patch adds that and Fforce() emulation.  However...
> 
> > When the program exits (=must hook also Pterm())?
> 
> ..this is much trickier.  I noticed that Hatari doesn't
> close *any* file handles when program terminates.
> 
> I.e. if one runs in a row a large number of programs that open
> many files, but which don't close them before exiting, Hatari
> GEMDOS emulation will run out of internal file handles.
> 
> I could add a hook for Pterm(), Pterm0() and Ptermres()
> that will close files and unalias them, but which of the open
> emulated files should be closed/unaliased on program exit?
> 
> How Hatari could know that given file is for current program
> and not for a program that started it?
> 
> And what should happen if program crashes instead of
> terminating normally?

I was thinking that I could track program startup and termination,
keep counter for current program [1] and use that to identify which
file handles belong to which program & are valid for it.

However, reliably detecting progam startup and termination so
that they don't get out of sync, is quite tricky, so I need some
advice.


GEMDOS emulation doesn't know whether Pexec() succeeds, and
then there's also AES shel_write(SHELL_LAUNCH...) for starting
programs (which doesn't necessarily do any externally visible
GEMDOS calls), so something else needs to be used for detecting
program startup.  I was thinking of using basepage address
for that as every concurrently resident program has it's own
basepage.

Is it safe to assume that if there's a new basepage, there's
also a new program?


As to program termination, I was thinking of catching Pterm(),
Pterm0() and Ptermres() as program's files are supposed to be
closed in each of these cases.

I'm assuming that programs left resident with Ptermres() won't
anymore access files, is this safe assumption?

Are there any other ways for program to terminate AND to detect
those?  E.g. what happens if program crashes?

Crashed program's file handles might not get closed by TOS, but
for this stuff to work for GEMDOS emulation, it would need to
detect that control moved back to previous program.


[1] As TOS is single tasking, only last started program should be
    doing GEMDOS calls until it exits and previous program resumes.
	Any GEMDOS calls done by (Emu)TOS on behalf of the program can
	be safely assigned for that program too I assume.  I.e. there's
	nothing that TOS retains after program termination?


	- Eero