Visual Basic n'a pas été conçu d'un seul tenant. C'est l'assemblage de deux projets sans rapport l'un avec l'autre : un générateur de formulaires racheté à un concepteur indépendant, et un moteur Basic écrit pour un logiciel de base de données. Leur mariage a été décidé par un mémo interne, en août 1989. Cette notice retrace la généalogie — et ce qu'elle a laissé dans la structure des exécutables.
1988 : Ruby, un shell qui ne remplacera pas le shell
Alan Cooper conçoit en 1988 un langage de programmation visuel, sous le nom de code Ruby. Ce n'est pas un environnement de développement mais un « shell construction set » : un outil permettant de composer une interface par glisser-déposer, destiné à remplacer l'interpréteur de commandes de Windows.
Cooper en fait la démonstration à Bill Gates, qui estime que l'innovation aura un effet « profond » sur la gamme de produits Microsoft. L'entreprise rachète Ruby, avec l'intention initiale de le livrer avec Windows 3.0.
Ce n'est pas ce qui se produira. Microsoft renonce à le distribuer comme shell pour l'utilisateur final et décide d'en faire un outil de développement professionnel. Windows 3.0 sortira avec le Gestionnaire de programmes, et Ruby restera sans emploi.
Embedded Basic, moteur d'un projet de base de données
Au même moment, une autre équipe développe Embedded Basic — EB —, un moteur de langage destiné à être intégré dans un logiciel de base de données au nom de code Omega. EB n'est pas un produit : c'est un composant, conçu pour être embarqué dans une application hôte.
Le nom du futur produit, lui, existe déjà. En janvier 1989, John Fine rédige une proposition pour un produit de langage appelé « Visual BASIC ». Le nom précède donc de plusieurs mois la décision de fusionner les deux technologies.
Août 1989 : le mémo
Bill Gates adresse un mémo à l'encadrement du groupe Business Languages : trouver un moyen de marier Ruby et EB. La rencontre a lieu en août 1989. Le projet reçoit le nom de code Thunder.
Le récit de première main de cette période a été publié par Scott Ferguson, responsable du développement et architecte du projet. Il nomme l'équipe : Adam Rauch au pilotage produit, Chris Fraley comme premier développeur affecté à VB, Brian Lewis pour l'équipe EB, Rick Olson aux tests, Nevet Basker au marketing produit, Brian Overland à la documentation, et Michael Geary comme consultant sur Ruby. Ce qui devait être un travail d'appoint de six mois devient un produit complet de dix-huit.
Ce que Ruby apporte
Le concepteur de formulaires, le glisser-déposer, la notion de contrôle doté de propriétés et d'événements.
Et un mécanisme d'extension dynamique : des contrôles fournis par des tiers, chargés à l'exécution.
Ce qu'Embedded Basic apporte
L'interpréteur, la syntaxe Basic, la gestion de la mémoire et des types.
Un moteur pensé pour être embarqué, donc pilotable depuis l'extérieur — ce que le concepteur de formulaires va faire.
1991 : Visual Basic 1.0
Le produit est présenté en mai 1991 au salon Windows World. Le mécanisme de contrôles personnalisés hérité de Ruby reçoit l'extension .VBX, suggérée par le développeur Lee Acton ; elle donnera plus tard les OCX, puis ActiveX.
Alan Cooper restera identifié comme le « père de Visual Basic », titre qu'il n'a pas revendiqué : il n'appréciait pas le Basic, et le produit livré n'était pas celui qu'il avait conçu.
Chronologie
.VBX des contrôles personnalisés est suggérée par Lee Acton.La séparation est encore dans le binaire
Trente-cinq ans après le mémo, la greffe reste lisible. Un exécutable Visual Basic 6 ne contient pas un tout homogène : il contient d'un côté la description des formulaires et de leurs contrôles, de l'autre le code compilé. Les deux mondes n'ont pas subi le même traitement, et c'est l'héritage direct de leurs origines séparées.
L'héritage de Ruby
- Formulaires, contrôles, disposition
- Noms des contrôles et valeurs des propriétés
- Stockés comme des données décrites, pas traduits en instructions
- Survivent donc à la compilation
L'héritage d'Embedded Basic
- Corps des procédures, expressions, boucles
- Noms des variables locales, constantes, énumérations
- Traduits en P-Code ou en x86 selon le mode de compilation
- Ce que la compilation dégrade ou supprime
C'est pour cette raison structurelle qu'un décompilateur Visual Basic restitue une interface fidèle et un code partiel, et non l'inverse. Le détail de ce qui revient selon le mode de compilation est traité dans P-Code ou code natif et dans du P-Code au MSIL ; l'outillage construit autour de ce problème est recensé dans l'histoire des décompilateurs Visual Basic.
La couverture mesurée de VBReFormer, fonction par fonction et instruction par instruction, est publiée avec ses dénominateurs : 1 153 correspondances documentées. La version gratuite indique en quelques secondes ce que contient un binaire donné.