Detalles de la vista previa de Windows 10 SDK Build 17713

Contenido

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

Vista previa de Windows 10 SDK Build 17713 Detalles

Julio 19, 2018

Microsoft entregó Windows 10 SDK Preview Build 17713 para ser usado en conjunto con al menos Insider Build 17713. Este paquete incluye correcciones de errores y modificaciones de desarrollo en el área de superficie de la API.

Puede obtener el SDK de vista previa actual desde el campo de desarrollador en Windows Insider. Microsoft se dirige a los desarrolladores para que naveguen hasta la plataforma Windows UserVoice y den sus comentarios. Windows 10 SDK Preview Build 17713 se ejecuta en Visual Studio 2017. Puede obtener este kit de desarrollo de software y enviar sus aplicaciones al target Windows 10 April 2018 update 1803 o ediciones anteriores a la Tienda.

Windows 10 SDK Preview Build 17713

Windows>>Windows

Actualización de C++/WinRT para Windows 10 SDK Preview Build 17713

Esta actualización incluye muchos cambios y correcciones para C++/WinRT. Lo más importante es que inicia la capacidad de construir C++/WinRT sin depender del SDK. Windows 10 SDK Preview Build 17713 no tiene cabeceras de Windows que lo hagan interesante para el desarrollador del sistema operativo además del repositorio del sistema operativo. De esta manera, un desarrollador normalmente atraerá a un pequeño número o a ninguna dependencia, incluso sin prestar atención. Esto también significa una disminución sustancial en el número de macros contra las que un desarrollador de C++/WinRT debe ser cauteloso. La reducción de la dependencia de las cabeceras de Windows indica que C++/WinRT es adicionalmente portátil y cumple con los estándares, y de antemano su esfuerzo por convertirlo en una librería de compiladores cruzados, además de una librería multiplataforma. Somacros nunca puede destrozar las cabeceras C++/WinRT. Si antes estaba involucrado en C++/WinRT para incluir diferentes encabezados de Windows, ahora tendrá que hacer lo mismo manualmente.

Puntos importantes de Windows 10 SDK Preview Build 17713

Apoyar get_trong y get_weak para crear delegados

Windows 10 SDK Preview Build 17713 permite a los desarrolladores usar get_strong o get_weak en lugar de un puntero crudo en el momento de crear un delegado que apunte a una función de miembro.

Incluir la llamada de cancelación de asíncronos :

La característica más solicitada para el soporte de la rutina C++/WinRT es la mejora de una llamada de cancelación.

Simplifica el uso de APIs que esperan parámetros de IBuffer

Sin embargo, las principales APIs prefieren grupos o matrices, las APIs adecuadas confían en IBuffer que debería ser más sencillo utilizar tales APIs desde C++. La actualización actual da acceso directo a los datos detrás de una implementación de IBuffer con la misma convención de nomenclatura de datos utilizada por los contenedores de biblioteca estándar C++. La función también evita colisionar con nombres de metadatos que tradicionalmente comienzan con letras mayúsculas.

Conformidad

Soporte mejorado para Clang, además Visual C++ modos de conformidad más estrictos.

Gen de código cambiado

Varios cambios para disminuir el tamaño del código, mejorar el inline, junto con la optimización de la memoria caché de fábrica.

Eliminar recursión innecesaria

Cuando ejecuta una línea de comandos se refiere a una carpeta en lugar de a unwinmd en particular, cppwinrt no buscará archivos winmd recursivamente en el futuro. Crea problemas de rendimiento en la compilación y puede causar problemas de uso y detectar que es problemático cuando los desarrolladores involuntariamente hacen que cppwinrt consuma más winmds de los esperados. El compilador cppwinrt también controla ahora los duplicados con mayor inteligencia, amplificando la resistencia al error del usuario y los archivos winmd mal formados.

Declarar ambos WINRT_CanUnloadNow además WINRT_GetActivationFactory en base.h: Las personas que llaman no requieren una declaración inmediata. Sus firmas también se han modificado, lo que supone un cambio radical. Las declaraciones disminuyen la mayoría de los problemas de este cambio. Debido a que C++/WinRT no dependerá de las cabeceras de Windows, la dependencia se ha eliminado de las cabeceras de Windows, por lo que este era un requisito.

Reforzar los punteros inteligentes

Había un problema, ya que los revocadores de eventos ni siquiera podían revocar cuando se asignaba un nuevo valor a la jugada. Así que el equipo del SDK ha investigado las clases de punteros inteligentes y ha notado cuidadosamente que no estaban manejando de forma fiable la autoasignación. La mayoría de los demás dependen de la plantilla de clase com_ptr y aquí está arraigada. Ellos corrigieron com_ptr y actualizaron los revocadores de eventos para controlar la semántica de movimiento apropiadamente para confirmar que se revocan en el momento de la asignación. El equipo también induró la plantilla de clase de mango mediante la eliminación del constructor implícito que simplificaba la escritura de código incorrecto. Esto también causó errores en el sistema operativo en los errores del compilador establecidos en este PR.

Cambios de balanceo

La compatibilidad con interfaces que no sean WinRT está desactivada de forma predeterminada. Para habilitarlo, sólo use #include antes de las cabeceras C++/WinRT.

en la construcción actual, winrt::get_abi(winrt::hstring) devuelve void* reemplazando a HSTRING. El código que requiere el HSTRING ABI sólo puede utilizar un static_cast.

Además, winrt::put_abi(winrt::hstring) devuelve void** como sustituto de HSTRING*. El código que requiere HSTRING ABI puede utilizar un reinterpret_cast.

