c# - ¿Por qué no se administra WinRT?

.net windows-8

Question

Windows 8 presenta WinRT, que es como .NET pero no administrado. ¿Por qué no está administrado? ¿Es un problema de rendimiento? ¿Significa que la recolección de basura no es adecuada para API de nivel inferior?

Answer 1

WinRT es un reemplazo para el antiguo Winapi basado en C. Es una API que debe ser utilizable en muchos entornos de tiempo de ejecución. Hace 20 años atrás, una C api era relativamente fácil de interoperar. Eso ha cambiado desde entonces, COM se convirtió en el pegamento universal en la última mitad de la década de 1990. Prácticamente cualquier tiempo de ejecución de idioma de uso común en Windows admite COM.

Un recolector de basura es un detalle de implementación de tiempo de ejecución de idioma. El recopilador de .NET es muy diferente del recopilador de Javascript, por ejemplo. Los objetos nativos creados en cualquiera de ellos deben observar las reglas muy estrictas del coleccionista. Lo que a su vez significa que tendrían que crear versiones WinRT que son específicas para cada idioma de ejecución. Eso no funcionará, incluso una empresa tan grande como Microsoft no puede permitirse crear y soportar una versión WinRT específica para cada enlace de idioma. Tampoco es necesario, dado que estos lenguajes ya son compatibles con COM.

En este momento, el mejor enlace para WinRT es C ++ ya que COM funciona de manera más eficiente con la administración de memoria explícita. Con la amplia ayuda de las nuevas extensiones del compilador de C ++ que lo hacen automático, muy similar a _com_ptr_t de la antigüedad con sintaxis de C ++ / CLI para evitarlo. La vinculación a los lenguajes administrados es relativamente simple ya que el CLR ya tiene un excelente soporte de interoperabilidad COM. WinRT también adoptó el formato de metadatos de .NET. Afaik, hasta el momento no se ha hecho ningún trabajo sobre compiladores administrados.

EDITAR: Larry Osterman, un conocido programador y blogger de Microsoft, dejó un comentario bastante bueno en una respuesta ahora eliminada. Lo citaré aquí para preservarlo:

WinRT no está administrado porque el sistema operativo no está administrado. Y al diseñar WinRT tal como fue diseñado, gana la capacidad de expresarse en muchos idiomas diferentes, no solo en C ++, C # y JS. Por ejemplo, podría ver fácilmente un conjunto de módulos de Perl que implementan las API de WinRT que funcionan en el escritorio. Si lo hubiéramos implementado en .Net, eso hubiera sido extremadamente difícil

Answer 2

WinRT no está administrado porque está destinado a ser un reemplazo para Win32, la API accesible de desarrollador de nivel más bajo para Windows. Una API no administrada sigue siendo la más potencialmente funcional que se puede exponer al desarrollador y el razonamiento es que siempre será posible ajustar una API administrada sobre ella, que es precisamente lo que hacen las "proyecciones".

También significa que los desarrolladores de C ++ pueden usar WinRT sin saltar por los aros que introduce C ++ / CLI (ver http://www2.research.att.com/~bs/bs_faq.html#CppCLI ). Sin embargo, eso significa que todavía tiene que estudiar COM si quiere usar WinRT.

La verdadera pregunta es ''¿por qué es necesario COM? ¿Por qué Microsoft tuvo que inventarlo? Debido a que el simple C ++ sin todas las facilidades adicionales de COM es inadecuado para el trabajo OOP real y las afirmaciones de Stroustrup de C ++ que le da ''portabilidad'' son muy poco sinceras a la luz de la realidad de trabajo. Ver http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/