總結升級易語言支持庫保證向下兼容性

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

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

二：保證原有的易語言程序（.exe）能正常運行（兼容點4）、運行結果正確（兼容點5）。

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

本文主要就此問題結合具體情況進行分析和總結。

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

新增加的命令，必須放在所有原有命令的后面，否則將違反兼容點2和4，更無法保證兼容點3和5。這是因為，在源程序和EXE中，記錄的都是命令的索引，一旦在中間插入一條命令，將導致后面的命令索引全變了，進而導致非常嚴重的錯位問題。只要記住，總是在所有命令的最后添加新的命令，就不會引入兼容性問題。具體到數據類型的成員方法，與上面的分種一致，因為它也是使用支持庫中唯一的全局函數表的，但這里引入了一個新的細節，有一個LIB_DATA_TYPE_INFO.m_pnCmdsIndex 用于指定方法在全局函數表中的命令索引，所以通過它可以調整各成員方法的順序，這種做法通常不會引入兼容性問題。

二，為命令增加一個參數，或修改命令的參數

新增加的參數，必須放在所有參數的后面，否則將違反兼容點2,3,4,5；必須允許省略該參數（AS_DEFAULT_VALUE_IS_EMPTY）或該參數有默認值（AS_HAS_DEFAULT_VALUE）；同時在編寫代碼讀取該參數值時要小心，須判斷nArgCount和MDATA_INF.m_dtDataType（否則違反兼容點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; //假設第三個參數是新版添加的參數 int nArg3 = 0; if(nArgCount > 2 && pArgInf[2].m_dtDataType != _SDT_NULL) { nArg3 = pArgInf[2].m_int; } //... }

修改一個已有命令的參數時，不能隨便修改數據類型，否則將違反兼容點2,3,4,5，要改也只能改成通用型（同時在代碼中根據參數傳遞來的真實類型(MDATA_INF.m_dtDataType)做相應處理）。參數的名稱和說明，因為都是文本，可以隨便改，有會有兼容性問題，但不要改的意思與原來相反哦（排除原來失誤寫反了的情況），改變參數語義往往會導致代碼改動，進而導致違反兼容點5。

三，為窗口組件增加屬性

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

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

四，為數據類型增加私有成員

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