Il y a une demande croissante pour des logiciels portables, c'est-à-dire des logiciels que l'on copie sur une clé USB ou sur un disque dur externe, et que l'on peut ensuite transporter avec soi et brancher à volonté sur n'importe quel système matériel.
L'idée est vraiment intéressante, car c'est exactement l'idée inverse de celle dont rêvent toutes les grandes firmes informatiques qui voudraient nous imposer des systèmes n'ayant plus d'unités de stockage, pour que tout soit stocké sur leurs serveurs centralisés, et que nous devenions totalement dépendants de leurs services et de leurs réseaux.
Le logiciel portable permet à l'inverse de ne plus dépendre du tout du matériel, qui ne devient qu'un hôte pour notre unité de stockage portable, tout ce qui est important étant décentralisé auprès de l'utilisateur.
La première condition pour qu'un logiciel soit portable, c'est qu'il n'ait pas besoin d'inscrire des données dans le registre de
Windows. Certains disent qu'il ne doit pas avoir besoin d'installation. En réalité c'est seulement l'installation dans le registre de
Windows ou dans des dossiers fixes du système comme
c:\windows\system32 qui doit être prohibée. Si le logiciel a une procédure d'installation qui se contente de copier des fichiers sur l'unité de stockage portable, alors cela ne nuit pas à la portabilité. Par exemple, dézipper des fichiers. S'il écrivait par contre des données dans le registre de
Windows, il ne pourrait pas les transporter sur un autre ordinateur, et ne pourrait ainsi sans doute pas fonctionner sur son nouvel hôte.
Vous savez que mes logiciels n'ont pas besoin d'installation, autre que de dézipper le fichier exécutable. Ils respectent donc le 1er niveau de portabilité. Mais ils sauvent - du moins si vous l'acceptez - leurs préférences dans le registre. D'où le second niveau de portabilité à respecter: pouvoir retrouver ses préférences quel que soit le système sur lequel tourne la clé. Par exemple si vous avez un navigateur web, vous voudrez avoir toujours sous la main ses favoris. Ou si vous avez changé les couleurs dans
Filmerit, il faut que ces changements suivent le logiciel dans la clé usb.
J'avais tenu compte de cet objectif sur les dernières révisions de
DVdate,
Filmerit et
ImageGrab, en permettant à l'utilisateur de sauver ses préférences dans un fichier ini situé dans le même dossier que l'application, donc circulant avec cette dernière sur l'unité de stockage mobile.
Christophe qui travaille sur le projet
liberkey, une compilation de logiciels portables gratuits que l'on peut copier sur une clé usb, me signale que cela n'est pas encore suffisant.
En effet, dans les préférences, il y a parfois l'indication d'un dossier, ou d'un fichier utilisables par le logiciel. Par exemple dans
DVdate, les préférences comprennent:
- le dossier par défaut pour ouvrir des vidéos
- le dossier préféré ouvert par F7
- le dossier par défaut pour ouvrir les playlist
- le dossier pour les fichiers créés par conversion
- l'emplacement du fichier imagegrab
- l'emplacement de deux fichiers à lancer par F3 ou F4
Enfin, de manière moins voyante, sous le nom
exename, les préférences sauvent aussi l'adresse de l'application. C'est utile pour que mes programmes puissent s'appeler l'un l'autre, en sachant où chacun a été copié.
Supposons maintenant que le fichier
imagegrab soit sur la même clé usb que
DVdate, sous le chemin
e:\image\imagegrab.exe. Ce fichier
e:\image\imagegrab.exe sera noté dans le fichier ini. Or au prochain lancement, la clé sera peut-être implantée sur un autre ordinateur et aura hérité de la lettre de lecteur
F:\. Alors
DVdate aura un problème car il cherchera
imagegrab.exe dans le dossier
e:\image\ qui n'existe pas, et qui est devenu le dossier
f:\image\.
Christophe me demande d'en tenir compte dans mes logiciels, en sauvant des chemins relatifs au lieu de sauver des chemins absolus. C'est ce qu'on pourrait appeler une précaution de troisième niveau.
Cela me pose deux difficultés: d'abord une difficulté de programmation, car pour saisir des chemins j'utilise des composants de
delphi qui ne fonctionnent qu'en chemin absolu.
Ensuite une difficulté de fond: pour un logiciel qui traite de vidéo numérique, il faut manipuler de très gros fichiers. Il y a donc peu de chances que le dossier où chercher ces très gros fichiers soit sur une clé usb. En revanche, il pourrait très bien être sur un disque dur externe. Dans le premier cas, il est donc inutile de transcrire son adresse en relatif, alors que dans le second cas, il faudrait y procéder. Comment faire la différence?
J'ai mis au point la solution suivante pour contourner ces difficultés, et compte l'implanter dès la prochaine révision de mes logiciels:
D'abord l'utilisateur devra indiquer s'il veut que sa version soit portable (donc enregistre ses préférences dans un fichier ini situé dans le même dossier que l'application) ou s'il veut que sa version soit normale (et enregistre ses préférences dans le registre).
S'il est dans le premier cas, au prochain lancement, le programme regardera quelle était la lettre du périphérique dans l'exécutable indiqué sous
exename. C'était la lettre de l'unité usb ou disque dur externe, par exemple
E:\. Ensuite il regarde quelle est la lettre actuelle du périphérique sur lequel se trouve l'application (qui par définition est considéré comme une unité de stockage portable). Par exemple
F:\.
Chaque fois que dans les préférences apparaîtra un dossier ou le chemin d'un fichier commençant par la première lettre (
E:\), on corrigera cette lettre en la remplaçant par la seconde (
F:\).
De cette manière, toutes les références qui pointaient vers la clé usb (ou le disque dur externe) continueront à pointer vers la clé usb (ou le disque dur externe). Pour autant, l'utilisateur n'a absolument besoin de se préoccuper de rien, il ne verra que des chemins absolus et non relatifs, et le programme n'écrira dans le fichier ini que des chemins absolus et non relatifs. C'est
DVdate qui saura relativiser tout cela au lancement.
Si Christophe lit ce billet, il me dira peut-être qu'il faut assurer un quatrième niveau de portabilité: en effet, il ne lui aura pas échappé que
DVdate peut sauver l'adresse d'une playlist. Avec ma technique de 3ème niveau, si l'utilisateur prend soin de sauver la playlist dans un dossier qui figure sur la clé usb, alors
DVdate pointera toujours vers ce dossier, même si la clé a été déplacée sur un autre système. Par contre, le fichier
playlist.txt ainsi pointé, liste lui-même des fichiers vidéo, dont certains pouvaient être sur la clé usb. Si j'étais rigoriste, je devrais donc aussi corriger ces fichiers en changeant leur périphérique
E:\ en
F:\.
Je ne suis sans doute pas assez rigoriste en matière de portabilité pour aller aussi loin, car au fond je crois que ce n'est pas utile, et compliquerait les opérations de
DVdate. Par contre, si je trouvais un mécanisme simple et automatique pour imposer toutes les corrections de
E:\ vers
F:\au fur et à mesure que l'on veut utiliser un fichier ou un dossier, sans devoir les lister a priori, je n'hésiterai pas à l'implanter.
En attendant, vous pouvez tester la clé
liberkey sur laquelle vous trouverez
Filmerit, en version 3.0.8, donc avec une portabilité de niveau 2 pour reprendre l'échelle ci-dessus. Et ne ratez pas la prochaine version 6.4.0 de
DVdate, qui devrait avoir la portabilité de niveau 3.
