Inoffizielles deutsches Xbase-Forum

Ich bin kein Spieler also kenne ich mich da nicht aus.

nun sagte mir ein Bekannter (Spieler, EDV Techniker) das es einen 64 Bit Patch für ""WoW" oder "SimCity 4" gäbe die noch 32 Bit sind.

nun frage ich mich wie das funktioniert und was der 64 Bit Patch bei Spielen bedeutet
klar frage ich mich ob man die Technik auch auf 32 Bit Apps anwenden könnte ...

Hallo, Jimmy -


warum fragst Du das Deinen Freund nicht?

Aus meiner Sicht gibt es höchstens einen Patch, der es ermöglicht, ein 32bit Programm besser unter einem 64bit Windows laufen zu lassen. Aber ich bezweifle, dass es einen Patch gibt, der aus einem 32bit Programm ein 64bit Programm macht.

hi Georg,

georg hat geschrieben: ↑Mi, 24. Jul 2019 22:15 warum fragst Du das Deinen Freund nicht?

gefragt hab ich ihn schon aber nichts verstanden ... so viele "Fach" Ausdrücke für einen Nicht-"Spieler" wie mich.

ich habe nur verstanden das es bei Spielen wohl um den GDDR5 RAM der GFK > 4 GB geht.
bei 32 Bit Spielen / Treiber kann eine "moderne" GFK mit 8 GB wohl nur 4 GB "nutzen" um Texturen etc. zu laden.

nun sind Spiele wie "WoW" oder "SimCity 4" für meinen Bekannten "alte" Spiele mit denen er sich nicht (mehr) beschäftigt.
deshalb frage ich nach "Spielern" ob die davon was gehört haben nach mehr Infos.

das mit dem RAM auf der GFK ist wohl noch eine andere Sache.
wie man mir erklärte existieren 64 Bit Patches für 32 Bit Spiele schon lange.

---
unter DOS wurde im Bereich > 640 Kb bis 1 MB (A000-FFFF) genutzt für die Hardware Adressen.
in dem Bereich (E000-F000) konnte man auch "Fenster" zu EMS etc. aufmachen um Speicher > 1 MB anzusprechen.

mit Windows kam dann Extendet Memory was den Bereich nutzten und die Hardware Adressen verschoben hat auf > 2 GB
als dann 64 Bit aufkam hat man "lediglich" einen Schalter für das "Remap" eingeführt
wenn man einen aktuellen PC kauft ist es für 64 Bit ausgelegt d.h. ein 32 Bit OS zeigt nur 2 GB an

---
die 4 GB Patche sollen nun für ein "Remap" sorgen so das alle Hardware Adressen über 4 GB liegen und man damit die "vollen" 4 GB hätte.
das soll aber nicht nur für Spiele gelten sondern auch für 32 Bit Apps

die 4 GB Patche sind "Loader" mit welchen man das Spiel/App startet ... welche Spiel/Apps damit nur laufen muss man selbst raus finden.

hi,

Ich habe mir von meinem Bekannten einige "4 GB-Patch" besorgt und damit getestet.

ohne Patch wird die 2 GB als Grenze angezeigt mit Patch sind es 4 GB - X ASRock Deskmini 110 mit i5-6400T, 16 GB Windows 10 64/32 Bit

Ich habe das Mainboard mit H110 Chipsatz und Skylake CPU gewählt weil man auf den noch ein 32 Bit OS (Treiber) installieren kann.

dabei liegt die "maximale" Grenze im BIOS bei 3.5 GB und die kann ich mit dem Array Demo (scheinbar) nutzen ! (s.h. Logfile)
statt das er nach 20 Runden schlapp macht schafft der nun 35 Runden

ich habe bislang nur die beiden Demo EXE damit "ge-Patched" und sie laufen weiterhin unter 32 Bit OS
unter 64 Bit OS kommt dann der "Loader" ins Spiel ... mal sehen wie stabil das ist. Nachtrag : bei mir funktioniert es und auch Avira & Co meckern nicht.
trotzdem übernehme ich keine Garantie wenn bei der Nutzung Schäden auftreten

habe weitere Test gemacht und es sieht gut aus WENN man keine Xbase++ DLL benutzt.
sobald ich alles in ein EXE packe läuft der Patch wobei ich noch nicht die Memory Grenze testen konnte ... so viel Speicher brauche ich normal nicht.

