De temps en temps TWD Industries reçoit des questions techniques. Des programmeurs nous demandent comment nous avons pu créer un produit qui a plus de fonctions que pcAnywhere (80 Mo) alors que RA fait seulement 80 Ko!

Voici comment nous avons fait:

RA a été créé par des ingénieurs qui ont travaillé pour les cinq premiers éditeurs de logiciels. Les choix faits pour l'architecture et la réalisation de RA ont été dictés par l'efficacité, pas par un manque d'expérience ou à cause d'alliances 'stratégiques' (cette sorte d'alliance qui fait que la dernière version de votre traitement de texte est si lente que vous êtes obligé d'acheter un nouveau PC tout les deux ans).

Nous avons simplement essayé de rendre RA (et le DS) aussi bon que possible, en partant de zéro.

       RA utilise des librairies seulement si le code source est disponible et portable.

       RA n'utilise pas les pilotes de bas-niveau ou les services de Windows.

       RA est écrit en C++ portable. Cela nous permet de travailler sur des versions Mac et Unix.
        La portabilité a des effets de bord intéressants qui rendent le code de RA:

             plus petit
             plus rapide
             plus fiable
             plus facile à maintenir et à améliorer

       L'optimisation est un art qui se perd mais nous avons essayé de faire RA petit et rapide.
        Nous avons appliqué les méthodes de bon-sens suivantes:

             le faire marcher (versions alpha)
             le faire marcher bien (versions beta et finales)
             le faire marcher rapidement (mises à jour gratuites)

       Nous avons considéré les utilisateurs de RA comme la source de feedback idéale.

Malgré nos efforts les plus soutenus, RA a des bugs. Lorsqu'un bug est trouvé, nous postons une version corrigée aussi vite que possible, la plupart du temps en quelques jours, parfois en quelques heures.

