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.
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. > 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. > But if you ask me, a command line option for that non-default, > but POSSIBLE sort order should be enough for FDISK. Probably better than nothing, but I prefer this to be auto-detected. > I guess it could be more interesting to improve detection of whether > a disk is completely empty - no risk of damaging previous partitions > and/or boot code. Maybe improve boot code blobs offered by FDISK, too? I can update the code that gets installed into the MBR. Are there any problems with the current boot code? If one provides me with an updated code I will happily include it. > 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?!? Greetings, Bernd _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
