Vista previa de Windows 10 SDK ¡Build 17709 disponible ahora!

Hoy, lanzamos una nueva compilación de vista previa de Windows 10 del SDK que se usa junto con la vista   previa de  usuario de  Windows 10 (compilación  17709  o superior). Vista previa SDK Build  17709  contiene correcciones de errores y cambios de desarrollo en el área de superficie de la API.

El SDK de vista previa se puede descargar desde la   sección de desarrollador en Windows Insider .
Para obtener comentarios y actualizaciones sobre los problemas conocidos, consulte el   foro de desarrolladores. Para las nuevas solicitudes de características del desarrollador, diríjase a nuestra   plataforma Windows UserVoice.

Cosas a tener en cuenta:

  • Esta compilación funciona en conjunto con los SDK publicados anteriormente y Visual Studio 2017. Puede instalar este SDK y seguir enviando sus aplicaciones a un Windows 10 build 1803 o anterior a la tienda.
  • El SDK de Windows ahora es formalmente compatible solo con Visual Studio 2017 y videos posteriores. Puede descargar el Visual Studio 2017   aquí .
  • Esta compilación del Windows SDK  se puede instalar en  Windows 10 Inside Preview y admite los sistemas operativos de Windows.

Actualización de C ++ / WinRT para la compilación 17709 y posteriores:

Esta actualización presenta muchas mejoras y correcciones para C ++ / WinRT. En particular, presenta la capacidad de compilar C ++ / WinRT sin ninguna dependencia en el SDK de Windows. Esto no es especialmente interesante para el desarrollador del sistema operativo, pero incluso en el repositorio del sistema operativo ofrece beneficios porque no incluye ningún encabezado de Windows. Por lo tanto, no se debe utilizar ninguna otra fuente de publicidad inadvertidamente.

Esto también significa una reducción drástica en el número de macros que un desarrollador de C ++ / WinRT debe evitar. Eliminar la dependencia de los encabezados de Windows significa que C ++ / WinRT es más portátil y cumple con los estándares y fomenta nuestros esfuerzos para convertirlo en una biblioteca de compilación cruzada y multiplataforma. También significa que los liderados C ++ / WinRT nunca serán destruidos por las macros.

Si alguna vez se cerró en C ++ / WinRT para incluir varios encabezados de Windows, ahora tendrá que incluirlos usted mismo. Siempre ha sido una buena práctica incluir los encabezados de los que dependen de manera explícita, y no dependen de otra biblioteca para incluirlos por usted.

Reflejos

Admite get_strong y get_weak para crear delegagados: esta actualización permite que un desarrollador use get_strong o get_weak en un lugar sin formato al crear un delegado que apunta a una función de miembro.

Agregue devolución de llamada de cancelación asíncrona: la función más solicitada para la compatibilidad con corotine de C ++ / WinRT ha recibido la venta de una devolución de llamada de cancelación.

Simplifique el uso de la API que espera los parámetros de IBuffer: aunque la mayoría de las API prefiera colecciones o matrices, API API que es más fácil de usar API de C ++. Esta actualización proporciona acceso a los datos de una implementación de IBuffer utilizando la misma convención de nomenclatura de datos utilizada para los contenedores de la biblioteca estándar de C ++. Esto también evita la colisión con los nombres de metadatos que, de forma convencional, comienza con una letra mayúscula.

Conformidad: soporte mejorado para los medios de comunicación más estrictos de Clang y Visual C ++.
Generación de código mejorada: mejoras para reducir el tamaño del código, mejorar el alineamiento y optimizar el almacenamiento en caché de fábrica.

Eliminar recursión innecesaria: cuando la línea de comando se refiere a una carpeta en lugar de un winmd específico, cppwinrt ya no buscará recursivamente archivos winmd. Causa problemas de rendimiento en la compilación del sistema operativo y puede dar lugar a errores de uso que a veces son difíciles de diagnosticar cuando los desarrolladores inadvertidamente provocan que cppwinrt consuma más winmds de lo esperado. El compilador cppwinrt ahora también maneja los duplicados de forma más inteligente, lo que es más resistente a los errores del usuario ya los archivos winmd mal formados.

