Hello,

I am working on a shell that would replace COMMAND.COM and I wonder: is
there any way I can figure out where my shell is, once it is executed
by the MS-DOS kernel?

By default MS-DOS launches whatever it finds at [BOOTDRV]:\COMMAND.COM.
This situation is easy, but there is also the possibility that the shell
was configured through a "SHELL" or "SHELLHIGH" CONFIG.SYS directive: SHELL=X:\EXOTIC\PATH\CUSTOM.COM

I am unable to find a way to discover the above path. Any ideas if this
is feasible at all? I went through RBIL but with no luck so far.

The environment contains the full path/name of the executed program,
but this does not apply to process 0, as the MS-DOS kernel does not
allocate any environment for it (env segment in PSP = 0x0000).

Mateusz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mateusz Viste wrote:

I am working on a shell that would replace COMMAND.COM and I wonder: is
there any way I can figure out where my shell is, once it is executed
by the MS-DOS kernel?

By default MS-DOS launches whatever it finds at [BOOTDRV]:\COMMAND.COM.
This situation is easy, but there is also the possibility that the shell
was configured through a "SHELL" or "SHELLHIGH" CONFIG.SYS directive: SHELL=X:\EXOTIC\PATH\CUSTOM.COM

I am unable to find a way to discover the above path. Any ideas if this
is feasible at all? I went through RBIL but with no luck so far.

The environment contains the full path/name of the executed program,
but this does not apply to process 0, as the MS-DOS kernel does not
allocate any environment for it (env segment in PSP = 0x0000).

Just throwing out the obvious here... have you considered just looking
through config.sys for the shell?

--
"Armies with ammo" comes before "damsels in distress" alphabetically.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

2021-11-16 at 16:54 -0000, Auric__ wrote:

Mateusz Viste wrote:

I am working on a shell that would replace COMMAND.COM and I
wonder: is there any way I can figure out where my shell is, once
it is executed by the MS-DOS kernel?

By default MS-DOS launches whatever it finds at
[BOOTDRV]:\COMMAND.COM. This situation is easy, but there is also
the possibility that the shell was configured through a "SHELL" or "SHELLHIGH" CONFIG.SYS directive: SHELL=X:\EXOTIC\PATH\CUSTOM.COM

I am unable to find a way to discover the above path. Any ideas if
this is feasible at all? I went through RBIL but with no luck so
far.

The environment contains the full path/name of the executed program,
but this does not apply to process 0, as the MS-DOS kernel does not allocate any environment for it (env segment in PSP = 0x0000).

Just throwing out the obvious here... have you considered just
looking through config.sys for the shell?

Yes, of course, but this seemingly obvious solution is extremely complex
and unreliable.

Such parser would have not only to look for SHELL or SHELLHIGH
directives in CONFIG.SYS, but also understand the logic behind
conditional instructions (config menus), with possible dialect
variations between DOS versions. There are also DOSes that use a file
named differently than "CONFIG.SYS". And then, there's also the
possibility that the user simply skipped the SHELL directive (F5/F8) or
that the shell has been entered by hand at boot time (some DOSes ask
for the command interpreter path if the default file cannot be found).

Mateusz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mateusz Viste wrote:

2021-11-16 at 16:54 -0000, Auric__ wrote:

Mateusz Viste wrote:

I am working on a shell that would replace COMMAND.COM and I
wonder: is there any way I can figure out where my shell is, once
it is executed by the MS-DOS kernel?

By default MS-DOS launches whatever it finds at
[BOOTDRV]:\COMMAND.COM. This situation is easy, but there is also
the possibility that the shell was configured through a "SHELL" or
"SHELLHIGH" CONFIG.SYS directive: SHELL=X:\EXOTIC\PATH\CUSTOM.COM

I am unable to find a way to discover the above path. Any ideas if
this is feasible at all? I went through RBIL but with no luck so
far.

The environment contains the full path/name of the executed program,
but this does not apply to process 0, as the MS-DOS kernel does not
allocate any environment for it (env segment in PSP = 0x0000).

Just throwing out the obvious here... have you considered just
looking through config.sys for the shell?

Yes, of course, but this seemingly obvious solution is extremely complex
and unreliable.

Such parser would have not only to look for SHELL or SHELLHIGH
directives in CONFIG.SYS, but also understand the logic behind
conditional instructions (config menus), with possible dialect
variations between DOS versions. There are also DOSes that use a file
named differently than "CONFIG.SYS". And then, there's also the
possibility that the user simply skipped the SHELL directive (F5/F8) or
that the shell has been entered by hand at boot time (some DOSes ask
for the command interpreter path if the default file cannot be found).

Well...

The MS-DOS 2.0 source code is on Github, where you might look into the file SYSINIT.ASM, available here:

https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/SYSINIT.ASM

AFAIK, this was the first time DOS could use external shells. I don't know
if it's at all relevant to modern DOS, but it's a start.

