L'étrange amour d'un développeur, ou : comment j'ai appris à ne plus m'en faire et à aimer Windows

1. La conclusion, d’abord

Quand on développe des applications Windows, il y a beaucoup de raisons de s’inquiéter.

Est-ce que ça démarrera sur ce PC ? Est-ce que ça fonctionnera dans un environnement sans droits administrateur ? Est-ce que la différence 32 bits / 64 bits va tout casser ? Chemins en japonais, chemins longs, lecteurs réseau, vieilles DLL, composants COM, ActiveX, imprimantes, communication série, antivirus, Windows Update.

Dès qu’on commence à y penser, les inquiétudes ne s’arrêtent plus.

Mais à un moment donné, j’ai commencé à voir les choses autrement.

Et si ce n’était pas un défaut, mais la preuve que Windows a porté sur ses épaules des activités professionnelles bien réelles ?

Windows n’est pas une utopie immaculée. Mais il porte en lui les logiciels, les équipements, les flux de travail et les habitudes humaines qui tournent sur le terrain depuis des décennies.

Ce chaos-là est précisément ce qui rend Windows intéressant, et ce qui, pour un développeur, mérite qu’on s’y confronte.

2. Le développement d’applications Windows est source de nombreuses inquiétudes

Dans le développement d’applications Windows, il ne suffit pas que « le code soit correct ».

Ça fonctionne en environnement local. Ça fonctionne sur le poste du développeur. Ça fonctionne même sur la VM de validation.

Et pourtant, rien ne garantit que ça fonctionnera sur le PC du client.

Par exemple, voici ce qui peut arriver :

• Une DLL est introuvable
• Le runtime Visual C++ n’est pas installé
• La version du .NET Framework ne correspond pas
• Le chargement d’une DLL 32 bits depuis un processus 64 bits échoue
• L’enregistrement COM est corrompu
• On confond les versions 32 bits et 64 bits de regsvr32.exe
• Du code qui suppose un répertoire courant fixe se casse sous le Planificateur de tâches
• Une tentative d’écriture sous Program Files déclenche une erreur de droits
• AppData\Roaming et AppData\Local sont utilisés à l’envers
• Ça plante avec un nom d’utilisateur ou un nom de dossier en japonais
• Impossible d’ouvrir un fichier à cause d’un chemin trop long
• Ça marche sur un lecteur réseau mappé mais pas via un chemin UNC
• L’affichage se casse dans les environnements à haute densité de pixels (DPI)
• Les calculs de coordonnées se décalent sur plusieurs moniteurs
• Le résultat d’impression varie selon le pilote d’imprimante
• Les périphériques USB, caméras, instruments de mesure et communications série ne sont pas reconnus selon l’environnement
• L’antivirus bloque une partie du traitement
• Le comportement change après une mise à jour Windows

Dressée ainsi, la liste donne un peu le vertige.

Les problèmes qu’une application web confine entre le navigateur et le serveur se propagent, dans une application Windows, à l’ensemble du PC. Système de fichiers, base de registre, profils utilisateurs, imprimantes, périphériques, réseau, stratégies de sécurité, programmes d’installation, runtimes.

L’application ne se contente pas de « tourner sur l’OS » : elle est posée en plein cœur d’un environnement de travail bien réel.

C’est pour cela que le développement d’applications Windows est difficile. Mais je pense qu’écarter tout ça d’un simple « Windows, c’est nul » manque la cible.

Ce qui repose là-dessus, c’est la complexité du monde réel.

3. Windows est l’OS du terrain

Windows n’est pas un système d’exploitation qui n’existe que pour les dernières technologies.

Usines, hôpitaux, administrations, écoles, laboratoires, diffusion audiovisuelle, équipements d’inspection, bornes d’accueil, terminaux d’édition de documents, entrepôts, commerces, comptabilité, paie, gestion des stocks. Dans tous ces endroits, d’innombrables PC Windows tournent encore aujourd’hui.

On n’y trouve pas seulement les derniers services web.

