Requisiti di certificazione per Le app desktop di Windows
Versione del documento: 10
Data documento: 29 luglio 2015
Questo documento contiene i requisiti tecnici e le qualifiche di idoneità che un'app desktop deve soddisfare per partecipare al programma di certificazione app desktop Windows 10.
Benvenuto!
La piattaforma Windows supporta un ampio ecosistema di prodotti e partner. La visualizzazione del logo di 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 superamento della certificazione app di Windows consente di visualizzare l'app nel Centro compatibilità di Windows e di visualizzare il logo di certificazione nel sito.
Il programma di certificazione app di Windows è costituito da requisiti tecnici e di programma per garantire che le app di terze parti che trasportano il marchio 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 nella piattaforma Windows per i PC. Questi sforzi includono test di compatibilità per la coerenza dell'esperienza, prestazioni migliorate e sicurezza avanzata nei PC che eseguono software Windows. 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.
Windows App Certification Kit viene usato per convalidare la conformità a questi requisiti e sostituisce le versioni precedenti del kit usato per convalidare in Windows 7, Windows 8 o Windows 8.1. Windows App Certification Kit è uno dei componenti inclusi in Windows Software Development Kit (SDK) per Windows 10.
Idoneità delle app
Affinché un'app possa qualificarsi per Windows 10 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 PC locale Windows 10
- Può essere un componente client di un'app di Windows Server certificata
- Deve essere il codice e la funzionalità completa
- Non deve comunicare con le app di Windows Store tramite meccanismi locali, inclusi i file e le chiavi del Registro di sistema, ad eccezione degli scenari aziendali supportati
- Non deve compromettere o compromettere la sicurezza o la funzionalità del sistema Windows
- Deve avere un nome univoco e non deve essere marchiato da altri
- Tutti i componenti esterni devono essere certificati separatamente o conformi a Windows App Certification Kit
- Deve avere un'opzione di opt-out per tutte le app in bundle
Se l'app desktop viene inviata alla categoria di prodotti anti-virus e/o anti-spyware (ad esempio, antimalware), deve essere conforme alle LINEE GUIDA ANTIMALWARE PLATFORM. Il CONTRATTO DI LICENZA PER LE API ANTIMALWARE DI WINDOWS 10 E LISTATO deve essere stato firmato ed effettivo prima dell'invio. Il partner deve essere membro di o avere ricercatori di e in buona posizione in una delle organizzazioni elencate nel contratto. La funzionalità deve essere certificata in Windows 10 da una delle organizzazioni elencate nel contratto. L'app deve essere stata testata almeno una volta negli ultimi 12 mesi e certificata per il rilevamento e la pulizia.
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à di Windows, dal messaggio AppHelp e da eventuali altre correzioni di compatibilità
1.2 L'app deve avere un manifesto di compatibilità e usare i GUID appropriati per le versioni supportate di Windows
1.3 L'app deve essere con riconoscimento DPI usando il manifesto dell'assembly dell'applicazione anziché chiamando SetProcessDPIAware
1.4 L'app non deve accettare una dipendenza dal runtime VB6
1.5 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 di Windows
L'uso delle procedure consigliate per la sicurezza di Windows consente di evitare di creare un'esposizione alle superfici di attacco di 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.
Si noti che i test 2.1 2.6 sono applicabili solo per le app desktop testate in Windows 7, Windows 8 o Windows 8.1.
- 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.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 ai servizi di riavviare più di due volte ogni 24 ore.
Nota: l'accesso deve essere concesso solo alle entità che lo richiedono.
Il programma di certificazione app windows verificherà che le superfici di attacco di 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 di Windows
Il sistema operativo Windows ha 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 solo 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.
- 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.
- WM\_ENDSESSION con LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Almeno, l'app deve prepararsi salvando i dati utente e dichiarando le informazioni necessarie dopo un riavvio.
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
- DisplayName
- InstallLocation
- Publisher
- UninstallString
- VersionMajor o MajorVersion
- VersionMinor o MinorVersion
- Se l'installazione ha esito negativo, l'app deve essere in grado di eseguirne il rollback e ripristinare il computer allo stato precedente.
- Il riavvio del computer non deve mai essere l'unica opzione alla fine di un'installazione, disinstallazione o aggiornamento. Gli utenti devono avere l'opportunità di riavviare in un secondo momento.
- Gli strumenti di inventario di Windows e gli 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:
6. Le app devono firmare digitalmente file e driver
Una firma digitale Authenticode consente agli utenti di assicurarsi che il software sia autentico. Consente anche 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à di 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 verificarsi 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 del file system devono essere firmati da Microsoft.
6.3 Eccezioni e rinuncia
- Le rinuncia verranno considerate solo per i ridistribuibili non firmati, esclusi i conducenti. Per concedere questa rinuncia è necessaria una prova di comunicazione che richiede una versione firmata degli elementi ridistribuibili.
7. Le app non bloccano l'installazione o l'avvio delle app in base a un controllo della versione del sistema operativo
È importante che i clienti non vengano artificialmente bloccati 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 della versione per verificarne l'uguaglianza
- Le app distribuite come pacchetto che vengono eseguite anche in Windows 7, Windows 8 e Windows 8.1 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.
- Se è necessaria una funzionalità specifica, verificare se la funzionalità è disponibile. Se è necessario Windows 7, verificare la presenza di Windows 7 o versione successiva (>= 6.2). In questo modo, il codice di rilevamento continuerà a funzionare sulle versioni future di Windows. I programmi di installazione dei driver e i moduli di disinstallazione non devono mai controllare la versione del sistema operativo.
8. Le app non caricano servizi o driver in modalità provvisoria
La modalità provvisoria 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:
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 di Windows vengono eseguite nel contesto di sicurezza di un account amministratore e le app spesso richiedono diritti utente eccessivi e privilegi di 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 (UAC) un'app fornisce 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
- 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.
- 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 Microsoft. 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""/>
- 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, devono essere firmate Authenticode.
- 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:
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
- 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
- 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.
- Ad esempio, l'app non deve impostare uno dei seguenti elementi;
- Usare i metodi corretti per l'installazione di file, ad esempio tipi di carattere o driver.
- 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.
- 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 esplicitamente richiesta la condivisione di un assembly.
11. Le app devono supportare sessioni multiutente
Gli utenti di Windows 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.
- Fare riferimento ai requisiti di Controllo dell'account utente.
12. Le app devono supportare le 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 Qualsiasi plug-in shell deve essere eseguito 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.
Conclusione
Poiché questi requisiti si evolveranno, si noteranno le modifiche nella cronologia delle revisioni riportate di seguito. I requisiti stabili sono fondamentali per svolgere il vostro lavoro migliore, quindi vogliamo garantire che le modifiche apportate siano sostenibili e continuino a proteggere e migliorare le tue app.
Grazie di nuovo 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 | Aggiornare alla sezione 2. | 1.1 |
| 31 maggio 2012 | 1.2 | Aggiunta dei risultati dei test di riepilogo | 1.2 |
| 29 giugno 2012 | 3.0 | Windows 8 documento finale | 3.0 |
| 18 giugno 2013 | 3.1 | Windows 8.1 documento | 3.1 |
| 20 febbraio 2014 | 3.2 | Aggiornamento interno | |
| 18 marzo 2014 | 3.3 | Windows 8.1 Update 1 | 3.3 |
| 29 luglio 2015 | 10 | Windows 10 aggiornamento | 10 |
Altre informazioni sulla certificazione delle app desktop
| Requisito | Descrizione |
| Compatibilità e resilienza | Gli arresti anomali & blocchi 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. Il punto di ingresso dell'app per l'utente deve essere manifesto per la compatibilità, oltre a dichiarare il GUID corretto. I punti di ingresso dell'app per l'utente devono essere manifestati per la consapevolezza di HIGH-DPI e che le API appropriate vengono chiamate per supportare HIGH-DPI. Per altre informazioni, vedere: |
| Rispettare le procedure consigliate di Sicurezza di Windows | L'uso delle procedure consigliate per la sicurezza di Windows consente di evitare di creare un'esposizione alle superfici di attacco di 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. Per altre informazioni, vedere: |
| Funzionalità di supporto Sicurezza di Windows | Il sistema operativo Windows 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. Per altre informazioni, vedere 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 disattivano. 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. |
| Installazione reversibile | Un'installazione pulita, reversibile, consente agli utenti di gestire correttamente (distribuire e rimuovere) le app nei propri sistemi. Per altre informazioni, vedere Procedura: Installare prerequisiti con un'applicazione ClickOnce. |
| 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. Applicazione della firma del codice in modalità kernel è una funzionalità di 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. |
| 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. Per altre informazioni, vedere Controllo delle versioni del sistema operativo. |
| Non caricare servizi e driver in modalità provvisoria | La modalità sicura 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. Per altre informazioni, vedere: |
| Seguire le linee guida per il controllo account utente | Alcune app di Windows vengono eseguite nel contesto di sicurezza di un account amministratore e molti richiedono diritti utente e privilegi di Windows eccessivi. 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. Per altre informazioni, vedere: |
| 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. Per altre informazioni, vedere Riepilogo dei requisiti di installazione/disinstallazione. |
| Supportare sessioni multiutente | Gli utenti di Windows devono essere in grado di eseguire sessioni simultanee senza conflitti o interruzioni. Per altre informazioni, vedere 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 in versioni a 64 bit di Windows. |
Vedi anche
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per