Windows SDK

Windows SDK (10.0.22000) per Windows 11 fornisce le intestazioni, le librerie, i metadati e gli strumenti più recenti per la creazione di applicazioni di Windows. Usa questo SDK per creare applicazioni UWP (Universal Windows Platform) e Win32 per Windows 11 e versioni precedenti di Windows.

Attività iniziali

Puoi ottenere Windows SDK in due modi: puoi installarlo da questa pagina selezionando il collegamento per il download oppure puoi selezionare "Windows 11 SDK (10.0.22000)" tra i componenti facoltativi del programma di installazione di Visual Studio 2019.

Prima di installare l'SDK:

  1. Esamina tutti i requisiti di sistema
  2. Chiudi Visual Studio prima dell'installazione.
  3. Esamina le Note sulla versione e problemi noti.

Requisiti di sistema

I requisiti di sistema minimi per Windows SDK sono i seguenti:

Sistemi operativi supportati

  • Sviluppo di app UWP (Universal Windows Platform)
    • Windows 10 versione 1507 o successiva: Home, Professional, Education ed Enterprise (le versioni LTSB e S non sono supportate)
    • Windows Server 2019, Windows Server 2016 e Windows Server 2012 R2 (solo da riga di comando)
  • Sviluppo di app Win32
    • Windows 10 versione 1507 o successiva
    • Windows Server 2019, Windows Server 2016 e Windows Server 2012 R2 (solo da riga di comando)
    • Windows 8.1
    • Windows 7 SP1

Non tutti gli strumenti sono supportati nei sistemi operativi precedenti.

Requisiti hardware

  • Processore da 1,6 GHz o superiore
  • 1 GB di RAM
  • 4 GB di spazio disponibile su disco rigido

Requisiti aggiuntivi dell'SDK

Per l'installazione in Windows 8.1 e sistemi operativi precedenti è richiesto l'aggiornamento KB2999226. Per eseguire l'installazione tramite Windows Update, assicurati di installare le patch e gli aggiornamenti consigliati più recenti da Microsoft Update prima di installare Windows SDK.

Novità

Windows SDK per Windows 11 ti consente di aggiornare le tue app per la versione più recente di Windows OS. Scopri di più sulle nuove funzionalità di Windows 11.

Per scoprire le nuove API introdotte con Windows 11, vedi Nuove API in Windows 11 build 22000.

I file binari di Windows 11 sono stati ricompilati nel sistema operativo ARM stesso con ARM64EC in modo che qualsiasi codice del sistema caricato da app x64 venga eseguito con velocità nativa. Sfrutta i vantaggi di ARM64EC per eseguire la transizione incrementale della tua app all'esecuzione con velocità nativa su ARM, anche se sono presenti dipendenze o plug-in che non supportano ancora ARM. Leggi l'annuncio.

Esempi

Gli esempi di app di Windows sono ora disponibili tramite GitHub. Puoi esplorare il codice in GitHub, clonare una copia personale del repository da Git o scaricare un archivio compresso di tutti gli esempi. Siamo interessati a ricevere feedback, quindi non esitare a inviare una richiesta nel repository in caso di problemi o domande. Questi esempi sono progettati per l'esecuzione in computer desktop, dispositivi mobili e nei dispositivi futuri che supportano la piattaforma UWP (Universal Windows Platform).

Versioni precedenti di SDK

Puoi trovare le versioni precedenti di SDK ed emulatori, inclusi i dettagli degli aggiornamenti, nella pagina di archivio.

Informazioni importanti sulle API

Quando usi nuove API per le destinazioni, scrivi l'app con caratteristiche adattive, in modo che possa essere eseguita correttamente sulla più ampia serie possibile di dispositivi Windows. Un'app adattiva può rendere disponibili nuove funzionalità quando supportate dai dispositivi e dalla versione di Windows, in caso contrario offre solo le funzionalità disponibili sulla versione della piattaforma rilevata. Per dettagli sull'implementazione, vedi l'articolo sul codice adattivo per la versione.

Note sulla versione e problemi noti

