I ate my computer

Pas tous les jours facile de vouloir proposer le meilleur quand la technologie n'aide pas.

Que faire lorsque l'on souhaite proposer une application aboutie, intégrer le mieux possible au système d'exploitation, mais qu'au final, suivant la technologie utilisée, l'accès au fonctionnalité est limité ?

Et bien on retrousse ses manches et on plonge les mains dans le cambouis. On ne va pas lister ici toutes les manières possible de développer une application sous Windows, mais prenons par exemple les deux plus répandu (il me semble), à savoir utiliser l'API Win32 ou le Framework .NET. L'un possède un nombre inimaginable d'API (100 000 parait il, mais je ne retrouve plus ma source), mais est beaucoup plus complexe à utiliser, l'autre est du simplicité déconcertante, mais se retrouve limité dès qu'il s'agit de toucher aux fonctionnalités de l'OS, ou de sortir des sentiers battus.

Petit exemple, il peut être fort intéressant pour une application de faire appel au système d'association de fichier, pour faire en sorte que celle-ci ouvre par défaut certaines extensions. Malheureusement l'API qui permet cela n'existe qu'en Win32, il n'y a pas d'équivalent .NET. Dommage. Un développeur .NET peu scrupuleux, ira donc forcer l'association de fichiers sans passer par les API, en allant directement fouiller dans la base de registre, et si celui-ci ne prend pas le temps de le faire bien, l'application pourra avoir un comportement désagréable pour l'utilisateur. Pareil, vous souhaitez afficher les icônes de fichiers dans votre application à la manière de l'explorateur windows ? Et bien je vous conseil de vous accrocher. Vous ne trouverez dans .NET que les icônes stocker dans les fichiers (donc en général les .exe), via la méthode ExtractAssociatedIcon, pour ceux stocker dans Windows, il faudra repasser. Pour plus d'info vous pouvez par exemple regarder ce post de Brad Smith sur comment construire une meilleur version de cette methode .

Bref, il y en a encore d'autre, il serait trop long de toutes les lister. Ce que je regrette c'est que Microsoft ne mette pas plus l'accent sur l'uniformisation de ses API. Il est clair que Windows étant codé en C/C++ les API sont en premiers faite pour Win32, et que porter toutes ces API vers .NET ne se fait pas en 15 jours. Mais même le minimum n'est pas fait. Il me semble que la moindre des choses serait que lors de la sortie d'une nouvelle version de Windows, les nouvelles fonctionnalités soit ajoutés en même temps à .NET. Et non pas via une DLL téléchargeable sur MSDN, et à peine maintenue.

Je comprend en tout cas mieux pourquoi il est si difficile de trouver de bonne application .NET, utilisant une majorité des API liés à l'OS de façon cohérente. Microsoft n'utilisant pas vraiment cette technologie dans ses propres projets. Le vent tourne légèrement depuis que Visual Studio utilise WPF pour son interface, et donc .NET, on a pu voir quelques améliorations, malheureusement nous ne somme pas encore à égalité avec les développeurs Win32.