Vouloir ouvrir aussi large que possible le champ d'utilisation aux applications MB entraîne directement la recherche d'un code qui pourrait être reconnu par le plus grand nombre d'installations MI possible. Il n'y a aucun doute que la nature même d'une application impose d'utiliser une certaine version de MB comme exigence minimale; ainsi la connection à un serveur exige la version 4.5, les cartes en 3D, la 6.0. Mais pour un grand nombre d'applications, il suffit encore de la version 3.0 pour les faire marcher.
La Compatibilité à rebours des applications (= Application Backward Compatibility, ou A.B.C.) est un projet conçu pour maximiser cette capacité. Un aspect en est de construire une bonne documentation sur les impacts des changements de version sur le language et ses capacités; on souhaite que cette information permettra aux programmeurs de spécifier efficacement la version la plus ancienne sur laquelle leur application pourra fonctionner.
Une deuxième facette est d'aider de trouver pour des applications déjà compilées quelle serait la plus ancienne version compatible. Comme il ne faut pas s'attendre à ce que chaque programmeur conserve les MB de chaque version existante, il faut envisager de changer l'étampe de version dans le MBX pour lui donner la valeur la plus convenable possible.. Ceci est un projet en plein développement qui va générer de nouveaux documents et de nouvelles éditions. Toute contribution sera bienvenue.
Tout MBX est étampé lors de sa compilation avec le numéro de version. Quand un MBX est lancé sur MI, cette étampe est vérifiée et si sa version est plus haute que celle de MI, MI ne l'accepte même pas.
Ce qui rend les versions de MB différentes sont les changements qui apparaissent dans la liste des éléments fonctionnels (énoncés, fonctions), dans les paramètres d'énoncés spécifiques (mots clés faisant partie d'énoncés, "phrases"(=clauses) de MI) et dans la définition des paramètres (essentiellement la gamme de valeurs qu'un paramètre peut prendre, les valeurs permises d'un attribut).
Exemples:
Toutes les fonctions utilisant les modes de calcul 'Spherical' or 'Cartesian' ont été introduites avec la v 5.5On pourrait théoriquement faire fonctionner sur un MI d'une version donnée tout MBX écrit dans une version postérieure (plus récente) aussi longtemps que le MBX ne compte aucun élément qui serait apparu dans une version plus récente que celle du MI. Il y a de nombreux exemples de MBX compilés avec la version 5.5 qui pourraient marcher sur un MI 3.0 parce qu'ils n'utilisent aucun des changements introduits depuis cette version 3.0.
L'énoncé 'SetDateWindow' est apparu aussi avec la 5.5
Le nombre de nœuds dans un objet était limité à 32k dans les versions antérieures à 4.5
Le mot clé 'Version' a été ajouté en v 6.0 au 'Commit Table' pour la sauvegarde de table Access
La valeur maximale de l'attribut de la fonction MapperInfo() est passé de 18 à 22 avec la version 5.5
Si quelqu'un recherche une façon d'étendre l'utilisation de ses MBX, il devrait donc considérer des moyens d'étamper ses MBX avec la version la plus ancienne compatible avec le code utilisé. Un MBX ainsi "modifié" aura un plus grand marché que s'il était offert avec un numéro de version plus récent.
N'importe qui avec un éditeur Hexadécimal peut modifier l'étampe de version. Un fichier MBX compilé avec MB 5.5 commence toujours par "!App !Version550". Cette ligne est très facile à trouver et à modifier. Mais il doit rester prudent qu'il fait la bonne chose, c'est à dire qu'il change vraiment pour la version la plus ancienne et que le code soit compatible. Sinon, le MBX peut ne pas marcher ou peut bloquer à tout moment.
Les divers documents produits par MapIfo sous la forme de livres ou de fichiers distribués avec le logicel devraient être la source principale de l'information concernant chaque version. Mais ces documents ne sont pas toujours explicites et parfois l'information concernant un élément de code précis est difficile à trouver.
J'ai identifié la séquence suivante de publications officielles:
(aucune trace de la version 3.0 sur mes étagères)
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 MANRF1013 6/01
Un simple fichier texte faisait partie de la mise à jour 4.12.
(*) comme membre du programme de mise-à-jour, je n'ai pas reçu les documents complets qui existent certainement
Ces livres ont une contrepartie dans les fichiers d'Aide dont un existe pour la 4.12. Les fichiers Mapbasic.hlp sont certainement une source aussi fiable que les livres mais les nouveautés ne sont pas mises autant en évidence, même si présentées dans l'article "New Features", que dans les livres parce que ces fichiers sont des documents "complets" alors que la majorité des livres ne sont que des "suppléments".
Le premier document offert pour consultation est MB_Changes (en format pdf) qui est une simple compilation de l'article 'New Features" présent dans chaque fichier d'Aide depuis la version 4.0. Cette source est assez inégale et décrit souvent les changements par grands domaines ce qui n'aide pas à l'identification de changements spécifiques. Nous avons débuté à identifier les changements à partir de cette source mais très vite il nous a fallu trouver une façon beaucoup plus systématique de travailler.
Comme autre ressource, nous avons aussi utilisé les fichiers DEF pour MapBasic.qui contiennent toutes les définitions autorisées des attributs d'une fonction. C'est un ensemble limité de l'environnement MapBasic car il ne touche que les fonctions avec attributs, mais bien des changements proviennent justement de différences introduites dans les gammes reconnues des attributs.
Dans quelques cas, on ne peut pas seulement se baser sur des documents officiels pour remonter à la plus ancienne version compatible; on m'a laissé entendre que quelques éléments de code auraient "existé" dans le compilateur MB et dans MI avant d'être annoncé comme faisant partie d'une nouvelle version ou d'être inclus dans un fichier DEF. Ceci ne peut être retrouvé qu'en examinant attentivement les fichiers des divers versions. Sur cette question, Mi est resté plutôt silencieux et pas particulièrement coopératif. C'est seulement grâce à quelques invidus bien motivés qu'une compilation de tous les changements de versions a pu être entreprise, mais elle ne comprend pas encore les détails les plus précis.
Phil Bolian de Stopwatch Maps a compilé une liste de "mots" avec la version dans laquelle ils sont apparus pour la première fois. Par "mot" il faut comprendre tout mot simple qui n'est pas un nom de variable ou une valeur; un énoncé peut comprendre plusieurs mots dans son nom seul (Set Paper Units est formé de 3 mots); les mots clés peuvent exister seuls (Window dans l'énoncé Set Map) ou comme un groupe (Frame Contents in Set Layout); ceci s'applique aussi à une "phrase" (clause) avec son nom et ses mots clés; mais une fonction ou un "handler" est toujours un mot simple.
Une phrase (clause) est un block d'information formé par un identificateur et un ensemble de mots clés respectant leurs règles propres et qui peut être répété dans le cadre de certains énoncés (la phrase Layer dans Set Map), ou par une simple expression qui peut se trouver dans différents contextes (CoordSys, les styles Brush, Pen, Font, Symbol).Sur la base d'une telle liste (mots et versions associées), Phil a écrit une application pour détecter quelle serait la plus "récente" parmi toutes les versions attachées aux mots présents dans le MBX et rapporter cette version comme la plus "ancienne" pour pouvoir faire marcher le MBX. Cette application permet aussi de changer l'étampe du MBX à n'importe quelle version précédente (sous la responsabilité entière de l'utilisateur) ou automatiquement à la version détectée précédemment (avec la réserve formulée plus bas). Cette application est offerte sous deux formes: DLL (MbxVerFn.dll with its MbxVerFn.def) ou EXE autonome (MbVersion.exe) que l'on peut obtenir sur son site.
J'ai aussi écrit une application MBX aux standards MLC_INI qui requiert la présence de MbxVerFn.dll (à télédécharger du site indiqué). Pour détails voir MBXVER.MBX. Il faut être conscient que la version rapportée par cette application ne prend en compte que les différences identifiées dans la liste des "mots" et qu'il n'y a aucune garantie que tous les MBX étampés avec la version détectée comme la plus ancienne vont marcher. Il y a des subtilités qui sont ignorées par la version d'août 2000 du DLL parce qu'elles nétaient pas encore répertoriées de façon systématique. Vu cette mise en garde, les résultats pratiques à date sont très encourageants.
MbxVerFn ne traite pas encore de toutes les situations dans lesquelles il y a eu des changements. Ceux-ci ne se manifestent pas seulement par la simple apparition de nouveaux mots. Ils peuvent aussi impliquer la gamme des valeurs acceptables pour un paramètre, la disponibilité d'icônes, les codes d'items de menus, etc. Cette diversité de sources de changement exige une parfaite identification de toutes ces manifestations et de leurs caractéristiques en fonction de la version. Ce travail en cours est expliqué dans 'Banque d'Info sur les changements'