{"id":23560,"date":"2023-04-21T02:21:55","date_gmt":"2023-04-21T02:21:55","guid":{"rendered":"https:\/\/www.booksofall.com\/es\/?post_type=product&p=23560"},"modified":"2023-04-21T02:21:55","modified_gmt":"2023-04-21T02:21:55","slug":"the-little-book-about-os-development-2","status":"publish","type":"product","link":"https:\/\/www.booksofall.com\/es\/the-little-book-about-os-development-2\/","title":{"rendered":"The little book about OS development"},"content":{"rendered":"

Chapter 2 – First Steps<\/h2>\n

Developing an operating system (OS)<\/a> is no easy task, and the question \u201cHow do I even begin to solve this problem?\u201d is likely to come up several times during the course of the project for different problems. This chapter will help you set up your development environment and booting a very small (and primitive) operating system.<\/p>\n

Tools<\/h3>\n

Quick Setup<\/h4>\n

We (the authors) have used Ubuntu<\/a>\u00a0 as the operating system for doing OS development, running it both physically and virtually (using the virtual machine VirtualBox<\/a> ). A quick way to get everything up and running is to use the same setup as we did, since we know that these tools work with the samples provided in this book. Once Ubuntu is installed, either physical or virtual, the following packages should be installed using apt-get:<\/p>\n

sudo apt-get install build-essential nasm genisoimage bochs bochs-sdl<\/p>\n

Programming Languages<\/h4>\n

The operating system will be developed using the C programming language, using GCC . We use C because developing an OS requires a very precise control of the generated code and direct access to memory. Other languages that provide the same features can also be used, but this book will only cover C. The code will make use of one type attribute that is specific for GCC:<\/p>\n

__attribute__((packed))<\/p>\n

This attribute allows us to ensure that the compiler uses a memory layout for a struct exactly as we define it in the code. This is explained in more detail in the next chapter. Due to this attribute, the example code might be hard to compile using a C compiler other than GCC. For writing assembly code, we have chosen NASM<\/a>\u00a0 as the assembler, since we prefer NASM\u2019s syntax over GNU Assembler<\/a>. Bash\u00a0 will be used as the scripting language throughout the book.<\/p>\n

Host Operating System<\/h4>\n

All the code examples assumes that the code is being compiled on a UNIX like operating system. All code examples have been successfully compiled using Ubuntu\u00a0 versions 11.04 and 11.10.<\/p>\n

Build System<\/h4>\n

Make [13] has been used when constructing the Makefile examples.<\/p>\n

Virtual Machine<\/h4>\n

When developing an OS it is very convenient to be able to run your code in a\u00a0virtual machine\u00a0<\/i>instead of on a physical computer, since starting your OS in a virtual machine is much faster than getting your OS onto a physical medium and then running it on a physical machine. Bochs\u00a0 is an emulator for the x86 (IA-32) platform which is well suited for OS development due to its debugging features. Other popular choices are QEMU<\/a>\u00a0 and VirtualBox . This book uses Bochs. By using a virtual machine we cannot ensure that our OS works on real, physical hardware. The environment simulated by the virtual machine is designed to be very similar to their physical counterparts, and the OS can be tested on one by just copying the executable to a CD and finding a suitable machine.<\/p>\n

Booting<\/h4>\n

Booting an operating system consists of transferring control along a chain of small programs, each one more \u201cpowerful\u201d than the previous one, where the operating system is the last \u201cprogram\u201d. See the following figure for an example of the boot process:<\/p>\n

\"\"<\/p>\n

Figure 2.1: An example of the boot process. Each box is a program.<\/p>\n

BIOS<\/h4>\n

When the PC is turned on, the computer will start a small program that adheres to the\u00a0Basic Input Output System\u00a0<\/i>(BIOS)<\/a>\u00a0 standard. This program is usually stored on a read only memory chip on the motherboard of the PC. The original role of the BIOS program was to export some library functions for printing to the screen, reading keyboard input etc. Modern operating systems do not use the BIOS\u2019 functions, they use drivers that interact directly with the hardware, bypassing the BIOS. Today, BIOS mainly runs some early diagnostics (power-on-self-test) and then transfers control to the bootloader.<\/p>\n

The Bootloader<\/h4>\n

The BIOS program will transfer control of the PC to a program called a\u00a0bootloader<\/i>. The bootloader\u2019s task is to transfer control to us, the operating system developers, and our code. However, due to some restrictions1 of the hardware and because of backward compatibility, the bootloader is often split into two parts: the first part of the bootloader will transfer control to the second part, which finally gives control of the PC to the operating system. Writing a bootloader involves writing a lot of low-level code that interacts with the BIOS. Therefore, an existing bootloader will be used: the GNU GRand Unified Bootloader (GRUB)<\/a> . Using GRUB, the operating system can be built as an ordinary ELF\u00a0 executable, which will be loaded by GRUB into the correct memory location. The compilation of the kernel requires that the code is laid out in memory in a specific way (how to compile the kernel will be discussed later in this chapter).<\/p>\n

The Operating System<\/h4>\n

GRUB will transfer control to the operating system by jumping to a position in memory. Before the jump, GRUB will look for a magic number to ensure that it is actually jumping to an OS and not some random code. This magic number is part of the\u00a0multiboot specification <\/i>\u00a0which GRUB adheres to. Once GRUB has made the jump, the OS has full control of the computer.<\/p>\n","protected":false},"excerpt":{"rendered":"