Welches C++ nehmen?
-
Hallo,
ich möchte eine Delphi-Anwendung nach C++ portieren (wg. Zukunftssicherheit nach dem Verkauf von Codegear; BCB kommt deshalb nicht Frage).
Die Anwendung sorgt für das fehlende Teilstück in der Windows-Suche, indem sie das Suchergebnis als Textdatei speichert.
Der derzeitige Code passt auf alle Windows-Versionen von Windows 95 bis Vista; unter 64-bit-Vista läuft er als 32-bit-Prozess. Er kann aber nicht mit Unicode umgehen. Aus der VCL werden die gängigen GUI-Elemente (Splitter, TabPages, Buttons, Listboxes, Labels) sowie ein TreeView zur Darstellung der Ordnerstruktur benutzt.
Die Frage ist, welches C++ ich nehmen soll. Genauer: welches Framework bzw. Klassenbibliothek deckt sämtliche 32-bit-Windows-Versionen ab? Ab welcher Windows-Version wird Unicode unterstützt? Wie komplex ist der Umstieg auf nativen 64-bit-Windows-Code?
Ich danke für alle Ratschlage.
-
Gerhard_S schrieb:
wg. Zukunftssicherheit nach dem Verkauf von Codegear
Hättest du das _vor_ dem Verkauf getan, könnte ich es noch nachvollziehen.
Was ist denn durch den Verkauf schlechter geworden als zuvor? Der neue Besitzer ist im Gegensatz zu Borland daran interessiert, in die Entwicklung Delphi und C++Builder zu investieren.Gerhard_S schrieb:
welches Framework bzw. Klassenbibliothek deckt sämtliche 32-bit-Windows-Versionen ab?
wxWidgets zum Beispiel.
Gerhard_S schrieb:
Ab welcher Windows-Version wird Unicode unterstützt?
Windows NT 4 (vielleicht auch schon NT 3.5, aber das sollte doch out of scope sein
) unterstützt UCS-2, NT 5 und höher unterstützt UTF-16. Windows 9x unterstützt kein Unicode.Gerhard_S schrieb:
Wie komplex ist der Umstieg auf nativen 64-bit-Windows-Code?
Hängt davon ab, wie sehr du den von Microsoft vorgegebenen Konventionen bei der Win32-Programmierung folgst. Je höher das Abstraktionslevel ist, desto einfacher wird die Portierung vermutlich (anders ausgedrückt: ein Programm in Delphi/VCL oder C#/WinForms wird einfacher zu portieren sein als ein MFC-/wxWidgets-/WinAPI-Programm).
-
Also wenn es wirklich sauber programmiert ist, reicht es einfach aus architecture auf x64 umzustellen, und auf kompilieren zu drücken...
-
Unicode funktioniert auch schon "nativ" ab Win98-(SE?), ist also unabhängig vom Framework. Win95-C mit OCR 2.5 sollte auch mit Unicode umgehen können.
[ Wer heutzutage noch Win95 einsetzt, aber kein Win95-C OCR 2.5 dem ist eh nicht mehr zu helfen. ]Die Frage ist, welchen Compiler willst du verwenden ... :
Die neueren MSVC-Compiler/Studios erzeugen keine Applikationen die unter früheren Win-System lauffähig sind. Um die Win95/98-Kompatibilität sicher zu stellen mußt du also schätzungsweise den MSVC-5 nehmen (lang ists her).Mit dem MingW siehts schon besser aus.
Der baut "native" Win32-Applikationen ... also theoretisch noch lauffähig unter Win3.11
Frameworks : MFC, wxWidgets, QT
Die Windowsnähe legt natürlich das MFC nahe ... mangels Erfahrung kann ich dir aber nicht sagen, in wie weit das MFC abwärtskompatibel ist. Zusätzlich hast du noch das obige Problem mit dem passenden VC++.
wxWidgets & QT
haben den Vorteil der Platformunabhängigkeit. Du hast also (theoretisch) direkt eine Linux-Version "verfügbar", u.U. Kunden-Vorteil. Der Vorteil von wxWidgets gegenüber QT ist die bessere Lizenz ( kommerziell kostenlos ).64Bit-Code
lohnt sich absolut nicht, außer du brauchst den letzten Rest Performance.
Es gibt keinen 64bit-Umstieg. Du kannst nur eine für 64bit-kompilierte Anwendung haben.Gruß
nurF
-
Oder DotNet mit WinForms C++/CLI oder C#. Läuft aber nicht auf Win95.
-
Gerhard_S schrieb:
...Delphi-Anwendung nach C++...
Wenn du Delphi gewöhnt bist, würde ich tatsächlich eher zu C# und dem .Net Framework als zu C++ raten (Auch wegen den Oberflächendesigner). Haken an der Sache ist, das dies glaube ich erst ab Windows 2000 lauffähig ist (anderseits muss ich gestehen das alles vor 2000 eh langsam dermaßen veraltet ist, das man sich Fragen muss, ob ein Support dieser Plattformen noch rentiert).
Zur Auswahl dabei steht Windows Forms und WPF, letzeres wird wohl wenn ich die aktuelle MS Strategie ansehe zukunftssicherer sein, dafür läuft es sogar erst ab Windows XP Servicepack 2. Ein Ableger der WPF existiert auch für das Internet: Silverlight (Falls es mal relevant werden sollte).
cu André
-
:schland: asc schrieb:
-
nurf schrieb:
Unicode funktioniert auch schon "nativ" ab Win98-(SE?), ist also unabhängig vom Framework. Win95-C mit OCR 2.5 sollte auch mit Unicode umgehen können.
[ Wer heutzutage noch Win95 einsetzt, aber kein Win95-C OCR 2.5 dem ist eh nicht mehr zu helfen. ]Aber nur in Verbindung mit Unicows. Windows 9x selbst unterstützt nur wenige ausgewählte Unicode-Funktionen.
nurf schrieb:
Die Frage ist, welchen Compiler willst du verwenden ... :
Die neueren MSVC-Compiler/Studios erzeugen keine Applikationen die unter früheren Win-System lauffähig sind. Um die Win95/98-Kompatibilität sicher zu stellen mußt du also schätzungsweise den MSVC-5 nehmen (lang ists her).VC6 klappt auf jeden Fall, VS2005 sollte eigentlich auch noch unter Windows 9x lauffähige Dateien erstellen können.
-
Ich würde C++ nehmen: zwischen C++ und VC++ besteht ein Unterschied: VC++ ist eingeschränkt. Ist für einfache Programme gedacht, da diese Sprache nicht so schnell abstürzt, wie C++, denn hier kann der Kompiler eibnige sachen korrigieren, was auch die Eingeschränktheit erklärt.
-
Kenner des C++ schrieb:Ich würde C++ nehmen: zwischen C++ und VC++ besteht ein Unterschied: VC++ ist eingeschränkt. Ist für einfache Programme gedacht, da diese Sprache nicht so schnell abstürzt, wie C++, denn hier kann der Kompiler eibnige sachen korrigieren, was auch die Eingeschränktheit erklärt.
Klar, manchmal muss man einfach dummfug schreiben.
-
Kenner des C++ schrieb:
Ich würde C++ nehmen: zwischen C++ und VC++ besteht ein Unterschied: VC++ ist eingeschränkt. Ist für einfache Programme gedacht, da diese Sprache nicht so schnell abstürzt, wie C++, denn hier kann der Kompiler eibnige sachen korrigieren, was auch die Eingeschränktheit erklärt.
Wieso schafft es dieser untode Troll immer wieder aus seinen Grab aufzuerstehen, und immer wieder den gleichen Quatsch zu schreiben. Wenigstens etwas neues könnte sich der "Nicht-Kenner" mal einfallen lassen.
-
Ich denke das war nur ein Zitat, um an die guten alten Zeiten zu erinnern, als Spieleprogrammierer hier noch so richtig trollte.
-
nurf schrieb:
Unicode funktioniert auch schon "nativ" ab Win98-(SE?), ist also unabhängig vom Framework. Win95-C mit OCR 2.5 sollte auch mit Unicode umgehen können.
Tatsächlich? Link?
nurf schrieb:
Der baut "native" Win32-Applikationen ... also theoretisch noch lauffähig unter Win3.11
Unter 16-Bit-Windows? Glaube ich kaum.
Oder meinst du Win32s?nurf schrieb:
Frameworks : MFC, wxWidgets, QT
MFC wohl eher nicht. Die neueren Versionen unterstützen Windows 98 nicht mehr, und das soll ja offenbar ein Kriterium sein. Es bleiben wxWidgets und Qt, eine Open-Source- und eine weitere kommerzielle Lösung.
Trolltech wurde übrigens auch gerade gekauft, und zwar von Nokia. Bleibt also wxWidgets
Wenn es denn wirklich auf allen Win32-Plattformen lauffähig sein soll, dann bleibe doch einfach bei der gegenwärtigen Lösung mit Delphi. Ganz unabhängig davon, wie die Zukunftsperspektive bei CodeGear oder Microsoft jetzt ist: weder von MFC noch von VCL werden die zukünftigen Versionen Windows 9x unterstützen. Und solange eure Delphi-Version noch läuft, ist der Kostenaufwand für eine Neuentwicklung eigentlich nicht zu rechtfertigen.
-
nurf schrieb:
Die neueren MSVC-Compiler/Studios erzeugen keine Applikationen die unter früheren Win-System lauffähig sind. Um die Win95/98-Kompatibilität sicher zu stellen mußt du also schätzungsweise den MSVC-5 nehmen (lang ists her).
So ein Unsinn! Visual C++ 2005 macht noch immer Anwendungen, die unter Windows-98 lauffähig sind. Erst ab Version 2008 ist Schluss damit.
nurf schrieb:
Mit dem MingW siehts schon besser aus.
Der baut "native" Win32-Applikationen ... also theoretisch noch lauffähig unter Win3.11So ein Schwachsinn! Erstens erstellt auch Visual C++ native Anwendungen. Zwitens ist Windows 3.11 16 Bit. Wie willst du da eine Win32-Anwendung zum laufen bringen.