On 29/04/2025 10:47, Eric Auer via Freedos-devel wrote:
The problem with SETVER style tools is their relatively large RAM
footprint, which is why CALLVER is a lot more simple, at the price
of having to be used as a wrapper for calling one app at a time.
Update: One of the posts in this thread says the resident part of
MS DOS 6 SETVER is surprisingly small in RAM, so sure, if anybody
gets bored, future FreeDOS could have an implementation of SETVER.
Consider myself nerd-sniped on this one.
The SETVER list is found in the list of lists (INT 21h, AH=52h, returned
in ES:BX) at offset 0037h as a far pointer. That fact is documented in
RBIL. What isn't documented there is the actual format of the list. Each
entry is in the following format with no gaps between (checked with
MS-DOS 6.22 and 7.10):
- 1 byte for the name length (a value of 0 terminates the list right
here and this is the last byte in that case)
- That many bytes for the name, upper-cased
- 1 byte for the major version
- 1 byte for the minor version
The MS-DOS 7.10 list as posted earlier packs down to 692 bytes. To
compare, a 98SE VM I have takes up 730 bytes, and truncating the list to
where MS-DOS 6.22 ends packs down to 408 bytes. Either way, we'll use
that figure of 692 bytes.
I had a go at implementing a program to read a command line argument,
read through a list built into the program, and then print the version
in x.yy format (or 0.00 if it's not in the list). My asm code adds up to
107 bytes, which includes uppercasing the file name (~24 bytes), but
also includes some things that might not be relevant including skipping
leading whitespace in the command line (~8 bytes) and printing the
version (~29 bytes).
With the 692-byte list, this gives us 799 bytes. Although with the
408-byte list, this gives us 515 bytes, higher than the 464 bytes of
overhead expected.
Something to note is that the SETVER list tends to be at an offset of
004Bh (at least for MS-DOS 7.10), 75 bytes into the memory block, so
already there's extra overhead in the "reference implementation". We
probably don't need to do it this way.
Anyway, if someone's keen and able... it's probably not going to be
bigger than a KB resident. The most painful part of it is probably going
to be the challenge of making a tool to manipulate the list. Otherwise,
the list is pretty easy to traverse.
- Ben R
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
