3 SFT entries stuck in the Low Memory Area?

[ecm-pushbx]

I found that in config.c at

kernel/kernel/config.c

Line 408 in 192cccc

sp = sp->sftt_next = KernelAlloc(sizeof(sftheader) + 3 * sizeof(sft), 'F', 0);

a table consisting of 3 SFT entries is allocated. This appears to remain in the Low Memory Area no matter what.

MS-DOS v4 and the lDOS kernel (based on the former) work well with only the 5 SFT entries that are a part of the DOSDATA segment. This may be correlated with the fact that they open the configuration file (ldos.ini or config.sys by default, like FreeDOS the names can be changed using the lDOS kernel command line) once and read the entire contents of the file into a buffer, then close the file before processing the config directives. If I recall, the FreeDOS kernel keeps the file opened.

(The FreeDOS kernel does have 5 SFT entries in the DOSDATA segment as well, and it never relocates DOSDATA. Enhanced DR-DOS only has 3 SFT entries in the DOSDATA segment, due to its larger layout for the cleaner FAT32 extensions and the additional 2 dwords for FAT+ extension per SFT entry.)

Note that it is not trivial to relocate possibly open SFT entries. In lDOS's DOSREINIT function (called initially to init DOS DS and then upon relocation of DOS DS, which always happens at some point) I specifically added code to process the sharer tables in case the sharer is already installed. This involves the sharer structure known as the Master File Table (MFT), the SFT's own "next SFT" pointer, and the sharer's lock records, all of which may point to open SFTs by a far pointer address.

I already referred to the LMA SFTs both on the freedos-devel list and in a retrocomputing stackexchange answer.

[ecm-pushbx]

Reminded of this while working on #203

[boeckmann]

Doesn't that cause problems with the config.sys CHAIN directive? If MAX_CHAINS is 5 and the files are not closed it would exceed the 8 SFT entries, wouldn't it? CHAIN directive is processed in DoConfig(2) pass, but additional FILES are allocated after that in the PostConfig() function.

Btw. CHAIN is a misleading name, as there is nothing "chained". It more resembles a call, continuing the "calling" file at the position after the chain, if I understand the code. MS-DOS does not seem to have this directive?

kernel/kernel/config.c

Line 151 in b8ef68f

#define MAX_CHAINS 5

kernel/kernel/config.c

Lines 2610 to 2630 in b8ef68f

	STATIC VOID CmdChain(BYTE * pLine)
	{
	struct CfgFile *cfg;
	int fd;
	InstallPrintf(("CHAIN: %s\n", pLine));
	if (nCurChain >= MAX_CHAINS) {
	CfgFailure(pLine);
	return;
	}
	if ((fd = open(pLine, 0)) < 0) {
	CfgFailure(pLine);
	return;
	}
	cfg = &cfgFile[nCurChain++];
	cfg->nFileDesc = nFileDesc;
	cfg->nCfgLine = nCfgLine;
	nFileDesc = fd;
	nCfgLine = 0;
	}

[ecm-pushbx]

Good catch!

I do get an error like you suggested, but I'm uncertain whether it is due to the MAX_CHAINS limit or the SFTs:

chain1 start
chain2 start
chain3 start
chain4 start
chain5 start
CONFIG.SYS error in line 2
>>>chain=chain6.ini
        ^
chain5 end
chain4 end
chain3 end
chain2 end
chain1 end

drive_c$ cat chain1.ini
chain=fdconfig.sys
echo chain1 start
chain=chain2.ini
echo chain1 end
drive_c$ cat chain2.ini
echo chain2 start
chain=chain3.ini
echo chain2 end
drive_c$

I ran this like so: boot protocol freedos cmdline 1 ldp/fdkernel.sys . config=chain1.ini - Some of my fdconfig.sys contents aren't correctly processed with the chain=fdconfig.sys directive it seems, eg the SHELL= directive.

MS-DOS does not seem to have this directive?

Correct.

[boeckmann]

Some of my fdconfig.sys contents aren't correctly processed with the chain=fdconfig.sys directive it seems, eg the SHELL= directive.

This should be a result of CHAIN being processed only in phase 2 of config.sys processing. So every directive in a "chained" config file which is not processed in phase 2 is ignored, making this somewhat inconvinient and useless. In its current form, only CHAIN, DEVICE(HIGH), ECHO, INSTALL(HIGH) and SET can be used.

Btw the carret indicating the error position is off by one. Fix pending...