Inicio ” Windows 10 ” Vista previa del SDK de Windows 10 Build 17758 Detalles

Vista previa de Windows 10 SDK Build 17758 Detalles

22

Windows 10 SDK Preview Build 17758 llegó para trabajar en conjunto con Windows 10 Build 17758 o posterior. La nueva versión del kit incluye correcciones de errores, cambios en el subdesarrollo, características y mejoras en el área de superficie de la API. Desde la compilación 17444, Microsoft ha eliminado algunas API y le ofrece una lista aquí.

Puede recibir la vista previa de Windows 10 SDK Build 17758 desde la sección para desarrolladores de Insider. Le ofrecen la posibilidad de solicitar, enviar un problema y recibir comentarios sobre la plataforma Uservoice.

Windows>>Windows

Cosas importantes

Esta actualización actual funcionará junto con la versión anterior de SDKs, incluido Visual Studio 2017. Puede instalar este SDK y, sin embargo, también puede enviar sus aplicaciones que tengan como objetivo Windows 10 1803 o anteriores a la tienda.

El Kit del desarrollador de software de Windows ahora sólo será compatible formalmente con Visual Studio 2017 y posteriores. Puede descargar el Visual Studio 2017aquí.

Esta versión del SDK de Windows se instalará posteriormente en las versiones de Insider Preview y en el sistema operativo Windows compatible.

Con el fin de facilitar el acceso al guión, también se puede acceder a la ISO a través de este enlace.

Actualización de C++/WinRT para la versión 17709 y posteriores

Windows 10 SDK Preview Build 17758 inicia varias mejoras y correcciones para C++/WinRT. Lo más importante es que tiene la capacidad de construir C++/WinRT sin necesidad de depender del SDK de Windows. Esto no es específicamente intrigante para el desarrollador, pero incluso en el repositorio del sistema operativo, da beneficios porque no comprende ninguna cabecera de Windows. Por lo tanto, un desarrollador típicamente atraerá menos o ninguna dependencia involuntariamente. Esto también indica una considerable disminución en el número de macros que un desarrollador de C++/WinRT debe cuidar. Por lo tanto, C++/WinRT es más portátil y cumple con los estándares y Microsoft está tratando de convertirlo en una biblioteca de compiladores y plataformas cruzadas. Además, las macros nunca pueden manipular cabeceras C++/WinRT. Usted mismo tendrá que incluir diferentes encabezados de Windows. Sabes que es mejor incluirlos sin depender de otra biblioteca.

Vista previa de Windows 10 SDK Build 17758 Highlights

La construcción actual Soporte get_strong y get_weak para crear delegados – Esta actualización permite a un desarrollador usar “get_trong” o “get_weak” en lugar de un puntero crudo. Esto es útil cuando se crea un delegado que señala una función de miembro.

Agregar llamada de cancelación de asíncronos – Los desarrolladores han estado exigiendo constantemente esta función. La devolución de llamada de cancelación tiene la extensión de soporte de la rutina C++/WinRT.

La construcción del SDK hace más comprensible el uso de APIs que esperan parámetros de IBuffer – Esta actualización ofrece acceso directo a los datos detrás de una implementación de IBuffer utilizando la misma convención de nomenclatura de datos utilizada por los contenedores de biblioteca estándar C++. Esto también restringe la colisión de nombres de metadatos que tradicionalmente comienza con una letra mayúscula.

Conformidad – Theupdate proporciona una mejor compatibilidad con los modos de conformidad más estrictos de Visual C++ y Clang.

La actualización ha mejorado el código gen – Diferentes cambios para disminuir el tamaño del código, proporcionan un mejor inlining y además optimizan el almacenamiento en caché de fábrica.

Cortar recursión innecesaria : Cuando la línea de comandos se dirige a una carpeta en lugar de a unwinmd en particular, cppwinrt no buscará recursivamente archivos “winmd”. Provoca problemas de rendimiento en la construcción de Windows y puede provocar errores de uso. Estos son rigurosos para detectar cuando los desarrolladores inadvertidamente utilizan el viento para consumir más vientos de los esperados. Después de la mejora, el compilador cppwinrt ahora también maneja los duplicados más sabiamente. El cambio hace que sea más flexible a los errores del usuario y a los archivoswinmd mal formados.

