Windows和Unix是當(dāng)前兩大主流操作系統(tǒng)平臺，基于C/C++的開發(fā)人員經(jīng)常會面臨這兩個平臺之間的移植的問題。Unix作為一個開發(fā)式的系統(tǒng)，其下有出現(xiàn)了很多個分支，包括Sun的Solaris、IBM的AIX、HP Unix、SCO Unix、Free BSD、蘋果的MAC OS以及開源的Linux等。對于這些Unix的分支操作系統(tǒng)，其實(shí)現(xiàn)又有很大的差別，因此開發(fā)人員又要針對這些不同的系統(tǒng)進(jìn)行移植。本文的目的就是介紹一下Windows平臺和Unix平臺之間的差別，并簡單介紹一下不同Unix分支操作系統(tǒng)之間的差別，在移植開發(fā)過程中的一些注意事項(xiàng)，同時(shí)簡要介紹一下Unix下開發(fā)的一般流程和常用的開發(fā)調(diào)試工具。
關(guān)于平臺之間的差異，主要是Windows平臺和Unix平臺之間的差異，這里著重介紹一下這兩個平臺在C/C++開發(fā)中存在的差異，其間會穿插介紹一些Unix不同分支之間的差異。
語言特性的差異，指的是不同操作系統(tǒng)平臺中，實(shí)現(xiàn)C++/C時(shí)的一些細(xì)微的差異，忽略這些差異可能會帶來一些特別隱蔽的錯誤。而且可能是致命的錯誤。所以，了解語言特性的差異，對于在Unix移植來說非常重要。如果考慮系統(tǒng)多多個平臺支持，就必須了解在不同平臺下語言特性的差異，從開發(fā)一開始就把這些因素考慮進(jìn)去，這樣才能最低限度的降低移植的過程中工作量。
字節(jié)順序指的主要是整型變量在內(nèi)存中的存儲方式。在計(jì)算機(jī)中，數(shù)據(jù)都是以二進(jìn)制方式存儲的，包括在內(nèi)存和硬盤中。而計(jì)算機(jī)又以8位二進(jìn)制作為一個存儲單元。在32位系統(tǒng)中，一個整型的存儲需要四個存儲單元。也就是說要把一個32位的整數(shù)分割成位四段分別進(jìn)行存儲，而每一段的存儲位置就是字節(jié)順序的差異。為了清楚的表示每段存儲的先后位置，我們用16進(jìn)制來表示一段的值，下表列出了在Unix系統(tǒng)和Windows系統(tǒng)中整數(shù)20000在內(nèi)存中的情況。
|
十六進(jìn)制表示 |
0x00004E20 |
|
Windows內(nèi)存表示 |
20 4E 00 00 |
|
Unix內(nèi)存表示 |
00 00 4E 20 |
如表中所示，Windows中存儲方式和該整數(shù)的16進(jìn)制表示是相反，是一種低位在前高位在后的存儲順序。而Unix下的存儲順序和正常的16進(jìn)制表示的順序相同，稱為高位在前低位在后的順序。這種差異帶來的問題，主要體現(xiàn)在以下幾個方面：
? 網(wǎng)絡(luò)通信時(shí)
當(dāng)Windows和Unix之間發(fā)生網(wǎng)絡(luò)數(shù)據(jù)傳輸，傳輸一個整型數(shù)據(jù)（如一個數(shù)據(jù)包的長度）的時(shí)候，如果不經(jīng)處理直接把內(nèi)存中的數(shù)據(jù)傳輸過去，那么在對方看來完全是另一個數(shù)據(jù)，這樣就會造成問題。如Windows下面發(fā)送過去一個20000（0x00004E20），在Unix下面收到的數(shù)據(jù)就會被理解成541982720（0x204E0000），這簡直是天壤之別。
? 文件存儲和讀取時(shí)
跟網(wǎng)絡(luò)傳輸類似，如果在Windows下面把某個整數(shù)寫到了文件中，然后在Unix下面打開這個文件讀取該數(shù)據(jù)，就會出現(xiàn)跟上面類似的問題。
這個問題主要體現(xiàn)在不同平臺之間互操作時(shí)，在多平臺開發(fā)過程中，尤其時(shí)在網(wǎng)絡(luò)應(yīng)用開發(fā)的時(shí)候，兩個平臺之間數(shù)據(jù)交互是非常普遍的，所以這個問題也就顯的很普遍。解決這個問題的方法就是交互的雙方采用一種相同的數(shù)據(jù)編碼標(biāo)準(zhǔn)，就是數(shù)據(jù)在傳輸和存儲的時(shí)候采用什么方法進(jìn)行編碼，具體的做法有一下幾種：
1． 數(shù)字轉(zhuǎn)換成字符傳進(jìn)行交互
2． 協(xié)商一個同意的字節(jié)順序，根據(jù)自己平臺的字節(jié)順序還原數(shù)據(jù)
3． 采用其他標(biāo)準(zhǔn)的編碼方式，如ASN1編碼
跟這個問題類似，32位系統(tǒng)和64位系統(tǒng)的差異也會出現(xiàn)這樣的問題，解決方法跟這個問題的解決方法相同。在32位系統(tǒng)和64位系統(tǒng)中，長整型（long）分別用32位和64位表示，這樣，在不同系統(tǒng)之間交互的時(shí)候必然會出現(xiàn)整型數(shù)據(jù)表示方式不同的問題。目前大多數(shù)Windows系統(tǒng)都是32位的系統(tǒng)，而Unix中很多都是64位的，尤其是大型的服務(wù)器，所以這個問題必須引起重視。
在不同的系統(tǒng)下，由于編譯器的不同，對變量作用域的實(shí)現(xiàn)機(jī)制也有所不同，這里以Windows下的VC和Solaris下的CC這兩個編譯器為例做一個簡單的比較說明。
在C++的開發(fā)過程中，我們經(jīng)常會有這樣的用法：
for(int i=0;i<num;i++)
{
…
}
這是一種最常用的for循環(huán)的用法，因?yàn)槠渲衖主要使用來控制循環(huán)，所以一般沒有必要拿出來單獨(dú)進(jìn)行聲明，只是放在for語句中一起聲明。這里i、j等簡單的變量就成了我們常用的變量，一般不按照編程規(guī)范那樣為他們命名。就是這種聲明方法，在Windows下和Solaris下有了不同的理解，i的作用域不同。我們先把作用域進(jìn)行劃分，如下：
{
…
for(int i=0;i<num;i++)
|
II |
|
I |
}
…
…
}
我們劃分出I和II兩個作用域，其中作用域II包含在作用域I當(dāng)中。在Windows下，變量i的作用域是I的整個范圍，而Solaris下的i的作用域只是II的范圍。其實(shí)標(biāo)準(zhǔn)的C++語法應(yīng)該是Solaris的做法，但是微軟在實(shí)現(xiàn)的時(shí)候沒有按照這個標(biāo)準(zhǔn)實(shí)現(xiàn)，這就引發(fā)了我們討論的這個問題。由于這個差異，就引發(fā)了一些微妙而隱蔽的問題。先看一下下面兩端代碼。
A：
for(int i=0;i<num;i++)
{
…
}
…
for(i=0;i<num;i++)
{
…
}
B：
for(int i=0;i<num;i++)
{
…
}
…
for(int i=0;i<num;i++)
{
…
}
代碼A在Windows下面可以正常編譯，而在Solaris下面確編不過去，提示第二個for循環(huán)中變量i沒有定義。相反代碼B在Solaris下可以正常編譯，而在Windows下面編不過去，提示第二個for循環(huán)中變量i重復(fù)定義。
在通常的情況下，我們會按照B的方法書寫代碼，而在Windows編譯是出現(xiàn)錯誤，然后改成A的那種形式。這樣，在Windows下就沒有問題了，程序也可以編譯過去了，但是到Solaris下時(shí)，有會出現(xiàn)問題，這是就不得不把i的聲明拿到所有for循環(huán)的外面。當(dāng)i的聲明拿到for循環(huán)的外面時(shí)，真正的問題來了。首先提示一下，這樣的一段代碼是沒有問題的：
C：
int i = 0;
if(cond)
{
…
for(int i=0;i<num;i++)
{
…
}
…
}
這是一段正確的代碼，雖然在外面已經(jīng)定義了i，但是在for里面重新定義一個i也沒有問題，這是C++的語法所允許的（java里面不允許這樣做）。但就是因?yàn)檫@種C++語言的靈活機(jī)制，引發(fā)了問題的產(chǎn)生。
問題產(chǎn)生源于程序中出現(xiàn)了A_B那樣的代碼，然后把i的聲明拿到了外面。在后期維護(hù)的過程中，又在后面增加了一個循環(huán)，但是卻是按照C的那種方式增加的，這樣就產(chǎn)生了問題。請看如下代碼：
int i=0;
char str1[10];
char str2[10];
strcpy(str1,”hello”);
…
for(i=0;i<20;i++)
{
…
|
I |
…
if(cond)
{
for(int i=0;i<10;i++)
|
III |
|
II |
}
memcpy(str2,str1,i);
str2[i]=0;
}
…
在上述代碼，為了分析方便，我們把整段代碼分成I、II和III三個作用域。其中作用域II就是整個if語句，實(shí)現(xiàn)的相當(dāng)于一個strcpy函數(shù)的功能。II中的內(nèi)容就好是我們上面說的后期維護(hù)中加入的，當(dāng)然，實(shí)際情況并不像我們例子中這么明前，i的聲明可能離我們的if語句很遠(yuǎn)，所以加入這段代碼是不知道上面是否聲明了i變量。而且，這段代碼編譯的時(shí)候也不回出錯，不管是Windows還是Solaris（單獨(dú)的一段II中的代碼在Solaris下面編不過去）。在Windows下面，這段代碼可以正常的運(yùn)行，不回出現(xiàn)任何問題，因?yàn)镮I中的代碼完全是根據(jù)Windows下的習(xí)慣編寫的。但是在Solaris下面，這段代碼就會出現(xiàn)內(nèi)存越界的錯誤，雖然編譯可以正常通過，但是實(shí)現(xiàn)的卻不是程序員預(yù)期的目的。在執(zhí)行memcpy的時(shí)候，那個i其實(shí)是外層聲明的那個i，值是20，而str2和str1的大小之后10，所以就發(fā)生了讀寫內(nèi)存越界。而程序員預(yù)想的，這個i是for循環(huán)算出來的str1字符串的長度，應(yīng)該是5。
要解決這類問題，就得加強(qiáng)編程規(guī)范，杜絕這種錯誤代碼的生成。從開始的時(shí)候就要意識到可能產(chǎn)生的問題，從而避免問題的發(fā)生。