Kann man mit normalem C++ irgendwann keine Windows-Programme mehr schreiben?
-
Ok. überleg. 5 Jahre. Win '95 war das 32Bit - System von MS. 5 Jahre später kam 2000 raus ohne Support für 16Bit Anwendungen.
Ja, aber für Win32 gibt es viel mehr Software. Ich denke nicht, dass MS das so schnell kicken wird. Vorallem wurde Windows ME ja noch bis 2001/2002 verkauft :p
Sie sind nicht ganz ideal zum Portieren, ja. Nichts ist ideal, auf Avalon portiert zu werden. Was das allerdings mit OpenSource zu tun hat, ist mir ein Rätsel. Ich könnte ohne allzu große Probleme einen Wrapper um Winforms für MFC schreiben. Für das WinAPI tu ich mich da allerdings schwer.
Wenn du irgend eine API nachbauen als zukunftssicher bezeichnest, dann ist ja jede API zukunftssicher, da du jede API irgend wie auch nachbauen kannst.
Natürlich sind da einige APIs besser für geeignet und andere weniger.
Gibt es irgend welche umfangreichen MFC nachbauten?
Wine funkitioniert IMHO heute noch nicht richtig
100% sicher nicht, aber das wird auch keiner deiner MFC um WinForms wrapper tun
Sobald eine API eine gewisse komplexität erreicht hat, wird es schwer diese nachzubauen und so eine RundumLibraryMitGui ist eben extrem komplex, vorallem wenn die API sich evolutionär entwickelt hat und man nicht viel über das Innenleben weiß.
-
Ok. überleg. 5 Jahre. Win '95 war das 32Bit - System von MS. 5 Jahre später kam 2000 raus ohne Support für 16Bit Anwendungen.
Auf Windows XP laufen auch noch 16-Bit Anwendungen. Also dann auf Windows 2000 natürlich auch.
http://www.zdnet.de/downloads/prg/c/g/de00CG-wc.html
Falls du es mal testen willst
Oder was meintest du mit Support?
-
Ich verstehe eben nicht warum alle davon ausgehen, dass MFC/WINAPI innerhalb der nächsten Jahre aussterben soll? Es gibt so verdammt viele, verdammt bekannte kommerzielle Programme, die darauf aufsetzen. Somit wäre es für Microsoft absolut geschäftsschädigend diese einfach zu kicken. Und der jahrelang nachhaltende Support für DOS zeigt, dass Microsoft (mit Abstrichen) schon auf Abwärtskompatibilität setzt.
Microsoft erzählte schon zu oft "C++ stirbt aus"...
-
Wann haben sie denn das zuletzt gesagt? Muss vor meiner Zeit gewesen sein.
-
operator void schrieb:
Wann haben sie denn das zuletzt gesagt? Muss vor meiner Zeit gewesen sein.
Die Einführung von Sprachen wie C# impliziert das doch bereits.
Außerdem muss man sich als normaler C++ Programmierer mit MFC schon verarscht fühlen. Ohne riesige Klassensets, um überhaupt annähernd ein GUI zu kreieren, das aktuellem Standard entspricht, geht garnichts (man denke an standardmäßig 16 Farben bei vielen Icons...).
Das ist das, was ich an der Geschäftspolitik bzgl. Entwicklerprodukten bei Microsoft so schleierhaft finde. Der, der reine und effektive Windows-Anwendungen (da kommt man um WINAPI-WRAPPER jeglicher Art kaum herum) programmiert, somit an die Zukunft des Microsoft-Betriebssystems glaubt, auf diese setzt und Microsoft vertraut, schaut in die Röhre.
-
Die Einführung von Sprachen wie C# impliziert das doch bereits.
Nein. Aber es ist für Sprachen wie C# einfach leichter, sie in die .Net Plattform zu integrieren. C++ kann einfach zuviel.
Außerdem gibt es noch Leute (wie mich), die C++ gar nicht so gerne mögen.Der, der reine und effektive Windows-Anwendungen (da kommt man um WINAPI-WRAPPER jeglicher Art kaum herum) programmiert, somit an die Zukunft des Microsoft-Betriebssystems glaubt, auf diese setzt und Microsoft vertraut, schaut in die Röhre.
Ach, lol. Jaja, die tollen Effizienz-Master, die Super-Optimierer, die ne GUI, die 99% der Zeit schläft, in WinAPI und Assembler coden, damit sie effizienter ist. Und praktisch gar nicht mehr zu portieren. seufz.
-
Optimizer schrieb:
Jaja, die tollen Effizienz-Master, die Super-Optimierer, die ne GUI, die 99% der Zeit schläft, in WinAPI und Assembler coden, damit sie effizienter ist. Und praktisch gar nicht mehr zu portieren. seufz.
Hier gehts effizienzmäßig nicht nur um die GUI! Seit wann schlafen GUIs 99% der Zeit? Außerdem bemerke ich beispielsweise schon Geschwindigkeitsunterschiede zwischen Java-GUIs und MFC/C++-GUIs...
Optimizer schrieb:
Und praktisch gar nicht mehr zu portieren.
Wer sagt das? Sind QT und wxWidgets wohl nicht portabel?
-
Er spricht von WinAPI und Assembler und du von QT und wxWidgets? Irgendwie redet ihr an einander vorbei.
-
simon.phoenix schrieb:
Seit wann schlafen GUIs 99% der Zeit?
Jedenfalls sollten sie das tun.
Außerdem bemerke ich beispielsweise schon Geschwindigkeitsunterschiede zwischen Java-GUIs und MFC/C++-GUIs...
Ich nicht. Ich kann SWT nicht von WinAPI unterscheiden.
Wer sagt das? Sind QT und wxWidgets wohl nicht portabel?
Die Rede war doch von WinAPI. Ich sehe gerade, dass ich dich vielleicht misverstanden habe. Ich sehe jetzt zwei Möglichkeiten:
- du trauerst der WinAPI-Programmierung nach. So habe ich es erst verstanden. Dann verstehe ich nicht, warum du mit wxWidgets jetzt kommst.
- du trauerst der MFC nach. Die ist aber nicht "effizienter" als z.B. Winforms. Die sind genauso ein Wrapper um die Betriebssystem-Funktionen. Dann verstehe ich überhaupt nicht, worauf du hinauswillst und was das mitDer, der reine und effektive Windows-Anwendungen (da kommt man um WINAPI-WRAPPER jeglicher Art kaum herum) programmiert, somit an die Zukunft des Microsoft-Betriebssystems glaubt, auf diese setzt und Microsoft vertraut, schaut in die Röhre.
zu tun hat.
Inwiefern schaust du in die Röhre? Ich verstehe dein Problem nicht. Irgendwas scheinst du gegen high-level GUIs zu haben, obwohl es gerade bei GUIs so egal ist.
-
Wer sagt das? Sind QT und wxWidgets wohl nicht portabel?
Die Rede war doch von WinAPI. Ich sehe gerade, dass ich dich vielleicht misverstanden habe.
Sorry, dachte es wäre von Wrappern/APIs im Allgemeinen die Rede gewesen.
Ich sehe jetzt zwei Möglichkeiten:
- du trauerst der WinAPI-Programmierung nach. So habe ich es erst verstanden. Dann verstehe ich nicht, warum du mit wxWidgets jetzt kommst.
- du trauerst der MFC nach...Nachtrauern tue ich in gewisserweise der MFC und zwar weil ich sie gerne weiterverwenden möchte, aber sie aus bestimmten Gründen irgendwo einfach nicht abkann (Stilfragen, zu überladen, veraltetes GUI, etc). Außerdem bin ich aus geschäftlichen Gründen zusätzlich gebunden, sie zu benutzen.
Irgendwas scheinst du gegen high-level GUIs zu haben, obwohl es gerade bei GUIs so egal ist.
In Bezug auf GUIs fühle ich mich eben von den MFC (gegen die ich grundsätzlich nichts habe) verarscht. Microsoft bietet hier standardmäßiges GUI-Design, wie es vielleicht zu Win95-Zeiten aktuell war. Wie ich bereits erwähnte, kommt man also um die Verwendung von Unmengen (-> Fehlerquelle Third-Party-Freeware-Programmierer; nicht falsch verstehen, die Leute verdienen Respekt. Der Code ist leider aber oft buggy.) fremden Codes nicht herum, den man mühevoll anpassen muss.
Inwiefern schaust du in die Röhre? Ich verstehe dein Problem nicht.
In die Röhre schaut momentan finde ich derjenige der unter C++ reine Windows-Anwendungen schreiben möchte, eben aus o.g. Gründen. Und ich denke aufgrund der Verbreitung von Windows gerade im Client-Bereich ist dieser Gedanke nicht aus der Luft gegriffen.
-
simon.phoenix schrieb:
In die Röhre schaut momentan finde ich derjenige der unter C++ reine Windows-Anwendungen schreiben möchte, eben aus o.g. Gründen. Und ich denke aufgrund der Verbreitung von Windows gerade im Client-Bereich ist dieser Gedanke nicht aus der Luft gegriffen.
Wieso?
wxWidgets ist fein, Qt ist auch OK. Und C++/CLI ist sogar sehr fein.also so schlimm sieht es nicht aus.
aber klar, das einstellen der MFC und der VCL zeigt sicher wirkung.
-
Also nach dem Einstellen der MFC siehts noch lange nicht aus. Bis jetzt wird sie immer weiterentwickelt. Jedenfalls erhöhen sie die Versionsnummer bei jeder Visual C++ Version.
(Visual C++ 2005 => MFC 8.0)
-
8.0 schrieb:
Also nach dem Einstellen der MFC siehts noch lange nicht aus. Bis jetzt wird sie immer weiterentwickelt. Jedenfalls erhöhen sie die Versionsnummer bei jeder Visual C++ Version.
(Visual C++ 2005 => MFC 8.0)aber es tut sich nix.
die MFC beim vc++8 kenne ich zwar nicht, aber von 6er auf 7.1er hat sich nicht viel getan...das problem ist aber avalon - wenn MFC dafuer nicht angepasst wird, schaut es traurig aus.
-
Hallo,
von Arbeit her komme ich auch mit Visual FoxPro in Kontakt die RuntimeDlls
VFP[Version].dll sind gegen die MSVC[Version].dll gelinkt.Von MS aus besteht für VFP Support bis 2012. In der Version 9.0, erscheint
dieses Jahr wird es erstmals möglich sein auf Windowsereignisse WM_HasteNichtGesehen und Co. zuzugreifen.VFP ist und wird definitiv nicht Bestandteil von .Net, weil man hat es mir mal erklärt beim Techtalk ( MS - Veranstaltung ) es einfach nicht möglich ist, weiß der Geier warum.
MfG
RB
-
...das einstellen der MFC und der VCL zeigt sicher wirkung.
Die VCL wird noch lange nicht eingestellt. Warum die Leute immer dieses Gerücht umbedingt am Leben halten wollen.
-
MFC IMHO auch nicht. MFC ist mit Sicherheit nicht so schwer, auf Winforms oder Avalon zu portieren, wie das WinAPI.
-
Ich würde mal sagen das ist genauso schwer. MFC abstrahiert nicht weit genug von der WinAPI. Und das ist auch gut so. :xmas1:
-
hmmmm schrieb:
Ich würde mal sagen das ist genauso schwer. MFC abstrahiert nicht weit genug von der WinAPI. Und das ist auch gut so. :xmas1:
full ack. Das Abstraktionslevel ist oft sehr gering. Ich kenne eine eventuelle Avalon-API zwar nicht, aber eine Umstellung der MFC auf diese dürfte womöglich kein leichtes sein.
Deshalb bin ich der Meinung, dass MFC in der jetzigen Form am Leben erhalten wird und der Support erst in vielen Jahren fallen wird, auch wenn Microsoft anderweitiges behauptet um vielleicht jeden dazu zu bringen dotnet zu benutzen... (kommerzieller Grund)
-
die MFC beim vc++8 kenne ich zwar nicht, aber von 6er auf 7.1er hat sich nicht viel getan...
Naja, wenigstens hat Microsoft versucht mit Compiler und auch den MFC standardkonformer zu werden. Auch wenn das nicht gerade der große Wurf war, wie du schon sagtest.
-
MFC wurde bisher in 7.0 und 7.1 zumindest gepflegt. Es ist zwar nicht großartiges passiert, aber viel wichtiger ist, das MS wenigstens die MFC pflegt und jeder neuen VC++-Version beilegt. Das wird sicherlich in Zukunft erstmal so bleiben, da zu viele Programme die MFC benutzen. Und sollte MS mal wirklich mit der MFC nichts zu tun haben wollen, kann ich mir gut vorstellen, das sie es ähnlich wie WiX und die WTL als OpenSource frei geben.
Also, alles paletti und blos keine Panik!