Quote:
Originally Posted by Photon
If specialized hunk types were added after 1.3, they will either be absolutely required for the correct functioning of the program or not. If not, they must still be parsed correctly. If so, they can return an error message on an OS version not supporting it, but detection must determine support.
|
So you want to be able to load a program under eg. KS1.3 which has a hunk format the OS doesn't recognize, but which
might run if it could be loaded. If it can't be loaded then an error should be returned that identifies why.
IOW, you want a replacement for LoadSeg which supports hunk formats that the OS it's running under may not, thus allowing users to
attempt to run programs that were not designed for that OS (or at least have a incompatible hunk format and so have never been tested on that OS).
I guess there could be a use for that, but I suspect the vast majority of programs that don't have a compatible hunk format won't be compatible for other reasons too.
I faced a sort of similar situation with my disassembler, which I wanted to be compatible with KS1.3 to permit disassembling
any program on older machines. I needed a custom LoadSeg anyway to retain the relocation information, so I just took some published code and modified it to suit. Then I discovered that a few programs use drel32 and reloc32short, so I added code to handle them. I also added a read cache to speed up parsing symbol hunks (which can slow down loading a lot because every entry has to be parsed individually to get to the end of the hunk). To date I have not found any program that won't load, though I don't load overlay hunks because my disassembler doesn't know what to do with them (one day, maybe...).
My code is no good for your application, but
this might:-
https://sintonen.fi/src/loadseg/LS.asm