Declare WINRT_CanUnloadNow y WINRT_GetActivationFactory en base.h: las personas que llaman no necesitan declararlas directamente. Sus firmas también lo han cambiado, lo que equivale a un cambio radical. Las declaraciones alivian la mayor parte del dolor de este cambio. El cambio es necesario por el hecho de que C ++ / WinRT ya no depende de los encabezados de Windows y este cambio elimina la dependencia de los tipos de los encabezados de Windows.

Harden punteros  inteligentes : los revocados del evento no revocaron cuando se asignó un nuevo valor. Esto me llevó a mirar más allá de las clases de punteros inteligentes y me di cuenta de que no manejaban de forma confiable la autoasignación. Esto está enraizado en la plantilla de clase com_ptr en la que confían la mayoría de los demás. Arreglé com_ptr y actualicé los revocadores de eventos para manejar la semántica de los movimientos para asegurar que se revoquen al asignarlos. La plantilla de clase de control también se ha visto reforzada por la eliminación del constructor que facilita la escritura del código incorrecto. Esto también convirtió los errores en el sistema operativo en errores de compilación corregidos en este PR.

Rompiendo cambios

La compatibilidad con interfaces que no son WinRT está deshabilitada de forma predeterminada. Para habilitar, simplemente #include <unknwn.h> antes de cualquier encabezado de C ++ / WinRT.

winrt :: get_abi (winrt :: hstring) ahora devuelve void * en lugar de HSTRING. El código que requiere HABLAR ABA puede simplemente usar un static_cast.

winrt :: put_abi (winrt :: hstring) devuelve void ** en lugar de HSTRING *. El código que requiere HABLAR ABI puede simplemente usar un reinterpretar_cast.

HRESULT ahora se proyecta como winrt :: hresult. El código que requiere un HRESULT puede simplemente static_cast si necesita hacer funciones de comprobación de tipo o de tipo de soporte, pero de lo contrario es convertible, siempre que se agrega <unknwn.h> primero.
GUID ahora se proyecta como winrt :: guid. El código que implementa las API con parámetros GUID debe usar winrt :: guid en su lugar, pero de lo contrario es convertible siempre que se adjunta <unknwn.h> primero.

Las firmas de WINRT_CanUnloadNow y WINRT_GetActivationFactory han cambiado. El código no debe declarar estas funciones en absoluto e incluir winrt / base.h para incluir sus declaraciones.

El constructor winrt :: handle ahora es explícito. El código que asigna un valor de identificador sin formato debe llamar al método de vinculación en su lugar.

winrt :: clock :: from_FILETIME ha quedado en desuso. El código debería usar winrt :: clock :: from_file_time en su lugar.

Qué hay de nuevo:

Soporte MSIX

¡Finalmente está aquí! Ahora puede empaquetar sus aplicaciones como MSIX. Estas aplicaciones se pueden instalar y ejecutar en cualquier dispositivo con  17682 compilación 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 comprender más acerca de MSIX, mire este video introductorio:  enlace

Comentarios y comentarios son bienvenidos en nuestra página de la comunidad MSIX:  http://aka.ms/MSIXCommunity
En este momento, MSIX no es compatible con el Kit de certificación de aplicaciones ni con la Tienda de Microsoft.

MC.EXE

ETW C / C ++ de mc.exe (compilador de mensajes):
El parámetro "-mof" está en desuso. Este parámetro instruye a MC.exe a generar código ETW que sea compatible con Windows XP y versiones anteriores. El soporte para el parámetro "-mof" se puede eliminar en una versión futura de mc.exe.
Mientras no se use el parámetro "-mof", el encabezado C / C ++ generado ahora es compatible tanto con el modo kernel como con el modo usuario, independientemente de si se especificó "-km" o "-um" en la línea de comando. El encabezado usa la macro _ETW_KM_ para determinar automáticamente si está compilando para kernel-mode o modo de usuario y llamará a las preferencias ETW API para cada modo.
  • La única diferencia restante entre "-km" y "-um" es que las macros EventWrite [EventName] generadas con "-km" tienen un parámetro de identificación de actividad, mientras que las macros EventWrite [EventName] generadas con "-um" no tienen un parámetro de identificación de actividad.
