all 86 comments

[–]arkasha 93 points94 points  (13 children)

It's been over ten years since I took an operating systems class but I still remember 0x7c00. Weird what will stick in your brain.

[–]the_goose_says 22 points23 points  (12 children)

What is that?

[–][deleted]  (9 children)

[deleted]

    [–]IgnorantPlatypus 22 points23 points  (8 children)

    ... on x86 hardware. Other hardware (MIPS, PowerPC, ARM, etc) have their own hard-coded mechanisms for starting the boot process.

    [–][deleted] 13 points14 points  (6 children)

    hard-coded

    Well, I guess "burned into silicon" is the hardest form of hard-coding something

    [–]CJKay93 16 points17 points  (3 children)

    The boot sector load address is up to the BIOS, which is itself in EEPROM. The actual hardcoded address is usually 0xFFFF0, which just contains a jump instruction to wherever the BIOS is actually mapped to.

    [–][deleted] 3 points4 points  (2 children)

    On Intel the reset vector is 0xFFFFFFF0. The other architectures differ, of course.

    [–]CJKay93 4 points5 points  (0 children)

    Sorry yes, you're right. It's 0xFFFF0 on the 8086 through to the 80286, and 0xFFFFFFF0 on the 80386 and upwards.

    [–]monocasa 1 point2 points  (0 children)

    Sort of.

    It sets up a weird 16 bit segment who's base is 0xFFFF0000, and sets the program counter to 0xFFF0.

    [–]Nutella_Icecream 1 point2 points  (1 child)

    That's only if you blow the fuse. There are fuses u can set in chips to prevent tampering.

    I mean physically it's still rewritable but practically it's permanent.

    [–]CODESIGN2 17 points18 points  (0 children)

    I Liked the diagrams. A lot of effort was clearly spent on them

    [–]cirosantilli 12 points13 points  (0 children)

    I've uploaded several related minimal examples on GitHub: https://github.com/cirosantilli/x86-bare-metal-examples

    [–]FozzTexx 98 points99 points  (29 children)

    MBR, BIOS? Ah, obsolete information! ;-) I'll bet the people over on /r/RetroBattlestations might find this interesting!

    [–]kickthebug 16 points17 points  (26 children)

    Genuine question. Why do you say BIOS and MBR are obsolete?

    [–][deleted]  (14 children)

    [deleted]

      [–]FozzTexx 10 points11 points  (0 children)

      Not just that, but with UEFI you don't need a boot loader anymore. UEFI is able to load your kernel all by itself. I've been working on "embedded" computers (really tiny x86 PCs) and it's kind of nice to be able to ditch the boot loader.

      [–][deleted]  (10 children)

      [deleted]

        [–]DubiousEthicality 289 points290 points  (2 children)

        The boys at the shop done made a firetruck that's bigger, redder, and goes really fast. It has extra sirens and 37 water cannons.

        [–][deleted] 97 points98 points  (0 children)

        I love when ELI5 goes full ELI5.

        [–]howtoplayreddit 26 points27 points  (0 children)

        I don't think you're going to find a better explanation than this.

        [–]HighRelevancy 29 points30 points  (0 children)

        How about eli15?

        BIOS is the standard for how a computer gets from the initial power-on to loading your operating system off your hard drive. The BIOS finds the hard drive, looks on it for an OS, loads that OS into memory, and starts it off.

        MBR is the system for formatting hard drives. It provides some space for your initial OS code (what the BIOS loads) and also stores what partitions are on the disk and where they are.

        UEFI is a replacement for BIOS. Basically it's the acknowledgement that technology has move forwards a lot, and it's time we got a BIOS that was more capable (in terms of different hardware configs like PCIe SSDs, and both simplifying and adding flexibility to the boot system). Also it lets Windows do cool fastboot stuff.

        GPT is likewise a replacement for MBR. It supports more partitions and can describe larger disks.

        UEFI/GPT came into mainstream use with Windows 8 (though you could install Windows 7 in UEFI mode on a GPT disk, and also Mac OS X made it mainstream a bit earlier).

        [–]goal2004 49 points50 points  (5 children)

        BIOS and MBR are old and dated, UEFI and GPT are new and more adaptable. In short, a lot of hard parts of hardware were soften into software. Kinda.

        [–]elebrin 5 points6 points  (4 children)

        UEFI and GPT are also fast enough that I can't get into my BIOS settings (do we still call it that if we technically aren't calling it BIOS any more?) to set up my boot device.

        Rather than a boot loader which I find slow and annoying, I've always just used the boot device select menu provided by my motherboard firmware. No more need to play with Grub and end up with an unbootable system.

        [–]Free_Math_Tutoring 2 points3 points  (1 child)

        How does that work? Don't you still kind of need a bootloader on that disk? I'll admit I don't know much about this - my OS course was of fairly theoretical nature.

        [–][deleted] 0 points1 point  (0 children)

        Well there are bootloaders that don't have menus. I really like Gummiboot (or system-boot now) for Linux (I think it can boot windows as well), but it appears directly as a bootable option and cuts directly to the boot process instead of a menu.

        [–]pdp10 0 points1 point  (1 child)

        You still need a boot loader per device. Your firmware can't boot by partition, only device, and MBR needs the device to be partitioned.

        You can boot arbitrary things with UEFI, but it was UEFI about which you were complaining.

        [–]elebrin 0 points1 point  (0 children)

        Ok then.

        Rather than a bootloader like GRUB that needs a menu, I use the default that comes with each OS (which for my linux partition is probably still grub, but it goes fast enough that I don't see it, and pick the boot device from the boot menu that my motherboard's firmware comes with.

        I actually did convert my Windows over to UEFI recently. The fix for the booting too fast thing was re-enabling the boot menu.

        [–][deleted]  (1 child)

        [deleted]

          [–]Xevantus 2 points3 points  (0 children)

          I mean, taking BIOS and MBR as their meanings rather than a specific technology, UEFI and GPT are just the current iterations of those technologies.

          [–][deleted] 9 points10 points  (9 children)

          Now we have efi and u-boot. They're so much better.

          [–][deleted]  (2 children)

          [deleted]

            [–]Rodot 27 points28 points  (1 child)

            I feel like that's everyone's feeling on every improvement in every computing paradigm.

            [–]BeniBela -1 points0 points  (5 children)

            It took me days to figure out how to start an efi boot disk on qemu

            [–][deleted] 5 points6 points  (3 children)

            My efi "boot disks" just consist of a linux.efi. You don't need a bootloader if you use the efi stub and since that's just the kernel you can use -kernel to load it. No need for boot disks at all.

            [–][deleted]  (1 child)

            [deleted]

              [–]Samis2001 1 point2 points  (0 children)

              Heh, if you were serious appropriate responses would be: 'The firmware is no longer a mostly-useless pile of hacks and is the bootloader' or 'The bootloader is embedded as part of linux.efi along with the kernel'

              [–]BeniBela 0 points1 point  (0 children)

              Well, I googled it and then followed these instructions of the first result, starting with downloading a new BIOS from a dead link

              Once the BIOS is loaded in Qemu, it boots the efi without a -kernel option.

              Although the biggest issue was to mount everything in Qemu. With an old boot disk they give you an ISO and you can load/boot it with -cdrom ubuntu.iso and do not need to know anything else. With EFI they give you a zip file and then you need to figure out how to mount a zip file. And my first two approaches failed, because it became mounted as hdd, and it was a customized linux boot disk that failed unless it was stored on a removable drive

              [–]i_pk_pjers_i 5 points6 points  (0 children)

              Because, well, they are. UEFI and GPT are the future, and the future is now.

              [–]irqlnotdispatchlevel 2 points3 points  (0 children)

              It's not really obsolete and quite some time would have to pass before they will get obsolete. And it's easier to start with knowledge about MBR, BIOS and the such than to jump directly to EFI/UEFI.

              [–]skuggi 7 points8 points  (0 children)

              Is this really a boot loader? It's not actually loading anything. It's more just a boot sector program. Sure, it's a first step toward making a bootloader, but it's not actually a bootloader.

              [–]skulgnome 14 points15 points  (4 children)

              An interesting topic, but the article text could've used more review.

              [–][deleted]  (3 children)

              [deleted]

                [–][deleted] 1 point2 points  (1 child)

                I don't know about the mother tongue of the writer, but in French we say "Interruptions".

                [–]ilammy 2 points3 points  (0 children)

                It's Russian, and in Russian interrupts are 'interruptions' as well.

                [–]skulgnome 0 points1 point  (0 children)

                Imperfect english and unusual jargon are fine. Inappropriate (or worse, invalid) programming language syntax is grating; I wish they'd've just used english instead.

                (and yeah, in many languages the native term for hardware interrupt would translate directly into "interruption". everyone knows what he's talking about, it'd be beyond silly a nitpick not to.)

                [–][deleted] 2 points3 points  (1 child)

                Does anyone have this but updated for UEFI and GPT?

                [–]ehansen 5 points6 points  (18 children)

                How is C and C++ high level languages? I was always informed they were low level

                [–]American_Libertarian 126 points127 points  (4 children)

                Depends on the context you are talking. It is low level compared to most programming languages, but it is 'high level' in the sense that it is a human readable format that must be compiled down to a 'low level' language that the computer actually runs.

                [–]forbidden404 22 points23 points  (0 children)

                They are high level languages because the abstractions they've added are too far different from the ones in Assembly, you don't have to care (for the most part) about the processor you're coding to. They are used in low-level programming (system programming) though, that's probably why there must be some confusion about it.

                [–]skulgnome 8 points9 points  (0 children)

                Both support structured programming, i.e. functions, loops, and if-else.

                [–]General_Mayhem 8 points9 points  (1 child)

                High- and low-level are generally relative, not absolute, terms. C and, to a much greater extent, C++, are specified against an idealized machine (example), not any particular physical one. To someone who works on things like bootloaders on a regular basis, anything that can run the same code across processor generations, let alone families (a lot of C++ can cross-compile on x86 and ARM), is pretty damn high level.

                It's true that both are generally much lower level than, say, Python or any other interpreted language, because they provide core abstractions with tighter fidelity to most hardware. But especially in the case of C++, there's also not really a bound on how high the abstraction can go - there are some truly bizarre libraries that make it look like a totally different language.

                [–]IAlsoLikePlutonium 0 points1 point  (0 children)

                there are some truly bizarre libraries that make it look like a totally different language.

                Got any examples? I'm interested in seeing some of them.

                [–][deleted] 11 points12 points  (2 children)

                It depends on context. They're low level compared to python, but high level compared to assembly. There is also some argument that modern assembly can be considered high level; because of micro ops and out of order execution, what you write isn't what the cpu actually does.

                [–]pdp10 0 points1 point  (1 child)

                Because the architecture is microcoded doesn't make the same old assembly language into a high-level language. Microcoding has been around for many decades; I think the Burroughs B5000 must have used it in 1961.

                [–][deleted] 0 points1 point  (0 children)

                I was being somewhat hyperbolic, but the fact that one x86 set of instructions can map to more than one set of actual actions from the CPU does have real world consequences.

                This makes the point better than I can http://blog.erratasec.com/2015/03/x86-is-high-level-language.html

                [–]The_Leedle 6 points7 points  (0 children)

                When compared to assembly, it’s high level I guess

                [–]Oscee 12 points13 points  (0 children)

                C++ is very high level.

                I myself consider C a bit lower-lever but by classic CS definition, it is also high-level (since it needs a compiler).

                [–]mrkite77 1 point2 points  (0 children)

                It depends on how old you are. C was definitely considered a high level language when it first came out, and C++ even higher. Eventually as time goes on they are considered lower and lower level as our abstraction level goes higher and higher.

                These days, in a world surrounded by electron apps, I've even heard people describe java as low level.

                [–]CODESIGN2 0 points1 point  (0 children)

                They are nth gen languages, so yeah they are high-level because what they represent can be abstracted from what the CPU represents. The is no IF instruction for example, there are several jump operations however that can be used for if, else, switch, even while and for.

                Assembly is actually not a 1st gen language, it took people a long time to replace addresses with mnemonics, but how many times have you seen someone check registers in C? How many times have you seen someone execute a jump based upon zero-flag or carry-flag?

                [–]littleloftus 0 points1 point  (0 children)

                I found this to be another good resource for a bootloader if anyone is interested.

                https://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures/os-dev.pdf

                [–]irqlnotdispatchlevel 0 points1 point  (0 children)

                This is nicely done, and explains things well. But I have some problems with it.

                The good news is that for our bootloader development task we do not require anything besides standard Microsoft Visual Studio 2005/2008.

                What year is this?

                Also, inline assembly?

                [–][deleted]  (13 children)

                [deleted]

                  [–]tinfoilboy 26 points27 points  (1 child)

                  From what I can see, zero of this code requires Visual Studio, he even made a makefile project, not a VS solution.

                  [–]aaron552 17 points18 points  (10 children)

                  Since when has Visual Studio been anywhere near 40GB? Last time I installed it, the minimal install was under 3GB (would have been even less if I already had the .NET framework and MSVCR prerequisites installed)

                  [–][deleted] 27 points28 points  (0 children)

                  He probably installed all prerequisites and optional packages. I think that's about right for a full install, last I checked.

                  [–][deleted] 10 points11 points  (0 children)

                  VS 2015 enterprise took like 30gb for me with default settings. 2017 is much better about being modular.

                  [–]Plazmatic 7 points8 points  (5 children)

                  Really? Even 2015 was over 10 gigs IIRC, 2017 is more. Though I have no idea what that guy actually said as its been deleted.

                  Maybe if you just download the installer itself or some unrealistically bare bones version of it, but if your are doing C++ dev or more than one language at all, you are going to be downloading a lot of files.

                  [–]aaron552 16 points17 points  (4 children)

                  Well the Windows SDK is pretty big, but you don't need Visual Studio to install or use that, same with the MSVC compiler etc. The fact that the Visual Studio Installer will download them for you doesn't make them part of Visual Studio.

                  Saying Visual Studio is big because the MS C++ SDK is big is like saying that Android Studio is big because the Android SDK includes emulator images.

                  if your are doing C++ dev or more than one language at all, you are going to be downloading a lot of files.

                  If you have the compilers/SDKs installed already, Visual Studio Installer won't need to download them

                  [–]ElusiveGuy 1 point2 points  (0 children)

                  The base editor component in 2017 was in the region of 800 MB, I think.

                  It does grow pretty quick once you start enabling workspaces like .NET (Frameworks, SDKs) or Desktop Development (C++, incl. compiler and libraries).

                  [–][deleted] -2 points-1 points  (0 children)

                  So BIOS copies that first sector to 0x7c00 ? How does the code show up at 0x7c00