....and another response just in....\n(interleaved - from Chris Quirke - MVP)\n-\- \nNoel Paton (MS-MVP 2002-2006, Windows)\n\nNil Carborundum Illegitemi\n[URL]http://www.crashfixpc.com/millsrpch.htm[/URL]\n\n[URL]http://tinyurl.com/6oztj[/URL]\n\nPlease read [URL]http://dts-l.org/goodpost.htm[/URL] on how to post messages to NG's\n[QUOTE]\nSubject: Re: FDISK /MBR question\n[/QUOTE]\n\nTrue. It is OS-agnostic, system-level code. If you mark an MS extended \npartition as active, it will boot it (i.e. run code in the first sector of \nthe extended partition, which will typically lock up the PC).\n\nTrue. I haven't checked the 460-byte figure, but it sounds correct.\n\nTrue - if you are dealing with standard MBR code. But that code can be \nanything, and thus do anything. Non-standard MBR code include malware, boot \nmanagers, DDO driver code, and possibly other utils such as disk encryption \nor system diagnostics. Such code may use an alternate partition table \nlocation and/or structure, or not parse any tables for OSs at all. For \nexample, if I were a PC maker that was not committed to any particular OS, I \ncould drop 20M of system diags into the first sectors of the physical drive \nand run this code directly, with no OS, partitions or file system present at \nall.\n\nTrue. Drive letters, files, file systems and logical volumes are all \nOS-level concepts, unknown to OS-agnostic system-level code such as MBR.\n\nHe's losing the plot here. Additional caveat; absence of 55AAh boot sig in \nMBR causes FDisk /MBR to zero out the partition table. Malware can move \npartition table to another sector and/or encrypt it, not just change the \noffset. Boot managers such as BING may use different table structure to \nsupport more partitions, either via the "standard" table, or directly.\n\nIn any case, none of this system-level code knows what OS is in a partition, \nbecause it is not this code that reads the partition type byte; that is done \nby whatever OS loads from the partition boot record. Some boot managers may, \nas a "courtesy", enumerate partitions according to OS type byte, but can \nonly do so for those types known to the utility.\n\nAt this level, there is no such thing as "primary" vs. "extended" \npartitions; that, too, is an OS-level concept peculiar to MS OSs and those \nthat use the same conventions as MS OSs. FDisk understands logical volumes \nonly because it is an OS tool, as much as it is a system tool.\n\nMmmmh. In that the OS starts from the first byte of the partition, it is \nindeed the MBR code's role to initiate the loading of the OS. You can think \nof MBR as a "soft" extension of the BIOS.\n[QUOTE] \nTrue.\n[/QUOTE]\n\nTrue - but this is only an expectation; it can do anything it likes, e.g.\n\na malware there may trash the HD's contents as a payload. I see this code as \nbeing part of the OS itself, even though it is not a file within the OS's \nfile system (as the concept "file system" has yet to be built)\n\nIt is expected to behave in the same way. The expectation is that MBR code \ndropped by any OS will be functionally interchangeable, as this is supposed \nto be OS-neutral territory. FDisk is part of DOS rather than Win3.yuk, \nthough Win3.yuk often drops newer versions of certain DOS files such as \nHiMem.sys, Emm386.exe etc. There was always version leapfrog between various \nDOS and Win3.yuk versions.\n\nTrue. This is why it's so attractive a place to overcome BIOS address \nlimitations via a Dynamic Drive Overlay. This extends BIOS's ability to \naddress the HD, so that partition that are "too big" or too far up the \naddress space can be reached. The OS can either take over the addressing of \nthe HD, or use the DDO's interrupt services in place and use these instead \nof the broken code within system BIOS.\n\nLooks like the dude knows what he's talking about, though isn't quite as \nclear as he should be (he has the concepts, but they are not really \nhard-coded into place).\n\nSee [URL]http://cquirke.mvps.org/9x/startup.htm[/URL] (yes, it's the Win9x startup \naxis, but it starts from PSU PowerGood and thus covers this system-level MBR \nstuff).\n\nI'm lucky in that I was aware of these issues from my first week on the PC, \nas I started off mainly in PICK R83 with DOS 3.3 as a sideline. Most folks \nstart off with one vendor's OSs only, and thus don't have a clear idea of \nwhere the system ends and the OS should begin, and how multiple OSs are \nsupposed to co-exist.