一．前言

　　Linux擁有豐富各種源代碼資源,但是大部分代碼在Windows平臺情況是無法正常編譯的。Windows平臺根本無法直接利用這些源代碼資源。如果想要使用完整的代碼，就要做移植工作。因為C/C++ Library的不同和其他的一些原因，移植C/C++代碼是一項困難的工作。本文將以一個實際的例子（Tar）來說明如何把Linux代碼移植到Windows平臺上。移植過程將盡量少修改代碼,以便代碼的運行邏輯不會發(fā)生任何變動。保留絕大部分軟件主要功能。

　　二．準備工作

　　Tar是Linux平臺下面一個打包工具。移植這樣一個程序到windows平臺需要做那些工作呢？

　　首先是一些準備工作，在Windows平臺上面安裝上Cygwin的最新版本，在Cygwin中安裝好GCC等開發(fā)工具。 同樣也需要一個Windows開發(fā)環(huán)境。可以使用最新版本Visual 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包的時候會有問題。使得解包之后的目錄和文件出現(xiàn)異常。如果是源代碼包將有可能不能在Cygwin下面正確編譯。解開壓縮包之后，進入 tar-1.13目錄，在當前的目錄下面輸入

./configure

　　命令，運行完畢之后，再次輸入

make

　　命令。開始編譯tar的Cygwin版本。

　　編譯基本上不會有問題，進入src目錄，可以看到新編譯好的Tar程序tar.exe。

　　Cygwin是一個API層的Linux模擬環(huán)境。如果能夠在Cygwin下面編譯，運行。實際上也就是能在Windows下面編譯和運行，只是需要有一層中間API模擬某些Linux特有的操作。簡單的判斷一個Linux程序能不能移植到Windows平臺下面，就是看是否能在Cygwin下面編譯源代碼，并運行程序。

　　在Cygwin中編譯Tar的源代碼，判斷能否移植只是其中一個原因。另外一個原因是移植代碼過程中需要一個特殊的頭文件config.h。config.h是移植過程中最重要的源代碼文件。Config.h文件并不是源代碼本身的一部分。文件是在Cygwin下面運行”./configure”命令時生成的。在Cygwin下運行”./Configure”命令時，會根據Cygwin平臺開發(fā)環(huán)境生成config.h文件。編譯時也需要config.h文件對代碼編譯項進行控制。移植工作也以config.h文件為基礎。

　　接下來就是構造Windows工程。先用Visual Studio .NET 2003創(chuàng)建一個空的工程（Project），命名為WinTar。根據Cygwin中的編譯輸出信息，Tar主要的代碼在Src和lib兩個目錄中。把這兩個目錄復制到新工程里，并把代碼加入到工程中。然后復制Config.h到WinTar工程目錄下面。

　　準備工作基本上完成了，接著就是移植。移植過程可以分為3個部分。

　　三．第一個目標：使得WinTar能編譯過（Compiler）

　　第一個目標的完成主要圍繞Config.h來實現(xiàn)。Linux下開發(fā)環(huán)境和Windows開發(fā)環(huán)境很大的不同是C Library頭文件和各種類型的定義不同。而Config.h提供了完整編譯開關來處理因為不同平臺間開發(fā)環(huán)境不同帶來的不同之處。現(xiàn)在需要手工去修改這個文件，以便Tar源代碼能適應Windows平臺。

　　首先調整各種C Library頭文件（Header File）的包含問題。在Config.h中定義了很多類似HAVE_XXXX_H。比如定義HAVE_CONFIG_H為1表示工程中可以使用config.h。

　　#define HAVE_MALLOC_H 1表示可以在工程中使用Malloc.h頭文件。通過調整這些定義值，可以去除一些Windows平臺下面沒有的頭文件包含。也許其他地方還有很多頭文件包含關系需要處理，但是這里的定義基本上解決了大部分的頭文件包含問題。

/* 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 */

　　第二步，調整各種數(shù)據類型的定義，可能在linux下面會有很多特殊的數(shù)據類型定義，Config.h文件中也包含了一部分可以變動的數(shù)據類型定義項。這些定義一般都是基本數(shù)據類型的重定義。可以根據Windows平臺下的數(shù)據類型定義情況進行修補。比如在Cygwin的開發(fā)環(huán)境中有個數(shù)據類型mode_t， Visual Studio的C Library中卻(作者 很土,聯(lián)系方法 jackforce at 163 dot com)找不到這樣數(shù)據類型。Tar代碼中使用了大量的mode_t數(shù)據類型. config.h中提供了修改項來讓開發(fā)人員自己修改mode_t的定義，并提示如果mode_t在<sys/types.h>中沒有定義的話，可以把他定義為int型。所以在config.h加上#define mode_t int。這樣mode_t沒有定義的問題就解決了。其他的數(shù)據類型也是同樣對待處理。

