SvarDOS
DOS DS reinit questions: Sharer jump table and SFT references?
In EDR-DOS, the DOS DS is initialised at a high address in the Low Memory Area and later relocated either to the start of available memory or to the UMA. This relocation happens after INSTALL= time but before INSTALLLAST= time. The dos_init pointer is advanced by 3 bytes and then later it is called to re-init the DOS DS after the relocation.
In a retrocomputing stackexchange comment I noticed that lDOS's DOSREINIT function should take care to relocate SFT references. (In lDOS / MS-DOS / FreeDOS, the first 5 SFT entries live at DOSDATA:00CCh. In EDR-DOS due to the SFT layout extension, only 3 entries live there.)
Specifically, if the sharer is installed using INSTALL= then in the sharer and within SFTs, pointers to the first 5 SFTs could exist at the time DOSREINIT is called to relocate the DOS DS.
In EDR-DOS, the re-init seems to be done by jumping to the second DOS entrypoint called "PCMODE Re Init Entry". This branches to the "pcmode_init2" function. Much like current lDOS, this does not relocate references to the SFTs. Now here's the kicker: it re-initialises the sharer jump table -- without regard to what it contains. So if you install a (compatible) sharer using INSTALL=, it seems like its entry pointers will be corrupted here because this code doesn't check that the pointers still point into the DOS DS.
lDOS doesn't have this problem because its sharer jump table's default entries point into the DOSENTRY segment where they relocate to the DOSCODE segment. So DOSREINIT never has to relocate the sharer table contents, nor does anyone else have to.
Homework: Does EDR-DOS indeed crash if the DR-DOS sharer is installed using INSTALL= ?
Homework: Does EDR-DOS indeed crash if the DR-DOS sharer is installed using INSTALL= ?
Installing https://pushbx.org/ecm/download/edrdos/share.zip (file from the defunct DR-DOS/OpenDOS Enhancement Project) using INSTALL= does indeed crash current lDOS flavour EDR-DOS, whereas using INSTALLLAST= or running it from the command prompt don't crash.
Fixed in https://hg.pushbx.org/ecm/edrdos/rev/6c174e5361fb
Rather than point the table to different entrypoints like lDOS I simply check that the segments are still equal to the old DOS DS, and relocate them only if they are.
lDOS's DOSREINIT now scans for sharer MFTs, the SFTs linked to them, and the sharer lock records to relocate all possible references to SFTs moved with the DOS DS: https://hg.pushbx.org/ecm/msdos4/rev/1c9856ddf574
I don't know enough about the DR-DOS sharer's table formats to do the same for EDR-DOS. Would have to study the sharer, much like for evaluating its FAT32 compatibility.