Il y a des macros Excel. Il y a Access. Il y a de vieilles applications VB. Il y a des applications métier sous .NET Framework. Il y a des applications résidentes écrites en C++. Il y a des composants COM. Il y a de l’ActiveX. Il y a des connexions ODBC. Il y a des pilotes d’imprimante. Il y a des lecteurs de codes-barres. Il y a des instruments de mesure en communication série. Il y a des SDK fournis par des fabricants.

Et rien de tout cela n’existe isolément.

Des personnes les utilisent, impriment des documents, changent des périphériques USB, déposent des fichiers CSV dans des dossiers partagés ; des traitements de nuit s’exécutent, et le lendemain matin le travail reprend. Tout cela fonctionne au sein de cet enchaînement continu.

Windows n’est pas simplement un socle pour lancer des applications. C’est une plateforme qui absorbe le travail quotidien du terrain, les actifs existants, les périphériques, et jusqu’aux habitudes des personnes.

C’est pour cela qu’il paraît parfois vieux. Parfois compliqué. Parfois on se demande pourquoi telle ou telle chose existe encore.

Mais cela signifie aussi qu’on n’y a jamais jeté le vieux sans égard.

4. La rétrocompatibilité, une forme d’amour

Si l’on voulait seulement rendre un OS beau, il serait plus simple de couper les vieux mécanismes.

Supprimer les anciennes API. Supprimer les anciens runtimes. Supprimer les anciens écrans de paramétrage. Considérer que les anciennes applications ne fonctionnent tout simplement plus.

En faisant cela, le design serait peut-être plus épuré. La documentation serait peut-être plus courte. Les développeurs se sentiraient peut-être un peu plus légers.

Mais derrière tout ça, il y aurait des applications métier qui cesseraient de fonctionner. Des équipements qui s’arrêteraient. Des sites qui se retrouveraient en difficulté.

La rétrocompatibilité de Windows est, techniquement, une vraie contrainte. Il y a WOW64, pour faire tourner des applications 32 bits sur un Windows 64 bits. La base de registre et les DLL peuvent apparaître différemment selon qu’on est en code 32 bits ou 64 bits. Il y a cette structure — déroutante au premier abord — où C:\Windows\System32 correspond au côté 64 bits et C:\Windows\SysWOW64 au côté 32 bits.

COM aussi est contraignant. Déposer la DLL ne suffit pas ; un enregistrement peut être nécessaire. L’enregistrement se fait-il par utilisateur ou par machine ? S’agit-il de COM 32 bits ou 64 bits ? Faut-il des droits administrateur ?

Le .NET Framework, c’est pareil. Aujourd’hui, on peut choisir d’utiliser un .NET moderne comme .NET 8 ou .NET 9. Mais sur le terrain, des applications en .NET Framework 4.x existent encore. Ce n’est pas simplement de l’ancienneté : cela signifie que cette version a porté une activité réelle pendant de longues années.

La rétrocompatibilité n’est pas un concept simplement beau. C’est plutôt une lourde responsabilité.

Faire tourner de vieilles choses, c’est porter une dette technique. Mais c’est aussi, en même temps, une forme d’intégrité : celle de ne pas interrompre l’activité des utilisateurs.

C’est là, je crois, que se trouve ce qu’il y a d’aimable chez Windows.

5. Windows est un OS fait de strates géologiques

Dans Windows, les technologies de chaque époque se sont accumulées comme des strates géologiques.

Win32. COM. ActiveX. Windows Forms. WPF. .NET Framework. UWP. WinUI. Windows App SDK. MSIX. PowerShell. Windows Terminal. WSL.

Chacune a eu son époque d’apparition, ses points forts, et les terrains où elle a été utilisée.

À ne regarder que le neuf, l’ancien peut sembler encombrant. Mais dans le développement d’applications Windows, il y a souvent des situations où l’on ne peut pas ignorer les strates les plus anciennes.

Par exemple, même en construisant une application WPF, l’impression peut vous ramener à des problèmes de GDI et de pilotes d’imprimante. Même en écrivant en C#, si le SDK d’un fournisseur est une DLL native, on touche à P/Invoke et aux problèmes de bitness. Même en construisant de nouveaux écrans, il faut parfois conserver des composants COM existants ou une intégration Excel.

