一種輕量級的Win32應用程序二進制接口兼容方案

周海洋 黃小大

摘要：在COM組件技術的基礎上，對Win32平臺下應用程序的二進制接口跨編譯器兼容問題進行了研究。通過利用Win32平臺下COM技術規約針對對象內存分布的一致約定，結合C++語言虛函數表的特性，提出一種專用于Win32平臺的應用程序二進制接口跨編譯器兼容問題解決方法。并由該方法衍生出一系列二進制接口兼容的類，形成一整套解決方案。與傳統Win32平臺上使用C語言接口或COM組件來達到二進制接口兼容的方式不同，新方案采用精簡的類和虛函數表來規范對象內存分布，借助Win32平臺下編譯器對COM技術的廣泛支持，實現了應用程序接口在不同編譯器下二進制級別的統一。同時，方案保持了原C++語言的面向對象特性，還具有簡單、輕量級的特點。

關鍵詞：Win32平臺;二進制接口兼容;跨編譯器;輕量級

中圖分類號：TP311.1

文獻標識碼：A

“二進制兼容”即使用舊版本組件的應用程序，可以和該組件的新版本進行正常連接與調用，而無需進行重新編譯[1]。不同編譯器下開發的軟件模塊，即使在同一操作系統平臺下，也難以做到二進制級別的兼容。

在Win32平臺下，傳統方法一般使用純C語言接口或COM組件技術來實現跨編譯器的二進制兼容。M給出了跨邊界對象的特性[2]，給跨邊界對象調用指明了方向。Box等探討了COM技術與C++的內在聯系[3]，為對象的跨編譯器兼容奠定了基礎。梁忠杰等給出了COM技術與動態連接庫技術相結合的開發案例[4]。上述研究單純關注跨邊界對象或COM技術本身，對于同時跨邊界、跨編譯器問題傾向于使用COM技術解決。純C語言接口不具有面向對象特性和豐富的類庫，而COM技術對于中小型項目而言過于復雜。針對這些問題，依據Win32平臺下COM技術原理，利用C++語言的虛函數表等特性，生成二進制接口兼容的組件，實現跨邊界、跨編譯器兼容，為中小型項目提供一種輕量級的解決方案。

2 建立定長的數據類型

相同的數據類型如bool，在不同架構或不同編譯器下長度可能不同。由于bool類型被定義在標準中并由編譯器廠商實現[5]，不同實現數據長度可能不同，這給兼容增加了難度，所以它在函數以及類的公共接口的規格聲明中很少使用。因此，實現二進制兼容的第一步，即建立定長的數據類型。

C99標準就提供了一組定長的類型[6]，包括int8_t、int16_t、uint32_t等。通過在C++中引用頭文件cstdint，可以結合typedef定義出定長整型數據類型。就浮點型數據類型而言，其長度和表示方式在各編譯器下均一致，無需特殊考慮。64位長整型在實際編程中使用較少，亦不作定義。需特別注意的是布爾類型，為增強可移植性，統一將其定義為32位有符整型，即int32_t。數據類型定義詳見表1：

3 設計符合COM標準的框架

COM（Component Object Model，組件對象模型），是由微軟提出的一套軟件接口規范，允許來自不同軟件供應商的二進制組件，以一種定義良好的方式連接和通信[7]。COM標準使用C++虛函數表來實現對象的二進制兼容，各模塊定義統一抽象接口由其它模塊調用，將類的接口與實現相分離。其原理如圖1所示。

模塊的抽象接口生成全局唯一的虛函數表，提供給其它模塊引用。其它模塊通過接口指針或引用，取得該模塊虛表地址，通過虛表地址結合函數偏移量，解析出模塊內函數在內存中的指針，達到跨邊界函數調用的目的。

一般而言，符合COM標準的抽象接口具有如下特征：

（1）接口是一個純虛類，含有純虛函數，且純虛函數之間不存在函數重載;

（2）接口中盡量不包含實體函數，若需要使用實體函數則其必須為內聯函數;

（3）對于需要導出的接口函數，其調用約定統一為_stdcall;

（4）析構函數不能為虛函數，需要額外定義函數用于析構資源;

遵循以上規則，設計出框架的基類，如圖2所示：

抽象類IObject為所有框架類的基類，其中Destroy為受保護類型的純虛函數，是模塊析構資源的接口，起到替代析構函數的作用。IObject重載了delete操作符，使其調用Destroy函數。當外界對IObject或IObjectOtherA指針使用delete操作符時，將調用Destroy函數。若需要擴展接口，可繼承IObject，以提供多種擴展功能，如IObjectOtherA的做法。

IObjectDelete作為輔助模板類，實現了資源的正確釋放。該模板類所有函數均為內聯函數，主要用于綁定各類擴展接口如IObjectOtherA等。同時，它實現了Destroy接口，并將其析構函數聲明為虛，重載了delete操作符用于真正釋放資源。IObject-Delete首先綁定擴展接口，其余IObject的實現類，如IObj ectlmplA等，通過繼承IObjectDelete模板類，來實現具體的接口功能。IObjectDelete可以綁定不同接口，相應的也可以有IObjectlmplA、IOb-jectlmplB等不同實現。

