2009-11-27 4 views
5

Ho un'app (32 bit C++) in esecuzione in XP che devo adattare per funzionare con Windows 7 e Vista. Ha bisogno di memorizzare alcune dozzine di byte di dati in qualche posto indipendente dall'utente. Sotto XP, ho archiviato i dati nel registro sotto HKEY_LOCAL_MACHINE \ Software. Quando eseguo l'app su Windows 7, le voci del registro sono virtualizzate e ogni utente riceve una copia separata dei dati.windows 7 - dove e come posso memorizzare dati indipendenti dell'utente della macchina?

Il registro non virtualizzato sembra un luogo logico per i dati, ma non ho idea di come procedere. Prendo atto che ci sono una moltitudine di applicazioni che effettivamente memorizzano i dati lì; come fanno a farlo?

Sono anche disposto a memorizzare i dati in cui è presente un repository globale ben noto? Un solo piccolo file è tutto ciò di cui ho bisogno.

Sono più o meno ignorante dell'intera gestione dei diritti/privilegi, quindi qualsiasi suggerimento, suggerimento, ecc. È molto apprezzato.

+0

Potrebbe fornire ulteriori informazioni su questi dati? Viene scritto una volta durante l'installazione e non cambia mai in seguito? Potrebbe cambiare ogni volta che viene eseguita l'applicazione? – reuben

+0

@Ruben: Attualmente è inizialmente creato alla prima esecuzione e aggiornato molto raramente probabilmente solo poche volte. Potrebbe essere inizializzato all'installazione ma dovrebbe essere aggiornato in seguito. –

+0

Perché è necessario essere indipendenti dall'utente? Perché ogni utente che ha una propria copia è cattivo? –

risposta

2

Uno degli obiettivi di progettazione di Windows 7 è l'isolamento dei dati utente e delle applicazioni. Questo per migliorare la privacy, la sicurezza e la personalizzazione. In effetti, gli utenti standard in Win 7 non possono modificare i dati di altri utenti.

Le posizioni standard per la memorizzazione dei dati dell'applicazione vengono restituite dall'enumerazione System.Environment.SpecialFolder. Nota che non tutte le cartelle sono leggibili o scrivibili da tutti gli utenti. Ad esempio, CommonApplicationData è leggibile da tutti gli utenti, ma solo scrivibile da quelli con una politica appropriata, come gli amministratori.

Se è assolutamente necessario disporre di dati condivisi tra gli utenti, un Amministratore o uno con autorizzazione deve installarlo in un percorso condiviso. Se gli utenti devono aggiornare questi dati, devono copiarli in una posizione in cui possono scrivere, ad esempio ApplicationData, e aggiornare le proprie copie private. Questa copia privata non può essere modificata da altri utenti. Non installare i dati in posizioni condivise a meno che l'applicazione non funzioni diversamente.

Infatti, in Win7 è necessario installare tutte le applicazioni e i dati nelle cartelle dell'applicazione e dei dati dell'utente connesso, non nelle posizioni condivise. Se più utenti installano l'applicazione, ogni utente riceverà la propria copia dell'applicazione e dei dati. Questo è quasi sempre quello che vuoi. Se più utenti eseguono un'applicazione o un gioco, non si desidera che un utente modifichi tutti gli altri. Se più utenti hanno davvero bisogno della stessa modifica, lascia che ogni utente aggiorni la propria copia privata quando ne ha bisogno. Se l'account di un utente viene violato o diventa malvagio, non vuoi che distrugga le applicazioni e i dati di tutti gli altri.

Inoltre, in Win7, gli utenti possono accedere a una macchina da remoto, quindi non è una buona idea memorizzare dati specifici della macchina, come risoluzioni dello schermo o indirizzi IP, dall'utente. Invece, controlla questo ogni volta che viene eseguita la tua app.

+1

In realtà, l'approccio raccomandato nella guida alla certificazione di Vista per il caso in cui sono necessari dati condivisi scrivibili, è per il programma di installazione dell'applicazione per creare una cartella in CommonApplicationData e impostare le sue autorizzazioni di conseguenza (cioè scrivibile in tutto il mondo). –

+0

... il che significa che non vi è alcun divieto di dati scrivibili condivisi o qualcosa del genere. È volutamente non banale da fare, ma non è impossibile, e ci sono casi d'uso validi. –

+0

Buon commento Pavel; non è impossibile ma sostengo il suggerimento che non dovresti farlo. –

0

IMHO, è irragionevole pensare che molte persone stiano andando avere singoli utenti che installano le proprie copie di un pacchetto software. In effetti molti pacchetti non verranno installati a meno che non vengano eseguiti in ADMIN (ALLUSERS = 1). Se non sono forniti mezzi ragionevoli per facilitare installazioni di sistema a un livello di protezione inferiore a quello di ADMIN, le installazioni di livello ADMIN rimarranno la norma.

Ad esempio, perché non è possibile che alcune installazioni di utenti non ADMIN (con privilegi intermedi) consentano di creare chiavi del Registro di sistema in alcune parti del registro (HKLM \ SOFTWARE \ pacchetto) e directory in TUTTI GLI UTENTI \ DATI DELL'APPLICAZIONE \pacchetto?

Ho deciso di rendere necessario un AMM (ALLUSERS = 1) .msi e creare chiavi di registro con protezione modificata.

0

Quindi, in una situazione in cui il mio cliente ha una stazione di lavoro dedicata, la nostra applicazione (che ricava i dati da un buon vecchio file INI che andremo a +) al nostro messaggio al personale IT è che dovranno installarlo sulla stessa macchina per ogni utente che hanno?

abbiamo bisogno di leggere/scrivere (sotto Windows 7/Vista): Environment.GetFolderPath (Environment.SpecialFolder.CommonApplicationData) + @ "\ GoScan \ GoScan.ini"

ma come le altre sono scoperto le autorizzazioni per un utente tipico non sono sufficienti per r + w. È una pratica "accettabile" cambiare le autorizzazioni di directory/file dopo che l'installer è stato fatto o forse durante l'installazione (non è sicuro dove farlo nel progetto di installazione di VS 2008).

-Paul

Problemi correlati