Zum Verständnis, C++ vs. Net, WinApi, Windows Vista usw.
-
Hallo, ich würde gern ein paar Fragen an die Fachwelt stellen, die mir gerade so durch den Kopf gehen und mich schon mal im Voraus für hilfreiche Antworten bedanken. Hintergrund ist, das ich vor kurzem ein Gespräch mit jemandem führte wo es darum ging eine bestehende Windows-Software die auf einer umfangreichen Bibliothek (dlls in c++) basiert auf .Net zu portieren und für kommende Windows Generationen (Vista & Co) "fit zu machen".
Ohne die genaue Architektur der Sofware zu kennen (also womit z.B. die Oberfläche usw. erstellt wurde), war die erste Frage die sich mir da aufdrängte: Warum sollte das überhaupt notwendig sein. Welchen Vorteil bringt die Re-Implementierung einer komplexen Bibliothek mit aufwendigen Algorithmen in C# (sofern das überhaupt möglich wäre)? Meiner Meinung nach nichts, solange sie Betriebssystemneutral gehalten ist, oder? Da C++ in direkten Maschinencode übersetzt wird wäre doch bei einer C# Implementierung, die dann in einer Laufzeitumgebung ausgeführt wird eher mit einem Performanceverlust zu rechnen? Abgesehen davon lässt sich mit C# eher schlecht systemnah (Speicherzugriff usw.) programmieren. Lassen sich damit überhaupt DLLs erstellen? UND: Wozu .Net (plattformunabhängige Laufzeitumgebung) wenn es eine offizielle Laufzeitumgebung von MS momentan eh nur für Windows gibt.
Zweite Frage die mir kam: Man könnte die Bibliothek als C++ Implementierung beibehalten und das Frontend bzw. umgebende Framework portieren. Wie sind hier die Möglichkeiten mit C#/.Net, Bibliotheken (DLLs) einzubinden. Ich meine mal gelesen haben, dass diese sich nur dynamisch laden lassen und nicht statisch linkbar sind. Ist das korrekt?
Dritte Frage die mir kam. Wie siehts eigentlich mit der guten WinApi unter Windows Vista aus. Existiert die noch, oder gibt es ein Nachfolgemodell welches die altbekannte WinApi über einen Wrapper oder ähnliches zur Verfügung stellt?
Vierte Frage: Wird es zukünftig überhaupt notwendig sein Windows Software .Net fähig zu halten um sie auf Windows auszuführen. Auf der WinApi basierende Programme müssen doch aus Kompatibilitätsgründen weiter ausgeführt werden können. Somit kann man doch auch weiterhin klassisch MFC oder WinApi Programme in C++ schreiben ohne was zu befürchten zu haben oder?
Fünfte Frage: Soweit ich gelesen hab, ist C++/CIL momentan die einzige Möglichkeit Mischcode (.Net/Maschinencode) zu erstellen aber wohl sehr unbeliebt wegen der unangenehmen Syntax und schlechten Lesbarkeit. Wäre diese Lösung ein Mittelweg (also Bilbiothek in C++ behalten) und Frontend auf .Net umstellen.
Wäre sehr schön wenn jemand meine wirren Denkanstöße mal mit fachlich, fundiertem Wissen hinterlegenlegen/diskutieren könnte.
Viele Grüße
mc_ginley
-
Also, zu Frage 3: Die Frage hat es schon öfters gegeben. Die WinAPI wird weiter bestehen bleiben.
-
Und zu Frage fünf:
Sehr unbeliebt war der erste Versuch C++ an .net zu binden. Dieser hieß "managed C++". Deswegen gibt es seit .net 2.0 C++/CLI. Das sieht wesentlich übersichtlicher aus.
Die Zusammenarbeit zwischen C# und C++ klappt damit ganz gut.
-
Frage 4: Es wird weiterhin native Programme geben; die MFC wird IMHO sogar mit Orcas wesentlich erweitert und auf Vista angepasst; es kann sein, das MS für neue Sachen (keine OS-Dinge) nur noch Managed-Schnittstellen zur Verfügung stellt (wie sie es ja schon mit Avalon/Indigo getan haben).
-
ja danke soweit. muss mich mal schlau machen was es mit C++/CLI auf sich hat.
-
mc_ginley schrieb:
ja danke soweit. muss mich mal schlau machen was es mit C++/CLI auf sich hat.
