Antikes Programm - alte Borland Units

[HHick123]

Hallo Leute,
ich habe gerade den Job übernommen, ein antikes Programm in die Neuzeit (z.B. Delphi2006) zu heben.
Dabei bin ich mir momentan noch gar nicht sicher, für welche Compilerversion es ursprünglich gedacht war (Ich tippe auf "Borland Pascal 7.0" oder "Turbo Pascal for Windows 1.x").

Im Prinzip handelt es sich um ein Windows-GUI (mit einer enormen Menge an Fenstern), dass im Hintergrund auf eine Oracle-Datenbank 8.xx zugreift.

Ein erster Blick hat ergeben, dass es sich um zirka 260 :shock: units handelt,
die sich untereinander benötigen, aber auch folgende alte Borland-Units verwenden:
COMMDLG,CRT,DOS,FILEDLGS,OBJECTS,ODIALOGS,OMEMORY, OPRINTERS,OSTDDLGS,OSTDWND,OWINDOW,STDDLG,STRINGS, toolbar,TPSTRING,VALIDATE,WINDOS.

Gibt's da irgendeine Standard-Vorgangsweise, durch welche heutigen Units ich die ersetzen kann, oder gibt es Ersatz-Units, die sich auch heute noch kompilieren lassen, um eine sanfte Portierung zu ermöglichen...

Viele Grüße,
Helmut

[mkinzler]

Scheint sie ja eher um ein DO-Programm zu handeln. Der beste Weg scheint mir die Neuentwicklung der GUI zu sein.

[Assertor]

Mist, ich hab den falschen Eintrag editiert... :roll:

Kurz nach Gedächtnis:

Hier stand ursprünglich der Hinweis, daß die Dateien ja zum Teil aus dem OWL kommen, es für C++ das OWLNext gibt und teilweise ja Funktionen sogar noch 16bittig waren.

Dann schrieb ich, es sei besser das ganze From-The-Scratch neuzuschreiben.

Gruß Assertor

[mkinzler]

Oder besser umbauen statt nachbauen. Hierbei strikt nach MVC und Logik, Design und Daten trennen.

[Assertor]

Zitat:

Zitat von mkinzler

Oder besser umbauen statt nachbauen. Hierbei strikt nach MVC und Logik, Design und Daten trennen.

Die Trennung ist klar, das habe ich mal vorausgesetzt für einen Profi ;)

Aber ob das "Umbauen" bei der Anzahl nicht-kompilierender Forms und Funktionen besser ist? Ich sage, Rewrite-From-Scratch ist besser. :mrgreen: Dann weiß der TE wenigstens, was-wie-wo passiert und kann gleich aufräumen.

Gruß Assertor

[mkinzler]

Na die Logik kann er schon übernehmen, er muss sie halt u.U. nur entweben

[SvB]

Hi, ich bin gerade dabei ein DOS Programm, das mal mit Clipper geschrieben wurde (DBF-Datenbanken) auf Windows "umzustellen". Da man das nicht direkt umwandeln kann blieb nur eine Neuentwicklung übrig. Man kann dann natürlich auch direkt aktuelle Techniker mit einbauen. Von der Logik her habe ich die alten Sources ausgedruckt, bin Zeile für Zeile durchgegangen und habe sie entsprechend nach Delphi umgebaut und eingebaut, dann mit dem Stift auf Papier durchgestrichen, was erledigt ist und im Ordner abgeheftet. Somit wächst Stück für Stück ein neues Programm, das "überspützt" fast mit dem alten nichts mehr zu tun hat.

Also: Neuentwicklung ist schon besser.

Grüße Sven

[Assertor]

Zitat:

Zitat von mkinzler

Na die Logik kann er schon übernehmen, er muss sie halt u.U. nur entweben

Zitat:

Zitat von Assertor

... Funktionen nachbauen.

@mkinzler: Wir reden aneinander vorbei und dabei meinen wir doch das Gleiche - ich empfehle nur sich nicht mit alten Forms rumzuschlagen und das "entweben" ist ja das "nachbauen" ;)

