Inoffizielles deutsches Xbase-Forum

Hallo,

Sind die Runtimekomponenten von 2.0 abwärtskompatibel zu einem mit 1.9 kompilierten Programm kompatibel? Oder anders ausgedrückt, läuft ein 1.9 Programm mit den Runtimes von 2.0?

Ich wünsche allen einen guten Rutsch und ein erfolgreiches Jahr 2019!

Gruß Wolfgang

Nein,
darauf sollte man sich nie verlassen!

Viele Grüße,
Martin

Nein. Manche Funktion wurde in eine andere dll verschoben. Und auch auf eine andere Codebasis gestellt. Und soweit ich weiß wird auch eine andere Compilerversion benutzt.

Jan

Hm, dachte ich mir schon. Ich hatte mich auch vertan. Ich war der Annahme, daß das Programm beim Kunden noch eins mit 1.9 war. Ist aber nicht so. Es war schon 2.0, allerdings mit den Runtimes von 2014.

Danke nochmal.
Bis nächtes Jahr

Wolfgang

Hallo,


das funktioniert nicht, weil der Compiler in der 1.9 eine Funktion __This_program_requires__190__ (oder so ähnlich) einbindet, die nur mit einer entsprechenden 1.90er Laufzeit-DLL verfürbar ist. Analog dazu auch in Programmen, die mit 2.0 erstellt wurden.

Hi,

eigentlich sollte man *IMMER* die zum verwendeten Compiler passenen Runtimes verwenden!! Also pingelig darauf achten dass die Versionsnummer des Compilers und der Runtime DLL's die selbe ist und zueinander passen. Also alle Tools die selbe Versionsnummer haben.

Alles andere ist meiner Meinung nach "Russisches" Roulete oder mindestens als "grob fahrlässig" einzustufen!
Wer käme dann schon auf die Idee in Windos 10 DLL's mit gleichnamigen aus XP zu ersetzten???

In früheren Jahren hat "man" gelernt dass alle Teile eines Tools zusammen passen müssen. Dies war eine der elementaren Grundlagen.

Gelten diese Grundlagen heute nicht mehr????? Oder gilt heute nur noch Chaos oder "Jugend forscht" ??

ein 1.9 Programm mit den Runtimes von 2.0?

Kann ja wohl höchstens als Scherz in einer Partynacht gemeint sein?!!???? Oder ......


Gruss Carlo

Carlo,
ist ja schon gut....

Ja, so hab ichs auch mal gelernt. Aber hätte ja sein können, daß das Zeug abwärtskompatibel ist. Sollte auch kein Witz in einer Partynacht sein!
Trotzdem Danke für die deutliche Antwort.

Gruß Wolfgang

Man muss doch nicht gleich das Schlachtermesser ziehen, wenn jemand diese Frage stellt, die so unberechtigt dann auch wieder nicht ist, denn Xbase++-Applikationen basieren zu einem Großteil darauf, dass Funktionsaufrufe zur Laufzeit aus den Bibliotheken aufgelöst werden. Dazu steht mit dem Makroexpander ein Tool zur Verfügung, das es erlaubt, Code auch zur Laufzeit zu generieren und ausführen zu lassen, wodurch es sich bei Xbase++ quasi um einen Interpiler handelt - warum sollte das Zeug dann nicht auch in dieser Hinsicht abwärtskompatibel sein?

Die Antwort ist (natürlich): Weil der Code ein anderer ist. Weil sich viele Parameter geändert haben, Funktionen, Methoden, Klassen u.v.am. hinzugekommen sind, weggefallen sind, geändert wurden. Weil mit der 2.0 - jedenfalls, wenn man SPs Ausführungen zur Nomenklatur der Versionsnummern glaubt - sogar die Codebasis gewechselt hat. Außerdem sind die Laufzeit-DLLs keine herkömmlichen, sondern direkt gelinkte DLLs. Das ist der entscheidende Unterschied. Mit den Versionswechseln scheitert deshalb bereits die Adressierung.

Und es funktioniert ja auch überhaupt nicht. Wenn man versucht, ein Mischkonstrukt zu starten, bekommt man Fehlermeldungen wie "This DLL requires Version 1.9xxx" und ähnliche. Es ist also auch nicht mit einem Risiko für die Kunden verbunden, Carlo. Sondern nur etwas, das überhaupt nicht läuft.

Hallo Tom

vielleicht war die Antwort ja wirklich ein wenig Spitzzüngig. Das (Schlachtermesser) war nicht gewollt.

Ich habe die letzten Wochen auch über die Festtage viel Zeit aufgewendet um genau solche Probleme zu beheben. Es betriftt zwar nicht xbase direkt. Aber es waren Problem die durch (neue) unterschiedliche DLLs verursacht wurden. Bezw. Updates von dessen Herstellen. Die zum einen in den Originalordnern liegen müssen und dann einfach nicht mehr ganz so gleich funktionieren.....

Bei Xbase bekommst du die erwähnte Fehlermeldung hauptsächlich bei Start der ersten DLL, einige der anderen lassen sich dann schon verwechseln mit mehrer oder weniger krassen Fehlern.

Eigentlich sollte man *IMMER* die zum verwendeten Compiler passenen Runtimes verwenden! Dies schliesst natürlich auch selbst mit Xbase erstellt DLL's mit ein gerade hier liegt ja ein grossen Problemfeld wenn man mit den eigenen DLL's ein "durcheinander" bekommt.

Deshalb finde ich das noch immer eine der wichtigsten Reglen seit es DLL's gibt ......
Nur wenige Hersteller haben Versionsnummern im Dateinamen der DLL die solche Probleme dann grundsätzlich auschliessen....

Gruss Carlo

Hallo, Carlo.

Bei Xbase++ sind die Versionsnummern in die DLLs eingebettet, bei meinen DLLs ist das übrigens auch so. Aber Du kannst unterschiedliche DLLs aus einem Major-Release (also z.B. aus der Xbase++ 2.0) mischen, also einzelne DLLs als Hotfix ausliefern. Das war auch seitens Alaska der Standard mit der Einführung der Hotfix-Rollups in der 1.9.

Hallo Tom

wenn das so ist hat Alaska damit ja ein gutes Konzept!

Ich habe meine Erfahrungen mit mischen von Dateien eines Produkts gemacht,
überwiegend mit "unglücklichem" Ausgang.

Selbst baue nur noch Installer mit "Komplettpaketen".

Gruss Carlo

Tom hat geschrieben: ↑Mi, 02. Jan 2019 15:48 Aber Du kannst unterschiedliche DLLs aus einem Major-Release (also z.B. aus der Xbase++ 2.0) mischen, also einzelne DLLs als Hotfix ausliefern. Das war auch seitens Alaska der Standard mit der Einführung der Hotfix-Rollups in der 1.9.

das gilt wohl für v1.9x weil sich da nichts geändert hat aber für die v2.x gilt es seit der 519 nicht mehr.

So hat meine Frage doch noch Sinn gehabt

@Carlo, ich bin Dir nicht böse