* 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

　　第三步，調整各種函數(shù)定義。在Config.h中除了HAVE_XXXXX_H之外還有一種預定義，HAVE_XXXX。 這是一些可選用函數(shù)定義開關。#define HAVE_MEMSET 1 表示工程中可以使用memset函數(shù)。也就是說工程用到的類庫中已經實現(xiàn)了這個函數(shù)。如果沒有，那么就需要＃undef HAVE_MEMSET，當然也可以自己提供這些函數(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ù)據類型編譯選項之外，還有其他一些東西，比如環(huán)境變量，其他編譯選項。這些內容會根據不同的項目而有很大的不同。但是可以從Config.h基本看出移植的工作量有多大。

　　經過上面的調整之后，勢必(作者很土,其他文章 請查看vchelp很土專欄)因為Windows環(huán)境下沒有某些頭文件，比如poll.h,就會沒有poll函數(shù)，沒有dirent.h 就會沒有dirent 結構體。而繼續(xù)使得WinTar編譯不過。這個時候就需要根據具體的編譯錯誤信息進行細節(jié)修飾。當需要使用Windows下一些特殊的定義的時候請不要忘了在Config.h的最前面加入#include <Windows.h>.
關于細節(jié)修飾，舉個例子來說明。比如有個選項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)，代碼并不是需要一個完整的inttypes.h文件，而是為了一個uintmax_t的定義。在Visual Stdio的C Library中并沒有inttypes.h這個文件，也沒有uintmax_t這個定義。回溯Cygwin的include目錄的inttypes.h文件，發(fā)現(xiàn)了uintmax_t的定義

typedef unsigned long long uintmax_t;

　　很簡單的數(shù)據類型重定義。這么簡單定義，完全可以從Cygwin的Include目錄中單獨拿出來做一個專用版本的inttypes.h加入到WinTar項目中。這樣編譯過程中uintmax_t沒有定義的問題就解決了。解決這類問題的一般的做法也就是從Cygwin的Include目錄里面拿出相關的頭文件進行修改或者單獨復制到WinTar的目錄下面。[本文于2003年完成. 如需要轉載 請聯(lián)系jackforce at 163 dot com ]修改或者復制代碼的原則是不再引入更多的定義或者頭文件,僅取所需部分。其他類似的問題還有direct結構定義和相關函數(shù)。

　　在編譯過程中,很多錯誤是有由lib目錄下的文件產生的,但是lib目錄下的文件不是完全都需要的。lib目錄只是一個對Tar的補充庫。需要的代碼才需要編譯。 具體判斷的方法一個是參考Windows C Library庫的內容。如果同樣的函數(shù),數(shù)據類型已經定義,就不需要Lib目錄中的相同數(shù)據類型的定義和函數(shù)實現(xiàn)了。還有一個方法是盡量去掉lib目錄中的C文件,只保留頭文件,并使得編譯能夠通過,根據link的錯誤信息去檢查那些lib中的C文件是需要的。

　　除了修改外圍的各種頭文件之外，還不要忘了修改工程的編譯選項，特別是預定義選項。在Tar的移植過程就需要以下的預定義HAVE_CONFIG_H，_POSIX_SOURCE，MSDOS。HAVE_CONFIG_H 表示程序編譯需要config.h文件。為了方便期間，在tar移植過程中就放到工程的預編譯選項中了。MSDOS，移植的是Linux下的控制臺程序，而Windows平臺最接近Linux控制臺就是DOS，特別是一些環(huán)境變量設置和全局常量的定義。Tar的有些代碼針對MSDOS環(huán)境已經做了一部分修正,這點在移植過程中可以利用起來。還有一個可選項是__CYGWIN__。有些Linux程序會針對Cygwin平臺做出代碼上的特殊設定。當遇到這樣的代碼的時候，一定要加上__CYGWIN__預定義項，能夠大大減少移植需要的工作量。還有就是移植過程引入的各種Cygwin代碼中也可能需要__CYGWIN__定義（有時候是其他的定義，比如_POSIX_SOURCE，或者__INSIDE_CYGWIN__）。

