Archivio: Requisiti di certificazione per app desktop Windows v1.1

Versione del documento: 1.1

Data documento: 26 gennaio 2012

Questo documento contiene i requisiti tecnici e le qualifiche di idoneità che un'app desktop deve soddisfare per partecipare al programma di certificazione dell'app desktop Windows 8. Per Windows 7, questo programma è stato noto come programma di logo software Windows.

Benvenuto!

La piattaforma Windows supporta un ampio ecosistema di prodotti e partner. La visualizzazione del logo Windows sul prodotto rappresenta una relazione e un impegno condiviso per la qualità tra Microsoft e l'azienda. I clienti considerano attendibile il marchio Windows sul tuo prodotto perché garantisce che soddisfi gli standard di compatibilità e funzioni bene sulla piattaforma Windows. Il passaggio Windows Certificazione app consente di visualizzare l'app nel Centro compatibilità Windows ed è anche un passaggio necessario per elencare un riferimento all'app desktop nello Store Windows.

Il programma di certificazione delle app Windows è costituito da requisiti tecnici e di programma per garantire che le app di terze parti che trasportano il marchio di Windows siano sia facili da installare che affidabili nei PC che eseguono Windows. I clienti valutano la stabilità, la compatibilità, l'affidabilità, le prestazioni e la qualità nei sistemi acquistati. Microsoft è incentrato sugli investimenti per soddisfare questi requisiti per le app software progettate per l'esecuzione sulla piattaforma Windows per i PC. Questi sforzi includono test di compatibilità per coerenza dell'esperienza, prestazioni migliorate e sicurezza avanzata nei PC che eseguono Windows software. I test di compatibilità Microsoft sono stati progettati in collaborazione con i partner del settore e sono costantemente migliorati in risposta agli sviluppi del settore e alla domanda dei consumatori.

Il Windows App Certification Kit viene usato per convalidare la conformità a questi requisiti e sostituisce WSLK usato per la convalida nel programma Windows 7 Software Logo. Il kit di certificazione app Windows è uno dei componenti inclusi nel Windows Software Development Kit (SDK).

Idoneità delle app

Affinché un'app possa qualificarsi per Windows 8 Certificazione app desktop, deve soddisfare i criteri seguenti e tutti i requisiti tecnici elencati in questo documento.

  • Deve essere un'app autonoma
  • Deve essere eseguito in un computer locale Windows 8.1
  • Può essere un componente client di un'app server di Windows certificato
  • Deve essere il codice e la funzionalità completa

1. Le app sono compatibili e resilienti

I tempi in cui un'app si arresta o arresta la risposta causano molta frustrazione dell'utente. Le app devono essere resilienti e stabili ed eliminare tali errori aiutano a garantire che il software sia più prevedibile, gestibile, efficiente e affidabile.

1.1 L'app non deve accettare una dipendenza dalle modalità di compatibilità Windows, dal messaggio AppHelp e da eventuali altre correzioni di compatibilità
1.2 L'app non deve accettare una dipendenza dal runtime VB6
1.3 L'app non deve caricare DLL arbitrarie per intercettare le chiamate API Win32 usando HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls.

2. Le app devono rispettare le procedure consigliate per la sicurezza Windows

L'uso di Windows procedure consigliate per la sicurezza consente di evitare di creare un'esposizione alle superfici di attacco Windows. Le superfici di attacco sono i punti di ingresso che un utente malintenzionato potrebbe usare per sfruttare il sistema operativo sfruttando le vulnerabilità nel software di destinazione. Una delle peggiori vulnerabilità di sicurezza è l'elevazione dei privilegi.

2.1 L'app deve usare elenchi di controllo di accesso sicuri e appropriati per proteggere i file eseguibili 2.2 L'app deve usare elenchi di controllo di accesso sicuri e appropriati per proteggere le directory 2.3 L'app deve usare elenchi di controllo di accesso sicuri e appropriati per proteggere le chiavi del Registro di sistema 2.2 2.4 L'app deve usare elenchi di controllo di accesso sicuri e appropriati per proteggere le directory che contengono oggetti 2.5 L'app deve ridurre l'accesso non amministratore ai servizi vulnerabili alla manomissione 2.6 L'app deve impedire servizi con velocità rapida riavvia dal riavvio più di due volte ogni 24 ore
**Nota: l'accesso deve essere concesso solo alle entità che lo richiedono.**

