Guten Abend, ich habe die letzten 25 Jahre mit MFC-Programmierung verbracht, in C++. Ich kann das mit OpenGL kombinieren, Datenbanken, Internet, Ribbon kann ich natürlich - meine Frage ist, kann ich damit als (demnächst) Rentner noch etwas dazu verdienen, oder ist das alles obsolet? Ich kann das auch mit Fortan machen, Cobol geht mit Cross-Compiler, aber am liebesten wäre mir C++. Wie wird diese Kompetenz für legacy-Software eingeschätzt? Doku kann ich in D, E und F schreiben. Gruss MFC Guy
Fast. Wir suchen Rentner die GUIs in Fortran schreiben. Doku wäre allerdings auf Cn
Ja, sicher. Falls man eine Nische findet, kann man damit durchaus erfolgreich sein.
Im IGM Konzern gibt es bestimmt attraktive Stellen für Rentner. Ich werde auch direkt weiterarbeiten mit 67. Selbst schuld, wer sich auch in der Rente die 5k netto entgehen lässt.
MFC? Ok, das ist ja schon uralt. Das ist noch mit C++/CLI. Eigentlich hat das ja total gefailed bzw. sich nicht durchgesetzt.
Qwertz schrieb: > Ich > werde auch direkt weiterarbeiten mit 67. Selbst schuld, wer sich auch in > der Rente die 5k netto entgehen lässt. Es gibt dumme Kommentare und es gibt deren Krönung vom Qwertz. Wenn jemand noch fit ist und Spaß hat, seine Fähigkeiten zu nutzen, ist das eine gute Sache. Es mag sein, dass er den harten Ausstieg Beruf zu Rente mit einer begrenzten Nebentätigkeit abmildern möchte, verstehe ich gut. Es mag sein, dass die Rente etwas knapp geraten ist, z.B. wegen langer Studienzeiten und ein paar Euro zusätzlich gewünscht sind. Es mag sein, wie bei meinem ex-Chef, das da noch ein Kind Unterstützung im Studium braucht. Also was, liefere eine sinnvollen Vorschlag oder halt's ...
Dieter H. schrieb: > MFC? Ok, das ist ja schon uralt. Das ist noch mit C++/CLI. > Eigentlich hat das ja total gefailed bzw. sich nicht durchgesetzt. Nein, MFC ist ein gutes Stück älter als .NET und funktioniert auch mit normalem C++.
Qwertz schrieb: > Im IGM Konzern gibt es bestimmt attraktive Stellen für Rentner. > Ich werde auch direkt weiterarbeiten mit 67. Selbst schuld, wer sich > auch in der Rente die 5k netto entgehen lässt. 5k netto mit 40 Jahren Berufserfahrung sind etwas mickrig, finden Sie nicht Frau Quertz?
MFC Guy schrieb: > ich habe die letzten 25 Jahre mit MFC-Programmierung verbracht, in C++. Die üblichste Variante ist doch, einfach dort weiterzumachen. Wenn die allerdings keinen brauchen, ist das blöd. Oliver
Beitrag #7080386 wurde von einem Moderator gelöscht.
Felix L. schrieb im Beitrag #7080386:
> Qwertz ist halt untersten Niveau.
Zumindest, wenn es sich um eine billige Troll-Kopie wie weiter oben im
Thread handelt.
Sorry, MFC hat keine nennenswerte Relevanz. Ernsthafte, skalierbare Anwendungen werden in Qt (C++) oder (wenn man Windows only unterwegs sein möchte) WPF, WinUi, MAUI in C# geschrieben. Im Finanzbereich ist zudem häufig JavaFX anzutreffen. Flutter wird zudem immer wieder mal erwähnt, hat sich aber meines Wissens nach in der Desktop App Entwicklung nicht durchsetzen können. Selbst in der Mobile App Entwicklung ist das eine Nische.
ChezzPlaya schrieb: > Sorry, MFC hat keine nennenswerte Relevanz Na und, Nischen sind besonders lukrativ. Und wenn sich jemand gut mit MFC auskennt, weiss was geht und wo die Limits sind, kann er ggf. schnell ein ansehnliches Windows-Programm realisieren, wo unsere supa-dupa Qt und Java Studenten noch die Toolchain aufsetzen.
ChezzPlaya schrieb: > Sorry, MFC hat keine nennenswerte Relevanz. Das ist jetzt natürlich doof. Ich hatte so um das Jahr 2005 mal gelesen, dass es viele legacy-Anwendungen in der Finanzbranche mit MFC gibt. Aber das ist ja jetzt auch schon wieder eine Weile her. Dann muss ich mich wohl damit abfinden, obsolet zu sein.
Was ist am MFC falsch? Ich habe meine größte Programme vor dem Jahr 2000 geschrieben und meistens mit MFC, bzw. kleine Dinger mit WinAPI direkt (Dialog-App), um die Code-Größe minimal zu halten. Und jetzt, wenn ich Win-Programm brauche (ich bin 99% im Embedded tätig, deswegen ist es oft nur remote-setup, Monitor, flasher etc., keine Büro-Programme), wird immer noch im MFC gemacht, immer statistisch gelinkt und deswegen keine dll-Probleme mit mfc-libs. Geht schnell und ehrlich zu sein, WFC & Co. habe ich nie verstanden plus es wird eine riesige exe für Hello world generiert, das mag ich nicht.
MFC Guy schrieb: > ich habe die letzten 25 Jahre mit MFC-Programmierung verbracht, in C++. > Ich kann das mit OpenGL kombinieren, Datenbanken, Internet, Ribbon kann > ich natürlich - meine Frage ist, kann ich damit als (demnächst) Rentner > noch etwas dazu verdienen, oder ist das alles obsolet? Ich kann das auch > mit Fortan machen, Cobol geht mit Cross-Compiler, aber am liebesten wäre > mir C++. Wie wird diese Kompetenz für legacy-Software eingeschätzt? Doku > kann ich in D, E und F schreiben. Es gibt noch einige Unternehmen, die vor längerer Zeit GUIs mit MFC entwickelt und im Laufe der Zeit so viele Investitionen hineingesteckt haben, daß sie die nicht umschreiben wollen. Du müßtest solche Unternehmen finden und ihnen Deine Expertise und Erfahrung anbieten. Die andere Alternative wäre, ein moderneres, beliebtes und vielleicht idealerweise sogar plattformunabhängiges Framework herauszusuchen -- zum Beispiel Qt -- und Dich da hineinzuarbeiten. Einen großen Teil Deiner Erfahrungen, insbesondere im Design von Benutzerschnittstellen ("Usability") kannst Du dabei wiederverwenden.
Ein T. schrieb: > Die andere Alternative wäre, ein moderneres, beliebtes und vielleicht > idealerweise sogar plattformunabhängiges Framework herauszusuchen Na ja, das Problem ist dass die APIs immer schlechter wurden. Liessen sich mit Win16 noch saubere Programme schreiben die sich tiefgreifend ins System hakten (andere Fensterrahmen, user defined Dialogelemente, etc) fiel unter Win32 schon auf dass viele neue Funktionen unbenutzte sinnlose Parameter hatte (for future use, nie eingesetzt) weil das von David Cutler stumpf von VMS kopierte Funktionalität war die unter Windows nicht passte, aber immerhin waren die Schäden am Win16 API gering am fatalsten war wohl das halbfertig von Praktikanten zerhackstückte WinHelp32. Mit MFC begann das Drama, unvollständig und fehlerhaft als C++ Krücke implementiert schränkte es die Verwendbarkeit von Windows ein ohne irgendeinen Mehrwert zu bieten. Bei DotNET, Microsofts C# (gar nicht mal schlecht von Anders Hjelsberg, aber die von Microsofts Praktikanten drangestrickten Manifests sind unsäglicher Schrott) Antwort auf Java, wurde mit WPF (wer erinnert sich noch an Rohrkrepierer wie Silverlight) gleich noch ein API über das API gesetzt, noch einschränkender, nun gab es kaum noch Durchgriff, dafür um so mehr Programmier- und Konzeptfehler. Logischerweise trennte man sich von der Schicht in dem man noch eine Schicht drübergelagelt, UWP sollte App-Ptogrammierung für Windows Phone erlauben und unter Win10 funktionieren. Nichts funktionierte, mit Ach und Krach ein Beispiel aber wehe dem du hattest 0.01 Versionsnummer Abweichung in deiner Installation, dann funktionierten nicht mal mehr Microsofts Beispiele. Begann man selbst calls zu kombinieren musst man feststellen, dass gar nichts lief, never tested, Doku gab es auch nicht. Also benennt Microsoft es schnell um in WinUI und schickt es zum BugFix über Github in die open source Community, weil interne Entwickler an dem Verhau den sie verzettelt haben gescheitert sind. Nee, je älter, je besser. Und Qt, Java, DotNET braucht alles extra Laufzeitumgebung, niemand will das.
MaWin schrieb: > Ein T. schrieb: >> Die andere Alternative wäre, ein moderneres, beliebtes und vielleicht >> idealerweise sogar plattformunabhängiges Framework herauszusuchen > > Na ja, das Problem ist dass die APIs immer schlechter wurden. > > Liessen sich mit Win16 noch saubere Programme schreiben die sich > tiefgreifend ins System hakten Da kann ich nicht mitreden, ich hab' in meinem Leben (erfreulicherweise) nur sehr wenig selbst mit Windows zu tun gehabt. Allerdings schaut man ja immer mal wieder auch nach rinks und lechts, was die anderen so machen, und da sehe ich heute (aus welchen Gründen auch immer) schon seit Ewigkeiten nicht mehr, daß neue Projekte mit der Win16- oder der MFC-API angefangen würden. Im Gegenteil habe ich in den letzten Jahren mehrere Projekte gesehen, die von älteren APIs auf neue migriert wurden. > Nee, je älter, je besser. > > Und Qt, Java, DotNET braucht alles extra Laufzeitumgebung, niemand will > das. Im Enterprisebereich sehe ich meistens Java -- heute überwiegend als Web-UI -- und anderswo auch Qt und Dotnet. Irgendwer scheint das also zu wollen zu machen, und es scheinen nicht nur die Herren Gates und Joy in ihren stillen Kämmerlein sein.
COBOL-Programmierer werden auch heute noch gesucht, weil noch viele System im Finanzbereich damit laufen
MaWin schrieb: > Mit MFC begann das Drama, unvollständig und fehlerhaft als C++ Krücke > implementiert schränkte es die Verwendbarkeit von Windows ein ohne > irgendeinen Mehrwert zu bieten. Also das finde ich gerade nicht. Ich habe auch mit Win32 gearbeitet, das war sehr viel Handarbeit. MFC ist ein sehr dünner layer über Win32, der vieles erleichtert, ohne die Anwendungen aufzublähen. Mir hat das immer Spass gemacht. Es gibt ein paar Fallstricke bei der Event-Behandlung (manche Dinge darf man erst machen, wenn die Fenster sichtbar sind), aber das ist alles klar kommuniziert und mit den richtigen Nachrichten zu schaffen. Mir gefällt, dass die Anwendungen so klein bleiben - keine deployment-Probleme, fast keine dlls, das konnte danach kein anderes Framework bieten. Aber es wird wohl so sein, wie mein letzter Praktikant gesagt hat: "Wieso so sparsam mit dem Speicher, man hat's doch". Bin eben obsolet.
Wie ich schon oft ausgefuehrt habe... Sich nicht als Code Monkey, als Tastenhaemmerer verkaufen, sondern als Loesungsfinder. Du verkaufst Loesungen, nicht Codezeilen. Deshalb den Beschrieb auf die Thematiken und den Kontext legen, nicht auf Code.
Ich liebe immer noch mein Visual Studio 6.0 (ok, mit Service Packs) und zum Glück läuft das auch noch unter Win10 - und insbesondere Prototypen programmiere ich damit schneller als mit jedem anderen System. MFC hatte eine Menge Mängel, aber eigentlich sind alle bekannt und es gibt Workarounds, damit kann ich besser leben, als mit den meisten modernen Systemen. Im Industriebereich gibt es noch viele Anwendungen die auf MFC basieren, weil Produkte dort locker auch mal 15-20 Jahre Lebensdauer haben und ein Wechsel auch teilweise neue Zertifizierungen erfordern. Insofern sehe ich hier durchaus Potential für das ein oder andere Projekt, nur Mut.
Matthias D. schrieb: > Ich liebe immer noch mein Visual Studio 6.0 (ok, mit Service Packs) und > zum Glück läuft das auch noch unter Win10 - und insbesondere Prototypen > programmiere ich damit schneller als mit jedem anderen System. Das war auch die Version von Visual Studio, die ich am längsten eingesetzt habe. Dann 2005, 2010, 2013 und jetzt aktuell 2017. Ich glaube, VS 6 konnte nur 32Bit-Anwendungen (aber vielleicht habe ich das auch falsch in Erinnerung - damals hat 64bit ja noch keine Rolle gespielt). > MFC hatte eine Menge Mängel, aber eigentlich sind alle bekannt und es > gibt Workarounds, damit kann ich besser leben, als mit den meisten > modernen Systemen. Und weil so viele schon über diese Mängel gestolpert sind, gibt's im Netz haufenweise Hilfe. Alles in allem ein stabiles System. > Im Industriebereich gibt es noch viele Anwendungen die auf MFC basieren, > weil Produkte dort locker auch mal 15-20 Jahre Lebensdauer haben Ich betreue zwei solche legacy-Anwendungen bei uns, eine ist 22 Jahre alt, die andere wird demnächst 20. War erst 32bit, dann 64bit, dann Umstieg auf Ribbon - so schafft man die 20 Jahre und bleibt trotzdem zeitgemäß! Meine grösste Krise war, als Microsoft im Rahmen von Vista ankündigte, OpenGL rauswerfen zu wollen; wäre das passiert, wäre dass das vorzeitige Ende gewesen.
Hallo MFC Guy, schreib mir doch 'mal eine PM - ich hätte da eine Idee
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.