Alternately, if you can find a copy of the MS-DOS 6 source code (which was leaked to the internet some time back), you might want to look at these
files:
BIOS\CONFIG.INC
BIOS\SYSCONF.ASM
BIOS\SYSINIT1.ASM
BIOS\SYSINIT2.ASM
Just sayin'. SYSCONF.ASM has this comment which seems *very* relevant:

HACK: when 4DOS.COM is the shell and it doesn't have an environment from
which to obtain its original program name, it grovels through all of
memory to find the filename that was used to exec it; it wants to find
the SHELL= line in the in-memory copy of CONFIG.SYS, and it knows that
sysinit converts the SHELL= keyword to an 'S', so it expects to find an 'S'
immediately before the filename, but since we are now storing line # info
in the config.sys memory image, 4DOS fails to find the 'S' in the right
spot.
So, on the final pass of CONFIG.SYS, copy the command code (eg, 'S')
over the line number info, since we no longer need that info anyway. This
relies on the fact that getchr leaves ES:SI pointing to the last byte
retrieved.

As for other flavors of DOS, most of them are open source, so I think it
would be worth it to download some source code and search for "shell".

--
Money is truthful. If a man speaks of his honor, make him pay cash.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

2021-11-16 at 18:49 -0000, Auric__ wrote:

The MS-DOS 2.0 source code is on Github, where you might look into
the file SYSINIT.ASM, available here:

https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/SYSINIT.ASM

Actually I did glance at the MS-DOS 2.0 code already, and my
understanding is that they didn't even try addressing this, just relied
on COMSPEC (if defined, either through SET or by feeding it as an
argument to command.com), and if no COMSPEC then using the default
location.

That sounds okay when it's MS that does it, because it's their OS, but
an alternative shell does not have this luxury.

HACK: when 4DOS.COM is the shell and it doesn't have an environment
from which to obtain its original program name, it grovels through
all of memory to find the filename that was used to exec it; it
wants to find the SHELL= line in the in-memory copy of CONFIG.SYS,
and it knows that sysinit converts the SHELL= keyword to an 'S', so
it expects to find an 'S' immediately before the filename, but since
we are now storing line # info in the config.sys memory image, 4DOS
fails to find the 'S' in the right spot.
So, on the final pass of CONFIG.SYS, copy the command code (eg, 'S')
over the line number info, since we no longer need that info anyway.
This relies on the fact that getchr leaves ES:SI pointing to the
last byte retrieved.

That is very interesting indeed, thanks for sharing! This at least
confirms that there is no "clean" way to do what I wanted... So I will
probably give up on that. MS compatibility was only a bonus, my primary
target is working with the DOS-C kernel, and there I do not have any
such problems.

Nonetheless, thank you for your kind research.

As for other flavors of DOS, most of them are open source, so I think
it would be worth it to download some source code and search for
"shell".

Under DOS-C it is a no-brainer: the kernel actually allocates a tiny
(96 bytes) environment and passes it to COMMAND.COM. There, the entire
path is present.

Mateusz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 16 Nov 2021 10:44:16 +0100, Mateusz Viste wrote:

Hello,

I am working on a shell that would replace COMMAND.COM and I wonder: is
there any way I can figure out where my shell is, once it is executed
by the MS-DOS kernel?

By default MS-DOS launches whatever it finds at [BOOTDRV]:\COMMAND.COM.
This situation is easy, but there is also the possibility that the shell
was configured through a "SHELL" or "SHELLHIGH" CONFIG.SYS directive: SHELL=X:\EXOTIC\PATH\CUSTOM.COM

I am unable to find a way to discover the above path. Any ideas if this
is feasible at all? I went through RBIL but with no luck so far.

The environment contains the full path/name of the executed program,
but this does not apply to process 0, as the MS-DOS kernel does not
allocate any environment for it (env segment in PSP = 0x0000).

Mateusz

You may want to walk the MCB chain to find the master environment block.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

2021-11-17 at 08:23 +0700, JJ wrote:

On Tue, 16 Nov 2021 10:44:16 +0100, Mateusz Viste wrote:

Hello,

I am working on a shell that would replace COMMAND.COM and I
wonder: is there any way I can figure out where my shell is, once
it is executed by the MS-DOS kernel?

By default MS-DOS launches whatever it finds at
[BOOTDRV]:\COMMAND.COM. This situation is easy, but there is also
the possibility that the shell was configured through a "SHELL" or "SHELLHIGH" CONFIG.SYS directive: SHELL=X:\EXOTIC\PATH\CUSTOM.COM

I am unable to find a way to discover the above path. Any ideas if
this is feasible at all? I went through RBIL but with no luck so
far.

The environment contains the full path/name of the executed program,
but this does not apply to process 0, as the MS-DOS kernel does not allocate any environment for it (env segment in PSP = 0x0000).

Mateusz

You may want to walk the MCB chain to find the master environment
block.

No, because such an environment simply does not exists at the time
process 0 is being loaded.

Mateusz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)