一．前言

Linux擁有豐富各種源代碼資源,但是大部分代碼在Windows平臺(tái)情況是無(wú)法正常編譯的。Windows平臺(tái)根本無(wú)法直接利用這些源代碼資源。如果想要使用完整的代碼，就要做移植工作。因?yàn)镃/C++ Library的不同和其他的一些原因，移植C/C++代碼是一項(xiàng)困難的工作。本文將以一個(gè)實(shí)際的例子（Tar）來(lái)說(shuō)明如何把Linux代碼移植到Windows平臺(tái)上。移植過(guò)程將盡量少修改代碼,以便代碼的運(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等開(kāi)發(fā)工具。 同樣也需要一個(gè)Windows開(kāi)發(fā)環(huán)境。可以使用最新版本Visual Studio, Microsoft Visual Studio .NET 2003。從www.gnu.org上取得Tar的最新源代碼，版本是1.13。在Cygwin下面解開(kāi)tar-1.13.tar.gz.源代碼包。注意請(qǐng)不要在Windows下面使用WINRAR或者WINZIP來(lái)解壓縮。 WINRAR和WINZIP在解壓縮某些tar.gz包的時(shí)候會(huì)有問(wèn)題。使得解包之后的目錄和文件出現(xiàn)異常。如果是源代碼包將有可能不能在Cygwin下面正確編譯。解開(kāi)壓縮包之后，進(jìn)入 tar-1.13目錄，在當(dāng)前的目錄下面輸入

./configure

命令，運(yùn)行完畢之后，再次輸入

make

命令。開(kāi)始編譯tar的Cygwin版本。

編譯基本上不會(huì)有問(wèn)題，進(jìn)入src目錄，可以看到新編譯好的Tar程序tar.exe。

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

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

接下來(lái)就是構(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)備工作基本上完成了，接著就是移植。移植過(guò)程可以分為3個(gè)部分。

三．第一個(gè)目標(biāo)：使得WinTar能編譯過(guò)（Compiler）

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

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

#define HAVE_MALLOC_H 1表示可以在工程中使用Malloc.h頭文件。通過(guò)調(diào)整這些定義值，可以去除一些Windows平臺(tái)下面沒(méi)有的頭文件包含。也許其他地方還有很多頭文件包含關(guān)系需要處理，但是這里的定義基本上解決了大部分的頭文件包含問(wè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ù)類(lèi)型的定義，可能在linux下面會(huì)有很多特殊的數(shù)據(jù)類(lèi)型定義，Config.h文件中也包含了一部分可以變動(dòng)的數(shù)據(jù)類(lèi)型定義項(xiàng)。這些定義一般都是基本數(shù)據(jù)類(lèi)型的重定義。可以根據(jù)Windows平臺(tái)下的數(shù)據(jù)類(lèi)型定義情況進(jìn)行修補(bǔ)。比如在Cygwin的開(kāi)發(fā)環(huán)境中有個(gè)數(shù)據(jù)類(lèi)型mode_t， Visual Studio的C Library中卻(作者 很土,聯(lián)系方法 jackforce at 163 dot com)找不到這樣數(shù)據(jù)類(lèi)型。Tar代碼中使用了大量的mode_t數(shù)據(jù)類(lèi)型. config.h中提供了修改項(xiàng)來(lái)讓開(kāi)發(fā)人員自己修改mode_t的定義，并提示如果mode_t在<sys/types.h>中沒(méi)有定義的話(huà)，可以把他定義為int型。所以在config.h加上#define mode_t int。這樣mode_t沒(méi)有定義的問(wèn)題就解決了。其他的數(shù)據(jù)類(lèi)型也是同樣對(duì)待處理。

* 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ù)定義開(kāi)關(guān)。#define HAVE_MEMSET 1 表示工程中可以使用memset函數(shù)。也就是說(shuō)工程用到的類(lèi)庫(kù)中已經(jīng)實(shí)現(xiàn)了這個(gè)函數(shù)。如果沒(méi)有，那么就需要＃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ù)類(lèi)型編譯選項(xiàng)之外，還有其他一些東西，比如環(huán)境變量，其他編譯選項(xiàng)。這些內(nèi)容會(huì)根據(jù)不同的項(xiàng)目而有很大的不同。但是可以從Config.h基本看出移植的工作量有多大。

經(jīng)過(guò)上面的調(diào)整之后，勢(shì)必(作者很土,其他文章 請(qǐng)查看vchelp很土專(zhuān)欄)因?yàn)閃indows環(huán)境下沒(méi)有某些頭文件，比如poll.h,就會(huì)沒(méi)有poll函數(shù)，沒(méi)有dirent.h 就會(huì)沒(méi)有dirent 結(jié)構(gòu)體。而繼續(xù)使得WinTar編譯不過(guò)。這個(gè)時(shí)候就需要根據(jù)具體的編譯錯(cuò)誤信息進(jìn)行細(xì)節(jié)修飾。當(dāng)需要使用Windows下一些特殊的定義的時(shí)候請(qǐng)不要忘了在Config.h的最前面加入#include <Windows.h>. 關(guān)于細(xì)節(jié)修飾，舉個(gè)例子來(lái)說(shuō)明。比如有個(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

