Microsoft und sein Bekenntnis zu C++

Eigentlich ist es ja schön, dass Microsoft sich endlich mal zu etwas mehr durchgerungen hat, als nur partieller Kosmetik im Bereich der nativen Softwareentwicklung mit C++.

Nach meiner Meinung kommt das ganze allerdings um Jahre zu spät! Ich hätte spätestens mit VS-2005 erwartet, dass Microsoft den verbalen Bekenntnissen, dass es weiterhin auch native Entwicklung mit C++ geben wird, auch Taten folgen lässt.

Microsoft hat sich mit der einfältigen Umbenennung von Visual Studio in ein VS.NET 2002 keinen Gefallen getan. Die Verunsicherung unter den vielen C++ Entwicklern durfte ich damals in Neuss beim großen Launch des VS.NET 2002 als ATE (Ask the Expert) am eigenen Leib erfahren.

Geändert hat sich nicht viel in den Jahren danach. Die Verunsicherung ist geblieben und Vertrauen wurde keines zurück gewonnen. Ein vorbehaltloses Prüfen der neuen Compiler und Visual Studio Versionen hat in vielen Firmen nicht stattgefunden. Die Änderungen waren gravierend sicherlich, wenn man den Compiler und die IDE von VC++ 6.0 mit der von VC++ 2005 vergleicht, da liegen einfach Welten dazwischen.

Irgendwie hatten zu viele Firmen und Entwickler das Gefühl „nun stirbt C++“, „jetzt  ist die vielfach totgesagte MFC wirklich tot“. Zuversicht in die bestehende Technologie zu setzen war einfach nicht da.

Das Micrsoft natives C++ nicht abschreibt wurde zwar ab und zu gesagt, aber das hörte sich eher wie Pfeifen im dunklen Wald an. Die ganze Situation machte es C# und .NET Entwicklern leicht auf C++ Entwicklern herumzuhaken und sie zutiefst zu bemitleiden (natürlich immer mit einem hämischen Grinsen). Und teilweise geschah dies sogar aus den eigenen Reihen von Microsoft. Hatte man auf einmal mit C++ keine zukunftsweisende Technologie mehr?
Die Tracks bei Kongressen füllten sich mit .NET Beiträgen. Und was sich in C++ getan hat (und es hat sich noch einiges getan) wurde kaum veröffentlicht oder nicht gehört. Auch was Dokumentationen betrifft, hat sich die C++ Gruppe nicht mit Ruhm bekleckert.

Noch „besser“ wurde es als schwachsinnige Aussagen die Runde machte, dass die nächsten Betriebssysteme nur noch .NET erlauben würden, und demnächst alles, bis zum Treiber mit .NET entwicklet würden. C++ braucht man nicht mehr.
Schaut man sich heute an, wieviel .NET in Vista und Windows 2008 Server steckt, dann merkt man, wie blödsinnig diese Annahmen waren und das es kaum Ersatz gibt für native Entwicklung in C++.
Fakt ist: bis heute wurde keine wirklich weitreichende und wichtige Schnittstelle in Win32 geschaffen die nur aus der managed Welt anzusprechen wäre. Und selbst wenn, so ist die Brücke aus C++ in die managed Welt ist kurz…

Warum wurden keine Walkthroughs und Dokumentationen geliefert , die einem bei der Umstellung von Code der unter VC6 entwickelt wurde auf VC++2003/2005 erklären und leichter machen? Walkthroughs, die gezielt auf die speziellen Warnungen eingehen, die einem um die Ohren fliegen, oder konstruktiv bei Problemen mit dem Umstieg helfen, finden wir heute höchstens in der Community entsprechende Beiträge.

Wäre es zu viel verlangt gewesen, zum Beispiel sofort bei der Umstellung eines VC6 Projektes bestimmte Projekteinstellungen so zu gewährleisten, dass möglichst wenig Warnungen entstehen, aber der Programmierer auf die Änderungen, die seinen Code sicherer und kompatibler machen, klar hinweisen?

Es ist verschlafen worden! Ja es wurde Jahre lang geschlafen. MFCnext ist schön, nett. Das TR1 kommt ist prima. Ich frage mich aber ob es wirklich genügt das verloren gegangene Vertrauen wieder zurück zu gewinnen?

Just my 2 cents…

4 Gedanken zu „Microsoft und sein Bekenntnis zu C++“

  1. Ich frage mich, warum man MFCNext braucht?
    Viel sinnvoller wäre es einen „schönen“ und „einfachen“ Weg nach WPF zu finden…
    Das war zumindest eine der häuftigesten Fragen im ATE-Bereich in Barcelona. Kann ich WPF in MFC hosten (Antwort: Ja).

    Die meisten Entwickler sehen in der MFC keine Zukunft mehr (ist ja auch schon knapp 20 Jahre alt) und wollen auf was neues gehen…

  2. Die MFC war schon immer eine Bibliothek, die einem das Schreiben von C++-Anwendungen unter Windows erleichtern soll. Und das macht sie auch heute noch. Das Fundament ist stabil, performant und weitgehend kompakt, was will man mehr? Ich verwende die MFC nun seit 12 Jahren und sehe keinen Grund, warum ich plötzlich etwas anderes nehmen sollte. Und das liegt wohl auch daran, weil mich ich die meisten Technologien (z.B. .NET, WPF), die von MS immer wieder als „die Zukunft“ angekündigt werden, als Anwendungsentwickler weitgehend kalt lassen. Und ich habe nicht den Eindruck, dass dies meine Anwendungen unter XP/Vista irgendwie benachteiligt. Windows ist C++ und COM, dafür brauche ich keine Verrenkungen in Managed Code.

    Die MFCnext ist für mich aber auch mehr als überflüssig. Es ist nichts, was es nicht heute schon geben würde. Wer als Entwickler darauf Wert legte, dass sich seine Anwendungen im jeweils aktuellen Office-Stil präsentieren, der hatte bisher auch schon genügend Möglichkeiten dafür. Schade, dass MS hier wieder mal in einen funktionierenden Markt eindringt.

    Das Bekenntnis zu C++ selbst kann ich aber nur begrüßen. Denn das verspricht uns C++-Entwicklern nach dem ganzen .NET-Hype wirklich wieder eine gesicherte Zukunft.

  3. So ist es. MFCnext ist nett. Aber es kommt eben zu spät…

    Alles was Microsoft jetzt liefert haben sich Entwickler, die es brauchten, für unter 1000 Euro kaufen können.

    OK jetzt können auch Hobby-Entwickler diese Stile nutzen. Aber ist das der Bereich auf den Microsoft zielt?

    Ich denke auch Professionals interessiert das nur peripher.

    Ich gehe mit Euch beiden Jochen&Sven konform.

  4. Ich stimme auch mit euch überein.
    Ich habe schon .NET programmiert, das fand ich aber ’n bisschen zu ‚easy‘.
    Denn man muss/kann nur einfachen Code schreiben.
    Als Vergleich: ich habe einen Shredder in C# und C++ geschrieben, die Routine, die die Dateien zerstört ist bei beiden programmiersprachen gleich lang.

    Was mich an C# stört ist, dass Dialoge (Forms ?! warum forms? => hieß schon immer ‚Dialoge‘!!) nicht von der Resource geladen werden, wie bei WinAPI üblich, sondern direkt im Code generiert werden. Mann! Das ist doch viel zu langsam, kann Windows viel besser…

Schreibe einen Kommentar zu JochenKalmbach Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.