SvarDOS
FreeCOM fails to load string resources
Kernel is booted from drive A:. Chances are high it has something to do with COMSPEC, as FreeCOM indicates. Additional info: no CONFIG.SYS and AUTOEXEC.BAT. It should nevertheless work, even without these files and manuall specifying COMSPEC.
Bonus exercise: System crashes if "exit" is entered at the FreeCOM (process 0) command prompt, probably because the shell terminates, which it should not.
For this to work FreeCOM had to be modified to accept the config environment stored containing COMSPEC.
For this to work FreeCOM had to be modified to accept the config environment stored containing COMSPEC.
When you wrote "had to be modified", do you mean there is a patch for this or it is still to be done? A user contacted me noting that environment variables set in dconfig.sys don't carry over to the shell if using a PC-DOS command.com which I suspect is due to the kernel not passing the environment in the usual way.
By the way I got the same FreeCOM error prompt on lDOS when the 21.4B00 or 21.4B80 call has both the environment in the parameter block and the init PSP's environment set to zero. This leads to the child PSP's environment to be set to zero as well. FreeCOM doesn't need %COMSPEC% per se, but does need the environment and its own executable pathname behind the last variable.
When you wrote "had to be modified"
Replace it by "has to" :)
SvarCOM has already implemented SOME processing of the kernel initial environment: https://github.com/SvarDOS/core/blob/2c639bddbe07560603d611f56a409a98abe586a3/svarcom/trunk/command.c#L127
From this initial environment, a new environment has to be built in order to propagate the (case-sensitive!) environment variables set via the kernels SET config.sys directive.
See also: https://github.com/SvarDOS/edrdos/issues/88 (initial environment relocated to segment 0x60 to reduce chances that it gets overwritten too soon).
I guess I just don't see what it buys us to do things this way rather than passing the environment the normal way, at least as an option. If I understand correctly, the special config environment doesn't contain the executable pathname that FreeCOM wants to locate itself.
If I understand correctly, the special config environment doesn't contain the executable pathname that FreeCOM wants to locate itself.
The config environment should include COMSPEC with absolute path as of commit db318b3c. If it does not, I made an error.
But the config environment should be processed to upper-case the variable names if it is reused by FreeCOM, I guess.
Like I wrote, FreeCOM doesn't actually need %COMSPEC% if it gets its own executable pathname in its own environment block.
From my reply to the user's bug report:
Yes, it appears that DR-DOS / dcommand (what I call its own command.com) have a special handshake to pass the dconfig environment to the shell. If a different shell is used that doesn't support this (ie, ignores it) then it will receive a zero environment segment in its own PSP and assume that it wasn't passed an environment.
I dug up all the SvarDOS EDR-DOS issues mentioning the environment and came away with a likely related one here: https://github.com/SvarDOS/edrdos/issues/55
You can follow our discussion there if you'd like. Either the kernel or the application has to be changed, albeit it may be possible to write a small wrapper tool that transfers the dconfig environment variables into your shell's environment without needing to patch the shell itself. The support added to SvarDOS's own shell, as linked by Bernd, may prove instructive to that: https://github.com/SvarDOS/core/blob/2c639bddbe07560603d611f56a409a98abe586a3/svarcom/trunk/command.c#L127
I think the current config environment should not be changed by appending the executable file name, as the EDR COMMAND.COM expects the F5 / F8 flags after the 0x1A byte. Creating a new env from the config env by the kernel and passing it to command would be better then.
Well, appending the program file name to the config env might indeed work, as 0x1a character is at offset 0xfc. So there should be plenty of space for appending the file name before it. However, if the PSP env is set to the config env seg 0x60, the shell might be temped to eventually deallocate it?!? So I guess it would be better if there were a MCB for the env.
Creating a new env from the config env by the kernel and passing it to command would be better then.
Yes, and that's exactly what happens if you put the dconfig env's segment into either the exec parameter block as the environment source or into the init PSP.
However, if the PSP env is set to the config env seg 0x60, the shell might be temped to eventually deallocate it?!? So I guess it would be better if there were a MCB for the env.
FreeCOM happens to only accept the environment that you passed to it if it is preceded by an MCB found by MCB walking, that was the problem I had in https://github.com/FDOS/freecom/pull/161
But if you just specify the dconfig env as source for 21.4B then the DOS loader will automatically allocate a new environment and copy the dconfig env's contents over.
I tried out booting lDOS flavour EDR-DOS in my more recent (2024) dosemu2, loading FreeCOM. (This is also an environment I use for lDOS testing.) It produced the error prompt as expected. https://hg.pushbx.org/ecm/edrdos/rev/fe37cc2e8824 fixes this by passing the dconfig environment to the shell.
I had to remember to put DOS=HIGH,UMB after loading the umb.sys device driver in dconfig.sys
Different questions this test turned up in https://github.com/SvarDOS/edrdos/issues/138
https://hg.pushbx.org/ecm/edrdos/rev/fe37cc2e8824 fixes this by passing the dconfig environment to the shell.
User who reported the bug that another shell (PC-DOS command.com) ignores the dconfig SET directives has replied to me that this change fixes this use case.
SvarCOM works, as EDR COMMAND does. I will also test how 4DOS handles the change, before I finally import the change.