Mir stieß nur dein "besser" Umbauen auf. Aber gut :cheers:

:dp:

[Assertor]

Hi Sven,

Deine vorgehensweise finde ich sehr gut, schon fast vorbildlich :thumb:

Deine Tor-Chance muß ich aber nutzen:

Zitat:

Zitat von SvB

Man kann dann natürlich auch direkt aktuelle Techniker mit einbauen.

:zwinker:

Gruß Assertor

[SvB]

Oh, da ist ein kleiner Verschreibseler aufgetreten. Es soll natürlich heißen:

Zitat:

Man kann dann natürlich auch direkt aktuelle Techniken mit einbauen

Immer das Problem, dass man die Weckstaben verbuchselt.

Grüße Sven

[RavenIV]

Zitat:

Zitat von SvB

Also: Neuentwicklung ist schon besser.

Das ist aber keine Neu-Entwicklung, sonder nZeile für Zeile Nachbauen.
Die einzige Neuerung ist dabei das Delphi.

Eine Neuentwicklung würde (in meinen Augen) anderst ablaufen.
- Quellcode, Struktur und Funktion des alten Programms analysieren
- in kleine Teile zerlegen
- GUI-Design, Datenstruktur und Klassenstruktur entwicklen
- aufgrund dieser Basis den Quellcode erstellen
- Testen, ob das neue Programm wirklich die Funktion des alten Programms darstellt

Für eine Neuentwicklung darf ruhig ein neues DBMS und eine Klassenhierarchie verwendet werden.
Dabei kann man die Datenbank auch gleich normieren.
Es dürfen auch Module zusammengefasst werden

[HHick123]

Zitat:

Zitat von SvD

bin Zeile für Zeile durchgegangen

Der war gut... Das Ding hat sage und schreibe etwa 240.000 lines of code (ohne die Borland-Units)...
:-D :-D

[RavenIV]

Zitat:

Zitat von HHick123

Das Ding hat sage und schreibe etwa 240.000 lines of code (ohne die Borland-Units)...
:-D :-D

Davon kann man bestimt 1/3 vergessen, weil es toter Code ist.
Der Rest wird analysiert und "eingedampft".
Dabei erkennt man dann auch Ungereimtheiten oder sogar Fehler.
Durch ein gescheites SW-Design mit einem ausführlichen Klassenmodell wird daraus dann eine richtig gute Software.

[SvB]

Zitat:

Zitat von HHick123