Il Windows Programma di certificazione app verificherà che le superfici di attacco Windows non siano esposte verificando che gli elenchi di controllo di accesso e i servizi vengano implementati in modo da non mettere a rischio il sistema Windows.

3. Le app supportano le funzionalità di sicurezza Windows

Il sistema operativo Windows offre molte funzionalità che supportano la sicurezza e la privacy del sistema. Le app devono supportare queste funzionalità per mantenere l'integrità del sistema operativo. Le app compilate in modo non corretto potrebbero causare l'overrun del buffer che può, a sua volta, causare l'esecuzione di denial of service o consentire l'esecuzione di codice dannoso.

3.1 L'app non deve usare AllowPartiallyTrustedCallersAttribute (APTCA) per garantire l'accesso sicuro agli assembly con nome sicuro
3.2 L'app deve essere compilata usando il flag /SafeSEH per garantire la gestione delle eccezioni sicure
3.3 L'app deve essere compilata usando il flag /NXCOMPAT per impedire l'esecuzione dei dati
3.4 L'app deve essere compilata usando il flag /DYNAMICBASE per la casualizzazione casuale dello spazio indirizzi (ASLR)
3.5 L'app non deve leggere/scrivere le sezioni PE condivise

4. Le app devono rispettare i messaggi di gestione riavvio del sistema

Quando gli utenti avviano l'arresto, in genere hanno un forte desiderio di vedere l'arresto riuscito; potrebbero essere in fretta di lasciare l'ufficio e vogliono che i loro computer siano disattivati. Le app devono rispettare questo desiderio non bloccando l'arresto. Anche se nella maggior parte dei casi, un arresto potrebbe non essere critico, le app devono essere preparate per la possibilità di un arresto critico.

4.1 L'app deve gestire in modo appropriato gli arresti critici
In un arresto critico, le app che restituiscono FALSE a WM_QUERYENDSESSION verranno inviate WM_ENDSESSION e chiuse, mentre quelle che escono in risposta a WM_QUERYENDSESSION verranno terminate.

4.2 Un'app GUI deve restituire TRUE immediatamente in preparazione per un riavvio
WM\_QUERYENDSESSION con LPARAM = ENDSESSION\_CLOSEAPP(0x1). Le app console possono chiamare SetConsoleCtrlHandler per specificare la funzione che gestirà le notifiche di arresto. Le app di servizio possono chiamare RegisterServiceCtrlHandlerEx per specificare la funzione che riceverà notifiche di arresto.
4.3 L'app deve restituire 0 entro 30 secondi e arrestare
WM\_ENDSESSION con LPARAM = ENDSESSION\_CLOSEAPP(0x1). Almeno, l'app deve prepararsi salvando i dati utente e dichiarando le informazioni necessarie dopo un riavvio.
4.4 App console che ricevono la notifica CTRL\_C\_EVENT deve arrestare immediatamente 4.5 Driver non deve vetare un evento di arresto del sistema
**Nota: le app che devono bloccare l'arresto a causa di un'operazione che non può essere interrotta devono spiegare il motivo per l'utente.** Usare ShutdownBlockReasonCreate per registrare una stringa che spiega il motivo per l'utente. Al termine dell'operazione, l'app deve chiamare ShutdownBlockReasonDestroy per indicare che il sistema può essere arrestato.

5. Le app devono supportare un'installazione pulita e reversibile

Un'installazione pulita, reversibile, consente agli utenti di gestire correttamente (distribuire e rimuovere) le app nei propri sistemi.

5.1 L'app deve implementare correttamente un'installazione pulita e reversibile
Se l'installazione ha esito negativo, l'app deve essere in grado di eseguirne il rollback e ripristinare il computer allo stato precedente.

