Where do operating systems come from?
Author
I'm interested in the theory of making one's own OS.
I'm going to state what my assumptions are as far as the process goes, and you are all free to pick my thoughts apart. Any areas where I'm *really* unsure of, I have bolded questions inline with my assertions.
SUPER-OVER-SIMPLIFICATION:
(1) You choose a hardware platform (x86, etc.)
(2) The hardware dictates the language you use to write the OS in. How?
(3) You build and test your OS on a separate dev machine. How in the world do you build an OS on an existing machine running... an existing OS?
(4) You copy your "finished/stable" OS onto a storage device (CD/DVD/Flash/etc.) and pop it into your target machine
(5) When the BIOS loads up, you direct it to look for an OS on your storage device
(6) Your OS is loaded, whereby you would have a huge set of routines for storing it permanently on one of target machine's drives
Final question: In the eyes of BIOS, what makes an OS an OS? Operating systems have special CPU privs that applications don't get... what gives the OS its privs? How does BIOS know (or does it) that you're not trying to install a HelloWorld.exe application as your OS?
Thanks for any interesting thoughts!
1: Correct.
2: No it doesn't. The only requirement is that the code can be translated into machine code for your target architecture.
3: You can use virtual machines to develop operating systems. If you program an OS against real hardware, debugging is somewhat more difficult (but not impossible) since it is more difficult to pause a real machine.
4 to 6, and the final question: See this Wikipedia article. In essence, the machine doesn't care what it runs, as long as the code follows certain strict conventions. The boot loader doesn't run PE executables (commonly denoted by .exe).
2: No it doesn't. The only requirement is that the code can be translated into machine code for your target architecture.
3: You can use virtual machines to develop operating systems. If you program an OS against real hardware, debugging is somewhat more difficult (but not impossible) since it is more difficult to pause a real machine.
4 to 6, and the final question: See this Wikipedia article. In essence, the machine doesn't care what it runs, as long as the code follows certain strict conventions. The boot loader doesn't run PE executables (commonly denoted by .exe).
Did you do any research at all?
(2) The CPU 'understands' a specific 'machine code' (the language of the hardware) that is what the hardware dictates. Also, the hardware dictates the interupts and ports that you must use (in a way the API of the hardware)
(3) In the same way you build any other program. The tricky part is deployment and debugging.
The OS has the privileges. Most OS installs are done by booting a tiny OS (a kind of bootloader) that installs the actual OS.
(2) The CPU 'understands' a specific 'machine code' (the language of the hardware) that is what the hardware dictates. Also, the hardware dictates the interupts and ports that you must use (in a way the API of the hardware)
(3) In the same way you build any other program. The tricky part is deployment and debugging.
The OS has the privileges. Most OS installs are done by booting a tiny OS (a kind of bootloader) that installs the actual OS.
(1) Is this a question?
(2) Yes and no, the CPU can only read specific instructions, hence, it must be fed a specific set of instructions to understand what you want it to do. Each instruction can be of size 1byte and up. The x86 architecture instructions range from 1byte to 15bytes or so I believe (including arguments). At this level, the instructions are often in the forms of 1's and 0's, but more commonly in the form of hexadecimal numbers.
Programming the computer by entering 1's and 0's or hexadecimal numbers is not a very efficient way for a human, so smart people came up with the assembler languages to make programming easier. The assembler code gets compiled down to 1's and 0's that the computer can then read. The first assembler compilers must have been written directly with 1's and 0's or hexadecimal numbers.
Some people thought that writing programs in assembler was still a bit clunky, so they came up with higher-level languages that made programming a lot more intuitive for a human. Languages like Fortran, Lisp, Cobol and later C. Each new generation of programming languages was developed with an earlier generation programming language. And since these languages are mostly architecture independent, they work on all possible architectures if you have a compiler that can target that architecture.
(3) If you have a computer already running an OS, you can develop an OS in that OS.
(4) Correct.
(5) When the computer loads up, the BIOS will take care of initial hardware initialization. The BIOS will start executing the first few bytes of your boot-medium. Usually, this is a boot-loader, a rudimentary program that locates and executes an OS on said boot-medium. It does not need to be a boot-loader, it could be a normal program that runs without an OS. That said, an OS is really just another program that manages the computers resources (resources like memory, CPU, I/O devices) and lets other programs run in tandem of each other.
Final answer to final question: The OS is just another program that handles the computers resources. The CPU privileges are 'built-in' in the CPU, and restricts what CPU instructions the currently running program can execute. These are (usually) turned on and off by special interrupt instructions (anything that requires read/write from memory and I/O devices, malformed CPU instructions and more), that halts whatever the current program is doing, and starts executing a special function that comes with the OS to handle that interrupt, usually with elevated privileges, and then return control to the program (unless the OS deems to terminate the program), taking away the added privileges in the process.
And no, the bios itself does not differ between your HelloWorld program and your OS.
I'm not sure if all this makes sense, it's a rather complex topic and I may have oversimplified some bits. Anyway, if you want to know more there are resources on the internet that deals a great deal with OS design and programming, try here and here
(2) Yes and no, the CPU can only read specific instructions, hence, it must be fed a specific set of instructions to understand what you want it to do. Each instruction can be of size 1byte and up. The x86 architecture instructions range from 1byte to 15bytes or so I believe (including arguments). At this level, the instructions are often in the forms of 1's and 0's, but more commonly in the form of hexadecimal numbers.
Programming the computer by entering 1's and 0's or hexadecimal numbers is not a very efficient way for a human, so smart people came up with the assembler languages to make programming easier. The assembler code gets compiled down to 1's and 0's that the computer can then read. The first assembler compilers must have been written directly with 1's and 0's or hexadecimal numbers.
Some people thought that writing programs in assembler was still a bit clunky, so they came up with higher-level languages that made programming a lot more intuitive for a human. Languages like Fortran, Lisp, Cobol and later C. Each new generation of programming languages was developed with an earlier generation programming language. And since these languages are mostly architecture independent, they work on all possible architectures if you have a compiler that can target that architecture.
(3) If you have a computer already running an OS, you can develop an OS in that OS.
(4) Correct.
(5) When the computer loads up, the BIOS will take care of initial hardware initialization. The BIOS will start executing the first few bytes of your boot-medium. Usually, this is a boot-loader, a rudimentary program that locates and executes an OS on said boot-medium. It does not need to be a boot-loader, it could be a normal program that runs without an OS. That said, an OS is really just another program that manages the computers resources (resources like memory, CPU, I/O devices) and lets other programs run in tandem of each other.
Final answer to final question: The OS is just another program that handles the computers resources. The CPU privileges are 'built-in' in the CPU, and restricts what CPU instructions the currently running program can execute. These are (usually) turned on and off by special interrupt instructions (anything that requires read/write from memory and I/O devices, malformed CPU instructions and more), that halts whatever the current program is doing, and starts executing a special function that comes with the OS to handle that interrupt, usually with elevated privileges, and then return control to the program (unless the OS deems to terminate the program), taking away the added privileges in the process.
And no, the bios itself does not differ between your HelloWorld program and your OS.
I'm not sure if all this makes sense, it's a rather complex topic and I may have oversimplified some bits. Anyway, if you want to know more there are resources on the internet that deals a great deal with OS design and programming, try here and here
Quote:Original post by plywood
Final question: In the eyes of BIOS, what makes an OS an OS? Operating systems have special CPU privs that applications don't get... what gives the OS its privs? How does BIOS know (or does it) that you're not trying to install a HelloWorld.exe application as your OS?
On x86 the cpu always starts in 16 bit real mode, this is unrestricted and is also how DOS used to run, modern OS:es switch to protected mode at startup which lets it set the rules, you can check http://download.intel.com/design/intarch/papers/exc_ia.pdf for more information.
basically BIOS doesn't know anything about the OS , it just lets the cpu execute whatever is in the bootsector of the chosen harddrive, this could be anything you want. allthough its never an .exe file, modern Windows uses the Portable Executable format which is partially compatible with the earlier DOS executables (PE .exe files contain 2 headers, one that is at the start of the file that DOS will use and one that is below that that Windows uses, (This means DOS will successfully load Windows PE files but the header will point it towards a small segment of 16 bit code that prints an error message about requiring Windows)
Quote:Original post by SimonForsmanQuote:Original post by plywood
Final question: In the eyes of BIOS, what makes an OS an OS? Operating systems have special CPU privs that applications don't get... what gives the OS its privs? How does BIOS know (or does it) that you're not trying to install a HelloWorld.exe application as your OS?
On x86 the cpu always starts in 16 bit real mode, this is unrestricted and is also how DOS used to run, modern OS:es switch to protected mode at startup which lets it set the rules, you can check http://download.intel.com/design/intarch/papers/exc_ia.pdf for more information.
basically BIOS doesn't know anything about the OS , it just lets the cpu execute whatever is in the bootsector of the chosen harddrive, this could be anything you want. allthough its never an .exe file, modern Windows uses the Portable Executable format which is partially compatible with the earlier DOS executables (PE .exe files contain 2 headers, one that is at the start of the file that DOS will use and one that is below that that Windows uses, (This means DOS will successfully load Windows PE files but the header will point it towards a small segment of 16 bit code that prints an error message about requiring Windows)
When you have it explained out to you so well, it makes you realize how elegantly simple these machines are.
I think a fun exercise would be to build an emulator that emulates small games like the NES. This would really open your mind to how a program and an OS use the cpu.
AS a historical note, on older computers (No, not your old 100 MHz '86 - Older), each game and program had to have what was essentially its own OS. Fortunately, both computers and games were a lot simpler. Most of the time, it was a generic one (Bought, begged, borrowed or stolen), but sometimes they wrote their own.
Plus, of course, the danger of a virus was easily handled by a disk-drive wipe and "obtaining" the game again. (*Snort* - Piracy rampant now? Should have seen it before the internet and common game stores)
Plus, of course, the danger of a virus was easily handled by a disk-drive wipe and "obtaining" the game again. (*Snort* - Piracy rampant now? Should have seen it before the internet and common game stores)
Theres a nice little book you should read first call "OS vade mecum" if I remember the spelling right. I goes over all the various issues of OS design. Dont forget to buy a large bottle of asprin and some visine, Youll need them.
There was a tutorial OS called Minix around a while ago - you may still be able to find it.
Programming Language - ANSI C was in fact created primarily to write operating systems and is generally the language of choice. Very few other languages have the ability to control data and structure it to the needs of the cpu. Assembly can be used but It requires a lot more work overall.
Legal Note- Last I checked you may not make a competing product using windows software, Meaning it is not actually legal to write a non windows OS on a windows machine. BUT... if your not planning a release then it really doesnt matter.
Design is all important for an OS and OO design does have a lot to offer. Assuming you have a lot of programming experiance expect to leave your computer powered off for several months while you get most of the design worked out. If you dont have the patience needed to do a detailed design then I would strongly suggest you pick a different interest.
A consideration for you is outside support for drivers. Unless you intend to use drivers from an existing OS you will have to write/provide a driver for every possible peice of hardware yourself. This alone is a massive undertaking and hardware vendors are not very supportive of newcomers.
There is also the matter of the user interface. A command line is not too hard to write but a full GUI could take several years.
If you are still really interested in working on an OS then I would suggest you get involved with linux instead.
There was a tutorial OS called Minix around a while ago - you may still be able to find it.
Programming Language - ANSI C was in fact created primarily to write operating systems and is generally the language of choice. Very few other languages have the ability to control data and structure it to the needs of the cpu. Assembly can be used but It requires a lot more work overall.
Legal Note- Last I checked you may not make a competing product using windows software, Meaning it is not actually legal to write a non windows OS on a windows machine. BUT... if your not planning a release then it really doesnt matter.
Design is all important for an OS and OO design does have a lot to offer. Assuming you have a lot of programming experiance expect to leave your computer powered off for several months while you get most of the design worked out. If you dont have the patience needed to do a detailed design then I would strongly suggest you pick a different interest.
A consideration for you is outside support for drivers. Unless you intend to use drivers from an existing OS you will have to write/provide a driver for every possible peice of hardware yourself. This alone is a massive undertaking and hardware vendors are not very supportive of newcomers.
There is also the matter of the user interface. A command line is not too hard to write but a full GUI could take several years.
If you are still really interested in working on an OS then I would suggest you get involved with linux instead.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
