Ticket #44050

Add support for 'ver /r'

Open Date: 2022-03-08 00:13 Last Update: 2022-03-13 22:58

Reporter:
Owner:
Status:
Closed
Component:
MileStone:
(None)
Priority:
5 - Medium
Severity:
5 - Medium
Resolution:
Fixed
File:
None

Details

This is an undocumented feature in MS-DOS 5.x+.

Sample output is:

MS-DOS Version 6.22
Revision A
DOS is in HMA

Or:

MS-DOS Version 6.22
Revision A
DOS is in low memory

Update: I forgot "DOS is in ROM".

Ticket History (3/27 Histories)

2022-03-08 00:13 Updated by: bttr
  • New Ticket "Add support for 'ver /r'" created
2022-03-08 04:06 Updated by: bttr
  • Details Updated
2022-03-08 17:10 Updated by: mateuszviste
Comment

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) ?

2022-03-08 18:19 Updated by: bttr
Comment

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'.

2022-03-08 18:42 Updated by: bttr
Comment

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.

(Edited, 2022-03-08 20:09 Updated by: bttr)
2022-03-08 19:13 Updated by: bttr
Comment

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.

(Edited, 2022-03-08 19:14 Updated by: bttr)
2022-03-09 06:08 Updated by: mateuszviste
Comment

implemented in revision 1056

2022-03-10 05:30 Updated by: bttr
Comment

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.

(Edited, 2022-03-10 05:37 Updated by: bttr)
2022-03-10 05:36 Updated by: bttr
Comment

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.

2022-03-10 06:21 Updated by: mateuszviste
Comment

ver/r is not hidden, it simply does not exist. ver always displays all information, and ignores arguments other than /about and /dbg.

2022-03-11 04:00 Updated by: bttr
Comment

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...

(Edited, 2022-03-11 04:04 Updated by: bttr)
2022-03-11 04:49 Updated by: mateuszviste
Comment

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?

2022-03-11 04:58 Updated by: mateuszviste
Comment

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..

2022-03-11 06:01 Updated by: bttr
Comment

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.

2022-03-11 06:04 Updated by: bttr
Comment

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?

2022-03-11 06:25 Updated by: mateuszviste
Comment

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.

2022-03-11 06:39 Updated by: bttr
Comment

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.

(Edited, 2022-03-11 06:42 Updated by: bttr)
2022-03-11 06:52 Updated by: mateuszviste
Comment

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...).

2022-03-11 07:04 Updated by: mateuszviste
Comment

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?

2022-03-11 07:20 Updated by: bttr
Comment

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.

2022-03-11 07:34 Updated by: mateuszviste
Comment

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.

2022-03-12 06:39 Updated by: bttr
Comment

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?

2022-03-12 08:04 Updated by: bttr
Comment

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.

2022-03-12 19:06 Updated by: mateuszviste
Comment

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.

(Edited, 2022-03-12 19:07 Updated by: mateuszviste)
2022-03-12 19:28 Updated by: bttr
Comment

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.

2022-03-13 00:58 Updated by: bttr
Comment

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.

2022-03-13 22:58 Updated by: bttr
  • Status Update from Open to Closed
  • Resolution Update from None to Fixed
Comment

Enhancement became part of SvarCOM version 2022.3.

Attachment File List

No attachments

Edit

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login