框架調用的順序圖如圖3所示，以IObjec-tOtherA為例進行說明。為了更清晰地表示調用關系，圖3中IObject、IObjectOtherA和IObjectDelete以虛對象（外框為虛線）表示，在實際內存中均對應IObj ectlmplA對象。在進行對象析構時，在組件外部對基類指針進行delete操作，由于IObject重載了delete操作符，將調用其Destroy方法。此時通過虛函數表映射，跨越邊界，映射至IObjectDelete的Destroy實現，在函數體中對this指針進行delete操作，觸發對象的析構。此時，由于IObjectDelete類析構函數聲明為虛，子類IObjectImplA的析構函數將優先調用，整個對象的析構流程自此開始。

4 構建STL輔助類

為了增加新的優化和特性，Win32平臺下部分編譯器對STL（ Standard Template Library，標準模板庫）的實現有意打破了不同版本間的二進制兼容性[8]。因此，在使用STL庫時，使用不同版本編譯器編譯的目標文件和靜態庫不能在一個二進制文件中混用（EXE或DLL），并且不同版本編譯的STL二進制對象不能在組件之間作為參數傳遞。

STL庫在實際編程中，具有方便、快捷的特點。我們通過利用編譯器原有的STL庫實現，使用上文中提出的框架對其進行二次封裝，構建一系列輔助類，實現了Win32平臺下STL庫的二進制兼容，使其能跨編譯器使用。其類圖如圖4所示：

圖4中主要對STL庫中的string.vector和map類進行了二次封裝，已能滿足基本應用需求。其它標準容器的封裝方法與此類似，不再贅述。需特別注意的是，上述輔助類的實現必需是內聯實現，且函數的處理過程中不能拋出任何異常，不可使用任何運行期間類型信息（ RTTI），只能使用返回值來返回異常狀態。

輔助類的使用分為兩種情況：一是從組件外部傳遞對象至組件內部，此時只需在棧上聲明子類對象，再以基類接口指針或接口引用方式，傳遞給組件內部使用，使用完畢后對象資源將自動釋放。另一種是由組件內部傳遞對象至組件外部，這種情況需針對特定對象提供CreatelObject函數類似的C語言創建接口，返回基類接口指針以供外部使用，并由外部負責該對象資源的釋放。

5 方案效果驗證

運用上述框架構建驅動模塊和樁模塊，在Win32平臺下使用若干較為陳舊的編譯器編譯驅動和樁模塊，通過不同編譯器下驅動和樁模塊的交叉調用結果，驗證方案的可行性和有效性。其結果如表2所示：

表2中打勾的部分表示一種可用的兼容組合。從表2中可知，除少部分特別老舊的編譯器如GCC2.9.5以外，框架在大部分編譯器的組合下均能正常使用，基本達到了跨編譯器二進制兼容的設計目標。

6 結論

詳細介紹了一種Win32應用程序二進制兼容接口設計方法，利用COM技術的核心本質，繼而建立了Win32平臺下二進制兼容的程序框架，形成了一整套解決方案。該方案成功讓組件在大部分編譯器下達到二進制級別的兼容，實現了跨邊界、跨編譯器調用的目標，同時較COM組件更簡單、更輕量級。本方案的不足之處在于，缺乏統一的組件注冊管理機制，增加了組件調用和資源管理的復雜度，不適用于大型系統的設計。針對大型項目，由于缺乏統一的資源管理方式，該方案會增加程序設計的負擔。

參考文獻

[1] PONOMARENKO A.RUBANOV V.Automatic backward com-patibility analysis of software component binary interfaces[C].Shanghai：2011 IEEE International Conference on Computer Sci-ence and Automation Engineering （CSAE 2011），2011：167- 168.

[2]WILSON M.ImperfectC++[M].榮耀，劉未鵬，譯，北京：人民郵電出版社，2006：110-111.

[3] BOX D.Essential COM[M]. Massachusetts：Addison WesleyLongman， 1998：14-20.

[4]粱忠杰，思敏，李婷.COM技術和動態鏈接庫技術的應用研究[J].微計算機應用，2006，27（ 6）：701-703.

[5] ISO/IEC 14882：1998， Programming languages C++[S].New York：American National Standards Institute. 1998：76-77.

[6] ISOflEC 9899：1999，Programming languages C[S].New York：American National Standards Institute. 1999：254-259.

[7] PUGH B.The component object model： technical overview [EB/0L]. （1994 -12 -1） [2018.3.l].https：//www.cs.umd.edu/-pugh/com/.

[8] DICANIO G.The perils of C++ interface DLLs[EB/OL].（ 2016-7-11） [201 8.3.6].https：//blogs.msmvps.com/gdicanio/201 6/07/11/the-perils-of-c-interface-dlls/.