The wish to open the field as wide as possible to MB applications leads directly to looking for a code that can be understood by as many MI installations as possible. There is no doubt that in many cases the requirements of the application may impose that the code be written with a specific MB version as minimum requirement; server connectivity did not exist before version 4.5, 3D maps before 6.0 . But in a large number of applications, version 3.0 is still sufficient to run them.
Application Backward Compatibility is a project to maximize this feature. One aspect is to properly document the impacts of version changes on the language and its capacity; it is hoped that such information will help developers in properly specifying the earliest version that their applications require.
A second facet is to help with already compiled application in trying to find out with which earlier version they could run. It is not expected from every developer to keep a set of compilers for each existing version, but it is possible to change the version stamp with which a MBX is marked when it is compiled for an earlier version still compatible with its code. This is an ongoing project and will be updated as new documents are generated. Contributions will be the most welcome.
Each MB application is stamped when it is compiled with the version of the compiler. When a MBX is open by MapInfo, that stamp is verified and if its version is higher than the MI version, MI refuses to run it.
What makes MB versions different are the changes that exist in the list of the functional elements (statements, functions), in the parameters of specific statements (key words that are part of statements, the clauses in MI terms) and
in the definition of parameters (essentially the range of values a parameter can have, the allowed values of an attribute).
examples:
All the functions dealing with 'Spherical' or 'Cartesian' calculations were introduced in v5.5One could theoretically run on a MI of a given version any MBX written in a posterior version as long as no use is made of elements that would exist only in versions posterior to the MI given version. There are many instances of MBX compiled in say 5.5 that could be run on MI v3.0 because they do not use any of the additions or modifications introduced since v3.0. If one is looking for ways to widen the use of MB applications, he should then be looking at ways to stamp the MBX with the earliest version compatible with his code. Such a 'modified' MBX will have a larger potential market than if it were stamped with the latest version.
The 'SetDateWindow' statement appeared also in 5.5
The number of nodes in an object was limitited to 32k in versions prior to 4.5
The key word 'Version' was added in v6.0 to 'Commit Table' for Access table saves.
The maximum value of the attribute of the 'MapperInfo()' function went from 18 to 22 with v5.5
Anyone with a Hex editor can modify the version stamp on a MBX. A version 5.5 of a MBX file begins always by '!App !Version550 '. It is easy to locate and easier to change. But one must be careful that he does the right thing, that is that he changes to the really earliest version and that this change is acceptable. If not the MBX may not work or may crash at a given time.
The various documents produced by MapInfo as books or as files distributed as part of the software package should be the essential sources of information about the specificities of each version. But these documents are not always explicit and trying to find when a particular piece of code has appeared can be rather difficult.
I have identified the following sequence of official publications:
(no trace of version 3.0 on my bookshelves)
version 4.0 MapBasic Reference RM101W4 11/95
version 4.1 MapInfo v4.1 Upgrade Guide MANUG1014 8/96
version 4.5 MapInfo Professional 4.5 Supplement MANU1533 11/97
version 5.0 MapBasic Reference MANRF1013 8/98
version 5.5 MapInfo Professional 5.5 Supplement MANUG1533 5/99 (*)
version 6.0 MapInfo Professional 6.0 Supplement MANUG1533 5/00 (*)
version 6.5 MapBasic Reference Guide MANRF1013 6/01A simple text file was joined to the 4.12 update package.(*) because I had chosen the update program, I did not receive the full reference manuals that certainly exist for these versions.
These books have a counterpart in the help files that include the 4.12. The MapBasic.hlp files should certainly be as reliable a source as the printed documents but they may show version novelties less obviously (even if they are listed under 'New Features') than the books because they are always a complete document, while the upgrades and supplements will show only additions and changes.
The first document that we can consult is the MB_Changes (in pdf format) that is a simple compilation of the 'New Features' item contained in each of the MB Help files. This source is somewhat patchy and often describes general areas of changes rather than specifying specific modifications. We have started by identifying changes from that basis but we were not too long before refining a way of recording every pertinent element.
As a final resource, we can also look at the MapBasic.DEF files that contain all the definitions allowed for the attributes of various functions. This is of course a limited set of the MB environment; it touches only functions with defined attributes, but many changes between versions come from differences in the sets of recognized attributes.
In some cases, one cannot rely only on official documents if he wants to push back as far as possible the 'earliest' compatible version; I was told there may be few cases where some code elements existed in the MB compiler and in the MI main program before it was officially announced as part of a new version, or before their definitions were added to the def files. It can be proven only by investigating the various files of the different versions of the programs. On this entire issue, MI has remained rather silent and not particularly cooperative. It is only thanks to some very motivated individuals that a compilation of all the version changes has been undertaken but unluckily it does not include yet all the finer details.
Phil Bolian of Stopwatch Maps has compiled such a list of 'words' with the version in which they first appeared. By 'word', one must understand any single word that is not a variable name or a value; a statement can contain many different words in its 'name' only (Set Paper Units is formed of 3 words); key words may exist alone (Window in Set Map statement) or as a group (Frame Contents in Set Layout); the same can apply to a clause with its 'name' and keywords; but a function or a handler is always a single word.
A clause is understood to be a block of information formed by an identifier and a set of keywords respecting their own rules and that can be repeated in a given statement (the Layer clause in a Set Map), or by a single expression that can be used in many different contexts (CoordSys and the 4 style definitions Brush, Pen, Font, Symbol are clauses in MI terms).On the basis of such a list (words and the version in which they appear), Phil has written an application to detect the latest among all the versions attached to the words contained in a MBX and to report this version as the earliest MI version that could run that MBX. The stamp on the MBX can also be changed to any version desired, included that estimated earliest one.
This application comes under different forms. It is available as a DLL, (MbxVerFn.dll with its MbxVerFn.def) or as a self contained EXE (MbVersion.exe) from his site. I have also written a MLC_INI compliant MBX that requires the presence of the MbxVerFn.dll (to be downloaded from the above site). For details see MBXVER.MBX.
One must be aware that the version reported by that application does not take into account other differences than those detected by the 'words' check and that there is no guarantee that every MBX will work with the 'detected' version as its 'stamp'. Several subtleties are still ignored by the August 2000 version of that application because, unluckily, they have not yet been indexed in a systematic manner. But despite this caution, the results should be acceptable in the largest number of cases.
MbxVerFn does not deal yet with all the situations in which changes have occurred. Changes do not manifest themselves under the simple form of 'words'. For example, they can imply the range of acceptable values for some parameters, the availability of icons, of menu command codes, etc. This diversity of sources requires first the building of a complete list of elements and of their characteristics related to the version changes. This work is under way and is explained under 'Info base on changes'