Wandering Thoughts archives

On how PCs boot and hard disk partitioning

Starting from the very early days, PCs have booted in a very simple manner: the PC BIOS found the boot disk, loaded the first 512 byte sector from it into memory, verified that it had a valid MBR signature, and then jumped to the start of the sector (which had better be code). That was it. The code in the boot sector was responsible for doing everything else, calling on BIOS services as necessary for things like reading more data from the disk.

(Generally the code in the first sector is just smart enough to load the rest of the bootloader's code from disk. It's the second stage code, or sometimes even third stage code, that is capable enough to do all sorts of traditional bootloader things like displaying menus and so on.)

This simplicity means that in theory, a PC BIOS is completely agnostic about the presence and contents of the traditional MBR partition table (which under normal circumstances is located at the end of the first sector, reducing the amount of space available for MBR boot code somewhat). The MBR partition table and extended partitions only matter to the boot code, the OS, and any tools that you use, so you could replace them with another partitioning scheme entirely if you wanted to and everything agreed on it. I believe that this was (and is) sometimes done by various Unixes.

(In practice there are undoubtedly PC BIOSes that do care about the MBR partition table and get upset if it isn't there or isn't right. Also, a non-MBR partitioning scheme will make any MBR-based tool think that your disk is unpartitioned, so most OSes with their own partitioning schemes embed them inside one or more MBR partitions.)

Since MBR partitioning is a convention, you can replace it with another one without affecting how PCs boot (especially if you leave behind a more or less fake MBR to pacify MBR-aware things). You don't even need the BIOS's cooperation, you can do it entirely on your own.

(Note that some BIOSes, especially laptop BIOSes, have features that know about hidden MBR partitions and so on that are used for stuff like special recovery modes. I believe that this is generally separate from actually caring about them for ordinary booting.)

Sidebar: Linux and partitioning

Linux is unusual as a PC Unix in that it does not have its own partitioning scheme but uses normal PC primary and extended partitions. I believe that the reason for this is essentially historical. All of the other PC Unixes descend from ancestral Unix versions that already had their own disk partitioning schemes when they were ported to PCs. The simple way to do these ports was to embed the existing partitioning scheme inside a PC partition and then add a little bit of extra code to find it, rather than rewrite the entire disk partition handling code to take information from either the PC partitions or the Unix's own disk partition scheme.

(These Unixes generally did not want to throw away their existing partitioning schemes, partly because they wanted to be portable to non-PC systems and partly because they had a lot of existing tools, documentation, and practice that worked with the current partitioning schemes. Some of the resulting workarounds are a bit awkward.)

By contrast Linux started from scratch with no existing disk partitioning scheme to carry over into the PC world. So it made perfect sense to use the existing PC partition stuff (which Linux needed to understand a bit of anyways) rather than invent an entire new layer of disk partitioning.

My mouse button bindings in fvwm, my window manager

I've previously described my X Windows window manager as highly customized. If you've looked at the picture of my desktop, this may sound a little bit overdone; sure, it looks different, but a lot of that is just running custom programs and a fair amount of the rest of it is ultimately chrome and not crucially important. As it happens, the visual appearance of my desktop is just the tip of the iceberg; most of my really hard to part with customizations are in mouse and keyboard bindings. Today I'm going to run down my commonly used unusual mouse bindings, as an example both of what I do and of what you can do in fvwm.

(I'm going to skip conventional mouse button bindings, the sort of thing that people find perfectly normal and predictable.)

To start with, I should note that mouse button bindings in fvwm can be different in different contexts, and also be made conditional on various modifier keys. This can lead to a huge and bewildering number of different mouse bindings, as you are about to see.

The left mouse button:

• with plain Alt, it raises the the window I'm over.
• with Shift+Alt, it iconifies the window I'm over.

The middle mouse button:

• with plain Alt, it moves the window I'm over.
• with Shift+Alt on the root window, it switches me back to the previous virtual screen I was on. Repeatedly clicking it will flip back and forth between two virtual screens.
• by itself on the root window, it brings up my main application menu.
• with Control on the root window, it brings up a menu of things I can do with the current X selection (such as use it as an URL or Google it).
• when I am placing a new window, it lets me resize the window as it's being placed.

The right mouse button:

• by itself on the root window or anywhere with Alt, it brings up my main menu (which has various window management operations, lets me start xterm, and cascades to all of my other menus). One of the things I use this for is conveniently resizing windows.
• with Control on the root window, it brings up a menu of 'root on host <X>' for commonly used hosts.
• when I'm placing a window, it immediately locates the window where the mouse is and extends it down to the bottom of the screen. This is a very convenient way to get tall terminal windows.

(In window titlebars (for windows that have them), the left mouse button raises and possibly moves the window, the middle mouse button moves the window, and the right button lowers it.)

Pretty much all of these bindings are completely ingrained and unconscious by now; generally I couldn't possibly tell you what the bindings actually are, even as I'm using them. I can write them down now only because I carefully read through my fvwm configuration file.

The functionality in these bindings may strike you as incomplete; for example, I can use a mouse button to raise a window but not to lower it. Part of this is because I also have keyboard bindings in addition to mouse bindings and for some things I generally work through the keyboard bindings instead. Part of this is just because I don't want to steal too many mouse bindings from programs.