Windows SDK

Windows SDK (10.0.22621) per Windows 11 versione 22H2 fornisce le intestazioni, le librerie, i metadati e gli strumenti più recenti per la creazione di applicazioni Windows. Usare questo SDK per compilare applicazioni piattaforma UWP (Universal Windows Platform) (UWP) e Win32 per Windows 11, versione 22H2 e versioni precedenti Windows.

Suggerimento

Windows App SDK
Il SDK per app di Windows fornisce un set unificato di API e strumenti separati dal sistema operativo e rilasciati agli sviluppatori tramite pacchetti NuGet. Queste API e strumenti possono essere usati in modo coerente da qualsiasi app desktop in Windows 11 e livello inferiore per Windows 10, versione 1809.

Guida introduttiva

È possibile ottenere Windows SDK in due modi: installarlo da questa pagina selezionando il collegamento di download o selezionando "Windows 11 SDK (10.0.22621.0)" nei componenti facoltativi del programma di installazione Visual Studio 2022. Prima di installare l'SDK:

Ultimo aggiornamento: 4 ottobre 2021

Requisiti di sistema

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

Sistemi operativi supportati

  • Windows 10 versione 1507 o successiva: Home, Professional, Education e Enterprise (LTSB e S non sono supportati per la piattaforma UWP)
  • Windows Server 2022, Windows Server 2019, Windows Server 2016 e Windows Server 2012 R2 (solo 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

L'installazione in Windows 8.1 e nei sistemi operativi precedenti richiede un aggiornamento per Universal C Runtime in Windows. 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.

Esempi

Windows sono ora disponibili esempi di app tramite GitHub. È possibile 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 si usano nuove API, è consigliabile scrivere l'app in modo che sia adattiva in modo che venga eseguita correttamente nella matrice più ampia di dispositivi Windows. Un'app adattiva "si accende" con nuove funzionalità ovunque i dispositivi e Windows versione li supporti, ma in caso contrario offre solo le funzionalità disponibili nella versione della piattaforma rilevata. Per informazioni dettagliate sull'implementazione, vedere l'articolo Codice adattivo versione.

Note sulla versione e problemi noti

Windows 10 SDK, versione 2104
  • Rimosso api-ms-win-net-isolation-l1-1-0.lib. Le app che si collegavano a api-ms-win-net-isolation-l1-1-0.lib possono passare a t OneCoreUAP.lib come sostituzione.

  • Rimosso irprops.lib. Le app che si collegavano a irprops.lib possono passare a bthprops.lib come sostituzione.

  • Spostato tag ENUMServerSelection da wuapicommon.h a wupai.h e rimosso l'intestazione. Se si vuole usare il tag ENUMServerSelection, è necessario includere wuapi.h o wuapi.idl.

  • Il pacchetto API WinRT Windows 10 consente di aggiungere le API e le API di Windows Runtime più recenti alle librerie e alle app di .NET Framework 4.5+ e .NET Core 3.0+. Per accedere al Windows 10 WinRT API Pack, vedere Microsoft.Windows. SDK. Contratti pacchetto nuget.

  • La famiglia di funzioni printf ora è conforme alle regole di arrotondamento IEEE 754 quando si stampano numeri a virgola mobile esattamente rappresentabili e rispetta la modalità di arrotondamento richiesta tramite chiamate a fesetround. Il comportamento legacy è disponibile quando si esegue il collegamento con legacy_stdio_float_rounding.obj.

  • Windows Kit di certificazione app. Sono state aggiunte diverse nuove API all'elenco API supportate nel Kit di certificazione app e Windows Store. Se sono presenti API nell'elenco supportato visualizzate in grigio o disabilitate in Visual Studio, è possibile apportare una piccola modifica al file di origine per accedervi. Per altri dettagli, vedere questo problema noto. Trovare altri aggiornamenti ai test.

  • Aggiornamenti del compilatore di messaggi (mc.exe):

    • Ora rileva il byte order mark (BOM) Unicode nei file con estensione mc. Se il file mc inizia con un BOM UTF-8, verrà letto come file UTF-8. In caso contrario, se inizia con un BOM UTF-16LE, verrà letto come file UTF-16LE. Se il parametro -u è stato specificato, verrà letto come file UTF-16LE. In caso contrario, verrà letto usando la tabella codici corrente (CP_ACP).
    • Ora evita problemi con una sola definizione (ODR) negli helper ETW generati da MC C/C++ causati da macro di configurazione in conflitto (ad esempio, quando due file CPP con definizioni in conflitto di MCGEN_EVENTWRITETRANSFER 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 anziché scegliere arbitrariamente uno o l'altro).
  • aggiornamenti Windows preprocessore di traccia (tracewpp.exe):

    • Supporta i file di input Unicode (.ini, tpl e codice sorgente). I file di input che iniziano con un indicatore di ordine di byte UTF-8 o UTF-16 verranno letti come Unicode. I file di input che non iniziano con un BOM verranno letti usando la tabella codici corrente (CP_ACP). Per la compatibilità con le versioni precedenti, se viene specificato il parametro della riga di comando -UnicodeIgnore, i file che iniziano con un BOM UTF-16 verranno considerati vuoti.
    • Supporta i file di output Unicode (con estensione tmh). Per impostazione predefinita, i file di output verranno codificati usando la tabella codici corrente (CP_ACP). Usare i parametri della riga di comando -cp:UTF-8 o -cp:UTF-16 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 Unicode ed eseguivano l'elaborazione del testo presupponendo un set di caratteri a byte singolo. Ciò può causare modifiche al comportamento nei casi in cui i file di input non sono conformi alla tabella codici corrente. Nei casi in cui si tratta di un problema, valutare la possibilità di convertire i file di input in UTF-8 (con BOM) e/o usando il parametro della riga di comando -cp:UTF-8 per evitare ambiguità di codifica.
  • Aggiornamenti di TraceLoggingProvider.h:

    • Evita problemi di una regola di definizione (ODR) causati da macro di configurazione in conflitto (ad esempio, quando due file cpp con definizioni in conflitto di TLG_EVENT_WRITE_TRANSFER 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 anziché scegliere arbitrariamente uno o l'altro).
    • Nel codice C++ la macro TraceLoggingWrite è stata aggiornata per consentire una migliore condivisione del codice tra eventi simili usando modelli variadic.
  • Firma delle app. La firma di Device Guard è una funzionalità di Device Guard disponibile in Microsoft Store per le aziende ed Education, che consente alle aziende di garantire che ogni app provenga da un'origine attendibile. Vedere la documentazione sulla firma di Device Guard.

  • Le intestazioni SDK sono state aggiornate per risolvere gli errori durante la compilazione usando il preprocessore C conforme allo standard nel compilatore MSVC cl.exe (/Zc:preprocessor, introdotto in VS 2019 v16.6).

  • Corretto: "GdiplusTypes.h non viene compilato con NOMINMAX". Vedere Visual Studio Commenti e suggerimenti.

  • Quando si compila con /std:c11 o /std:c17, si ottiene ora:

    • C99 tgmath.h
    • C11 static_assert in assert.h
    • C11 stdalign.h
    • C11 stdnoreturn.h
  • Clang/LLVM per Windows versione 11 di destinazione ARM64 non è compatibile con la versione più recente di winnt.h

    • Come soluzione alternativa, usare la versione precedente di Windows 10 SDK (build 19041) o clang/LLVM per Windows v10 per le piattaforme ARM64
  • DirectXMath (inclusa la versione 3.16 in questa versione) non è compatibile con Clang/LLVM per Windows in ARM64.

  • Il caso di alcuni file di intestazione è stato modificato in modo da normalizzare i file system con distinzione tra maiuscole e minuscole:

    • OAIdl.h, ObjIdl.h, ObjIdlbase.h, OCIdl.h, Ole2.h, OleAuto.h e OleCtl.h sono stati tutti fatti in minuscolo.
    • Per le build Clang/LLVM per Windows, supportare sia la versione precedente che l'SDK più recente Windows 10 senza avvisi, aggiungere -Wno-nonportable-system-include-path all'interfaccia della riga di comando o il #pragma seguente nell'origine:

    #ifdef __clang__

    #pragma clang diagnostic ignored "-Wnonportable-system-include-path"

    #endif

Windows 10 SDK, versione 2004 dell'aggiornamento di manutenzione (rilasciato 12/16/2020)

Questa versione contiene i file seguenti. Se si verificano questi problemi, è consigliabile aggiornare la versione dell'SDK il prima possibile per evitare:

  • Risolta in modo imprevedibile e difficile da diagnosticare gli arresti anomali quando si collegano sia librerie di ombrelli che librerie del sistema operativo native (ad esempio, onecoreuap.lib e kernel32.lib)
  • Problema risolto che impediva il funzionamento di AppVerifier
  • Problema risolto che causava l'esito negativo di WACK con "Attività non riuscita ad abilitare HighVersionLie"

Altre risorse