für DBF wird es nichts bringen aber native mit SQL müsste es mehr bringen wenn man mehr als 2.000.000 Datensätze hat.
mit grossen Array (> 2 GB) scheint es zu funktionieren und damit ist auch Xbase++ schnell.

klar spreche ich über "extreme" Situationen wo der Patch "sinnvoll" ist ... besser wäre es natürlich wenn Xbase++ selbst 64 Bit wäre ...

Was hat denn eine Anzahl Datensätze mit dem Adressraum zu tun?

Xbase++ selbst 64 Bit wäre ...

Würde ja bei Dir eh nicht funktionieren da Du keine 2.x hast

Koverhage hat geschrieben: ↑Di, 30. Jul 2019 9:52

Xbase++ selbst 64 Bit wäre ...

Würde ja bei Dir eh nicht funktionieren da Du keine 2.x hast

ist die v2.x denn 64 Bit ...

wenn die nächste Xbase++ Version 64 Bit ist DANN wäre das ein Argument umzusteigen.
ich suche aber Lösungen für JETZT und da wären Array > 2 GB schon eine Hilfe.

---

man sollte solche Gamer Lösungen nicht unterschätzen. es geht nicht um einen "Hack" der tief in das OS eingreift.
es ist auch nicht die "alte" 4 GB Lösung (/PAE) für 32 Bit OS sondern für 32 Bit Apps unter 64 Bit OS.

kennt Ihr DOSbox entwickelt wurde das für Games
ich nutze vDOS unter 64 Bit was praktisch die CMD Box ersetzt (wo Powershell läuft) und ich auf 16 Bit Apps Zugriff hab.

---

mein Favorit unter den 4 GB Patchen "scheint" nur 1 Bit zu "verschieben".

Hallo, Jim.

Es wird tatsächlich nur eine Flag gesetzt. Die Frage ist aber, was mit dem Speichermanagement generell passiert. Ich würde davon abraten, das zu machen, außer in kritischen Einzelfällen, wo es wirklich hilft. Ansonsten siehe hier:

https://stackoverflow.com/questions/314 ... -real-life

Interessant wäre, was Alaska dazu sagt. Die können eigentlich beim Zusammenfahren des Compilers usw. selbst diese Flag setzen, dann gäbe es ein 64-Bit-Xbase++ - genau das wird auch der Schalter sein, von dem Steffen irgendwann mal gesprochen hat. Dann gäbe es aber eine 32- und eine 64-Bit-Version, was mehr Aufwand generieren würde. Um welches Problem zu lösen?

Tom,

Steffen hatte in einer der frankfurter Konferenzen mal klipp und klar gesagt: Wenn die eine 64-Bit-Version raus bringen, wird es nur noch die geben. Keine 32er mehr.

Warum das noch nicht gemacht wurde kann ich nicht sagen. Um sich nicht die Kunden abzugraben, die noch mit einem 32er Windows arbeiten? Bei Windows 10 dürfte ja vermutlich der Großteil aller neuen Lizenzen 64 Bit sein (wer nimmt heute noch freiwillig 32 Bit?). Aber alles was älter ist vermutlich eher 32, insbesondere beim immer noch sehr beliebten Windows 7.

Jan

Also diese FLAG mach noch keinen 64 BIT Compiler !
Es ermöglicht nur 4 GB Adressräume zu nutzen, statt der 2 GB - je Anwendung !
Eine normale 32 Bit Anwendung muss ja dem OS und anderen Anwendungen noch was über lassen, daher haben die das auf 2 GB begrenzt.

Ein 64 Bit Compiler muss 64 BIT LONG und WORD Integers zur Verfügung stellen, womit der tatsächliche Speicherbedarf ohne zusätzliche Leistung sofort verdoppelt wird.

Jan hat geschrieben: ↑Di, 30. Jul 2019 12:44 Wenn die eine 64-Bit-Version raus bringen, wird es nur noch die geben. Keine 32er mehr.

Wenn ich davon ausgehe dass dann keine 32Bit-Fremd-DLL's mehr verwendet werden können wäre dies ein "Unfall" der schwerer nicht sein könnte.
Weil viele DLL's gibt es nur als 32Bit Versionen. Was dann?

Hallo, Carlo.

Bei echten Fremd-DLLs ließe sich das wahrscheinlich im Wrapper (also allem, was z.B. per DLLFUNCTION genutzt wird) abbilden, aber bei fremden Xbase++-DLLs, die man ggf. via LIB statisch linkt, wär's echt ein Problem - das man aber bei unterschiedlichen Xbase++-Versionen auch hätte.