Windows 10 SDK, versione 2104

  • Il file api-ms-win-net-isolation-l1-1-0.lib è stato rimosso. Le app con collegamenti ad api-ms-win-net-isolation-l1-1-0.lib possono passare a OneCoreUAP.lib come sostituzione.
  • Il file irprops.lib è stato rimosso. Le app con collegamenti a irprops.lib possono passare a bthprops.lib come sostituzione.
  • È stato effettuato lo spostamento di ENUM tagServerSelection da wuapicommon.h a wupai.h e l'intestazione è stata rimossa. Se vuoi usare ENUM tagServerSelection, dovrai includere wuapi.h o wuapi.idl.
  • Il pacchetto di API di Windows 10 WinRT ti permette di aggiungere il supporto per le API di runtime più recenti alle librerie e alle app .NET Framework 4.5+ e .NET Core 3.0+. Per accedere al pacchetto di API di Windows 10 WinRT, vedi il pacchetto NuGet Microsoft.Windows.SDK.Contracts.
  • La famiglia di funzioni printf offre ora la conformità con le regole di arrotondamento di IEEE 754 durante la stampa di numeri a virgola mobile rappresentabili esattamente e rispetterà la modalità di arrotondamento richiesta tramite chiamate a fesetround. Il comportamento legacy è disponibile quando si esegue il collegamento con legacy_stdio_float_rounding.obj.
  • Kit di certificazione app Windows. Sono state aggiunte alcune nuove API all'elenco delle API supportate nel Kit di certificazione app e in Windows Store. Se nell'elenco di elementi supportati sono incluse API visualizzate in grigio o disabilitate in Visual Studio, puoi apportare una modifica minima al file di origine per accedere a tali API. Per altri dettagli, vedi questo problema noto. Trova altri aggiornamenti per i test.
  • Aggiornamenti al compilatore dei messaggi (mc.exe):
    • Il valore BOM (Byte Order Mark) Unicode viene ora rilevato nei file con estensione mc. Se il file con estensione mc inizia con un valore BOM UTF-8, verrà letto come file UTF-8. Se invece inizia con un valore BOM UTF-16LE, verrà letto come file UTF-16LE. Se è stato specificato il parametro -u, verrà letto come file UTF-16LE. In caso contrario, verrà letto usando la tabella codici corrente (CP_ACP).
    • Vengono ora evitati i problemi di tipo ODR (One-Definition-Rule) negli helper C/C++ ETW generati da MC provocati da un conflitto tra macro di configurazione. Ad esempio quando due file con estensione cpp con definizioni di MCGEN_EVENTWRITETRANSFER in conflitto sono collegati allo stesso file binario gli helper ETW generati da MC rispetteranno ora la definizione di MCGEN_EVENTWRITETRANSFER in ogni file con estensione cpp invece di selezionare arbitrariamente una definizione.
  • Aggiornamenti al preprocessore traccia Windows (tracewpp.exe):
    • Sono supportati file di input Unicode (INI, TPL e codice sorgente). I file di input che iniziano con un valore BOM (Byte Order Mark) UTF-8 o UTF-16 verranno letti come Unicode. I file di input che non iniziano con un valore BOM verranno letti usando la tabella codici corrente (CP_ACP). Per la compatibilità con le versioni precedenti, se è specificato il parametro -UnicodeIgnore della riga di comando, i file che iniziano con un valore BOM UTF-16 verranno considerati vuoti.
    • Sono supportati file di output Unicode (TMH). Per impostazione predefinita, i file di output verranno codificati mediante la tabella codici corrente (CP_ACP). Usa i parametri -cp:UTF-8 o -cp:UTF-16 della riga di comando per generare file di output Unicode.
    • Modifica del comportamento: tracewpp converte ora tutto il testo di input in Unicode, esegue l'elaborazione in Unicode e converte il testo di output nella codifica di output specificata. Le versioni precedenti di tracewpp evitavano le conversioni in Unicode ed eseguivano l'elaborazione del testo presupponendo un set di caratteri a byte singolo. Questo potrebbe provocare modifiche del comportamento nei casi in cui i file di input non sono conformi alla tabella codici corrente. Nei casi in qui ciò costituisce un problema, prendi in considerazione la conversione dei file di input in UTF-8 (con valore BOM) e/o l'uso del parametro -cp:UTF-8 della riga di comando per evitare l'ambiguità della codifica.
  • Aggiornamenti a TraceLoggingProvider.h:
    • Vengono evitati i problemi di tipo ODR (One-Definition-Rule) provocati da un conflitto tra macro di configurazione. Ad esempio quando due file con estensione cpp con definizioni di TLG_EVENT_WRITE_TRANSFER in conflitto sono collegati allo stesso file binario gli helper TraceLoggingProvider.h rispetteranno ora la definizione di TLG_EVENT_WRITE_TRANSFER in ogni file con estensione cpp invece di selezionare arbitrariamente una definizione.
    • Nel codice C++ la macro TraceLoggingWrite è stata aggiornata in modo da abilitare una migliore condivisione di codice tra eventi simili con modelli variadic.
  • Firma delle app. Firma di Device Guard è una funzionalità di Device Guard disponibile in Microsoft Store per le aziende e per la formazione che consente alle aziende di garantire che ogni app provenga da un'origine attendibile. Vedi la documentazione di Firma di Device Guard.
  • Le intestazioni dell'SDK sono state aggiornate per risolvere errori durante la compilazione mediante il preprocessore C conforme agli standard nel compilatore MSVC cl.exe (/Zc:preprocessor, introdotto in Visual Studio 2019 v16.6).
  • Problema risolto: "Non è possibile compilare GdiplusTypes.h con NOMINMAX". Vedi il feedback su Visual Studio.
  • Durante la compilazione con /std:c11 o /std:c17, puoi ora ottenere:
    • C99 tgmath.h
    • C11 static_assert in assert.h
    • C11 stdalign.h
    • C11 stdnoreturn.h
  • Clang/LLVM per Windows v11 che fa riferimento ad ARM64 non è compatibile con la versione più recente di winnt.h
    • Come soluzione alternativa, usa la versione precedente di Windows 10 SDK (build 19041) o clang/LLVM per Windows v10 quando fai riferimento alle piattaforme ARM64
  • DirectXMath (inclusa la versione 3.16 in questa release) non è compatibile con Clang/LLVM per Windows in ARM64.
  • L'uso di maiuscole/minuscole in alcuni file di intestazione è stato modificato in modo da normalizzarli per file system che applicano la distinzione tra maiuscole/minuscole:
    • Per OAIdl.h, ObjIdl.h, ObjIdlbase.h, OCIdl.h, Ole2.h, OleAuto.h e OleCtl.h è stato adottato l'uso di lettere minuscole.
    • Per le build di Clang/LLVM per Windows per supportare le versioni precedenti e la versione più recente di Windows 10 SDK senza avvisi, aggiungi '-Wno-nonportable-system-include-path' all'interfaccia della riga di comando o il valore #pragma seguente nell'origine:

      #ifdef __clang__
      #pragma clang diagnostic ignored "-Wnonportable-system-include-path"
      #endif

