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