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
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.
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
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.
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.
