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