Clipper S'87 Decompiler,brauche nur eine Routine [ERLEDIGT]

[wildwood]

Hallo Zusammen,

wir haben in unserem Familienbetrieb noch ein altes Programm der Firma DB-Soft in Benutzung. Dieses meldet seit Neuestem Fehler in einer bestimmten Routine (numeric overflow). Ich denke dass sich die Zaehler fuer Auftragsnummer oder Rechnungsnummer, die sich beide gerade ueber die 2^15 Grenze geschoben haben, der Grund sind . Um das zu verifizieren, muesste ich mir den Code ansehen. Da es eine kommerzielle Software ist, ist decompilieren natuerlich illegal. Andererseits gibt es die Firma schon lange nicht mehr und eine andere Chance habe ich wohl nicht (oder?). Ich will ja auch nicht das ganze Programm decompilieren, sondern nur die eine Routine ansehen. Die v5demo.exe kommt mit dem S'87 nicht klar. Kann mir jemand einen Link auf die S'87 demo von Valkyrie, oder sonst einen Tipp, geben?

Jede Hilfe dankbar annehmend,
Wildwood

[Martin Altmann]

Moin,
ich habe mal eben gegoogelt und folgendes gefunden:
http://fileshunt.com/rapidshare.php?fil ... +summer+87
Auf eigene Gefahr! Ich habe es nicht heruntergeladen.

Viele Grüße,
Martin

[wildwood]

Hallo Martin,

ja, das hatte ich natürlich als allererstes auch gemacht gehabt und mich schon gefreut. Bei den RARs handelt es sich leider nur um ein Antivirus-Programm und einen Film mit dem schönen Namen Valkyrie ... da komme ich so nicht weiter.

Aber Danke für die Mühe

[AUGE_OHR]

wir haben in unserem Familienbetrieb noch ein altes Programm der Firma DB-Soft in Benutzung.
...
Die v5demo.exe kommt mit dem S'87 nicht klar. Kann mir jemand einen Link auf die S'87 demo von Valkyrie, oder sonst einen Tipp, geben?

wieso meinst du das es ein S87 Programm ist ?
starte doch mal die Cl*pper EXE mit //INFO.

MyApp.EXE //INFO

ich "denke" das es eine v5.x Cli*pper Application ist und weil "kommerziell" vermutlich gegen das decompilieren "geschützt".

Du kannst mir ja mal das *.EXE zuschicken dann kann ich mir das mal ansehen und wenn gewünscht ein Angebot machen.
So eine (kleine) Cl*pper Application hat man in 30 Tagen "nach gebaut" ...

[Martin Altmann]

Hmmm,
schau mal hier http://www.grafxsoft.com/valkyrie.htm
Dort steht, dass die Originalversion für Sommer 87 mit dabei ist...
Unten auf der Seite findest Du einen link zu dem Valkyrie utility - mit diesem kannst (und musst) Du prüfen, ob Deine Anwendung mit Blinker im Dual Mode gelinkt ist. Wenn ja, kann Valkyrie eh' nichts machen...

Viele Grüße,
Martin

[Wolfgang Ciriack]

Ansonsten wird ich mir mal mit dem DBU die Datenbanken ansehen, bei welchem Feld es knallt.
Evtl. kann man ja das entsprechende Feld vergrößern.

[AUGE_OHR]

moin,

S87 Applicationen "könnten" auch das 2K Problem haben was sich nun 2010 auswirkt ...

[wildwood]

Hmmm,
schau mal hier http://www.grafxsoft.com/valkyrie.htm
Dort steht, dass die Originalversion für Sommer 87 mit dabei ist...
Unten auf der Seite findest Du einen link zu dem Valkyrie utility

Ja genau, dieses Utility ist auch bei der v5demo mit dabei. Daher weiss ich ja erst, dass es ein Summer 87 Kompilat ist, gelinkt mit Blinker 1.x. Valkyrie in der Original-Version unterstützt S87. Nur in der Demo-Version ist leider kein S87 Decompiler-Support enthalten. Deswegen dachte ich, dass es vielleicht eine "vs87demo.zip" geben könnte Man darf ja hoffen ...

Grüsse,
Dirk (aka wildwood)

[wildwood]

wieso meinst du das es ein S87 Programm ist ?
starte doch mal die Cl*pper EXE mit //INFO.
...
Du kannst mir ja mal das *.EXE zuschicken dann kann ich mir das mal ansehen und wenn gewünscht ein Angebot machen.
So eine (kleine) Cl*pper Application hat man in 30 Tagen "nach gebaut" ...

Der //INFO Parameter macht bei mir garnix, die Applikation startet ganz normal. VAU.EXE aus der Valkyrie-Demo identifiziert es als S87 mit Blinker 1.x.

Die EXE schicke ich Dir gerne. Eine Migration oder Nachbau ist wohl zuviel des Guten, da wir es nur noch 1 oder 2 Jahre brauchen werden. Wenn ich nur sicher sagen kann, welche Daten das Problem machen, kann ich es anders lösen. Daher: wenn Du an die Funktion "VM_42VRE" drankommst, wäre ich schon glücklich und zufrieden.

