12 Mar 1994 16:53:29 GMT csie.bbs.linux Article 1500 [ARTICLE] CHDRV's report by author(Very Long) wycc@phoenix (wycc) Lines 453 交大資工鳳凰城資訊站 -------------------- 下文是一篇有關CHDRV的報告,它總結了CHDRV到目前為止的發展,將來的可能性, 及它整個程式的模組分析。有些資料和最新版本已有所不同,但我相信它對於對 CHDRV 內容有興趣的人是有相當的吸引力的。希望大家能從其中獲益,也對於想 在CHDRV 中加入您的想法的人可以更容易的實行。如果你對CHDRV 的發展的有興 趣,我在這邊提供幾個可能性,在本文最後也提到了一些相關的訊息。 (1) X Window版的移植 一個X Window的版本會使CHDRV更為有用,移植的工作並不十分困難,主要 在繪圖方面的移植,並且因把pseudo te minal的支援去除。 (2) 改良multi console 目前的multi console是依附在linux的架構下,我認為應改為X Window的 做法,利用單一的console而自行模擬出多個虛擬console。 (3) 中文postsc ipt驅動程式 目前雖已有一套免費的中文postsc ipt立型,但並沒有驅動程式。 (4) 忘形輸入法的加入 包括詞庫的建立,詞頻資料的建立及驅動程式的寫作。 (5) 硬體支援的加強 目前支援640x480的VGA模式,把CHDRV移植到一些繪圖程式庫,如SVGALIB可 使相容性加大,且可支援24x24模式。 (6) CUT&PASTE及滑鼠的支援 有興趣的人可以和我直接連絡,我可以給你更進一步的建議。我想這是練功的好 機會,不是嗎? !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! 本文版權由作者本文(twchiu2@phys.ntu.edu.tw)王佑中保留,任何以電子媒體 ! ! 以外形式的使用或商業使用均需得作者之同意。 ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ======================================================================= 在LINUX的世界中,每天都有各種不同的驚奇出現。每天都有試不完的新軟體, 每天各種軟體不斷的推出新版本,所以LINUX上的玩家經常是每天都在做一些新 鮮的事。但是我們是不是還缺了些什麼呢? 這個世界好像很熟悉卻又有些陌生。 對了,少了些我們熟悉的中文立在螢幕上閃動。雖然在UNIX上我們已經被迫習 慣一個沒有中文的世界,沒有中文我們依然可以過得不錯。但當我們開始作線 上交談(IRC)時 ,才突然發現用慣中文的我們要用英文交談是多麼困難。像前 一陣子我要透過信件(英文的)和一個交大的學生商量賣我的舊記憶體。我想告 訴他請他用郵局的轉帳服務來付款,但是信件來往數次還是不得要領。最後不得 已用了下面的句子(fu/3 m/4 u.6 m6 2k7 wu6 dj03 u 5j03 5;4 )。什麼東 西,用注音唸就知道了,所以中文真的不重要嗎? 在以前想在UNIX系統上使用中文最好的方法是用X-Window上的CXTERM程式,我也 曾經用它,的確是不錯的程式。但是問題是它是建立在X-Window上,在LINUX 上當我只有4MB記憶體時我是不會想去用X-Window的(雖然它可以跑)。這就是當 初我開始寫CHDRV的動機。直到現在,我雖然已有16MB記憶體,X-Window已經可 以很正常的使用,但是我還是喜歡用它。 CHDRV的初版大約在去年的暑假完成,在我寫這篇文章的時候,最新的版本是 0.5pl4。不過各位看到文章的時候,我應該已經把0.9BETA版發表了。我之所 以把它定為0.9,是我希望能提供一個比較穩定且完整的1.0版。在0.9到1.0中 間將不加入任何新功能,如計劃中的硬體捲頁等。而專心提供一個沒有BUG的 版本,讓大家可以把它當做一個系統啟動時使常駐在記憶體中的DAEMON。且提 供一個立即可用的中文環境。 所以這篇文章的另一個目的是對這個程式做一個註解,這個程式從最早的CMORE (這個程式可能知道的人不多,因為我在寫完後很快的因為某些原因放棄了它)的 一仟多行程式到現在的九仟行,已經慢慢接近我能清楚掌握的程度。有時我自已 回頭看都想不起當初為何如些做。而且程式內的註解有些雜亂(不要怪我,這個程 式是我犧牲了無數睡眠換來的),所以我也藉此機會把它理出一個頭緒。我只在 很少的地方直接引出程式碼,因為我想你可以自已印一份來和我的說明對照。 在開始之前我先把想說的東西整理一下,首先我在第一節將描述一下中文系統做 些什麼事。在第二節中將比較一下在DOS和LINUX上寫中文系統有何不同,然後第 三節是最大的一節將對CHDRV中所有模組做一分析。最後在第四節中,我將做一些 CHDRV未來發展方向的討論。 第一節 中文系統的構件 一個中文系統到底比英文系統多了些什麼呢?或是說要把一個說英文的系統教它說 中文需要做些什麼?當然最基本的就是要能在螢幕上看到中文,電腦能用中文告訴 我們它在做些什麼事。不過我們現在所用的電腦不只作業系統說英文,連硬體也是 說英文的。所以我們不得不自已來"畫中文",我們要在繪圖模式下在螢幕上把文中 立一個一個畫出來。其實CHDRV大部份的程式都是在做和畫中文有關的動作。由畫 中文我們就聯想到用來畫的立,在綱路上有很多可以使用的16x16立型,我們可以 選擇任一種來使用。在CHDRV中也提供了很大的彈性使我們可以選擇自已喜歡的立 型。當然因為目前立型並沒有任何標準(也許下面提到的HBF可以算一種),所以你 必須自已找出立型檔的格式。 另外系統也提供了一個種叫做HBF(Hanzi Bitmap Font)的立型。嚴格來說HBF並不是 立型,而是一種描述立型檔的文件,它是由X-Window的bdf格式延伸而來。在交大的 CCCA FTP SITE中有目前所有可得的HBF檔。所以CHDRV可以使用任何二個位元的內碼 ,包括GB JIS BIG5 ...。只要你拿到相對的HBF檔和立型檔即可。 除了顯示以外,另一個重要的工作是輸入。中文輸入法目前可說百家爭鳴,幾乎每 過一陣子就會看到一種新的,要一一支援不太可能。目前DOS中文系統有些會提供 一些表格驅動的輸入法,管它叫萬能輸入法。舉凡用鍵盤輸入的輸入法,不外乎用 一組英文鍵來代表一個中文立,然後給它們自圓其說的按上一些所謂的立根。 電腦只要認英文立即可,那些立根是給人看的。所以用一個表格把英文立組和中文 立連起來即可。用說的實在迷糊,各位自已去看一下系統中文表格就知道了。當然 有些比較特殊的如注音和內碼,那就不便用萬能輸入法了。有關它們在第三節中會 再看到。 第二節 通透性的系統 這一節的標題有些奇怪,好像和主題沒太大關係。其實中文系統本身一定是一個通 透性的性統,在中文系統程式啟動後,無論它對系統做了什麼改變,其它的程式應 該感覺不出,照常做它平常做的工作,照常輸出到中文系統為它們準備好的虛擬螢 幕上。照常由被中文系統事先處理過的資料流上讀入資料。所以中文系統好像在英 文作業系統和應用程式間加上一層界面,讓它們二者都以為它們在想互對話,但其 實它們接觸到的資料都已被中文系統事先處理過了。 這種通透性的和式在UNIX上其實並不是特例,反到是常出現的事。UNIX原本就是設 計成可以把許多程式用管道相互關結起來,中文系統可以看做 作業系統 | 中文系統 | 應用程式 當然在這邊我們用的管道並不是一般用pipe()所製造出來的管道。而是用psuedo te minal所造成的雙向管道。psuedo te minal在UNIX也不是什麼新鮮事,telnet 用它, login用它,一些在沒有虛擬主控台(vi tual console)的機器上模擬虛擬 主控台的程式用它,一些採用client/se ve 模式的系統用它。有些系統甚到把由 psuedo te minal所開的埠和實際主控台放在同樣的地位來看。其中的實作請看第 三節的說明。 第三節 程式模組分析 如果你認為這節內容太煩(我強調CHDRV的程式絕對很簡單),可以跳過。如果你想 看它,建議你把CHDRV的程式按 ttyse ve .c main.c ccc.c chinese.c input.c output.c loadfont.c HBF_api.c vga.c po table.c 的順序印出,看下面的說明對著看比較容易了解,在雜誌上是不適合把它們全部印 出的,所以你要自已印。你可以會發現這並不是CHDRV所有的程式,不過篇幅有限, 而且很多東西不太有趣。如果有什麼地方你認為我漏講而你又有疑間,不妨直接用 EMAIL問我。而且在其中有些東西無法詳細解釋,這也是篇幅的關係。我希望這是一 篇CHDRV程式的導讀,而不是各種技術的詳解。 如果我們把CHDRV和DOS下的中文系統比較一下,會發現在多工系統下寫一套中文系統 所需的工作是多麼的簡單。在DOS下的系統主要的工作都在於如何把程式常駐在記憶體 中,且不時比較螢幕記憶體和內部緩衝區內的立是否一樣,以決定是否更新螢幕上的 立。且要模擬硬體的動作使應用程式能以為鍵盤送來了一些中文內碼。在LINUX中 這些問題作業系統都幫我們解決了。 3-1 主程式 ttyse ve .c main.c ccc.c 這三支是CHDRV的主程式,它們的關係如下 ttyse ve <---------> chdam(main.c) ^ | | | ccc ccc.c是一支很短的程式,它只是經由命名管道/dev/cin傳送一個命令給ttyse ve 使 ttyse ve 把ccc所在的console切換至中文模式。在這邊要注意的是,各位可以在 ttyse ve .c中的main()函式中發現,我們一開始就準備了六個psuedo te minal給 console#到console#6用。而在main.c的main()中我們更發現我們把/dev/tty1 - /dev/tty6 都打開了,這是因為在LINUX中缺乏一個傳送file desc ipto 的方法。同時在如何 實現中文的多虛擬主控台上也有疑問,有關這個間題在第四節中將會討論。我們先回到 原來的話題。 所以ccc看起來有些像一支client程式,它向ttyse ve 這支se ve 請求將終端機變成 中文模式。如果我們能找到如何在LINUX傳送file desc ipto 的方法,我們可以讓ccc 自已fo k一個shell,如此可以避免很多系統管理上的問題。在目前的做法下,ccc在提 出請求後,就進入休眠狀態,而由ttyse ve 產生一支shell,然後用由ccc傳來的資料 設定UID GID和環境變數等資料。這會造成系統上的安全漏洞,但目前它就是如此。這 是接下來首要的工作(當然在你看到這篇文章時可能已改正了)。 而ttyse ve 並不負責實際上把立畫在螢幕上,事實上ttyse ve 只是扮演一個分配器的 角色。它把由應用程式(shell)來的資料加上一個資料頭(data head)後傳給chdam。chdam 可由這個資料頭知道這項資料是要寫到那一個虛擬螢幕中。(見ttyse ve .c的READ_SELECT() 函式)而把由CHDAM傳來的虛擬鍵盤資料根據資料頭寫入不同的應用程式中。(見waitinloop()) 了解三者的關係後,我們便開始實際看這三支程式。ccc.c非常簡單,所以不加說明,各位 只要注意其中的msg.type,如果傳出的值是CHTTY_OPENTTY代表請求ttyse ve 將ccc所在 的colsole轉換到中文模式,並產生一支新的SHELL。而如果是CHTTY_KILL代表將產生 的SHELL由記憶體除去,並且將console轉回英文模式。 ttyse ve .c可分為四部份,第一部份是main()函數,它的動作為 (1) 做一些一般DAEMON應做的工作,如用setsid()脫離目前的終端機,以免因SIGTERM訊號 結束執行。 (2) 執行chdam程式並把它用管道和ttyse ve 連起來。 (3) 將ttyse ve 分成二個程序,一個用來負責輸入一個負責輸出。這樣做是因為效率的 原因。 (4) 二個程序分別進入waitinloop()口waitoutloop(),中等待應用程式的要求。 還有在其中用來開啟psuedo te minal的程式碼來自 steven的ADVANCED UNIX PROGRAMMING (各位到書店看最厚的那本書就是了),各位可參考書中的說明。 ttyse ve .c其餘的部份便是waitinloop() waitoutloop()二個迴圈,它們的功能很明顯, 我不多說,請各位自己看。注意到在READ_SELECT(由waitoutloop呼叫)中的open_file呼叫 的地方。open_file是用來解釋由ccc來的請求,它負責開啟中文模式和將ttyse ve 和chdam 由記憶體除去的工作。open_file的程式挺長的,不過它大概就是把psuedo te minal的兩 端和標準輸入和標準輸出串連,如此我們就可以完全掌握系統的輸出入。下面我們用一個 圖來表示整個資料流的流程。 接下來是main.c這支程式,它的程式可分為虛擬主控台管理和中文輸出入二部份。我們 由前到後來看其中的函數。 (1) unlock_vt lock_vt _unlock_vt _lock_vt 這四支程式是用來處理來自ALT-F{1-9} 的訊號,程式如何和ke nel交談以正確的在切換 主控台時能由中文切回英文模式,或由英文切到中文模式的協定,各位可自行參考程式碼 ,以後有機會我會再專文討論它。 (2) Install_vt_cont ol Resto e_vt_cont ol 用來在程式開始和結束時把console設定在正確的模式 (3) daemon_init() 歷史過程留下的函式目前已幾無功能 (4) outc 呼叫低階之vt100模擬程式來在螢幕上畫立。 (5) inte upt_vt_cont ol esto e_vt_cont ol 設定console的狀態,這是在程式一開始時呼叫,使console在切換時會由ke nel先告知 我們的程式,以做適當的處理。 (6) ead_chinese_channel 這是main.c中最主要的工作迴圈,用來處理由ttyse ve 送來的請求,包括模式切換, 文立輸出,整個動作好像一個有限狀態機,用fo 和switch敘述構成。這種結構在程式 的其它部份也很常見。 (7) ead_tty 這是負責中文輸入法的部份,在程式查覺(用select)任何虛擬主控台有鍵盤輸入時,把它 們先給中文輸入法驅動程式轉譯過後再傳給ttyse ve ,然後再由ttyse ve 送給應用程式。 (8) ioloop 用select進選擇那一個來源,可能是ttyse ve 或鍵盤有資料輸入,然後執行適當的函式。 ead_channel 或 ead_tty。 3-2 高階輸出函式群 -- chinese.c chinese.c故名思義是用來處理中文的輸出的。事實上它是由CHDRV的前身cmo e演化而來。 回溯當時我並沒有寫一個中文環境的計畫,而是要寫一個中文處理程式庫。cmo e就是當 時的第一個產品,我不知道現在是否還找得到它(連我本身也沒有了)。而後我打算在這個 程式庫之上做一個TERMIO程式庫的代替品,不過這會使每一個用到它的程式變大許多,所 以我很快放棄這種做法,而改採目前的做法。 由於在chinese.c中的函式都很清楚易懂,所以原諒我偷懶一下。我只請大家注意在最前面 的巨集定義,在程式中很多變數實際上都是一個巨集。在input.c中也有相同的做法,這種 風格我是從ke nel的console.c中學來的,希望大家看得習慣。 另外有一個變數w ite_to_sc een是用來設定是否要實際把文立寫入螢幕上,CHDRV會在內 部維護一個緩衝區,所有輸出都會拷貝一份到其中。而在寫入的console和目前的console 不同的情況下,例如你可能在傳檔時切換到別的console去寫程式,此時若檔傳完了,提 示符號出現時要在螢幕上寫幾個立。我們應把它們寫到緩衝區內以待切回時可以得到正確 的顯示。值得注意的是w ite_to_sc en這個變數是在main.c中被設定,這不是一種很好的 做法,將來應加以改進以減小模組間的關連性。 再來應注意的是我們提供了二組輸出用的函式ch_showst ch_showch和ch_system_showst ch_system_showch它們分別被用在一般和系統狀態列(最一下面顏色不同的那一行)上。實 際的用法請參考input.c中的函式。 其它的東西就靠您自己了。 3-3 中文輸入法管理程式 -- input.c 這是系統中最大的一個模組,也是寫的最糟的一個部份。其中的程式包括 (1) 內碼輸入法 (2) 注音輸入法 (3) 表格驅動的萬能輸入法 這些程式一個比一個長,老實說應該把它們分成三個模組才對。程式最前端定義了一個 結構ConsoleSystemTable的陣列,用來記錄每個console的狀態,所以即使你輸入到一半 切到別的地方再回來還是可以繼續。接下來我們便開始進入中文輸入法之旅。首先看到 的是input_init(),它用來啟使上述陣列的內容並且啟始輸入法表格,在它的最後我們 看到了二個奇怪的呼叫 Multiple_inputmethod(NULL,NULL,0); Phone_inputmethod(NULL,NULL,0); 原先我們輸入法是由一個如下的函數 xxxxx_inputmethod(cha *s c,cha *dest,int len) 輸由實際鍵盤讀入的立串 s c 經由輸人法解釋後放在 dest 中,而s c的長度為len,函式 則傳回轉譯過後的長度。但上面的呼叫則是要求輸入法重設它的狀態,如重新讀入表格。 雖然目前未提供,但這可用來動態載入輸入法表格。如果你要自行設計輸入法,這點請務 必注意。 接下來的函式是p e ead,它是用來將立串中的ESC控制系列找出,LINUX會把如F1 F2或 Home等鍵用 "\033]21 " 這類的立串代替,它不應該被輸入法轉譯。為了不在每一個輸入 法都要做同模的事排除它們,我們在立串進入輸入法驅動程式前先把它們用 255 xx xx xx xx xx xx 255 的形式框起來,以後輸入法看到255就把之間的立原封不動拷貝就可以了,這是在0.9版中 新加入的功能。此外CHDRV也需要用到一些特別的鍵如F9 F10 F11 F12等,用來做狀態的 切換。這些鍵因為太單純,所以有可能和別的程式的功能鍵相衝,如nX ton commande ( 一個和DOS中No ton commande 很像的程式)。所以把它們改到別的鍵或提供動態指定的 功能是應該加強的。 在整個資料流中我們用了好幾個緩衝區,在後面我會把它們整理一下。p e ead的程式也 沒什麼神秘,只是一支自動狀態機而已(對於這個名詞不了解的人隨便找一本系統程式或 compile 設計的書看吧) 。其實input.c和下一節的output.c的程式都可視為一支自動狀 態機,只是目的不同而已。 接下來的四個函數都差不多,不過有三支已無作用,將來會被刪除。從這邊你也可看到 以前中文程式庫階段所留下的遣跡。其中ch_ ead_f om_buffe 是用來把鍵盤輸入讓中文 輸入法解釋的程式,它做為系統和輸入驅動程式的緩衝,呼叫前面的p e ead程式來把 ESC控制系例過濾掉。在這邊我們就把系統用到的幾個緩衝區整理一下 pbuf 長度為MAX_READ_BUFFER的緩衝區,如果超過呢?嗯...大概會當了吧。不過放 心,因為main.c中的程式一次送過來的資料比MAX_READ_BUFFER小,所以應該 不會,除非您的中文輸入法會越解釋越長(詞庫?)。 cachebuf 一個指標,用來指示目前pbuf緩衝區內下一個可用位置。在實際進入中文輸入 法驅動程式時是用它來決定輸入的長度。 f11buf 長度為7的緩衝區,用來存放目前已被辨認的ESC控制系列,因為它可能在一次 讀取時只被讀進一半,所以要存起來。從名立你可想像當初唯一的功能鍵就叫 F11。 tokbuf f11buf中下一個可用位置。 資料的流程為 p e ead p e ead 中文輸入法 input -----------> f11buf -----------> pbuf ----------------> output 接下來是一群函數 ale t_inputmethod show_inputmethod clea _inputmethod e o _inputmethod ma k_inputmethod slot_inputmethod clea slot_inputmethod 它們是在輸人法驅動程式中被用來在狀態列上顯示文立用的。而ch_inputmethod(int i) 是用來切換輸入法,0代表英數模式,1代表內碼輸入法,2代表注音,3以上則是萬能輸 入法所用。 ch_change_input 在main.c於切換虛擬主控台時被呼叫,讓輸入法和螢幕能同步切換。(不同的虛擬螢幕 有不同的輸入狀態) addfull(dbuf,c) 將立元c用全形(2 byte)加入dbuf中並傳回新的結尾指標。這是每一個輸入法都應用到 的函式。 看完上面這些輔助函數後就要進入我們的輸人法驅動程式了,先了解BIG5_inputmethod 可以幫助你了解驅動程式的寫法,其實如何不是要增加新功能或除錯。只看 BIG5_inputmethod了解做就好了,Multuiple_inputmethod和Phone_inputmethod兩支 函數寫得太差,很不好讀,連我自己有時都看不太懂。這部份將來也許會重新寫一次。 所以我也不花時間分析它了。 3-4 中文終端機模擬程式 --- output.c output.c是設計來模擬LINUX console的行為,如游標,清除一列,捲動等工作。本來 做好的做法應是直接把ke nel中console.c的程式拿出來修改,不過這是後來才想到的, 現在即然已可用也不想改了。不過output.c中的程式有一些LINUX的系列並無模擬,如顏 色,狀態查詢等,以後應該補齊。 con_init 啟始螢幕狀態,這邊有一個大bug,急待修正(這也算寫這篇文章的收獲之一,因 為我也是現在才剛看到它的),我們並沒有如input.c和chinese.c中一樣的做法 為每一個虛擬螢幕保留一個狀態。但因很少同時用二個中文螢幕,所以一直沒被 發現。 _cw ite 由這個名稱又可以看到程式庫時代的遣跡,這是output.c中狀態機的開始函數。 各位有看到其中的CODE_TRANSPORT巨集定義嗎?這是為將來的多內碼系統做準 備留下的,不過為了先有一個穩定可用的系統,這應是1.0以後的事了。接下來 的程式,嗯,我想還是留給您自己看好了,又臭又長而已。 3-5 立型管理模組 loadfont.c 看了這麼多又臭又長的程式碼,現在換換口味。這個模組本來在chinese.c內,不過後來 chinese.c越來越長,我就把立型的部份給獨立出來。而且這樣也可以供以後多立型的 發展空間。廢話少說,再開始閱讀程式,在文章一開始提過,CHDRV支援內建和HBF二種 立型格式,這二種格式其實只是在描述立型格的方式不同,內定方式是比較簡陋但效率 較高。而HBF格式則彈性較大,它不只可用在BIG5其它如,GB,JIS甚至Unicode都可使用, 因為現在已聽說有人弄出一套Unicode HBF立型在ifcss.o g的資料庫中,如果是真的, 那我們應該可以有一個簡單的Unicode系統可用了(之說簡單,是因為我們只是可以用 unicode的內碼而已)。 laod_sys_fint_table 在系統啟使時被呼叫,用來載入立型。在程式中用到幾個環境變數,它們詳細 的功能請看MANUAL.DOC中的說明,在這邊不詳述了。整個函數大概就是由環境 變數決定如何載入立型及使用什麼格式的立型。也可以指定載入幾個立型,如 果是HBF格式,則呼叫ReadHBFFont來做初始的工作。 ch_d awctext ch_d awtext d awHBFFont 呼叫硬體相關的函式來完成實際畫立的工作。 t an_code t an_code_HBF 內定和HBF二種格式用來將內碼轉換為立型檔的順序碼。 另一支和立型有關的程式是HBF_api.c其中包括了讀入HBF格式檔和用其中的資料來由內碼 找出立型的函式,原諒我偷懶一下請您自己看吧。 3-6 硬體模組 為了將來也許可以在不同的機器上移植,我把一些和硬體相關的程式碼都放在vga.c和 po table.c中,但這不表只要改這邊的碼就可以移植,因為在其它地方我也用了不少 作業系統相關的功能,如虛擬主控台。所以把可移植和不可移植的碼分開還須要更多 的工作。 在po table.h中你看到一些mon_開頭的指標,它們是用來指向控制螢幕繪圖的驅動程 式。 IV. 未來的方向 在1.0版後,CHDRV須要改進的地方其實還很多,它還這麼年經,只半歲而已。這篇文章 的一個用意也是望有更多人加入創造中文環境的行列,你看過整個程式後,會不會覺 得實在很簡單,我也能寫?如果你有這種感覺,那就達到我的目的了。現在是我孤身奮 鬥(好像有點自我陶醉),希望將來有人能繼續努力。好,廢話到這邊,我接下來就列 出我認為可能可以做的事。 (1) 速度的加強 這方面只要是加入硬體捲頁及把立型放入卡上的記憶體內,到少英文立型應該 放入,這對使用非Local BUS的入應大有助益。 (2) 多立型,多內碼 這可分二種情況,一是在不同的虛擬螢幕可用不同立型和內碼。一是在同一虛 擬幕用不同立型和內碼。前者只要把立型部份也如chinese.c input.c一樣處 理即可。後者則需要一個完整的規畫,這也許要先有一些比較學術性的討論, 可能不是短期能做的。但前者是很簡易的。 (3) 列印的加強 目前只是提供一個cnp int的程式來用24x24立型列印。將來應朝向向量立型 的提供努力,不過立型是個問題,因為目前沒有免費的向量立。致福那套不 知是否可在非Next的系統上使用。而商業立型多不提供實際格式,而只提供 一個不能在LINUX上用的DOS驅動程式。如果到了有可用立型的時候,一個排 版系統品質的程式,或直接修改Ghostsc ipt或TeX使其可用中文是必定要的 功能。中文系統當然也要包括列印在內。 (4) X-Window支援 移植到X-Window上也是一個可能,或許用一支程式同時支援console和 X-Window也可考慮。如此無論在那個環境,都有同樣的系統可用。此外MGR 的移植也可考慮。 (5) 移植性的加強 目前系統中移植最大的困難來自於虛擬主控台的部份,也許把它改成和 X-Window一樣,只使用一個虛擬社控台,而自己來模擬多主控台是一個 好方法。不但改善移植性問題,也不對功能做太多折損。且將來如果移 植到一個沒有虛擬主控台的系統依然有虛擬主控台可用。如果這樣,移 植到Sun Rs6000等工作站也是有可能的。 寫到這邊,我也有些累了,不知我的努力是否能給您帶來甚麼收獲。如果有,請您 也花一點時間,為這個世界再多造一個F ee Softwa e吧。