5.2 L'app non deve mai forzare l'utente a riavviare immediatamente il computer
Il riavvio del computer non deve mai essere l'unica opzione alla fine di un'installazione o di un aggiornamento. Gli utenti devono avere l'opportunità di riavviare in un secondo momento.
5.3 L'app non deve mai dipendere da 8.3 nomi di file brevi (SFN) 5.4 L'app non deve mai bloccare l'installazione/disinstallazione invisibile all'utente 5.5 Il programma di installazione dell'app deve creare le voci corrette del Registro di sistema per consentire il rilevamento e le disinstallazioni riuscite
Windows strumenti di inventario e strumenti di telemetria richiedono informazioni complete sulle app installate. Se si usa un programma di installazione basato su MSI, msi crea automaticamente le voci del Registro di sistema di seguito. Se non si usa un programma di installazione del servizio gestito, il modulo di installazione deve creare le voci del Registro di sistema seguenti durante l'installazione:
  • DisplayName
  • InstallLocation
  • Publisher
  • UninstallString
  • VersionMajor o MajorVersion
  • VersionMinor o MinorVersion

6. Le app devono firmare digitalmente file e driver

Una firma digitale Authenticode consente agli utenti di assicurarsi che il software sia autentico. Consente inoltre di rilevare se un file è stato manomesso, ad esempio se è stato infettato da un virus. L'applicazione della firma del codice in modalità kernel è una funzionalità Windows nota come integrità del codice (CI), che migliora la sicurezza del sistema operativo verificando l'integrità di un file ogni volta che l'immagine del file viene caricata in memoria. CI rileva se il codice dannoso ha modificato un file binario di sistema. Genera anche un evento di diagnostica e log di controllo di sistema quando la firma di un modulo kernel non riesce a verificare correttamente.

6.1 Tutti i file eseguibili (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) devono essere firmati con un certificato Authenticode
6.2 Tutti i driver in modalità kernel installati dall'app devono avere una firma Microsoft ottenuta tramite il programma di certificazione hardware Windows. Tutti i driver di filtro file system devono essere firmati da Microsoft.
6.3 Eccezioni e eccezioni
Le rinuncia verranno considerate solo per i ridistribuibili non firmati, esclusi i driver. Una prova della comunicazione che richiede una versione firmata dei ridistribuibili è necessaria per concedere questa rinuncia.

7. Le app non bloccano l'installazione o l'avvio dell'app in base a un controllo della versione del sistema operativo

È importante che i clienti non vengano bloccati in modo artificiale dall'installazione o dall'esecuzione dell'app quando non sono presenti limitazioni tecniche. In generale, se le app sono state scritte per Windows Vista o versioni successive di Windows, non devono controllare la versione del sistema operativo.

7.1 L'app non deve eseguire controlli di versione per l'uguaglianza
Se è necessaria una funzionalità specifica, verificare se la funzionalità stessa è disponibile. Se è necessario Windows XP, verificare Windows XP o versione successiva (>= 5.1). In questo modo, il codice di rilevamento continuerà a funzionare sulle versioni future di Windows. I programmi di installazione del driver e i moduli di disinstallazione non devono mai controllare la versione del sistema operativo.

