Octocontrabass wrote:
kerravon wrote:
That's pretty rude. For what reason does the bios need to have knowledge of the internal details of the MBR?
Isn't that the sole prerogative of the MBR code?
The BIOS examines the MBR on a USB flash drive to decide whether the drive is bootable, whether INT 0x13 should treat it like a floppy disk or a hard disk, and what the INT 0x13 CHS geometry should be. This is done both to prevent booting from a drive that isn't bootable and to ensure compatibility with software that was written before USB existed.
Oh, I wasn't aware I could put a floppy image on a USB stick. That's great. I'll give it a try.
Quote:
UEFI needs to examine the partition tables to load a file from a partition. In theory, UEFI should prefer El Torito over MBR regardless of media, but who knows how well vendors follow that part of the specification...
Oh, I wasn't expecting El torito, I was expecting my mbr code to be executed. Basically I am designing for a 1995 bios with advance knowledge of El torito.
If the bios detects El torito and bypasses my fake mbr, will it actually give me a writable hard disk or will it make it read only like a normal cd?
Quote:
kerravon wrote:
Yes, I am planning on standardizing on El torito everywhere.
That seems like a bad idea. The UEFI specification says this should be fine, but I expect you will have problems with real hardware since firmware authors only bother to test Windows.
I don't really care if pdos doesn't work on buggy bioses. So long as it is clearly the bios that is violating protocol, someone can report the bug to the vendor.
If the vendor doesn't care, then select a different vendor when buying a pc.
Quote:
kerravon wrote:
Also note that my hard disk image will be a vhd so that it can be extracted from the iso and mounted on windows.
What happens when you write a small ISO to a big flash drive? Is the rest of the space unusable?
My fdisk program only handles a single partition currently, and the pdos mods haven't even started yet, but there is no reason why additional partitions can't be added after the event by fdisk.
fdisk will need to have knowledge of the additional vhd sectors plus the 2048-512 padding after the vhd.