C'est plus qu'un simple habillage.
Sous Windows, pour qu'une application soit "portable" (terme très mal choisi, d'ailleurs), il faut au moins qu'elle ne fasse pas appel à la base de registres. Le terme portable est très mal choisi parce que portable signifie compilable pour différents systèmes d'exploitation.
La base de registre a été introduite avec :
- Windows NT 3.1 (la première vraie version 32 bits de Windows)
- Windows 95
(OS2, mais je n'en mettrais pas ma main au feu, mais comme le développement NT et OS2 a été simultané chez MS...)
Jusqu'à Windows 3.11 for workgroups (dernière version du Windows initial), les options et autres paramètres étaient enregistrés dans un fichier "ini" dans le dossier de l'application, mais il y avait également les fichiers system.ini et windows.ini qui pouvaient être utilisés. Dans les versions 32 bits, l'appel aux vieilles fonctions des fichiers "ini" se traduit par des échanges de données avec la base de registre.
C'est simplement un retour à ce mode de fonctionnement, et ça nécessite de disposer des sources, et de remplacer tous les appels aux fonctions base de registre par des équivalents écrivant, lisant et trouvant ces informations dans un fichier texte ou binaire. Je ne pense pas qu'on puisse intercepter à la volée ("hook") les fonctions de base de registre pour lire et écrire les informations dans un fichier.
L'API de la base de registres fournit des fonctions facilitant la programmation (très faciles à utiliser). Pour qu'une application soit "portable", il faut donc réécrire ces fontions ou utiliser une bibliothèque comme par exemple celle-ci :
http://www.codeproject.com/Articles/8342/CIniFile-Class-for-C-A-robust-cross-platform-INI-f . En effet, l'appel aux fonctions originelles dans des aplpllications 32 bits redirigera les appels vers la base de registre. Il y a donc du travail pour contourner ça !
D'autre part, celà dispense d'écrire un programme d'installation. Et surtout de désinstallation propre. la quasi totalité des programmeurs, même pour les poids lourds, ne désinstallent pas réellement les applications : ils laissent souvent des dossiers, des fichiers, des clés de registre et autres saletés un peu partout.
Ensuite et surout, très peu de programmes offrent la possibilité de sauvegarder de façon simple ses options. Il faut pour ça mettre les mains dans le cambouis, et sauvegarder / restaurer des clés de registre. Pourant, ça ne serait pas trop cassant de faire ça !
Exemple : pour Outlook (pas express...), si on ne veut pas se retaper le paramétrage des comptes à chaque installation d'un système, il faut sauvegarder / restaurer : [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook]
C'est très parlant !
La base de registre et les bibliothèques runtime ont été un progrès (espace et performances disque, mémoire, etc.), mais sont devenues une contrainte.
Pour ma part, mes applis sont "portables", et la première chose que je fais quand je génère un projet avec Visual C++, c'est de supprimer les lignes de code qui font appel à la base de registre. Ensuite, je linke les runtime sous forme statique, et non sous forme de DLL.
Mais tout ça est envisageable surtout pour de petites applis. En particulier, ça pose des problèmes de mise à jour des bibliothèques, ainsi que que des informations "ini" qui peuvent être très lourdes et peu performantes à cause des accés disque (la base de registre maintient un cache).
On voit mal des usines à gaz comme Solidworks stockant ses options dans un fichier texte, le tout sur une clé USB ! Bonjour les performances !
Le sujet ayant été abandonné par son initiateur sans autre forme de procès, le hors sujet ne lui nuira en rien... C'était bien la peine de faire des essais sur machine virtuelle !