Explain to Me Like I'm Five What Happens When You Install a New Operating System

I’m a fairly tech savvy person, and I’ve done a fair amount of hardware install in my desktops over the years: RAM, video cards, sound cards, a power supply, I replaced a broken DVD drive and later even added a second DVD drive with the help of a wonderfully informative youtube video.

But I’ve never installed a hard drive *or *replaced an operating system, and I’d very much like to replace my current hard drive with an SSD drive, keeping the old hard drive as a secondary drive as my computer can house 3 hard drives and currently only has 2. I’d also like to install Windows 7 professional so I can increase the amount of RAM I can have (and if I do it soon, I get the professional version of 10 then, yay). Given this version of Windows 7 will be on a new primary hard drive, I think I need to get the full version, not an upgrade.

I’ve read enough to have a reasonable idea of how to put the new hard drive into the computer, but there’s one thing I just can’t grasp. I’ve tried looking for the answer but either I’m not feeding the right keywords into google or people who write articles think it’s too basic to bother with. This is what is tripping me up: after you replace a hard drive (or when you build your own computer from scratch) how the heck do you access an installer for the operating system if there’s not already an operating system in the computer??

I feel like a computer without an operating system would do nothing with a DVD put into the drive because there’s nothing to interface with the DVD’s contents, but that can’t be right. What am I missing? What actually happens when you go to install the operating system?

Your motherboard comes with some code directly built onto the system called the BIOS. The BIOS is what the CPU runs first. It knows how to read from your CD-ROM drive and locate and start the installer (it also is responsible for locating your OS on your hard drive and running that, once you have an OS installed).

At a simple level, the OS is a list of files which, together, make a computer a useful platform for running applications.

One of those files is called the kernel. The kernel runs in a special privileged mode and allows all of the other software to run in a way such that they don’t step on each others’ toes: They can all access the CPU, the RAM, and all of the other hardware because the kernel ensures they all take turns. The applications don’t know they’re taking turns; this part of what the kernel does is entirely invisible to them. It works through what’s called ‘preemption’, where, every so often, a clock inside the CPU signals the rest of the chip to save what it’s doing and go run some special code in a special location in RAM. That code is part of the kernel; its job is to look at the currently running application (or applications, on a multi-core system), see if some other application should run now, and, if so, to make it happen, in a way that’s completely invisible to application software.

So, how does the kernel get loaded into RAM when the computer is first turned on? There’s special code in NVRAM chips (used to be ROM, back in the Old Days) which is placed such that it’s the first code the CPU sees when it’s first powered up. That code is often called the BIOS (Basic Input-Output System), due to a plan which never quite worked, but now UEFI is making some inroads. Whatever the specific type, the result is the same: That code knows how to use a hard drive well enough to look for special code at a specific location on the drive. When it finds it, it blasts it into RAM and hands off control; the kernel does everything else from there. If it doesn’t find it, it beeps and puts an error message on the screen. (BIOSes can beep and flash lights due to a number of other problems, too. I don’t know what UEFI does.)

It’s possible to boot multiple OSes on the same computer if the special code the BIOS or UEFI finds isn’t an OS kernel but something called a bootloader, such as LILO or GRUB. Those programs can look in more different places for OSes, because BIOS development basically stopped in the 1980s and now consists of drunk monkeys throwing feces at MSVC++. In this way you can run multiple versions of Windows, Linux, BSD Unix, Minix, FreeDOS, and whatever else, and choose which you boot into when the computer is first turned on, after the BIOS is done but before any OS has been loaded. This process is invisible to OSes. (It has to be invisible to Windows, at least, which isn’t exactly friendly about sharing hardware.)

I’ll answer questions if there are any.

From a more practical level,

If you want to install a new OS :

  1. Put the OS install files on a thumb drive or DVD.
  2. When the computer starts up, the very first thing that comes up on the screen will be the BIOS popup. It will say something like “press <insert> to change BIOS settings”.

You press whatever key it says, hit reset again if you missed it. That will bring you to a menu that you can access with the arrow keys and enter key. Go to “boot” and select the thumb drive or DVD drive as the first boot device. That will cause the BIOS to look at that first before anything else.
3. Now, press “save and exit”. Computer will reboot, look at the thumb or DVD drive, and start the installer for the fresh OS install.

If you want to use your old OS :
You just need a disk cloning tool. Acronis is a good one. You just run it from windows after plugging in the new SSD. Tell it to clone everything to the new disk. Done.

