Auf aktuellen C++ builder umstellen

Computer: Software & Programmierung C/C++
#1

Hallo!

Ich möchte gerne ein altes Programm mit dem vor kurzem noch aktuellen Embarcadero XE2 Studio neu compilieren (aktueller C+±Builder, ehemals Borland).

Das Programm wurde ebenfalls mit einer C+±Builder Version erstellt, allerdings etwa vor 20 Jahren. Es wird zur Zeit auch weiter entwickelt (mit der 20 Jahre alten IDE) und soll nun auf die neue IDE umziehen.

Dazu wurden mir alle benötigten .cpp, .h und .res gegeben, allerdings keine borland-projekt-Datei. Ich nehme an, damals wurde noch nicht in Projekten zusammengefasst.

Das eigentlich Problem ist aber, dass einige Include-Pfade in der Haupt-Datei (.cpp) falsch sind (kann ich notfalls noch korrigieren) und dass ich nicht genau weiß, wie ich die Dateien in ein neues Projekt einbinden soll. Sicher kann ich sie über „Hinzufügen“ mitkompilieren, aber was ist mit dem Rest des Projektes, das dazu neu angelegt werden muss? Kann der irgendwie wieder entfernt werden? oder sollte man gleich etwas wie „Konsolenanwendung“ nehmen, wobei möglichst wenig Code erzeugt wird?
Ich wird dort u.a. die owl-Komponente benutzt, um eine grafische Oberfläche zu erzeugen. Soweit ich mich aber informiert habe, kann diese auch im aktuellen XE2 dazu installiert werden.

Zusammenfassend wollte ich mal fragen, ob sich jemand mit solchen IDE-Upgrades auskennt und ob das so läuft, wie ich mir das vorstelle.
Und ob es weitere Dinge gibt, auf die ich unbedingt achten muss oder ob ich lieber neu anfangen und lediglich noch funktionierende Includes/Funktionen übernehmen sollte.
Eventuell sollte man dazu schreiben, dass hier nicht objektorientiert, also ohne Unterteilung in Klassen mit Konstruktoren und ohne Vererbungen programmiert wurde.

Ich freue mich auf eure Antworten!

#2

Tschuldigung dass ich mich erst heute melde.
Ist das Thema noch aktuell?

Uli

#3

Ja, sicher!

Es ist ein größeres Programm und ich habe schon einige Dateien umgeschrieben. Größtenteils sind es Anpassungen der Include-Pfade, allerdings scheinen einige Funktionen nun andere Parameter zu erwarten. Häufig erhalte ich Fehlermeldungen, char* oder ähnliches sei erwartet und das übergebene könne nicht ohne weiteres konvertiert werden. Meist ist das aber schnell behoben und unproblematisch…
Was mich etwas verwundert hat, waren Funktionen, die Point-Werte erwarteten, aber wenn man den Point-Wert im Funktionsaufruf erstellt hat, gab es einen Fehler, der L-Wert sei kein Point. Erst nachdem ich explizit vorher den Point in eine Variable gesteckt habe und diese übergab, gab es keinen Fehler mehr.

Ich hoffe bloß, ich trample nichts wichtiges nieder…

#4

tschuldigung, schon wieder eine Woche um… im Moment einfach zu viel um die Ohren!

es wundert mich warum die alte IDE keine Pojekt-Datei haben soll - ich habe vor 20 Jahren mit Turbo-C auf DOS gearbeitet und selbst da wurde mit Projekt-Dateien gearbeitet, hier hiessen sie xxx.PRJ

1998 stellt ich auf C-Builder 3.0 um - hier hiessen sie dann über mehrere Versionen xxx.BPR
(Die DOS-version konnte ich nicht konvertieren und musste auch alles zu fuss machen)

2008 stellte ich dann auf die Version von CodeGear (Embarcadero) C-Builder 2007 um seitdem heissen sie xxx.CBPROJ
Seit 1998 wurden bei jedem Update auf eine neue C-Builder Version meine Projekte vom C-Builder (nach abfrage) automatisch umgestellt.

Welche C-Builder Version ist denn die 20-Jahre alte IDE?

#5

Ich habe mittlerweile die Pfade in der Hauptdatei zurück verfolgt und festgestellt, dass es eine .ide-Datei gibt, die wohl die Projekt-Datei war. Diese lässt sich mit meinem C+±Builder allerdings nicht öffnen.

Momentan habe ich eigentlich nur einen Fehler zu bewältigen:

