MiniGUI 創始人談 MiniGUI 魏永明 (2000/12/10) 注: 在本文中提到的一些 MiniGUI 所面臨的挑戰，已經在 MiniGUI-Lite 中得到了基本解決。 一、?什?要開發 MiniGUI 當自由軟體精神從國外傳入中國大陸的時候，當許多人已經開始關注 Linux 時，我正在自己 Windows 98 系統上進行痛苦的硬碟整理。我始終鬧不明白的是，?什?這個系統的磁片整理程式越來越慢？那時，我不知道 Linux 是一個什?東西，甚至連她是一個作業系統也不知道。我只知道我應該儘快逃離微軟營造的封閉世界，應該擦亮眼睛仔細看一看?什?要不停地升級自己的系統硬體。在這樣的背景下，我有了嘗試其他作業系統的衝動，而我當時所從事的研究課題也迫使我作出一個選擇──是 Windows 還是 Linux。 當時，我在清華大學某實驗室工作。該實驗室正要開發一套工業控制系統──用於新型機床的數控系統。以前，這樣的控制系統一般都建立在 DOS 作業系統之上，因? DOS 最?簡單，並且能夠直接控制中斷和 I/O，從而可以獲得非常高的即時回應能力。但是 DOS 是一個 16 位操作，不能充分發揮基於 Pentium 處理器的新硬體平臺的功能，因此，我們首先要選擇一個新的 32 位操作操作。由於微軟系列產品在大家心中“神聖不可侵犯”的地位，我所在研究小組的領導傾向于使用 Windows NT 作?作業系統開發這個數控系統。現在想起來真是有些後怕！如果當時真的選擇了 Windows NT，那這個數控系統簡直就是無法完成的──因?它需要 2ms 的即時回應能力！Windows NT，這個號稱“新技術”的作業系統，實際根本不是一個硬即時操作系統，而且其龐大累贅的體系結構，也無法真正應用於工業現場環境使用。 在經過很長時間的調研之後，我們對 Linux 有了一定的認識。其中最?關鍵的是，Linux 已經有了一個即時的內核補丁，即 RT-Linux。利用 RT-Linux，可以直接處理中斷，從而能夠讓一個普通的 Linux 系統成?一個健壯的硬即時系統。經過長時間的遊說，實驗室終於決定選擇 Linux 作?數控系統的作業系統平臺。但緊接著出現了另一個問題──GUI 怎?辦。因? Linux 上的 X Window 也不可避免地龐大和累贅。我們曾經做過一個試驗，如果在 RT-Linux 上?動 X Window，則會導致嚴重的關鍵中斷延遲。而且，當時的 X Window 漢化技術也不很成熟。所以，建立一個輕型的 GUI 系統，並且具有良好的中文支援，是首先要解決的問題。 但實際上，這已經不是什?問題了。那時，我已經具備了一定的圖形用戶介面系統開發經驗。早在 1995 年，就已經開發完成了 DOS 上一個簡單的圖形用戶介面系統。我將她稱? MiniGUI。在 Linux 上的 SVGALib 函數庫的幫助下，建立一個類似的圖形用戶介面支援系統的確是一項並不困難的工作。 二、MiniGUI 的開發歷史 但是，DOS 上的 MiniGUI 太簡單了，功能太有限。如果Linux 上的 MiniGUI 沒有什?大的突破，對 Linux 來講，太不公平了。我想，Linux 上的 MiniGUI 最起碼應該支援多窗口，支援類似 X Window Widget 的東西，同時要具有對中文的良好支援。因?我們的目標系統是一個數控系統，功能單一，並且即時要求很高。對比典型的基於進程的客戶/伺服器體系結構，如果採用線程實現多視窗，將節省大量的進程間通訊開銷。於是我選擇了 Linux 上的多線程機制，而不是典型的客戶/伺服器體系結構。 有了這樣的最初設想，我就開始在一台 Pentium 90 上開發新的 MiniGUI 版本。從 1998 年 12 月開始，最初的 MiniGUI 大概經歷了如下幾個開發過程： 1999 年 4 月。搭起 MiniGUI 的骨架，支援多主視窗，以及基本的圖形設備介面。 1999 年 5 月。功能表和計時器支援，有了控制項的支援框架。 1999 年 6 月。中文輸入法支援（由康曉寧編寫）。 1999 年 7 月。GIF 和 JPG 支援（由李琢編寫）。 1999 年 8 月。實現了基本控制項（最初版本由趙江華編寫）。 1999 年 9 月。掃雷遊戲的克隆（由鄭翔、龔曉瑞編寫）。 1999 年 9 月。對話方塊和訊息方塊邏輯。 1999 年 9 月。螢幕或視窗快照。 2000 年 1 月。VCOnGUI（MiniGUI 上的虛擬控制臺）穩定版發佈。 2000 年3 月。HappyLinux 發行版的安裝程式開發完成。 現在已經記不清楚什?時候向外界公佈 MiniGUI 的源代碼了。但是，像 DOS 上的 MiniGUI 一樣，一開始我就選擇了公開源代碼的方式（在開發 DOS 的 MiniGUI 版本時，我還不知道什?叫自由軟體，什?叫 GPL），並且以 LGPL 的授權條款發佈源代碼。 在此期間，有許多朋友? MiniGUI 貢獻了自己的代碼，我也得到了許多人的幫助和支援。其中最值得一提的是 AKA。AKA 是清華大學一個致力於中國資訊技術發展的學生組織。?了支援自由軟體在中國的發展，他們幫助我在 SMTH BBS 上進行宣傳，並且幫助我建立了一個主頁。有了這些幫助，才使得 MiniGUI ?更多的人所瞭解。而 MiniGUI 在數控系統和 Linux 發行版中的成功應用，也進一步鼓勵我繼續開發和完善 MiniGUI。 在這樣的背景下，我們將 MiniGUI 定義?： “MiniGUI 是 Linux 控制臺上運行的，基於 SVGALib 和 LinuxThread 庫的多視窗圖形用戶介面支援系統。MiniGUI 採用了類 Win32 的 API 介面，實現了簡化的類 Windows 98 風格的圖形用戶介面。 “MiniGUI的目標是保持現有小巧的特點，在 Linux 控制臺上提供一個小的視窗系統支援，‘小’是MiniGUI的特色。同時MiniGUI又將盡力於微軟的Win32 API保持相容。這?定位是希望我們的MiniGUI可以在未來以Linux ?基礎的應用平臺上提供一個簡單可行的 GUI 支援系統，讓MiniGUI 可以應用在 Windows CE 可以應用的任何場合。” 很明顯，我們希望 MiniGUI 不僅僅使用在數控系統，也希望她能夠在其他場合，比如目前時興的資訊設備（PDA、掌上電腦等）上。 2000 年 4 月份，筆者辭去了清華大學的工作，加盟藍點公司並專注於嵌入式系統的開發。MiniGUI 作?中國?數不多的幾個自由軟體專案之一，繼續以開放源碼的形式進行開發。 這之後，我們重點在如下幾個方面進行了開發： 在考慮到其他不同於數控系統的嵌入式系統時，?了滿足千變萬化的需求，必須要求 GUI 系統是可配置的。在數控系統中得到成功應用之後，我們立即著手於 MiniGUI 可配置的設計。我們通過 Linux 下的 Automake 和 Autoconf 介面，實現了大量的編譯配置選項，通過這些選項可指定 MiniGUI 庫中包括哪些功能而同時不包括哪些功能。 在 MiniGUI 0.3.xx 的開發中，我們引入了圖形和輸入抽象層（Graphics and Input Abstract Layer，GAL 和 IAL）的概念。抽象層的概念類似 Linux 內核虛擬文件系統的概念。它定義了一組不依賴於任何特殊硬體的抽象介面，所有頂層的圖形操作和輸入處理都建立在抽象介面之上。而用於實現這一抽象介面的底層代碼稱?“圖形引擎”或“輸入引擎”，類似作業系統中的驅動程式。這實際是一種面向物件的程式結構。利用 GAL 和 IAL，MiniGUI 可以在許多圖形引擎上運行，比如 SVGALib 和 LibGGI，並且可以非常方便地將 MiniGUI 移植到其他 POSIX 系統上，只需要根據我們的抽象層介面實現新的圖形引擎即可。目前，我們已經編寫了基於 SVGALib 和 LibGGI 的圖形引擎。利用 LibGGI， MiniGUI 應用程式可以運行在 X Window 上，將大大方便應用程式的調試。我們目前正在進行 MiniGUI 私有圖形引擎（即直接建立在 Linux FrameBuffer 之上的圖形引擎，而不依賴於已有圖形庫）的設計開發。通過 MiniGUI 的私有圖形引擎，我們可以最大程度地針對視窗系統對圖形引擎進行優化，最終提高系統的圖形性能和效率。在 MiniGUI 最新的版本中，已經包括了由浙江大學研究生宋立新開發的私有引擎。 在成功引入 GAL 和 IAL 之後，我們又在處理字體和字元集的模組當中引入了邏輯字體的概念。邏輯字體是 MiniGUI 用來處理文本（包括文本輸出和文本分析）的頂層介面。邏輯字體介面將各種不同的字體（比如宋體、黑體和揩體）和字體格式（比如等寬字體、變寬字體等光柵字體和 TrueType 等向量字體），以及各種不同字元集（ISO-8859、GB2312、Big5、UNICODE等）綜合了起來，從而可以通過統一的介面顯示不同字元集的不同字體的文本，並且還可以分析各種字元集文本的組成，比如字元、單詞等。在多字體和多字元集的支援中，我們也採用了面向物件的軟體技術，使得添加新的字體支援和新的字元集支援非常方便。目前，MiniGUI 能夠支援各種光柵字體和 TrueType、Type 1 等向量字體，並能夠支援 GB2312、Big5 等多位元組字元集，UNICODE 的支援正在開發當中。 完善現有的視窗機制，進一步增強MiniGUI 的視窗處理功能，比如控制項嵌套功能。 開發完成了多種控制項，包括多行編輯框、工具欄等等。 在開發這些功能的同時，MiniGUI 得到了更多人的認可及支援，同時也有了更多的用戶。但是，MiniGUI 的發展並不是一帆風順的。在這個領域中，競爭非常激烈。今年 11 月份，開發 QT 庫的公司就開發出了 QT/Embedded 庫，並且採用 GPL 授權條款公開源代碼，從而?許多嵌入式系統生?廠商提供了一個非常不錯選擇。與此同時，MicroWindows 的開發也異常活躍。在這種情況下，MiniGUI 如何定位，如何面對激烈的競爭，如何趕上技術的發展潮流呢？ 三、MiniGUI 面臨的困難和挑戰 MiniGUI 面臨的困難和挑戰是多方面的。首先，國內的自由軟體氛圍太淡，創新意識還有待提高。儘管 MiniGUI 的得到了許多人的支援。但是，也有許多人對是否有必要開發 MiniGUI 持懷疑態度。實際上，早在開發 MiniGUI 之前，國外就已經有了類似的軟體，比如上面提到的 MicroWindows 和歐洲的 OpenGUI 等等。這些軟體同樣是開放源碼的自由軟體，並且開發時間要比 MiniGUI 長許多。似乎我們沒有必要自己開發一個 GUI 系統：“如果要用輕型的 GUI 系統，用別人已有的軟體就行了。”但是我不這樣認?。大家都不會否認，從全球來講，自由軟體社區中中國人的聲音太弱小了。如果我們仍然採用跟隨而無創新的戰略，中國的軟體產業發展有什?希望？！筆者認?，自由軟體的本質是創新。而國內程式師缺少的恰恰就是創新，中國軟體業幾十年發展遺留的東西也是一昧地跟隨、跟隨。不管怎樣，創新問題應該得到大多數自由軟體愛好者的充分認識。只有創新，才能引領中國的自由軟體產業健康發展，中國的自由軟體才會更美好的前景。 另外，國內的程式師還普遍缺少奉獻精神和探索精神。舉個例子，儘管目前 MiniGUI 已經採用了 Autoconf/Automake 介面進行軟體的配置和安裝，但仍然免不了會在某些系統上出現問題。最多的問題就是 MiniGUI 的安裝問題和彙編代碼問題。由於 GCC 版本的增加，許多老的彙編代碼無法在新的 GCC 編譯器上編譯通過。我曾經收到國外程式師發送過來的可在新編譯器之上編譯的彙編代碼，但從國內程式師收到的只是詢問怎?辦的信件。我想，自由軟體需要大家共同的支援和努力，這樣我們的自由軟體才能發展得更快。 當然，我們相信這些問題是暫時的。隨著時間的推移，會有更多由中國人主持的自由軟體專案出現，國內的自由軟體氛圍也會越來越濃。 實際上，MiniGUI 所面臨的最大挑戰在於技術。前面提到的 MicroWindows 和 QT/Embedded 的確是非常好的嵌入式系統 GUI 解決方案。在面臨來自這些自由軟體的壓力時，如何發掘並保持 MiniGUI 的技術優勢，就成了我們當前的首要任務。這些挑戰包括： 如何適應諸如 PDA 等嵌入式系統？對 PDA 這樣的設備，傳統的客戶/伺服器體系結構還是有些臃腫。如何針對 PDA 對 GUI 系統進行簡化設計，並提高圖形操作的性能就成了當前的重要課題。 如何提高 GUI 系統的健壯性？MiniGUI ?了得到最大的效率，採用基於線程的多窗口機制。這種結構對數控系統這樣任務單一、即時要求高的系統來講，是最佳解決方案。但如果系統中運行的任務並不是單一的，就有可能因?一個任務的失效而影響其他任務。因此，提高 GUI 系統的健壯性就成?另一個亟待解決的問題。 如何提高程式師的開發效率？目前，MiniGUI 採用了類似 Win32 API 的 C 語言介面。但這種編程介面的開發效率並不是最高的──儘管程式的大小和執行效率最高。所以，增加其他類型的介面，比如類似 MFC 和 QT 的 C 介面，就成了下一步的重點工作。 儘管有許多困難和挑戰，我們仍然會繼續對 MiniGUI 進行開發和完善。但美好願望的實現，需要大家共同的努力和付出。

------
**********************************************************
哈哈&兵燹
最會的2大絕招 這個不會與那個也不會 哈哈哈 粉好

Delphi K.Top的K.Top分兩個字解釋Top代表尖端的意思,希望本討論區能提供Delphi的尖端新知
K.表Knowlege 知識,就是本站的標語:Open our mind