Actually, you don’t even need to do all this. You can just run the windows installer from windows, and tell it to install to your new hard drive, after you plug it in. Might be easier for you.

The Windows installation DVD contains a small, self-contained, special version of Windows that runs the full Windows installer.

When your computer boots up, it will look first at the hard drive. Finding no operating system there, it will then find the self-contained Windows installation on the DVD, and boot up using that. You will then get screens that allow you to install the full Windows operating system on the hard drive.

In short - when you are installing an operating system onto a hard drive from a DVD, the operating system runs first from the DVD itself and copies itself to the hard drive.

There’s much lower level stuff on your computer than a full blown OS that looks for the actual full blown OS. Normally it’ll look for the primary hard drive, but if it doesn’t find what it’s looking for there, it’ll look at the DVD drive, and then at a USB drive.

Anyway, if you stick a new hard drive in your machine, and a Win7 DVD in the drive, it’ll be fine.

AND FURTHERMORE, modern computers are all designed from the ground up to be highly network compatible (as opposed to older machines of, say, the 1980’s era, where networking capabilities was often an added-on kluge of sorts). That built-in ROM or NVRAM code that your computer comes with also has the ability to boot or install directly from a network source, in typical modern machines. That network source could be another nearby machine in your home LAN, or from a corporate server down in the IT department, or from a web site run by Microsoft, or Apple, or any of a million Linus sites or mirrors.

The point that all the above posts have in common is that your computer, from the day it is manufactured, is never a bare-bones blank slate tabula rasa devoid of all runnable code. There is always a chunk of executable program built into some form of non-volatile memory, and the machine is built to execute that the very first thing when you power it on. That chunk of executable code has, at the minimum, enough smarts to get the boot process started.

The next step – that is, whatever code it boots (from disk or CD or thumb drive or even from a network source) could be an arbitrary program that does whatever it does. Initially, when you do an install, that code will come from some external source (not your machine’s own disk), and it may be an installer that will know where to take it from there. A typical modern installer will actually be a somewhat stripped down version of an otherwise-full operating system. It could install Windows, any of dozens of Linux systems, or it could be a totally custom system that runs some industrial process control and nothing else.

The computer has a tiny “operating system” called the BIOS. It knows how to startup the computer. Usually this consists of starting up the hard drives and loading the data on them to boot the operating system. But most BIOS’s also know how to boot off of alternative devices like USB, DVD, etc.

So you would typically:

  • Buy Windows 7
  • Install new hard drive
  • Boot computer. Look at startup screen to see what special key you hit to get into extra settings. It may be Enter, Delete, F12, etc. depending on your BIOS.*
  • Look through the settings to find where you can select an alternative drive. The list should have your DVD player in it.
  • Put the Windows 7 drive into your DVD player
  • Select the DVD drive in the BIOS menu and continue booting
    From here it will load the system from the DVD and allow you to do the install.

*You may not need to press any special keys to get to the BIOS menu to boot to DVD. Some computers will automatically search the DVD drive for a boot image.

You’ve also, no doubt, heard of the “boot block” on your disk. That is in intermediate step in the boot process. First, the ROM / NVRAM in your computer runs. In earlier computers, this was a quite small and simple program, sufficient just to load a sector from disk (containing further boot code) and transfer control to that. In modern systems, that initial ROM / NVRAM code is vastly more elaborate, with all those BIOS menus and all those zillions of settings (which get stored in NVRAM) and the power-on self test (POST). But ultimately, when you tell it to boot from the hard disk drive (or it is ready to do so on its own, if you’re not booting interactively), it will load one sector from Cylinder 0, Track 0, Sector 0 (the boot block) and then transfer control to that.

And even then, you haven’t yet reached the “boot loader” stage. The boot block knows just enough to find and load an actual file from your file system. That, in turn, will be the “kernel” discussed above by Derleth in Post #3, or at least the first part of the kernel (which will, in turn, then find and load even more of the operating system).

See why the process is called “booting”? It derives from the old phrase of pulling oneself up by one’s bootstraps.

OR: If you want to install multiple operating systems, you need a way to control which one gets booted each time. That’s where the “boot loader” comes in. In the process of installing that, the boot block gets tweaked to load the boot loader (e.g., GRUB or LILO) instead of the operating system. Then the boot loader has the smarts of know what-all operating systems are installed on the disk and where they are, and it can present you the menu of operating systems to boot.

A bit of history you might find interesting.