HRESULT se proyecta como winrt::hresult. El código que requiere un HRESULT sólo puede static_cast cuando se desea escribir caracteres de tipo checking o support, pero es convertible de forma diferente siempre y cuando se incluya en primer lugar .

GUID se proyecta además como winrt::guid. El código que implementa APIs con parámetros GUID se ejecutaráwinrt::guid, pero es convertible de forma diferente mientras que se incluye primero.

Las firmas “WINRT_CanUnloadNow” y “WINRT_GetActivationFactory” han sido modificadas. Code no declarará estas funciones a cualquier costo e incluirá winrt/base.h para incluir sus declaraciones.

El constructor winrt::handle es explícito. El código que asigne un valor crudo de la manija llamará al método attach.

winrt::clock::from_FILETIME es ahora obsoleto. El código debe usar winrt::clock::from_file_time alternativamente.

Cambios en la vista previa de Windows 10 SDK Build 17713

Soporte para MSIX

Desde Windows 10 SDK Preview Build 17713, puede empaquetar sus aplicaciones como MSIX. Más tarde las aplicaciones pueden ser instaladas y ejecutadas en el sistema que contiene al menos la build 17682 build.

Para este propósito, necesita usar la herramienta MakeAppx. Simplemente haga clic en el archivo MSIX y se instalará. Para obtener más información sobre MSIX, eche un vistazo a este vídeo de introducción: link

MSIX no está actualmente soportado por el Kit de Certificación de Aplicaciones ni por el Microsoft Store en este momento.
MC.EXE

En Windows 10 SDK Preview Build 17713, han hecho ciertas modificaciones significativas a la generación de código C/C++ ETW de mc.exe –

El parámetro”-mof” se ha quedado obsoleto. Este parámetro da instrucciones a MC.exe (Compilador de Mensajes) para crear código ETW que sea compatible con Windows XP y anteriores. El soporte del parámetro “-mof” terminará en una próxima edición de mc.exe.

Aunque el parámetro “-mof” no se ejecuta, la cabecera C/C++ generada es compatible con el modo kernel así como con el modo usuario, lo que no importa si se especificó “-km” o “-um” en la línea de comandos. El encabezado utilizará la macro _ETW_KM_ y determinará por sí mismo si se está compilando para el modo kernel o para el modo usuario. Esto llamará a las APIs ETW apropiadas para cada modo.

“-km” y “-um” tienen una diferencia y son las macros EventWrite[EventName] generadas con “-km” que incluyen un parámetro Activity ID y la otra no.

Las macros EventWrite[EventName] funcionan por defecto como un desvío hacia adelante para llamar a EventWriteTransfer (modo usuario) o EtwWriteTransfer (modo kernel).

El encabezado generado ahora soporta múltiples macros de personalización. Como ejemplo, puede utilizar la macro MCGEN_EVENTWRITETRANSFER si necesita que las macros generadas llamen a algo diferente de EventWriteTransfer.

El manifiesto soporta atributos frescos.

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 incluyendo semántica definida por el usuario (por evento).
Campo “tags”: Valor de 28 bits más semántica definida por el usuario (por campo – se puede poner en una aplicación para elementos “data” o “struct”).

Puede definir “rasgos del proveedor” en el manifiesto (por ejemplo, grupo de proveedores). Si utiliza los rasgos del proveedor en el manifiesto, la macro EventRegister[Nombre del proveedor] los registrará por sí misma.
MC informará de un error si falta una cadena en un archivo de mensajes localizado.
.
El MC puede ahora crear salidas “utf-8” y “utf-16” utilizando los parámetros “-cp utf-8” o “-cp utf-16”.

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

Un problema es que las cabeceras del SDK se generan utilizando los tipos del espacio de nombres ABI. Microsoft ha hecho esto para evitar 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 son *no* puestos en el espacio de nombres ABI, aunque, esto tiene la capacidad de producir conflictos de equipos que intentan consumir tipos ABI desde Windows WinRT MIDL y cabeceras generadas por WinRT MIDL que no son de Windows. Esto es particularmente difícil si la cabecera que no es de Windows hace referencia a los tipos de Windows.

Para confirmar que los desarrolladores tienen una vista secuencial de la superficie de la API de WinRT, se ha incluido una validación en las cabeceras generadas para asegurarse de 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 programas (x86)kits de ventanas 10incluyen 10.0.17687.0winrtwindows.foundation.h(83)”:” error C2220:” warning treated as error – no se genera un fichero’object’

“5>c:ficheros de programas (x86)kits de ventanas 10incluyen10.0.17687.0winrtwindows.foundation.h(83):” “warning C4005: ‘CHECK_NS_PREFIX_STATE’: macro redefinition”

“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 generadas por el sistema.

Existen 2 métodos para arreglar esto –

Use este como una preferencia – Compile su archivo IDL acompañado por el parámetro /ns_prefix MIDL de la línea de comandos. Esto llevará a que todos sus tipos sean movidos al espacio de nombres ABI consistente con las cabeceras de Windows. Esto puede requerir modificaciones en el código, aunque.

De lo contrario, añada #define DISABLE_NS_PREFIX_CHECKS antes de añadir las cabeceras de Windows. Esto suprimirá la validación.

Actualizaciones, adiciones y eliminaciones de la API

Si está buscando nuevas APIs, piense en escribir aplicaciones que sean adaptables con el fin de que funcionen correctamente en el número máximo de dispositivos de Windows 10.

Descargue Windows 10 SDK Preview Build 17713 desde aquí

Fuente – Blog del desarrollador de Windows

4/5 - (5 votos)

Related posts

Leave a Comment