關(guān)鍵字 linux 源代碼 移植
原作者姓名 很土
介紹
用一個(gè)例子簡單說明了從linux平臺(tái)移植到windows平臺(tái)上的一些需要注意的問題和解決方法.
例子僅用來說明移植過程產(chǎn)生的問題用.
正文
簡單Linux代碼移植方法
一．前言
Linux 擁有豐富各種源代碼資源,但是大部分代碼在Windows平臺(tái)情況是無法正常編譯的。Windows平臺(tái)根本無法直接利用這些源代碼資源。如果想要使用完整的代碼，就要做移植工作。因?yàn)镃/C++ Library的不同和其他的一些原因，移植C/C++代碼是一項(xiàng)困難的工作。本文將以一個(gè)實(shí)際的例子（Tar）來說明如何把Linux代碼移植到 Windows平臺(tái)上。移植過程將盡量少修改代碼,以便代碼的運(yùn)行邏輯不會(huì)發(fā)生任何變動(dòng)。保留絕大部分軟件主要功能。
二．準(zhǔn)備工作
Tar是Linux平臺(tái)下面一個(gè)打包工具。移植這樣一個(gè)程序到windows平臺(tái)需要做那些工作呢？
首先是一些準(zhǔn)備工作，在Windows平臺(tái)上面安裝上Cygwin的最新版本，在Cygwin中安裝好GCC等開發(fā)工具。同樣也需要一個(gè)Windows開發(fā)環(huán)境?？梢允褂米钚掳姹綱isual Studio, Microsoft Visual Studio .NET 2003。從www.gnu.org上取得Tar的最新源代碼，版本是1.13。在Cygwin下面解開tar-1.13.tar.gz.源代碼包。注意請不要在Windows下面使用WINRAR或者WINZIP來解壓縮。 WINRAR和WINZIP在解壓縮某些tar.gz包的時(shí)候會(huì)有問題。使得解包之后的目錄和文件出現(xiàn)異常。如果是源代碼包將有可能不能在Cygwin下面正確編譯。解開壓縮包之后，進(jìn)入 tar-1.13目錄，在當(dāng)前的目錄下面輸入
./configure
命令，運(yùn)行完畢之后，再次輸入
make
命令。開始編譯tar的Cygwin版本。
編譯基本上不會(huì)有問題，進(jìn)入src目錄，可以看到新編譯好的Tar程序tar.exe。
Cygwin 是一個(gè)API層的Linux模擬環(huán)境。如果能夠在Cygwin下面編譯，運(yùn)行。實(shí)際上也就是能在Windows下面編譯和運(yùn)行，只是需要有一層中間API 模擬某些Linux特有的操作。簡單的判斷一個(gè)Linux程序能不能移植到Windows平臺(tái)下面，就是看是否能在Cygwin下面編譯源代碼，并運(yùn)行程序。
在Cygwin中編譯Tar的源代碼，判斷能否移植只是其中一個(gè)原因。另外一個(gè)原因是移植代碼過程中需要一個(gè)特殊的頭文件config.h。 config.h是移植過程中最重要的源代碼文件。Config.h文件并不是源代碼本身的一部分。文件是在Cygwin下面運(yùn)行”. /configure”命令時(shí)生成的。在Cygwin下運(yùn)行”./Configure”命令時(shí)，會(huì)根據(jù)Cygwin平臺(tái)開發(fā)環(huán)境生成config.h文件。編譯時(shí)也需要config.h文件對代碼編譯項(xiàng)進(jìn)行控制。移植工作也以config.h文件為基礎(chǔ)。
接下來就是構(gòu)造Windows工程。先用 Visual Studio .NET 2003創(chuàng)建一個(gè)空的工程（Project），命名為WinTar。根據(jù)Cygwin中的編譯輸出信息，Tar主要的代碼在Src和lib兩個(gè)目錄中。把這兩個(gè)目錄復(fù)制到新工程里，并把代碼加入到工程中。然后復(fù)制Config.h到WinTar工程目錄下面。
準(zhǔn)備工作基本上完成了，接著就是移植。移植過程可以分為3個(gè)部分。
三．第一個(gè)目標(biāo)：使得WinTar能編譯過（Compiler）。
???? 第一個(gè)目標(biāo)的完成主要圍繞Config.h來實(shí)現(xiàn)。Linux下開發(fā)環(huán)境和Windows開發(fā)環(huán)境很大的不同是C Library頭文件和各種類型的定義不同。而Config.h提供了完整編譯開關(guān)來處理因?yàn)椴煌脚_(tái)間開發(fā)環(huán)境不同帶來的不同之處?，F(xiàn)在需要手工去修改這個(gè)文件，以便Tar源代碼能適應(yīng)Windows平臺(tái)。
????首先調(diào)整各種C Library頭文件（Header File）的包含問題。在Config.h中定義了很多類似HAVE_XXXX_H。比如定義HAVE_CONFIG_H為1表示工程中可以使用config.h。
#define HAVE_MALLOC_H 1表示可以在工程中使用Malloc.h頭文件。通過調(diào)整這些定義值，可以去除一些Windows平臺(tái)下面沒有的頭文件包含。也許其他地方還有很多頭文件包含關(guān)系需要處理，但是這里的定義基本上解決了大部分的頭文件包含問題。
/* Define if you have the <linux/fd.h> header file.??*/
/* #undef HAVE_LINUX_FD_H */
/* Define if you have the <locale.h> header file.??*/
#define HAVE_LOCALE_H 1
/* Define if you have the <malloc.h> header file.??*/
#define HAVE_MALLOC_H 1
/* Define if you have the <memory.h> header file.??*/
#define HAVE_MEMORY_H 1
/* Define if you have the <ndir.h> header file.??*/
/* #undef HAVE_NDIR_H */
第二步，調(diào)整各種數(shù)據(jù)類型的定義，可能在linux下面會(huì)有很多特殊的數(shù)據(jù)類型定義，Config.h文件中也包含了一部分可以變動(dòng)的數(shù)據(jù)類型定義項(xiàng)。這些定義一般都是基本數(shù)據(jù)類型的重定義。可以根據(jù)Windows平臺(tái)下的數(shù)據(jù)類型定義情況進(jìn)行修補(bǔ)。比如在Cygwin的開發(fā)環(huán)境中有個(gè)數(shù)據(jù)類型 mode_t， Visual Studio的C Library中卻(作者 很土,聯(lián)系方法 jackforce at 163 dot com)找不到這樣數(shù)據(jù)類型。Tar代碼中使用了大量的mode_t數(shù)據(jù)類型. config.h中提供了修改項(xiàng)來讓開發(fā)人員自己修改mode_t的定義，并提示如果mode_t在<sys/types.h>中沒有定義的話，可以把他定義為int型。所以在config.h加上#define mode_t int。這樣mode_t沒有定義的問題就解決了。其他的數(shù)據(jù)類型也是同樣對待處理。
* Define to `int' if <sys/types.h> doesn't define.??*/
#define mode_t int
/* Define to `long' if <sys/types.h> doesn't define.??*/
/* #undef off_t */
/* Define to `int' if <sys/types.h> doesn't define.??*/
#define pid_t int
第三步，調(diào)整各種函數(shù)定義。在Config.h中除了HAVE_XXXXX_H之外還有一種預(yù)定義，HAVE_XXXX。這是一些可選用函數(shù)定義開關(guān)。#define HAVE_MEMSET 1 表示工程中可以使用memset函數(shù)。也就是說工程用到的類庫中已經(jīng)實(shí)現(xiàn)了這個(gè)函數(shù)。如果沒有，那么就需要＃undef HAVE_MEMSET，當(dāng)然也可以自己提供這些函數(shù)。
/* Define if you have the memset function.??*/
#define HAVE_MEMSET 1
/* Define if you have the mkdir function.??*/
#define HAVE_MKDIR 1
/* Define if you have the mkfifo function.??*/
#define HAVE_MKFIFO 1
/* Define if you have the munmap function.??*/
#define HAVE_MUNMAP 1
最后，Config.h文件中除了上面的頭文件，函數(shù)，數(shù)據(jù)類型編譯選項(xiàng)之外，還有其他一些東西，比如環(huán)境變量，其他編譯選項(xiàng)。這些內(nèi)容會(huì)根據(jù)不同的項(xiàng)目而有很大的不同。但是可以從Config.h基本看出移植的工作量有多大。
經(jīng)過上面的調(diào)整之后，勢必(作者很土,其他文章請查看vchelp很土專欄)因?yàn)閃indows環(huán)境下沒有某些頭文件，比如poll.h,就會(huì)沒有poll函數(shù)，沒有dirent.h 就會(huì)沒有dirent 結(jié)構(gòu)體。而繼續(xù)使得WinTar編譯不過。這個(gè)時(shí)候就需要根據(jù)具體的編譯錯(cuò)誤信息進(jìn)行細(xì)節(jié)修飾。當(dāng)需要使用Windows下一些特殊的定義的時(shí)候請不要忘了在Config.h的最前面加入#include <Windows.h>.
關(guān)于細(xì)節(jié)修飾，舉個(gè)例子來說明。比如有個(gè)選項(xiàng)HAVE_INTTYPES_H
/* Define if <inttypes.h> exists, doesn't clash with <sys/types.h>,
?? and declares uintmax_t.??*/
#define HAVE_INTTYPES_H 1
通過分析代碼可以發(fā)現(xiàn)，代碼并不是需要一個(gè)完整的inttypes.h文件，而是為了一個(gè)uintmax_t的定義。在Visual Stdio的C Library中并沒有inttypes.h這個(gè)文件，也沒有uintmax_t這個(gè)定義?；厮軨ygwin的include目錄的inttypes.h 文件，發(fā)現(xiàn)了uintmax_t的定義
typedef unsigned long long uintmax_t;
很簡單的數(shù)據(jù)類型重定義。這么簡單定義，完全可以從Cygwin的Include目錄中單獨(dú)拿出來做一個(gè)專用版本的inttypes.h加入到WinTar項(xiàng)目中。這樣編譯過程中uintmax_t沒有定義的問題就解決了。解決這類問題的一般的做法也就是從Cygwin的Include目錄里面拿出相關(guān)的頭文件進(jìn)行修改或者單獨(dú)復(fù)制到WinTar的目錄下面。[本文于2003年完成. 如需要轉(zhuǎn)載 請聯(lián)系jackforce??at 163 dot com ]修改或者復(fù)制代碼的原則是不再引入更多的定義或者頭文件,僅取所需部分。其他類似的問題還有direct結(jié)構(gòu)定義和相關(guān)函數(shù)。
在編譯過程中,很多錯(cuò)誤是有由lib目錄下的文件產(chǎn)生的,但是lib目錄下的文件不是完全都需要的。lib目錄只是一個(gè)對Tar的補(bǔ)充庫。需要的代碼才需要編譯。具體判斷的方法一個(gè)是參考Windows C Library庫的內(nèi)容。如果同樣的函數(shù),數(shù)據(jù)類型已經(jīng)定義,就不需要Lib目錄中的相同數(shù)據(jù)類型的定義和函數(shù)實(shí)現(xiàn)了。還有一個(gè)方法是盡量去掉lib目錄中的C文件,只保留頭文件,并使得編譯能夠通過,根據(jù)link的錯(cuò)誤信息去檢查那些lib中的C文件是需要的。
除了修改外圍的各種頭文件之外，還不要忘了修改工程的編譯選項(xiàng)，特別是預(yù)定義選項(xiàng)。在Tar的移植過程就需要以下的預(yù)定義HAVE_CONFIG_H，_POSIX_SOURCE， MSDOS。HAVE_CONFIG_H 表示程序編譯需要config.h文件。為了方便期間，在tar移植過程中就放到工程的預(yù)編譯選項(xiàng)中了。MSDOS，移植的是Linux下的控制臺(tái)程序，而Windows平臺(tái)最接近Linux控制臺(tái)就是DOS，特別是一些環(huán)境變量設(shè)置和全局常量的定義。Tar的有些代碼針對MSDOS環(huán)境已經(jīng)做了一部分修正,這點(diǎn)在移植過程中可以利用起來。還有一個(gè)可選項(xiàng)是__CYGWIN__。有些Linux程序會(huì)針對Cygwin平臺(tái)做出代碼上的特殊設(shè)定。當(dāng)遇到這樣的代碼的時(shí)候，一定要加上__CYGWIN__預(yù)定義項(xiàng)，能夠大大減少移植需要的工作量。還有就是移植過程引入的各種Cygwin代碼中也可能需要 __CYGWIN__定義（有時(shí)候是其他的定義，比如_POSIX_SOURCE，或者_(dá)_INSIDE_CYGWIN__）。
經(jīng)過上述的幾個(gè)步驟。第一個(gè)目標(biāo)，代碼能夠編譯通過基本上是不會(huì)有什么問題的。只要把握好二個(gè)修改代碼的基本原則，第一。引入新的代碼，而不修改原有的代碼。在沒有辦法進(jìn)行調(diào)試前修改源代碼是不允許的，修改的不好就會(huì)引起最后代碼運(yùn)行邏輯的混亂，而且在代碼能夠運(yùn)行之前是很難發(fā)現(xiàn)問題的。所以除非非常有把握，否則不要修改被移植工程的源代碼。第二，引入新的代碼之后，不能因?yàn)檫@次引入而需要再次引入新的代碼。這樣子，就進(jìn)入死循環(huán)了。為了解決某個(gè)數(shù)據(jù)類型的定義，而引入了新的不能解釋的數(shù)據(jù)類型。這樣還不如不引入新的代碼。所以引入新的代碼，特別是很多頭文件。引入之前一定要做修改，只保留工程本身需要的部分，去除那些不需要的代碼。直到能編譯通過為止。
三：第二個(gè)目標(biāo)，使得代碼能夠鏈接過（Link）
????完成了第一個(gè)目標(biāo)之后，就會(huì)有大量的 link錯(cuò)誤。原因是前面引入了很多外部函數(shù)，外部全局常量只有定義而沒有實(shí)體，于是就會(huì)產(chǎn)生link錯(cuò)誤?，F(xiàn)在需要的是為代碼提供引入的函數(shù)實(shí)體，外部全局變量實(shí)體。一般都是函數(shù)link(本文于2003年完成. 如需要轉(zhuǎn)載 請聯(lián)系jackforce at 163.com)不到的比較多。
?? 要解決link錯(cuò)誤就需要了解不同平臺(tái)上面函數(shù)操作的區(qū)別，特別是某些概念的區(qū)別。這里最好的參考資料有兩個(gè)。一個(gè)是Windows Services for UNIX （SFU）的幫助文件，一個(gè)是MSDN中的一篇文章《UNIX Application Migration Guide》。SFU是微軟提供一個(gè)Unix兼容環(huán)境，有點(diǎn)像Cygwin。在安裝上SFU之后有一個(gè)幫助文件。其中有一部分就是Unix，Linux函數(shù)的說明，有些函數(shù)提供了信息說明可以用Windows Library中那些函數(shù)來替代。這點(diǎn)對于移植是很重要的（省事）。UNIX Application Migration Guide應(yīng)該不算文章而是有點(diǎn)像書了。它說明了很多windows和Unix系統(tǒng)（類Unix系統(tǒng)）中很多概念不同之處，針對這些不同的概念提供了很多相關(guān)的信息來說明如何進(jìn)行模擬這些不同之處。比如Unix系統(tǒng)中Signals概念可以使用Windows環(huán)境中的Event來替代。SIGALRM用 Windows Message來替代等。
?? SFU的幫助文件提供了一部分信息來說明Windows平臺(tái)中哪些低階函數(shù)（C 函數(shù)庫）可以替代相關(guān)Unix函數(shù)?！禪NIX Application Migration Guide》則提供了一種方法來轉(zhuǎn)換Unix平臺(tái)上的一些OS級的概念到windows上。實(shí)際上Cygwin下面也做了很多這樣的轉(zhuǎn)換。具體解決 link問題的時(shí)候可以參考Cygwin本身的實(shí)現(xiàn)。
??不過有些概念，比如安全權(quán)限方面的概念。在Linux平臺(tái)和windows平臺(tái)上面是完全不能互換的。而且windows平臺(tái)中的權(quán)限函數(shù)操作(本文于2003年完成. 如需要轉(zhuǎn)載請聯(lián)系jackforce@163.com)的過于復(fù)雜。這樣對于某些linux函數(shù)。比如getuid處理可以參考Cygwin的處理辦法。什么也不做直接返回0 （return 0）。當(dāng)代碼中遇到這些函數(shù)的時(shí)候可以從Cygwin的代碼中復(fù)制一個(gè)getuid出來。放入工程中去。
?? 利用這些資料，并通過相關(guān)的工具比如sourceinsight來搜索Cygwin本身的源代碼，Link問題并不難處理。只是有可能在處理link問題的過程中會(huì)回復(fù)到上面的問題，編譯不過。這個(gè)時(shí)候的代碼修改還是一定要注意不要引入太多的新的代碼，免得問題越來越復(fù)雜。
四：代碼運(yùn)行正常。
?? 實(shí)際上當(dāng)link問題解決之后，程序可以在windows環(huán)境中運(yùn)行時(shí)，一切就盡在掌握了。如果不考慮做多平臺(tái)的程序的話，這個(gè)時(shí)候就可以任意去修改程序了。不過在代碼調(diào)試過程可能需要一個(gè)參照，看看正常的程序運(yùn)行流程是怎么樣的。剛剛移植過來的程序在很多地方并不能馬上就能正常的運(yùn)行?；氐紺ygwin 中,重新編譯一個(gè)可以調(diào)試的版本（在GCC編譯選項(xiàng)加上-g3）,在需要的時(shí)候可以在Cygwin中調(diào)試程序。調(diào)試可以用GDB或者Insight。如果習(xí)慣Windows 平臺(tái)下面編程，可以使用Insight，這是一個(gè)TCL/TK腳本程序，它提供了一個(gè)Windows界面以方便用戶調(diào)試程序，不過Insight最終還是調(diào)用GDB。在這里具體調(diào)試就不細(xì)說明了。
五：多平臺(tái)代碼
????移植后的代碼(本文于2003年完成. 如需要轉(zhuǎn)載請聯(lián)系jackforce@163.com)如果需要在多個(gè)平臺(tái)上面運(yùn)行，就要在lib目錄里面大做文章了。提供自己的函數(shù)庫，并根據(jù)各個(gè)平臺(tái)進(jìn)行調(diào)整。 Tar的代碼由Config.h和一些編譯選項(xiàng)來控制如何在各個(gè)不同的平臺(tái)上面做編譯。Lib則提供了很多C Library函數(shù)或者不同平臺(tái)下面的其他函數(shù)的替代版本。這樣Tar在編譯過程中就不會(huì)因?yàn)槟承┢脚_(tái)下某些函數(shù)的缺失而編譯不過。多平臺(tái)支持，一般都是在代碼中加上很多編譯開關(guān)，在編譯期間去分隔Linux，Windows或者其他平臺(tái)下面的特殊代碼。比如utime.h頭文件的包含問題。因?yàn)槲募?Linux（gcc）下面和Windows（cl）下所處的C Library目錄不同。包含的處理辦法就不一樣?？赡苄枰@樣寫才能完全正確的包含。
#if HAVE_UTIME_H?????????????????? ---- 如果有utime.h 文件
#????ifdef WIN32????????????????????-----如果是win32環(huán)境????
#????????include <sys/utime.h>????-----包含sys/utime.h
#????endif
#????ifdef LINUX????????????????????---- 如果是Linux環(huán)境
#????????include <utime.h>????????---- 包含utime.h????
#????endif
#else????????????????????????????--- 如果沒有utime.h定義出需要的結(jié)構(gòu)????
struct utimbuf
??{
????long actime;
????long modtime;
??};
#endif
???? 在其他的代碼中基本上也是這樣的處理。根據(jù)編譯環(huán)境的不同來編譯不同的代碼。這樣的define的區(qū)隔，主要就是為了區(qū)隔不同平臺(tái)的不同細(xì)微區(qū)別。有的區(qū)別也許是某些常量沒有定義，有些區(qū)別是某些函數(shù)不存在。如果代碼中調(diào)用函數(shù)在某些平臺(tái)下面不存在，就需要提供一個(gè)lib去提供這些函數(shù)。Tar的Lib的作用也是如此。
??
基本上代碼的移植是前難后易。前期首先要保證源代碼本身的邏輯不能變動(dòng)，所以在修改代碼方面只能盡量修改外圍的代碼，而不是修改源代碼本身。如果link過了之后，則就是一般的Windows 下面的編程了，可以根據(jù)需求任意修改移植后的代碼了。最難的地方可能就是OS級不同概念的替換了。C Library雖然在各個(gè)平臺(tái)上有不同之處，但是總是比較接近，不同的地方可以提供自己編寫的代碼來替換。但是OS級的概念，和平臺(tái)相關(guān)性太大，一般不太容易替換。
六：擴(kuò)展問題，待解決的問題
???? 如果需要把移植過來的代碼改成DLL或者lib給其他的工程調(diào)用。比如給其他的工程提供一個(gè)解包Tar文件的功能。如果不加修改，那么移植過來的代碼有很多缺陷。
首先是多線程支持問題。如果代碼中有很多全局變量，那么改成DLL或者lib之后就不能在多線程下面調(diào)用。
其次，DLL接口表。移植后的代碼入口是main函數(shù)，雖然整個(gè)工程里面有很多獨(dú)立功能，但是這些獨(dú)立功能的調(diào)用都是通過使用不同的參數(shù)來實(shí)現(xiàn)。如何輸出接口表給其他工程使用，需要做些功夫。
三?？刂?。原始的控制臺(tái)程序在下了運(yùn)行參數(shù)之后，一般都是一頭運(yùn)行到底的，也有可能在中間有些要求輸入某些信息的。這樣的程序如何集成到其他的工程中并受到其他工程的控制？比如遇到某些錯(cuò)誤要返回等等。在Tar代碼中遇到錯(cuò)誤就直接退出程序。顯然這些地方就不合DLL設(shè)計(jì)要求。可能需要重新設(shè)計(jì)代碼的結(jié)構(gòu)。
四，輸出信息。Tar工程里面很多向控制臺(tái)輸出的信息。這些信息輸出需要重新定向或者屏蔽。
第三第四部分可以參考Linux下面的FrontEnd程序，即只是為某個(gè)特殊的程序提供的一個(gè)GUI界面的程序。FrontEnd程序就是控制了主程序的運(yùn)行并重新定向輸出信息到GUI界面上。
??
注1.????Cygwin，是Windows平臺(tái)下面的一個(gè)Linux模擬環(huán)境?？梢詮膚ww.Cygwin.com上下載全部內(nèi)容。
注2.????Windows Services for UNIX （SFU）的SDK可以從微軟網(wǎng)站上獲得 http://www.microsoft.com/windows/sfu/
注3.????UNIX Application Migration Guide 可以從MSDN中取得，如果沒有MSDN可以從微軟MSDN網(wǎng)站上取得。 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/ucmglp.asp
注4.????Tar, Cygwin下面有Tar。但是只能在Cygwin下面運(yùn)行 或者必須提供Cygwin的平臺(tái)DLL才能在windows下面單獨(dú)使用Tar程序。
注5.????CL是微軟的C/C++編譯器，包含在Visual Studio各個(gè)版本中
本文于2003年完成. 如需要轉(zhuǎn)載 請聯(lián)系jackforce@163.com,如果有看到部分干擾信息.請?jiān)?主要避免轉(zhuǎn)載過程中作者信息丟失用.不得以為之,請各位原諒.
PS :
用一個(gè)例子簡單說明了從linux平臺(tái)移植到windows平臺(tái)上的一些需要注意的問題和解決方法.
例子僅用來說明移植過程產(chǎn)生的問題用.
正文完