c# javascript c++ windows-8 windows-runtime

C++, C#y JavaScript en WinRT



windows-8 windows-runtime (6)

A partir de la imagen de abajo, plataforma y herramientas de Windows 8. Sé que esto significa que puedo usar C ++, C # o JavaScript para la aplicación estilo Metro. También veo la nota clave de alguna compilación y tengo un par de preguntas aquí.

Plataforma y herramientas de Windows 8 http://www.windowsitpro.com/content/content/140554/windows8-platform-tools_2.jpg

  1. ¿Tienen alguna diferencia en C ++, C # y JavaScript en WinRT, por ejemplo, rendimiento, característica, capacidad, etc.?
  2. ¿Cómo puedo crear una aplicación de Metro nativa con JavaScript? ¿Necesito usar js library de MS o puedo usar cualquier js con el que esté familiarizado, por ejemplo jQuery?
  3. En la aplicación estilo Metro, System Services solo es WinRT, ¿significa que ya no puedo usar dll de bajo nivel? ¿Esto vendrá con el costo de rendimiento?

  1. Las mismas diferencias que siempre han tenido. No hay tal cosa como C # sin la gestión automática de la memoria. Los idiomas administrados tendrán gastos generales similares como siempre.

  2. Si ejecuta Javascript, deberías poder usar jQuery (que es javascript puro). Es posible que deba llamar a algunas funciones de MS para la inicialización, etc., pero las funciones de script existentes aún deben ejecutarse.

  3. Las fuentes más confiables que he visto han indicado que (al menos en su mayoría) WinRT se encuentra en la parte superior de Win32. Ese bloque de "Servicios del núcleo de Windows" es kernel32.dll de Win32. Algunas cosas de Win32 de nivel superior no se usan en Metro, pero ¿qué aplicación usó TODO de Win32?


1) El punto de permitir la elección del idioma es permitirle elegir un idioma para las ventajas intrínsecas del idioma y no porque es la única forma de acceder a una API. Si te gustan los idiomas dinámicos, elige JavaScript. Si le gusta la escritura estática, pero no quiere lidiar con la memoria, use C #. Si quieres la ejecución más rápida (pero la mayor capacidad para dispararte en el pie), elige C ++.

2) Eso depende de lo que quieras decir con nativo. Si solo quiere decir que quiere que se parezcan a las aplicaciones estilo Metro, la mejor manera es usar las bibliotecas WinJS que se suministran con el SDK de vista previa para desarrolladores.

3) WinRT le brinda la capacidad de escribir y llamar a sus propios DLL de C ++ o ensamblajes de C # desde su código JavaScript. La restricción es que tiene que exponer la DLL como un objeto WinRT y no puede llamar a ninguna función que de otra manera no se permita usar en las aplicaciones de estilo Metro.


Con respecto al # 1, la alineación sería aproximadamente como sigue:

JavaScript: nivel más alto, de tipo dinámico, GC. Solo puede usar HTML5 / CSS para su interfaz de usuario, el marco XAML (espacio de nombres Windows.UI.XAML ) no está disponible. Proporciona algunas API de JS estándar (especificadas por HTML5) además de la superficie disponible de WinRT, como el almacenamiento local o IndexedDB. Al ser tipificado dinámicamente, es probable que el procesamiento pesado enlazado a la CPU sea más lento que .NET o C ++, aunque el motor JS aún es muy rápido debido a que está compilado por JIT y altamente optimizado. Puede consumir componentes WinRT de C ++ y .NET, pero no escribir los suyos propios en JS. Algunos aspectos de la proyección del lenguaje parecen estar limitados de manera correspondiente; por ejemplo, por lo que puedo ver, no hay manera de implementar una interfaz WinRT en JS, por ejemplo. Las bibliotecas JS existentes generalmente pueden reutilizarse sin ningún esfuerzo o con un mínimo esfuerzo, siempre y cuando funcionen en IE10.

