Inoffizielles deutsches Xbase-Forum

Hallo,


basierend auf einer Empfehlung von F****++ (man kann inzwischen ja nicht mehr vorsichtig genug sein, da ich die Mail von damals nicht mehr habe, in der ich die Empfehlung erhielt) arbeite ich mit einer kleinen Batch-Datei, die beim Starten des Rechners ausgeführt wird. Sie erhält als Parameter die Version, so dass ich leicht zwischen verschiedenen Versionen hin- und herswitchen konnte, also z.B. "alaska 355"
Meine Verweise in den Umgebungsvariablen lauten dann z.B. w:\xppw32\lib;...

Ich will mich jetzt trotz allem mal mit der 2.0 versuchen und habe überlegt, wie ich das mit der Parallel-Installation hinbekomme. Das Interface, um die Umgebungsvariablen unter Windows 10 zu bearbeiten, ist inzwischen ja recht komfortabel geworden, wenn es auch richtig gut versteckt ist ...

Damit habe ich die Pfade der 2.0 Installation jeweils ans Ende geschoben (also INCLUDE, LIB, PATH - XPPRESSOURCE war aus irgendwelchen Gründen bei mir nicht gesetzt). Mit einem "subst /d w:" knipse ich die Umleitung aus, und die auf w:\ verweisenden Einträge laufen ins Leere, so dass ich auf die 2.0 Installation zugreife.

Wie habt Ihr das gelöst? Jeweils ein eigener Rechner für jede Version?

Hallo Georg,

da gibt es ganz frisch ein Video von Alaska zu. Schau Dir mal das Video von Andreas an. https://www.youtube.com/watch?v=JgXAWilI410

Jan

Hallo Georg

ich mache die Umschaltung für den Compiler auch per Batch-Datei.
Der Aufwand sich da was einfallen zu lassen war unnötig, habe nach wenigen Tagen die 1.9 nicht mehr verwendet.

Guten Morgen -


@Jan, danke - der Vortrag war aber sehr langatmig, und die dort vorgeschlagene Lösung ist dann prima, wenn man die Workbench einsetzt, was ich aber nicht mache und auch nicht plane. Und jedesmal den Installer aufrufen ... da ist meine Lösung doch ein wenig schneller.

@Roland - in der Anfangsphase der 2.0 habe ich ziemlich viele Probleme hier "mitgelesen", so dass ich erst einmal gewartet habe. Und ich habe in diesen Dingen auch immer noch Zeit, aber einen Versuch ist es mir schon wert. Und wenn's jetzt nicht klappt, vielleicht in einem Jahr wieder.

Hallo Georg

nimm doch eine virtuelle Maschine bezw. deren 2.

Gruss Carlo

Hallo Georg,
bleibe doch bei deiner Methode mit der Batch Datei.
Ich mache das genau so, habe einfach eine Kopie des Ordners C:\Program Files (x86)\Alaska Software\xpp20 unter
X:\Alaska angelegt. Somit habe ich im Pfad nur noch X:\Alaska\bin, ..lib, ..include zu stehen und kann mit 1.9 oder 2.0 arbeiten.
Einzig bei Updates für 2.0 muss ich dann wieder den Ordner X:\Alaska für die 2.0 aktualisieren.

Hallo Georg

hast Du denn vor längere Zeit mit beiden Versionen zu arbeiten?
Oder welche Gründe hättest Du, manche Programme weiterhin mit der 1.9 zu kompilieren?

Alle meine Programme laufen mit Version 2.0 prima.
Meine eigene Programmierfehler lassen natürlich auch nicht durch die 2.0 verhindern
Ebenso wird sich der eine oder andere Fehler in Xbase++ 2.0 (und später) nicht verhindern lassen, es wird ja auch ständig daran herumgeschraubt und weiterentwickelt (hoffe ich wenigstens).

Hallo -


@Wolfgang: danke, sehe ich genauso!

@Roland: schwere Frage. Ich musste mir erst einmal Gedanken machen, wie ich zum einen die 2.0 ausprobieren kann, zum anderen aber mit der 1.9 weiterarbeiten kann. Ich arbeite hin und wieder für andere Xbase-Entwickler, und muss mich dann an deren eingesetzte Version anpassen. Und für mich gibt es bis heute nichts, was einen Umstieg auf die 2.0 erforderlichen machen würde. Ausser vielleicht der Tatsache, dass es halt eben nur noch Fixes für die aktuelle Version gibt.

Hallo Georg

dann würde ich auch die von Wolfgang vorgeschlagene Methode vorziehen und eine virtuellen Maschine z.B. mit vmware zum Testen der 2.0 einrichten. Dann kommt auf jeden Fall in Deinem Hauptsystem nichts durcheinander.

Frage : wie sind die aktuellen Registry Einträge ?

in der CTP hatte ich es so für gelöst. wenn es jemanden interessiert kann ich es uploaden .

Hallo Wolfgang,

genau so habe ich das früher auch gemacht, als ich noch 1.9 und 2.0 parallel benutzt hatte. Wie Du schreibst etwas Aufwand bei Updates, aber es hat immer sauber funktioniert.

Jan

Ich mach das immer noch so, nur in letzter Zeit werden USER Umgebungsvariablen für LIB etc. gesetzt ... obwohl ich das eigentlich verboten hatte.
Die doppelten lösche ich raus und lass nur den für die Workbench (Path)
Die "normalen" stehen alle auf "H:\" und sind SYSTEM vars.