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

Vista previa de Windows 10 SDK Build 17763 Detalles

28

Windows 10 SDK Preview Build 17763 se acerca a Windows 10 Build 17763 y posteriores con correcciones de errores y mejoras en desarrollo en el área de superficie de la API. La actualización incluye cambios en C++/WinRT, la introducción deMSIX Support, MC.EXE y otras múltiples características.

Esta actualización funciona junto con los SDKs enviados anteriormente y Visual Studio 2017 Puede recibir este SDK y enviar sus aplicaciones que tengan como objetivo Windows 10 v1803 o anteriores a la tienda de Microsoft.

Windows>>Windows

Cosas importantes

• El kit de desarrollo de software de Windows ahora oficialmente sólo será compatible con Visual Studio 2017 y posteriores.
• Puede obtener la imagen ISO del SDK aquí – https://go.microsoft.com/fwlink/?prd=11966&pver=1.0&plcid=0x409&clcid=0x409&ar=Flight&sar=Sdsurl&o1=17763.

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

La actualización de Windows 10 SDK Preview Build 17763 incluye numerosas mejoras y correcciones para C++/WinRT. Lo más importante es que proporciona la capacidad de crear C++/WinRT sin tener que depender del SDK de Windows. Esto es beneficioso para los repositorios de SO además del desarrollador de SO porque no incluye ningún encabezado de Windows. Por lo tanto, un desarrollador generalmente atraerá menos número de dependencias o ninguna de ellas inadvertidamente. La eliminación de la dependencia también lleva a una dramática reducción en el número de macros contra las que un desarrollador de C++/WinRT debe protegerse. Esto indica que C++/WinRT es más portátil y cumple con los estándares. Además, las macros ya no manipularán las cabeceras C++/WinRT. Si anteriormente dependía de C++/WinRT para añadir múltiples encabezados de Windows, ahora tendrá que seguir este proceso por su cuenta.

Aspectos destacados de Windows 10 SDK Preview Build 17763

• Windows 10 SDK Preview Build 17763 permite a un desarrollador usar “get_strong” o “get_weak” reemplazando un puntero crudo cuando crean un delegado apuntando a una función de miembro.
• Microsoft ha añadido una función de cancelación de devolución de llamada en esta compilación, que es la más demandada para el soporte de la rutina C++/WinRT.
• Sin embargo, las APIs máximas tienen una opción para colecciones o arrays, suficientes APIs confían en IBuffer que debería ser más sencillo utilizar este tipo de API de C++. Esta construcción le da acceso directo a los datos detrás de una implementación de IBuffer. Esto utiliza la misma convención de nomenclatura de datos que utilizan los contenedores de biblioteca estándar de C++. El nuevo método también deja de lado los nombres de metadatos que tradicionalmente comienzan con una letra mayúscula.
• La versión actual ha afinado la compatibilidad con los modos de conformidad más estrictos de Clang y Visual C++.
• Encontrará varias mejoras para reducir el tamaño del código, aumentar el inline y optimizar el almacenamiento en caché de fábrica.
• En caso de que un comando que se refiera a una carpeta en lugar de un “winmd” particular, “cppwinrt”, entonces no buscará recursivamente archivos winmd. Esto causa problemas de rendimiento en la construcción del sistema operativo y puede provocar errores de uso que son difíciles de detectar. Esto ocurre cuando los desarrolladores involuntariamente originan cppwinrt para involucrar a más vientos de los esperados. El compilador cppwinrt ahora también maneja duplicados con más sabiduría. Para esto, hace más resistente a los errores del usuario y a los archivos winmd mal formados.
• Las personas que llaman no necesitan declararlas directamente. Sus firmas también han cambiado, lo que equivale a un cambio radical. Las declaraciones disminuyen la mayor parte del dolor de este cambio. Dado que C++/WinRT ya no depende de las cabeceras de Windows y este cambio elimina la dependencia, por lo que la alteración era importante.

Vista previa de Windows 10 SDK Build 17763 Breaking Changes

• En la versión actual, el soporte para interfaces no WinRT está desactivado de forma predeterminada. Para cambiar el estado y habilitar, sólo #include contra cualquier encabezado C++/WinRT.
• winrt::get_abi(winrt::hstring) volverá a ser void* en lugar de HSTRING. El código que necesita el HSTRING ABI puede simplemente usar un static_cast.
• winrt::put_abi(winrt::hstring) volverá a ser void**en lugar de HSTRING*. El código que requiere el HSTRING ABI sólo puede usar un reinterpret_cast.
• HRESULT se proyectará como winrt::hresult. El código que requiere un HRESULT sólo puede usar static_cast cuando se desea comprobar el tipo o apoyar los rasgos del tipo. Alternativamente, es convertible siempre y cuando se añada primero .
• Globally Unique Identifier se proyectará más adelante como winrt::guid. El código que implementa APIs con parámetros GUID debe usar “winrt::guid” en lugar de “winrt::guid”, pero es convertible mientras que se incluye desde el principio.
• En la versión actual, la firma “WINRT_CanUnloadNow” y “WINRT_GetActivationFactory” ha cambiado. El código no debe requerir declarar estas funciones a cualquier costo, sino que debe incluir winrt/base.h para las declaraciones.
• El constructor winrt::handle es explícito. El código que asigna un valor de mango crudo necesariamente llama al método attach en su lugar.
• winrt::clock::from_FILETIME ya está obsoleto. El código debería usar winrt::clock::from_file_time.

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