Merci und Grüsse,
Dirk

PS: exe kommt per mail

[Tom]

Mit DB-Soft hatte ich früher auch zu tun, es gab eine ganze Reihe von DB-Programmen (DB-Lohn, DB-Fibu usw. - an den Namen der ziemlich weit verbreiteten Warenwirtschaft erinnere ich mich leider nicht mehr, aber das Kürzel "VM" war bei denen sehr gängig), und keine davon war so schmächtig, dass man sie in 30 Tagen nachbauen könnte.

Bist Du sicher, dass es sich um einen echten "numeric overflow" handelt - und nicht etwa um ein simples "Länge des Datenbankfeldes wurde überschritten"? In diesem Fall wäre die Fehlerbeseitigung eher leicht.

@Jimmy: Ein Jahr-2000-Problem könnten solche Apps tatsächlich haben, aber ein 2010-Problem sollte bitte wie genau entstehen?

[Martin Altmann]

Moin Tom,

@Jimmy: Ein Jahr-2000-Problem könnten solche Apps tatsächlich haben, aber ein 2010-Problem sollte bitte wie genau entstehen?

noch nichts von dem EC-Chip-Skandal mitbekommen? Mit den fehlerhaft programmierten Routinen (aus Frankreich)?
War doch auch hier im Forum schon Thema.
Selbst Microsoft-Software und einige Firmware litten darunter...

Viele Grüße,
Martin

[Tom]

@Martin: Nein, ich Blödi habe natürlich nichts vom "Chipskandal" gehört. Nichts von den möglichen Ursachen könnte aber eine Clipper-App betreffen:

http://de.wikipedia.org/wiki/Jahr-2010-Problem

[Martin Altmann]

Huhu Tom,
ich persönlich glaube auch nicht, dass eine alte 16Bit Anwendung darunter krankt - aber wer weiss? Kann ja durchaus sein, dass eine lib diese Probleme hat?

Viele Grüße,
Martin

[brandelh]

in einer bestimmten Routine (numeric overflow). Ich denke dass sich die Zaehler fuer Auftragsnummer oder Rechnungsnummer, die sich beide gerade ueber die 2^15 Grenze geschoben haben,

2^15 = 32.768 ist nicht wirklich viel

oder meintest du, dass nun 15 Stellen voll sind ?

wie auch immer, der Feldname und die Routine solltest du aus der Fehlermeldung lesen können und
dann - wie von Tom beschrieben - einfach DBU nutzen und das Feld um 1 oder 2 Stellen länger machen.
Es könnte dann natürlich Anzeigeprobleme geben, aber ohne den richtigen Quellcode und den passenden Compiler und etwas Ahnung vom Programm kannst du sowieso nichts anderes versuchen als einfach das Feld zu verlängern.

[Manfred]

Hi Hubert,

ich meine ich hätte mir extra eine Errorsys gebastelt, weil das Feld nicht angegeben wird, sondern nur der Fehler nebst Routine.

[Tom]

@Manfred: Aber Feldlängenüberschreitungen wurden meiner Erinnerung nach auch unter Clipper87 nicht mit "numeric overflow", sondern mit "Länge des Datenbankfeldes überschritten" bemängelt. Ich kann mich aber irren. Man müsste einfach mal im Datenbankpfad nachsehen, welche Tabelle zuletzt vor dem Auftreten des Fehlers angefasst wurde. Schwierig wird es, wenn die Indexausdrücke ebenfalls limitiert sind oder den Wert transformieren (INDEX ON Str(AuftragsNr,9,0)). Da kann man noch so lange an den Feldern herumpopeln, die App wird anschließend nicht mehr ordnungsgemäß funktionieren. Aber auch das kann man herausfinden. Nach meiner Erinnerung gab es da auch irgendwo Voreinstellungen, die auf die nächsten zu vergebenden Nummern verwiesen (Kundennummer, Auftragsnummer usw.). Irgendwo dort müsste ein sehr hoher Wert zu finden sein - oder eine Null.

@Martin: Wenn ich mich recht erinnere, war die DB-Produktlinie (FIBU, LOHN, "AUF" für Warenwirtschaft) sehr puristisch und lief ohne Verwendung von Zusatzbibliotheken. Ich habe das Zeug eine Zeit lang (Anfang der 90er) geschult. Strukturell sehr übersichtlich.

[wildwood]

Mit DB-Soft hatte ich früher auch zu tun... bist Du sicher, dass es sich um einen echten "numeric overflow" handelt - und nicht etwa um ein simples "Länge des Datenbankfeldes wurde überschritten"?

