（六） Winelib開發元件2

話接上節！！

（二）：編譯資源檔案：wrc

為了編譯資源，你應該使用wine資源編譯器，簡寫為wrc,該編譯器會生成乙個二進位制.res檔案。當編譯spec檔案的時候，該資源檔案會被winebuild使用。

winemaker生成的makefiles檔案會幫你照料好。但是，如果你要編寫自己的makefile檔案的話，你應該將下面的語句加上：

wrc=$(
wine_dir)/tools/wrc/wrc
winelib_flags=-i
$(wine_dir)/include -dwinelib -d_reentrant
wrcflags = -r -l
.suffixes
: .rc .res
.rc.res:
$(wrc) $(
wrcflags) $(
winelib_flags) -o $@
$<

資源檔案中你可能會遇到兩個問題：

第乙個問題就是c庫標頭檔案問題。wrc不知道這些標頭檔案在**。如果乙個rc檔案，他包含標頭檔案的話，你將會得到乙個」檔案找不到」的錯誤。下面是解決這個問題的一些方法：

但這就會假設你知道這些標頭檔案在**，這會降低你的makefile檔案對其他平台的可移植性。或者是你可以使用c/c++編譯器來執行預處理。為了能夠這樣做，你可以簡單的修改你的makefile檔案如下：

.rc.res:
$(cc) $(
cc_opts) -drc_invoked -e -x c $< | $(
wrc) -n
$(wrcflags) $(
winelib_flags) -o $@

第二個問題就是標頭檔案可能會包含一些arc不能理解的結構。乙個典型的例子就是乙個返回const型別的函式。wrc期望的函式是兩個識別符號後跟乙個左括號。如果帶上const，就有三個識別符號後跟乙個左括號，因此wrc迷惑了（它實際上應該會忽略所有的windows資源編譯器所做的事情）。解決的辦法就是在#ifndef rc_invoked中新增乙個違規語句。

在資源中使用gif檔案是有問題的。最好的結果就是，將他們轉換成bmp檔案或者是改變你的.res檔案。

如果在你的資源檔案中，你使用通用的控制/對話方塊的話，你需要在#include後面新增乙個#include，這樣wrc才能夠明白控制專用標誌的值。

（三）：spec檔案

1：簡介

在windows中，應用和庫包含了一些必要的使api能夠工作的資訊，例如getprocaddress。所以說在unix世界中，為了能夠使winelib應用和庫以同樣的api工作，重複這些資料結構是有必要的。

spec檔案就是為了解決上面描述的語義上的差別的。他提供了從乙個dll提取出來的關於每乙個api的資訊，以使適當的表能夠生成。後期這些資訊被用於儲存日誌。

乙個典型的spec檔案看上去就像下面這樣：

@ stdcall -private
dllcanunloadnow()
@ stdcall -private
dllgetclassobject(ptr ptr ptr)
@ stdcall -private
dllregisterserver()
@ stdcall -private
dllunregisterserver()

2：更多細節

下面是對spec檔案格式更加詳細的描述。

# comment text

在』#』後面的任何資料都被認定為注釋。

ordinal functype options exportname([argtype [argtype [...]]]) handlername
@ stdcall createdesktopw(wstr wstr ptr long long ptr)
@ stdcall cm_get_parent(ptr long long) setupapi.cm_get_parent
@ cdecl -arch=x86_64 ceilf(float) msvcrt_ceilf

這個域可以出現0次或者是多次。每乙個例項定義乙個函式入口點。被exportname([argtype[argtype[…]]])定義的原型指定了用於動態鏈結和引數格式的可用的名稱。ordinal被與之相對應的功能的序號所代替，或者是使用@進行自動的序號分配（僅僅用於win32）。functype應該是下面的乙個：

對於wine32函式word,s_word,segptr和segstr是無效的。handlername是真實的以32位模式處理需求的wine函式的名稱。strings應該一直會對映到str,寬字串會對映到watr。作為乙個常用的規則，他依賴於引數是in,out或者是in/out。

這個是用於除錯資訊的。如果引數是out，他將不會被初始化，因此他也不會作為乙個字串被列印。

為了能夠在win16中使用一定數量的引數來宣告乙個函式，指定函式為無引數。引數將會在current_stack16->args中可用。在win32中，在c檔案中指定函式為varargs或者是以」…」作為引數宣告。可以檢視位於user32.spec檔案中的wsprintf*函式作為乙個例子。

ordinal stub exportname

ordinal extern exportname symbolname

這個域可以出現零次或多次。每乙個例項都定義了乙個對映到乙個wine符號（變數或函式）的條目；exportname將會指向在c**中定義的符號symbolname。這個型別僅僅在win32上工作。

為了成乙個可執行程式，你需要鏈結這些檔案：你的物件檔案，任何你的應用程式依賴的windows庫，例如gdi32，和你使用的其他附加庫。你要鏈結的所有的庫應該是作為.so庫可用的。如何他們僅僅在.dll下是可用的，那麼請想看「構建winelib dlls」這一節。

當你嘗試鏈結你的可執行程式的時候，你才會發現你的當前庫中是否丟失符號。在windows上，幫你構建庫的時候，鏈結器就會立即告訴你乙個符號是否未定義。在unix和winelib中，不是這樣的。符號會被默默的被標註為未定義，只有當你嘗試去構建乙個可執行程式的時候，鏈結器才會驗證所有的符號。

當首次轉換乙個庫到winelib成功之前，你應該嘗試把他聯街道乙個可執行程式中。在這個時候，你可能就會發現一些你認為已經實現的未被定義的符號。然後，進入到庫原始碼進行修改。但是你也可能會發現丟失的符號是被定義了的，就像gdi32。這是因為你並沒有將gdi32和庫鏈結。修復他的乙個方式就是鏈結這個可執行程式，另外乙個方式就是帶著gdi32來使用你的庫。最好的方式就是回到你的庫的makefile中，顯式的將他和gdi32鏈結起來。

正如你要注意到的，對於winelib所屬庫來說並沒有完全實現。所以如果乙個程式必須要鏈結ole32的話，你也需要和advapi32，rpcrt4和其他庫鏈結，即使你並不直接使用他們。

（六） Winelib開發元件2

（五） Winelib開發元件（1）

（三） Winelib使用者手冊2

AppBoxFuture 六前端元件化開發

（六） Winelib開發元件2

（五） Winelib開發元件（1）

（三） Winelib使用者手冊2

AppBoxFuture 六 前端元件化開發

相關推薦

AppBoxFuture 六前端元件化開發