refactor: DOSINT21H loads the initial DOS executable

[maximilien-noal]

Description of Changes

Gives the DOS INT21H class the capability and responsibility to load the host file, if the ProgramExecutor determines that it is a DOS executable (.COM or .EXE file)

Rationale behind Changes

Makes it easier for a potential contributor to implement DOS function INT21H 0x4B (LOAD AND/OR EXECUTE).
Along with the DOS SDA, PSP chains, and eventually TSR support.

Suggested Testing Steps

Test this with your favorite game.
It should still load, even if you set a preferred start segment in the config, or even use program arguments.

Dune still works.

[JorisVanEijden]

Krondor loads and runs.

But I don't think an interrupt handler is the right place for this file loading is it?
Feels like DosFileManager would be a better fit.

I'm also not quite sure how this makes it easier to implement DOS function INT21H 0x4B.

[maximilien-noal]

Dosbox does this :

Call the command processor, which eventually calls dos int21h 0x4b to execute a DOS program with a DOS path and args as parameters given via CPU registers.

It also handles the SDA structure, PSP chains, DOS process management, TSRs and such.

What we do currently on master:

We completely side step the dos kernel and dos int handlers and the usage of a DOS path.

We directly load an executable in memory from an absolute host path, with class that are foreign to the OperatingSystem namespace.

We don't have the SDA, DOS process management, TSR support, etc.

What this does:

What I see as the first step : call the dos int21h class to load the DOS program, from an absolute host path.

It's a little bit better, because the rest of the modifications will be done in the dos kernel and the dos int21h handler.

[JorisVanEijden]

Is deleting the currentDir really the only cause for IOExceptions when deleting a directory?

[JorisVanEijden]

Why not return this at the end of the codeblock where that boolean is set?

[JorisVanEijden]

Dosbox does this :

Call the command processor, which eventually calls dos int21h 0x4b to execute a DOS program with a DOS path and args as parameters given via CPU registers.

It also handles the SDA structure, PSP chains, DOS process management, TSRs and such.

What we do currently on master:

We completely side step the dos kernel and dos int handlers and the usage of a DOS path.

We directly load an executable in memory from an absolute host path, with class that are foreign to the OperatingSystem namespace.

We don't have the SDA, DOS process management, TSR support, etc.

What this does:

What I see as the first step : call the dos int21h class to load the DOS program, from an absolute host path.

It's a little bit better, because the rest of the modifications will be done in the dos kernel and the dos int21h handler.

The way I imagine it, we'd have a "FileLoader" class (or set of classes) that are used by both the int21handler and the ProgramExecutor.
I dunno, to me it just feels more like it belongs somewhere under the Spice86.Core.Emulator.OperatingSystem namespace rather than under the Spice86.Core.Emulator.InterruptHandlers.Dos namespace.

[maximilien-noal]

I can do that.