Kann man mit normalem C++ irgendwann keine Windows-Programme mehr schreiben?
-
Artchi schrieb:
Also, alles paletti und blos keine Panik!
Es geht aber um Avalon - also Longhorn.
Wenn MFC die neuen Longhorn Features nicht kann (sie also nicht gewrapt werden, dann wird man MFC nicht mehr fuer neue projekte verwenden und die MFC wird sich somit langsam aufloesen) dass MS nicht von heute auf morgen die MFC wegwirft ist klar.
-
Es gibt ja aber noch die möglichkeit auf QT oder wxWidgets umzusteigen. Diese (hoffe ich doch mal) werden diese funktionen irgendwann Wrappen
-
guenni81 schrieb:
Es gibt ja aber noch die möglichkeit auf QT oder wxWidgets umzusteigen. Diese (hoffe ich doch mal) werden diese funktionen irgendwann Wrappen
Also wenn die Freizeit-Programmierer (mal wieder nicht falsch verstehen, habe großen Respekt vor denen, finde wxWidgets auch sehr gelungen!) von wxWidgets das fertigbringen, sollte es Microsoft wohl auch gelingen die MFC umzuschreiben?
-
simon.phoenix schrieb:
Also wenn die Freizeit-Programmierer (mal wieder nicht falsch verstehen, habe großen Respekt vor denen, finde wxWidgets auch sehr gelungen!) von wxWidgets das fertigbringen, sollte es Microsoft wohl auch gelingen die MFC umzuschreiben?
Das mag sein das dann M$ die MFC vielleicht umschreiben könnte. Aber die habe dafür ja das ganze .NET Zeug geschaffen und deshalb wird mit sicherheit an der MFC nix mehr groartig gemacht. Die Leute von wxWidgets wollen aber ja das Ihr Framework weiterverwendet wird und deshalb denke ich mal das dies auch weiterentwickelt wird. Außerdem weisst du ja nicht ob dies wirklich nur Freizeitprogrammierer sind. Vielleicht sind diese ja auch als Programmierer im Arbeitsleben tätig.
-
simon.phoenix schrieb:
Die Einführung von Sprachen wie C# impliziert das doch bereits.
Und die Arbeit, die in CLI/C++ ging und geht, impliziert das Gegenteil. In der MSDN heißt es "Visual C++ [...] typically takes longer to master but can offer more horsepower and a finer degree of control [...]". Nur weil mit VB und C# Sprachen für Otto Normalcoder eingeführt wurden, muss C++ seine Position als Programmiersprache für die /richtige/ Arbeit nicht verlieren - und wenn die Idee hinter CLI/C++ aufgeht, wird C++ zu einer extrem mächtigen Rundum-Sprache.
Davon abgesehen war mir die WinAPI lieber als Windows Forms weil man sie IMHO wesentlich besser wrappen konnte, um sie anderen Sprachen (z.B. C++) anzupassen...
Edit: So früh kann doch kein Mensch tippen
-
guenni81 schrieb:
Aber die habe dafür ja das ganze .NET Zeug geschaffen und deshalb wird mit sicherheit an der MFC nix mehr groartig gemacht. Die Leute von wxWidgets wollen aber ja das Ihr Framework weiterverwendet wird und deshalb denke ich mal das dies auch weiterentwickelt wird.
Also ich denke aufgrund des vorhandenden MFC-Codes werden die MFC vielleicht schmalspurartig weiterentwickelt (hier und da mal ein Fix und eine neue Klasse).
Außerdem weisst du ja nicht ob dies wirklich nur Freizeitprogrammierer sind. Vielleicht sind diese ja auch als Programmierer im Arbeitsleben tätig.
Sie programmieren wohl aber in ihrer Freizeit
Mir stellt sich insgesamt eine Frage:
Wenn sich die, wie wir uns bereits einig waren, teilweise wenig abstrahierten MFC auf irgendeine Weise Avalon-kompatibel machen lassen würden, so dürfte Avalon von der Struktur her ja nichts grundlegend neues bieten. Somit könnte doch eigentlich gleich der WinAPI-Support fortbestehen?
-
simon.phoenix schrieb:
Wenn sich die, wie wir uns bereits einig waren, teilweise wenig abstrahierten MFC auf irgendeine Weise Avalon-kompatibel machen lassen würden, so dürfte Avalon von der Struktur her ja nichts grundlegend neues bieten. Somit könnte doch eigentlich gleich der WinAPI-Support fortbestehen?
WinAPI/MFC-Programme werden selbstverständlich auch auf Longhorn laufen. Der Support "besteht also fort".
Ich verstehe euer Problem nicht, es ist doch offensichtlich, dass ein Unterschied zwischen technischer Realisierbarkeit und kommerziellem Marketinginteresse besteht. Natürlich könnte MS die MFC anpassen. Das technische Wissen und die finanziellen Ressourcen sind zweifelsohne vorhanden. Der Punkt ist doch nur der, dass MS es nicht will.
-
WinAPI/MFC-Programme werden selbstverständlich auch auf Longhorn laufen. Der Support "besteht also fort".
Das war nicht der Punkt. Der Punkt war, ob MFC auf Avalon laufen wird. Und das kann man denke ich, mit gutem Gewissen verneinen, da es die Winforms auch nicht werden.
Daher besteht also echt die Möglichkeit, dass Avalon etwas komplett neues bringt.
Allerdings werden Winforms noch ne ganze Zeit lang emuliert, z.B. werden GDI-Funktionen über lock & copy emuliert. Das könnte für die MFC auch möglich sein. Ein Anpassung der MFC für Avalon halte ich für extrem unwahrscheinlich, wenn dann könnte ich es mir noch für die Winforms vorstellen. Die MFC hat ihre besten Tage hinter sich.
-
Optimizer schrieb:
WinAPI/MFC-Programme werden selbstverständlich auch auf Longhorn laufen. Der Support "besteht also fort".
Das war nicht der Punkt. Der Punkt war, ob MFC auf Avalon laufen wird. Und das kann man denke ich, mit gutem Gewissen verneinen, da es die Winforms auch nicht werden.
Ja eben, und ich sagte, dass das eine "politische" Entscheidung Microsofts ist und keine technische Unmöglichkeit.
-
Der Sourcecode von MFC ist offen lesbar.
-
Erhard Henkes schrieb:
Der Sourcecode von MFC ist offen lesbar.
Nicht der komplette wenn ich mich nicht irre. Das meiste steckt doch in der mfcxx.dll.
-
Laut Behauptung MS solls wirklich der ganze Sourcecode sein. Im SRC-Verzeichnis
vom MFC liegen auch verschiedene Makefiles, darunter einer namens MFCDLL die
eine Datei namne "MFC42.DLL" erstellen soll. Ich habs allerdings noch nie
probiert, (Gott sei Dank ).mfg JJ
-
Doch doch, Source Code ist komplett dabei. Vielleicht nicht bei der Standard Version.
-
Also das Verzeichnis existiert zumindest mal und hat auch einen Inhalt. Anscheinend ist dies bei der Standardversion auch dabei...