Robert recently asked me to help figure out an incompatibility where Dos Navigator would be unable to execute programs when run on SvarCOM as the shell. Some details are provided in the bug report. Read on for an overview of how we debugged this.

My first suggestion upon reading the initial problem description:

in lDebug you can use install indos then bp new ptr ri21p when ax == 4B00

you can also check with dirml 21 who has hooked int 21h. shouldn't be svarcom but who knows

hmm possibly DN sends a "%comspec% /c command" run to 21.4B00

as in comspec as ds:dx→ and " /c command" as parameter line

that would explain how svarcom is involved

Next, rr shared a patch that would replace Carriage Returns by NUL bytes in the "sanitize separators into spaces" loop of SvarCOM. Studying the Dos Navigator sources, we both found where it calls the shell.

in this case I would examine the command line. for that you need to hook 21.4B00 and when the call is coming from there check the parameter block

the command line in the parameter block is copied 1:1 by dos to psp:80h

so svarcom should know how long the command is and at the right spot there should be a CR

00h 0Dh is an empty line

so the counter at address byte [psp:80h] should not include the CR

if the CR is included by it then it's an error in dn. albeit svarcom of course could fix / work around that

that's just the first idea that I have. if it fits, hurray. if not we are smarter as well

To inspect the command line, I suggested a string of lDebug commands:

ldebug
tsr
install indos
bp new ptr ri21p when ax == 4B00
g

then with dm and r segment [ss:sp] check whether you are in dn. or also d ds:dx look whether it contains your comspec. if no, g. if yes, dw es:bx and d ptr [es:bx + 2]

r segment [ss:sp] . is a little more practical

skips the prompt for a new value

A few minutes later I provided a more involved lDebug scriptlet:

d segment [es:bx + 2]:word [es:bx + 2] + 1 length byte [ptr [es:bx + 2]] + 1 should show you the command line. last dumped byte should be a CR, before that no CRs

just tried it and it also works

Next rr noticed he had to skip one call to service 4B00h that presumably originated in SvarCOM loading its transient portion. Continuing with a g command then running Dos Navigator did the trick. Upon trying to execute a program from DN, the breakpoint was hit. My long command proved most useful:

I concluded this part of the debugging with a statement regarding this result:

as expected. it writes two CR, one at the expected location and one before

freecom and ms-dos presumably use only the CR as a terminator

svarcom I assume uses the length byte to find and overwrite the expected (first) CR with a NUL

The remainder is just inspection of how Dos Navigator builds its incorrect command line, and various attempts at fixing it. Three workarounds are depicted in the bug report linked above.