易語言支持庫升級之后，要保證向下兼容性，主要是做到以下幾點(diǎn)：

一：保證原有的易語言源程序（.e）能正常打開（兼容點(diǎn)1）、正常編譯（兼容點(diǎn)2）、編譯結(jié)果正確（兼容點(diǎn)3）；

二：保證原有的易語言程序（.exe）能正常運(yùn)行（兼容點(diǎn)4）、運(yùn)行結(jié)果正確（兼容點(diǎn)5）。

這里說的“原有的易語言源程序”和“原有的易語言程序”是指，替換新版支持庫文件之前，使用舊版支持庫編寫的易語言源程序，和使用該源程序編譯生成的可執(zhí)行程序。

本文主要就此問題結(jié)合具體情況進(jìn)行分析和總結(jié)。

一，為支持庫增加一條命令

新增加的命令，必須放在所有原有命令的后面，否則將違反兼容點(diǎn)2和4，更無法保證兼容點(diǎn)3和5。這是因?yàn)?，在源程序和EXE中，記錄的都是命令的索引，一旦在中間插入一條命令，將導(dǎo)致后面的命令索引全變了，進(jìn)而導(dǎo)致非常嚴(yán)重的錯位問題。只要記住，總是在所有命令的最后添加新的命令，就不會引入兼容性問題。具體到數(shù)據(jù)類型的成員方法，與上面的分種一致，因?yàn)樗彩鞘褂弥С謳熘形ㄒ坏娜趾瘮?shù)表的，但這里引入了一個新的細(xì)節(jié)，有一個LIB_DATA_TYPE_INFO.m_pnCmdsIndex 用于指定方法在全局函數(shù)表中的命令索引，所以通過它可以調(diào)整各成員方法的順序，這種做法通常不會引入兼容性問題。

二，為命令增加一個參數(shù)，或修改命令的參數(shù)

新增加的參數(shù)，必須放在所有參數(shù)的后面，否則將違反兼容點(diǎn)2,3,4,5；必須允許省略該參數(shù)（AS_DEFAULT_VALUE_IS_EMPTY）或該參數(shù)有默認(rèn)值（AS_HAS_DEFAULT_VALUE）；同時在編寫代碼讀取該參數(shù)值時要小心，須判斷nArgCount和MDATA_INF.m_dtDataType（否則違反兼容點(diǎn)4,5），大致大代如下：

void fn_Global_SetWindowRgn (PMDATA_INF pRetData, INT nArgCount, PMDATA_INF pArgInf) { int nArg1 = pArgInf[0].m_int; int nArg2 = pArgInf[1].m_int; //假設(shè)第三個參數(shù)是新版添加的參數(shù) int nArg3 = 0; if(nArgCount > 2 && pArgInf[2].m_dtDataType != _SDT_NULL) { nArg3 = pArgInf[2].m_int; } //... }

修改一個已有命令的參數(shù)時，不能隨便修改數(shù)據(jù)類型，否則將違反兼容點(diǎn)2,3,4,5，要改也只能改成通用型（同時在代碼中根據(jù)參數(shù)傳遞來的真實(shí)類型(MDATA_INF.m_dtDataType)做相應(yīng)處理）。參數(shù)的名稱和說明，因?yàn)槎际俏谋荆梢噪S便改，有會有兼容性問題，但不要改的意思與原來相反哦（排除原來失誤寫反了的情況），改變參數(shù)語義往往會導(dǎo)致代碼改動，進(jìn)而導(dǎo)致違反兼容點(diǎn)5。

三，為窗口組件增加屬性

新增加的屬性，必須放在已有屬性的后面，否則違反兼容點(diǎn)4,5，因?yàn)橐渍Z言運(yùn)行時是通過屬性的索引讀寫屬性值的。然后在序列化屬性值時，提高一個版本號，讀取時先判斷版本，舊版序列化出的數(shù)據(jù)少，就不能多讀。在此提示，序列化屬性值時，一定要先寫出版本號，如果沒有版本號，后續(xù)的兼容性問題多多。

（TODO：這一段另成一文）但即使有了版本號，使用不當(dāng)，也會導(dǎo)致升級時的麻煩，我前一段就遇到過，代碼有這么一句：if(dwVersion > CURRENT_VER) return FALSE; 版本號比現(xiàn)在能處理的版本號大，出現(xiàn)在什么情況呢，用舊版支持庫打開/運(yùn)行用新版支持庫編譯的易源程序/程序。返回假是合理的（畢竟不能完全處理這種情況），但是比較粗暴（這意味著無法用舊版支持庫打開用新版支持庫編寫的源程序/程序，這不是向下兼容的問題，是向上兼容的問題），如果能盡量讀取，放棄不能識別的數(shù)據(jù)，溫和的處理，效果更好。簡單的把這條判斷語句刪除，有用嗎？當(dāng)然沒用，舊版的支持庫已經(jīng)在用戶手上了，編譯結(jié)果是確定的，你的改動只能體現(xiàn)在新版中，而對舊版無能為力。解決這個問題需要技巧，我采取的方案是，版本號不升反降！即，把CURRENT_VER減小，那么我序列化出的數(shù)據(jù)，版本號比以前還小，舊版支持庫里的那條判斷（if(dwVersion > CURRENT_VER)）就不起作用了，嘿嘿。新的序列化數(shù)據(jù)版本更低，但寫的數(shù)據(jù)更多，需要擔(dān)心舊版支持庫讀出多余的數(shù)據(jù)來嗎？當(dāng)然不用，舊版支持庫的編譯結(jié)果和運(yùn)行結(jié)果是確定的。只要新版支持庫中識別出這種情況，不要因?yàn)榘姹咎栃【驼J(rèn)為是舊版就行了，同時后續(xù)升級的方便，再引入一個新的版本號，存到原有序列化數(shù)據(jù)的最后，這樣再次升級時直接判斷新版本號就行了，原有的那套版本號停止使用。這一段有點(diǎn)亂，需整理。

四，為數(shù)據(jù)類型增加私有成員

如果某個數(shù)據(jù)類型已經(jīng)有了一個或多個私有成員，升級時需要增加一個私有成員，該怎么辦，直接在LIB_DATA_TYPE_ELEMENT 數(shù)組中添加一項(xiàng)嗎？不行！這樣將違反兼容點(diǎn)4,5，因?yàn)閷ο笏加脙?nèi)存是在由EXE分配的，舊的EXE中只為對象分配了N個成員的空間，而新庫要去訪問第N+1個成員，不就發(fā)生內(nèi)存訪問越界的錯誤了嗎？解決方案是，把原來的N個私有成員連用新增加的成員，集中存儲到一塊新分配的內(nèi)存中，然后把這個內(nèi)存地址存儲到原有的第一個私有成員位置上（原有的其它成員位置廢棄不用）。因?yàn)榧词故桥fEXE也會調(diào)用新支持庫中的構(gòu)造函數(shù)和析構(gòu)函數(shù)，所以改變私有成員存儲位置不會影響程序的執(zhí)行。這種方案對代碼的影響是非常大的，需要修改很多地方（所有對私有成員的讀寫），但是為了保證支持庫的向下兼容性，這種付出是值得的。

最新評論