Re: [hatari-devel] Fforce strangeness

[Thorsten Otto <admin@xxxxxxxxxxx>]

On Montag, 29. Juni 2020 18:57:36 CEST Eero Tamminen wrote:

 

>Does "--trace gemdos --log-level info" show anything interesting?

 

No, not really.

 

>What this is *supposed* to do?

 

I guess this is done to get a clean state, be Fforcing all output to the console.

 

> Under TOS, -1 would be invalid file handle, so

> I guess above calls would all give EIHNDL errors

 

No it isn't. -1 Is a valid GEMDOS handle, the one that you get by doing Fopen("CON:")

 

 

>I think both would be valid under MiNT/Magic

 

No, FForce(-1, 2) is invalid, because -1 is not a standard handle, it refers to a device (you cannot redirect device output to a file)

 

>could you come up with a patch that fixes the behavior for you?

 

Thats the problem, i'm currently unsure whether that is actually the cause of the behaviour of fVDI, it might also be some other strange interaction between GEMINI and fVDI. I just stumbled upon that code while trying to find the issue. Since that code is just there to detect redirection of output to GEMDOS emulated files, and the code will forward the output to TOS in both cases, i actually think there must be something else.

 

>There are some things nowadays in GEMDOS HD

>emulation which rely on identifying programs

>by their basepage, such as file force()ing.

 

Yes, but that output is done by GEMINI, not fVDI. fVDI does not even see that output, because GEMINI catches it in the bconout vectors, in order to redirect it to the console window. Unluckily tracing this is quite difficult, because gemini seems to replace those hooks by their original values before it starts a GEM program.