Gibt auch sone Tools, übrigens:
http://www.dllwrapper.com/

Hallo Jan,

Jan hat geschrieben: ↑Di, 30. Jul 2019 12:44 Steffen hatte in einer der frankfurter Konferenzen mal klipp und klar gesagt: Wenn die eine 64-Bit-Version raus bringen, wird es nur noch die geben. Keine 32er mehr.

Warum das noch nicht gemacht wurde kann ich nicht sagen. Um sich nicht die Kunden abzugraben, die noch mit einem 32er Windows arbeiten? Bei Windows 10 dürfte ja vermutlich der Großteil aller neuen Lizenzen 64 Bit sein (wer nimmt heute noch freiwillig 32 Bit?). Aber alles was älter ist vermutlich eher 32, insbesondere beim immer noch sehr beliebten Windows 7.

Jan

Der Grund für meine Aussage ist klar, es sind die Wartungskosten für einen 32Bit und einen 64Bit Compiler + Runtime. Das rechnet sich nicht, wir müßten die Preise erhöhen und würden wertvolle Resourcen binden. Ich habe aber in meinen Slides noch viel mehr gesagt:

a. Im Regelfall benötigt der 64Bit Prozess circa 1.5 - 2.2 mal mehr Hauptspeicherresourcen
b. Die Cache-Lines der normalen Desktop CPUs sind zu klein um Multithreading vernünftig zu unterstützten. Es kommt somit bei einem 64Bit Prozess verglichen mit einem 32bit Prozess zu einem Performance Verlust.
c. Gegenwärtig sind alle 64Bit Prozessoren unterhalb von E/XEON für 32Bit Code Ausführung optimiert.
d. Ein 64Bit Prozess kann nur mit 64Bit fremd Dlls, Add-Ons udgl. umgehen das gibt gleich das nächste Problem... mit Wrapper geht das nicht. Mann müßte eine IPC (Interprozesskommunikation) zu einem 32Bit Server Prozess aufbauen ist aber super komplex.

Es gilt nach wie vor, das beste ist ein 32Bit Prozess auf einem 64Bit Betriebssystem - beste Performance und optimale Resourcenverteilung.

ACHTUNG: Nicht das "large address aware" Flag setzen. Wenn Ihr das tut, startet die Xbase++ Runtime anders und konfiguriert sich auf 4GB und nutzt diesen Speicher dann auch. Das Problem ist jetzt, das nahezu alle Add-Ons (DllCall/DllFunction) oder CAPI Code oder ActiveX Controls gebrochen sind. Es gibt manchmal bereits beim hochfahren dieser angebundenen Fremd-DLLs einen Fatal-Error, manchmal auch einfach später wenn Funktionalität dieser Fremd-Dlls oder ActiveX Komponenten gerufen wird. Wir haben es mit unterschiedlichen Anwendungen die wir von Kunden hatten probiert und es dann wieder verworfen.

mfg
Steffen F. Pirsig
Alaska Software Inc.

Steffen,

das mit den doppelten Wartungskosten auf Eurer Seite ist klar. Daher ja die Aussage von Euch, die ich hier wiedergegeben hatte: 32 oder 64, aber nicht beides.

An Deinen Punkt a) erinnere ich mich noch gut, wobei das heutzutage nicht mehr so ganz wirklich ein Problem sein sollte bei den RAM-Preisen. Der Rest b) - d) ist mir so nicht mehr in Erinnerung - entweder nicht genug aufgepasst damals, oder die liebe Vergesslichkeit, oder damals von Dir nicht so umfangreich erläutert, oder wir reden über unterschiedliche Sessions (soweit ich mich erinnere war das von Dir eine Antwort auf eine Zwischenfrage, also ohne Folien).

Jan

Steffen schreibt es wohl nicht explizit. Aber:

Es gilt nach wie vor, das beste ist ein 32Bit Prozess auf einem 64Bit Betriebssystem - beste Performance und optimale Resourcenverteilung.

lese ich als: "Es bleibt 32-Bit" weil es ja das beste ist.
Damit ist die Sache dann wohl "geklährt". Danke.

Zur Klarstellung:

Korrekt ist: "Es bleibt 32Bit solange die 32Bit Vorteile überwiegen und dann gibt es nur noch die 64Bit Version, denn die 32bit Version geht in passive Maintenance"

