On at 2022-07-31 15:49 +0800, TK Chia wrote:
Hello Jerome,
Generally, I would not include an attachment. However, this is a
tiny zip and includes the test source, build scripts and the compiled
version.
Well... I found that your ansitest.com still works with the FreeDOS 1.3
kernel + nansi.sys 4.0d. (I.e. there was no regression between FreeDOS
1.0 and 1.3.)
I took a FreeDOS 1.3 "floppy edition" boot disk image, and doctored it
so that it loads nansi.sys on startup and does not start the installer,
then ran it under QEMU. ansitest.com says "ANSI supported".
(I will try to enclose a floppy disk image once I manage to pare it down
to a small enough size...)
Are you using devload.com to load the nansi.sys driver? If so, this
might explain the failure. I found that if I use devload.com --- rather
than load the driver through fdconfig.sys --- then for some reason
nansi.sys's input handling routines are not triggered, and there is no
ESC [ y ; x R response. This would mean there is an issue in devload.com.
I haven't finished my study of DEVLOAD yet, so I cannot tell for sure.
(I started looking into it to support loading lDebug in device-driver
mode using DEVLOAD, which requires an allocation to the device that's
larger than 64 KiB. I uploaded my experimental patch [1] and also set up
a repo [2] for DEVLOAD on our hgweb server, but did not yet get around
to figuring out the specifics for some proper patches. Those will show
up in the repo if I get to them.)
However, I believe that DEVLOAD will not re-open the file handles held
by existing programs that point to the previous CON device. If NANSI
requires usage of its CON device to make the check work (eg to insert
its response string as input from the CON device), then this will not
work if you use DEVLOAD to load NANSI. DOS's config processing will
re-open all of the current (init) process's standard handles after
having finished loading device drivers.
When DOS creates a child process from an existing process then it will
duplicate the process file handles (except ones opened with the "no
inherit" flag), so that the new process will have a set of process
handles referring to the same system file handles as the parent at the
time of the child creation. That means if DEVLOAD doesn't close and
re-open (or otherwise redirect) currently open file handles to CON in
the shell, then that shell and all its child processes will continue to
refer to the prior CON device after NANSI has been loaded.
Hello Tom,
have YOU thought about using your favorite DEBUG tool to chase down
this issue?
Diagnosing this problem with debug.com turns out to be trickier than
expected, since it involves tracing the innards of int 0x21 that
debug.com also uses for its I/O...
Thank you!
To get to the actual point of me writing this mail, there are some
debuggers that do allow tracing interrupt 21h.
FreeDOS Debug has some support for this, which it detects by checking
the InDOS flag. My lDebug expands this support: If you issue the command
"r dco or= 8" then all debugger I/O afterwards is forced not to use DOS
and the debugger will not use DOS otherwise either. (Except for the Q
commands.) This might be more helpful for debugging DOS or other
interrupt 21h handlers. I/O is done using the ROM-BIOS interrupt 16h and
interrupt 10h services instead, for as long as lDebug is in its "InDOS"
condition (either the actual InDOS flag is set and/or DCO option 8 set).
lDebug also allows to do its own I/O across a serial port [3], which
drastically cuts down on the DOS calls made by the debugger as well.
However, if you specifically want to debug interrupt 21h handlers you
likely want to set the option 8 anyway, even if you use serial I/O. So
that'd be "r dco or= 4008".
The Insight debugger that I have been working on some might also allow
debugging DOS, because all its I/O is done using either the ROM-BIOS
(interrupt 16h in particular) or direct screen writes to the text-mode
video memory. However, I cannot promise this with certainty.
Another option that I didn't check yet is to use Microsoft's now free
software version of Debug that ships in the MS-DOS version 2 release.
That has a build option called SYSVER [4] which is intended to make the
debugger use the CON device directly for its I/O, instead of calling
into DOS. That is not as general as using the ROM-BIOS, but might
suffice. However, I have not yet built Microsoft's Debug with this
option enabled.
Yet another option is to use a debugger built into a virtual machine,
such as dosemu2's dosdebug. I believe DOSBox and DOSBox-X also offer
debuggers. I have heard good things about Bochs's debugger too. From my
experiences with dosemu2 dosdebug I cannot recommend it very highly
though, lDebug has a better interface. But it is able to debug at a very
low-level that lDebug cannot reach.
Regards,
ecm
[1]: https://pushbx.org/ecm/test/20220509/devload.diff
[2]: https://hg.pushbx.org/ecm/devload
[3]: https://pushbx.org/ecm/doc/ldebug.htm#interface-serial
[4]:
https://hg.pushbx.org/ecm/msdos2/file/05669dfa5edd/v2.0/source/debug/DEBUG.ASM#l32
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