.NET (C # / VB): nivel medio, tipificado estáticamente con escritura dinámica opcional (palabra clave dynamic etc.) y GC. El marco de la interfaz de usuario de XAML es el predeterminado para la interfaz de usuario, pero también puede utilizar HTML utilizando el control WebView . Proporciona acceso completo a las bibliotecas WinRT, pero también a algunas de ellas propias, que a veces son más convenientes de usar (por ejemplo, Stream vs IInputStream / IOutputStream ). Además, el único que incluye soporte especial a nivel de idioma para operaciones asíncronas (palabras clave async y de await ), que se usan mucho cuando se usan las API de WinRT debido a su diseño altamente asíncrono. En términos generales, proporciona la mayor parte del azúcar sintáctico; además de las cosas asíncronas, usted obtiene LINQ a los objetos (que funciona sobre las colecciones WinRT). Puede escribir sus propios componentes WinRT, que luego se pueden usar desde JS o C ++ / CX. Las bibliotecas existentes .NET pueden o no ser fácilmente reutilizables, dependiendo de las clases en las que se basen .NET Framework; los componentes escritos para Silverlight o WP7 tienen más probabilidades de ser reutilizables sin cambios mínimos o mínimos, mientras que los componentes escritos para .NET 4 Full o Client Profile pueden requerir cambios significativos para ejecutarse.

C ++ / CX (Extensiones de componentes de Visual C ++) - nivel bajo / medio, tipificado estáticamente, sin GC - solo recuento. Más cercano "al metal" en que su modelo de objeto está diseñado para asignarse directamente a WinRT sin desajuste de impedancia (por lo tanto, refcounting) pero aún lo suficientemente alto como para evitar la caldera y ser generalmente seguro de usar (por ejemplo, excepciones en lugar de HRESULTs, cadenas vistas como objetos y no como manejadores, dynamic_cast lugar de QueryInterface etc.). No hay capas adicionales, objetos proxy, etc. entre usted y WinRT, todas las llamadas son directas. En la mayoría de los casos, el más rápido de los tres, aunque la diferencia exacta varía significativamente dependiendo de la tarea específica, y puede ser minúsculo para algunos (por ejemplo, una aplicación dirigida por eventos con poca o ninguna computación), y considerable para otros (por ejemplo, análisis o cálculos pesados). ). La historia de UI es la misma que para .NET. Además, obtiene toda la biblioteca estándar de C ++ disponible para usted, así como un subconjunto de ATL. Puede escribir sus propios componentes WinRT, que luego se pueden usar desde JS o .NET. Las bibliotecas existentes de C ++ pueden o no ser fácilmente reutilizables, dependiendo de las API que utilicen; los que se basan estrictamente en el Estándar C / C ++ normalmente funcionarán sin cambios, mientras que los que llaman API de Win32 pueden plantear un problema si se basan en API que no están disponibles en el contenedor de aplicaciones de Metro.

Con respecto al # 3, este video, http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C , debe responder la mayoría de sus preguntas sobre el uso de Win32 (que supongo que significa "DLL de bajo nivel" ) de las aplicaciones de Metro. Tenga en cuenta que si bien el video es sobre C ++, esto también se aplica completamente a C #, ya que P / Invoke y COM Interop todavía están allí. Entonces, si puedes llamarlo desde C ++, puedes llamarlo desde C #.



Otras personas han explicado la diferencia entre los 3 pozos de opciones, así que no lo repetiré.

Sin embargo creo que viene hecho para:

  • Elige lo que sabes
  • Elige lo que te permite reutilizar la mayoría del código.

Asi que

  • Si usted es un programador .net, use C # o VB.Net
  • Si está portando una aplicación desde Windows Phone, use C # o VB.NET
  • Si tiene una gran base de código C ++, considere usar C ++ no administrado con WinRT
  • Si tiene un sitio web y desea proporcionar una versión fuera de línea, puede obtener una buena reutilización de código (y habilidad) utilizando JavaScript con HTML
  • Si le gusta JavaScript y HTML, pero no le gusta .Net, use ...
  • Etc

Sugerencia:

  • ¿Por qué no descargas la vista previa para desarrolladores y te buscas?

http://msdn.microsoft.com/en-us/windows/apps/br229516

Hechos:

  • Por supuesto, aún podrá usar Win32 .dll''s (en un nivel u otro), al igual que puede hacerlo con .Net.

  • Windows 8 tiene más de un año de duración oficial: no hay manera de decir en este punto qué "características" y "capacidades" específicas estarán en la versión final.