Inicio ” Windows 10 ” Vista previa de Windows 10 SDK Build 17754 Fixes and Improvements Details

Vista previa de Windows 10 SDK Build 17754 Fixes and Improvements Details

13

Microsoft publicó Windows 10 Preview SDK Build 17754 que incluye un montón de correcciones y mejoras. características. El foco de atención de esta actualización esC+++/WinRT Update para la build 17709,nuevos atributos,Better code gen, y otros. Es posible que encuentre algunos errores en la compilación del SDK guardados bajo los problemas conocidos, pero esto se paliará en el próximo lanzamiento.

Esta edición del SDK funcionará con un mínimo de Windows 10 Insider Build 17754. Puede descargar la actualización desde el campo Modo de desarrollador de Configuración de Windows.

Windows 10 Vista previa SDK Build 17754 –

Windows>>Windows

Puntos importantes

Windows 10 Preview SDK Build 17754 funciona en conjunto con SDKs promulgados anteriormente y Visual Studio 2017. Puede instalar este kit de desarrollador y, sin embargo, seguir enviando sus aplicaciones que tengan como objetivo Windows 10 V1803 o anteriores a la tienda.

Puede obtener acceso al SDK 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=17754 una vez publicada la URL estática.

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

Esta actualización incluye múltiples cambios y correcciones para C++/WinRT. Significativamente, comenzó la capacidad de construir C++/WinRT y esto no está teniendo una dependencia del SDK de Windows. La característica permite que el repositorio no incluya ninguna cabecera de Windows. Así, un desarrollador se vuelve capaz de atraer a un número menor de dependencias o de no tenerlas por inadvertencia. Así que el desarrollador de C++/WinRT debe protegerse contra menos macros. La portabilidad y el estándar de NOW C++/WinRT se han incrementado y en adelante están intentando convertirlo en una librería de compiladores y plataformas cruzadas. Esto también indica que las macros no pueden manipular cabeceras C++/WinRT. Ahora necesitará incluir varias cabeceras de Windows por su cuenta en lugar de depender de C++/WinRT. Se supone que siempre es una buena práctica añadir cabeceras de las que depende explícitamente y no depender de otra biblioteca.

Vista previa de Windows 10 SDK Build 17754 Highlights

SDK Build 17754 Soporta get_trong y get_weak – Puede aplicar “get_trong” además “get_weak” en lugar de un puntero crudo en el momento de desarrollar un delegado apuntando a una función de miembro.

Agregar llamada de cancelación de asíncronos – Muchos desarrolladores estaban solicitando repetidamente soporte para la rutina C++/WinRT. Esto ha sido la adición de una llamada de cancelación.

Hace que las APIs que esperan parámetros de IBuffer sean más fáciles – Sin embargo, las interfaces de programación de aplicaciones máximas prefieren elegir colecciones o matrices, lo suficiente como para confiar en IBuffer para que sea más fácil de usar desde C++. Esta construcción da acceso directo a los datos detrás de la aplicación de IBuffer con la convención de nomenclatura de datos idéntica aplicada por los contenedores de biblioteca estándar C++. El método evita la colisión con nombres de metadatos que tradicionalmente comienzan con una letra mayúscula.

Conformidad – La versión actual proporciona mejor soporte para Clang, incluyendo los modos de conformidad más estrictos de Visual C++.

Mejor código gen – Encontrará diferentes cambios para disminuir el tamaño del código, aumentar el inline y optimizar el almacenamiento en caché de fábrica.

La compilación elimina la recursión inútil – Si el comando se dirige a una carpeta en lugar de a unwinmd en particular, cppwinrt no buscará recursivamente archivos winmd. Esto crea problemas de rendimiento en la construcción del sistema operativo y puede iniciar errores de uso que son difíciles de detectar. Ocurre si los desarrolladores inadvertidamente intentan usar winmdsin más de lo esperado. Debe estar contento de saber que el compiladorcppwinrt también gestiona los duplicados de forma más inteligente. Para este propósito, el compilador lo hace más flexible a los archivos de error del usuario y badwinmd.

Declarar tanto “WINRT_CanUnloadNow” como “WINRT_GetActivationFactory in base.h”. : – Después de recibir la actualización, las personas que llaman ya no necesitan declararlos directamente. Las firmas de la persona que llama se han alterado, lo que equivale a un cambio radical. Los cambios se hacen debido al C++/WinRT que no dependerá de las cabeceras de Windows. Estas modificaciones eliminan la dependencia de los tipos de las cabeceras de Windows.

Fortalecer los punteros inteligentes – La actualización actual resuelve com_ptr y actualiza los revocadores de eventos para gestionar correctamente la semántica de movimientos y confirmar que se revocan en el momento de la asignación. También endureció la plantilla de clase eliminando el constructor implícito.

Vista previa de Windows 10 SDK Build 17754 Breaking Changes

Los desarrolladores del SDK de Windows le permiten habilitar el soporte para interfaces no WinRT en esta versión. En este sentido, Sólo #incluye antes de cualquier encabezado C++/WinRT.

“winrt::get_abi(winrt::hstring)” devuelve además void* reemplazando “HSTRING”. El Código que necesita el HSTRING ABI apenas puede usar un static_cast.

“winrt::put_abi(winrt::hstring)” devuelve void** en lugar de HSTRING*. El código que requiere el HSTRING ABI puede simplemente aplicar un reinterpret_cast.

