Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+====== Remote debugging of SvarCOM and Dos Navigator incompatibility ======
+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 [[https://github.com/SvarDOS/bugz/issues/67|in the bug report]].
+Read on for an overview of how we debugged this.
+===== =====
+My first suggestion upon reading the initial problem description:
+<blockquote>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</blockquote>
+<blockquote>as in comspec as ds:dx-> and " /c command" as parameter line
+that would explain how svarcom is involved</blockquote>
+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 [[https://github.com/maximmasiutin/Dos-Navigator/blob/cc294560cd3ef90fe39b0ac16a3d1791e41c951d/DN.ASM#L195|where it calls the shell]].
+<blockquote>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
+h 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</blockquote>
+To inspect the command line, I suggested a string of lDebug commands:
+<blockquote>
+<code>ldebug
+tsr
+install indos
+bp new ptr ri21p when ax == 4B00
+g</code>
+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</blockquote>
+A few minutes later I provided a more involved lDebug scriptlet:
+<blockquote>''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</blockquote>
+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:
+{{:blog:pushbx:2024:20240211_175538653_030c.png|}}
+I concluded this part of the debugging with a statement regarding this result:
+<blockquote>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</blockquote>
+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.
+{{tag>svardos svarcom dn ldebug}}
+~~DISCUSSION~~

pushbx wiki

User Tools

Site Tools

Differences

Page Tools