[WD17] Application conforme aux normes de l’UAC

Si vous développiez pour Windows XP, mais aussi pour Windows Vista ou 7 tout en ayant désactivé le contrôle de comptes utilisateur, il était possible d’installer vos applications de manière classique, sans intégrer un quelconque manifeste dans votre application. Cependant, il y a bel et bien des règles qui doivent être absolument appliquées puisque désormais sous Windows 8, il est impossible de totalement désactiver le contrôle des comptes utilisateur (sauf en bidouillant dans le registre).

Il y a donc quelques normes de programmation à adopter. En effet, lorsque le mécanisme de l’UAC est activé, et si l’application qui est installée ne possède pas de droits suffisants pour accéder à certains fichiers/dossiers ou éléments du registre, les services de virtualisation de l’UAC redirigent de manière transparente les écritures ainsi que les lectures vers des emplacements spécifiques accessibles de tous. Cependant, nous ne souhaitons pas que ce phénomène arrive : nous désirons que nos fichiers soient toujours enregistrés aux mêmes endroits.

Comme la documentation de PC SOFT l’indique, pour créer et modifier des fichiers sans avoir de privilèges administrateur, il faut ne pas écrire ni dans le répertoire “Windows” (cela inclut les sous-répertoires), ni dans le dossier “Program Files”, bien qu’on puisse au moins y installer les applications.

Par conséquent, il faut également adapter d’autres éléments :

  1. L’emplacement des fichiers HyperFileSQL Classic liés à votre application, si vous n’utilisez pas de serveur de base de données (ce répertoire peut être (re-)défini au déploiement de l’installation sur le poste client).
  2. L’emplacement des fichiers externes, comme des logs ou des paramètres (.ini), que vous interrogez avec les fonctions fXXX() ou même INILit/INIEcrit.
  3. L’installation recommandée est plutôt de type “exécutable auto-extractible”.

Écrire dans les répertoires et le registre

Notre application-exemple écrit des fichiers “log” au format texte et permet de lire (pas d’écrire) dans un fichier de paramètres (.ini) qui contient les informations de connexion à une base de données de type AS/400. Nous avons défini une classe qui contient des variables chaine pour stocker les dossiers “par défaut”.

Le premier répertoire est un dossier temporaire où l’on va écrire les fichiers “log” lorsqu’une erreur grave se produit dans notre application. Remarquez que nous utilisons la fonction “SysRep()” avec la constante “srAppDataCommun”. Sur un poste Windows Vista / 7 / 8, voici le chemin que cela renvoie :

Le second répertoire est celui de l’application, dans lequel nous allons simplement lire. La fonction “ExeInfo()” permet de récupérer le répertoire depuis lequel l’exécutable a été lancé. Il suffit de compléter celui-ci grâce à la fonction ”ComplèteRep()” qui retourne le nom donné avec le séparateur défini par la norme système.

Attention lorsque vous voulez interagir avec le registre

Si vous tentez d’écrire dans:

  • HKEY_LOCAL_MACHINE\Software

Cette opération sera redirigée vers:

  • HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE

Ceci explique pourquoi nous avons défini la clé de notre application en demandant d’écrire dans “HKEY_CURRENT_USER\Software”, qui reste accessible.

Exécutable et installation

Lorsque vous lancerez l’outil “Créer la procédure d’installation” depuis le menu “Atelier”, vous devrez configurer certains points dans les différentes étapes proposées. Par exemple, dans “Données et groupware”, vous devez sélectionner “Répertoire des données de l’application” puis indiquer si par défaut, les données sont installées dans un répertoire par utilisateur ou pour tous. Dans notre cas, nous choisirons la première option.

Lorsque vous arriverez à l’étape “Sécurité (1/2)”, il faudra bien demander à intégrer un manifeste “pour Windows Vista et Supérieur”. Cela ne s’applique donc pas si vous développez pour des postes encore sous Windows XP et inférieur. En cliquant sur “Suivant”, l’assistant vous proposera quatre choix : 3 manifestes de base et la possibilité d’en intégrer un personnalisé (format XML, fichier .manifest).

Dans notre cas, nous souhaitons que l’application utilise les privilèges maximum de l’utilisateur courant. Dans ce cas, l’application vous demandera une confirmation avant de se lancer. Si bien sûr, vous ne disposez quand même pas de privilèges suffisants, certaines opérations pourraient échouer. Cela convient bien si vous êtes déjà dans un compte de type “administrateur”.

Plus d’informations sur les manifestes : Manifests (Windows) (en)

Pour l’installation, nous avons choisi l’option “avec mise à jour automatique”, en réseau local. Arrivés à “Fichiers de l’installation”, nous avons choisi que le logiciel s’installerait dans un sous-répertoire de “Program Files” (ex : <srProgramFiles>\MonAppli, voir l’image ci-dessus).

Continuons ensuite jusqu’à l’étape “Données (1/4)” qui est elle aussi, très importante. Nous allons pouvoir définir l’emplacement par défaut des données HyperFileSQL Classic qui sera utilisé par l’application à l’exécution. Cochez donc la case “Configurer l’emplacement des fichiers de données de l’application”.

A l’étape “Paramétrage des connexions de données”, sélectionnez” “Emplacement par défaut” puis cliquez sur le bouton “Paramètre”. Cela ouvre une nouvelle fenêtre dans laquelle il faudra saisir les informations suivantes :

  • (…) en utilisant : cocher “Les valeurs indiquées ci-dessous”.
  • Type de connexion : HyperFileSQL Classic (ISAM).
  • Onglet “HFSQL Classic”, saisie du chemin de données. Exemple : <srAppDataCommun>\MonAppliDB

Et après?

Lorsque vous déployez votre application sur le poste client, les options sont configurables : emplacement des données HyperFileSQL, localisation des fichiers de l’exécutable. Ainsi, si vous installez sur une machine équipée de Windows XP, vous pouvez faire en sorte que le tout se retrouve dans “Program Files”, sans vous soucier des différentes lectures et écritures. Vous pouvez également adapter votre code en analysant la version de Windows s’exécutant sur la machine (des fonctions existent pour réaliser cette opération) afin d’effectuer un traitement X, Y ou Z.

Voir aussi : Normes de programmation sous Windows Vista et supérieur.

2 commentaires sur « [WD17] Application conforme aux normes de l’UAC »

  1. Bonjour,

    Ça fait toujours plaisir de trouver une explication Claire et pertinente.

    Merci d'avoir pris le temps d'avoir rédiger cette info.

    Thamis

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *