Clipper S87 Migration nach Windows

[waldforest]

Hallo,
irgendwann erreicht es jeden.
Ich habe mehrere Anwendungen in der alten Clipper S87 Welt geschrieben. Aber langsam werden mir die Umwege zu umständlich, die erforderlich sind, die Anwendungen unter Windows am Leben zu halten.
(Interfaces zu Word, Outlook, Windows Druckern ...).
Ich überlege wirklich den schritt zu wagen und meine Anwendungen zu migrieren.
Sicherlich ein Thema, welches einige in der Vergangenheit bereits gemacht haben. Gerne möchte ich auf diese Erfahrungen zurück greifen.

Welches Programm zur Migration wäre da wohl am besten geeignet.
Ziel sollte es sein, einen Großteil des Codes weiter nutzen zu können.

Viele greifen auf mind. Clipper 5.0 als Basis zurück (xharbour), Alaska xbase könnte vielleicht eine Lösung sein.

Würde mich über einige Tipps freuen, ohne gigantischen Aufwand die alte, mir immer noch am herzenliegende Clipper Welt S87, auf eine brauchbare Lösung zu migrieren.

Die letzte, derzeit für mich nicht tragbare Alternative wäre, alles komplett in einer neuen Sprache neu zu schreiben, was aber sehr zeitintensiv wäre.

mft

Ich habe bereits

[Jan]

Hallo Waldwald ,

es gibt hauptsächlich 3 Ansatzpunkte:
1) Alles als CRT compilieren. Dann bleibst Du zeichenorientiert, sieht aus wie unter Clipper, funktioniert auch so.
2) Alles in GUI übertragen. Dann ist das wirklich Windows. Aber alle "optischen" Elemente müssen natürlich umgeschrieben werden. Und es wird sich zwangsläufig ergeben, auhc noch eine menge anderer Sachen auch. Weil alles objektorientiert wird.
3) Du besorgst Dir ein Zusatztool. eXpress++ z. B. Da kannst Du weiter mit @-Angaben arbeiten, und hast trotzdem Windows

Streng genommen gibt es unter Xbase++ noch einen Zwischenschritt, CRT mit GUI-Elementen. Für eine langsame Migration.

Was Du wählst ist natürlich Geschmacksache, hängt davon ab, wieviel Du finanziell bereit bist zu inverstieren, und was dabei herauskommen soll. ich selber habe den Sprung direkt von Clipper nach GUI gewagt. Ohne Zusatztools. Was ein harter Kampf war und ist. Manfred hat den Zwischenschritt geagt, erst CRT, dann GUI. Und viele hier benutzen eXpress++ oder TopDown. Was natürlich kostet, aber Arbeit spart.

Egal was Du wählst: Ich wünsch Dir viel Erfolg dabei. Der Unterstützung durch das Forum kannst Du Dir jedenfalls sicher sein

Jan

[Tom]

Ergänzend zu dem, was Jan geschrieben hat: Problematisch ist das alles nur, wenn man Zusatzbibliotheken benutzt hat, die es für Xbase++ oder xHarbour nicht (mehr) gibt. Ansonsten sind marginale Änderungen - wenn überhaupt - am Quellcode nötig, um ein 32-Bit-CRT-Compilat zu erzeugen. Jedenfalls mit Clipper-5-Applikationen. Sommer 87? Großer Gott, was war da anders?

Den Schritt nach GUI haben wir mit Roger Donnays eXpress++ ziemlich rasant gemacht. Wir benutzen das Tool immer noch. Es erzeugt echte und objektorientierte GUI-Dialoge auf Basis relativ geringfügiger Änderungen am Originalcode. Zudem enthält es tonnenweise nützlicher Zusatzfunktionalitäten. Und es kostet nur 199 Dollar, wenn ich das auf der DevCon richtig mitbekommen habe. Auf der Con gab es übrigens umfangreiche Tracks zum Thema Migration. Hast Du leider verpaßt.

http://www.donnay-software.com

[Manfred]

Hi,

ich muß mal jetzt hier einen beitun...

Im nachhinein betrachtet, war die Sache mit dem Zwittermodus rausgeschmissene Zeit. Gut, ich habe etliches gelernt. Aber wirklich empfehlen kann ich es nicht.

Wenn Du die Möglichkeit hast, mache direkt in GUI, oder nur in reinem Text. Hybridmodus kann ich nicht wirklich empfehlen. Ich habe auch ein paar mal vor die Wand rennen müssen um es zu kapieren....

Wenn Du in GUI machst, wirst Du erst richtig zu schätzen wissen, was so alles möglich ist.

Wie gesagt, meine Meinung hier, jetzt und heute.

[Jan]

Hallo Manfred,

genau der Meinung bin ich auch. Deswegen hatte ich das auch nicht als wirklich Option genannt. Meine eigene Meinung war damals, als ich zu Alaska umgestiegen bin: Ganz oder garnicht. Sprich, alles im Textmodus lassen, oder gleich richtig auf GUI umsteigen.

Und ich steh noch immer dazu.

Wobei wohl ein Großteil hier im Forum den Weg gewählt hat, den Tom bekräftigt hat. Also voll auf GUI umsteigen, und um den Aufwand gering zu halten und noch etlichen Zusatznutzen zu bekommen, ein Zusatz-Tool zur Hilfe nehmen.

Jan

[brandelh]

Hi,

wenn deine Anwender mit einer Clipper-Like Oberfläche zufrieden sind, geht die Migration in Xbase++ Textmodus recht schnell (außer du hast exotische Tools verwendet ...), allerdings sollte man LOCAL Variablen statt der PRIVATE verwenden, das ist aber kein muss.

Wenn du dann die Anwendung mit Xbase++ compilieren kannst und auf GUI umschaltest, dann wird deine Anwendung immer noch nach Clipper aussehen, aber du hast intern vollen Zugriff auf Windowsdrucker und Windowsdrucken (ich nehme dazu meine Druckerklasse). Kannst Reportgeneratoren verschiedenster Art einbinden oder per ActiveX z.B. MS Office.

2 Vorteile hat sicher xHarbour, ersten ist es (fast ?) kostenlos und da es C-Code erzeugt (soweit ich weiß) müsste es auch unter Linux native laufen.

Folgende Vorteile hat Xbase++:
Es ist zwar nicht kostenlos, aber ausgereift.
In diesem Forum hier sitzen viel alte Clipper Hasen, die jetzt Xbase++ nutzen, mit den verschiedensten Zwischenschritten, da kommt schon Erfahrung zusammen -> und alles in deutsch

Wenn du gut englisch kannst, ist die Alaska Xbase++ Newsgroup sicher auch sehr hilfreich.

[Rolf Ramacher]

Hi,

ich kann mich meinen Vorschreibern nur anschliessen. Ich bin dabei von
clipper auf Xbase zu migrieren. Unsere Anwendung Warenwirtschaftssystem+Kundenverwaltung+Kassenmodul läuft bei den Kunden noch auf Clipper.

Ich habe mir die Warenwirtschaft als erstes rausgesucht uuuaahhh
das sind ein paar brocken. Aber direkt auf GUI - zwischenschritt ist quatsch.

[brandelh]

Aber direkt auf GUI - zwischenschritt ist quatsch.

so hart würde ich das nicht formulieren

Quatsch ist auf jeden Fall das Mischen von bisherigem ClipperStyle Programm mit z.B. neuen Menü oder GUI Elementen, auch wenn das möglich ist. Denn es ist vertane Zeit, das Programm wird so nie wie ein GUI aussehen (eventuell bei Express) aber man braucht dennoch Zeit dafür.

Wenn du aber - wie ich oben geschrieben habe - z.B. nur für inhause entwickelst, oder dein Kunde mit der Optik zufrieden ist, kann man SEHR SCHNELL die Oberfläche lassen und auf Xbase++ migrieren und dennoch von den anderen Vorteilen profitieren. Nicht zuletzt ist das auch eine Kostenfrage

Ich habe noch 3 Programme im Einsatz, die ich so umgestellt habe.
Diese Anwender wollten ihre alte Oberfläche beibehalten und es musste sehr schnell gehen.

Neue Kunden kann man aber nur mit reiner GUI überzeugen, da hat Rolf natürlich völlig Recht.

