Find and HEX edit it in command.com.

p.kapica027 wrote on 2024-08-30, 18:01:

I'm on pure MS-DOS 7.10 (the VER command reports "Windows 98 [Version 4.10.2222]") and wondering about the possibility of changing that output to read "MS-DOS version 7.10"
Any way of accomplishing this?

There is, and you may also run into all your MS-DOS externals reporting "Incorrect DOS Version".

AlaricD wrote on 2024-08-30, 21:15:

There is, and you may also run into all your MS-DOS externals reporting "Incorrect DOS Version".

Really?
Don't they use INT 21h to obtain DOS version, rather than invoking the VER command?

Cyberdyne wrote on 2024-08-30, 20:13:

Find and HEX edit it in command.com.

Thanks for the suggestion. Unfortunately this doesn't seem to work with the COMMAND.COM included with Win98 DOS. I used a binary editor to replace all strings matching "Windows 98 [Version %1]" with "MS-DOS Version 7.10 " (padded with spaces to match the original string length), but that darned VER command still responds with "Windows 98 [Version 4.10.2222]". Seems like 7.x version of COMMAND.COM might be getting this information from elsewhere.

AlaricD wrote on 2024-08-30, 21:15:

There is, and you may also run into all your MS-DOS externals reporting "Incorrect DOS Version".

I'll look at this from another angle, then. Maybe I should've been specific and asked why does Watcom VI cause problems with the VER command in MS-DOS 7.10? After starting and then exiting the VI editor, executing VER gets me "Windows 98 [Version " followed by garbled data about T_FIND, some numbers and some extended ASCII characters. I have no idea what's behind it and it's mucking up a script I use. Going to an older DOS version isn't a good option since MS-DOS 7 is LFN friendly, and I like to preserve the case of filenames when sharing with Windows and Linux.

Cyberdyne wrote on 2024-08-30, 20:13:

Find and HEX edit it in command.com.

This actually works. I tried it. The string "Windows 98 [Version %1]" is a pascal string with the length byte in front, while "4.10.2222" is zero-terminated.

I did it once for jiggles and it was straightforward. I just wanted to replace all strings reporting Windows 98 to be MS DOS but keep the version 7..etc. There were quite a handful of such strings that I replaced carefully while maintaining spacing and character count. Then just save the new file and done. I can't see how this "can't work".

But you don’t even need to maintain the length.

There was that "China DOS Union" thing identifying itself as "MS-DOS 7.10"...

Grzyb wrote on 2024-08-31, 07:16:

There was that "China DOS Union" thing identifying itself as "MS-DOS 7.10"...

Allso just a simple HEX edited thing.

Can't you just use setver in a bat?

myne wrote on 2024-08-31, 09:01:

Can't you just use setver in a bat?

SETVER doesn't affect the VER command.
VER command in MS-DOS 7.x doesn't display the DOS version - instead it pretends it's Windows, not DOS 🤣

https://www.computerhope.com/setverhl.htm

Ringding wrote on 2024-08-31, 04:47:

Cyberdyne wrote on 2024-08-30, 20:13:

Find and HEX edit it in command.com.

This actually works. I tried it. The string "Windows 98 [Version %1]" is a pascal string with the length byte in front, while "4.10.2222" is zero-terminated.

Okay, I'm going to give it another shot next week. Thanks for the info about mixing C and traditional Pascal strings—I had modified command.com with a text editor in binary mode where a proper hex editor should've been used to expose each byte numerically.

myne wrote on 2024-08-31, 11:51:

https://www.computerhope.com/setverhl.htm

That page describes the SETVER program, which maintains a database of individual executable names and for each an associated 'fake' DOS version number that gets reported internally at run time. SETVER does not in any way affect the output of the command shell's internal VER command, which is what gets garbled after running a certain program on my system, in turn affecting a batch file (unless it's rebooted first). The main thing is, VER will by default always display the actual DOS version you're running whether SETVER.EXE is loaded or not. That's why poking around that COMMAND.COM binary is the only way to modify the string displayed by VER.

Tried setting it for vi?

myne wrote on 2024-08-31, 13:21:

Tried setting it for vi?

Yes. I've added the vi executable to setver, associating it with version 5.00 and then 6.20. Neither worked, but it was definitely worth a try.

The OS/2 museum guy tracked down a bug in that same variant of vi a while back: http://www.os2museum.com/wp/tracking-down-a-bug/
Maybe if you can give instructions to reproduce this he'd be convinced to dig into it if he is already familiar with the code.

jakethompson1 wrote on 2024-08-31, 15:52:

The OS/2 museum guy tracked down a bug in that same variant of vi a while back: http://www.os2museum.com/wp/tracking-down-a-bug/
Maybe if you can give instructions to reproduce this he'd be convinced to dig into it if he is already familiar with the code.

What's happening, in my case, is that exiting vi causes VER to print "Windows 98 [Version " followed by either bits of its config file if vi was started with an empty buffer, or bits of the file that was just loaded into vi if it was an existing file.
I'm now searching for a better vi. This one definitely has more serious issues than the one I've encountered and I hear the Open Watcom v2 codebase is messy, so I don't expect any official fixes soon.