Summary on how to upgrade the easy language support library to ensure downward compatibility

Original: http://blog.csdn.net/liigo/article/details/4089969

Author: Zhuang Xiaoli (liigo), 2009-04

Reprinted please indicate the source: http://blog.csdn.net/liigo

After the easy language supports library upgrade, to ensure downward compatibility, the main measures are as follows:

1. Ensure that the original easy language source code (. e) can be opened properly (compatible with point 1), compiled properly (compatible with point 2), and compiled correctly (compatible with point 3 );

2. Ensure that the original language program (.exe) runs properly (compatible with point 4) and the running result is correct (compatible with point 5 ).

The "original easy language source program" and "original easy language program" here refer to the easy language source program written in the old version of the support library before the new version supports library files, and the executable program compiled using the source program.

 

This article analyzes and summarizes the problem based on the actual situation.

 

1. Add a command to the supported Database

The newly added commands must be placed behind all the original commands. Otherwise, compatibility points 2 and 4 will be violated, and compatibility points 3 and 5 will not be guaranteed. This is because, in the source program and exe, the record is the index of the command. Once a command is inserted in the middle, the index of the subsequent command changes completely, leading to a very serious dislocation problem. As long as you remember, adding new commands at the end of all commands will not introduce compatibility issues. The member method specific to the data type is consistent with the preceding sub-types, because it is also used to support the unique global function table in the database, but a new detail is introduced here, there is a lib_data_type_info.m_pncmdsindex that is used to specify the command index of the method in the global function table. Therefore, you can adjust the order of each member method through it. This method usually does not introduce compatibility issues.

 

2. Add a parameter for the command or modify the parameter of the command.

The newly added parameter must be placed behind all parameters; otherwise, the compatibility points 2, 3, 4, and 5 will be violated; this parameter must be omitted (as_default_value_is_empty) or the parameter has a default value (as_has_default_value ); at the same time, be careful when writing code to read the value of this parameter. You must judge nargcount and mdata_inf.m_dtdatatype (otherwise, the compatibility point is 4 or 5). the approximate generation is as follows:

Void fn_global_set1_wrgn (pmdata_inf pretdata, int nargcount, pmdata_inf parginf) <br/>{< br/> int narg1 = parginf [0]. m_int; <br/> int narg2 = parginf [1]. m_int; <br/> // assume that the third parameter is added in the new version. <br/> int narg3 = 0; <br/> If (nargcount> 2 & parginf [2]. m_dtdatatype! = _ Sdt_null) <br/>{< br/> narg3 = parginf [2]. m_int; <br/>}< br/> //... <br/>}

When you modify the parameters of an existing command, you cannot modify the data type at will. Otherwise, the compatibility points 2, 3, 4, and 5 will be violated, to modify the data type, you can only change the data type to general type (mdata_inf.m_dtdatatype ). Parameter names and descriptions. Because they are both texts, they can be changed at will. There may be compatibility issues, but do not change the meaning to the opposite of the original one (excluding the original incorrect descriptions ), changing the parameter semantics often leads to code changes, resulting in violation of compatibility point 5.

 

3. Add properties for window components

The newly added attribute must be placed behind the existing attribute; otherwise, the compatibility point is 4 or 5, because the attribute index is used to read and write the attribute value during easy language runtime. Then, when serializing the attribute value, increase the version number. When reading the data, judge the version. If the old version serializes less data, it cannot read more. Note that when serializing attribute values, you must first write the version number. If no version number is available, there will be many compatibility issues in the future.

(Todo: This paragraph is another article) but even if the version number is used improperly, it will cause trouble during the upgrade. I have encountered this in the previous section. The Code has the following sentence: if (dwversion> current_ver) return false; the version number is larger than the version number that can be processed now. What is the situation, use the old version of the support library to open/run the easy source program/program compiled by the new version of the support library. It is reasonable to return false (after all, it cannot completely handle this situation), but it is rough (this means that the source program/program written in the new version support library cannot be opened with the old version support library, this is not a problem of backward compatibility, but an issue of upward compatibility. If you can read as much data as possible, give up unidentifiable data, and perform gentle processing, the effect is better. Is it useful to simply delete this judgment statement? Of course it is useless. The old version of the support library is already in the hands of users, and the compilation result is definite. Your changes can only be reflected in the new version, but you cannot do anything about the old version. Skills are required to solve this problem. The solution I (liigo) adopted is that the version number does not increase or decrease! That is, reduce current_ver, so the version number of the serialized data is smaller than before. The old version supports the judgment in the Library (if (dwversion
> Current_ver) does not work anymore. The new version of serialized data is lower, but more data is written. Do you need to worry that the old version supports reading excess data from the database? Of course, no. The compilation and running results of the old version support libraries are definite. As long as the new version supports the identification of this situation in the library, do not consider it as an old version because the version number is small. At the same time, it is convenient for subsequent upgrades to introduce a new version number, save to the end of the original serialized data, so that you can directly judge the new version number when upgrading again, and the original version number will not be used. This section is a bit messy and needs to be sorted out.

 

4. Add a private member to the Data Type

If a data type already has one or more private members, you need to add a private member during the upgrade. What should I do? Add a private member directly to the lib_data_type_element array? No! This will violate the compatibility point, because the memory occupied by the object is allocated by the EXE, and the old EXE only allocates space for n members to the object, if the new database is going to access the n + 1 member, will there be an out-of-bounds memory access error? The solution is to use the original n private members to add new members and store them in a new allocated memory, then store the memory address to the original first private member location (other original member locations are not used ). Because even the old exe will call the constructors and destructor in the new supported libraries, changing the private member storage location will not affect program execution. This scheme has a very large impact on the Code and needs to be modified in many places (all the reads and writes to private members). However, to ensure the downward compatibility of the supported libraries, this kind of effort is worthwhile.

5. Add a constant to the supported database or add a constant member to the enumeration type

Must be added to the end of an existing constant or constant member. Otherwise, the compatibility point is 1, 2, and 3. Because the source code is easy to use. the E file records the indexes of constants in the supported databases. Once a new constant is inserted in the middle, the constant indexes will change in the future, and the previously used constants will be misplaced, extremely destructive. However, because the constant value is directly compiled into the EXE/DLL, the runtime does not support loading constants in the library, so it does not violate compatibility points 4 or 5.