[Tom]

Es hängt davon ab, wieviel Zeit man hat. Man kann durchaus etwas dabei lernen, wenn man im Hybridmodus ein paar Windows-Kontrollelemente einbaut und schaut, was die so tun und wie sie funktionieren. Aber das Ergebnis wird möglicherweise nicht vorzeigbar sein. Eine App komplett mit Bordmitteln nach GUI umzustellen, ist eine aufwendige Angelegenheit, die aber gleichzeitig die Chance bietet, die Software zu restrukturieren und sich von Altlasten zu befreien. Mit Migrationstools wie eXpress++ kommt man sehr schnell zu vorzeigbaren Ergebnissen, trennt sich aber möglicherweise nicht von scheußlichem "Legacy-Code". Wie gesagt, eine Frage der Zeit und des investierbaren Zeitaufwands. Das muß sich jeder selbst ausrechnen, was billiger ist: Ein halbes Jahr Arbeit oder ein Monat Arbeit und 199 Dollar Zusatzkosten.

[AUGE_OHR]

hi,

Sommer 87? Großer Gott, was war da anders?

Es gibt unter S87 keine LOCAL oder STATIC sondern nur PRIVATE
oder PUBLIC. Damit ist MDI nicht möglich.

Wenn wirklich jemand von S87 kommt ist die umsetzung nach GUI
kaum möglich und MDI oder Multi-Threading dann sowieso nicht.

Dies sind aber genau die Vorteile von Xbase++ den xHarbour kann z.b.
kein Multi-Threading und GUI ist erst mit Zusätzen möglich (und
umständlich)

Deshalb ist es bei kleineren Anwendungen (< 1000) evtl besser die
gleich komplett neu (in GUI) zu schreiben, aber bei grösseren (> 50 000)
Applikationen wird man wohl "Stück für Stück" an einen "Umbau" gehen.

gruss by OHR
Jimmy

[Manfred]

Hi Tom,

genau das ist es. Mir ist es vorhin nur nicht eingefallen. Man trennt sich dann nicht von evtl. altem Müll, der eigentlich schon längst hätte weg sein müssen.

Ich habe durch die "neue" Art etliches besser gemacht und vor allen Dingen sauberer. Jetzt bin ich froh, dass ich es getan habe, auch wenn ich etliches an Prügel dafür einstecken mußte, nicht sofort damit angefangen zu haben. (hier im Forum ) Aber wie war das noch mit der heißen Herdplatte und dem kleinen Kind?

[waldforest]

Hallo,
vielen Dank für die schnellen Erfahrungswerte.

Ich denke alle Empfehlungen haben, wie es immer im Leben ist, so ihre vor aber auch Nachteile.
Ein Punkt, der mir noch wichtig wäre, sollte ich die sanfte Migration wählen wäre,
kann die "alte" Anwendung parallel zur Neuen auf die Dateien zugreifen ?

Ich weiß, das hat so den geschmack von "Wasch mich, aber mach mich nicht nass", aber dies ist genau das Problem welches ich bei meinen kunden vorfinde und mich bisher davon abgehalten haben auf z.B. SQL-Datenbank um zu steigen. (Habe aktuell ein paar kleinere neue Awendungen in Delphi in Zusammenspiel mit Firebird geschrieben) aber an die großen Clipperanwendungen habe ich mich aus Fallbackbedingung noch nicht heran gewagt.

mfg

Denn die Fallbacklösung ist eine weiter Herausforderung.

[Jan]

Hallo Tom,

recht hast Du.

Bei mir war es so, daß ich viele Dinge aus dem Hintergrund, wo einfach nur zusammengesucht oder berechnet wird, 1:1 übernommen habe. Oder es zumindest versucht habe. Dabei aber gemerkt habe, daß maches davon einfach nur Schwachsinn im Sinne von zu kompliziert da immer wieder nachgebessert und erweitert war. Oder es mit einigen neuen Sachen in Xbase++ einfach besser und schneller zu machen ist. Wie oft habe ich unter Cliper die Tools eingesetzt! Jetzt benutze ich glaube ich gerade mal 2 Befehle daraus. Und das wars.