Way back in the very bad old days, computers were really really simpler than anything you young-uns have ever seen. Early computers (1960’s era, roughly) had very primitive operating systems.

I first learned programming in 1968/1969, while I was in high school, on an IBM 1620 at a nearby community college on weekends. It had a very primitive OS even by 1970’s standards. If the OS was already loaded in memory, it had a well-known starting point at address 00796, and you could always restart it by typing 4900796 on the console typewriter. (That meant: Branch to 00796.) (ETA: Scan down that Wiki page a ways. It shows the various restart procedures in detail, although I don’t see the 00796 address mentioned.)

There was no ROM or NVRAM. To get the boot process started, you had to type several instructions in, manually, at the console – a sequence of about 60 digits that all good 1620 operators (not me) had thoroughly memorized. Or, you could have that punched onto an IBM card, stick that in the card reader, and press a certain button on the reader panel that would read the card into a specific place in memory (location 00000 I assume) and then transfer control there.

That brief sequence was enough to load one sector from disk and jump to that, which then had enough code to load some more stuff, etc., which eventually got the whole system loaded.

I don’t recall ever hearing the term “boot” or “bootstrap” used in those days, though. The phrase was always “deadstart”.

Going back even further into even badder oldder days (1950’s era), computers typically had no operating system at all. And no ROM either. However, at least some of the computer memory technologies were non-volatile, so any program you managed to load into memory would stay there even when you powered the machine down and then back up.

At U. C. Berkeley, circa 1969, we had an old Univac SS-90 system that a lumber company gave us (for a tax write-off no doubt) when they upgraded their in-house IT to an early model IBM 360. It had a non-volatile memory that consisted of a magnetic drum with 5000 words of 10 decimal digits each, or roughly 25KB equivalent in modern memory terms. (Two decimal digits being roughly equivalent to one modern byte.)

There was no operating system whatsoever. You just wrote your program, loaded it into memory, and started running it. There was nothing even remotely like multi-programming or multi-tasking.

There were three data registers, and a little console with a ten-key keypad and some buttons. You could choose one of the registers by pressing the right button, and enter a ten-digit number into the register.

To load a program: First, assume you have the program punched into a deck of cards in a particularly defined format (which was done by an earlier program, an assembler or compiler that you ran earlier or by some other means). There was a special “loader” that itself consisted of a few cards containing enough of a program to load the rest of your deck. And there was a special “boot loader” consisting of just ONE card that had enough code on it just to load the second card and, which had just enough code to load the third card.

So you put together your deck of cards: First, the standard loader (consisting of the boot loader card and subsequent loader cards) followed by your actual program deck. Then you manually entered three program instructions, via the front panel and the ten-key pad, into the three registers, then pressed the “Start” button. That was enough code to read one card from the card reader, which in turn got the whole process started.

Those were they days when computers were machines that you actually had to operate. Primitive, but fun toys to play with!

The term I remember was IPL (Initial Program Load).

Yes, I’ve seen that phrase too. It sounds a lot more formal – like something you’d see in the formal operations manuals from IBM or other big companies.

ETA:

BTW, that Univac SS-90 link I posted above ( here it is again ) is a really good read on what one particular early computer was like. There are many pages to that site (most pages have a menu at the bottom listing other pages), with a bit of description and lots of pictures, with detail on how the memory worked, close-ups of the circuitry, the old-style punch cards and an old keypunch machine, and a lot more.

I would strongly suggest (from painful experience) that you only do one of these things at a time. Much easier to deal with any problems you might encounter if only 1 major change is happening.

So I’d suggest just adding the SSD drive, while keeping with your current OS. You should be able to do that – drive upgrades are a common thing – but you might have to call Microsoft if your OS mistakenly thinks it’s a new machine.

Then, when you have the new hardware all installed & working for a day or two, then install the new OS.

It’s really much easier – and safer – to do this in two steps. And you aren’t hacing an all-day into the night session to complete this, where you get tired out and start making mistakes.

One fine day (actually, more like a few weeks) some years ago, I installed a second hard drive into my Windows 98 machine, and at some point I also installed a Red Hat Linux system. This was about 10 years ago. And of course, a boot loader so I could load one system or the other. I also re-partitioned the disks, so that each disk had two main partitions. But I made the first partition on each disk be a Windows partition, and the second partition on each disk be a Linux partition.

By the time I was done, I got really really good at reading hexadecimal dumps of the boot sector!

Here’s more early computer history information, for anyone who’s interested:

