Brendan wrote:
You claimed that it was other OSs developers (and not IBM or MS) that hacked the IBM/MS's design to handle multiple OSs; when it was designed to support this from the very beginning by IBM/MS themselves and not hacked to support it by other OS developers.
When did I say that "other OS developers" excludes Microsoft's XENIX developers (which was clearly the first non-DOS OS to use the MBR; and the only non-DOS OS for PCs produced by Microsoft/IBM until 1987's OS/2 1.0 - which was known as "DOS 5.0" during development, so maybe shouldn't be called "non-DOS" at all)?
It's plainly obvious that the MBR system was invented for DOS and that other OSs didn't originally factor into that design. Then low values "partition type" field clearly indicate the chronology of the early MBR-compatible OSs. They go FAT12 (DOS 2.x), XENIX, FAT16 (DOS 3.x), OS/2, Windows NT. Early versions of XENIX for the PC don't ship with a dual-boot MBR/boot manager, so cannot (officially) co-exist with any other OS; the use of the MBR by them is purely arbitrary, probably based on code/ideas "borrowed" from DOS to speed up development (there was definitely code/idea "sharing" between these two; e.g. the Xenix-derived handle-based file I/O API added in DOS 2.0) and was not an interoperability measure; at best it was chosen to "protect" a XENIX system should it be accidentally booted from a DOS floppy.
Even DOS wasn't entirely dependent on the MBR; since early (pre-4.0) versions of DOS were only shipped by Microsoft to OEMs, partially in source-code form (as "OEM Adaption Kits"), it was entirely possible (and expected, according to the documentation) that OEMs would use their own partitioning/boot schemes for their hard drives.
The MBR was never intended to support more than one OS on a PC. It wasn't even originally intended to be a "universal" standard; just an "implementation detail" for PC-DOS on IBM systems.
Any OS/boot manager (including those from Microsoft/IBM) that implements dual-boot is a "hack", an extension and overreaching of the original design intent and absolutely not part of the design or "specification".
Brendan wrote:"IBM PC DOS" wasn't written by IBM either.
The OS family known as "MS-DOS"/"PC-DOS" was co-developed by IBM and Microsoft (and as you note, originally based on SCP's 86-DOS) under their "Joint Development Agreement" until that agreement ended around 1990, so yes, significant parts of "IBM PC DOS" (and MS-DOS) were in fact written by IBM. Since Microsoft released the source code for DOS 1.1 and 2.0, you can see it for yourself; there are plenty of IBM copyright notices (the code also differs, files that originated at IBM tend to have the "IF IBMVER" before "IF MSVER" in conditionals, whereas Microsoft files are the other way around; compare FORMAT.ASM with MORE.ASM; "FORMAT" was originally an IBM-only utility, other OEMs were expected to build their own floppy/hard drive formatting utilities).
Brendan wrote:I don't know if you're stupid enough to think this is relevant; or if your trolling. Microsoft were dominant in the 1990s when they decided to break the established (de-facto) standard that their competitors were relying on (and were probably under investigation by the US Federal Trade Commission for other anti-competitive practices at the time).
If Microsoft weren't allowed to "break" the MBR specification that they themselves invented when they released Windows NT in 1993 because it (theoretically) negatively affected third-party software, then by the same logic they shouldn't have been allowed to release Windows NT at all, since it negatively affected compatibility with plenty of pre-existing third-party software written for DOS and OS/2 (NT was partly marketed by Microsoft as an upgrade/replacement for their OS/2 releases). MBR was a Microsoft/IBM "product", they had every right to change it.
Brendan wrote:
I'm saying there's major differences between system utilities that must have access to the disk; and normal applications (and licence managers) that do not need (and should not have) raw access to the disk.
How do you tell the difference? A program is a program. Figuring out what a program does without executing it is a problem closely related to the halting problem; as such there is no general-case solution.
Brendan wrote:Boot managers that have nothing at all to do with any OS are obviously unrelated to any specific OS. If you find this "logically inconsistent" the flaw is your lack of logic.
They have to be installed somehow. Unless they're shipped on a bootable storage device, that's going to be done from an existing (usually quite specific) OS. If your OS doesn't allow "raw" disk access, that can't be done. Thus, you can't both promote third-party boot managers and the principle that no OS should allow raw disk access; that's logically inconsistent.
Brendan wrote:You assume that everyone in the world has the same IQ as you (which is a natural assumption, but often false). Because of this assumption; you've assumed that people aren't smart enough to use the boot manager they've chosen to use, and you've assumed people are so stupid that they'll try to fix a boot manager's MBR by reinstalling something that has nothing at all to do with the boot manager (one of the OSs).
Ignoring the personal snipes, I'm assuming that the average user has no idea what an "MBR" or "boot manager" is, nor do they care. They're dimly aware of what an OS is, but don't understand anything below the user interface. Do you really disagree with those assumptions?
The
vast majority of users have only one OS and aren't interested in dual-booting. The only time they've ever installed a "boot manager" is when installing their OS; they've never consciously "chosen" one at all. For that user, if the MBR/"boot manager" is ever damaged, they're absolutely right to expect that re-installing the OS will fix it. If your OS doesn't re-install the MBR/boot manager by default when re-installing the OS, it's "broken" for this majority of users.
Brendan wrote:Yes; I'm assuming OS developers are competent and comply with established standards that ensure compatibility (e.g. "chain loading").
Since you're so resistant to established, documented standards, going so far as to call them "wrong" and deny the black-and-white text contained within them; why are you so confident that every other developer in the world respects them?
Brendan wrote:
This is pure wishful thinking. It's more likely that they tested various alternative MBRs to make sure it screwed up everyone else's software.
Name one piece of contemporary (i.e. from 1993) software that's damaged by the signature.
Brendan wrote:
No, it misses the point entirely. Just because a few specific versions of a few specific OSs (from a relatively small time period) might or might not have trouble, does not mean that all OSs from all time periods will have trouble or that no user will want to use any of the OSs that don't have trouble.
Where on earth did this "all OSs from all time periods" nonsense come from? You said that the number of OSs affected by that issue (BIOS-to-physical geometry mismatch) was "exactly zero", even after I'd given an example. Now, after being conclusively proven wrong, you're still trying to argue the point...
Brendan wrote:Am I supposed to care;
Interesting how you stop caring about a point (that you brought up) or declare it "irrelevant" or "missing the point" at exactly the point that you're proven wrong about it...