On at 2024-01-04 17:46 +0100, Bernd Böckmann via Freedos-devel wrote:
Hi Eric,
I would assume the kernel parameter is neither meant to be queried
at runtime nor is it used by a significant number of people at all.
There is no external API, but you may pull it from RAM, possibly.
No, the CONFIG block is not preserved in memory anywhere. It is loaded
at linear 602h when the kernel is being loaded in the FreeDOS load
protocol. Prior to my new exeflat format [1] a UPX-compressed kernel
would copy it to 5E2h where it would possibly survive for longer, but
this is no longer the case. The memory at 600h is re-used as the initial
PSP later.
I would only read kernel RAM directly if the kernel tells me the address, for
example by using a newly introduced FreeDOS INT 21h extension returning a
pointer to the config data and its version. Otherwise, if the address changes
for whatever reason, that would break compatibility.
There are some FreeDOS extensions on interrupt 21h function 33h
subfunctions [2], including the well-known 21.33FF for a version string
(now also supported by RxDOS and Enhanced DR-DOS). 21.33F9 seems to be
the highest unused subfunction number.
Alternatively, you could extract settings from the kernel file of the
boot drive or (better?) try and compare your view of which drive is
which to the kernel in terms of sizes and labels for local drives.
Comparing if the drive letters agree beteween DOS and FDISK should be doable.
The DPBs should provide everything that is needed, I think. But I have to
investigate this. It makes only sense doing this once after FDISK started. As
soon as any operations are performed by the user, the assignments differ anyway.
You actually want to inspect what I call the UPBs, the Unit Parameter
Blocks. These are called Drive Data Tables by the Interrupt List [3] and
by the FreeDOS kernel [4], and UDSC (Unit Descriptor?) by EDR-DOS [5].
Note that they contain two BPBs, which are actually EBPBs for
FAT32-enabled FreeDOS and EDR-DOS (probably the same for MS-DOS v7.10
too). But not so for FAT32-disabled FreeDOS.
Also, that detection thing could provide a command line way for some
"just detect and return errorlevel" mode for use in batch processing.
Or maybe that feature even already is there? :-)
Jerome parses the output of FDISK /info in his installer scripts. But a more extensive and
easier to parse query interface came into my mind previously. Something like FDISK /query
<parameter>, where <parameter> may be a bunch of supported query keys, like
(IS_EMPTY, NUM_PRIMARIES, PART_0_TYPE etc.). First I thought that its a good idea to return
them as error level. But it is not, because FDISK already uses them to return specific
error codes if something goes wrong, like failure to read a sector. So currently I think it
would be better to instead return a single value to stdout, or a list of KEY=VALUE pairs if
multiple parameters are queried. Not exactly sure it is worth the effort, because this
rules out using it in batch files without a helper tool, or I am wrong?!?
Key value pairs would be more difficult. A single string output can be
picked up using FreeCOM's SET /E however, eg:
> set /e variable=fdisk /query what-to-query
Regards,
ecm
[1]: https://github.com/FDOS/kernel/pull/78
[2]:
https://github.com/FDOS/kernel/blob/db71b1a78337e96a89b4343b8303c6b8c4e6bb14/kernel/inthndlr.c#L143
[3]: https://fd.lod.bz/rbil/interrup/dos_kernel/2f0803.html
[4]:
https://github.com/FDOS/kernel/blob/db71b1a78337e96a89b4343b8303c6b8c4e6bb14/hdr/device.h#L205
[5]: https://hg.pushbx.org/ecm/edrdos/file/465be5fcbb65/drbio/udsc.equ
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
