Inicio ” Windows 10 ” Vista previa de Windows 10 SDK Build 17749 Cambios, Corrección de errores Detalles

Vista previa de Windows 10 SDK Build 17749 Cambios, detalles de corrección de errores

6

Microsoft ha impulsado Windows 10 SDK Preview Build 17749 con un montón de mejoras, personalizaciones y nuevas características. La actualización se ejecutará junto con Windows 10 Insider Build al menos 17749. La compilación incluye múltiples correcciones de errores y cambios en desarrollo en el área de superficie de la API.

Puede descargar Windows 10 SDK Preview Build 17749 desde la región de desarrolladores en el sitio web de Windows Insider.

Windows>>Windows

Cosas notables

• La versión actual de Windows 10 SDK Preview Build 17749 funciona en conjunto con SDKs y Visual Studio 2017 recién lanzados. Puede instalar el SDK e incluso ahora seguir enviando a la tienda sus aplicaciones que tengan como objetivo 1803 Windows 10 o versiones anteriores.
• El SDK de Windows ahora formalmente sólo será soportado por Visual Studio 2017 y superior. Puede descargar Visual Studio 2017 aquí.
• Esta actualización del SDK se instalará en el sistema operativo Windows 10 Insider.

Para facilitar el acceso al SDK, también se podrá acceder a la ISO a través de la siguiente URL: https://go.microsoft.com/fwlink/?prd=11966&pver=1.0&plcid=0x409&clcid=0x409&ar=Flight&sar=Sdsurl&o1=17749 una vez publicada la URL estática.

Actualización de C++/WinRT para Windows 10 SDK Preview Build 17749 y posteriores

Esta actualización incluye múltiples mejoras y correcciones para C++/WinRT. Esto no es especialmente interesante para el desarrollador del sistema operativo, pero incluso en el repositorio del sistema operativo ofrece beneficios porque no incluye ninguna cabecera de Windows. Por lo tanto, un usuario normalmente arrastrará menos dependencias o ninguna inadvertidamente. Esto también indica una reducción considerable en la cantidad de macros contra las que un desarrollador de C++/WinRT debe protegerse.

La eliminación de la dependencia de las cabeceras de Windows significa que C++/WinRT es portátil en mayor medida y cumple con los estándares. Además, el cambio muestra los esfuerzos del equipo para convertirlo en una biblioteca multiplataforma para todos los compiladores. También indica que las cabeceras C++/WinRT nunca serán picadas por macros. Si anteriormente dependía de C++/WinRT para añadir múltiples cabeceras de Windows, ahora tendrá que incluirlas manualmente. Será mejor añadir cabeceras de las que dependa explícitamente y no depender de una biblioteca diferente para incluirlas por usted.

Aspectos destacados de la vista previa de Windows 10 SDK Build 17749

La compilación de soportes get_strong además get_weak para crear delegados – Esta compilación permite que un usuario aplique “get_trong” o “get_weak” para reemplazar un puntero crudo de este punto al generar un delegado que señala una función de miembro. Esta construcción permite al usuario aplicar “get_trong” o “get_weak” para reemplazar un puntero crudo de este puntero cuando se genera un delegado que apunta a una función de miembro.

Include async cancellation callback – La característica más solicitada para el sustento de rutina de C+++/WinRT ha sido la inclusión de una llamada de cancelación.

Simplificar el uso de APIs que esperan parámetros de IBuffer : Sin embargo, muchas APIs prefieren colecciones o matrices, las APIs adecuadas confían en IBuffer que debería ser más sencillo usar tales APIs desde C++. Esta construcción da acceso inmediato a los datos detrás de una implementación de IBuffer utilizando la convención de nomenclatura de datos idéntica aplicada por los contenedores de biblioteca estándar C++. Esto también evita la colisión con nombres de metadatos que empiezan con una letra mayúscula.

Conformidad – Mejor soporte para Clang además de los modos de conformidad más estrictos de Visual C++.

Mejor código gen – Diferentes mejoras para reducir el tamaño del código, modificar el inline y optimizar el almacenamiento en caché de fábrica.