An Illustrated History of Computers, Part 1 (Page 1 of 4 pages. Previous/Next links are at the bottom of each page.) Lots of pictures of really old machines through the ages!

Microsoft publishes official installers for Win 7 and Win 8 (now Win 8.1) to install onto a USB drive.

Windows 7

Windows 8.1

You don’t need any special privileges to download these. All you need, come install time, is the proper legal Windows key to install. And then of course activate once the system is up and running.

This was how I recently installed Win 8.1 on my NUC5i5RYH, which being a mini-PC does not have any optical drive.

What I did:

Bought another official Win 8.1 license from my existing desktop (which already had a legit 8.1 version, but new PC means new license needed.) Ignored the download. All I wanted was the new product key.

Ran the Microsoft Win 8.1 “Create Installation Media” tool from my existing desktop, put the installation files on a USB flash drive

Installed Win 8.1 on the NUC with said flash drive. Used newly purchased product key during install on the NUC. Pretty easy, overall.

Ah! I’ve heard of BIOS in passing, of course. But I thought it was really tiny, and only did much simpler things like keep the time and date accurate. :smack:

t-bonham@scc.net, it sounds like you’re suggesting that the SSD be a secondary drive? I want it the SSD to be the primary drive because some of my games, those I want to increase the load speed of which is much of the attraction of an SSD drive in the first place, will not install properly to a secondary drive according to scores of unhappy people who have tried it.

These days, BIOS’ only role is to run a simple test (called the POST, or Power-On Self Test) and then find an OS or bootloader and hand off control; once any non-BIOS code is running, the BIOS is essentially dead weight which is never used again until the computer is shut down and then rebooted again. (Going to sleep doesn’t count, by the way; the OS handles sleep mode and suspend-to-disk all by itself.)

Back in the 1980s, the idea was that the BIOS would actually be a Basic Input-Output System; that is, it would handle low-level hardware details such as the process of getting text onto a screen and getting blocks of data onto and off of a hard drive, such that OSes would be more portable from one system to the next and, oh yeah, the BIOS code was owned by IBM so hands off.

That went flooie in two ways. One, Compaq successfully copied the functionality of the IBM BIOS (but not the code) and then convinced a court that it wasn’t a dirty thief, because the BIOS was required to make computers compatible with IBM PCs. This opened the door to clone makers of all kinds and is the reason the Official IBM-owned IBM PC business languished and was eventually sold to Lenovo. (It managed to make some nice Thinkpads before that happened, and Lenovo’s laptops aren’t bad, either.)

Two, the BIOS code wasn’t as fast as just going to the hardware directly and doing it yourself. So that’s what everyone did. Game makers especially, since games are typically what push the limits of hardware on home systems, but even basic office software found the BIOS routines just too dang slow to actually use in real life. Hey, when your CPU runs at a blistering 4.77 MHz, a few clock cycles here and there can make the difference between a snappy application and one that pauses… every so… often.

This resulted in code rot: Nobody used the BIOS, so bugs weren’t fixed and newer hardware wasn’t accomodated, and by the later 1980s, the PC industry was switching over to the 80386, which had 32-bit pointers (so it could use more RAM without resorting to bizarre hacks) and had a protected mode people actually used. Protected mode means that the OS kernel can prevent applications from going directly to hardware: If a protected-mode application wants to write to the screen, it has to ask the OS, and the OS handles all the details.

This would have been great for the BIOS, had the BIOS ever been updated to handle 32-bit code calling into it. It hadn’t. To my knowledge, it still hasn’t. The BIOS is as 16-bit as it was in 1984 or thereabouts, meaning 32-bit code can’t use it and neither can 64-bit code. Therefore, modern OSes interface with hardware, often using device drivers, and typically have a subsystem inside of them called the HAL, or Hardware Abstraction Layer, which is essentially what the BIOS was originally envisioned to be.

(Side note: An even older home computer OS with something like a HAL was CP/M, which ran on 8- and 16-bit CPUs (as CP/M-86, if nothing else) and had a software component called BDOS, or Basic Disk Operating System. The BDOS encapsulated most of the hardware-specific knowledge, so porting was mainly a matter of re-writing that and reusing most of the rest of CP/M’s code, depending on the CPU of the new system.)

An SSD can be a primary drive. In fact, it usually is. Most people get one to run their OS because that is what everything else depends on but you can put anything on it as well as long as you have the space available. The computer itself doesn’t care. It is just another hard drive like any other (albeit a much faster one for most operations).