Hallo Herr C. Masloch, am Sonntag, 31. Juli 2022 um 22:25 schrieben Sie:
> 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. your analysis seems to be correct. at least after test.bat devload ansitest.com CTTY NUL CTTY CON ansitest reports ANSI detected of course DEVLOAD could borrow the code from CTTY. but: how can DEVLOAD detect that STDIN is indeed CON, and not COM1 Tom _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