Esta actualización declara tanto “WINRT_CanUnloadNow” como “WINRT_GetActivationFactory” en base.h – Después de la llegada de este SDK, las personas que llaman están libres de declararlos directamente. Sus firmas también han cambiado, lo que equivale a un cambio radical. Las declaraciones reducen la mayor parte del dolor de este cambio. El cambio era necesario porque C++/WinRT ya no depende de las cabeceras de Windows. Esta mejora elimina la dependencia de los tipos de las cabeceras de Windows.

Fortalecer los punteros inteligentes – Después de la llegada de Windows Preview SDK Build 17758, los revocadores de eventos no se revocaron cuando se asignó un nuevo valor a mover. Microsoft corrigió este error después de una investigación adecuada.

Vista previa de Windows 10 SDK Build 17758 Breaking Changes

En Windows 10 SDK Preview Build 17758, la compatibilidad con interfaces que no sean WinRT no está habilitada por la configuración incorporada. Para habilitarlo, sólo #include anterior a cualquier encabezado C++/WinRT.

winrt::get_abi(winrt::hstring) devuelve void* en lugar de HSTRING. El código que requiere el HSTRING ABI puede utilizar directamente un static_cast.

winrt::put_abi(winrt::hstring) devuelve void** en lugar de HSTRING*. El código que requiere HSTRING ABI puede utilizar directamente un reinterpret_cast.

HRESULT se proyecta además como winrt::hresult. El código que requiere un HRESULT sólo puede static_cast si necesita hacer verificación de tipo o soportar rasgos de tipo, pero es convertible siempre y cuando sea incluido primero.

El identificador único global se proyecta ahora como winrt::guid… El código que implementa APIs con parámetros GUID utiliza winrt::guid. Pero lo mismo es por lo demás convertible siempre y cuando se incluya inicialmente.

“WINRT_CanUnloadNow” además “WINRT_GetActivationFactory” Las firmas han cambiado. Code no requiere declarar estas funciones en absoluto y alternativamente incluye winrt/base.h para añadir sus declaraciones.

El constructor winrt::handle es actualmente explícito. El código que asigna un valor crudo de la manija requiere llamar al método attach en su lugar.

winrt::clock::from_FILETIME es ahora obsoleto. El código debería llevarwinrt::clock::from_file_time al uso.

Novedades en la vista previa del SDK de Windows 10 Build 17758

Soporte para MSIX

Debe utilizar la herramienta MakeAppx para empaquetar su aplicación con MSIX. Para iniciar la instalación, simplemente haga clic en el archivo MSIX.

En Windows Preview SDK Build 17758, usted puede empaquetar su desarrollo de aplicaciones como MSIX! Para instalar la aplicación – simplemente haga clic en el archivo MSIX. Para saber más sobre MSIX, vea el video introductorio que se encuentra aquí.

Puedes enviar comentarios y sugerencias sobre la Comunidad MSIX.

MC.EXE

Windows Preview SDK Build 17758 presenta algunos cambios consecuentes en la generación de código C/C++ ETW de mc.exe –

El parámetro -mof ha sido obsoleto en esta actualización. Este parámetro “.mof'” guía MC.exe para generar código ETW compatible con Windows XP y anteriores. El soporte para el parámetro – mof será eliminado en una próxima versión de mc.exe.

Aunque no se utilizará el parámetro”-mof, la cabecera C/C++ es ahora compatible tanto con el modo kernel como con el modo usuario. No es necesario especificar “-km” o “-um” en la línea de comandos para ello. El encabezado aplicará la macro _ETW_KM_ a sí mismo para comprobar si está siendo compilada en modo usuario o en modo kernel. Esto llamará a las APIs ETW aplicables para cada modo.

Sólo hay una diferencia entre “-km” y “-um”. Las macros EventWrite[EventName] generadas con “-km” tienen un parámetro Activity ID mientras que las macros EventWrite[EventName] no.

