0.1 What's Your Goal & Plan?
[Home] [Top] [Next]
0.1.1 Overview
你好！
我已經收到了你的關於面向對象的操作系統設計的想法，由於我對這方面的資料瞭解甚少，所以我無法馬上給你任何有關於它的任何建議，不過我覺得這個想法確實是一個比較不錯的想法。
關於這項工作的意義和價值你已經論述的很清楚，但在做它之前，你是否考慮過以下幾個問題：
1）你是否對面向對象的操作系統的幾個特性有了充分的理解和認識，並且對如何實現它有了一個比較成熟的想法（關於面向對象操作系統的幾個特性的實現方法）？
2）你最多有多長的時間可以去做這個工作，同時這個工作需要的最短時間有多少？
3）有多少人可以參與這個工作？
4）是否有一定要做出來的決心和精力？
這幾點問題是關於這個工作成敗的關鍵。
我覺得這件事情本身是富有趣味性和挑戰性的，如果你有關於這方面的電子版的資料,Mail 給我一份，我需要了解一些技術細節。
關於下載的問題，很不幸的就是我們公司的代理限制的更嚴，僅能訪問有限的一些站點，並且速度奇慢。
另外，關於C++編譯器的問題,我認爲如果你有Minix a.out 的文件格式，另外由於gc++編譯器的源代碼是開放的，我們可以將其修改爲Minix下的C++編譯器，有關問題我們可以請教 Al Woodhull 及其他人員。當然如果有其他現成的編譯器就更好了，可以Mail給 Al Woodhull問一下。
他很快回了信，對我的問題一一作了回答：
>1）你是否對面向對象的操作系統的幾個特性有了充分的理解和認識，並且對如何實現它有了一個比較成熟的想法（關於面向對象操作系統的幾個特性的實現方法）？
事實上，一開始我們可以不要過多的考慮那幾個特性，因爲那是當我們有足夠的實力，時間和經驗時，纔可以去考慮的事情。我現在的目的其實很簡單，說白了就是希望將現有的系統全部用c++代碼來代替掉，其實這已經意味着有很多工作要做了。
>2)你最多有多長的時間可以去做這個工作，同時這個工作需要的最短時間有多少？
滿打滿算，我最多有1.5年來做這項工作，直到畢業（當然畢業以後也可以幹）。
這個工作需要的最短時間，我不敢預測，別見笑，確實不敢預測，我的想法是在畢業時，能拿出一些東西給別人看，就算沒被幹。
這個工作需要的最短時間，我不敢預測，別見笑，確實不敢預測，我的想法是在畢業時，能拿出一些東西給別人看，就算沒被幹。
>3）有多少人可以參與這個工作？
你想在當前的中國，有幾個人願意跟你做操作系統，要不中國IT業也不致於這樣衰。目前，前前後後張羅的人就本人一人，當然還可能爭取過來幾個，不過這要看運氣了。
>4）是否有一定要做出來的決心和精力？
首先精力是不成問題的，我就是專門做這個的。如果事情進展地順利，我指的是如果編程方面沒有了問題，同時能拉過幾個人來，我就幹定了，大不了不要這個學位了。
>我覺得這件事情本身是富有趣味性和挑戰性的，如果你有關於這方面的電子版的資料,Mail 給我一份，我需要了解一些技術細節。
>我覺得這件事情本身是富有趣味性和挑戰性的，如果你有關於這方面的電子版的資料,Mail 給我一份，我需要了解一些技術細節。
說真的，我也沒有這方面的電子版的資料，我的一些資料全是網上查找的。但由於現在忙着解決如何編程開發的問題，所以關於面向對象的操作系統的一些理論上的東西，我也沒有多少了解（有關這個問題，我們可以專門找時間來切磋）。我個人覺得其實不需要太多的理論，只要能解決掉C++中關於操作系統相關性的部分（例如生成一個對象的new操作符，必須自己做，不能用編程系統提供的，因爲這是系統相關的）。
>另外，關於C++編譯器的問題,我認爲如果你有Minix a.out 的文件格式，另外由於gc++編譯器的源代碼是開放的，我們可以將其修改爲Minix下的C++編譯器，有關問題>我們可以請教 Al Woodhull 及其他人員。當然如果有其他現成的編譯器就更好了，可以Mail給 Al Woodhull問一下。
Minix a.out的文件格式不成問題，代碼中有。但關於修改gcc爲Minix下的C++編譯器的事，我不敢瞎說，因爲不怕你笑話，我是學數學出生的，沒學過編譯，對此我是門外汗（看了這句話，你不會不理我了吧！）。事實上，Minix2.0因爲不支持虛擬內存，而C++編譯器簡直就是一個喫內存的大怪物，所以將gcc移植到Minix2.0上基本上是可以判死刑的---沒戲！我在comp.os.minix新聞組上不止一次看到過類似的說法，好象Al Woodhull 大叔也這麼說。現在你應該明白了爲什麼minix-vmd上可以移植gcc了吧，因爲它支持虛擬內存。但我給Al Woodhull發過一個email,問他在minix-vmd上生成的可執行文件可不可以直接在minix2.0上運行，如果不行，有沒有工具進行這方面的轉化呢？結果他說，他也不太清楚，反正沒回答到點子上，不過他說他把我的email轉給了kees j.bot，但"酷人"kees J.bot至今仍是杳無音信，大概他不願回答我們的“愚蠢”問題吧。(另：附件中有Al Woodhull給我的回信）
這次通信的郵件就成了我們對計劃設計和開發的OS的目標定位和開發計劃的說明，非常的模糊。更要命的是，當時我們對於製作OS的方面的知識知之甚少，我們打算使用C++來開發面向對象的OS，而當時我們對C++根本就不熟悉。但當時我們對於OS都滿懷着極大的熱情，於是沒有考慮更多的問題，就開始上路了。
這中間我們還有幸結識了幾位比我們兩個在OS方面有經驗的多的國外的朋友，他們也加入了我們。我們建立了自己的Mailing List，那段時間我們5個人進行了大量的討論，也嘗試着開始做一些設計，並開始寫相關代碼。但由於最初所定的目標很模糊，我們花了更多的時間來爭論——究竟是做成微內核的，還是做成整體內核的，是使用NASM，還是使用AS...等等類似的問題——逐漸有人開始對此感到厭倦，開始很少參與討論，其實也就等於退出了小組，畢竟大家還有自己的工作。5個月之後，我突然接手一個壓力極大的項目，也退出了小組。半年之後，當公司的項目忙完之後，我試圖和他們聯繫，但郵件都被退回，這個計劃最終失敗了。儘管我在這個過程中學到了不少東西，但給我印象更加深刻的是，如果一件事情，你不十分清楚你的目標及計劃，那麼這件事情基本上從一開始就失敗了。
對於這個問題，在Internet上有一篇廣爲流傳的經典文章，不妨借花獻佛，引用於此。
0.1.2 Questions For an OS Designer
Here are questions that you should answer before you start to code an OS. It's not a secret that every program must be designed before it is written (implemented). Also it's not a secret that a very few of programs are written this way... Most are written under pressure and hardly have a complete requirements list when coding starts.
Such an approach is very harmful. Design is finished in breaks between coding work and is dictated by things that are already written and work. Programmers tend to think "I'll change it later" but mostly later never comes. Nobody really wants to change already working code to fit a changed design.
It may be very painful if you write an OS. Because of design flaws or incomplete design the whole project may be brought down or at best take months to redesign and rewrite big parts.