[bin Zeile für Zeile durchgegangen

Tja, wie willst Du denn den Code übernehmen, geschweige denn verstehen, was da passiert.
Man kann natürlich auch 1:1 übernehmen und hoffen, dass es funktioniert.

Mein altes Programm hat schätzungsweise 30.000 Zeilen Code und mit aktuellen Anforderungen sitze ich dan schon ca. 3 bis 4 Monate dran.
Da hast Du dann ja noch etwas vor Dir. Ich wünsche Dir schon mal viel Erfolg

Grüße Sven

[RavenIV]

Zitat:

Zitat von SvB

Da hast Du dann ja noch etwas vor Dir. Ich wünsche Dir schon mal viel Erfolg

Wenn das eine Ein-Mann-Show gibt, dann ist der Job für die nächsten ein bis zwei Jahre gesichert.

Aber vermutlich kann man so ein grosses Projekt nicht alleine durchziehen...

[p80286]

Hallo Leute,

ich habe mich auch schon des öfteren mit so alten Hunden herumschlagen dürfen, meine Empfehlung:
Nur die "echte Geschäftslogik" also Datenmanipulationen übernehmen. Aber Vorsicht, Real und Integer und ... ist nicht mehr das gleiche wie damals.

Den Rest, die Oberfläche und die "KlickLogik" ganz neu schreiben.

Wahrscheinlich bleibt die darunter liegende Datenbank die gleiche, da bietet es sich an die Zugriffsroutinen gleich in eine seperate Unit auszulagern, da ist der DB-Wechsel demnächst nicht mehr so aufwendig.

Ich wette, für den alten Hund gibt es keine vernünftige Dokumentation. Also zuerst diese erstellen und dann ist das Schreiben eines neuen Programms eine Kleinigkeit (würde jedenfalls mein Chef behaupten).

Gruß
K-H

[Der.Kaktus]

Hallo,

also ich hab, vor 10Jahren und evtl. auch Stueckchen laenger, viele "brauchbare" damals von mir entwickelte Programme von Turbo7 ueber TPW1.. nach Delphi uebertragen..ging eigentlich Problemlos. Nur erstmal nen Rumpf(Hauptprogramm) basteln..dann Stueck fuer Stueck die alten Units..einbinden und nur die "uses" Anweisung(dem neuen anpassen)..einfach "f9"..und laufen lassen..an Fehlerstellen korrigieren. Die "Feinheiten"..wie Klassen etc. kann man spaeter machen..erstmal nen Grundgeruest. Meine Meinung und war erfolgreich in kurzer Zeit(damals).

[RavenIV]

Zitat:

Zitat von Der.Kaktus

Hallo,

also ich hab, vor 10Jahren und evtl. auch Stueckchen laenger, viele "brauchbare" damals von mir entwickelte Programme von Turbo7 ueber TPW1.. nach Delphi uebertragen..ging eigentlich Problemlos. Nur erstmal nen Rumpf(Hauptprogramm) basteln..dann Stueck fuer Stueck die alten Units..einbinden und nur die "uses" Anweisung(dem neuen anpassen)..einfach "f9"..und laufen lassen..an Fehlerstellen korrigieren. Die "Feinheiten"..wie Klassen etc. kann man spaeter machen..erstmal nen Grundgeruest. Meine Meinung und war erfolgreich in kurzer Zeit(damals).

Alles Murks. :-(
Wenn ich schon migrieren muss, dann mach ich das richtig.
Siehe eines meiner Posting weiter oben...

[HHick123]

Zitat:

Davon kann man bestimt 1/3 vergessen, weil es toter Code ist

Ja, ich glaub' auch. Eine Gruppe von Units hab' ich gerade gefunden, die einander total ähnlich sind. Da sind glaub' ich viele Daten "hartcodiert" hineingetippt worden...

Also vielleicht alles halb' so schlimm...

Zitat:

Zitat von RavenIV

Alles Murks.
Wenn ich schon migrieren muss, dann mach ich das richtig

Ich stimme Dir ja eh' vollkommen zu. Falls ich das Projekt übernehmen kann, werd' ich versuchen, einem "Neuentwurf" so nah wie möglich zu kommen, um die Zukunftsicherheit zu wahren.

Sich mal kurz durch's Programm zu klicken, und es in ein paar Tagen neuzuproggen ist leider auch nicht so einfach, weil es besteht aus *ziemlich vielen* Dialogen, wobei eigene Schulungen im Umgang mit dem Programmerl angeboten werden.

Ich hoffe immer noch auf einen "sanften Weg":
Momentan hab' ich mal die alten Units hinausgeworfen und eine Dummy.pas eingefügt,
wobei ich versuche herauszufinden, was die restlichen Units eigentlich alles brauchen...
Aber ob' ich diesen Weg durchstehe, weiss ich noch nicht...

[Der.Kaktus]

Zitat:

Zitat von RavenIV

Zitat:

Zitat von Der.Kaktus

Hallo,

also ich hab, vor 10Jahren und evtl. auch Stueckchen laenger, viele "brauchbare" damals von mir entwickelte Programme von Turbo7 ueber TPW1.. nach Delphi uebertragen..ging eigentlich Problemlos. Nur erstmal nen Rumpf(Hauptprogramm) basteln..dann Stueck fuer Stueck die alten Units..einbinden und nur die "uses" Anweisung(dem neuen anpassen)..einfach "f9"..und laufen lassen..an Fehlerstellen korrigieren. Die "Feinheiten"..wie Klassen etc. kann man spaeter machen..erstmal nen Grundgeruest. Meine Meinung und war erfolgreich in kurzer Zeit(damals).

Alles Murks. :-(
Wenn ich schon migrieren muss, dann mach ich das richtig.
Siehe eines meiner Posting weiter oben...

[Edit]
OK, machs als Off...
(OT]
Hast Du schon gelebt als es Turbo-Pascal gab? *fg* :spin:[/OT]
[/Edit]

[DeddyH]

Wenn man sich allein die Unterschiede zwischen Delphi 1 (16 Bit) und Delphi 2 ansieht, kommt man zu dem Schluss, dass sich vermutlich das Allerwenigste vernünftig übernehmen lassen wird. Von daher würde ich auch eine Neuentwicklung für das Gescheiteste halten, wirklich ausgefuchste Algos kann man ja kopieren und das Beste hoffen *g*.

[HHick123]

Ich bin in die Windows-Programmierung erst mit Delphi 3 eingestiegen, vorher hab' ich mit den Turbo Pascal und Borland Pascal für DOS programmiert.

[Der.Kaktus]

Zitat:

Zitat von HHick123

Ich bin in die Windows-Programmierung erst mit Delphi 3 eingestiegen, vorher hab' ich mit den Turbo Pascal und Borland Pascal für DOS programmiert.

Dann sollte es doch kein Problem sein ;-)

[Edit] Fang doch einfach mal mit dem Rumpf an...wenn de Problem bekommst..einfach mal posten ;-) [/Edit]

[Hansa]

Ich kann aus Erfahrung folgendes sagen : bei sowas muss das GUI fast völlig neu entwickelt werden, sonst wird das nichts. Wenn man alles über den Haufen schmeißt, dann sind dies ca. 95 % der Arbeit. Ein paar Funktionen/Prozeduren kann man wohl übernehmen. Wird die Ablauflogik einigermaßen beibehalten, dann kann man aus dem vom User-gewöhnten Programm das auch abkupfern. Aber nur die Logik ! Programmieren muss man das schon selber. Gut, sagen wir 85 % wird neu gemacht werden müssen. Dann wieder die DB, Konvertierungsprogramme etc. Der Wert steigt auf über 100 % wegen neu zu machender Randprogramme usw. ! Wird die DB gewechselt, dann besteht auch kaum eine Chance da billiger wegzukommen.

[rotfc]

Zitat:

Zitat von Hansa

Ich kann aus Erfahrung folgendes sagen : bei sowas muss das GUI fast völlig neu entwickelt werden, sonst wird das nichts. Wenn man alles über den Haufen schmeißt, dann sind dies ca. 95 % der Arbeit. Ein paar Funktionen/Prozeduren kann man wohl übernehmen. Wird die Ablauflogik einigermaßen beibehalten, dann kann man aus dem vom User-gewöhnten Programm das auch abkupfern. Aber nur die Logik ! Programmieren muss man das schon selber. Gut, sagen wir 85 % wird neu gemacht werden müssen. Dann wieder die DB, Konvertierungsprogramme etc. Der Wert steigt auf über 100 % wegen neu zu machender Randprogramme usw. ! Wird die DB gewechselt, dann besteht auch kaum eine Chance da billiger wegzukommen.

:thumb:

[sakura]

@rotfc: Bitte schreibe in Zukunft etwas reichhaltigere Kommentare. Solche Kommentare wie der vorhergehende gelten einfach als Spam und sind nicht erwünscht.

Danke,
...:cat:...

[HHick123]

Zitat:

bei sowas muss das GUI fast völlig neu entwickelt werden

Ja, ich werd auf jeden Fall vorschlagen, von der OWL auf die VCL umzusteigen.
Es handelt sich zirka um 165 (meist modale) MDI-Fenster (im Code nachgeschaut) mit jeweils ca. 20-30 Steuerelementen (geschätzt).

Leider kommen so Dinge häufig vor, wie, dass bei einer Eingabe eine Datenbank-Abfrage/Berechnung ausgelöst wird, und der Focus dann gleich woanders hinspringt und dort gleich irgendetwas selektiert wird, etc...

Irgendwie muss ich mir einen planvollen Weg überlegen, die Fenster und Ereignisbhandlungsroutinen auf die VCL zu portieren.

Super wär's natürlich, wenn man das schrittweise machen könnte (ein Fenster und noch ein Fenster), Dazu müsste ich aber irgendeine Möglichkeit finden, doch die Object-Windows-Library-Dateien (zumindest so weit wie notwendig) nachzubilden.

Was ist eigentlich mit Free-Pascal? Kann das mit der Object Windows Library und der VCL etwas anfangen?

Noch eine Frage: Könnt' ihr mit der Klasse TStrCollection (ursprünglich aus objects.pas)etwas anfangen. Die wird exzessiv benutzt. Meiner Meinung nach ist das so eine Art TStringList für pchars... Ich hätte geplant, sie vorläufig nachprogrammieren und dann Schritt für Schritt durch TStringList zu ersetzen.... Gibt's da schon etwas fertiges?

Danke für eure Geduld mit mir,
Helmut

[HHick123]

Hallo Leute ich bin gerade einen entscheidenden Schritt weiter gekommen!! :-D :-D

Mittels des "Borland Resource Workshops" ist es mir gelungen, die vielen RES-Dateien (in denen die Forms drinnen sind) in RC-Dateien, die ja anscheinend normale Textdateien sind, umzuwandeln, was ca. so aussieht:

RATTRIBUTE DIALOG 35, 24, 332, 230
STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU
CAPTION "Rohr - Attribute"
FONT 8, "Helv"
{
CONTROL "COMBOBOX", 101, "COMBOBOX", CBS_DROPDOWNLIST | CBS_SORT | WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_TABSTOP, 15, 21, 83, 58
EDITTEXT 102, 103, 21, 32, 14, ES_RIGHT | ES_MULTILINE | WS_BORDER | WS_TABSTOP
CONTROL "COMBOBOX", 103, "COMBOBOX", CBS_DROPDOWNLIST | CBS_SORT | WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_TABSTOP, 173, 20, 147, 119
CONTROL "COMBOBOX", 104, "COMBOBOX", CBS_DROPDOWNLIST | CBS_SORT | WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_TABSTOP, 12, 70, 143, 110
CONTROL "COMBOBOX", 105, "COMBOBOX", CBS_DROPDOWNLIST | CBS_SORT | WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_TABSTOP, 182, 70, 47, 67
CONTROL "COMBOBOX", 106, "COMBOBOX", CBS_DROPDOWNLIST | CBS_SORT | WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_TABSTOP, 257, 71, 47, 69
CONTROL "COMBOBOX", 107, "COMBOBOX", CBS_DROPDOWNLIST | CBS_SORT | WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_TABSTOP, 13, 111, 56, 59
CONTROL "COMBOBOX", 108, "COMBOBOX", CBS_DROPDOWNLIST | CBS_SORT | WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_TABSTOP, 94, 111, 47, 59
CONTROL "COMBOBOX", 109, "COMBOBOX", CBS_DROPDOWNLIST | CBS_SORT | WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_TABSTOP, 176, 111, 108, 79
RADIOBUTTON "warmgefertigt", 110, 14, 151, 67, 10, BS_AUTORADIOBUTTON | WS_GROUP | WS_TABSTOP
RADIOBUTTON "kaltgefertigt", 111, 88, 151, 65, 10, BS_AUTORADIOBUTTON | WS_TABSTOP
CONTROL "COMBOBOX", 112, "COMBOBOX", CBS_DROPDOWNLIST | CBS_SORT | WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_GROUP | WS_TABSTOP, 176, 149, 79, 50
CHECKBOX "kalibriert", 113, 12, 186, 52, 12, BS_AUTOCHECKBOX | WS_TABSTOP
CHECKBOX "profiliert", 114, 96, 185, 52, 12, BS_AUTOCHECKBOX | WS_TABSTOP
CHECKBOX "mit Endkappen", 115, 178, 186, 73, 12, BS_AUTOCHECKBOX | WS_TABSTOP
PUSHBUTTON "OK", 1, 108, 210, 55, 15, NOT WS_TABSTOP
PUSHBUTTON "Abbrechen", 2, 167, 210, 55, 15, NOT WS_TABSTOP
GROUPBOX "Bestellung in", -1, 4, 4, 158, 41, BS_GROUPBOX | WS_GROUP
GROUPBOX "Herstellungsverfahren", -1, 4, 134, 159, 34, BS_GROUPBOX
GROUPBOX "Kalibrierung", -1, 4, 170, 79, 35, BS_GROUPBOX
GROUPBOX "Lieferzustand", -1, 166, 4, 161, 41, BS_GROUPBOX
GROUPBOX "Profilierung", -1, 86, 170, 77, 35, BS_GROUPBOX
GROUPBOX "Prüfklasse/kategorie", -1, 4, 96, 82, 35, BS_GROUPBOX
GROUPBOX "Gütegrad", -1, 89, 96, 73, 35, BS_GROUPBOX
LTEXT "[m]", -1, 138, 23, 16, 12, NOT WS_GROUP
GROUPBOX "Durchmesser", -1, 173, 57, 71, 31, BS_GROUPBOX
GROUPBOX "Ausführungsart und Aussehen der Oberfläche", -1, 4, 46, 158, 48, BS_GROUPBOX
GROUPBOX "Wanddicke", -1, 248, 57, 73, 31, BS_GROUPBOX
GROUPBOX "ISO-Toleranzklasse", -1, 166, 46, 161, 48, BS_GROUPBOX
GROUPBOX "Form der Schweißfuge nach DIN 2559", -1, 167, 96, 161, 35, BS_GROUPBOX
GROUPBOX "Lieferart (Gewinderohre)", -1, 167, 134, 161, 34, BS_GROUPBOX
GROUPBOX "Endkappen", -1, 167, 170, 161, 35, BS_GROUPBOX
}

Interessanterweise gehen die RC-Dateien mit Delphi2006 auf, was im mir Hoffnungen weckt...

Kann man die RC-Dateien eigentlich automatisch in DFM-Dateien umwandeln? Gibt' es da vielleicht irgendein Tool?

Andernfalls würde ich mir eventuell - wenn es wirklich sein muss -etwas schreiben, um die vielen RC-Dateien zu parsen und in dfm-Dateien umzusetzen...

Viele Grüße,
Helmut

[HHick123]

Zitat:

Kann man die RC-Dateien eigentlich automatisch in DFM-Dateien umwandeln? Gibt' es da vielleicht irgendein Tool?

Also in der anderen Richtung "DFM->RC" hab' ich ein Tool gefunden, aber egal, das ist nicht viel Aufwand, ich schreib' mir halt eines...

P.S.: Momentan schaut es eh so aus, als würd' ich den Auftrag gar nicht bekommen... Schade, ich hätte das alte Programm gerne revitalisiert...

[HHick123]

Hallo Leute, bin in der Sache einen Schritt weitergekommen...
Keine Sorge, es hat keine 3 Monate gedauert... Hab' entweilen an einem anderen Projekt gearbeitet ;-)

- Also die RES-Dateien hab' ich mit dem "Borland Resource Workshop" in RC-Dateien umgewandelt.
- Die RC-Dateien hab' ich mit dem "Borland C++ Builder 3" in DFM-Dateien umgewandelt.
- Mit einem Tool namens dfm2pas hab' ich die zugehörigen TForm-Klassenableitungen mit den entsprechenden Steuerelementen, die auf den Forms drauf sind erzeugt

Also die Geometriedaten des GUI sind nun schon mal portiert... :-D

Viele Grüße