Comment in source code:
/*
* some tools expect this interrupt to have the same segment as the
* command.com PSP, but FreeCOM is an exe...
*/
I don't know if your build tools can handle this yet; but I've come across an ingenious way to construct the EXE headers so this works.
- Adjust link order so the interrupt handler is fairly early in the file.
- Set the start address to have a segment of FFE0h.
This works because of the 16 bit arithmetic in the DOS kernel. The segment offset overflows and you end up entering the program with CS=DS=ES. I tried this with the DOS 5 kernel. It does in fact work, it's not just a FreeDOS thing.
In theory even if your tools can't do this, you have all the fixup addresses in the EXE header so it should be possible edit all the code fixups that refer to the code segment at startup. But that won't work if you have any global variables initialized with function pointers.
[I came across this comment looking for documentation on CMDLINE environment variable. It's shockingly poorly documented.]
Comment in source code:
I don't know if your build tools can handle this yet; but I've come across an ingenious way to construct the EXE headers so this works.
This works because of the 16 bit arithmetic in the DOS kernel. The segment offset overflows and you end up entering the program with CS=DS=ES. I tried this with the DOS 5 kernel. It does in fact work, it's not just a FreeDOS thing.
In theory even if your tools can't do this, you have all the fixup addresses in the EXE header so it should be possible edit all the code fixups that refer to the code segment at startup. But that won't work if you have any global variables initialized with function pointers.
[I came across this comment looking for documentation on CMDLINE environment variable. It's shockingly poorly documented.]