Hello tom ehlert,
On at 2022-08-01 15:11 +0200, tom ehlert wrote:
> Hallo Herr C. Masloch,
> am Sonntag, 31. Juli 2022 um 22:25 schrieben Sie:
I would appreciate if you did not refer to me wrongly.
>> 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
It would have to peek into the SFT entries for system file handles
pointing to character devices, matching the name "CON".
On at 2022-08-01 16:05 +0200, tom ehlert wrote:
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
in addition: after exiting from DEVLOAD, the next program started will
get the STDIN/STDOUT/STDERR handles as duplicates from COMMAND.COM
so it seems DEVLOAD would have to change the handle of command.com,
not it's own copy. is that true?
Yes, it is true. That's what I was referring to by "then that shell and
all its child processes will continue to refer to the prior CON device".
DEVLOAD should look up the process handles at least of its immediate
parent process (if not other processes too), map them to system file
handles, check for a handle opened to a character device and a name
match to what was loaded, then probably just patch that SFT to refer to
the new device.
If we do patch the SFT as opposed to re-opening the new character device
then we wouldn't have to go the process handle route at all, we can just
intercept all currently opened character device system file handles with
a matching name.
while it's obviously possible as CTLOAD does this, it seems to be
nontrivial.
It's another bit that depends on DOS internals, much like what DEVLOAD
already needs to do to load block devices and create the corresponding
DPBs and fill the CDS entries.
(Something else that DEVLOAD could be better at, I believe when it finds
*one* unused CDS entry it can load multiple block devices (or one block
device with multiple units) and enter all loaded block units into
consecutive CDS entries starting from the one available CDS entry that
it detected. If any of the subsequent entries weren't unused, bad luck.)
Regards,
ecm
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