Steffen F. Pirsig
Alaska Software Inc.

steffen.pirsig hat geschrieben: ↑Di, 30. Jul 2019 19:23 Zur Klarstellung:

Korrekt ist: "Es bleibt 32Bit solange die 32Bit Vorteile überwiegen und dann gibt es nur noch die 64Bit Version, denn die 32bit Version geht in passive Maintenance"

Steffen F. Pirsig
Alaska Software Inc.

Hallo Steffen

es wäre schön ein wenig Sicherheit für die nächste Zeit zu haben.
Könntest du bitte deine Aussage noch besser formulieren bezw. einen Zeitlichen Horizont nennen?

Es bleibt 32 Bit -> Wie lange wird dies mindestens noch so sein?

Was Ist "passive Maintanance"?

Guten Abend,


vielleicht sollte man mal ein paar Gedanken an eine mögliche 64bit Version von Xbase++ verwenden.

Ein 64bit Xbase++ bedeutet, dass man alle 3rd Party-Produkte, die mit eingelinkt werden, erneut erwerben muss. Ausnahmen sind Produkte, bei denen man selbst im Besitz des Quelltextes ist.

Aus meiner Sicht bedeutet ein solcher Umstieg seitens Alaska, dass alle Programmierer gezwungen wären, ihre 3rd Party-Produkte zumindest zu aktualisieren. Sind alle entsprechenden Anbieter noch tätig?

Für mich wäre das kein Problem, da mir der Quellcode soweit vorliegt, aber ich mache unter anderem intensiven Gebrauch von OT4XB, und wird Pablo davon dann auch eine 64bit Version zur Verfügung stellen?

Also: wenn eine 64bit Version von Xbase++ auf den Markt käme, und damit die 32bit Version in eine passive Maintenance rutscht (ich vermute mal, nur noch extrem wichtige Sicherheitslücken oder Funktionsdefizite aufgrund von Windows-Updates - meine Einschätzung), würden Deine (und damit meine ich alle hier) Anwendungen noch laufen unter Berücksichtigung der Gedanken, die ich hier in den Raum gestellt habe?

Hallo Georg

Aus meiner Sicht bedeutet ein solcher Umstieg seitens Alaska, dass alle Programmierer gezwungen wären, ihre 3rd Party-Produkte zumindest zu aktualisieren. Sind alle entsprechenden Anbieter noch tätig?

Gute Frage. Gezwungen würde ja noch gehen. Ich habe einige Module die gibt es nur als 32 Bit und es wird auch nie eine 64 Bit Fassung davon geben.
Also Nein, die App wüde nicht mehr laufen ....

schön das Steffen sich eingeklinkt hat und auf mögliche Probleme eingeht.

wie Steffen sagte ist der Einsatz des "large address aware" Flag möglich wenn die Software angepasst ist.

---

bei einer Xbase++ App mit DBF gab es kaum eine Situation das RAM knapp wurde.
wenn dann war es beim einlesen einer grossen CSV in ein Array wo man RAM intensive nutzte.

unter SQL "denke" ich nun an grössere (Roh) Datenmengen die man zum bearbeiten in ein Array lädt.
solche Arrays hab ich bei "Delaunay triangulation" verwendet und da war bei 1.5 GB Schluss auf meinem alten P4 (Sockel 478) Win 7 unter 64 Bit komme ich zwar bis 2 GB aber für solche Projecte wäre "mehr" RAM gut ... und pro Thread eine CPU ...

Hallo,

ramses hat geschrieben: ↑Di, 30. Jul 2019 19:48 es wäre schön ein wenig Sicherheit für die nächste Zeit zu haben.
Könntest du bitte deine Aussage noch besser formulieren bezw. einen Zeitlichen Horizont nennen?

Es bleibt 32 Bit -> Wie lange wird dies mindestens noch so sein?

Was Ist "passive Maintanance"?

das mit der Sicherheit verstehe ich gut, wir hätten hier im Lab auch gerne mal einen Plannungshorizont. Aber leider ist Intel in den letzen 5 Jahren 2 mal zurückgerudert - aktuell gibt es keine offiziellen Positionen mehr zur Thematik - will sagen solange nicht durch die Fertigungskosten auch die Desktop CPUs 512kb oder idealerweise 1MB L2 pro Kern haben wird das alles nichts.

