Hello world à tous !

Voilà presque un an que je travaille en pointillé sur ce projet. ClipboardZanager, le gestionnaire de presse-papiers que je maintiens depuis 2010 a le droit à un nouveau visage tout beau tout propre après 3 ans sans nouvelles.

Quoi de neuf?

Voici avant tout un résumé des nouveautés :

  1. Inspiré par Windows 10 pour Windows 10
    Une toute nouvelle interface qui s’adapte au nombre et à la taille de vos écrans et aux paramètres de personnalisation de Windows. L’interface adapte sa couleur et transparence en fonction de ce que vous avez définit dans vos paramètres.
  2. Sécurité améliorée
    Un procédé de chiffrement similaire à celui de PasszordZanager a été utilisé. L’application peut éviter automatiquement de conserver des données dangereuses telle que des numéros de carte de crédit. Enfin, vous pouvez choisir une application dont ClipboardZanager doit ignorer les données copiées.
  3. Synchronisation avec le Cloud
    Il est (de nouveau) possible de synchroniser ses données avec le Cloud via son compte OneDrive ou Dropbox personnel. Une application Android et iOS sont en cours de développement.
  4. Accessibilité
    Cette nouvelle version a été conçu pour supporter la navigation intégralement au clavier, les lecteurs d’écrans et le contraste élevé.
  5. Performances
    Une grande amélioration a été apportée. Au repos, ClipboardZanager consomme moins de 3Mo de RAM (comparé à 45 avant) et monte jusqu’à 75Mo lors que l’on réalise une capture d’écran (contre environ 500Mo à 1Go auparavant).
  6. Licence
    ClipboardZanager est désormais OpenSource sous licence WTFPL (Do What The Fuck You Want Public License). J’en profite pour annoncer que je cherche des traducteurs et développeurs Android/iOS qui voudraient bien contribuer. 🙂

Plus d’informations sur le site internet de ClipboardZanager : clipboardzanager.velersoftware.com

Aspect technique

Ce projet m’a donné quelques challenges à surmonter.

Tout d’abord, la gestion des écrans. J’ai voulu faire en sorte que la barre de collage (la barre horizontal qui s’affiche en haut… ou en bas maintenant… de l’écran) se positionne automatiquement sur l’écran où se trouve la souris. Pas de soucis, il suffit probablement de récupérer la résolution des écrans et de calculer la taille et les coordonnées. Mais quand je me suis plongé réellement dans le problème, je me suis rendu compte que selon le zoom de l’écran principal, les coordonnées et la taille des autres écrans retournées par les API de Windows étaient bien différentes de ce que l’utilisateur final voyait dans les paramètres du système.

Bref, j’avais écrit un article qui décrivait le problème en détail avec la solution technique trouvée.

Le deuxième défi technique a été la gestion du presse-papiers en lui-même. Je vais dire les choses comme elles sont : le presse-papiers sous Windows, c’est un galère ! (dixit certains collègues qui ont été dans les équipes Windows à Microsoft auparavant) Dès que l’on veut exploiter autre chose que du texte et des fichiers, ça devient mission impossible avec des formats particuliers difficiles à exploiter. C’est le cas des images par exemple.
Les anciennes versions de ClipboardZanager utilisaient l’API .Net pour récupérer une image du presse-papiers. Seulement cette API récupère l’image intégrale et nous la renvoie sous la forme d’un seul objet. Problème : dans le cas d’une capture d’écran avec une haute résolution, l’objet qui était retourné par l’API pouvait prendre jusqu’à 1Go de RAM dans certains scénarios, ce qui n’est pas acceptable.

Après de nombreuses recherches sans résultat sur internet pour trouver une solution moins coûteuse en ressource, j’ai décidé d’explorer les codes sources du .Net Framework afin de comprendre comment l’API fonctionne.
J’ai finalement compris que le Framework utilise un ensemble d’APIs bas niveau de Windows qui sont documentées sur internet mais pour certaines jamais exploitée de cette manière sur StackOverflow. Grâce à 3 jours de Reverse Engineering à essayer d’isoler l’intégralité de l’API du presse-papiers du Framework dans un projet console puis d’écrire mon propre système en utilisant ces APIs bas niveaux, j’ai réussi à faire en sorte de lire toutes les données petit à petit, bloque par bloque et de les chiffrer au fur et à mesure pour les sauvegarder sur le disque dur (de cette manière la RAM n’augmente presque pas).

Le dernier défi mais qui reste le plus simple des trois a été de pouvoir récupérer l’icône de l’application à partir de laquelle on a copié une donnée. Pour cela, on doit dans l’ordre :

  1. Récupérer le Handle de la fenêtre active à l’écran.
  2. Récupérer le Handle du processus associé.
  3. Avec ça, on peut détecter si l’application est Win32 ou UWP.
  4. Si c’est Win32, on récupère l’icône associé à la fenêtre. Si on la considère trop petite, on récupère l’icône du .EXE.
  5. Si c’est une application universelle, on récupère l’ID du package associé à la fenêtre, et on récupère l’icône du package (l’icône de l’application dans le Store).

Et tout ça sans jamais demander les droits administrateurs !

Si tout cela vous intéresse, à votre tour de faire du Reverse Engineering et de comprendre comment j’ai fait ça en explorant les codes sources de ClipboardZanager. 😉

A bientôt !