[BCC32 Fehler] AcMode_TS_Dial.CPP(13): E2285 Keine Übereinstimmung für ‚b_LV_DISPINFO_NOTIFY_Sig(void (TTSCalibDialog::*)(TLvDispInfoNotify &amp:wink:)‘ gefunden while the second argument is declared void MassCol_EndLableEditResp(TLwDispInfoNotify& nmHdr)
{MassCol->EndLableEditResp(nmHdr);};

dieser Tritt bei
EV_LVN_ENDLABELEDIT(IDC_CALIBMASSES, MassCol_EndLableEditResp)

und einigen anderen ähnlichen Befehlen auf.
Es geht hier wohl um das TextChange-Ereignis von Labeln… Diese Befehle stammen aus der s.g. OWL-Bibliothek, evtl sind’s auch schon OwlNext.

Dieser Befehl steckt in einem größeren zur Erstellung des Labels:
DEFINE_RESPONSE_TABLE1(TTSCalibDialog, TDialog) EV_LVN_ENDLABELEDIT(IDC_CALIBMASSES, MassCol_EndLableEditResp), EV_COMMAND(IDC_CALIBRATEBUT, CalibrateResp), EV_COMMAND(IDC_CALIBSAVEBUT, CalibSaveResp), EV_COMMAND(IDC_CALIBLOADBUT, CalibLoadResp), EV_COMMAND(IDC_CALIBRESTORE, CalibRestoreResp), EV_COMMAND(IDC_CALIBSETNUMMASSES, CalibSetNumMassesResp), EV_WM_DESTROY, // Ev_WM_Destroy END_RESPONSE_TABLE;

Ich habe die Argumente allerdings schon geprüft und es scheinen die korrekten Typen zu sein… weißt du evtl, wo der Fehler herkommt?

#6

Ah, toll… da vertraut man mal auf die „erlaubten Tags“ und dann fehlt da wieder was^^

Hier nochmal der Beitrag mit lesefreundlichen Codeblöcken:

Ich habe mittlerweile die Pfade in der Hauptdatei zurück verfolgt und festgestellt, dass es eine .ide-Datei gibt, die wohl die Projekt-Datei war. Diese lässt sich mit meinem C+±Builder allerdings nicht öffnen.

Momentan habe ich eigentlich nur einen Fehler zu bewältigen:

[BCC32 Fehler] AcMode\_TS\_Dial.CPP(13): E2285 Keine Übereinstimmung für 'b\_LV\_DISPINFO\_NOTIFY\_Sig(void (TTSCalibDialog::\*)(TLvDispInfoNotify &amp:wink:)' gefunden while the second argument is declared void MassCol\_EndLableEditResp(TLwDispInfoNotify& nmHdr)
{MassCol-\>EndLableEditResp(nmHdr);};

dieser Tritt bei

EV\_LVN\_ENDLABELEDIT(IDC\_CALIBMASSES, MassCol\_EndLableEditResp)

und einigen anderen ähnlichen Befehlen auf.
Es geht hier wohl um das TextChange-Ereignis von Labeln… Diese Befehle stammen aus der s.g. OWL-Bibliothek, evtl sind’s auch schon OwlNext.

Dieser Befehl steckt in einem größeren zur Erstellung des Labels:

DEFINE\_RESPONSE\_TABLE1(TTSCalibDialog, TDialog) EV\_LVN\_ENDLABELEDIT(IDC\_CALIBMASSES, MassCol\_EndLableEditResp), EV\_COMMAND(IDC\_CALIBRATEBUT, CalibrateResp), EV\_COMMAND(IDC\_CALIBSAVEBUT, CalibSaveResp), EV\_COMMAND(IDC\_CALIBLOADBUT, CalibLoadResp), EV\_COMMAND(IDC\_CALIBRESTORE, CalibRestoreResp), EV\_COMMAND(IDC\_CALIBSETNUMMASSES, CalibSetNumMassesResp), EV\_WM\_DESTROY, // Ev\_WM\_Destroy END\_RESPONSE\_TABLE;

Ich habe die Argumente allerdings schon geprüft und es scheinen die korrekten Typen zu sein… weißt du evtl, wo der Fehler herkommt? … mehr auf http://www.wer-weiss-was.de/app/query/display_query?..

#7

also .ide-Datei sieht nicht nach einer Projekt-Datei aus.

Aber die fehlende Projekt-Datei ist auch nicht Dein wirkliches Problem, denn auch wenn Du sie hättest, dann würden die jetzigen Fehler trotzdem auftreten.

Da hast Du dir aber einen mächtigen Brocken aufgeladen:
alles was heutzutage die VCL erledigt von Hand zu erzeugen, bzw. umzustellen.

Ehrlich gesgt habe ich noch nie mit owl gearbeitet.

Und genauso wie die schon vorher beschriebeben Pointer-Unstimmigkeiten vom alten zum neuen C-Builder, sind die jetzigen BCC32-Fehlermeldungen kompatibilitäts Probleme.

Ich stand auch häufig vor der Frage: anpassen oder neues Projekt?

Ein neues Projekt anzulegen und die Code-Files des alten Programmes einzubinden ist nicht das Problem. Auch die von Dir im ersten Mail gestellte Frage was mit dem überflüssig gewordenen File des neuen Projektes passieren soll, dies kann einfach aus dem Projekt gelöscht werden.

Ich würde dann auch statt der owl-Objekte, die standard Komponenten benutzen um das aktuelle Problem zu umgehen, und für die zukünftigen BCC-Updates nicht abermals Anpassungen vornehmen zu müssen.

Nur, die Feldbehandlungs-Routinen an denen es gerade kränkelt, kannst Du ja nicht einfach beiseite lassen. In ihnen sind bestimmt auch Behandlungen die den Programmablauf bestimmen sollen.

#8

MMh…
Das Problem ist, dass das Programm lang ist… die mein.cpp hat ~200.000 Zeilen plus noch 8 include-Dateien…
Ich könnte mich dort natürlich durch wursteln und mit vlc setzen und einstellen, das das Programm bislang macht, allerdings habe ich auch hier ein entscheidendes Problem:
Ich kann den OWL-Code nicht einfach nachvollziehen, welche Funktion jetzt zu welchem Event gehört und wofür welche Konstante als Eigenschaft steht. Man könnte das evtl aus dem Programm (exe) ableiten, diese lässt sich allerdings nur auf einem Rechner mit entsprechender Hardware (Zusatz-Geräte über USB etc.) fehlerfrei starten.

hat Borland nicht mal gesagt, dass eine Projekte Abwärtskompatibel seien? also neue IDEs alte Projekte öffnen und kompilieren können? Ich meine in einem Buch darüber gelesen zu haben.
Muss ich nun wirklich die Programmoberfläche und Einbindung neu in VLC schreiben? Oder kennst du vielleicht jemanden, der mit OWL Erfahrung hat?

mit freundlichen Grüßen
Julian Bergmann

#9

Ich kenne nur einen der das Alter hat um mit owl gearbeitet haben könnte, jedoch weiss ich von ihm dass er es nie im Beruf gemacht hat. Aber ich werde ihn gleich mal mailen.

das mit der borländschen Abwärtskompatibilität trifft zu, dass hebe ich ja mit meinen Projekten erfahren: wie gesagt ich habe 1998 mit C-Builder 3 begonnen, dann mit 5 und 6 weitergemacht,und 2008 auf CodeGear 2007. Jedesmal wurden die Projekte entsprechend umgewandelt.
Ich habe auch grade mal ein Projekt der 3-er Version mit dem 2007-er geöffnet - also 4 Versionen übersprungen - geht auch.
Jedoch gab es manchmal Probleme mit Komponenten von anderen Herstellern die dem Builder-Paket beigepackt sind z.B. für eMails oder FTP-Connections.
Plötzlich gibt es diese nicht mehr, stehen aber von einem anderen Anbieter zur Verfügung. Und dann muss alles per Hand umgebaut werden.

Aber die Abwärtskompatibilität bringt bei Dir ja wohl nichts, wenn es keine Projekt-Datei gibt.
Wenn Du sagst dass es nur eine Code-Datei mit einigen Include-Dateien gibt, dann liegt wohl tatsächlich kein klassisches Projekt vor.
Du kannst Dir nicht mal zeigen lassen wie in der 20 Jahre alten Entwicklungsumgebung das ‚Projekt‘ geladen wird um zu sehen ob da wirklich keine Projektdatei benutzt wird?

Das würde mich nur mal interessieren, weiter würde es Dich aber vermutlich nicht bringen, da zwar alle projektbezogenen Informationen geändert werden, am programmierten Code wird aber nichts verändert. Ob er funktionstüchtig ist, bringt erst der Compiler zum Vorschein.
Und dann bist Du wieder da wo Du jetzt bist.

Haben denn vielleicht die Entwickler des alten Programmes nicht eine Doku, oder gibt es dort nicht Programmierer die noch am Programm arbeiten (so wie ich Dich verstanden habe) die Dir die Events erklären können?