Mais d'autres fois, RA ne fonctionnait pas bien sur l'une des douzaines de versions 32-Bit de Windows:
(ajoutez les 'services packs', les versions d'Internet Explorer et des applications MS qui modifient le système comme Office ou IIS et vous finirez avec plus de 400 plate formes différentes. Ô joie...)

La plupart du temps, le problème venait des versions différentes et incompatibles des DLL de Windows. Les DLL de Windows DLL sont un sujet très frustrant. De plus, les utilisateurs ne le comprennent pas. Pour eux, comme Windows n'est pas planté, c'est votre programme qui a un bug, pas Windows.

Ils ne peuvent simplement pas imaginer la vérité: "Windows" n'est pas une plate-forme mais plutôt une poignée de systèmes d'exploitation écrits par des équipes différentes qui parfois ont essayé de maintenir la compatibilité. Cela n'est pas visible pour l'utilisateur, mais, pour un programmeur, même la façon d'écrire un programme change suivant la version de Windows que vous comptez utiliser. L'API Windows offre des fonctions qui, quand elles sont disponibles sur toutes les versions de Windows (un cas assez rare), ne fonctionnent pas de la même manière sur les différentes versions de Windows.

Elles peuvent fonctionner, ne pas fonctionner, donner des résultats différents ou simplement planter votre application ou le système. Parfois, elles obligent le programmeur à leur fournir des valeurs différentes afin de les faire fonctionner normalement. Elles peuvent également empêcher votre application d'être lancée, même si vous ne faites pas usage de la fonction en question (vous devez détecter au départ quelle version de Windows est utilisée, et vérifier si toutes les fonctions que vous voulez utiliser sont disponibles). 

Certains appels ne fonctionnent plus après un Service Pack, un patch ou l'installation d'un autre logiciel, ou leur comportement peut changer. Cela rend très difficile de créer des programmes "fiables" parce que ce qui fonctionne aujourd'hui peut ne plus marcher demain -sur la même machine et avec la même version de Windows!

RA et le DS évitent d'ajouter au problème en utilisant un fichier exécutable unique par programme. Pas de DLL, ni de hooks système ou de pilotes bas-niveau, donc pas de conflits.

De plus, l'API Windows n'est pas correctement documenté. Cette documentation contient des erreurs et des informations manquantes. Certaines fonctions sont documentées mais pas implémentées dans le compilateur C++ de Microsoft -ou l'inverse. Quand vous écrivez un programme pour Windows, vous devez faire avec les bugs:

       que vous pouvez créer (ils sont faciles à trouver et à corriger)
       du compilateur (difficiles à trouver et faciles à contourner, en ré-écrivant des fonctions)
       de la documentation de Microsoft (vous finissez avec votre propre version du MSDN)
       de toutes les différentes versions de Windows (difficile à isoler, à identifier et à résoudre)

La plupart des bugs de Windows sont difficiles à isoler parce qu'ils ne sont actifs que sur une ou deux des 16 versions 32-Bit de Windows. Un programmeur ne peut pas tester chaque nouvelle ligne de code sur 16 PC. Les programmeurs ne vivent pas assez longtemps pour cela. Un ingénieur de qualité peut faire ce travail mais personne n'est en mesure de vérifier toutes les fonctions d'un programme sur 400 PC comme il serait nécessaire de la faire pour être raisonnablement sûr que le programme est 'stable' sur une plate-forme aussi diverse que Windows.

Pas convaincu? Voyez par vous-même. Voici un extrait du code source de Microsoft Office Visual Basic:
(authentique)

Robuste? Sûr? Propre? Utile? Hmm... pas vraiment.

Qu'en pensent les développeurs chez Microsoft? Un mémo interne destiné à Bill Gates le 21 février 1997 nous le dit sans détours :

"L'API Windows est si large, si profonde, et si fonctionelle que la plupart des éditeurs de logiciels seraient fous de ne pas l'utiliser. Et elle est si profondément intégrée dans le code source d'un grand nombre d'applications Windows que les faire migrer sur un système d'exploitation different génèrerait d'énormes coûts. C'est le coût de cette migration qui a donné aux clents la patience de rester avec Windows malgré toutes nos erreus, nos pilotes bugués, notre TCO (coût de possession total) élevé, notre manque d'une vision séduisante parfois, et un grand nombre d'autres difficultés. Les clients évaluent constamment d'autres plate-formes d'ordinateurs de bureau, mais cela représenterait tellement de travail de changer qu'ils espèrent juste que nous améliorerons Windows plutôt que de les forcer à migrer. En bref, sans la franchise exclusive appelée Windows API, nous serions morts depuis longtemps." 

- Aaron Contorer, chef du développement en C++ chez Microsoft

Pourquoi Windows est-elle si frustrante -même pour les employés de Microsoft? Microsoft n'a jamais essayé de commercialiser de la technologie, ce qu'ils ont fait c'est appliquer à toute l'informatique une taxe très élevée. Aujourd'hui, Microsoft est si riche que même les gouvernements sont  incapables de faire appliquer les décisions de justice contre elle.

Le bon-sens suggère d'écrire du code pour une seule version de Windows. Mais avec une nouvelle version majeure (incompatible) de Windows tout les ans votre programme n'aurait aucune chance d'être un succès commercial. Comme l'a dit John Walker, fondateur et CEO d'Autodesk: "If you want to enter the Gates, you have to pay the Bill". Encore et encore, chaque année.

S'il vous plait aidez-nous. Lorsque vous avez un problème avec RA, lisez le manuel et les FAQ, et ne pensez pas que nous détestons Microsoft si nous disons qu'il s'agit d'un bug de Windows. C'est seulement un fait technique, pas une astuce que nous utilisons quand RA ne fonctionne pas comme prévu. Tout le monde doit admettre que Microsoft a été un contributeur majeur de l'industrie du logiciel -que vous aimiez la façon dont ils l'ont fait ou pas.

A TWD Industries, nous essayons juste de faire de ce monde un monde meilleur -pour tout le monde.