6 操作系統開發中的困難

現在市面上眾多的C編譯器都是以開發Windows或Linux上的應用程序為前提而設計的，幾乎從來沒有人想過要用它們來開發其他的軟件，比如自己的操作系統。筆者所提供的編譯器，也是以Windows版的gcc為基礎稍加改造而做成的，與gcc幾乎沒什么不同。或許也有為開發操作系統而設計的C編譯器，不過就算有，恐怕也只有開發操作系統的公司才會買，所以當然會很貴。這次我們用不了這么高價的軟件。

因為這些原因，我們只能靠開發應用程序用的C編譯器想方設法編寫出一個操作系統來。這實際上是在硬來，所以當中就會有很多不方便的地方。

就比如說printf(“hello\n”)；吧，這個函數總是出現在C語言教科書的第一章，但我們現在就連它也無法使用。為什么呢？因為printf這個函數是以操作系統提供的功能為前提編寫的，而我們最開始的操作系統可是什么功能都沒有。因此，如果我們硬要執行這個函數的話，CPU會發生一般保護性異常，直接罷工。剛開始的時候不僅是printf，幾乎所有的函數都無法使用。

關于這次開發語言的選擇，如果非要說出個所以然的話，其實也是因為C語言還算是很少依賴操作系統功能的語言，基本上只要不用函數就可以了。如果用C++的話，像new/delete這種基本而重要的運算符都不能用了，另外對于類的做法也會有很多要求，這樣就無法發揮C++語言的優勢了。當然，為了使用這些函數去開發操作系統，只要我們想辦法，還是能夠克服種種困難的。但是如果做到這個份上，我們不禁會想，到底是在用C++做操作系統呢，還是在為了C++而做操作系統呢。對別的語言而言這個問題會更加突出，所以這次還是決定使用C語言，希望大家予以理解。

順便插一句，在開發操作系統時不會受到限制的語言大概就只有匯編語言了。還是匯編語言最厲害（笑）。但是如果本書僅用匯編來編寫操作系統的話，恐怕沒幾個人會看，所以就算是做事管前不顧后的筆者也不得不想想后果。

另外，在開發操作系統時，需要用到CPU上的許多控制操作系統的寄存器。一般的C編譯器都是用于開發應用程序的，所以根本沒有任何操作這些寄存器的命令。另外，C編譯器還具有非常優秀的自動優化功能，但有時候這反而會給我們帶來麻煩。

歸根到底，為了克服以上這些困難，有些沒法用C語言來編寫的部分，我們就只好用匯編語言來寫了。這個時候，我們就必須要知道C編譯器到底是怎樣把程序編譯成機器語言的。如果不能夠與C編譯器保持一致的話，就不能將匯編語言編寫的部分與C語言編寫的部分很好地銜接起來。這可是在編寫普通的C語言程序時所體會不到哦！不過相比之下，今后的麻煩可比這種好處多得多啊（苦笑）。

同樣，如果用C++來編寫操作系統，也必須知道C++是如何把程序編譯成機器語言的。當然，C++比C功能更多更強，編譯規則也更復雜，所以解釋起來也更麻煩，我們選用C語言也有這一層理由。總之，如果不理解自己所使用的語言是如何進行編譯的，就沒法用這種語言來編寫操作系統。

書店里有不少C語言、C++的書，當然也還有Delphi、Java等其他各種編程語言的書，但這么多書里沒有一本提到過“這些源代碼編譯過后生成的機器語言到底是什么樣的”。不僅如此，雖然我們是在通過程序向CPU發指令的，但連CPU的基本結構都沒有人肯給我們講一講。作為一個研究操作系統的人，真覺得心里不是滋味。為了彌補這一空缺，我們這本書就從這些基礎講起（但也僅限于此次開發操作系統所必備的基礎知識）。

我們具備了這樣的知識以后，說不定還會改變對程序設計的看法。以前也許只想著怎么寫出漂亮的源代碼來，以后也許就會更注重編譯出來的是怎樣的機器語言。源代碼寫得再漂亮，如果不能編譯成自己希望的機器語言，不能正常運行的話，也是毫無意義的。反過來說，即便源代碼寫得難看點兒，即便只有特定的C編譯器才能編譯，但只要能夠得到自己想要的機器語言就沒有問題了。雖然不至于說“只要編譯出了想要的機器語言，源代碼就成了一張廢紙”，但從某種意義上說還真就是這樣。

對于開發操作系統的人而言，源程序無非是用來得到機器語言的“手段”，而不是目的。浪費太多時間在手段上就是本末倒置了。

對了，還有一點或許會有人擔心，所以在這里事先說明一下：雖然操作系統是用C語言和匯編語言編寫的，但并不是用C++編寫的應用程序就無法在這個操作系統上運行。編寫應用程序所用的語言，與開發操作系統所使用的語言是沒有任何關系的，大家大可不必擔心。