¿Un marco .NET de código abierto permitirá la compatibilidad integrada con programas de Windows?

¿Un marco .NET de código abierto permitirá la compatibilidad integrada con programas de Windows?

Como probablemente al menos algunas personas sepan, Microsoft hizo que el marco de la aplicación .NET fuera de código abierto.

¿Significa esto que será posible ejecutar más programas de Windows en Linux y de alguna manera acelerar el vino integrando directamente las API? ¿O es más bien un sistema de desarrollo que no será posible integrar de forma nativa para ejecutarse tan fluidamente como los programas escritos para usar bash?

He usado Wine y descubrí que, incluso en distribuciones donde está instalado de forma nativa, termina ejecutándose lentamente incluso para los programas más básicos, y con discos virtuales y demás, termina siendo complicado de usar. ¿Será posible integrar las API a nivel de núcleo/núcleo, tal vez cambiar un par de cosas para que las barras se representen de manera diferente e incluir una versión de Windows informada y dejar que se ejecuten como lo harían de forma nativa? Si alguien piensa que esto será posible sólo una vez que los cerdos vuelen solos, dígame que nunca funcionará, pero me gustaría saber específicamente por qué funcionaría o no, no solo una respuesta de una palabra.

Respuesta1

¿Qué tiene que ver el vino con esto? Ignoremos eso por un momento.

Microsoft está abriendo el código fuente de las partes principales de .NET y haciendo que ASP.NET sea más de código abierto de lo que ya era. Por sí solas, estas dos partes le permitirían crear aplicaciones de línea de comandos y sitios web ASP.NET. Si tiene aplicaciones existentes como esta, eventualmente debería ser posible crear destinos de Linux (si es necesario) y ejecutarlos de forma nativa en Ubuntu.

Dicho esto, se necesita toda una flota de componentes .NET para crear algo así como una aplicación GUI. En Windows, los desarrolladores utilizan elementos como Windows Presentation Foundation para dibujar cosas en la pantalla. En Mono, podemos usar cosas como GTK# y Qt#. Si desea una aplicación multiplataforma, necesita un conjunto de herramientas multiplataforma.

Ésa es una forma muy larga de decir que no habrá mucho cambio inicialmente. Los desarrolladores podían usar Mono antes si querían aplicaciones multiplataforma y todavía pueden hacerlo. En el futuro, tal vez sea más fácil incorporar los kits de herramientas de Mono a un proyecto VS.NET, o MS reemplazará WPF con un kit de herramientas multiplataforma.

Volver al vino. Una aplicación .NET que se ejecuta en Wine aún necesitará algo que le proporcione bibliotecas de presentación y (si son bibliotecas nativas de Windows) necesitarán continuara través deVino para que se les proporcione el ambiente adecuado. Wine sigue siendo el vínculo entre la aplicación y el hardware (bueno, hardware virtual a través de Linux) sobre el que se encuentra .NET. No veo que ese acuerdo cambie pronto.

información relacionada