es ist DB-Auf V4.5, die Warenwirtschaft. Ich sehe, Du bist voll im Thema Ich bin mir nach einigem rumprobieren ziemlich sicher, dass ein Indexausdruck (AUNR*1000+POS) den Ärger macht. Aber ich habe keine Möglichkeit, das zu prüfen. Die Feldlänge kann es nicht sein. Es passiert beim Verbuchen eines Auftrags, regelmässig ab einer bestimmten Auftragsnummer, was an derselbigen oder der Rechnungsnummer oder der RecNo liegen könnte. Der Fehlertext ist soweit eindeutig, nur dass er mir nicht hilft. Danach ist dann auch Schluss, sprich ich muss das Programm abschiessen.

Vielen Dank für die Hilfe und die Hinweise (gilt auch für alle anderen hier, war über´s Wochenende weg)! Weiss ich wirklich zu schätzen

Grüsse
Dirk

[Martin Altmann]

Moin Dirk,
Du schreibst:

Es passiert beim Verbuchen eines Auftrags, regelmässig ab einer bestimmten Auftragsnummer,...

wie lautet diese denn?

Viele Grüße,
Martin

[wildwood]

Moin Martin,

wenn ich das genau wüsste ... Die aktuelle Auftragsnummer ist 32377/0 (gespeichert wird 323770), die aktuelle Rechnungsnummer ist 32893. Das Phänomen tritt "seit Kurzem" auf. Also etwa im Bereich von je 10-200 Nummern rückwärts, schätze ich.

Grüsse,
Dirk

(gehe jetzt schlafen, bis morgen)

[Martin Altmann]

Hm, also 323.770.
Im Indexausdruck wird diese mit 1.000 multipliziert 323.770.000
Ist zwar zehnmal größer, als ein Integer (mit Vorzeichen) sein darf, aber ob das unter Clipper die Ursache sein kann? Keine Ahnung.

Viele Grüße,
Martin

[brandelh]

Hi,

Clipper kennt genausowenig Integer wie Xbase++ (offiziell) letzteres verwendet intern zwar
integers wenn keine Nachkommastellen vorliegen, aber Clipper kann mit allem umgehen was kürzer als 18 (oder sogar bis 20) Stellen und Ganzzahl ist (bei den Nachkommastellen wird dann gerundet )

Wenn ein Feld zu kurz wäre, dann dürfte das Problem nur auftreten wenn eine Stelle mehr benötigt würde:

999999 -> speichern in 6 Stellen
999999+1 -> nun kracht es, denn dafür braucht man 7 Stellen, oder auch
999999*-1 -> nun kracht es auch, denn dafür braucht man auch 7 Stellen (Vorzeichen).

Über die Multiplikation mit 1000 wird offensichtlich aus der Auftragsnummer eine Positionsnummer (-> max 1000 Positionen je Auftrag) ... intern mit 9 Stellen. Str(nWert,9) oder Transform(nWert,"999,999,999") dürften deshalb bei dieser Zahl keine Probleme bekommen ... aber das ist alles Kaffeesatzlesen

Du solltest ernsthaft eine Alternative zu dem Uralt Programm suchen. Eventuell kann man dort dann die alten Dateien einlesen.

[wildwood]

Ich würde wohl auch eine Ablösung suchen, aber mein Vater ist schon 71, und bis er sich an die neue App gewöhnt hat, hört er auf zu arbeiten. Lohnt sich nicht mehr. Mir wird schon was einfallen.

Merci nochmal an alle,
Dirk

[AUGE_OHR]

Ich würde wohl auch eine Ablösung suchen, aber mein Vater ist schon 71, und bis er sich an die neue App gewöhnt hat, hört er auf zu arbeiten. Lohnt sich nicht mehr. Mir wird schon was einfallen.

In diesem Forum sind viele Entwickler die dir das ganze in Xbase++ "nachbauen" könnten d.h. keine "Um Gewöhnung".

Cl*pper ist ja 16bit d.h. es läuft nicht "so" auf einem aktuellen 64bit System wie Win 7, aber Xbase++ würde es tun.
Cl*pper benutzt ESC Sequenzen zum Drucken, aber kaum ein "Windows" Drucker "versteht" das.
S87 "müsste" auch noch den Y2K BUG haben ... das EXE ist ja vom 18.12.1991

Wenn man den Source (mit "Copyright") "hätte" würde die Umstellung auf Hybrid in 1 Woche erledigt ... GUI dauert etwas länger

[Klaus49]

Hallo Wildwood,
das Problem muß nicht in der Zahl liegen.
Eine Picture-Anweisung die zu knapp dimensioniert ist, kann es auch sein.
Eine RechnungsNR+2000+MM+DD kann auch schon mal querschiessen.
Das alles ist wirklich ohne Quelltext, wie ein Lottotreffer.

Einzige Möglichkeit ist die DBF-Dateien in den Feldern zu durchforsten und
zu schauen, ob da irgendwie Müll durch Programmabsturz,Virus,... hineingekommen ist.
Kaputte Indexe sind ebenso möglich.

Aber wie gesagt.
Nachsehen ohne Sicherung geht nicht.
Und dann wäre es ziemlich glücklich wenn es gelöst wäre.

Grüße Klaus