Windows n’est pas un jardin parfaitement ordonné. Il ressemble plutôt à une immense ville sans cesse agrandie et reconstruite.

Il y a de grands boulevards. Il y a des passages souterrains. Il y a de vieilles ruelles. Il y a de nouvelles tours.

On s’y perd facilement. Mais au fond de ces ruelles, une activité importante tourne encore aujourd’hui.

Ce dont un développeur a besoin, ce n’est pas de juger que « ancien veut dire inutile ». C’est de discerner quelle strate technologique porte quelle activité.

6. Transformer la contrainte en conception

Le titre parle de « ne plus m’en faire ».

Mais ne plus s’en faire ne signifie pas devenir négligent. Cela ne signifie pas non plus fermer les yeux sur les problèmes.

Ne plus s’en faire, c’est transformer l’inquiétude en conception.

Par exemple, si l’on doute que l’application démarre, on transforme la vérification du démarrage en test de fumée (smoke test).

Start-Process .\MyApp.exe

Et on ne se contente pas de vérifier le démarrage : on teste aussi sans fichier de configuration, sans dossier de logs, avec des droits utilisateur standard, sans connexion réseau, sans imprimante configurée, en haute densité de pixels, avec des chemins longs et des chemins en japonais.

Si les DLL inquiètent, on vérifie les dépendances. Si le runtime Visual C++ est nécessaire, on décide de l’inclure dans le programme d’installation ou de le documenter explicitement comme prérequis. Si l’on utilise des DLL natives, on ne laisse pas la relation x86 / x64 / AnyCPU dans le flou.

Si COM inquiète, on consigne la procédure d’enregistrement dans un mode opératoire et on la reproduit intégralement sur un PC de test.

# Exemple : enregistrement d'une DLL COM 64 bits
C:\Windows\System32\regsvr32.exe .\SomeComponent64.dll

# Exemple : enregistrement d'une DLL COM 32 bits
C:\Windows\SysWOW64\regsvr32.exe .\SomeComponent32.dll

Si les droits inquiètent, on évite les conceptions qui ne fonctionnent qu’avec des droits administrateur. On place les paramètres par utilisateur dans AppData, et les paramètres pour toute la machine dans ProgramData. On évite les conceptions qui écrivent des logs sous Program Files.

Si les chemins inquiètent, on intègre aux tests le japonais, les espaces, les noms de dossiers longs et les chemins UNC.

New-Item -ItemType Directory -Path "C:\テスト 用\とても長いフォルダー名\さらに深いフォルダー" -Force

Si le DPI inquiète, on vérifie à 100 %, 125 %, 150 % et 200 %. Sur plusieurs moniteurs, on vérifie que rien ne se casse en passant d’un écran à un autre avec une mise à l’échelle différente. WinForms, WPF et WinUI n’abordant pas le DPI de la même façon, on vérifie séparément selon la technologie d’interface.

Si la mémoire ou les handles inquiètent, on utilise Application Verifier, WinDbg, ProcDump, Process Explorer, et autres outils similaires. Si les plantages inquiètent, on conserve les journaux d’événements, les dumps et les journaux d’application.

Get-EventLog -LogName Application -Newest 20

Ou, dans des environnements plus récents, on consulte le journal des événements ainsi :

Get-WinEvent -LogName Application -MaxEvents 20

Si des anomalies qui ne se reproduisent pas sur le terrain inquiètent, on augmente la granularité des journaux. « Une erreur s’est produite » ne suffit pas. Quel fichier essayait-on d’ouvrir ? Quel périphérique était recherché ? Sous quel utilisateur l’exécution avait-elle lieu ? Dans quel chemin essayait-on d’écrire ? Quelle DLL n’a-t-on pas pu charger ?

Transformer l’inquiétude en quelque chose d’observable.

C’est, dans le développement d’applications Windows, un point extrêmement important.

7. « Ça fonctionne sur le PC du client » est l’objectif final