Und mit dem Umstieg ist es natürlich so, daß man abwägen muß. Ich hatte wie Manfred teilweise eine schlimme Zeit. Null Ahnung von Windows-Programmierung. Geringste Ahnung von Objektorientierung (was konnte man da schon unter Clipper lernen?) Und dann direkt auf GUI umgestiegen. Klar hätte eXpress++ da sicher geholfen. Aber der Unterschied zwischen uns beiden ist: Du hast Deine Kunden im Hintergrund, durch die Du Dein Geld und das Deiner Angestellten verdienen musst. Musst schnell gute Ergebnisse liefern. Und Manpower kostet richtig Geld. Die 199 € für eXpress++ hattest Du schneller wieder drin als man gucken kann. Ich dagegen habe Zeit. Naja, hatte ich, bis zu meinem aktuellen Projekt, wo Mitte März Stichtag ist. Aber damit hab ich ja nicht angefangen. Also Zeit war da. Geld dagegen nicht. Ich konnte es mir also durchaus leisten, den schweren und komplizierten Weg zu gehen.

Es kommt halt in der Tat absolut darauf an, was man wie schnell und wie aufwändig erreichen möchte/kann/muß.

Jan

[AUGE_OHR]

hi,

kann die "alte" Anwendung parallel zur Neuen auf die Dateien zugreifen ?

Ja. Es gibt unter Xbase++ die Konstante "__XPP__".

Code: Alles auswählen

#IFDEF __XPP__
     Do_my_Xbase++_Code()
#ELSE
     Do_my_Cl*pper_Code()
#ENDIF

Da deine Application ja S87 ist kannst du "nur" DbfNTX benutzen (default)

Der "umstieg" von Cl*pper auf Xbase++ ist "im Prinzip" ganz einfach :

Statt PROCEDURE START schreibst du PROCEDURE MAIN und schon
kannst du versuchen deinen S87 Code zu comlilieren/linken und laufen
zu lassen.

Das "Problem" sind die "Waitstate´s" in Cl*pper wie INKEY(nWert). Hier
sollte "nWert" <> 0 und "nWert" < 1.0 sein damit es "flüssig" läuft.

Natürlich gibt es dann noch jede Menge zu lernen, aber da werden dir
die Mitglieder des Forums sicherlich gerne helfen.

gruss by OHR
Jimmy

[Manfred]

Hi,

es wäre auch von Vorteil sich die "Broschüre" downzuloaden, ja verflixt, wie heißt sie nochmal? Die, in der beschrieben wird, wie der DBU von Clipper auf Xbase++ umgefröddelt wird. War das nicht Xbase++ in 3 Stunden oder so?

[brandelh]

Ein Punkt, der mir noch wichtig wäre, sollte ich die sanfte Migration wählen wäre, kann die "alte" Anwendung parallel zur Neuen auf die Dateien zugreifen ?

Wenn die 'alte' Version in Clipper S87 ist und die umgestellt in Xbase++ macht der gemeinsame Zugriff zwar nicht viel Sinn (du hast ja schon umgestellt ), aber sicher auch keine Probleme.

Man muss dann darauf achten, dass der LockOffset auf 1GByte steht und nicht wie später unter Clipper 5 möglich auf 2, aber das ist kein großes Thema.

Xbase++ ALT und Xbase++ GUI haben natürlich keine Probleme mit gemeinsamen Dateienzugriff.

Die GUI Lernkurve ist schon nicht zu verachten, da habe ich auch lange gebraucht zum Umdenken von 'Ich steuere jeden Tastendruck des Anwenders' hin zu 'ich muss auf alle Tasten vorbereitet sein und reagieren die er drücken kann ...' aber wie gesagt, es kommt auch auf die Kunden an was die wollen.

Wenn du Delphi erwähnst, so schöne IDEs haben wir nicht, unsere VX ist immer noch beta und der Painter gewöhnungsbedürftig. Aber dafür kann man arbeiten wie früher unter Clipper (ein ANSI Editor mit OEM Auswahl sollte es schon sein).

Hol dir doch einfach mal die Testversion von der Alaska Site, ließ im Handbuch die Grundlagen insbesondere für Clipper Programmierer und versuche dein Programm zu kompilieren.