> the resident part of SETVER (MS-DOS 6.22) when loaded as a device > driver is 464 byte on my system. This is mainly the version table > (4Bh bytes for other stuff like the device header). The SETVER > device driver notifies the kernel about the location of the table. > The far pointer to the table is stored at 37h of the LoL [1]. > > So by _far_ smaller you mean in the order of a few bytes? As the > table gets larger, more RAM gets occupied. So this MIGHT become an > issue if one enters hundreds of additional entries to the table. But > had this ever be an issue?
I try to avoid loading things as device drivers when there is an option to load them as a TSR for lots of reasons (one of them being you can't easily tell how much and what kinds of memory it's actually using). MS-DOS SETVER requires a table of executable file names and the version number DOS is supposed to return when those executable files with those specific names are running and ask DOS what version it is. If SETVER stores the table in memory it takes a lot more than a few hundred bytes. The table doesn't necessarily be in conventional memory, but it will be somewhere. It could also do what the DOS kernel does by dividing itself into a resident and transient part with the transient part (with the table of names and versions) stored on disk and would need to open the file and read it into memory when it wanted to look up data from the table. What I'm saying about the other program I used to use is that it didn't have a table of names and versions like the MS SETVER does. You can sort of think of it like the way many anti-virus programs work. They have a list of known viruses and signatures (kind of like what MS SETVER does with a list of known programs and versions), but anti-virus programs also have a heuristic check that finds non-specific viruses. MS SETVER doesn't do a heuristic test of what it should return for the DOS version, but the other program I had only did the "heuristic" test and didn't have a fixed list. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