Que ça fonctionne en environnement de développement, c’est important. Que les tests passent en intégration continue, c’est important. Que ça fonctionne sur une VM propre, c’est important.

Mais pour une application Windows, l’obstacle final, c’est toujours : « est-ce que ça fonctionne sur le PC du client ? »

Sur ce PC, quelque chose est déjà installé. Il y a peut-être un vieux pilote d’imprimante. Il y a peut-être un logiciel de sécurité propriétaire. Des lecteurs réseau sont peut-être mappés. L’utilisateur n’a peut-être pas de droits administrateur. Il y a peut-être des raisons pour lesquelles Windows Update ne peut pas être appliqué immédiatement. C’est peut-être un environnement sans accès à Internet.

C’est pourquoi la méthode de distribution compte aussi.

Suffit-il de fournir un simple exe ? Faut-il un MSI ? ClickOnce ? MSIX ? Peut-on distribuer via winget ? Faut-il passer par un système de distribution interne ? Un programme d’installation hors ligne est-il nécessaire ? La signature de code est-elle requise ? SmartScreen ou l’antivirus vont-ils bloquer l’application ?

Ce n’est qu’en incluant, au-delà de l’application elle-même, l’installation, la mise à jour, la désinstallation, la collecte des journaux et les procédures de restauration que l’on se rapproche vraiment d’un état « utilisable sur le terrain ».

Dans le développement d’applications Windows, le logiciel n’est pas terminé à la livraison. Il doit démarrer chez le client, aujourd’hui comme demain.

8. Pourquoi j’aime quand même Windows

Windows a ses aspects contraignants. C’est un fait.

Les DLL. COM. La base de registre. L’UAC. Le DPI. Les imprimantes. Les runtimes. Le 32 bits / 64 bits. Les lecteurs réseau. Les chemins longs. Les environnements en japonais. Les logiciels de sécurité. Windows Update.

À énumérer les contraintes, on n’en finit plus.

Mais une grande partie de cette contrainte vient du fait que Windows porte depuis très longtemps une activité professionnelle bien réelle.

Il n’abandonne pas les anciens actifs tout en intégrant les nouvelles technologies ; il possède une interface graphique comme une ligne de commande ; il accueille aussi bien les applications locales que le web, les périphériques que les terminaux métier, les PC personnels que les PC d’entreprise.

Ce n’est pas une belle philosophie unique.

Mais c’est solide.

Et, pour un développeur, cela vaut la peine de s’y confronter.

Construire un logiciel qui fonctionne de façon fiable sur Windows, ce n’est pas simplement appeler des API. C’est lire les contraintes du terrain, comprendre les actifs existants, repérer les points fragiles, tester, observer, et corriger ce qui doit l’être.

C’est un travail discret. Mais il a de la valeur.

9. Conclusion

Dans le développement d’applications Windows, les inquiétudes ne tarissent jamais.

Mais une grande partie de ces inquiétudes est aussi le résultat du fait que Windows, en tant qu’OS, a absorbé pendant très longtemps une activité professionnelle réelle, des terrains réels, des équipements réels, des gestes humains réels.

C’est pourquoi je ne considère pas Windows comme un simple vieux système d’exploitation.

C’est une plateforme immense, complexe et un peu maladroite, qui a continué de tourner en composant avec la réalité.

Et construire un logiciel qui fonctionne de façon fiable sur cette base a encore aujourd’hui une grande valeur.

Arrêter de s’en faire.

Mais cela ne veut pas dire baisser la garde.

Transformer l’inquiétude en conception, en tests et en observation.

C’est ainsi que, petit à petit, j’en suis venu à aimer Windows.

Liens de référence

• Application Verifier - Overview - Microsoft Learn
• High DPI Desktop Application Development on Windows - Microsoft Learn
• Setting the default DPI awareness for a process - Microsoft Learn
• Running 32-bit Applications - Microsoft Learn
• Maximum Path Length Limitation - Microsoft Learn
• MSIX documentation - Microsoft Learn
• Version compatibility in .NET Framework - Microsoft Learn

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.