Interesting! I stand corrected, though I think the MS explanation does sound plausible for the times.
Can this "Windows poked around in the guts of DOS" and "DOS 4.0 patched Windows" sort of mechanic be verified elsewhere?
Can this "Windows poked around in the guts of DOS" and "DOS 4.0 patched Windows" sort of mechanic be verified elsewhere?
What they said it's entirely plausible is the problem, and that's why people bought it. Even if it was true, it's on Microsoft for doing that, not DR-Dos for being incompatible. It's like how you needed to be using IE6 to browse the web, or using Microsoft Word from Microsoft Office to edit your documents.
What's really sad is how much things have shifted against Microsoft. Now it's Apple's turn on top, and people are buying that same line just as naively. iMessage this and iCloud that.
This is well past the point where any of this actually mattered. It's just plausible to me that there was more than one reason for it. Eg, that Windows poked in DOS brains and did weird stuff is a very convenient thing to the higher ups who wanted an excuse to have less competition, so both things can be true at the same time -- that Microsoft was unethical, but there was a technical reason as well.
Arguably of course all of that should have been documented and have a proper API for it
https://www.os2museum.com/wp/the-ihc-damage/
https://jeffpar.github.io/kbarchive/kb/148/Q148637/
jdebp touches the matter on the page on (previous) messing up with bootsectors by MS-DOS:
http://jdebp.info/FGA/volume-boot-block-oem-name-field.html
(but those DOS ones were only about not trusting the BPB fields, not about corrupting the OEM field)
The code that put up the fake error messages (in the Windows beta versions) when running drdos was xor encrypted in an apparent effort to obfuscate / hide the code. What possible reason would there be for MS to try to escape detection if there was any legitimate reason for the error messages?
These BS error messages have a more modern equivalent by MS-- MS added open document support to MS office natively, having already supported odt with a plugin in their earlier version in order to do business in places that mandated open data formats. The native odt support would convert all formulas in a spreadsheet to the static values they calculated to the first time the spreadsheet was opened by MS Office. Destroying people's work to annoy them to using their proprietary formats. The old plugin did not have this issue (so MS did know how to implement proper support, and had to expend effort re-writing existing code in order to get the 'destroy document' feature to work).
Why should Microsoft have gone out of their way to make windows compatible with some operating system it was never designed to run on?
E.g., MS windows 3.1 running in a window under Desqview ran faster than Windows 3.1 running natively. This was presumably embarrassing for Microsoft. Microsoft removed the operating mode that windows ran in that was supported by Desqview in Windows 3.11. Perhaps there were legitimate reasons for this feature removal, but breaking compatibility with a competitor's product would only be seen as a benefit by MS management, and is plausibly the exclusive reason for removing the feature.