Eliminar recursión no esencial – Si la línea de comandos indica a una carpeta en lugar de a un winmd en particular, entonces cppwinrt no explora recursivamente los archivos winmd. Esto sucede cuando los desarrolladores involuntariamente fuerzan a cppwinrt a comer más viento del necesario. . En esta compilación, el compilador cppwinrt controla los duplicados de forma muy inteligente. Hace que los duplicados sean más resistentes a los errores del usuario y a los archivos winmd defectuosos.

Declarar tanto WINRT_CanUnloadNow como WINRT_GetActivationFactory en base.h – Las personas que llaman no necesitan declararlas directamente. Sus firmas también se han modificado, lo que supone un cambio radical. Las declaraciones disminuyen la mayor parte del dolor de este cambio. La modificación es necesaria por el hecho de que C++/WinRT no depende de las cabeceras de Windows y esto elimina la dependencia de los tipos.

Fortalecer punteros inteligentes : Fortalecer punteros inteligentes – Los revocadores de eventos no revocaron en el momento de la jugada – asignaron un nuevo valor. Esto nos da una visión de cierre de las clases de punteros inteligentes y observamos que no estaban manejando de manera confiable la auto-asignación. Esto está absorbido en la plantilla de clase com_ptr en la que muchos confían. El equipo resolvió com_ptr y modificó los revocadores de eventos para gestionar la semántica de movimientos con precisión para confirmar que “revocan en el momento de la asignación”. La plantilla de la clase handle también se ha visto reforzada por la eliminación del constructor implícito que simplificaba la escritura de código incorrecto. Esto también conduce a errores en el sistema operativo a errores de compilador resueltos en este PR.

Cómo romper los cambios en la vista previa del SDK de Windows 10 Build 17749

En la compilación, los soportes para interfaces no WinRT se desactivan como configuración integrada. Para encenderlo sólo #include antes de las cabeceras C++/WinRT.

“winrt::get_abi(winrt::hstring)” en adelante devuelve “void*” en lugar de “HSTRING”. El código que necesita el HSTRING ABI puede usar lúcidamente un static_cast.

winrt::put_abi(winrt::hstring) devuelve void** reemplazando HSTRING*. El código que necesita el HSTRING ABI puede usar lúcidamente un static_cast.

La construcción actual proyectará GUID como winrt::guid. El código que necesita un HRESULT sólo puede ser static_cast si va a escribir caracteres de tipo checking o support, alternativamente convertible siempre y cuando sea incluido primero.

El proyecto de actualización del SDK GUID como winrt::guid. El código que implementa interfaces de programación de aplicaciones con “GUID parameters” debe aplicar primero “winrt::guid”, pero convertible siempre que se incluya primero “”.

En la actualización del SDK, las firmas de WINRT_CanUnloadNow y WINRT_GetActivationFactory tienen una modificación. El código debe asegurarse de no declarar las funciones anteriores e incluir winrt/base.h para incluir sus declaraciones.

La presente actualización hace que winrt::handle constructor sea explícito. El código que asigna un valor crudo de la manija debe confirmar para llamar al método attach en su lugar.

winrt::clock::from_FILETIME es obsoleto ahora. El código debería aplicarwinrt::clock::from_file_time en su lugar.

Nueva vista previa del SDK de inWindows 10 Build 17749

Soporte para MSIX

La actualización del SDK le permite empaquetar aplicaciones como MSIX. Puede instalar estas aplicaciones y ejecutarlas en sistemas con SDK 17682 y posteriores.

Debe utilizar la herramienta MakeAppx para el empaquetado.

Actualmente, MSIX no es compatible con el Kit de certificación de aplicaciones ni con el Microsoft Store.

MC.EXE

La compilación viene con algunas modificaciones a la generación de código C/C++ ETW de mc.exe.

Después de esta construcción, el parámetro “-mof” es ahora obsoleto. Este parámetro sugiere que MC.exe cree un código ETW que sea compatible con Windows XP y anteriores. Microsoft eliminará el soporte para el parámetro “-mof” en una futura edición de mc.exe.

Mientras no esté implicado el parámetro “-mof”, la cabecera de salida C/C++ soporta ahora ambos modos de kernel y de usuario. A esto no le importa si se especificó “-km” o “-um” en la línea de comandos. El encabezado aplicará la macro _ETW_KM_ para determinar si está siendo compilada en modo kernel o en modo usuario. Llamará a las APIs ETW correctas para cada modo.

