周海洋 黃小大

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

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

中圖分類號：TP311.1

文獻標識碼：A

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

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

2 建立定長的數(shù)據(jù)類型

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

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

3 設計符合COM標準的框架

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

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

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

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

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

（3）對于需要導出的接口函數(shù)，其調用約定統(tǒng)一為_stdcall;

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

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

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

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

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

4 構建STL輔助類

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

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

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

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

5 方案效果驗證

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

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

6 結論

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

參考文獻

[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技術和動態(tài)鏈接庫技術的應用研究[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/.