　　經過上述的幾個步驟。第一個目標，代碼能夠編譯通過基本上是不會有什么問題的。只要把握好二個修改代碼的基本原則，第一。引入新的代碼，而不修改原有的代碼。在沒有辦法進行調試前修改源代碼是不允許的，修改的不好就會引起最后代碼運行邏輯的混亂，而且在代碼能夠運行之前是很難發(fā)現(xiàn)問題的。所以除非非常有把握，否則不要修改被移植工程的源代碼。第二，引入新的代碼之后，不能因為這次引入而需要再次引入新的代碼。這樣子，就進入死循環(huán)了。為了解決某個數(shù)據類型的定義，而引入了新的不能解釋的數(shù)據類型。這樣還不如不引入新的代碼。所以引入新的代碼，特別是很多頭文件。引入之前一定要做修改，只保留工程本身需要的部分，去除那些不需要的代碼。直到能編譯通過為止。 三：第二個目標，使得代碼能夠鏈接過（Link）

　　完成了第一個目標之后，就會有大量的link錯誤。原因是前面引入了很多外部函數(shù)，外部全局常量只有定義而沒有實體，于是就會產生link錯誤?，F(xiàn)在需要的是為代碼提供引入的函數(shù)實體，外部全局變量實體。一般都是函數(shù)link(本文于2003年完成. 如需要轉載 請聯(lián)系jackforce at 163.com)不到的比較多。

　　要解決link錯誤就需要了解不同平臺上面函數(shù)操作的區(qū)別，特別是某些概念的區(qū)別。這里最好的參考資料有兩個。一個是Windows Services for UNIX （SFU）的幫助文件，一個是MSDN中的一篇文章《UNIX Application Migration Guide》。SFU是微軟提供一個Unix兼容環(huán)境，有點像Cygwin。在安裝上SFU之后有一個幫助文件。其中有一部分就是Unix，Linux函數(shù)的說明，有些函數(shù)提供了信息說明可以用Windows Library中那些函數(shù)來替代。這點對于移植是很重要的（省事）。UNIX Application Migration Guide應該不算文章而是有點像書了。它說明了很多windows和Unix系統(tǒng)（類Unix系統(tǒng)）中很多概念不同之處，針對這些不同的概念提供了很多相關的信息來說明如何進行模擬這些不同之處。比如Unix系統(tǒng)中Signals概念可以使用Windows環(huán)境中的Event來替代。SIGALRM用Windows Message來替代等。

　　SFU的幫助文件提供了一部分信息來說明Windows平臺中哪些低階函數(shù)（C 函數(shù)庫）可以替代相關Unix函數(shù)?！禪NIX Application Migration Guide》則提供了一種方法來轉換Unix平臺上的一些OS級的概念到windows上。實際上Cygwin下面也做了很多這樣的轉換。具體解決link問題的時候可以參考Cygwin本身的實現(xiàn)。

　　不過有些概念，比如安全權限方面的概念。在Linux平臺和windows平臺上面是完全不能互換的。而且windows平臺中的權限函數(shù)操作(本文于2003年完成. 如需要轉載 請聯(lián)系jackforce@163.com)的過于復雜。這樣對于某些linux函數(shù)。比如getuid處理可以參考Cygwin的處理辦法。什么也不做直接返回0 （return 0）。當代碼中遇到這些函數(shù)的時候可以從Cygwin的代碼中復制一個getuid出來。放入工程中去。
利用這些資料，并通過相關的工具比如sourceinsight來搜索Cygwin本身的源代碼，Link問題并不難處理。只是有可能在處理link問題的過程中會回復到上面的問題，編譯不過。這個時候的代碼修改還是一定要注意不要引入太多的新的代碼，免得問題越來越復雜。

　　四：代碼運行正常

　　實際上當link問題解決之后，程序可以在windows環(huán)境中運行時，一切就盡在掌握了。如果不考慮做多平臺的程序的話，這個時候就可以任意去修改程序了。不過在代碼調試過程可能需要一個參照，看看正常的程序運行流程是怎么樣的。剛剛移植過來的程序在很多地方并不能馬上就能正常的運行。回到Cygwin中,重新編譯一個可以調試的版本（在GCC編譯選項加上-g3）,在需要的時候可以在Cygwin中調試程序。調試可以用GDB或者Insight。如果習慣Windows 平臺下面編程，可以使用Insight，這是一個TCL/TK腳本程序，它提供了一個Windows界面以方便用戶調試程序，不過Insight最終還是調用GDB。在這里具體調試就不細說明了。

　　五：多平臺代碼

