Reply 20 of 23, by jakethompson1
- Rank
- Oldbie
That blog suggests there are parts of that vi that assume ss=ds in situations where they aren't, so it scribbles randomly in memory.
It's no surprise you're having issues.
That blog suggests there are parts of that vi that assume ss=ds in situations where they aren't, so it scribbles randomly in memory.
It's no surprise you're having issues.
I just loaded COMMAND.COM from MS-DOS 6.22 into a hex editor and, aside from the copyright string, I couldn't find a single reference to "MS-DOS" or the version number embedded in the binary. This is in contrast with the MS-DOS 7.1 COMMAND.COM, wherein the string "Windows 98 [Version %1]" appears twice. I wonder how the %1 refers to the string "4.10.2222" (or whichever version of Windows 9x), and if the bug I'm experiencing is a result of Watcom VI just not being able to handle the newer format; possibly historical code not updated or tested with MS-DOS 7.1?
Very likely, it has absolutely nothing to do with DOS 7.10 or command.com; it’s just that in your particular setup, vi tends to corrupt the specific memory area where the version string happens to reside.
Grzyb wrote on 2024-08-30, 22:35: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?
When I tried it under MS-DOS 2.11.13, none of the externals worked anymore. Had to copy command.com from a boot diskette to fix it. This was in like '91 or so, so I've forgotten some of the details. (I think I used debug to edit the file, not a hex editor. Could've been part of the problem.)