En SDK Build 17758, las macros “EventWrite[EventName]” pagan un papel por defecto con el fin de llamar “EventWriteTransfer” (modo usuario) o “EtwWriteTransfer” (modo kernel). Anteriormente, las macros EventWrite[EventName] eran las predeterminadas para el mismo.

El encabezado generado soportará además múltiples macros de personalización. Por ejemplo, tiene la opción de establecer la macro “MCGEN_EVENTWRITETRANSFER” si desea que las macros generadas llamen a cualquier otra cosa que no sea EventWriteTransfer.

“El manifiesto soporta nuevos atributos”.

Event “name”: nombre del evento no localizado.

Atributos” de eventos: metadatos adicionales de valores clave para un evento, por ejemplo, nombre de archivo, número de línea, nombre de componente, nombre de función.

Etiquetas de eventos: Valor de 28 bits con semántica definida por el usuario (por evento).

Campo “tags”: Valor de 28 bits con semántica definida por el usuario (por campo – puede aplicarse a elementos “data” o “struct”).

Ahora puede definir los “rasgos del proveedor” en el manifiesto. Si los rasgos del proveedor se aplican en el manifiesto, la propia macro EventRegister[Nombre del proveedor] los registrará.

MC informará además de un error si un archivo de mensajes localizado está perdiendo una cadena (anteriormente MC generaría un recurso de mensajes corrupto.)

El compilador de mensajes ahora puede generar salida Unicode (UTF-8 o UTF-16) con los parámetros “-cp utf-8” o “-cp utf-16”.

Vista previa de Windows 10 SDK Build 17758 Problemas conocidos

En la construcción actual, las cabeceras se generan con tipos en el espacio de nombres ABI. La ejecución minimiza los conflictos entre clientes C++/CX y C++/WinRT que necesitan consumir tipos directamente en la capa ABI[1]. Con la configuración incorporada, los tipos desechados por MIDL *no* se ponen en el espacio de nombres ABI. A pesar de esto tiene el potencial de crear conflictos de equipos que intentan consumir tipos ABI de las cabeceras generadas por Windows WinRT MIDL, además de no ser Windows WinRT MIDL.

Confirmando que los desarrolladores tienen una visión consistente de la Interfaz de Programación de Aplicaciones WinRT, se ha incluido la validación en las cabeceras generadas. Esto también asegura que el prefijo ABI sea consistente en el centro de las cabeceras de Windows y de las cabeceras generadas por el usuario. Si se enfrenta a un error como:

“5>c:Nficheros de programas (x86) kits de ventanas 10 incluyen 10.0.17687.0 Windows.foundation.h(83) </ i&gt: "error C2220": advertencia tratada como error – no se genera un archivo'object'

5>c:Nficheros de programas (x86)Kits de Windows 10, incluyendo 10.0.17687.0NWindows.foundation.h(83): “advertencia C4005: “CHECK_NS_PREFIX_STATE”: redefinición de macros

“5>g:N(41)”: nota: véase la definición anterior de “CHECK_NS_PREFIX_STATE”.

Indica que ciertas cabeceras generadas por MIDL son inconsistentes con respecto a las cabeceras generadas por el sistema.

Hay dos maneras de arreglar esto:

1. Compile su archivo IDL con el parámetro de línea de comandos /ns_prefix MIDL. Esto moverá todos los tipos al espacio de nombres ABI de acuerdo con las cabeceras de Windows. Sin embargo, tendrá que cambiar el código.
2. “Añadir #define DISABLE_NS_PREFIX_CHECKS” antes de incluir las cabeceras de Windows. Este método suprimirá la validación.

Windows 10 SDK Preview Build 17758 Actualizaciones, adiciones y eliminaciones de la API

Cuando se dirige a nuevas interfaces de programación de aplicaciones, puede escribir su aplicación para que se adapte y funcione correctamente en un máximo de dispositivos Windows 10. Por favor, eche un vistazo a la detección dinámica de características con contratos de API para más detalles.

Fuente – Windows Developer Blog.