標題：編寫適用于模擬器的Linux代碼

編寫適用于模擬器的Linux代碼
在某臺計算機上模擬其他計算機的歷史已經很長，通常是為了使用遺留應用程序，或者是為了使用更穩定、響應更快的OS的系統上運行流行的OS而編寫的應用程序。隨著Linux越來越流行，當開發人員規劃將運行于非Linux系統上的二進制程序時，需要審視他們的選擇。本文將研究模擬器的功能，并將詳細地研究硬件模擬和軟件模擬的問題。
在某臺計算機上模擬其他計算機已有多年的歷史。模擬老的計算機的一個常見原因是懷舊，不過不可否認，很多模擬器能夠非常出色地運行多種計算機游戲。模擬其他計算機的另一個原因是為了使用只存在于某個特定平臺上的應用程序軟件。
通常，應用程序模擬以占據較大市場份額的平臺為目標。例如，WINE 項目嘗試去提供一個運行 Windows二進制程序的途徑。
不過，近年來Linux已經被證明是一個穩定而且全能的操作系統；因而，它的市場份額也有所增長。市場份額的增長激起了人們對模擬Linux的興趣。本文評論了在其他系統上進行Linux二進制程序模擬的現狀，并著重指出為了讓人們更方便地在模擬環境中運行他們的二進制程序，開發人員應該緊記的一些問題。
基本的模擬器
模擬器的思想很簡單。計算機是充分可預測的。如果您想確切地了解如果給出一段特定的代碼計算機會做什么，那么通過建立這臺計算機的模型就可以得到結果。當然，這會涉及到相當多的開銷，但是，如果要模擬的計算機比正在進行模擬的計算機老得多，那么模擬環境將比原來的機器更快。
有一些模擬層，比如NetBSD的Linux模擬層，只是提供某個環境的軟件部分的模擬，從 Linux 程序庫取得系統調用，并處理返回結果，使得看起來像是在使用 Linux內核。其他的模擬層，比如VirtualPC，可以模擬整臺計算機，包括處理器。模擬處理器的速度會更慢，但是可以帶來更好的兼容性。
發行版本格式的模擬器
盡管本文重點關注的是在其他平臺上運行Linux二進制程序的方法，但是，經過編譯的二進制程序發行版本同樣占有一席之地。隨著Linux模擬環境越來越普及，Linux二進制程序格式成為發行簡單程序（不給出源代碼）的一個可行方法。Linux二進制程序可以在多種系統上運行，無可否認，有時需要付出一些代價——以Linux二進制程序格式作為通用發行版本格式還會遇到一些挑戰。
通常，模擬不足以讓您在為另一個系統構建的程序中運行為某個系統構建的共享對象。如果您的產品大部分是以共享程序庫對象的形式發行的，那么這些產品可能不會被加載到其他平臺上。
有人認為，使用Linux二進制程序格式來向其他平臺發行代碼是瘋狂的。也許這很瘋狂，但它是可行的。近幾年，我的主要的Web瀏覽器就一直在模擬環境中運行（更不用提字處理器、文檔轉換器，甚至信用卡處理軟件）。
我們樂于使用的大部分軟件應用程序都是商用的，并且，能夠發行可以運行在很多平臺之上的單一的二進制程序會使商業軟件供應商大大受益。如果有多種多樣的Linux模擬環境可用，那么Linux二進制程序格式會表現為第一個真正的軟件發行版本選擇。
噢，移植源代碼是與發行有很大區別的任務；通常，移植任務更為簡單。
完全硬件模擬器
完全硬件模擬器會模擬一臺完整的機器；不只是處理器，還包括機器所有其余部分。例如，被模擬的計算機可能擁有自己的鍵盤控制器和視頻卡。
完全硬件模擬常用于使用較老機器的程序。MAME街機游戲（arcade game）模擬器就是一個流行的示例，它模擬了多種老式街機游戲機的硬件。
就某些方面而言，完全硬件模擬器是進行模擬的最簡單方式。很多工作都需要構建一個完全硬件模擬器，但是一旦您擁有這樣一個模擬器，所有的事情就都可以迎刃而解。例如，用于 Macintosh 的 VirtualPC 版本 3 開始支持 Linux。
硬件模擬可以解決使用其他方式難以解決的問題。例如，我以前有一個BIOS閃存工具，僅以用于DOS的自解壓縮的映像文件的格式發布。更糟糕的是，運行它的機器必須在傳統的 ISA 軟盤控制器上安裝實際的軟盤（我的 Windows 桌面機有一個 LS-120 驅動器）。通過模擬來解決這個問題吧！我在模擬器下運行該程序，將數據寫入已經插入 Mac 的一個 USB 軟盤驅動器。
硬件模擬也有其不利方面。為了讓一切都能夠運轉，需要付出很大努力。如果需要網絡，那么還需要很好地模擬網絡芯片，以使得操作系統可以在這個芯片上運行。此外，模擬本身所沒有的指令的代價可能非常高昂。通常，像這樣一個系統可以近乎完美地運轉，但是，與時限（timing）相關的功能可能會不可靠。
完全硬件模擬器已經使用了很長時間，最適合處理速度可能受模擬影響的遺留系統和代碼。
雖然如此，想要在 Macintosh 或者任何其他非 x-86 機器上運行x86Linux二進制程序的用戶，為了嘗試運行程序，可能要完全依賴于某種當前可用的x86模擬器。在類似這樣的系統上，大部分工具程序將運行得非常好（雖然可能較慢）。要擔心的惟一一個主要顧慮是，為了提高性能，這種系統的用戶可能安裝較小的或者較老的 Linux 發行版本。使用 32 MB 內存來運行模擬機器的那些人不可能運行最新版本的 KDE。
部分硬件模擬器
部分硬件模擬器是一個中間解決方案：它們模擬一臺計算機，但是這臺計算機只能是與它們實際上所在的計算機類型相同的計算機。由于執行的速度與宿主機器相當，所以類似這樣的程序可以降低模擬的成本。此類模擬器的示例包括 Serenity Virtual Station 和 VMWare。
當您擁有用于多種操作系統的應用程序，而且需要同時運行它們時，這些系統最為實用。類似于完全硬件模擬，這樣的系統將運行一個完全的 Linux OS 環境，只要您的程序能夠適當地跨Linux系統移植，那么就沒什么問題。不過，再次聲明，Linux的移植到較老版本的可移植性將有非常有用。使用虛擬機的人們可能愿意在這樣的系統上運行一個較老的、占空間較小的 Linux 版本。
軟件模擬器
在模擬世界中，軟件模擬器是最基本的。軟件模擬器不在某臺虛擬機上運行您的應用程序——它不通過虛擬機，而是實時地去運行它。建立一個環境，在這個環境中，程序的代碼可以正常運行，但是，程序訪問操作系統的嘗試會被通過某個模擬層來發送，這樣，這些程序就可以使用了。WINE是一個極好的示例（雖然是用于Windows），盡管它并不是一個正式的模擬器。
有一些軟件模擬器是由用戶顯式地調用，比如可用于 SCO 和 Solaris系統的lxrun程序。有些軟件模擬器則構建成為UNIX內核對加載二進制映像的支持 —— 如果程序看起來不正確，那么，可以將它與一個可能模擬器表相對照，以查看它們是否可以運行它。
軟件模擬器通常會帶來最好的用戶體驗。不需要特殊的設置，不需要龐大的磁盤映像。程序只需要去運行即可（大部分情況下）。不過，訪問系統調用、共享程序庫以及文件系統結構會引發許多問題，所以，接下來我們將討論它們。
系統調用
系統調用是模擬中最簡單也是最困難的部分。系統調用具有明確定義的接口，而且，通常可以方便地檢測并處理調用機制——這是簡單的部分。困難之處在于可能難以或者不可能較好地實現系統調用。傳統上，Linux模擬中最難以處理的是clone()系統調用。這個調用提供了獲得簡單線程的一個強制方法，即創建兩個共享許多內容進程，共享的內容可以包括內存、文件描述符、信號處理——換句話說，可以包括任何內容和所有內容。不幸的是，如果您的操作系統不具備與此完全類似的功能，那么沒有任何辦法來實現這個系統調用。
更糟糕的是，由于當POSIX線程還沒有完善或獲得廣泛支持之前，clone()就已經出現，并經常被用作POSIX線程的替代，所以，許多程序都以多種令人興奮的、復雜的且（我必須要說）意想不到的方式來使用它。
如果您想讓人們運行您的二進制程序，那么嘗試讓他們不要使用針對特定操作系統的系統調用；最好使用標準的POSIX系統調用。這是軟件開發的一個良好的習慣做法。
基于內核的模擬器可以捕捉到到達它的系統調用。用戶空間模擬器，比如 lxrun，會等待應用程序嘗試進行系統調用。由于 Linux 系統調用功能與 Solaris 或SCOUNIX上的系統調用功能不同，所以結果是發生一個代碼段錯誤。然后，lxrun程序像一個調試器那樣糾正這個錯誤并使系統調用繼續運行——但是，實際上，它已經截取了這個系統調用，并向底層操作系統進行相應的系統調用，而且解決了所有問題。聰明！
文件系統結構
文件系統的問題通常更為微妙。訪問文件系統極其簡單。不簡單的是如何找到您想要的文件。
如果您的程序在模擬環境中運行，那么要訪問的文件系統可能與您開發程序時使用的文件系統有本質上的不同。例如，如果您的程序使用了/proc文件系統（常用來獲得內核狀態和信息），那么在較新的內核中常見的特性在較老的系統中可能并不存在。
這里的開發人員比專有系統上的開發人員擁有巨大的優勢，因為不同的Linux發行版本以不同方式安排文件，所以大部分程序員都非常清楚如何避免過分依賴于文件系統設計。但是 —— 有時 —— 不得不將文件名嵌入到程序之中。
許多模擬器解決這個難題所采取的一個方案是：建立一個針對文件系統調用的額外的解釋層。例如，在 NetBSD 的 Linux 模擬環境代碼中，首先根據 /emul/linux中的文件檢查對文件的訪問，之后才對系統真正的root目錄中的文件進行檢查。這就使得當Linux二進制程序不能使用標準文件時，系統可以提供“覆蓋（override）”系統文件的文件。
實際上，這一方法的主要用途在于程序庫和其他支持文件，不過也同樣提供了許多系統二進制程序。例如，如果 Linux 二進制程序嘗試調用 uname 來得到內核版本，卻得到了NetBSD的版本號，這將非常令人迷惑。取而代之，它應得到所預期的 Linux 版本號。
共享程序庫
如前所述，共享程序庫是能夠被模擬的二進制程序找到卻不能夠被系統二進制程序找到的一個非常好的例子。由于在不同的系統上共享程序庫的格式和 ABI 細節可能各異，所以不能隨意假定所有的系統都可以共享某個給定的程序庫。名稱可能沖突 —— 例如，當前NetBSD和SUSE7.3都擁有一個名為libncurses.so.5的文件。重要的是要使用其中正確的那一個。
共享程序庫為開發人員指出了另外一個注意事項。了解不同的系統正在使用的程序庫版本很重要。現在，NetBSD 的 Linux 模擬環境正在使用的是 SUSE 7.3 共享程序庫。仍然有使用9.1共享程序庫的代碼，但是它們會獲得警告，告之它們不能穩定地進行內核級模擬。
模擬環境軟件包通常遠遠跟不上市場的步伐。即使您覺得大部分預期用戶都應該擁有了相當新的Linux發行版本，但是大批模擬器還是幾乎全都有些跟不上時代。
共享程序庫還引發了另一個顧慮——不是每個系統都包含全部共享程序庫。模擬環境軟件包通常不會安裝所有最新的共享程序庫。而且，更麻煩的是，它們的用戶也不太可能有能力輕松地安裝所缺少的軟件包。
在這些情況下，最大限度地減少對新特性和非核心共享程序庫的依賴是一個好辦法。模擬器用戶可能會遇到這些問題。
不要誤以為使用靜態程序庫就可以保證解決這些問題。靜態程序庫可能引入其自己的新的依賴，而且不容易檢查到它們。如果靜態地鏈接了一個使用某個不可移植的系統調用，那么通過重寫算法來避免這個系統調用將沒有什么用處。動態鏈接讓您構建的程序能夠在更大范圍內的系統上運行。
調用其他程序的程序
有一種特別的情形比任何其他情形更令人們頭疼，尤其與安裝器相關。在很多系統上，調用 /bin/sh 所得到的 shell 不是bash。這就意味著使用 bash 擴展的腳本可能不能在其他系統上運行。
這就陷入了模擬器中的一個特別錯綜復雜的邏輯中。當執行二進制程序時，操作系統可能知道的足夠多，可以核對相關的Linux二進制程序的Linux路徑，而且它可能在那里安裝 bash 的一個副本。但是，當您運行一個腳本時，內核不會將其看作是一個 Linux二進制程序；它發現腳本附帶有一個解釋程序路徑，當嘗試加載解釋程序時，它將不再運行于模擬模式之下。
可移植shell腳本技術在這里得到了應用。當用戶運行被模擬的應用程序時，這是要面對的最常見問題之一。安裝器可能會因為不是可移植的 shell 腳本而不能運行。
類似于標準的開發，只是更為標準
為了方便那些可能要在模擬環境中運行您的程序的用戶，開發軟件時需要緊記以下事項，并且開發任何軟件時都應該緊記這些事項：
盡可能遵循適當的標準。
避免“專門特性”。
不要挑戰極限（push the envelope）。
而且，只要可以避免，就不要依賴于一個月前剛剛發布的某些東西來構建您的代碼。因為那樣做將縮小您的有效的目標市場。