So wie wir einen Entscheidungshorizont haben werden wir dies kommunizieren, von da an dann circa 2 Jahre bis wir 32Bit in die ""passive maintanance" schieben. Letzteres bedeuted es gibt keine Updates mehr, nur noch notwendige fixes falls bestehenden Anwendungen in der Produktion gefährdet sind.

Je nach Situation machen wir das für 2 weitere Jahre und gehen dann auf "de-supported". Wobei ich hier sagen muss das man mit Alaska Software hier immer reden kann. Wir haben in 2018 sogar einen private-fix-level für eine embedded OS/2 Version aus 1999 erstellt.

Mit besten Grüßen
Steffen F. Pirsig
Alaska Software Inc.

AUGE_OHR hat geschrieben: ↑Mi, 31. Jul 2019 2:40 schön das Steffen sich eingeklinkt hat und auf mögliche Probleme eingeht.

wie Steffen sagte ist der Einsatz des "large address aware" Flag möglich wenn die Software angepasst ist.

---

bei einer Xbase++ App mit DBF gab es kaum eine Situation das RAM knapp wurde.
wenn dann war es beim einlesen einer grossen CSV in ein Array wo man RAM intensive nutzte.

unter SQL "denke" ich nun an grössere (Roh) Datenmengen die man zum bearbeiten in ein Array lädt.
solche Arrays hab ich bei "Delaunay triangulation" verwendet und da war bei 1.5 GB Schluss auf meinem alten P4 (Sockel 478) Win 7
DTL_Ribs.jpg

unter 64 Bit komme ich zwar bis 2 GB aber für solche Projecte wäre "mehr" RAM gut ... und pro Thread eine CPU ...

Nur mal für die Akten, mittels Multithreading auf mehreren CPUs lässt sich eine "Delaunay triangulation" (DT) egal ob du via Point-Insertion (CAGL) oder Divide-and-Conquer(Triangle) vorgehst nicht wirklich beschleunigen. DT und Parallelisierung ist ein Klassiker allein schon wegen FEM (Hallo Herr Grözinger). In beiden Fällen (Triangle+CAGL) müßen zu viele Daten zwischen den Threads ge-shared werden was dann zu Warte und Strafzeiten führt. Deshalb gibt es für DT Optimierungen d.h. spezifische Algorithmen die zwar wesentlich komplexer als die Klassichen sind, die Berechnung aber auf viele CPUs als Prozess verteilen und deshalb skalierbar sind. Bei deinem Problem bringt dir ein größeres Array so ziemlich gar nichts. Ein fqDel zum Beispiel schlägt selbst die GPU/CUDA Implementierung um längen und wie du sicherlich weisst ist eine GPU mit dem GDDR auf höchste parallelität getrimmt.

Abgesehen davon, deine Aufgabenstellung (DT/FEM) gehört definitv nicht zur Kernkompetenz von Xbase++ als Sprache.

Mfg
Steffen F. Pirsig
Alaska Software Inc.

Referenzen::
- gute Referenzliste zum Problem https://www.minet.uni-jena.de/preprints ... 3und5.html
- aktuellste Arbeit https://www.semanticscholar.org/paper/L ... 45b28f89ff
- oder einfach ACM oder IEEE digital library Suche benutzen

steffen.pirsig hat geschrieben: ↑Mi, 31. Jul 2019 19:20 So wie wir einen Entscheidungshorizont haben werden wir dies kommunizieren, von da an dann circa 2 Jahre bis wir 32Bit in die ""passive maintanance" schieben. Letzteres bedeuted es gibt keine Updates mehr, nur noch notwendige fixes falls bestehenden Anwendungen in der Produktion gefährdet sind.
Je nach Situation machen wir das für 2 weitere Jahre und gehen dann auf "de-supported". Wobei ich hier sagen muss das man mit Alaska Software hier immer reden kann.

Hallo Steffen

Danke für deine Ausführungen.

Also im ungünstigsten Fall geht es ab heute mindestens noch 4-5 Jahre bis es keine Updates für die 32 Bit Version mehr gibt.
Damit bin ich beruhigt. Das lässt sich so bereits jetzt auch den Kunden kommunizieren das es so kommen könnte und eine
Strategie für die nicht als 64Bit vorhandenen Module ausarbeiten.
Desktop CPU's werden wohl im Umfeld der aktuell herschenden Cloud Strategien noch lange lange nicht die erwähnte Menge L2 Cache haben ..... für was auch die Aufgaben werden ja immer mehr von den Server ausgeführt.