EDR kernel spawns SvarCOM without /P flag
boeckmann opened this issue · 10 comments
After installing SvarDOS with the EDR kernel, autoexec.bat is not executed.
I guess this is because the kernel does execute command.com without /P, and no config.sys with a SHELL= line exists after installation. I manually run autoexec.bat after installation, and after a reboot everything worked. A config.sys was created with a SHELL= line.
@mateuszviste is it possible for SvarCOM to detect if it is started as first process and then unconditionally execute autoexec.bat?
is it possible for SvarCOM to detect if it is started as first process and then unconditionally execute autoexec.bat?
As I was saying in #28, SvarCOM indeed executes AUTOEXEC.BAT only when /P is being passed - that is unless /d is also present, which is used by the FD kernel to signal "skip autoexec" (F5 pressed at boot time).
Having some way to smartly imply /P would be nice. Do you know what would be the most reliable (possibly universal) way to confirm that COMMAND.COM is being executed as the initial process?
Having some way to smartly imply /P would be nice. Do you know what would be the most reliable (possibly universal) way to confirm that COMMAND.COM is being executed as the initial process?
Not right now, perhaps by inspecting if the parent PSP segment is 8?
I don't think a parent PSP can ever be 8. If such a process was entered it would overlap the PSP with the IVT. The "8" as an owner of system MCBs (SD/SC/S/RPL) is hacked into the MCBs by DOS, it doesn't come from normally allocating memory using a current PSP of "8". The initial PSP for FreeDOS is at segment 60h.
Yes, does NOT work. I made a quick test with a simple dump program spawned as command.com, and this revealed that the parent PSP was segment 0x9FE0.
I had a look at the EDR command.com source. They seem to check for the environment size to be zero. That would not work with the FreeDOS kernel in all cases, as this environment may actually not empty, like Wolf Bergheim on coincidence noted yesterday on the FreeDOS devel list:
I'm working on an article about the environment, and found something which was new to me, namely that DOS (at least MS-DOS and FreeDOS, haven't checked with DR-DOS yet) actually doesn't give the primary shell an environment of 0000h when CONFIG.SYS uses a MENU. This mini environment is used to pass the menu selections to the primary shell.
Lines 378 to 380 in 8a173d3
That is not surprising, I remember having researched this subject a bit two years ago and failed to find a method that would be generic enough so it would work on both FreeDOS and MS-DOS. EDR is just yet another corner case. It's the reason why I went with running autoexec on /P.
The more worrying thing is why your CONFIG.SYS (as generated by the SvarDOS installer) did not contain the necessary SHELL directive. I will look into this today.
The more worrying thing is why your CONFIG.SYS (as generated by the SvarDOS installer) did not contain the necessary SHELL directive.
Fixed in build 20240726
I think there's not much else to do here, unless there is some universal way to make the shell detect it's the initial process.
btw I will test the 20240726 build today and if it's stable enough I will flag it as the new "stable release" so we can then experiment with EDR on bleeding edge.
Works :)
Works :)
Thanks for confirming. So I am closing this for the time being. If one day we learn about a proper way to detect the "I am the root shell" situation then I will implement it in SvarCOM. If such way exists at all.
The current (trunk) version of SvarCOM no longer needs to be invoked with an explicit /P parameter. It assumes it is the "init" process if its environment segment is zeroed. This does not work on FreeDOS, but does work on (E)DR-DOS and MS-DOS 5.x (I did not test other versions). On FreeDOS it is a non-issue though, because FreeDOS invokes the shell with /P by default, even without a SHELL= directive in CONFIG.SYS.