Add support for 'ver /r'
mateuszviste ver /r displays the DOS kernel version and an information about where in memory the DOS kernel is loaded.
the kernel version is already displayed by SvarCOM, even without /r.
any idea how to know where DOS is (UMA/HMA/LOW/ROM) ?
Reply To mateuszviste
ver /r displays the DOS kernel version and an information about where in memory the DOS kernel is loaded.
Nice summary.
the kernel version is already displayed by SvarCOM, even without /r.
Yes.
any idea how to know where DOS is (UMA/HMA/LOW/ROM) ?
For the ROM part you can use the version flag: https://fd.lod.bz/rbil/interrup/dos_kernel/2130.html
INT 21 - DOS 2+ - GET DOS VERSION
AH = 30h
---DOS 5+ ---
AL = what to return in BH
00h OEM number (see #01394)
01h version flag
Return: AL = major version number (00h if DOS 1.x)
AH = minor version number
BL:CX = 24-bit user serial number (most versions do not use this)
---if DOS <5 or AL=00h---
BH = MS-DOS OEM number (see #01394)
---if DOS 5+ and AL=01h---
BH = version flag
bit 3: DOS is in ROM
other: reserved (0)
The version flag is also supported by this call: https://fd.lod.bz/rbil/interrup/dos_kernel/213306.html
INT 21 - DOS 5+ - GET TRUE VERSION NUMBER
AX = 3306h
Return: BL = major version
BH = minor version
DL = revision (bits 2-0, all others 0)
DH = version flags
bit 3: DOS is in ROM
bit 4: DOS is in HMA
AL = FFh if true DOS version < 5.0
As both bits could be set, I wonder, if there really exists a DOS kernel in ROM and HMA at the same time.
By the way: Recent FreeCOM doesn't support displaying this info, although it supports '/r'.
As both bits could be set, I wonder, if there really exists a DOS kernel in ROM and HMA at the same time.
Based on my FAKECI I hacked together an Int21.3306 faker.
When both bits are set, MS-DOS 6.22 command.com prints 'DOS is in ROM'. It doesn't seem to check bit 4 anymore after.
It probably does something like this:
printf("DOS is in ");
switch(dosVersionFlag) {
case 8:
printf("ROM\n");
return;
case 16:
printf("HMA\n");
return;
default:
printf("low memory\n");
return;
}
Code above is wrong.
Returning 'DOS_IN_ROM or DOS_IN_HMA or 32' in my Int21h handler will still show 'DOS is in ROM'. So, command.com checks for single bits.
About the DOS revision: 0 = Revision A, 1 = Revision B, ..., 7 = Revision H.
Although according to RBIL only bits 2-0 are used for returning the revision, you can set bit 3 (dl = 8) and MS-DOS 6.22 command.com will happily print 'Revision I'. Revision Z is 25 or 0x19 (= 'Z'-'A').
To the max: dl = 255 -> 'Revision *' :-D
So, just add 'A' (0x41) to DL in order to get the revision for displaying for max compatibility with MS-DOS 6.22.
mateuszviste implemented in revision 1056
Now, that SvarCOM uses Int21.3306, we should implement a DOS version check on start.
Quoting 'SvarCOM is a shell interpreter for DOS kernels compatible with MS-DOS 5+', this check should exit SvarCOM, if it detects, via Int21.30, a DOS version below 5.
I also don't like to hide 'ver/r' from the help screen.
Maybe we can also rename '/about' to '/a' and '/dbg' to '/d' (like for MEM).
BTW, FreeCOM uses:
Displays the FreeDOS command shell version and other information. VER [/R] [/W] [/D] [/C] /R Shows kernel version and other information. /W FreeDOS command shell warranty. /D FreeDOS command shell redistribution information. /C FreeDOS command shell contributors.
mateuszviste ver/r is not hidden, it simply does not exist. ver always displays all information, and ignores arguments other than /about and /dbg.
Reply To mateuszviste
ver/r is not hidden, it simply does not exist. ver always displays all information, and ignores arguments other than /about and /dbg.
You are right. I didn't look at the actual code.
It confused me, that FreeCOM reports DOS 5.0 on my Windows XP, when SvarCOM reports DOS 5.50.
So, I added displaying both versions:
DOS kernel version 5.0 True version 5.50 Revision A DOS is in HMA SvarCOM shell ver 2022.3
Or:
DOS kernel version 3.30 SvarCOM shell ver 2022.3
Or should SvarCOM call Int21.3306 any time, but check AL on return: AL = FFh if true DOS version < 5.0 -- Need to test this...
mateuszviste Reply To bttr
It confused me, that FreeCOM reports DOS 5.0 on my Windows XP, when SvarCOM reports DOS 5.50.
So, I added displaying both versions: {{{ DOS kernel version 5.0 True version 5.50 Revision A DOS is in HMA SvarCOM shell ver 2022.3 }}}
This, on the other hand, might be confusing to users. Isn't this the described FreeCOM behavior simply a bug?
mateuszviste also, I'm not 100% that the if (ver >= 5) makes sense. Isn't it possible that DOS reports some ver 3.3 or so just because it was told to do that by some SETVER-spoofing directive? besides, on a pre-5 DOS chances are there is a lot of other things that will break anyway..
Reply To mateuszviste
Reply To bttr
It confused me, that FreeCOM reports DOS 5.0 on my Windows XP, when SvarCOM reports DOS 5.50.
So, I added displaying both versions: {{{ DOS kernel version 5.0 True version 5.50 Revision A DOS is in HMA SvarCOM shell ver 2022.3 }}}This, on the other hand, might be confusing to users. Isn't this the described FreeCOM behavior simply a bug?
Why would this confuse users? We now display the same version as FreeCOM. Plus the true version.
I don't think it's bug in FreeCOM. It just behaves like MS command.com.
Reply To mateuszviste
also, I'm not 100% that the if (ver >= 5) makes sense. Isn't it possible that DOS reports some ver 3.3 or so just because it was told to do that by some SETVER-spoofing directive?
I now rely on AL instead of 'ver'.
besides, on a pre-5 DOS chances are there is a lot of other things that will break anyway..
If you know this, why does SvarCOM not do any version checking?
mateuszviste Reply To bttr
Why would this confuse users? We now display the same version as FreeCOM. Plus the true version.
I don't know if typical (non-power) users are familiar with the fake/true version business. It looks a little odd to have one version displayed, only to have a different version displayed later as "true". Not that it bothers me, I'm just wondering what a normal human will think out of it.
If you know this, why does SvarCOM not do any version checking?
SvarCOM is the SvarDOS command.com shell and requirements are documented. If users try to run it on some prehistoric microsoft kernels then, well - the joke's on them.
BTW It would be nicer to merge the two _asm blocks into one, saves a couple of push/pops. And it would also allow to display only a single version if both "true" and "normal" are the same, so at least in the common case (SvarDOS being used) users won't have any chance for confusion.
Reply To mateuszviste
Reply To bttr
Why would this confuse users? We now display the same version as FreeCOM. Plus the true version.
I don't know if typical (non-power) users are familiar with the fake/true version business. It looks a little odd to have one version displayed, only to have a different version displayed later as "true". Not that it bothers me, I'm just wondering what a normal human will think out of it.
Normal human will probably never use 'ver'. ;-)
If you know this, why does SvarCOM not do any version checking?
SvarCOM is the SvarDOS command.com shell and requirements are documented. If users try to run it on some prehistoric microsoft kernels then, well - the joke's on them. BTW It would be nicer to merge the two _asm blocks into one, saves a couple of push/pops. And it would also allow to display only a single version if both "true" and "normal" are the same, so at least in the common case (SvarDOS being used) users won't have any chance for confusion.
Will think about that and check my skills and motivation. INFOPLUS's still waiting... :-D
SvarCOM could also report it this way:
DOS kernel version 6.22 (true version 7.10)
But probably not better for understanding.
mateuszviste Reply To bttr
SvarCOM could also report it this way: {{{ DOS kernel version 6.22 (true version 7.10) }}} But probably not better for understanding.
I had the same thought, and I think it would be actually much clearer. Well, not clearer for the "true/not true" business, but clearer for indicating what the versions relates to (DOS kernel, SvarCOM, something else...).
mateuszviste committed a simple change so truename is on the same line + displayed only if different than the "normal" version.
I have also removed the "rc != 1" check, as it seems possible that the FD kernel would advertise such rc eventually... maybe there's a better method to detect DRDOS if you really think it's a problem?
committed a simple change so truename is on the same line + displayed only if different than the "normal" version.
Your first intention was to remove some pushes/pops. But you introduced two additional variables.
Is it now really better in terms of code size or readability? ;-)
I have also removed the "rc != 1" check, as it seems possible that the FD kernel would advertise such rc eventually...
'rc' var is still declared/defined, but never evaluated. :-D
maybe there's a better method to detect DRDOS if you really think it's a problem?
I'm not sure, what will happen on DR DOS 5&6, because this call is not supported there. You will probably get a '(true version xx.xx)' display.
Checking 'rc' was the easiest way to workaround this DR DOS bug.
mateuszviste Reply To bttr
Your first intention was to remove some pushes/pops. But you introduced two additional variables. Is it now really better in terms of code size or readability? ;-)
It's a functional improvement: not displaying confusing "version is ... true version is..." when both are the same.
'rc' var is still declared/defined, but never evaluated. :-D
oops!
maybe there's a better method to detect DRDOS if you really think it's a problem?
I'm not sure, what will happen on DR DOS 5&6, because this call is not supported there. You will probably get a '(true version xx.xx)' display.
Checking 'rc' was the easiest way to workaround this DR DOS bug.
According to RBIL DR-DOS sets CF on unsupported function calls, so I changed the code to look at that. Didn't test it, so fingers crossed.
I did some testing:
pcdos-2.00
----------
hangs on startup; pce-ibmpc displays invalid opcode
Rating:
We don't care. ("SvarCOM is the SvarDOS command.com shell and requirements are
documented. If users try to run it on some prehistoric microsoft kernels then,
well - the joke's on them.")
pcdos-3.30
----------
SvarCOM output:
DOS kernel version 3.30
Revision A
Rating:
'Revision A' should not be displayed, because it's not supported by DOS < 5.
msdos-3.30a
-----------
SvarCOM output:
DOS kernel version 3.30
Revision A
Rating:
'Revision A' should not be displayed, because it's not supported by DOS < 5.
msdos-4.01-de
-------------
SvarCOM output:
DOS kernel version 4.0
Revision A
Rating:
'Revision A' should not be displayed, because it's not supported by DOS < 5.
drdos-5.0-de
------------
SvarCOM output:
DOS kernel version 3.31
Revision A
Rating:
'Revision A' should not be displayed, because it's not supported by DOS < 5.
According to DR DOS' sid.exe and version-check patched MS-DOS 6.22 debug.exe
CF was NOT set on unsupported Int21.3306, although became AX=0001.
RBIL is wrong!
drdos-6.0-de
------------
SvarCOM output:
DOS kernel version 3.31
Revision A
Rating:
'Revision A' should not be displayed, because it's not supported by DOS < 5.
According to DR DOS' sid.exe and version-check patched MS-DOS 6.22 debug.exe
CF was SET on unsupported Int21.3306 and became AX=0001. -- RBIL is correct.
nwdos-7.0-de
------------
SvarCOM output:
DOS kernel version 6.0
Revision A
DOS is in low memory
Rating: All fine. (According to DR DOS' debug.exe and MS-DOS 6.22 debug.exe
DL (rev) is set to 0.)
ptsdos-2k
---------
SvarCOM output:
DOS kernel version 6.80
Revision J
DOS is in HMA
Rating: All fine, I think. (I don't use PTS-DOS very often.)
From my POV, returning to the ((rc != 255) && (rc != 1)) method would prevent all this trouble. Or did I miss something?
There seems to be another error with the current code.
On Windows XP SvarCOM' 'ver' now only shows:
DOS kernel version 5.0 Revision A SvarCOM shell ver 2022.3
It's missing the 'true version' display.
debug.exe gives me:
AX=3306 BX=3205 CX=0000 DX=1000 SP=FFF0 BP=0000 SI=0000 DI=0000 DS=1A28 ES=1A28 SS=1A28 CS=1A28 IP=0105 NV UP EI PL NZ NA PO NC
So, ((maj != truemaj) || (min != truemin)) is definitely true.
I found doserr is 13062, which is 0x3306, what I don't understand, because carry is NC. So, doserr should still contain zero.
The code doesn't seem to skip the mov doserr, ax instruction.
Because under DOS 5+ Int21.3306 is not defined to modify CF. We need an explicit clc before int 0x21.
After fixing this, it displays DOS-Kernel-Version 5.0 ().
() are there but no 'true version'. -- Found it, one output(buff) was missing.
Fixed in rev 1086. -- Although I still think, checking rc/AL would be better.
mateuszviste Reply To bttr
From my POV, returning to the ((rc != 255) && (rc != 1)) method would prevent all this trouble. Or did I miss something?
To be honest I initially misunderstood the purpose of your rc variable. I thought it was some kind of "release candidate" subversion field, and as such it seemed dangerous to rely on it since a "subversion=1" could be likely. But I see now it is simply an undefined things and AL is probably likely to stay to the value it was set to initially on conforming systems.
Myself I won't invest time into non-SvarDOS compatibility things, but feel free to revert the rc thing (maybe with a one-line comment for clarity?) if you think it's safe. My only concern was for SvarDOS users not to be bothered with "true vs apparent" versions if both are the same value anyway.
mateuszviste)
Reply To mateuszviste
Reply To bttr
From my POV, returning to the ((rc != 255) && (rc != 1)) method would prevent all this trouble. Or did I miss something?
To be honest I initially misunderstood the purpose of your rc variable. I thought it was some kind of "release candidate" subversion field, and as such it seemed dangerous to rely on it since a "subversion=1" could be likely. But I see now it is simply an undefined things and AL is probably likely to stay to the value it was set to initially on conforming systems.
You spend too much time on 'buildidx.php', didn't you? ;-) 'rc' = return code, but I'm with fine your 'doserr'.
Myself I won't invest time into non-SvarDOS compatibility things, but feel free to revert the rc thing (maybe with a one-line comment for clarity?) if you think it's safe. My only concern was for SvarDOS users not to be bothered with "true vs apparent" versions if both are the same value anyway.
I see. Will change it soon. For 2022.3 or 2022.4 doesn't matter, I think, if you're in a hurry to release it.
I see. Will change it soon. For 2022.3 or 2022.4 doesn't matter, I think, if you're in a hurry to release it.
Rev 1092 fixed that.
Enhancement became part of SvarCOM version 2022.3.
This is an undocumented feature in MS-DOS 5.x+.
Sample output is:
Or:
Update: I forgot "DOS is in ROM".