Soporte para MSIX

Después de recibir Windows 10 SDK Build 17763, puede empaquetar sus aplicaciones como MSIX. Puede ejecutar estas aplicaciones en cualquier dispositivo que tenga la versión 17682 o superior.

Necesitará utilizar la herramienta “MakeAppx” para empaquetar su aplicación con MSIX. Para instalarlo, haga clic en el archivo MSIX. Para saber más sobre MSIX, siga este video introductorio: link

Comentarios y sugerencias son bienvenidos en nuestra comunidad MSIX: http://aka.ms/MSIXCommunity

MSIX no está actualmente soportado por el ACK ni por Microsoft Store.

MC.EXE

Microsoft realiza algunos cambios importantes en la generación de código C/C++ ETW del compilador de mensajes –

El parámetro “-mof” ha sido obsoleto. Este parámetro indica a MC.exe que produzca un código ETW que sea compatible con la versión de Windows XP y anteriores. La compatibilidad con el parámetro -mof se eliminará en una próxima versión de mc.exe.

Aunque no se utiliza el parámetro -mof, el encabezado C/C++ generado ahora es compatible con ambos núcleos, además, con el modo de usuario. No le importa si se especificó -km o -um en la línea de comandos. El encabezado utilizará la “_ETW_KM_ macro” para decidir por sí mismo si se está compilando para el modo kernel o para el modo usuario. Llamará a las APIs ETW adecuadas para cada uno de los modos.

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

Las macros “EventWrite[EventName]” serán inmediatamente predeterminadas para llamar a “EventWriteTransfer” (modo usuario) o “EtwWriteTransfer” (modo kernel). Anteriormente, las macros “EventWrite[EventName]” funcionaban por defecto.

El encabezado actualmente soporta múltiples macros de personalización. Por ejemplo, puede utilizar la macro “MCGEN_EVENTWRITETRANSFER” si necesita que las macros generadas llamen a algo distinto de “EventWriteTransfer”.

El manifiesto soporta nuevos atributos.

Nombre del evento – nombre del evento no localizado.

Atributos de evento: metadatos de valor clave adicionales 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 acompañado de una semántica definida por el usuario (por evento).

Etiquetas” de campo – Valor de 28 bits junto con la semántica definida por el usuario (por campo – válido para elementos “data” o “struct”).

Actualmente se pueden definir los rasgos del proveedor en el manifiesto (por ejemplo, el grupo de proveedores). Cuando se aplican los rasgos del proveedor, la macro “EventRegister[ProviderName]” los registrará.

MC informará ahora sobre un error en la situación en la que falta una cadena de texto en el archivo de mensajes localizado.

MC es ahora capaz de generar salida Unicode con los parámetros -cp utf-8 o -cp utf-16.

Vista previa de Windows 10 SDK Build 17763 Problemas conocidos

En la presente compilación, las cabeceras del SDK se generan utilizando tipos dentro del espacio de nombres ABI. El proceso genera conflictos entre clientes C++/CX y C++/WinRT que necesitan consumir tipos directamente en la capa ABI. Con la configuración incorporada, los tipos lanzados por MIDL son *no* puestos en el espacio de nombres ABI, sin embargo, esto tiene la capacidad de crear conflictos. Esto ocurre entre los equipos con la intención de involucrar tipos ABI de Windows WinRT MIDL y cabeceras no generadas por Windows WinRT MIDL.

La construcción del SDK ha añadido validación a las cabeceras generadas para asegurarse de que los desarrolladores tienen una vista persistente de la superficie de la API de WinRT. Esto también confirma que el prefijo ABI es consistente entre las cabeceras generadas por Windows y las generadas por el usuario. En la situación se encuentra un error, por ejemplo, –

“5>c:ficheros de programas (x86)kits de Windows 10incluyen 10.0.17687.0winrtwindows.foundation.h(83)”: error C2220: advertencia tratada como error – no se ha generado un fichero’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- PATH TO YOUR HEADER HERE>(41)”: nota: véase la definición anterior de ‘CHECK_NS_PREFIX_STATE’

Indica que algo en las cabeceras generadas por MIDL no es consistente con las cabeceras generadas por el sistema.

Hay dos maneras de arreglar esto:

1ª preferencia: Compile su archivo IDL junto con el modificador de línea de comandos “/prefix MIDL”. Esto hará que todos sus tipos sean cambiados al espacio de nombres ABI consistente con las cabeceras de Windows. Sin embargo, esto puede requerir cambios en el código.

Preferencia alternativa – Añada “#define DISABLE_NS_PREFIX_CHECKS” antes de incluir las cabeceras de Windows. Esto suprimirá la validación.

Kit de certificación de aplicaciones de Windows

Al examinar su aplicación con WACK, la prueba puede fallar si incluye 2 o más entradas TargetDeviceFamily en el archivo Package.appxmanifest. Por ejemplo –

MinVersion=”10.0.0.0″

MaxVersionTested=”10.0.0.0″/>

MinVersion=”10.0.0.0″

MaxVersionTested=”10.0.0.0″/>

Puede resolver el problema eliminando una de las entradas de TargetDeviceFamily.

Vista previa de Windows 10 SDK Build 17763 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 soportar el mayor número de dispositivos de Windows 10. Por favor, compruebe la detección dinámica de funciones con contratos de API para obtener más detalles.

Fuente – Blog del desarrollador de Windows.