Las macros EventWrite [EventName] ahora son predeterminadas para llamar a EventWriteTransfer (modo de usuario) o EtwWriteTransfer (modo kernel). Anteriormente, las macros EventWrite [EventName] se predeterminaban para llamar a EventWrite (modo de usuario) o EtwWrite (modo kernel).
  • El árbol de las estrellas permite el logro de varias macros de personalización. Por ejemplo, puede establecer la macro MCGEN_EVENTWRITETRANSFER si necesita las macros generadas para llamar a algo que no mar EventWriteTransfer.
  • El documento tiene nuevos atributos.
    • "Nombre" de evento: nombre de evento no localizado.
    • "Atributos" del evento: metadatos clave-valor adicional para un evento como nombre de archivo, número de línea, nombre del componente, nombre de la función.
    • "Etiquetas" de eventos: valor de 28 bits con semántica definida por el usuario.
    • "Etiquetas" de campo: valor de 28 bits con semántica definida por el usuario (por campo: se puede aplicar a elementos de "datos" o "estructura")
  • Ahora puede definir "características del proveedor" en el manifiesto (por ejemplo, grupo de proveedores). Si se utiliza rasgos de proveedor en el manifiesto, la macro EventRegister [ProviderName] los registrará automáticamente.
  • MC ahora tiene un error al encontrar un archivo localizado. (Anteriormente MC generó un mensaje de error).
  • MC ahora puede generar salida Unicode (utf-8 o utf-16) con los parámetros "-cp utf-8" o "-cp utf-16".

Problemas conocidos:

Los encabezados SDK se crean con tipos en el espacio de nombres "ABI". Esto se puede hacer 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 *  no * se ponen en el espacio de nombres ABI, sin embargo, esto tiene el potencial de introducir conflictos de los equipos que intentan consumir tipos ABI desde Windows WinRT MIDL encabezados generados y encabezados por Windows MIDR no WinRT (esto es especialmente desafiante si el encabezado no es Windows hace referencia a los tipos de Windows).

Para garantizar que los desarrolladores tengan una vista adecuada de la superficie API de WinRT, se ha agregado la validación a los encabezados para garantizar el prefijo ABI mar coherente entre los encabezados de Windows y los encabezados generados por el usuario. Si encuentra un error como:
5> c: archivos de programa (x86) kits de ventanas10include10.0.17687.0winrtwindows.foundation.h (83): error C2220: advertencia tratada como error - no se generó un archivo 'objeto'
5> c: archivos de programa (x86) kits de ventanas10include10.0.17687.0winrtwindows.foundation.h (83): advertencia C4005: 'CHECK_NS_PREFIX_STATE': redefinición de macros
5> g: <RUTA A SU ENCABEZADO AQUÍ> (41): nota: vea la definición anterior de 'CHECK_NS_PREFIX_STATE'
Significa que algunos de los encabezados por MIDL hijo son inconsistentes con los encabezados generados por el sistema.

Hay dos formas de solucionar esto:
  • Preferido:  compila tu archivo IDL con el modificador de línea de comandos MIDL / ns_prefix. Esto hará que todos los tipos se muevan al espacio de nombre ABI de forma conjunta con los encabezados de Windows. Sin embargo, esto puede requerir cambios de código en tu código.
  • Alterno:  agregue #define DISABLE_NS_PREFIX_CHECKS antes de incluir los encabezados de Windows. Esto suprimirá la validación.

Actualizaciones, adiciones y eliminaciones de API

Al orientar las API nuevas, considere escribir su aplicación para que el mar se adapte y funcione correctamente en la mayoría de dispositivos con Windows 10. Consulte    Funciones de detección dinámica con contratos de API (10 por 10)  para obtener más información.
Las siguientes API se han agregado a la plataforma desde el lanzamiento de 17134. Las API que figuran a continuación se han eliminado.

Adiciones:



Eliminación:



<a onclick=omegayalfa" class='avatar avatar-64 photo' height='64' width='64'>
  • Autor:
  • Editor:
      Tutoriales En Linea
  • Fecha:2018-07-21
  • Categorias: Microsoft Noticias Software Tutorial Windows



Información
Usuarios que no esten registrados no pueden dejar comentarios, te invitamos a que te registre!