（四）移植問題

下面講一下我們的windows專案的可移植性問題。總共從三個方面來講這個問題。

（一）：unicode編碼

wchar_t型別在unix（4位元組）和windows（2個位元組）中有不同的標準大小。你需要乙個較新版本的gcc(2.9.7或者是更新)來支援-fshort-wchar選項來設定wchar_t的大小。

如果你正在使用unicode編碼，並且你想要能夠使用標準的庫函式呼叫，你一定要使用msvcrt執行庫而不是glibc。在glibc中的函式對16位的字串不能很好的執行。

（二）：c庫

對於使用哪乙個c庫你現在有兩個選擇：本地glibc庫和msvcrt c庫。

注意在wine下，crtdll庫是使用msvcrt來實現的，所以，嘗試使用它是沒有好處的。

使用glibc一般具有最低開銷，但是這僅僅對i/o是非常重要的，因為在msvcrt中的一些函式就是簡單的解析成了glibc。

為了使用glibc，你不必對你的應用去做改變；他應該是直接可以工作的。下面有幾個情況使用gibc是不可能的:

你的應用使用win32和c庫的unicode函式

你的應用使用ms專門的呼叫例如beginthread(),loadlibrary()等等

你依賴於呼叫的精確語義，例如，返回-1而不是非0.更有可能的是，你的應用依賴於呼叫像fopen()採用windows路徑而不是unix路徑的函式。

在這些情況下，你應該使用msvcrt來提供你的c執行呼叫。

新增乙個 -mno-cygwin到你的編譯器標誌中。這個能夠使得winebuild解決你的c庫呼叫msvcrt.dll。一些簡單的執行效果一樣的呼叫已經從msvcrt中被指定成為非重要性的。在這種情況下，winebuilder講不會處理他們，標準鏈結器ld將會講他們鏈結到glibc中。

為了避免因為沒有原型而導致在c（和在c++中潛在的錯誤）中的警告，你需要使用一系列的ms相容的標頭檔案。這些都是預定的納入到wine中，但是在編寫的時候是不可用的。你可以嘗試使用你需要的原型的函式或者是僅僅在警告中。

@ignore = (fopen,fclose,fwrite,fread,fputs,fgets)

很明顯，完整的列表會更長。記住一些函式在他們的名稱中使用下橫線實現的，有的是在ms標頭檔案中#define巨集定義的。所以你可能需要通過檢查dlls/msvcrt/msvcrt.spec來位你的@ignore元素找到正確的名稱。

（三）：編譯問題

如果你遇到了在windows和wine標頭檔案的不同而中斷了編譯，嘗試詢問[email protected]來尋求幫助。

（四） 移植問題