On at 2022-07-31 22:44 +0200, Eric Auer wrote:
Hi!
(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] ...
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 ... 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.
Very interesting reasoning :-)
I verified in the NANSI sources that it stuffs its responses into the
reads/readaheads done to the CON device (not into the interrupt 16h
buffer). So that part of my story holds up.
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.
Good catch. Your patch does not seem to address that yet, though?
Yes, as I intended to communicate with the separate parenthetical
paragraph, and the fact that the patch is in a directory named after the
early-May date 2022-05-09, this patch only addresses loading lDebug
where the unpatched DEVLOAD fails.
Instead, it introduces multiple int3 calls (bad idea for any app
on disk, breakpoints should only be inserted dynamically in RAM)
As I wrote, it is an experimental patch. Parts of the experiment
required breaking in specific places to verify things were working as
expected. So therefore I left in those breakpoints, because it is not
meant to be a "production" quality contribution yet.
and circumvents the deliberate 64k driver size limit. Although I
do not remember WHY the limit was there. Maybe compatibility?
Yes, as you commented in the source [1], "clipping the value to 64k for
now, feels more compatible". However, this particular limit makes it so
lDebug can never load, because it is a nice application which checks the
limit passed by the loader instead of ignorantly allocating whatever
amount of memory it desires. So it may be "more compatible" for some
applications, but it makes this INcompatible with others. Albeit there
is an idea, if I finish the proper patch we could add a switch to
DEVLOAD to fall back to the "maximum below 64 KiB" allocation, just in
case this is actually ever needed.
You may also notice the first and last hunks of the experimental patch.
I found that DEVLOAD didn't properly initialise and process its
allocation size variables. The first hunk is for initialising the word
[EndSeg] variable, which without this was never written before calling
the device driver's initialisation. The last hunk I'm not quite sure
about but I believe I found that it didn't do what it was supposed to
without the patch.
As I wrote, it is all experimental and I would have to test and confirm
the logic to finish it properly, either with the same exact changes or
perhaps better ones.
Regards,
ecm
[1]: https://hg.pushbx.org/ecm/devload/file/b10d4fe6d877/devload.asm#l1170
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
