FreeCOM memory usage

We've long recognized that FreeCOM (our shell) is a bit of a memory pig. The following discussion was posted to the FreeDOS mailing list about what we might do about it:

Brian E. Reifsnyder writes:

I just finished testing a patch I made, for the kernel, that unloads FreeCOM when exe files are loaded. (Due to the smaller size of com files, FreeCOM is not unloaded.) Once the exe file terminates, FreeCOM is then re-loaded and executed. This process increases the free conventional memory from 436K to 553K! The problem, as you probably already realized, is that FreeCOM asks for the time and date and needs the environment re-loaded. Do you have any suggestions as how to fix this problem? I have a suspicion that FreeCOM may need to be modified to handle such a strategy.

Tone replies:

What needs to happen is that FreeCOM needs to be rewritten as a two part program, like COMMAND.COM. The resident portion, relatively small, can keep track of the environment and such, and the transient portion, which downfills from 640K can contain the code for the internal command set. Undocumented DOS has an example of relocatable code, as used for DEVLOAD.COM (CTLOAD.COM) if you are interested.

In the end, we did something like this, with a two-part executable (one to act as the shell, the other to launch programs).

Owen Rudge also responds with this helpful link:

Spawno at lets you swap the calling program out to XMS, EMS, disk or raw extended memory, and there is only about a 1K stub left in memory. This could be useful for FreeCOM.

The file RBROWN.TXT included with the library says:

A replacement for the Turbo C and Microsoft C spawn..() functions
which swaps the current program to disk, EMS, XMS, or raw extended
memory while the spawned program executes, leaving less than 300
bytes in memory.  Also includes a variant for Turbo Pascal v4.0 or
Current version: SPWNO413 (v4.13 12/12/92)
Price: libraries free, full source code $100.

There is an archive included with this one called SOURCE.ZIP that contains the source. However, there are no mentions of GNU GPL or the GNU Library GPL or whatever it's called, so it doesn't look as if we can use it.

Steffen Kaiser (FreeCOM maintainer) gives this answer:

spawno won't be integrated into FreeCOM, because you have no control over the portions that are left in memory. Also, there is the potentional problem that the 6 or 10 hooked (by the C startup code) interrupts are triggered and may call a library funtion. The C library is linked to the end of the program (most of the time) and has been swapped out therefore; the same applies to the data segment.