通過(guò)分析代碼可以發(fā)現(xiàn)，代碼并不是需要一個(gè)完整的inttypes.h文件，而是為了一個(gè)uintmax_t的定義。在Visual Stdio的C Library中并沒(méi)有inttypes.h這個(gè)文件，也沒(méi)有uintmax_t這個(gè)定義。回溯Cygwin的include目錄的inttypes.h文件，發(fā)現(xiàn)了uintmax_t的定義

typedef unsigned long long uintmax_t;

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

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

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

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

完成了第一個(gè)目標(biāo)之后，就會(huì)有大量的link錯(cuò)誤。原因是前面引入了很多外部函數(shù)，外部全局常量只有定義而沒(méi)有實(shí)體，于是就會(huì)產(chǎn)生link錯(cuò)誤。現(xiàn)在需要的是為代碼提供引入的函數(shù)實(shí)體，外部全局變量實(shí)體。一般都是函數(shù)link(本文于2003年完成. 如需要轉(zhuǎn)載 請(qǐng)聯(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ù)的說(shuō)明，有些函數(shù)提供了信息說(shuō)明可以用Windows Library中那些函數(shù)來(lái)替代。這點(diǎn)對(duì)于移植是很重要的（省事）。UNIX Application Migration Guide應(yīng)該不算文章而是有點(diǎn)像書(shū)了。它說(shuō)明了很多windows和Unix系統(tǒng)（類(lèi)Unix系統(tǒng)）中很多概念不同之處，針對(duì)這些不同的概念提供了很多相關(guān)的信息來(lái)說(shuō)明如何進(jìn)行模擬這些不同之處。比如Unix系統(tǒng)中Signals概念可以使用Windows環(huán)境中的Event來(lái)替代。SIGALRM用Windows Message來(lái)替代等。

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

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

四：代碼運(yùn)行正常

實(shí)際上當(dāng)link問(wèn)題解決之后，程序可以在windows環(huán)境中運(yùn)行時(shí)，一切就盡在掌握了。如果不考慮做多平臺(tái)的程序的話(huà)，這個(gè)時(shí)候就可以任意去修改程序了。不過(guò)在代碼調(diào)試過(guò)程可能需要一個(gè)參照，看看正常的程序運(yùn)行流程是怎么樣的。剛剛移植過(guò)來(lái)的程序在很多地方并不能馬上就能正常的運(yùn)行。回到Cygwin中,重新編譯一個(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界面以方便用戶(hù)調(diào)試程序，不過(guò)Insight最終還是調(diào)用GDB。在這里具體調(diào)試就不細(xì)說(shuō)明了。

五：多平臺(tái)代碼

移植后的代碼(本文于2003年完成. 如需要轉(zhuǎn)載 請(qǐng)聯(lián)系[email protected])如果需要在多個(gè)平臺(tái)上面運(yùn)行，就要在lib目錄里面大做文章了。提供自己的函數(shù)庫(kù)，并根據(jù)各個(gè)平臺(tái)進(jìn)行調(diào)整。Tar的代碼由Config.h和一些編譯選項(xiàng)來(lái)控制如何在各個(gè)不同的平臺(tái)上面做編譯。Lib則提供了很多C Library函數(shù)或者不同平臺(tái)下面的其他函數(shù)的替代版本。這樣Tar在編譯過(guò)程中就不會(huì)因?yàn)槟承┢脚_(tái)下某些函數(shù)的缺失而編譯不過(guò)。多平臺(tái)支持，一般都是在代碼中加上很多編譯開(kāi)關(guān)，在編譯期間去分隔Linux，Windows或者其他平臺(tái)下面的特殊代碼。比如utime.h頭文件的包含問(wèn)題。因?yàn)槲募贚inux（gcc）下面和Windows（cl）下所處的C Library目錄不同。包含的處理辦法就不一樣。可能需要這樣寫(xiě)才能完全正確的包含。

#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;--- 如果沒(méi)有utime.h定義出需要的結(jié)構(gòu) struct utimbuf{long actime;long modtime;};#endif

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

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

六：擴(kuò)展問(wèn)題，待解決的問(wèn)題

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

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

其次，DLL接口表。移植后的代碼入口是main函數(shù)，雖然整個(gè)工程里面有很多獨(dú)立功能，但是這些獨(dú)立功能的調(diào)用都是通過(guò)使用不同的參數(shù)來(lái)實(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)境。可以從www.Cygwin.com上下載全部?jī)?nèi)容。

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

注3. UNIX Application Migration Guide 可以從MSDN中取得，如果沒(méi)有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)載 請(qǐng)聯(lián)系[email protected],如果有看到部分干擾信息.請(qǐng)?jiān)?主要避免轉(zhuǎn)載過(guò)程中作者信息丟失用.不得以為之,請(qǐng)各位原諒.

PS :

用一個(gè)例子簡(jiǎn)單說(shuō)明了從linux平臺(tái)移植到windows平臺(tái)上的一些需要注意的問(wèn)題和解決方法.

例子僅用來(lái)說(shuō)明移植過(guò)程產(chǎn)生的問(wèn)題用.