Windows 7 - Où et comment puis-je stocker des données indépendantes de l'utilisateur de la machine?

Question

J'ai une application (c ++ 32 bits) sous XP que je dois adapter pour pouvoir fonctionner sous Windows 7 et Vista. Il doit stocker quelques dizaines d'octets de données indépendamment de l'utilisateur. Sous XP, j'ai stocké les données dans le registre sous HKEY_LOCAL_MACHINE \ Software. Lorsque j'exécute l'application sous Windows 7, les entrées de registre sont virtualisées et chaque utilisateur reçoit une copie distincte des données.

Le registre non virtualisé semble être un endroit logique pour les données mais je ne sais pas comment s'y prendre. Je remarque qu’il existe une multitude d’applications qui stockent des données à cet endroit; comment s'y prennent-ils?

Je suis également disposé à stocker les données ailleurs, existe-t-il un référentiel mondial bien connu pour cela? Un seul petit fichier est tout ce dont j'ai besoin.

Je suis plus ou moins au courant de l’ensemble des activités liées aux droits et aux privilèges, de sorte que toutes les astuces, indications, etc. sont très appréciées.

Answer 1

L'un des objectifs de conception de Windows 7 est d'isoler les données et les applications de l'utilisateur. Cela vise à améliorer la confidentialité, la sécurité et la personnalisation. En fait, les utilisateurs standard de Windows 7 ne peuvent pas modifier les données d’autres utilisateurs.

Les emplacements standard pour stocker les données d'application sont renvoyés par System.Environment.SpecialFolder énumération. Notez que tous les dossiers ne sont pas lisibles ou inscriptibles par tous les utilisateurs. Par exemple, CommonApplicationData est lisible par tous les utilisateurs, mais uniquement accessible en écriture par ceux qui ont une stratégie appropriée, comme Admins.

Si vous devez absolument disposer de données partagées par les utilisateurs, un administrateur ou un administrateur autorisé doit les installer sur un emplacement partagé. Si les utilisateurs doivent mettre à jour ces données, ils doivent les copier dans un emplacement où ils peuvent écrire, tels que ApplicationData, et mettre à jour leurs propres copies privées. Cette copie privée ne peut pas être modifiée par d'autres utilisateurs. Vous ne devez pas installer de données sur des emplacements partagés, sauf si votre application ne fonctionne pas autrement.

En fait, sous Win7, vous devez installer toutes les applications et les données dans les dossiers d’application et de données de l’utilisateur connecté, et non dans des emplacements partagés. Si plusieurs utilisateurs installent l'application, chaque utilisateur recevra sa propre copie de l'application et des données. C'est presque toujours ce que tu veux. Si plusieurs utilisateurs exécutent une application ou un jeu, vous ne voulez pas qu'un utilisateur change tout le monde. Si plusieurs utilisateurs ont réellement besoin du même changement, laissez chaque utilisateur mettre à jour sa copie privée quand il le souhaite. Si le compte d'un utilisateur est piraté ou s'il fait le mal, vous ne voulez pas qu'il détruise les applications et les données de tous les autres.

Sachez également que sous Win7, les utilisateurs peuvent se connecter à une machine à distance. Il est donc déconseillé de stocker des données spécifiques à la machine, telles que les résolutions d'écran ou les adresses IP, par utilisateur. Cochez plutôt cette option à chaque exécution de votre application.

Answer 2

IMHO, il est déraisonnable de penser que beaucoup de gens vont demander à des utilisateurs individuels d’installer leurs propres copies d’un progiciel. En fait, de nombreux paquets ne seront pas installés à moins d’être effectués sous ADMIN (ALLUSERS = 1). Si aucun moyen raisonnable de faciliter les installations à l'échelle du système à un niveau de protection inférieur à ADMIN n'est fourni, les installations de niveau ADMIN resteront la norme.

Par exemple, pourquoi certaines installations non-ADMIN utilisateur (avec privilèges intermédiaires) ne peuvent-elles pas créer de clés de registre dans une partie restreinte du registre (HKLM \ SOFTWARE \ package) et des répertoires dans ALL USERS \ APPLICATION DATA \ paquet?

J'ai décidé de créer un fichier ADMIN requis (ALLUSERS = 1) .msi et de créer des clés de registre avec une protection modifiée.

Answer 3

Ainsi, dans le cas où mon client dispose d’un poste de travail dédié, notre application (qui dérive des données d’un bon vieux fichier INI auquel nous reviendrons), notre message à son personnel informatique est qu’il va falloir installer le logiciel. sur la même machine pour chaque utilisateur qu'ils ont?

Nous devons lire / écrire dans (sous Windows 7 / Vista): Environment.GetFolderPath (Environment.SpecialFolder.CommonApplicationData) + @ "\ GoScan \ GoScan.ini"

mais comme les autres ont découvert que les autorisations pour un utilisateur typique ne suffisent pas pour r + w. Est-ce un "acceptable"? pratique de modifier les autorisations de répertoire / fichier après la fin du programme d'installation ou peut-être pendant l'installation (vous ne savez pas où procéder dans le projet d'installation de VS 2008).

-Paul