久久久久久狠狠丁香,国产麻豆精品久久一二三,午夜肉伦伦影院久久精品免费看国产一区二区三区

Linux代碼移植到Windows的簡(jiǎn)單方法(轉(zhuǎn))

Linux代碼移植到Windows的簡(jiǎn)單方法(轉(zhuǎn))

一．前言

　　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)境。可以使用最新版本Visual Studio, Microsoft Visual Studio .NET 2003。從 www.gnu.org 上取得Tar的最新源代碼，版本是1.13。在Cygwin下面解開tar-1.13.tar.gz.源代碼包。注意請(qǐng)不要在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特有的操作。簡(jiǎn)單的判斷一個(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文件對(duì)代碼編譯項(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)境不同帶來的不同之處。現(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 header file. */

　　/* #undef HAVE_LINUX_FD_H */　　

　　/* Define if you have the header file. */

　　#define HAVE_LOCALE_H 1　　

　　/* Define if you have the header file. */

　　#define HAVE_MALLOC_H 1　　

　　/* Define if you have the header file. */

　　#define HAVE_MEMORY_H 1　　

　　/* Define if you have the 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在中沒有定義的話，可以把他定義為int型。所以在config.h加上#define mode_t int。這樣mode_t沒有定義的問題就解決了。其他的數(shù)據(jù)類型也是同樣對(duì)待處理。

　　* Define to `int' if doesn't define. */

　　#define mode_t int 　　

　　/* Define to `long' if doesn't define. */

　　/* #undef off_t */　　

　　/* Define to `int' if 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)整之后，勢(shì)必(作者很土,其他文章請(qǐng)查看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í)候請(qǐng)不要忘了在Config.h的最前面加入#include .

　　關(guān)于細(xì)節(jié)修飾，舉個(gè)例子來說明。比如有個(gè)選項(xiàng)HAVE_INTTYPES_H　　

　　/* Define if exists, doesn't clash with ,

　　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è)定義。回溯Cygwin的include目錄的inttypes.h文件，發(fā)現(xiàn)了uintmax_t的定義　　

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

　　在編譯過程中,很多錯(cuò)誤是有由lib目錄下的文件產(chǎn)生的,但是lib目錄下的文件不是完全都需要的。lib目錄只是一個(gè)對(duì)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的有些代碼針對(duì)MSDOS環(huán)境已經(jīng)做了一部分修正,這點(diǎn)在移植過程中可以利用起來。還有一個(gè)可選項(xiàng)是__CYGWIN__。有些Linux程序會(huì)針對(duì)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ò)誤。現(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ù)的說明，有些函數(shù)提供了信息說明可以用Windows Library中那些函數(shù)來替代。這點(diǎn)對(duì)于移植是很重要的（省事）。UNIX Application Migration Guide應(yīng)該不算文章而是有點(diǎn)像書了。它說明了很多windows和Unix系統(tǒng)（類Unix系統(tǒng)）中很多概念不同之處，針對(duì)這些不同的概念提供了很多相關(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ù)。《UNIX Application Migration Guide》則提供了一種方法來轉(zhuǎn)換Unix平臺(tái)上的一些OS級(jí)的概念到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)載請(qǐng)聯(lián)系 jackforce@163.com )的過于復(fù)雜。這樣對(duì)于某些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)行。回到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界面以方便用戶調(diào)試程序，不過Insight最終還是調(diào)用GDB。在這里具體調(diào)試就不細(xì)說明了。

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

　　移植后的代碼(本文于2003年完成. 如需要轉(zhuǎn)載請(qǐng)聯(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)槲募贚inux（gcc）下面和Windows（cl）下所處的C Library目錄不同。包含的處理辦法就不一樣。可能需要這樣寫才能完全正確的包含。　　

　　#if HAVE_UTIME_H ?---- 如果有utime.h 文件

　　# ifdef WIN32 ?-----如果是win32環(huán)境

　　# include ?-----包含sys/utime.h

　　# endif

　　# ifdef LINUX ?---- 如果是Linux環(huán)境

　　# include ?---- 包含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級(jí)不同概念的替換了。C Library雖然在各個(gè)平臺(tái)上有不同之處，但是總是比較接近，不同的地方可以提供自己編寫的代碼來替換。但是OS級(jí)的概念，和平臺(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)境。可以從 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中取得，如果沒有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)系 jackforce@163.com ,如果有看到部分干擾信息.請(qǐng)?jiān)?主要避免轉(zhuǎn)載過程中作者信息丟失用.不得以為之,請(qǐng)各位原諒.

　　PS :

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

　　例子僅用來說明移植過程產(chǎn)生的問題用

posted on 2007-01-18 12:03 小不懂^_^ 閱讀(672) 評(píng)論(0) 編輯收藏引用

只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
【推薦】100%開源！大型工業(yè)跨平臺(tái)軟件C++源碼提供，建模，組態(tài)！



網(wǎng)站導(dǎo)航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

C++樂園

公告

常用鏈接

留言簿(4)

隨筆分類(1)

隨筆檔案(12)

文章分類(9)

文章檔案(18)

相冊(cè)

學(xué)習(xí)的客

最新隨筆

搜索

積分與排名

最新隨筆

最新評(píng)論

閱讀排行榜

評(píng)論排行榜