I remember somebody at Microsoft arguing that AARD had a sort of legitimate purpose -- Windows reached deep into DOS in ways that in modern times would be anathema, and did stuff that one couldn't expect to necessarily work properly on a DOS clone, since it wasn't part of the public API.
> As a simple example, when Windows started up, it increased the size of MS-DOS’s internal file table (the SFT, that’s the table that was created by the FILES= line in config.sys). It did that to allow more than 20 files to be opened on the windows system (a highly desirable goal for a multi-tasking operating system). But it did that by using an undocumented API call, which returned a pointer to a set of “interesting” pointers in MS-DOS.
[...]
> But the problem was that the MS-DOS 4.0 SFT was 2 bytes larger than the MS-DOS 3.1 SFT. In order to get Windows to work, I had to change the DOS loader to detect when win.com was being loaded, and if it was being loaded, I looked at the code at an offset relative to the base code segment, and if it was a “MOV” instruction, and the amount being moved was the old size of the SFT, I patched the instruction in memory to reflect the new size of the SFT! Yup, MS-DOS 4.0 patched the running windows binary to make sure Windows would still continue to work.
So yeah, by modern standards the way old DOS software worked was all kinds of screwy.
It was later revealed exactly what the purpose was, when internal mail discussions came out in court.
"What the guy is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is dr-dos and then go out to buy ms-dos. or decide to not take the risk for the other machines he has to buy for in the office."
Would it be legal to create similar incompatibilities if there is both a legal business justification (that particular solution can be implemented in X developer time and would cost us Y money which wins against a proper implementation) and an engineering justification (that particular solution would use X less bytes of disk/RAM and would run better on Y% of our customer's machines) for an implementation which heavily depends on undocumented internals of another product?
No, "gaslighting" is a term for specifically making somebody doubt their own sanity by sabotaging their perception of their own actions.
It's not simply lying or creating fear, it's something a lot more insidious, and I don't think it can be really done on a non-specific target.
Eg, an example would be intentionally hiding somebody's keys to convince them they can't keep track of anything, or scheduling an appointment the person is supposed to go to, never telling them about it, then arguing they were told several times, they're just dumb and forgot.
Sorry, you bought Microsoft lies hook, line, and sinker. No shame! Everybody did. That's why DR-Dos isn't with us any more.
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.
I didn't originally, I used MS-DOS, PC-DOS, DR-DOS and even I think PTS-DOS at some point. I liked trying weird stuff.
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
> It's just plausible to me that there was more than one reason for it.
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).
I think the implication is that MS went out of its way to make windows not compatible with others (or just appear to be by throwing bogus messages from xor encrypted obfuscated code).
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.
Still, that idea could have been better executed.
Aha, here:
https://learn.microsoft.com/en-us/archive/blogs/larryosterma...
> As a simple example, when Windows started up, it increased the size of MS-DOS’s internal file table (the SFT, that’s the table that was created by the FILES= line in config.sys). It did that to allow more than 20 files to be opened on the windows system (a highly desirable goal for a multi-tasking operating system). But it did that by using an undocumented API call, which returned a pointer to a set of “interesting” pointers in MS-DOS.
[...]
> But the problem was that the MS-DOS 4.0 SFT was 2 bytes larger than the MS-DOS 3.1 SFT. In order to get Windows to work, I had to change the DOS loader to detect when win.com was being loaded, and if it was being loaded, I looked at the code at an offset relative to the base code segment, and if it was a “MOV” instruction, and the amount being moved was the old size of the SFT, I patched the instruction in memory to reflect the new size of the SFT! Yup, MS-DOS 4.0 patched the running windows binary to make sure Windows would still continue to work.
So yeah, by modern standards the way old DOS software worked was all kinds of screwy.