Windows 10: Windows 10 SDK Preview Build 17692

La vista previa de SDK Build 17692 contiene correcciones de errores y cambios en desarrollo en el área de superficie de la API.

El SDK de vista previa se puede descargar de la sección para desarrolladores de Windows Insider.

Para obtener comentarios y actualizaciones sobre los problemas conocidos, consulte el foro para desarrolladores. Para solicitudes de nuevas funciones de desarrollador, diríjase a nuestra plataforma Windows UserVoice.

Cosas a tener en cuenta:

Esta versión funciona en conjunto con SDKs lanzados anteriormente y Visual Studio 2017. Puede instalar este SDK y seguir enviando sus aplicaciones que tengan como objetivo Windows 10 build 1803 o versiones anteriores a la tienda.
El SDK de Windows ahora formalmente sólo será soportado por Visual Studio 2017 y superior. Puede descargar Visual Studio 2017 aquí.
Esta versión del SDK de Windows sólo se instalará en la vista previa de Windows 10 Insider.

Qué hay de nuevo:

Soporte de MSIX

Por fin ha llegado! Ahora puede empaquetar sus aplicaciones como MSIX! Estas aplicaciones pueden instalarse y ejecutarse en cualquier dispositivo con la versión 17682 o posterior.

Para empaquetar su aplicación con MSIX, use la herramienta MakeAppx. Para instalar la aplicación – simplemente haga clic en el archivo MSIX. Para entender más sobre MSIX, vea este video introductorio: link

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

MSIX no es actualmente compatible con el Kit de certificación de aplicaciones ni con la tienda de Microsoft en este momento.

MC.EXE

Hemos hecho algunos cambios importantes en la generación de código C/C++ ETW de mc.exe (compilador de mensajes):

El parámetro “-mof” es obsoleto. Este parámetro indica a MC.exe que genere código ETW compatible con Windows XP y versiones anteriores. El soporte para el parámetro “-mof” será eliminado en una futura versión de mc.exe.

Mientras no se utilice el parámetro “-mof”, la cabecera C/C++ generada es ahora compatible tanto con el modo kernel como con el modo usuario, independientemente de si se especificó “-km” o “-um” en la línea de comandos. El encabezado utilizará la macro _ETW_KM_ para determinar automáticamente si se está compilando para el modo kernel o para el modo usuario y llamará a las APIs ETW apropiadas para cada modo.

  • La única diferencia que queda entre “-km” y “-um” es que las macros EventWrite[EventName] generadas con “-km” tienen un parámetro Activity ID mientras que las macros EventWrite[EventName] generadas con “-um” no tienen un parámetro Activity ID.

Las macros EventWrite[EventName] ahora están por defecto llamando a EventWriteTransfer (modo usuario) o EtwWriteTransfer (modo kernel). Anteriormente, las macros EventWrite[EventName] por defecto llamaban EventWrite (modo usuario) o EtwWrite (modo kernel).

El encabezado generado ahora soporta varias macros de personalización. Por ejemplo, puede configurar la macro MCGEN_EVENTWRITETRANSFER si necesita que las macros generadas llamen a algo distinto de EventWriteTransfer.
El manifiesto soporta nuevos atributos.

Event “name”: nombre del evento no localizado.

Atributos” de evento: metadatos adicionales de valor clave para un evento, tales como 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 “rasgos del proveedor” en el manifiesto (p. ej., grupo de proveedores). Si se utilizan rasgos del proveedor en el manifiesto, la macro EventRegister[Nombre del proveedor] los registrará automáticamente.
MC ahora reportará un error si a un archivo de mensajes localizado le falta una cadena. (Anteriormente MC generaba silenciosamente un recurso de mensajes corrupto).
MC ahora puede generar salida Unicode (utf-8 o utf-16) con los parámetros “-cp utf-8” o “-cp utf-16”.

 

Problemas conocidos:

Las cabeceras del SDK se generan con tipos en el espacio de nombres “ABI”. Esto se hace para evitar conflictos con clientes C++/CX y C++/WinRT que necesitan consumir tipos directamente en la capa ABI[1]. Por defecto, los tipos emitidos por MIDL son *no* puestos en el espacio de nombres ABI, sin embargo, esto tiene el potencial de introducir conflictos de equipos que intentan consumir tipos ABI desde cabeceras generadas por Windows WinRT MIDL y cabeceras no generadas por Windows WinRT MIDL (esto es especialmente desafiante si las cabeceras que no son de Windows hacen referencia a tipos de Windows).

Para asegurar que los desarrolladores tienen una vista consistente de la superficie de la API WinRT, se ha añadido validación a las cabeceras generadas para asegurar que el prefijo ABI es consistente entre las cabeceras de Windows y las cabeceras generadas por el usuario. Si encuentra un error como:

5>c:\ficheros de programa (x86)\kits de Windows 10, incluyendo 10.0.17687.0\winrt\windows.foundation.h(83): error C2220: warning treated as error – no ‘object’ file generated
5>c:\ficheros de programa (x86)\kits de Windows 10, incluyendo 10.0.17687.0\winrt\windows.foundation.h(83): aviso C4005: “CHECK_NS_PREFIX_STATE”: redefinición macro
5>g:\<PATH TO YOUR HEADER HERE>(41): nota: véase la definición anterior de ‘CHECK_NS_PREFIX_STATE’.

Esto significa que algunas de las cabeceras generadas por MIDL son inconsistentes con las cabeceras generadas por el sistema.

Hay dos maneras de arreglar esto:

Preferido: Compile su archivo IDL con el parámetro de línea de comandos /ns_prefix MIDL. Esto hará que todos sus tipos sean movidos al espacio de nombres ABI consistente con las cabeceras de Windows. Sin embargo, esto puede requerir cambios en el código.
Alternar: Añada #define DISABLE_NS_PREFIX_CHECKS antes de incluir las cabeceras de Windows. Esto suprimirá la validación.

 

Autor de la publicación

Deja un comentario