• La única diferencia superflua entre “-km” y “-um” es que las macros EventWrite[EventName] creadas con “-km” incluyen un parámetro Activity ID. Mientras tanto, las macros EventWrite[EventName] generadas con “-um” no incluyen un parámetro Activity ID.

Las macros EventWrite[EventName] están incorporadas para llamar a EventWriteTransfer (modo usuario) o EtwWriteTransfer (modo kernel). Anteriormente, las macros “EventWrite[EventName]” por defecto llamaban a “EventWrite” (modo usuario) o a “EtwWrite” (modo kernel).

• El encabezado creado ahora soporta múltiples macros de personalización. Por ejemplo, puede configurar la macroinstrucción MCGEN_EVENTWRITETRANSFER cuando necesite que las macros generadas llamen a algo que esté en desacuerdo con EventWriteTransfer.
• El manifiesto confirma atributos adicionales.
  Event “name”: nombre del evento no localizado.
  Atributos” de eventos: metadatos adicionales de valores clave para un evento, por ejemplo, nombre de archivo, línea, componente y función.
  Etiquetas de eventos: Valor de 28 bits con semántica definida por el usuario.
  Campo “tags”: Valor de 28 bits con semántica definida por el usuario (por campo – puede utilizarse para “datos” o “estructurar” elementos).
• Puede definir a continuación las características del proveedor en el manifiesto (por ejemplo, el grupo de proveedores). Cuando los rasgos del proveedor se aplican en el manifiesto, la propia macro EventRegister[Nombre del proveedor] los registrará.
• MC ahora lanzará un error si un archivo de mensajes localizado se pierde una cadena.
• MC puede ahora crear una salida Unicode (UTF-8/UTF-16) con los parámetros “-cp utf-8” o “-cp utf-16”.

Problemas conocidos en la vista previa del SDK de Windows 10 Build 17749

Las cabeceras del SDK se crean con tipos en el espacio de nombres ABI. Esto se hace para dejar de lado los conflictos con clientes C++/CX y C++/WinRT que requieren consumir tipos directamente en la capa ABI[1]. Con la configuración incorporada, los tipos emitidos por MIDL no se incluyen en el espacio de nombres ABI. Aunque, esto tiene la capacidad de aumentar los conflictos de los equipos que intentan utilizar tipos de ABI de Windows WinRT MIDL, además de las cabeceras generadas por WinRT MIDL que no son de Windows.

Confirmar que los desarrolladores tienen una vista continua de la superficie de la Interfaz de Programación de Aplicaciones WinRT. La validación ha sido incluida en las cabeceras generadas para asegurar que el prefijo ABI es persistente entre las cabeceras generadas por el usuario de Windows. Si se enfrenta a un error como por ejemplo-

5>c:ficheros de programas (x86)kits de ventanas10incluyen10.0.17687.0winrtwindows.foundation.h(83): error C2220: warning treated as error – no se genera ningún archivo’object’

5>c:ficheros de programas (x86)kits de ventanas10incluyen10.0.17687.0winrtwindows.foundation.h(83): warning C4005:’CHECK_NS_PREFIX_STATE’: redefinición de macros

5>g:N- PATH TO YOUR HEADER HERE>(41): note: see previous definition of ‘CHECK_NS_PREFIX_STATE’

Indica que algunas de las cabeceras generadas por MIDL son inconsistentes con las cabeceras creadas por el sistema.

Hay dos métodos para arreglar esto –

• Preferred way – Compila tu archivo IDL junto con el parámetro de línea de comandos /ns_prefix MIDL. Esto creará tipos enteros para ser movidos al espacio de nombres ABI consistente además de las cabeceras de Windows. Sin embargo, es posible que sea necesario modificar el código.
• Modo alternativo – Añadir “#define DISABLE_NS_PREFIX_CHECKS” antes de incluir las cabeceras de Windows. Esto suprimirá con éxito la validación.

Fallos del kit de certificación de aplicaciones de Windows

En la actualización actual del SDK (17749), el Kit de certificación de aplicaciones de Windows se bloqueará. Por lo tanto, Microsoft recomienda evitar esto desmarcando la opción durante la instalación.

Actualizaciones, adiciones y eliminaciones de la API

Cuando se dirija a nuevas APIs, piense en escribir su aplicación para que sea adaptable y pueda cubrir los extensos dispositivos de Windows 10.

Fuente – Blog del desarrollador de Windows