　　移植后的代碼(本文于2003年完成. 如需要轉載 請聯(lián)系jackforce@163.com)如果需要在多個平臺上面運行，就要在lib目錄里面大做文章了。提供自己的函數(shù)庫，并根據各個平臺進行調整。Tar的代碼由Config.h和一些編譯選項來控制如何在各個不同的平臺上面做編譯。Lib則提供了很多C Library函數(shù)或者不同平臺下面的其他函數(shù)的替代版本。這樣Tar在編譯過程中就不會因為某些平臺下某些函數(shù)的缺失而編譯不過。多平臺支持，一般都是在代碼中加上很多編譯開關，在編譯期間去分隔Linux，Windows或者其他平臺下面的特殊代碼。比如utime.h頭文件的包含問題。因為文件在Linux（gcc）下面和Windows（cl）下所處的C Library目錄不同。包含的處理辦法就不一樣?？赡苄枰@樣寫才能完全正確的包含。

#if HAVE_UTIME_H &#61663;---- 如果有utime.h 文件
# ifdef WIN32 &#61663;-----如果是win32環(huán)境
# include <sys/utime.h> &#61663;-----包含sys/utime.h
# endif
# ifdef LINUX &#61663;---- 如果是Linux環(huán)境
# include <utime.h> &#61663;---- 包含utime.h
# endif
#else &#61663;--- 如果沒有utime.h定義出需要的結構
struct utimbuf
{
long actime;
long modtime;
};
#endif

　　在其他的代碼中基本上也是這樣的處理。根據編譯環(huán)境的不同來編譯不同的代碼。 這樣的define的區(qū)隔，主要就是為了區(qū)隔不同平臺的不同細微區(qū)別。有的區(qū)別也許是某些常量沒有定義，有些區(qū)別是某些函數(shù)不存在。如果代碼中調用函數(shù)在某些平臺下面不存在，就需要提供一個lib去提供這些函數(shù)。Tar的Lib的作用也是如此。

　　基本上代碼的移植是前難后易。前期首先要保證源代碼本身的邏輯不能變動，所以在修改代碼方面只能盡量修改外圍的代碼，而不是修改源代碼本身。如果link過了之后，則就是一般的Windows下面的編程了，可以根據需求任意修改移植后的代碼了。最難的地方可能就是OS級不同概念的替換了。C Library雖然在各個平臺上有不同之處，但是總是比較接近，不同的地方可以提供自己編寫的代碼來替換。但是OS級的概念，和平臺相關性太大，一般不太容易替換。

　　六：擴展問題，待解決的問題

　　如果需要把移植過來的代碼改成DLL或者lib給其他的工程調用。比如給其他的工程提供一個解包Tar文件的功能。如果不加修改，那么移植過來的代碼有很多缺陷。

　　首先是多線程支持問題。如果代碼中有很多全局變量，那么改成DLL或者lib之后就不能在多線程下面調用。

　　其次，DLL接口表。移植后的代碼入口是main函數(shù)，雖然整個工程里面有很多獨立功能，但是這些獨立功能的調用都是通過使用不同的參數(shù)來實現(xiàn)。如何輸出接口表給其他工程使用，需要做些功夫。

　　三、控制 原始的控制臺程序在下了運行參數(shù)之后，一般都是一頭運行到底的，也有可能在中間有些要求輸入某些信息的。這樣的程序如何集成到其他的工程中并受到其他工程的控制？比如遇到某些錯誤要返回等等。在Tar代碼中遇到錯誤就直接退出程序。顯然這些地方就不合DLL設計要求?？赡苄枰匦略O計代碼的結構。

　　四，輸出信息。Tar工程里面很多向控制臺輸出的信息。這些信息輸出需要重新定向或者屏蔽。

　　第三第四部分可以參考Linux下面的FrontEnd程序，即只是為某個特殊的程序提供的一個GUI界面的程序。FrontEnd程序就是控制了主程序的運行并重新定向輸出信息到GUI界面上。

　　注1. Cygwin，是Windows平臺下面的一個Linux模擬環(huán)境。可以從www.Cygwin.com上下載全部內容。

　　注2. Windows Services for UNIX （SFU）的SDK可以從微軟網站上獲得 http://www.microsoft.com/windows/sfu/

　　注3. UNIX Application Migration Guide 可以從MSDN中取得，如果沒有MSDN可以從微軟MSDN網站上取得。 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/ucmglp.asp

　　注4. Tar, Cygwin下面有Tar。但是只能在Cygwin下面運行 或者必須提供Cygwin的平臺DLL才能在windows下面單獨使用Tar程序。
注5. CL是微軟的C/C++編譯器，包含在Visual Studio各個版本中

　　本文于2003年完成. 如需要轉載 請聯(lián)系jackforce@163.com,如果有看到部分干擾信息.請原諒.主要避免轉載過程中作者信息丟失用.不得以為之,請各位原諒.

　　PS :

　　用一個例子簡單說明了從linux平臺移植到windows平臺上的一些需要注意的問題和解決方法.

　　例子僅用來說明移植過程產生的問題用.