Aggiornamento di manutenzione di Windows 10 SDK, versione 2004 (rilasciato il 16/12/2020)

    Questa release contiene i file seguenti. Se si verificano questi problemi, ti consigliamo di aggiornare la tua versione dell'SDK non appena possibile per evitarli:
  • Risoluzione di arresti anomali del sistema imprevedibili e difficili da diagnosticare in caso di collegamento di librerie ombrello e librerie native del sistema operativo, ad esempio onecoreuap.lib e kernel32.lib
  • Risoluzione di un problema che impediva il funzionamento di AppVerifier
  • Risoluzione del problema che provocava un errore di WACK con messaggio analogo a "L'attività non è riuscita ad abilitare HighVersionLie"

Fornisci feedback

Per i problemi noti, vedi le domande e risposte per winapi-sdk.

Per richiedere nuove funzionalità per gli sviluppatori, invia la richiesta tramite l'app Hub di Feedback nella categoria "Piattaforma/API per sviluppatori".

Altre risorse

Download e strumenti

Ottieni le edizioni più recenti degli strumenti di sviluppo di Visual Studio e Windows 10.

ALTRE INFORMAZIONI

Archivio di SDK

Trova le versioni precedenti di Windows SDK e altri strumenti.

CONSULTA L'ARCHIVIO

Blog di Windows

Ottieni informazioni sempre aggiornate sulle versioni di anteprima più recenti per l'SDK sottoscrivendo il blog.

OTTIENI NOTIZIE SULLE VERSIONI DI ANTEPRIMA PER L'SDK

Scheda informativa sul ciclo di vita di Windows

Trova le date essenziali per gli aggiornamenti delle versioni di Windows e la fine del supporto.

VEDI LA SCHEDA INFORMATIVA