Page 2 of 3

Re: Check if device is bootable

Posted: Fri Nov 13, 2015 3:29 am
by mallard
Brendan wrote:
Do you understand the difference between "may" and "must"?

This may be used by the OS to identify the disk (but it's still perfectly legal for the OS to use it for executable MBR code instead).
Even if the use of those 4 bytes for a signature is optional, the standard has never said that they can be used for boot code, even the 2.0/2.1 versions of the standard say that the boot code is 440 bytes. If you decide you don't want to use a field, that doesn't give you permission to overwrite it with something else.

Brendan wrote:"PC compatible" computers are full of backward compatibility for very good reasons. Breaking backward compatibility (and breaking all older OSs that complied with previous versions of a specification) is almost never acceptable. Don't forget that most computers that come with UEFI also have a BIOS compatibility layer and that hybrid "MBR + GPT" is entirely possible; and nothing prevents you from running (e.g.) DOS 1.0 from 1981 on a UEFI system purchased last week.
It doesn't break any compatibility. Using those 4 byte for boot code was always against the spec. MS-DOS 1.0 didn't even support hard drives (or even 3.5" floppies, so good luck running it on a modern system), so is utterly irrelevant. Ancient OSs (that do support hard drives) are almost certainly already incompatible with modern UEFI-based systems due to their lack of LBA addressing support. All of that is besides the point anyway, because the "de-facto" Microsoft/IBM MBR specification included the signature and any OS/bootloader that abused those 4 bytes was always violating the spec.
Brendan wrote: It's very much a problem if you install 2 different versions of Windows (e.g. Win7 and Win10) in separate partitions and they both fail to keep track of which disk is what because they're constantly trashing each other's disk signatures.
Clearly you've never actually tried that... That doesn't happen.
Brendan wrote:It has nothing to do with the virus protection features of 1990s BIOSs which did none of this any only prevented writes to the MBR.
What exactly that feature did depended on the BIOS. Systems I'm aware of stored a checksum in their configuration memory (Flash/CMOS) and alerted the user on boot if it changed. They obviously only considered the first 440 bytes.
Brendan wrote: The firmware (not me) "measures" the entire sector. It makes no difference if it's executable or not. Please note that other data (e.g. ACPI tables, etc) is also measured (by firmware, not me).
So the act of installing Windows will change the checksum anyway, since it will modify the partition table. Quibbling over the 4-byte signature is therefore rather stupid.
Brendan wrote: UEFI specs say that "the OS" (my OS) may use those bytes. If any other OS that is not "the OS" (e.g. Windows) modifies those bytes then it's a malicious violation.
The specifications say "the OS", not "Brendan's OS". I agree that it's vague, but it could easily be interpreted to mean "the last/current OS booted". Your assertion that it has to mean "your OS" or maybe "the first OS installed" is without suppport.
Brendan wrote: Of course (as I've already said) the MBR shouldn't belong to any specific OS. An OS only "owns" data in its partitions and has no right to modify any part of any disk outside of its own partitions unless it has the computer owner's consent. If UEFI specs says otherwise then the UEFI specs are wrong (but they don't, they only say "optional" or "may" and never say "must").
The spec is the spec whether you agree with it or not. Your philosophical beliefs about the MBR are not supported by it. If you want to invent your own computing platform with a different spec, go ahead. The fact that it says that "may be used by the OS" and unambiguously says that the boot code is only 440 bytes makes it pretty clear that those 4 bytes cannot be "claimed" by any bootloader for its own use.

Re: Check if device is bootable

Posted: Fri Nov 13, 2015 4:39 am
by Antti
mallard wrote:Ancient OSs (that do support hard drives) are almost certainly already incompatible with modern UEFI-based systems due to their lack of LBA addressing support.
I would not be so sure. If true, is there any reason to put in a lot of effort for making the system backwards compatible at all? It is true that their lack of LBA addressing is going to set some limits for the partition layout. However, making it incompatible because of this would cut out so many old operating systems without any good reason. It would be relatively easy to just support CHS addressing if there were support for BIOS disk functions to start with.

Re: Check if device is bootable

Posted: Fri Nov 13, 2015 5:04 am
by Brendan
Hi,
mallard wrote:
Brendan wrote:Do you understand the difference between "may" and "must"?

This may be used by the OS to identify the disk (but it's still perfectly legal for the OS to use it for executable MBR code instead).
Even if the use of those 4 bytes for a signature is optional, the standard has never said that they can be used for boot code, even the 2.0/2.1 versions of the standard say that the boot code is 440 bytes. If you decide you don't want to use a field, that doesn't give you permission to overwrite it with something else.
Brendan wrote:"PC compatible" computers are full of backward compatibility for very good reasons. Breaking backward compatibility (and breaking all older OSs that complied with previous versions of a specification) is almost never acceptable. Don't forget that most computers that come with UEFI also have a BIOS compatibility layer and that hybrid "MBR + GPT" is entirely possible; and nothing prevents you from running (e.g.) DOS 1.0 from 1981 on a UEFI system purchased last week.
It doesn't break any compatibility. Using those 4 byte for boot code was always against the spec. MS-DOS 1.0 didn't even support hard drives (or even 3.5" floppies, so good luck running it on a modern system), so is utterly irrelevant. Ancient OSs (that do support hard drives) are almost certainly already incompatible with modern UEFI-based systems due to their lack of LBA addressing support. All of that is besides the point anyway, because the "de-facto" Microsoft/IBM MBR specification included the signature and any OS/bootloader that abused those 4 bytes was always violating the spec.
The de facto spec is, 446 bytes that boot code can use however it wants, then four partition table entries, then a 2 byte boot signature. This is how it's been since the MBR partitioning scheme existed. The 4 byte disk signature never existed and wasn't part of any spec until Microsoft needed an ugly hack for their OS and their OS alone (because they're too stupid to use the serial number that most disk drives have had for a very long time) and decided to screw up something that no OS has the right to modify. The only reason it ended up in UEFI is because UEFI are incompetent cowards that are far too willing to allow Microsoft to urinate in everyone's faces.

Note that it is not the first time Windows and Windows applications have ignored long standing practices and tampered with areas of the disk that no OS has the right to mess with. See slashdot.org for a summary or Ubuntu's bug tracker for all the details. Microsoft have a history of assuming they own everything and trashing other OSs.
mallard wrote:
Brendan wrote: It's very much a problem if you install 2 different versions of Windows (e.g. Win7 and Win10) in separate partitions and they both fail to keep track of which disk is what because they're constantly trashing each other's disk signatures.
Clearly you've never actually tried that... That doesn't happen.
Clearly if 2 or more OSs use different methods to determine what the "correct" disk signature is, it will happen.

If it was an actual part of an official specification (and not just morons bending over and taking it from behind at the request of Microsoft) then that specification would have to specify how all OSs should create the disk signature to ensure there are no (additional) compatibility problems.
mallard wrote:
Brendan wrote:The firmware (not me) "measures" the entire sector. It makes no difference if it's executable or not. Please note that other data (e.g. ACPI tables, etc) is also measured (by firmware, not me).
So the act of installing Windows will change the checksum anyway, since it will modify the partition table. Quibbling over the 4-byte signature is therefore rather stupid.
For GPT (where the MBR contains boot code that uses GPT partitions to find an OS and ensure the disk is bootable on systems that don't support UEFI; and where the MBR partitions are "protective" and not used) installing any OS (including Windows) should not corrupt the MBR. Plugging a device (e.g. USB flash) into a computer that happens to have Windows installed on a completely different/unrelated disk should also not cause the MBR on the completely different/unrelated disk to be trashed.
mallard wrote:
Brendan wrote:UEFI specs say that "the OS" (my OS) may use those bytes. If any other OS that is not "the OS" (e.g. Windows) modifies those bytes then it's a malicious violation.
The specifications say "the OS", not "Brendan's OS". I agree that it's vague, but it could easily be interpreted to mean "the last/current OS booted". Your assertion that it has to mean "your OS" or maybe "the first OS installed" is without suppport.
It should never have said "the OS" because that relies on the false assumption that there is only one OS.
mallard wrote:
Brendan wrote: Of course (as I've already said) the MBR shouldn't belong to any specific OS. An OS only "owns" data in its partitions and has no right to modify any part of any disk outside of its own partitions unless it has the computer owner's consent. If UEFI specs says otherwise then the UEFI specs are wrong (but they don't, they only say "optional" or "may" and never say "must").
The spec is the spec whether you agree with it or not. Your philosophical beliefs about the MBR are not supported by it. If you want to invent your own computing platform with a different spec, go ahead. The fact that it says that "may be used by the OS" and unambiguously says that the boot code is only 440 bytes makes it pretty clear that those 4 bytes cannot be "claimed" by any bootloader for its own use.
It makes it perfectly clear that I may store my own disk signature in that 4 byte area; and if/when that disk signature is modified I may display a huge red "Your computer has been maliciously tampered with" error screen that includes a "Press a key to disinfect your hard drive" prompt, where (if the user agrees) it wipes Windows off of the hard drive and restores the MBR then reboots (and where after rebooting the TPM's hash will be correct and remote attestation will succeed).


Cheers,

Brendan

Re: Check if device is bootable

Posted: Fri Nov 13, 2015 5:16 am
by Brendan
Hi,
Antti wrote:
mallard wrote:Ancient OSs (that do support hard drives) are almost certainly already incompatible with modern UEFI-based systems due to their lack of LBA addressing support.
I would not be so sure. If true, is there any reason to put in a lot of effort for making the system backwards compatible at all? It is true that their lack of LBA addressing is going to set some limits for the partition layout. However, making it incompatible because of this would cut out so many old operating systems without any good reason. It would be relatively easy to just support CHS addressing if there were support for BIOS disk functions to start with.
It's not true.

For the old BIOS disk services (which are limited to 1024 cylinders, 256 heads and 63 sectors), BIOSs have been converting "fake CHS" to LBA behind the scenes for an extremely long time; and if an ancient OS only uses the old BIOS disk services then it will work perfectly well (even on a modern UEFI system that has a BIOS compatibility layer) as long as the ancient OS's partition/s are within the first ~8 GiB of the disk.

For an OS that use "int 0x13 extensions" (that were introduced in the 1990's; long before Microsoft decided to force their personal "disk signature" hack on everyone else) that ~8 GiB limit disappears.


Cheers,

Brendan

Re: Check if device is bootable

Posted: Fri Nov 13, 2015 6:49 am
by mallard
Brendan wrote: The de facto spec is, 446 bytes that boot code can use however it wants, then four partition table entries, then a 2 byte boot signature. This is how it's been since the MBR partitioning scheme existed. The 4 byte disk signature never existed and wasn't part of any spec until Microsoft needed an ugly hack for their OS and their OS alone (because they're too stupid to use the serial number that most disk drives have had for a very long time) and decided to screw up something that no OS has the right to modify.
The "signature" at 0x1B8 has been there since Windows NT launched in 1993. I'm sure if all storage devices could be relied upon to have completely unique serial numbers (they most certainly cannot, even you say "most"), Microsoft wouldn't have had to resort to this. In 1993 the PC platform was in the "wild west" era of development when nobody was really in control (IBM lost control in ~1987, Microsoft/Intel took control around 1996/7). All specs were "up for discussion". Dual-booting was rare and acknowledged as the hack it is (pre-UEFI).
Brendan wrote: Note that it is not the first time Windows and Windows applications have ignored long standing practices and tampered with areas of the disk that no OS has the right to mess with. See slashdot.org for a summary or Ubuntu's bug tracker for all the details. Microsoft have a history of assuming they own everything and trashing other OSs.
That (singular, both links are talking about the same problem) is an instance of third-party Windows software (HP, Dell and Novell are mentioned) screwing things up, not anything that Microsoft have done.
Brendan wrote: Clearly if 2 or more OSs use different methods to determine what the "correct" disk signature is, it will happen.
Sure, but different versions of Windows don't appear to have such a disagreement.
Brendan wrote: If it was an actual part of an official specification ...
It is. Live with it.
Brendan wrote: For GPT (where the MBR contains boot code that uses GPT partitions to find an OS and ensure the disk is bootable on systems that don't support UEFI; and where the MBR partitions are "protective" and not used) installing any OS (including Windows) should not corrupt the MBR. Plugging a device (e.g. USB flash) into a computer that happens to have Windows installed on a completely different/unrelated disk should also not cause the MBR on the completely different/unrelated disk to be trashed.
Anyone installing an OS will expect to be able to boot it immediately afterwards. In the pre-UEFI world, that requires modifying the MBR. Nobody wants to have to go through a separate process of updating the MBR post-install. The MBR-booted GPT scheme is no different.

"Plugging in a device" doesn't cause any changes to the disk. If you boot from a device and opt to begin the Windows installation process, it's entirely reasonable to expect changes to the disk, including changes that might "upset" existing operating systems. There's no way for a newly installed OS to add itself to an existing OSs boot system.
Brendan wrote: It makes it perfectly clear that I may store my own disk signature in that 4 byte area; and if/when that disk signature is modified I may display a huge red "Your computer has been maliciously tampered with" error screen that includes a "Press a key to disinfect your hard drive" prompt, where (if the user agrees) it wipes Windows off of the hard drive and restores the MBR then reboots (and where after rebooting the TPM's hash will be correct and remote attestation will succeed).
Sure, if you want to do that, go ahead. I doubt many actual users will appreciate that feature, but who knows...
Brendan wrote:For the old BIOS disk services (which are limited to 1024 cylinders, 256 heads and 63 sectors), BIOSs have been converting "fake CHS" to LBA behind the scenes for an extremely long time; and if an ancient OS only uses the old BIOS disk services then it will work perfectly well (even on a modern UEFI system that has a BIOS compatibility layer) as long as the ancient OS's partition/s are within the first ~8 GiB of the disk.
There are many hard drive "limits" that will affect old OSs on modern hardware; here's a list of just some of them. It's not just that they'll only use part of the disk; there's a good chance that an old might reject the partition table as "corrupt" and attempt to "fix" it, the possibility that it may corrupt the "upper" part of the disk by using the upper bits in an address as flags or that it might just out-right crash when it sees a modern disk.

Not to mention the various other reasons why old OSs often fail on modern systems (lack of USB support meaning no input devices available, CPU speed too fast for old timing code, etc, etc.).

The chances of an OS from before around 2000 working properly on a modern system is pretty slim.
Brendan wrote:For an OS that use "int 0x13 extensions" (that were introduced in the 1990's; long before Microsoft decided to force their personal "disk signature" hack on everyone else) that ~8 GiB limit disappears.
The disk signature was introduced in 1993, the "BIOS Enhanced Disk Drive Specification" (aka INT 13h extensions) was introduced by Phoenix in 1994 or 1995 (oldest PDF I can easily find is version 1.1 dated May 9, 1995), so Microsoft's signature predates it.

Re: Check if device is bootable

Posted: Fri Nov 13, 2015 8:01 am
by Antti
mallard wrote:The chances of an OS from before around 2000 working properly on a modern system is pretty slim.
The old operating systems, e.g. MS-DOS 6.22, work surprisingly well. It could be easy to find some problems if someone wanted to point out the problems for their own sake. If we were honest, we would just be impressed how well they work in general.

Re: Check if device is bootable

Posted: Fri Nov 13, 2015 10:28 am
by Brendan
Hi,
mallard wrote:
Brendan wrote:The de facto spec is, 446 bytes that boot code can use however it wants, then four partition table entries, then a 2 byte boot signature. This is how it's been since the MBR partitioning scheme existed. The 4 byte disk signature never existed and wasn't part of any spec until Microsoft needed an ugly hack for their OS and their OS alone (because they're too stupid to use the serial number that most disk drives have had for a very long time) and decided to screw up something that no OS has the right to modify.
The "signature" at 0x1B8 has been there since Windows NT launched in 1993. I'm sure if all storage devices could be relied upon to have completely unique serial numbers (they most certainly cannot, even you say "most"), Microsoft wouldn't have had to resort to this. In 1993 the PC platform was in the "wild west" era of development when nobody was really in control (IBM lost control in ~1987, Microsoft/Intel took control around 1996/7). All specs were "up for discussion". Dual-booting was rare and acknowledged as the hack it is (pre-UEFI).
It has existed in MBRs that Windows NT and later create (e.g. when Windows is being installed), and I'm perfectly fine with that - it's their MBR and they are free to do whatever they like with their MBR.

I don't know when they decided to tamper with MBRs that Windows did not create (and has no right to modify) that either belong to other OSs or no OS at all (e.g. boot manager). This is not acceptable, regardless of when they decided to do it.
mallard wrote:
Brendan wrote:Note that it is not the first time Windows and Windows applications have ignored long standing practices and tampered with areas of the disk that no OS has the right to mess with. See slashdot.org for a summary or Ubuntu's bug tracker for all the details. Microsoft have a history of assuming they own everything and trashing other OSs.
That (singular, both links are talking about the same problem) is an instance of third-party Windows software (HP, Dell and Novell are mentioned) screwing things up, not anything that Microsoft have done.
If an OS lets applications modify arbitrary sectors of the disk (including areas that the OS itself has no right to modify) then that OS is a security disaster; and that definitely is Microsoft's fault.
mallard wrote:
Brendan wrote:If it was an actual part of an official specification ...
It is. Live with it.
It's not; it's obviously something UEFI "shoehorned" in for the sake of Microsoft, and obvious UEFI have not forced it on everyone (or at least are reluctant to force it on everyone) by using worlds like "optional" and "may" rather than "must". If UEFI themselves actually wanted something like this to be part of their official specification they would've added it to GPT's own partition table header instead, and would've documented it properly (including the method to construct the signature and/or ensure it's unique, most likely via. the use of GUIDs similar to what they're using throughout the rest of UEFI).
mallard wrote:
Brendan wrote:For GPT (where the MBR contains boot code that uses GPT partitions to find an OS and ensure the disk is bootable on systems that don't support UEFI; and where the MBR partitions are "protective" and not used) installing any OS (including Windows) should not corrupt the MBR. Plugging a device (e.g. USB flash) into a computer that happens to have Windows installed on a completely different/unrelated disk should also not cause the MBR on the completely different/unrelated disk to be trashed.
Anyone installing an OS will expect to be able to boot it immediately afterwards. In the pre-UEFI world, that requires modifying the MBR. Nobody wants to have to go through a separate process of updating the MBR post-install. The MBR-booted GPT scheme is no different.
Wrong. Traditionally (for systems intended to have multiple OSs installed) you'd have some sort of boot manager (like PLOP or Smart BootManager or GAG or XOSL or LILO or GRUB); you'd install an OS in its partition, then tell that boot manager how to boot that new OS. The MBR-booted GPT scheme is no different.

Of course it's nice for an OS installer to offer to install an MBR (e.g. possibly a simple thing only capable of booting one OS) so that people who only want that one OS don't need to worry about it. Sadly, this is yet another case where Microsoft assume they own the world and urinate on everyone else by always replacing the MBR (and not giving the user a choice). Fortunately this is also something that UEFI solves.
mallard wrote:"Plugging in a device" doesn't cause any changes to the disk. If you boot from a device and opt to begin the Windows installation process, it's entirely reasonable to expect changes to the disk, including changes that might "upset" existing operating systems. There's no way for a newly installed OS to add itself to an existing OSs boot system.
Wrong. According to Wikipedia's MBR page "Windows NT (and later Microsoft operating systems) uses the disk signature as an index to all the partitions on any disk ever connected to the computer under that OS". According to Mark Russinovich's blog post (in the Disk Signature Collisions section) "When you chose the Online menu option, Windows will without warning generate a new random disk signature and assign it to the disk by writing it to the MBR". I'm sure there's plenty of other sources of information saying that windows does write to the MBR of disks (even when you're not installing Windows on that disk).
mallard wrote:
Brendan wrote:It makes it perfectly clear that I may store my own disk signature in that 4 byte area; and if/when that disk signature is modified I may display a huge red "Your computer has been maliciously tampered with" error screen that includes a "Press a key to disinfect your hard drive" prompt, where (if the user agrees) it wipes Windows off of the hard drive and restores the MBR then reboots (and where after rebooting the TPM's hash will be correct and remote attestation will succeed).
Sure, if you want to do that, go ahead. I doubt many actual users will appreciate that feature, but who knows...
It's possibly a little extreme (in practice I'd only restore the MBR and wouldn't wipe Windows); but beyond that I don't have a choice. I do expect/hope users will appreciate the security features of my OS (e.g. very few OSs even try to protect against "physical presence").
mallard wrote:
Brendan wrote:For the old BIOS disk services (which are limited to 1024 cylinders, 256 heads and 63 sectors), BIOSs have been converting "fake CHS" to LBA behind the scenes for an extremely long time; and if an ancient OS only uses the old BIOS disk services then it will work perfectly well (even on a modern UEFI system that has a BIOS compatibility layer) as long as the ancient OS's partition/s are within the first ~8 GiB of the disk.
There are many hard drive "limits" that will affect old OSs on modern hardware; here's a list of just some of them. It's not just that they'll only use part of the disk; there's a good chance that an old might reject the partition table as "corrupt" and attempt to "fix" it, the possibility that it may corrupt the "upper" part of the disk by using the upper bits in an address as flags or that it might just out-right crash when it sees a modern disk.
Wrong. Almost all of these limits effect OSs on old hardware/firmware, and don't effect OSs on new hardware/firmware. The only limit that effects old OSs on new hardware is "BIOS Int 13 - the 8.5 GB limit" which is exactly what I already described.

Your assumption that an OS will have trouble with the partition table is idiotic - an OS only needs to access its own partitions and doesn't/shouldn't care about partitions that don't belong to that OS and won't decide to trash the MBR simply because it didn't understand something it had no reason to care about. Yes; an old disk partitioning utility might complain, but any sane user wouldn't use an old disk partitioning utility to begin with.
mallard wrote:Not to mention the various other reasons why old OSs often fail on modern systems (lack of USB support meaning no input devices available, CPU speed too fast for old timing code, etc, etc.).

The chances of an OS from before around 2000 working properly on a modern system is pretty slim.
For something like MS-DOS (which mostly uses BIOS) and Win9x (which will fall back to BIOS for disk and VBE) most things will work fine.

Don't forget that BIOS emulates some old things (e.g. emulating PS/2 keyboard and mouse when there's only USB keyboard and mouse; emulating PIT when there's only HPET, etc) and some devices also emulate legacy devices (video cards emulate VGA, some hard disk controllers emulate ancient IDE/ATA, etc).

Things that probably won't work are network cards, sound cards, CD/DVD and USB flash; but an OS can be used without these, and nothing prevents people from writing device drivers that didn't exist.
mallard wrote:
Brendan wrote:For an OS that use "int 0x13 extensions" (that were introduced in the 1990's; long before Microsoft decided to force their personal "disk signature" hack on everyone else) that ~8 GiB limit disappears.
The disk signature was introduced in 1993, the "BIOS Enhanced Disk Drive Specification" (aka INT 13h extensions) was introduced by Phoenix in 1994 or 1995 (oldest PDF I can easily find is version 1.1 dated May 9, 1995), so Microsoft's signature predates it.
See above - when Microsoft started using the disk signature in their own MBR is irrelevant.


Cheers,

Brendan

Re: Check if device is bootable

Posted: Fri Nov 13, 2015 11:05 am
by mallard
Brendan wrote: I don't know when they decided to tamper with MBRs that Windows did not create (and has no right to modify) that either belong to other OSs or no OS at all (e.g. boot manager). This is not acceptable, regardless of when they decided to do it.
The MBR (at least prior to the publication of standards like UEFI) was created by Microsoft/IBM for their use alone. There was no intention to support other OSs or dual-booting. If the PC was to run a different OS, it was expected to use a different structure. The fact that other OSs managed to hack this structure to live alongside Microsoft and IBMs OSs is simply a hack. A hack that Microsoft (and IBM) have absolutely no obligation to support.
Brendan wrote:If an OS lets applications modify arbitrary sectors of the disk (including areas that the OS itself has no right to modify) then that OS is a security disaster; and that definitely is Microsoft's fault.
Are you serious? You want an OS to make it impossible to access the raw disk? So, if I add a new disk to my system (or want to erase another OS, resize partitions, install/update my bootloader, etc.), I can't; because that would involve changing "arbitrary" sectors of the disk. Think before you type.
Brendan wrote:It's not; it's obviously something UEFI "shoehorned" in for the sake of Microsoft
How/why it's in the specification is irrelevant. It's in there, like it or not.
Brendan wrote:Traditionally (for systems intended to have multiple OSs installed) you'd have some sort of boot manager (like PLOP or Smart BootManager or GAG or XOSL or LILO or GRUB); you'd install an OS in its partition, then tell that boot manager how to boot that new OS. The MBR-booted GPT scheme is no different.
It would be nice if things could work that way, but since there are absolutely no standards as to how an OS installer is supposed to "register" with one of those boot managers and it's impractical for an OS installer to have knowledge of all of them (and impossible for it to know about ones that postdate it), there is no practical alternative to replacing the boot code. Some Linux distributions manage to migrate existing GRUB configurations (but still replace the current version of GRUB), but that's as good as it gets.
Brendan wrote:Of course it's nice for an OS installer to offer to install an MBR (e.g. possibly a simple thing only capable of booting one OS) so that people who only want that one OS don't need to worry about it. Sadly, this is yet another case where Microsoft assume they own the world and urinate on everyone else by always replacing the MBR (and not giving the user a choice). Fortunately this is also something that UEFI solves.
It would be nice if Windows had a "don't update the MBR" option for the installer, but it's a very minor thing. The vast majority of people with a non-Windows MBR both expect that reinstalling Windows will erase it and know how to restore it. It's not something that the average user (who doesn't dual-boot, doesn't run anything but Windows) is going to have problems with.
Brendan wrote:According to Wikipedia's MBR page "Windows NT (and later Microsoft operating systems) uses the disk signature as an index to all the partitions on any disk ever connected to the computer under that OS". According to Mark Russinovich's blog post (in the Disk Signature Collisions section) "When you chose the Online menu option, Windows will without warning generate a new random disk signature and assign it to the disk by writing it to the MBR". I'm sure there's plenty of other sources of information saying that windows does write to the MBR of disks (even when you're not installing Windows on that disk).
If you want to use a disk with Windows, it requires a unique signature. That's not unreasonable. It's no different from the requirement that you use a filesystem that Windows understands. Connecting a disk with Windows on it to a non-Windows system won't magically affect any other disk. Only booting that disk and selecting to start the Windows installer will do that.
Brendan wrote:The only limit that effects old OSs on new hardware is "BIOS Int 13 - the 8.5 GB limit" which is exactly what I already described.
Nope. Any OS that expects the BIOS-reported geometry to match the physical geometry will be limited to 528MB (this includes such things as the 32-bit IDE driver in Windows 3.11), an OS that has a 256 head limit (e.g Windows 95) will be limited to 4.2GB, an OS that stores the number of heads in a 16-bit value will be limited to 33.8GB and an OS that only supports 28-bit LBA will be limited to 137GB.

I will admit that I neglected to remember MS-DOS in the "pre-2000" comment. MS-DOS relies entirely on the BIOS, so it's a testament to the BIOS developers that they've kept it compatible. However, running any of the more advanced MS-DOS applications/games is very likely to run into issues on modern systems (lack of PS/2 hardware, CPU too fast, disk drive geometry is "invalid", etc.)

Re: Check if device is bootable

Posted: Fri Nov 13, 2015 1:00 pm
by Brendan
Hi,
mallard wrote:
Brendan wrote:I don't know when they decided to tamper with MBRs that Windows did not create (and has no right to modify) that either belong to other OSs or no OS at all (e.g. boot manager). This is not acceptable, regardless of when they decided to do it.
The MBR (at least prior to the publication of standards like UEFI) was created by Microsoft/IBM for their use alone. There was no intention to support other OSs or dual-booting. If the PC was to run a different OS, it was expected to use a different structure. The fact that other OSs managed to hack this structure to live alongside Microsoft and IBMs OSs is simply a hack. A hack that Microsoft (and IBM) have absolutely no obligation to support.
Wrong. IBM and Microsoft had multiple operating systems for the PC (e.g. Xenix, CP/M-86) and designed the partitioning and MBR scheme to allow for the possibility of multiple OSs for their own benefit. Once established as a de facto standard everyone involved has an obligation to comply with that standard for inter-operability. For Microsoft this isn't necessarily just an ethical obligation - it could be considered a legal obligation imposed by competition law.
mallard wrote:
Brendan wrote:If an OS lets applications modify arbitrary sectors of the disk (including areas that the OS itself has no right to modify) then that OS is a security disaster; and that definitely is Microsoft's fault.
Are you serious? You want an OS to make it impossible to access the raw disk? So, if I add a new disk to my system (or want to erase another OS, resize partitions, install/update my bootloader, etc.), I can't; because that would involve changing "arbitrary" sectors of the disk. Think before you type.
Yes, I'm perfectly serious. It's not my fault if you're too stupid to understand the difference between normal applications and system utilities (that are typically included as part of the OS because they do need special access, unlike normal applications).
mallard wrote:
Brendan wrote:Traditionally (for systems intended to have multiple OSs installed) you'd have some sort of boot manager (like PLOP or Smart BootManager or GAG or XOSL or LILO or GRUB); you'd install an OS in its partition, then tell that boot manager how to boot that new OS. The MBR-booted GPT scheme is no different.
It would be nice if things could work that way, but since there are absolutely no standards as to how an OS installer is supposed to "register" with one of those boot managers and it's impractical for an OS installer to have knowledge of all of them (and impossible for it to know about ones that postdate it), there is no practical alternative to replacing the boot code. Some Linux distributions manage to migrate existing GRUB configurations (but still replace the current version of GRUB), but that's as good as it gets.
An automated method that OSs, viruses and rootkits could use to automatically convince the boot manager to boot them would be "nice". However; the OS installer doesn't really need to do any of this (unless it's also installing an MBR) and the user simply tells the boot manager themselves after installing the OS. It's not like it's hard or time consuming for users to do. Note that most of the boot managers I linked to have the ability to auto-detect installed OSs anyway.
mallard wrote:
Brendan wrote:Of course it's nice for an OS installer to offer to install an MBR (e.g. possibly a simple thing only capable of booting one OS) so that people who only want that one OS don't need to worry about it. Sadly, this is yet another case where Microsoft assume they own the world and urinate on everyone else by always replacing the MBR (and not giving the user a choice). Fortunately this is also something that UEFI solves.
It would be nice if Windows had a "don't update the MBR" option for the installer, but it's a very minor thing. The vast majority of people with a non-Windows MBR both expect that reinstalling Windows will erase it and know how to restore it. It's not something that the average user (who doesn't dual-boot, doesn't run anything but Windows) is going to have problems with.
Yes it'd be nice; and yes it's only a very minor/subtle method that Microsoft uses to make the use of alternative OSs more hassle than necessary for end users.
mallard wrote:
Brendan wrote:According to Wikipedia's MBR page "Windows NT (and later Microsoft operating systems) uses the disk signature as an index to all the partitions on any disk ever connected to the computer under that OS". According to Mark Russinovich's blog post (in the Disk Signature Collisions section) "When you chose the Online menu option, Windows will without warning generate a new random disk signature and assign it to the disk by writing it to the MBR". I'm sure there's plenty of other sources of information saying that windows does write to the MBR of disks (even when you're not installing Windows on that disk).
If you want to use a disk with Windows, it requires a unique signature. That's not unreasonable. It's no different from the requirement that you use a filesystem that Windows understands. Connecting a disk with Windows on it to a non-Windows system won't magically affect any other disk. Only booting that disk and selecting to start the Windows installer will do that.
If you want to use one partition and not the whole disk from Windows, it magically trashes your MBR for no sane reason just because they were too stupid to put a signature in their own file system where it belongs (and where it would serve the purpose of persistent drive letters far better)?
mallard wrote:
Brendan wrote:The only limit that effects old OSs on new hardware is "BIOS Int 13 - the 8.5 GB limit" which is exactly what I already described.
Nope. Any OS that expects the BIOS-reported geometry to match the physical geometry will be limited to 528MB (this includes such things as the 32-bit IDE driver in Windows 3.11), an OS that has a 256 head limit (e.g Windows 95) will be limited to 4.2GB, an OS that stores the number of heads in a 16-bit value will be limited to 33.8GB and an OS that only supports 28-bit LBA will be limited to 137GB.
The number of OS's that expect the BIOS-reported geometry to match the physical geometry is zero.
mallard wrote:I will admit that I neglected to remember MS-DOS in the "pre-2000" comment. MS-DOS relies entirely on the BIOS, so it's a testament to the BIOS developers that they've kept it compatible. However, running any of the more advanced MS-DOS applications/games is very likely to run into issues on modern systems (lack of PS/2 hardware, CPU too fast, disk drive geometry is "invalid", etc.)
Like I already said, the firmware in modern systems emulate PS/2 when there's only USB keyboard and mouse. "CPU too fast" only effects extremely poorly designed games and not normal applications or any OS. Disk geometry is irrelevant.

The only potential issue is that some old games used special "anti-disk copying" techniques to prevent users from copying their floppy disk; which is a problem on modern hardware because computers don't have floppy drives any more.


Cheers,

Brendan

Re: Check if device is bootable

Posted: Sat Nov 14, 2015 1:23 am
by Octocontrabass
Brendan wrote:The number of OS's that expect the BIOS-reported geometry to match the physical geometry is zero.
False. Some operating systems rely on the BIOS reporting the correct physical geometry in order to access the disk.

Re: Check if device is bootable

Posted: Mon Nov 16, 2015 4:13 am
by mallard
Brendan wrote: Wrong. IBM and Microsoft had multiple operating systems for the PC (e.g. Xenix, CP/M-86) and designed the partitioning and MBR scheme to allow for the possibility of multiple OSs for their own benefit.
I'm not sure how that's "wrong". I said that IBM/Microsoft designed the MBR scheme "for their use alone" and you're saying "for their own benefit". That's the same thing. Dual-booting still almost certainly wasn't a design goal. At best they may have considered that users might dual-boot DOS and one other OS, such as Xenix or OS/2, but that was almost certainly something that the developers of those OSs "hacked" after the fact.

Also CP/M-86 wasn't an IBM/Microsoft OS, but also was only an official option with the original hard-drive-less IBM PC, not the PC/XT that introduced hard drives and the MBR.
Brendan wrote: Once established as a de facto standard everyone involved has an obligation to comply with that standard for inter-operability. For Microsoft this isn't necessarily just an ethical obligation - it could be considered a legal obligation imposed by competition law.
When the MBR scheme was invented in 1983 (for the PC/XT), neither Microsoft or IBM were in a "dominant" position in the PC market. 8-bit systems such as the Commodore 64 or Atari 400/800 series outsold PCs and PC-compatibles by orders of magnitude until the late 1980s.
Brendan wrote: Yes, I'm perfectly serious. It's not my fault if you're too stupid to understand the difference between normal applications and system utilities (that are typically included as part of the OS because they do need special access, unlike normal applications).
So you're saying that no OS should allow any third-party disk management, backup or cloning tools? No OS should allow a third-party boot manager to be installed? Considering that you're advocating third-party boot managers in your next point, I find your argument logically inconsistent.
Brendan wrote:However; the OS installer doesn't really need to do any of this (unless it's also installing an MBR) and the user simply tells the boot manager themselves after installing the OS. It's not like it's hard or time consuming for users to do.
Well, you can answer all the support calls from users who've "installed" a new OS, but can't boot it then. Leaving the user with a "you appear to have an unrecognised boot manager installed, please configure it yourself to complete the installation" type message is an awful user experience. Not to mention users who actually just have a corrupted MBR and were re-installing the OS in an attempt to fix it (and didn't understand what the "do you want to overwrite the MBR (this may make any installed OS unbootable)?" message meant, so selected "no" because your OS installer made that the default).
Brendan wrote:Note that most of the boot managers I linked to have the ability to auto-detect installed OSs anyway.
Some can, some can't. Most of the boot managers' installers have the ability to detect currently-installed OSs and pre-configure them, but many cannot do it on-the-fly. You're also assuming that the installed boot manager is even compatible with a newly-installed OS, which isn't always the case.
Brendan wrote: because they were too stupid to put a signature in their own file system where it belongs (and where it would serve the purpose of persistent drive letters far better)?
I'm sure that if that solution solved the problem that they were faced with, they would have done it. It's quite likely that they needed to be able to uniquely identify disks with no supported filesystems or only legacy filesystems and needed the identifier to persist when partitions were added/removed. They almost certainly also tested this with various "alternative" MBRs that were around at the time and found it not to cause problems.
Brendan wrote:The number of OS's that expect the BIOS-reported geometry to match the physical geometry is zero.
Since both I and Octocontrabass gave actual examples of this (the article he linked mentions 286 Xenix and Novell Netware, as well as related "complications" that make dual-booting with SCO Unix or slightly later versions of Netware very difficult indeed). This Microsoft article confirms the issue for Windows 3.11:

"In Windows and Windows for Workgroups versions 3.1 and later, 32-bit disk access is provided by a FastDisk driver called WDCTRL. WDCTRL compares the total number of cylinders specified for the hard disk in the CMOS memory in the BIOS Parameter Block (BPB) with the number of cylinders reported by the hard disk in response to an Identify Drive command. If the BIOS reports more than 1024 cylinders, WDCTRL validation does not work regardless of whether the system BIOS or bus adapter supports geometry translation or INT13h extensions."
Brendan wrote:"CPU too fast" only effects extremely poorly designed games and not normal applications or any OS.
Nope. It affects any application written in Turbo Pascal (for DOS), Windows 95, the BusLogic SCSI driver in old versions of Linux and I'm sure there are many other examples. The Windows 95 article also mentions a "too much RAM" issue, which another fairly common complication running old OSs on new hardware.

Re: Check if device is bootable

Posted: Mon Nov 16, 2015 1:40 pm
by Brendan
Hi,
mallard wrote:
Brendan wrote:Wrong. IBM and Microsoft had multiple operating systems for the PC (e.g. Xenix, CP/M-86) and designed the partitioning and MBR scheme to allow for the possibility of multiple OSs for their own benefit.
I'm not sure how that's "wrong". I said that IBM/Microsoft designed the MBR scheme "for their use alone" and you're saying "for their own benefit". That's the same thing. Dual-booting still almost certainly wasn't a design goal. At best they may have considered that users might dual-boot DOS and one other OS, such as Xenix or OS/2, but that was almost certainly something that the developers of those OSs "hacked" after the fact.
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.
mallard wrote:Also CP/M-86 wasn't an IBM/Microsoft OS, but also was only an official option with the original hard-drive-less IBM PC, not the PC/XT that introduced hard drives and the MBR.
"IBM PC DOS" wasn't written by IBM either. CP/M-86 was the OS IBM was planning to use for PC, but negotiations between IBM and CP/M-86's authors Digital Research didn't go well, so IBM had to settle for a lesser known CP/M clone called 86-DOS that was written by a company called Seattle Computer Products (which Microsoft purchased and ported to PC).
mallard wrote:
Brendan wrote:Once established as a de facto standard everyone involved has an obligation to comply with that standard for inter-operability. For Microsoft this isn't necessarily just an ethical obligation - it could be considered a legal obligation imposed by competition law.
When the MBR scheme was invented in 1983 (for the PC/XT), neither Microsoft or IBM were in a "dominant" position in the PC market. 8-bit systems such as the Commodore 64 or Atari 400/800 series outsold PCs and PC-compatibles by orders of magnitude until the late 1980s.
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).
mallard wrote:
Brendan wrote:Yes, I'm perfectly serious. It's not my fault if you're too stupid to understand the difference between normal applications and system utilities (that are typically included as part of the OS because they do need special access, unlike normal applications).
So you're saying that no OS should allow any third-party disk management, backup or cloning tools? No OS should allow a third-party boot manager to be installed? Considering that you're advocating third-party boot managers in your next point, I find your argument logically inconsistent.
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.

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.
mallard wrote:
Brendan wrote:However; the OS installer doesn't really need to do any of this (unless it's also installing an MBR) and the user simply tells the boot manager themselves after installing the OS. It's not like it's hard or time consuming for users to do.
Well, you can answer all the support calls from users who've "installed" a new OS, but can't boot it then. Leaving the user with a "you appear to have an unrecognised boot manager installed, please configure it yourself to complete the installation" type message is an awful user experience. Not to mention users who actually just have a corrupted MBR and were re-installing the OS in an attempt to fix it (and didn't understand what the "do you want to overwrite the MBR (this may make any installed OS unbootable)?" message meant, so selected "no" because your OS installer made that the default).
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).
mallard wrote:
Brendan wrote:Note that most of the boot managers I linked to have the ability to auto-detect installed OSs anyway.
Some can, some can't. Most of the boot managers' installers have the ability to detect currently-installed OSs and pre-configure them, but many cannot do it on-the-fly. You're also assuming that the installed boot manager is even compatible with a newly-installed OS, which isn't always the case.
Yes; I'm assuming OS developers are competent and comply with established standards that ensure compatibility (e.g. "chain loading").
mallard wrote:
Brendan wrote: because they were too stupid to put a signature in their own file system where it belongs (and where it would serve the purpose of persistent drive letters far better)?
I'm sure that if that solution solved the problem that they were faced with, they would have done it. It's quite likely that they needed to be able to uniquely identify disks with no supported filesystems or only legacy filesystems and needed the identifier to persist when partitions were added/removed. They almost certainly also tested this with various "alternative" MBRs that were around at the time and found it not to cause problems.
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.
mallard wrote:
Brendan wrote:The number of OS's that expect the BIOS-reported geometry to match the physical geometry is zero.
Since both I and Octocontrabass gave actual examples of this (the article he linked mentions 286 Xenix and Novell Netware, as well as related "complications" that make dual-booting with SCO Unix or slightly later versions of Netware very difficult indeed).
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.
mallard wrote:
Brendan wrote:"CPU too fast" only effects extremely poorly designed games and not normal applications or any OS.
Nope. It affects any application written in Turbo Pascal (for DOS), Windows 95, the BusLogic SCSI driver in old versions of Linux and I'm sure there are many other examples. The Windows 95 article also mentions a "too much RAM" issue, which another fairly common complication running old OSs on new hardware.
Am I supposed to care; or did you just have nothing better to do with your time than to find excuses for pathetic whining that has nothing to do with the actual issue (Microsoft inflicting their boot signatures on the world)?


Cheers,

Brendan

Re: Check if device is bootable

Posted: Tue Nov 17, 2015 4:37 am
by Antti
About old operating systems, I wrote if we were honest, we would just be impressed by how well they work in general. However, the expedition took off and we are in pursuit of the compatibility problems. At the same time we are putting aside the big picture which, in my opinion, shows us a unique and impressive effort for making the platform backwards compatible. Maybe all the facts are not on my side but I think they have succeeded in this.
Brendan wrote:Am I supposed to care; or did you just have nothing better to do with your time than to find excuses for pathetic whining that has nothing to do with the actual issue (Microsoft inflicting their boot signatures on the world)?
Although this has nothing to do with the actual issue, we have off-topic discussions all the time. Labeling this single remark as pathetic whining is a little bit rude. When it comes to the "CPU too fast" issue, the remark defended mallard's views on the matter and is perfectly in line with our discussion quality.

It is a little bit surprising that "CPU too fast" really had effect on OSs and applications that were not considered "extremely poor" at their time. Of course they would be extremely poor in that sense but not if we kept a sense of proportion. In the early years, CPU performance was increasing very significantly in a short time so it would had been reasonable to cut out all the dependencies on it. Fortunately, almost all did this! That is why we can use those old operating systems/applications and be surprised at how well they work in general. Therefore the original claim, "the chances of an OS from before around 2000 working properly on a modern system is pretty slim", is not true although someone could argue what that "slim" means.

Re: Check if device is bootable

Posted: Tue Nov 17, 2015 4:45 am
by mallard
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...

Re: Check if device is bootable

Posted: Tue Nov 17, 2015 5:51 pm
by Brendan
Hi,
Antti wrote:
Brendan wrote:Am I supposed to care; or did you just have nothing better to do with your time than to find excuses for pathetic whining that has nothing to do with the actual issue (Microsoft inflicting their boot signatures on the world)?
Although this has nothing to do with the actual issue, we have off-topic discussions all the time. Labeling this single remark as pathetic whining is a little bit rude. When it comes to the "CPU too fast" issue, the remark defended mallard's views on the matter and is perfectly in line with our discussion quality.
I just get annoyed when there's a single issue (whether or not Microsoft has the right to force their OS's silly hack onto all competing OSs in part of the disk that must be shared and isn't "owned" by any OS), and someone (mallard) fragments the conversation into 100 different side issues for the sole purpose of complaining for each of those 100 different side issues while ignoring the main issue; and does so using illogical/nonsensical arguments.

Let's analyse his most recent post and I'll show you what I mean...
mallard wrote:
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)?
This introduces yet another irrelevant side-issue using the fallacy that "other" is the same as "all".
mallard wrote: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.
This is both unsubstantiated and nonsensical - if the disk/s were intended to be used by one and only one OS there's no point having partitions in the first place; so the partitioning system must have been designed for multiple OSs.
mallard wrote: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.
This is more illogical stupidity. Just because an OS ships with a simple MBR (intended for users that only use one OS) doesn't imply that the OS couldn't be used for dual boot (e.g. using a third party boot manager) or that the partitioning system wasn't designed to allow a third party boot manager to be instead of the MBR that any OS ships with.
mallard wrote: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.
This is the introduction of another irrelevant side-issue. What happened before the "de facto" MBR partitioning scheme became accepted practice has nothing to do with what happened after the "de facto" MBR partitioning scheme became accepted practice.
mallard wrote: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".
This is more illogical stupidity. Originally ancient OSs used the entire disk (just like a floppy still does, without partitions); and if the MBR partitioning scheme was intended for a single OS only there would've been no point having partitions, and no reason to break compatibility by shifting the OS's boot loader into the start of a partition.
mallard wrote:
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).
This is known as a "straw man" fallacy - pretending to refute my argument (whether or not IBM PC DOS was originally written by IBM) when actually refuting a very different argument (who ported and maintained it long after it was first written).
mallard wrote:
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.
This paragraph begins with a false analogy fallacy (incorrectly assuming that how a monopolist treats competitors is analogous to how they treat allies); then continues with an obvious untruth (Microsoft do put a significant amount of effort into ensuring backward compatibility for applications designed for their previous OSs); then finishes with a genetic fallacy (assuming that the origin of the MBR is relevant after it became established as a de facto standard).
mallard wrote:
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.
This is a "wrong direction" fallacy; where the cause (Microsoft failed to implement any of many ways to uphold the the principle of least privilege) is assumed to be the effect; and the effect (Microsoft's security is crap because they can't tell the difference between system utilities and normal applications) is assumed to be the cause.
mallard wrote:
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.
This is a fallacy of composition. The first part is true ("if boot manager's installer is not bootable and if OS doesn't allow raw disk access for all software; then its impossible to install boot manager") but that does not in any way imply that all parts are true.

Essentially; it tries to say "if boot manager's installer is not bootable and if OS doesn't allow raw disk access for all software; then its impossible to install boot manager even when boot manager's installer is bootable and even when OS does allow raw disk access for some software".
mallard wrote:
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?
This is another "straw man" fallacy. I argue that people who do install multiple OSs are able to figure out the boot manager they've chosen; and mallard misrepresents my argument as "all people, including those that never install multiple OSs and have no reason to use a third party boot manager, are able to figure out their boot manager".
mallard wrote: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.
This is the first, last and only thing mallard has said that's logical. Of course it's just an extension of what I already said previously (an OS can/should provide the option to install a default MBR to make things easier for people that only care about a single OS).
mallard wrote:
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?
This begins with an outright lie (I'm not resistant to established standards, and am in fact arguing that Microsoft should have followed the established de facto standard). This is followed by fiction (the implication that I'm confident that every other developer respects standards and/or is competent that is without any basis).
mallard wrote:
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.
This is "red herring". Whether or not anything was effected by an action has nothing to do with whether or not that action is right/ethical.
mallard wrote:
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...
This is "red herring" again (trying to draw attention away from the subject of argument by introducing yet another irrelevant argument), compounded by the fact that it's a response to an attempt at pointing out a previous red herring that "misses the point entirely".
mallard wrote:
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...
This is implying causation from correlation - implying that there's a correlation between me not caring and being wrong. The fact is that there are many solutions to speed problems (e.g. like this one) and I was not proven wrong; and I did not stop caring about the issue and have only stopped caring about mallard.


Cheers,

Brendan