7.2 Le eccezioni e le rinuncia verranno considerate per le app che soddisfano i criteri seguenti:
  • Le app distribuite come pacchetto che vengono eseguite anche in Windows XP, Windows Vista e Windows 7 e devono controllare la versione del sistema operativo per determinare quali componenti installare in un determinato sistema operativo.
  • App che controllano solo la versione minima del sistema operativo (solo durante l'installazione, non in fase di esecuzione) usando solo le chiamate API approvate e che elencano correttamente il requisito di versione minima nel manifesto dell'app.
  • App di sicurezza (antivirus, firewall e così via), utilità di sistema (ad esempio, deframmentare, backup e strumenti di diagnostica) che controllano la versione del sistema operativo usando solo le chiamate API approvate.

8. Le app non caricano servizi o driver in modalità provvisoria

Cassaforte modalità consente agli utenti di diagnosticare e risolvere i problemi di Windows. I driver e i servizi non devono essere impostati per il caricamento in modalità provvisoria, a meno che non siano necessari per operazioni di sistema di base, ad esempio driver di dispositivo di archiviazione o per scopi di diagnostica e ripristino, ad esempio scanner antivirus, . Per impostazione predefinita, quando Windows è in modalità provvisoria, avvia solo i driver e i servizi preinstallati con Windows.

  • 8.1 Eccezioni e rinuncia
    I driver e i servizi che devono essere avviati in modalità provvisoria richiedono una rinuncia. La richiesta di rinuncia deve includere ogni driver o servizio applicabile scrivendo nelle chiavi del Registro di sistema SafeBoot e descrivere i motivi tecnici per cui l'app o il servizio deve essere eseguito in modalità provvisoria. Il programma di installazione dell'app deve registrare tutti questi driver e servizi usando queste chiavi del Registro di sistema:
    - HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal - HKLM/System/CurrentControlSet/Control/SafeBoot/Network

Nota: È necessario testare questi driver e servizi per assicurarsi che funzionino in modalità provvisoria senza errori.

9. Le app devono seguire le linee guida per il controllo dell'account utente

Alcune app Windows vengono eseguite nel contesto di sicurezza di un account amministratore e le app spesso richiedono diritti utente eccessivi e privilegi Windows. Il controllo dell'accesso alle risorse consente agli utenti di controllare i propri sistemi e di proteggerli da modifiche indesiderate. Una modifica indesiderata può essere dannosa, ad esempio un rootkit che prende il controllo del computer o è il risultato di un'azione eseguita da persone con privilegi limitati. La regola più importante per controllare l'accesso alle risorse consiste nel fornire il minor numero di accessi al contesto utente standard necessario per consentire a un utente di eseguire le proprie attività necessarie. Seguendo le linee guida per il controllo dell'account utente ,l'app fornisce all'app le autorizzazioni necessarie quando sono necessarie per l'app, senza lasciare il sistema costantemente esposto ai rischi per la sicurezza. La maggior parte delle app non richiede privilegi di amministratore in fase di esecuzione e deve essere eseguita correttamente come utente standard.

9.1 L'app deve avere un manifesto che definisce i livelli di esecuzione e indica al sistema operativo quali privilegi richiedono l'app per l'esecuzione
Il contrassegno del manifesto dell'app si applica solo a EXEs, non alle DLL. Questo avviene perché controllo dell'account utente non controlla le DLL durante la creazione del processo. Vale anche la pena notare che le regole di Controllo dell'account utente non si applicano ai servizi di Windows. Il manifesto può essere incorporato o esterno.
Per creare un manifesto, creare un file con il nome <app_name>.exe.manifest e archiviarlo nella stessa directory del file EXE. Si noti che qualsiasi manifesto esterno viene ignorato se l'app ha un manifesto interno. Ad esempio:
<requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false""/>

9.2 Il processo principale dell'app deve essere eseguito come utente standard (asInvoker).
Tutte le funzionalità amministrative devono essere spostate in un processo separato eseguito con privilegi amministrativi. Le app rivolte agli utenti, ad esempio quelle accessibili tramite il gruppo di programmi nel menu Start, e richiedono l'elevazione dei privilegi devono essere firmate Authenticode.
9.3 Eccezioni e rinuncia
Una rinuncia è necessaria per le app che eseguono il processo principale con privilegi elevati (requireAdministrator o highestAvailable). Il processo principale viene identificato come punto di ingresso dell'utente all'app. Le rinuncia verranno considerate per gli scenari seguenti:
  • Strumenti amministrativi o di sistema con livello di esecuzione impostato su highestAvailable e/o requireAdministrator
  • Solo l'accessibilità o l'app del framework di automazione interfaccia utente imposta il flag uiAccess su true per ignorare l'isolamento dei privilegi dell'interfaccia utente. Per avviare correttamente l'utilizzo dell'app, questo flag deve essere firmato Authenticode e deve trovarsi in un percorso protetto nel file system, ovvero Programmi.

10. Le app devono essere installate nelle cartelle corrette per impostazione predefinita

Gli utenti devono avere un'esperienza coerente e sicura con il percorso di installazione predefinito dei file, mantenendo al tempo stesso l'opzione per installare un'app nel percorso preferito. È anche necessario archiviare i dati dell'app nella posizione corretta per consentire a più persone di usare lo stesso computer senza danneggiare o sovrascrivere i dati e le impostazioni dell'altro. Windows fornisce percorsi specifici nel file system per archiviare programmi e componenti software, dati dell'app condivisi e dati dell'app specifici di un utente

10.1 L'app deve essere installata nella cartella Programmi per impostazione predefinita
Per le app native a 32 bit e a 64 bit in %ProgramFiles%, e %ProgramFiles(x86)% per le app a 32 bit in esecuzione su x64. I dati utente o i dati dell'app non devono mai essere archiviati in questa posizione a causa delle autorizzazioni di sicurezza configurate per questa cartella.

10.2 L'app deve evitare l'avvio automatico all'avvio
Ad esempio, l'app non deve impostare uno dei seguenti elementi;
  • Chiavi di esecuzione del Registro di sistema HKLM e HKCU in Software\Microsoft\Windows\CurrentVersion
  • Chiavi di esecuzione del Registro di sistema HKLM e o HKCU in Software\Wow6432Node\Microsoft\windows\CurrentVersion
  • Start Menu AllPrograms > STARTUP
10.3 I dati dell'app, che devono essere condivisi tra gli utenti del computer, devono essere archiviati all'interno di ProgramData 10.4 I dati dell'app esclusivi di un utente specifico e che non devono essere condivisi con altri utenti del computer, devono essere archiviati in Users\\<username>\\AppData 10.5 L'app non deve mai scrivere direttamente nella directory "Windows" e nelle sottodirectory o nelle sottodirectory
Usare i metodi corretti per l'installazione di file, ad esempio tipi di carattere o driver.
10.6 L'app deve scrivere i dati utente alla prima esecuzione e non durante l'installazione nelle installazioni per computer
Quando l'app è installata, non esiste un percorso utente corretto in cui archiviare i dati. I tentativi da parte di un'app di modificare i comportamenti di associazione predefiniti a livello di computer dopo l'installazione avranno esito negativo. Le impostazioni predefinite devono invece essere richieste a livello di singolo utente, che impedisce a più utenti di sovrascrivere le impostazioni predefinite dell'altro.
10.7 Eccezioni e rinuncia
Una rinuncia è necessaria per le app che scrivono nelle app .NET della Global Assembly Cache (GAC) devono mantenere private le dipendenze degli assembly e archiviarla nella directory dell'app, a meno che non sia richiesta esplicitamente la condivisione di un assembly.

11. Le app devono supportare sessioni multiutente

Windows gli utenti devono essere in grado di eseguire sessioni simultanee senza conflitti o interruzioni.

11.1 L'app deve assicurarsi che quando si esegue in più sessioni in locale o in remoto, la normale funzionalità dell'app non influisce negativamente
11.2 Le impostazioni e i file di dati dell'app non devono essere mantenuti tra gli utenti
11.3 La privacy e le preferenze di un utente devono essere isolate per la sessione dell'utente
11.4 Le istanze dell'app devono essere isolate l'una dall'altra
Ciò significa che i dati utente di un'istanza non sono visibili a un'altra istanza dell'app. Il suono in una sessione utente inattiva non deve essere sentito in una sessione utente attiva. Nei casi in cui più istanze dell'app usano risorse condivise, l'app deve assicurarsi che non vi sia un conflitto.

11.5 Le app installate per più utenti devono archiviare i dati nelle cartelle e nei percorsi del Registro di sistema corretti
Fare riferimento ai requisiti di Controllo dell'account utente.
11.6 Le app utente devono essere in grado di essere eseguite in più sessioni utente (passaggio rapido dell'utente) sia per l'accesso locale che per l'accesso remoto 11.7 L'app deve controllare altre sessioni del servizio terminale (TS) per le istanze esistenti dell'app
**Nota:** Se un'app non supporta più sessioni utente o accesso remoto, deve indicare chiaramente questo quando viene avviato da questo tipo di sessione.

12. Le app devono supportare versioni x64 di Windows

Man mano che l'hardware a 64 bit diventa più comune, gli utenti si aspettano agli sviluppatori di app di sfruttare i vantaggi dell'architettura a 64 bit eseguendo la migrazione delle app a 64 bit o che le versioni a 32 bit dell'app vengono eseguite correttamente con versioni a 64 bit di Windows.

12.1 L'app deve supportare in modo nativo a 64 bit o, almeno, le app basate su Windows a 32 bit devono essere eseguite senza problemi nei sistemi a 64 bit per mantenere la compatibilità con le versioni a 64 bit di Windows
12.2 L'app e i relativi programmi di installazione non devono contenere codice a 16 bit o basarsi su qualsiasi componente a 16 bit
12.3 L'installazione dell'app deve rilevare e installare i driver e i componenti appropriati per l'architettura a 64 bit
12.4 Tutti i plug-in shell devono essere eseguiti in versioni a 64 bit di Windows
12.5 L'app in esecuzione nell'emulatore WoW64 non deve tentare di sottrarre o ignorare i meccanismi di virtualizzazione Wow64
Se esistono scenari specifici in cui le app devono rilevare se sono in esecuzione nell'emulatore WoW64, è consigliabile farlo chiamando IsWow64Process.

Conclusioni

Man mano che questi requisiti si evolvono, si noteranno le modifiche nella cronologia delle revisioni riportata di seguito. I requisiti stabili sono fondamentali per svolgere il tuo lavoro migliore, quindi ci punteremo a garantire che le modifiche apportate siano sostenibili e continuino a proteggere e migliorare le tue app.

Grazie ancora per l'adesione al nostro impegno per offrire esperienze di clienti eccezionali.

Cronologia delle revisioni

Data Versione Descrizione revisione Collegamento al documento
20 dicembre 2011 1,0 Bozza iniziale del documento per l'anteprima.
26 gennaio 2012 1,1 Eseguire l'aggiornamento alla sezione 2. 1,1

Altre informazioni sulla certificazione delle app desktop

Requisito Descrizione Altre informazioni
Compatibilità e resilienza Gli arresti & anomali sono un'interruzione principale per gli utenti e causano frustrazione. Le app devono essere resilienti e stabili, eliminando tali errori, consente di garantire che il software sia più prevedibile, gestibile, efficiente e affidabile. Windows Vista, Windows 7 e sistemi operativi Windows 8
Application Verifier
DLL AppInit
Rispettare le procedure consigliate di Sicurezza di Windows L'uso di Windows procedure consigliate per la sicurezza consente di evitare di creare un'esposizione alle superfici di attacco Windows. Le superfici di attacco sono i punti di ingresso che un utente malintenzionato potrebbe usare per sfruttare il sistema operativo sfruttando le vulnerabilità nel software di destinazione. Una delle peggiori vulnerabilità di sicurezza è l'elevazione dei privilegi. Attack Surface Analyzer
Elenchi di controllo di accesso
Funzionalità di supporto Sicurezza di Windows Il Windows sistema operativo ha implementato molte misure per supportare la sicurezza e la privacy del sistema. Le applicazioni devono supportare queste misure per mantenere l'integrità del sistema operativo. Le applicazioni compilate in modo non corretto potrebbero causare sovraccarichi del buffer che a sua volta potrebbero causare l'esecuzione di denial of service o rendere eseguito codice dannoso. Informazioni di riferimento sullo strumento BinScope
Rispettare i messaggi di System Restart Manager Quando gli utenti avviano l'arresto, nella maggior parte dei casi, hanno un forte desiderio di vedere l'arresto riuscito; potrebbero essere in fretta di lasciare l'ufficio e "solo vuole" che i loro computer siano disattivati. Le app devono rispettare questo desiderio non bloccando l'arresto. Anche se nella maggior parte dei casi, un arresto potrebbe non essere critico, le app devono essere preparate per la possibilità di un arresto critico. Modifiche all'arresto dell'applicazione in vista Windows
Riavviare lo sviluppo di Manager
Installazione reversibile Un'installazione pulita, reversibile, consente agli utenti di gestire correttamente (distribuire e rimuovere) le app nei propri sistemi. Procedura: Installare i prerequisiti con un'applicazione ClickOnce
Installazione dell'applicazione in sistemi a 64 bit
Firma digitale dei file e dei driver Una firma digitale Authenticode consente agli utenti di assicurarsi che il software sia autentico. Consente inoltre di rilevare se un file è stato manomesso, ad esempio se è stato infettato da un virus. L'applicazione della firma del codice in modalità kernel è una funzionalità Windows nota come integrità del codice (CI), che migliora la sicurezza del sistema operativo verificando l'integrità di un file ogni volta che l'immagine del file viene caricata in memoria. CI rileva se il codice dannoso ha modificato un file binario di sistema. Genera anche un evento di diagnostica e log di controllo di sistema quando la firma di un modulo kernel non riesce a verificare correttamente. Firme digitali per i moduli kernel in Windows
Non bloccare l'installazione o l'avvio dell'app in base al controllo della versione del sistema operativo È importante che i clienti non vengano bloccati in modo artificiale dall'installazione o dall'esecuzione dell'app quando non sono presenti limitazioni tecniche. In generale, se le app sono state scritte per Windows Vista o versioni successive, non dovrebbero avere alcun motivo per controllare la versione del sistema operativo. Controllo delle versioni del sistema operativo
Non caricare servizi e driver in modalità Cassaforte Cassaforte modalità consente agli utenti di diagnosticare e risolvere i problemi di Windows. A meno che non sia necessario per le operazioni di base del sistema (ad esempio, driver di dispositivo di archiviazione) o per scopi di diagnostica e ripristino (ad esempio, scanner anti-virus), i driver e i servizi non devono essere impostati per il caricamento in modalità sicura. Per impostazione predefinita, la modalità provvisoria non avvia la maggior parte dei driver e dei servizi che non sono stati preinstallati con Windows. Devono rimanere disabilitati a meno che il sistema non richieda operazioni di base o per scopi di diagnostica e ripristino. Determinazione del fatto che il sistema operativo sia in esecuzione in modalità Cassaforte
Seguire le linee guida per il controllo account utente Alcuni Windows'app vengono eseguiti nel contesto di sicurezza di un account amministratore e molti richiedono diritti utente eccessivi e privilegi di Windows. Il controllo dell'accesso alle risorse consente agli utenti di controllare i propri sistemi contro le modifiche indesiderate (una modifica indesiderata può essere dannosa, ad esempio un rootkit che prende in modo invisibile il computer o un'azione da parte di persone che hanno privilegi limitati, ad esempio un dipendente che installa software vietato in un computer aziendale). La regola più importante per controllare l'accesso alle risorse consiste nel fornire la quantità minima di contesto utente standard di accesso necessaria per l'esecuzione delle attività necessarie da parte di un utente. Le linee guida relative all'interfaccia utente forniscono all'app le autorizzazioni necessarie quando necessario, senza lasciare il sistema costantemente esposto ai rischi di sicurezza. Controllo account utente
Interfaccia utente: Linee guida per l'aggiornamento delle applicazioni
Installare nelle cartelle corrette per impostazione predefinita Gli utenti devono avere un'esperienza coerente e sicura con il percorso di installazione predefinito dei file, mantenendo l'opzione per installare un'app nel percorso scelto. È anche necessario archiviare i dati dell'app nella posizione corretta per consentire a più persone di usare lo stesso computer senza danneggiare o sovrascrivere i dati e le impostazioni dell'altro. Riepilogo dei requisiti di installazione/disinstallazione
Supportare sessioni multiutente Windows gli utenti devono essere in grado di eseguire sessioni simultanee senza conflitti o interruzioni. Linee guida per la programmazione di Servizi Desktop remoto
Supportare le versioni x64 di Windows Poiché l'hardware a 64 bit diventa più diffuso, gli utenti prevedono che gli sviluppatori di app sfruttano i vantaggi dell'architettura a 64 bit eseguendo la migrazione delle app a 64 bit o che le versioni a 32 bit dell'app vengono eseguite bene sotto le versioni a 64 bit di Windows. Compatibilità delle applicazioni: Windows Vista a 64 bit

Vedi anche