Windows 10 Preview SDK Build 17754 proyecta winrt::hresult for HRESULT. El código que necesita un HRESULT sólo puede static_cast si desea realizar una comprobación de tipo o admitir caracteres de tipo. Pero es convertible siempre y cuando se incluya primero .

El proyecto de construcción winrt::guid para GUID. Es por eso que el código que implementa APIs con parámetros GUID debe ingresarwinrt::guid, pero es alternativamente convertible siempre y cuando sea incluido primero.

En el SDK, las firmas “WINRT_CanUnloadNow” y “WINRT_GetActivationFactory” han sido modificadas. Por lo tanto, el código debe evitar la declaración de estas funciones e incluir winrt/base.h para incluir sus declaraciones.

Después de la llegada de Windows 10 Preview SDK Build 17754, winrt::handle constructor es explícito. Por lo tanto, el código que asigna un valor crudo a la manija debe llamar al método attach.

“winrt::clock::from_FILETIME” ha sido obsoleta. Por lo tanto, el código debería aplicar winrt::clock::from_file_time.

Novedades en Windows 10 Vista previa del SDK Build 17754

Soporte para MSIX

Windows 10 Preview SDK Build 17754 le facilita empaquetar sus aplicaciones como MSIX! Puede instalar estas aplicaciones y ejecutarlas en cualquier dispositivo que ejecute la versión 17682 o posterior.

La herramienta MakeAppx viene como una utilidad para instalar la aplicación. Simplemente haga clic en el archivo MSIX. Sigue este video para aprender -MSIX: Inside and Out.

Actualmente, MSIX no es compatible con el Kit de certificación de aplicaciones (ACK) ni con la tienda de Microsoft.

MC.EXE

Los desarrolladores del SDK introducen algunas mejoras en la generación de código C/C++ ETW de mc.exe –

En Windows 10 Preview SDK Build 17754, -mofparameter es obsoleto. Esto hace que MC.exe desarrolle código ETW compatible con Windows XP y anteriores. La característica terminará en una futura edición de mc.exe.

La cabecera C/C++ es compatible tanto con el modo kernel como con el modo usuario hasta que no se utilice el parámetro -mof. A esto no le importa si se especificó -km o -um en la línea de comandos. En este proceso, el encabezado aplicará la macro _ETW_KM_ para detectar si va a ser utilizada en modo kernel o en modo usuario. Esto llamará a las APIs ETW adecuadas para cada uno de los dos modos.

La única diferencia entre -km y -um. Se trata de las macros EventWrite[EventName] generadas con -km que incluyen un parámetro Activity ID. Mientras que las macros EventWrite[EventName] generadas con -um no incluyen un parámetro Activity ID.

Después de que Windows 10 Preview SDK Build 17754, las macros “EventWrite[EventName] macros” funcionan por defecto para llamar a EventWriteTransfer modo usuario o modo kernel.

La nueva cabecera en adelante soporta múltiples macros de personalización. Puede configurar la macro MCGEN_EVENTWRITETRANSFER si desea que las macros generadas llamen a algo diferente 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, componente y nombre de función.

Las etiquetas de eventos indican un valor de 28 bits junto con la semántica definida por el usuario (de acuerdo con el evento).

Etiqueta de campo – Valor de 28 bits con semántica definida por el usuario (para cada -campo- puede aplicarse a datos o elementos estructurales).

Ahora puede definir los rasgos del proveedor en el manifiesto (también conocido como grupo de proveedores). La macro “EventRegister[ProviderName] macro” se registrará sin su esfuerzo cuando utilice los rasgos del proveedor en el manifiesto.

MC mostrará ahora un error cuando un archivo de mensajes localizado esté ausente en una cadena.

MC ahora puede proporcionar salida Unicode (UTF-8 o UTF-16) con los parámetros -cp utf-8 o -cp utf-16.

Problemas conocidos

Una vez que obtenga Windows 10 Preview SDK Build 17754 en su máquina, las cabeceras se desarrollan con tipos en el espacio de nombres ABI. Esto evita choques con clientes “C++/CX” y “C+++/WinRT” que requieren gastar tipos directamente en la “capa ABI[1]”. Con la configuración incorporada, los tipos emitidos por MIDL *no* se ponen en el espacio de nombres ABI. Aunque, esto tiene la similitud con los conflictos iniciales de los equipos que intentan comer tipos de ABI de Windows WinRT MIDL y de cabeceras generadas por WinRT MIDL que no son de Windows.

Para asegurarse de que los desarrolladores tienen un aspecto persistente sobre la superficie de la API de WinRT, Microsoft ha añadido validación a las cabeceras generadas. Esto confirmará que el prefijo ABI es invariable entre el Windows y las cabeceras generadas por el usuario. Si encuentra 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 el 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)”: nota: véase la definición anterior de “CHECK_NS_PREFIX_STATE”.

Indica que ciertas cabeceras desarrolladas por MIDL no son consistentes con las cabeceras generadas por el sistema.

Hay dos métodos para arreglar esto –

1ª opción – Compila tu archivo IDL con el parámetro /ns_prefix MIDL de la línea de comandos. Este método enviará todos sus tipos al espacio de nombres ABI consistente con las cabeceras de Windows. Sin embargo, esto puede requerir cambios en su código.

2ª opción – Añadir “#define DISABLE_NS_PREFIX_CHECKS” antes de incluir las cabeceras de Windows. Este método suprimirá la validación.

Fuente – Blog del desarrollador de Windows.