Wie wahrscheinlich zumindest einigen Leuten bekannt ist, hat Microsoft das .NET-Anwendungsframework Open Source gemacht.
Bedeutet dies, dass es möglich sein wird, mehr Windows-Programme unter Linux auszuführen und Wine durch die direkte Integration von APIs irgendwie zu beschleunigen? Oder handelt es sich eher um ein Entwicklungssystem, das sich nicht nativ integrieren lässt, um so reibungslos zu laufen wie Programme, die für die Verwendung von Bash geschrieben wurden?
Ich habe Wine verwendet und festgestellt, dass es selbst bei Distributionen, auf denen es nativ installiert ist, selbst bei den einfachsten Programmen langsam läuft, und mit virtuellen Festplatten und dergleichen ist es mühsam zu verwenden. Wird es möglich sein, die APIs auf Kernel-/Kernelebene zu integrieren, vielleicht ein paar Dinge zu ändern, sodass Schrägstriche anders dargestellt werden, eine gemeldete Windows-Version einzufügen und sie wie nativ laufen zu lassen? Wenn jemand denkt, dass dies erst möglich sein wird, wenn Schweine von selbst fliegen, sagen Sie mir bitte, dass es nie funktionieren wird, aber ich würde gerne konkret wissen, warum es funktionieren würde oder nicht, und nicht nur eine einsilbige Antwort.
Antwort1
Was hat Wein damit zu tun? Lassen wir das für einen Moment außer Acht.
Microsoft macht die Kernteile von .NET zu Open Source und macht ASP.NET noch quelloffener, als es ohnehin schon ist. Alleine diese beiden Teile würden es Ihnen ermöglichen, Befehlszeilen-Anwendungen und ASP.NET-Websites zu erstellen. Wenn Sie bereits über derartige Anwendungen verfügen, sollte es irgendwann möglich sein, Linux-Ziele zu erstellen (falls das überhaupt erforderlich ist) und diese nativ auf Ubuntu auszuführen.
Allerdings ist eine ganze Reihe von .NET-Komponenten erforderlich, um so etwas wie eine GUI-Anwendung zu erstellen. Unter Windows verwenden Entwickler Dinge wie die Windows Presentation Foundation, um Dinge auf dem Bildschirm zu zeichnen. In Mono können wir Dinge wie GTK# und Qt# verwenden. Wenn Sie eine plattformübergreifende Anwendung möchten, benötigen Sie ein plattformübergreifendes Toolkit.
Das ist eine sehr langatmige Art zu sagen, dass sich zunächst nicht viel ändern wird. Entwickler konnten schon vorher Mono verwenden, wenn sie plattformübergreifende Apps wollten, und das können sie immer noch. In Zukunft wird es vielleicht einfacher sein, Monos Toolkits in ein VS.NET-Projekt einzubinden, oder MS wird WPF durch ein plattformübergreifendes Toolkit ersetzen.
Zurück zu Wine. Eine .NET-Anwendung, die in Wine läuft, braucht immer noch etwas, das sie mit Präsentationsbibliotheken versorgt, und (wenn es native Windows-Bibliotheken sind) müssen diese immer nochdurchWine, damit ihnen die richtige Umgebung zur Verfügung steht. Wine ist immer noch das Bindeglied zwischen Anwendung und Hardware (also virtueller Hardware über Linux), auf der .NET aufbaut. Ich kann mir nicht vorstellen, dass sich diese Anordnung in naher Zukunft ändern wird.