Arbeitsspeicher

[Jan]

Moin,

wir haben ja alle die Obergrenze von 4 GB RAm, bzw. 2 GB, die wir mit unseren Xbase++-Programmen nutzen können. Weil das halt 32 Bit ist. Womit ich bislang nicht wirklich Probleme hatte.

Jetzt bin ich aber zufällig über einen Hinweis zu einem Wettbewerber-Programm gestoßen, das zwar auch 32 Bit ist, aber mehr RAM nutzen kann. Weil das eine Einstellung "Large Address Aware" nutzt. Weiß da jemand mehr drüber?

Jan

[Tom]

Hallo, Jan.

Nach meinem Verständnis geht es dabei nur um 1 GB, das man als 32-Bit-Anwendung unter einem 32-Bit-Windows (!) mehr bekommt, wenn diese Flag gesetzt ist. Dafür verringert man von den 4 adressierbaren GB den Betriebssystemanteil auf ein GB. Unter 64 Bit ist das unerheblich und unsere Anwendungen können die vollständigen 4 GB erreichen. Das ist ein über zehn Jahre altes Thema.

[Jan]

Hallo Tom,

ich hab das heute zum ersten Mal gesehen. Ich hatte mich damit auch nie vorher beschäftigt, weil es für mich halt bislang keinen Bedarf gab.

Nach dem, was ich gelesen habe, soll der Schalter für 32 Bit-Windwos egal sein. Aber bei 64 Bit-Windows soll man die Obergrenze auf 3 oder 4 GB setzen können. Was bei manchen Anwendungen wohl durchaus sinnvoll sein mag.

Ich verstehe aber Dein Posting nicht so ganz. Können Xbase++-Programme das schon von Natur aus? Oder wie muß ich Deine Ausage interpretieren?

Jan

[AUGE_OHR]

hi,

Unter 64 Bit ist das unerheblich und unsere Anwendungen können die vollständigen 4 GB erreichen.

glaube ich nicht das du mehr als 2 GB "Data" mit Xbase++ nutzen kannst

probiere mal das

Code: Alles auswählen

#IFDEF __XPP__
#ELSE
   REQUEST HB_GT_WIN_DEFAULT           // Console
#ENDIF
PROCEDURE MAIN
LOCAL i
LOCAL aString := {}
LOCAL bOldError := ERRORBLOCK( { | e | BREAK( e ) } )

   BEGIN SEQUENCE
   FOR i := 1 TO 400
      ? i
      AADD(aString, REPLICATE("A",1024*10000))
   NEXT
   END SEQUENCE
   ERRORBLOCK( bOldError )
WAIT
RETURN

@Jan
such mal nach "3 GB Patch".
mit einer Demo ging er damit über die 2 GB Grenze bei Array

wenn man dann "andere" Sachen macht "passieren" Dinge ...

---

/3GB oder /userva in der BOOT.INI und sorgte für 3/1 statt 2/2 Aufteilung ABER

die App muss mit /LARGEADDRESSAWARE flag compiliert werden.

Code: Alles auswählen

HBMK2 -ldflag="-pthread  -static-libgcc  -static-libstdc++  -static -lpthread -Wl,--large-address-aware " -mt -o"%~n1" %HMGPATH%\hmg32.hbc %gtdrivers% %debug% -q %1 %2 %3 %4 %5 %6 %7 %8 >hbmk.log 2>&1

es hat was mit dem "Anfang" des Speicherbereich zu tun was "on Top" startet
https://en.wikipedia.org/wiki/Virtual_address_space

und dann gibt es noch /PAE (seit PentiumPro) welches "Server 2003 Data Centre Edition" nutzt um 64 GB unter 32 Bit OS zu verwalten.

[AUGE_OHR]

hi,

hier mal erweiteter Code

Code: Alles auswählen

#IFDEF __XPP__
   #include "os.ch"
#ELSE
   REQUEST HB_GT_WIN_DEFAULT           // Console

   #define HB_MemoryLoad           1   /* approximate percentage of physical memory that is in use (0 indicates no memory use and 100 indicates full memory use) */
   #define HB_TotalPhys            2   /* amount of actual physical memory, in bytes */
   #define HB_AvailPhys            3   /* amount of physical memory currently available, in bytes */
   #define HB_TotalPageFile        4   /* current committed memory limit for the system or the current process, whichever is smaller, in bytes */
   #define HB_AvailPageFile        5   /* maximum amount of memory the current process can commit, in bytes */
   #define HB_TotalVirtual         6   /* size of the user-mode portion of the virtual address space of the calling process, in bytes */
   #define HB_AvailVirtual         7   /* amount of unreserved and uncommitted memory currently in the user-mode portion of the virtual address space of the calling process, in bytes */

#ENDIF

PROCEDURE MAIN
LOCAL i
LOCAL aString := {}
LOCAL bOldError := ERRORBLOCK( { | e | BREAK( e ) } )

   BEGIN SEQUENCE
   FOR i := 1 TO 400
      ? i
      AADD(aString, REPLICATE("A",10 * ( 1024 ^ 2 )))		//10MB

#IFDEF __XPP__
      ?? " Available VAS (MB): " + Str( MEMORY(MEM_PROC_AVAIL) / 1024 )
      IF  MEMORY(MEM_PROC_AVAIL) / 1024 < 50 
      	?? "  !!! CRITICAL !!!   "
	inkey(1)
      ENDIF
#ELSE
      ?? ' Total VAS (MB): ' + AllTrim ( Str( INT( (GlobalMemoryStatusEx () [ HB_TotalVirtual ] / 1024^2) ) ) )
      ?? ',   Available VAS (MB): ' + Str( INT( (GlobalMemoryStatusEx () [ HB_AvailVirtual ] / 1024^2) ) )
      IF INT( (GlobalMemoryStatusEx () [ HB_AvailVirtual ] / 1024^2) ) < 50 		// Available less than 50 MB
	?? "  !!! CRITICAL !!!"
      ENDIF
      IF INT( (GlobalMemoryStatusEx () [ HB_AvailVirtual ] / 1024^2) ) < 100 		// Available less than 100 MB
	inkey(1)
      ENDIF
#ENDIF

   NEXT i
   END SEQUENCE
   ERRORBLOCK( bOldError )
WAIT
RETURN

wenn man den Code unter Xbase++ startet stehen 2 GB -= System also ca. 1.5 GB für das Array zur Verfügung
wenn man das Xbase++ EXE File mit dem 3 GB Patch "behandelt" geht es bis 2 GB Array Grösse.

Das was System + App vorher "weggenommen" haben kann man nun nutzen

---

ein "Client" 32 Bit OS kann 4 GB verwalten. die 32 Bit Server Version bis zu 64 GB ... hm
es ist "nur" eine Lizenz Frage
https://www.geoffchappell.com/notes/win ... memory.htm

---
es gibt nun Apps welche die Lizenzierung aufheben ... wer den o.g. Artikel liest findet Hinweise darauf
dann bekommt man den "gesamte" RAM wo man jetzt mehrere 32 Bit Processe starten kann (ohne Swap File)

aber uns interessiert eine einzelnen 32 Bit App. Da steht immer noch die 2 GB Grenze im Weg.
und hier kommt VAS ins Spiel womit man einen "virtuellen" Bereich (2^32 = 4GB) für "Data" nutzt

komplette 2 GB Grenze ausgenutzt

memo_2GB_of_VAS.zip

(686.73 KiB) 189-mal heruntergeladen

und hiermit geht es bis volle 4 GB

memo_4GB_of_VAS.zip

(686.73 KiB) 184-mal heruntergeladen

[Jan]

Ich hatte mal bei Alaska angefragt. Deren Antwort:

Auch mit Large Address Awareness kann ein Prozess maximal 3,5 GB adressieren. Der Rest bleibt dem Betriebssystem vorbehalten.

Der Xbase++ Linker alink.exe unterstützt dieses Flag nicht. Wir haben die Xbase++ Runtime unter diesen Randbedinungen nicht validiert und geben keineGarantie für korrekte Funktionalität.

Jan

[AUGE_OHR]

hi,

Ich hatte mal bei Alaska angefragt. Deren Antwort:

es ist richtig das der /LARGEADDRESSAWARE Flag "nur" innerhalb des 4 GB Limit arbeitet, aber es ist nur ein Teil der Lösung die es inzwischen gibt.

die beiden Demos zeigen wie der "volle" Bereich von einer 32 Bit App genutzt werden kann.
kannst die Demos ja an Alaska weiterleiten, Source hab ich ja gepostet

---

Das ganze wäre viel einfacher wenn alles 64 Bit fähig wäre ...

[Jan]

Jimmy,

1) Das ist ohnehin klar, das bei 32 Bit-Windows nur 4 GB gehen. Was aber das Doppelte von dem wäre was im Moment mit Xbase++ geht. Und selbst wenn das "nur" 3,5 GB wären - mancher wäre vermutlich ganz glücklich darüber.

2) Es geht ja nicht nur darum, ob das machbar wäre. Alaska schreibt ja ausdrücklich, das die das nicht validiert haben. Es mag also gehen. Die übernehmen aber keine Gewähr dafür. Und auch wenn ALink das nicht unterstützt - mit Visual Studio kann man das per command line ja trotzdem nachträglich einbrennen.

3) Klar wäre das alles kein Problem, wenn Xbase++ 643 Bit wäre. Aber die Diskussion führen wir mit Alaska schon seit mindestens 13 Jahren (damals habe ich das in Berlin das erste Mal mitbekommen). Schon damals sagte Steffen, das die nur einen Compilerschalter ändern müssten, und dann wäre alles 64 Bit. So einfach war das dann wohl doch nicht. Aber da heute eigentlich keine 32 Bit-Windows mehr installiert werden, und Alaska sehr viel am Unterbau und entsprechenden Funktionen geschraubt hat, wird der Zeitpunkt für den Umstieg sicher langsam näher rücken. Wobei dann halt alle die, die doch noch ein 32 Bit-Windows haben (aus welchem Grund auch immer), natürlich hinten über fallen.

Jan

[Tom]

Wenn Alaska auf 64 Bit umschalten würde, würden sie einen bemerkenswerten Teil ihrer Kunden vergraulen, die mit garagengestrickten Speziallösungen zum Teil noch auf prähistorischer Hardware und Windows 7 oder sogar XP sitzen. Nicht nur deshalb müsste eine 32-Bit-Version neben einer 64-Bit-Version gepflegt werden. Der Anreiz dafür ist offenbar noch zu gering, wobei die Automatisierung, die seit einiger Zeit im Bereich Test & Distribution etabliert wurde, möglicherweise helfen könnte, das voranzutreiben.

Wir haben auch noch einige Kunden mit 32-Bit-Hardware.

[Jan]

Tom,

ich finde es immer wieder überraschend, wie viele Leute tatsächlich noch mit solchen alten, nicht mehr supporteten System arbeiten. Da gibt es natürlich verschiedene Gründe für. Einer ist oftmals das die Software, die für diesen Prozess gebraucht wird, nicht auf neueren Systemen läuft. Es aber auch kein Update gibt auf eine Version, die auf aktuellem Windows lauen würde. Aber ja klar, oftmals ist das auch Faulheit, Gedankenlosigkeit, Geiz der Chefs oder Admins.

Ich kenne sogar einen Entwickler einer Wettbewerbs-Software, der in seine Software ausdrücklich eine Abfrage auf das Betriebssystem einbaut - aber anders als wir alle das machen. Wenn das nämlich neuer ist als Windows 7 gibt das eine passende Meldung, und das Programm beendet sich selber. Ich weiß, das die Software an sich auch unter Windows 10 laufen würde. Weil der mal in einer Version diesen Schalter vergessen hat. Aber er weigert sich, dieses üble Betriebssystem zu unterstützen.

Oftmals mag das aber auch daran liegen, das es die zur Entwicklung der Software verwendeten Tools nicht als 64 Bit zur Verfügung stehen. Auch dann könnte man gekniffen sein.

Hatte Steffen nicht zuletzt gesagt, das wenn Alaska auf 64 Bit umsteigt, die von da an keine 32 Bit Version mehr veröffentlichen werden? Also ein striktes entweder-oder?

Jan

[AUGE_OHR]

hi,

ich arbeite mit 32 Bit UND 64 Bit muss "nur" den "Schalter" in der IDE umlegen und die LIBs neu erstellen.

IDE_32_64_BIT.jpg (30.66 KiB) 7144 mal betrachtet

es hat aber ca. 2 Jahre gedauert bis der "Schalter" 2009 unter harbour / HMG eingeführt wurde denn alle API Functionen mussten ja angepasst werden***

***
UNICODE "W" statt "A", Parameter und UTF-8 Anpassung
Zeit abhängig von der Man-Power

---

die Frage an Alaska war "falsch formuliert" denn das ist "alte" Technik was die "Verschiebung" von "System" und "Data" mit 2/2 bis 3/1 angeht und nennt sich "RAMmap".
ein Tool von Sysinternal findest du bei Microsoft hier
https://docs.microsoft.com/en-us/sysint ... ads/rammap

es gibt also die Grenze die man verschieben kann innerhalb der "Physkalischen" 2^32 = 4 GB Limit
bei meinem AsRock Deskmini 110 kann ich im UEFI ; "Dynamisch (2GB), 2.5 GB und 3.5 GB" einstellen

GB35_x86.jpg (53.3 KiB) 7144 mal betrachtet

nun spreche ich von "Virtuelle Adressbereiche" wo man "System" und "Data" trennen kann und die vollen 4 GB, für 32 Bit "System" und "Data" Bereiche, zur Verfügung hat durch AWE und VAS
https://docs.microsoft.com/de-de/window ... extensions
https://en.wikipedia.org/wiki/Virtual_address_space

---

wir reden wir über 32 Bit Apps unter 64 Bit OS wo man gewöhnlich > 4 GB hat

die 32 Bit App nutzt das 32 Bit SubSystem wo die "alten" Regeln gelten
die Physikalische 2^32 Regel gilt zwar aber im 64 Bit OS System sind die Adressen dann "virtuell"

mit genügend RAM kann ich ja mehrere 32 Bit Apps laufen lassen und die Adressen liegen > 4 GB
jede 32 Bit App "sieht" bis zu 4 GB aber eben nur "virtuell"

auch die 2/2 bzw 3/1 Aufteilung ist nicht mehr zwingend notwendig.
man kann die komplett trennen so das dann volle 2^32 = 4GB zur Verfügung steht wie meines Demos zeigen.

nun stammt die Technik aus einer Zeit wo 64 Bit nur in Server System als OS zu finden war.
das Windows SubSystem ist nur aus Kompatibilität Gründen vorhanden.

deshalb wird dieses "Tuning", was ich mit den Demos gezeigt habe, kaum noch genutzt und gleich 64 Bit verwendet.

[brandelh]

Jimmy,

all die Beispiele mit Harbour bringen nix - JAN hat Xbase++

Allgemein zum Thema.

Ich weiß nicht ob die 32 Bit EXE von Xbase++ unter Win64 tatsächlich 2 oder 3 oder 4-Systembereich GB zur Verfügung hat, all das erinnert mich an Clipper unter OS/2 oder WinNT ...

Egal was auch immer, solange Alaska Software das nicht tut ist jede Manipulation der Speicherverwaltung egal von wem höchst gefährlich !

Die maximale Größe eines Arrays wird auch nicht nur durch den physischen RAM sondern durch interne Festlegungen bzw. logische Stack-Adressen etc. begrenzt und
sicherlich ist es nicht sinnvoll in einer normalen Anwendung erst 3 GB Daten in ein Array zu laden um es dann zu bearbeiten.

Beim Dateikopieren habe ich festgestellt, dass es viel effizienter ist 4 KB Blöcke zu lesen und zu schreiben, als erst alles in den RAM und danach auf die Platte zu bringen.
Und da werden nur einfache Bytes geschoben, eine komplexe Struktur im Array abzubilden um sie dann abzuarbeiten ist sicherlich ein Design Fehler bei dem was wir normal für Probleme haben.

Anwendungen die 64 Bit Adressraum benötigen, müssen eben in C/C++ etc. geschrieben werden, die dann auch Mathebibliotheken haben, die damit effizient umgehen können.
Ein früherer Bekannter hat mit vorgeschwärmt, wieviel einfacher C++ die Aufgabe als Fortran erledigen kann, der hat für professionelles CAD Zusatzbibliotheken mit komplexen Matrixoperationen geschrieben,
dafür wäre Xbase++ einfach nicht geeignet.

Mit Amipro (16 Bit Textverarbeitung) habe ich vielen geholfen 300 bis 500 Seiten starke UNI Arbeiten - inkl. Bilder und Zeichnungen - zu schreiben, auf einem Win 3.11 Rechner
Die Textdaten auf Platte, war alles kein Problem, Word kann damit vielleicht heute endlich umgehen, aber ich trauere immer noch AmiPro nach.

Viel Hardware kann sinnvolle Planung nicht ersetzen.

[Jan]

Hallo Hubert,

Danke für Deinen Kommentar. Allerdings habe ich mir angewöhnt, bei Jimmies Kommentaren direkt auszustigen, sobald er mit ot4xb oder harbour anfängt. Weil mir das einfach nichts bringt, das irritiert nur und lenkt von den wirklichen Fragen ab.

Manchmal ist es ganz interessant auszureizen, was mit Xbase++ geht oder nicht. Aber ich stimme Dir zu - etwas an fundamentalen Grundlagen zu machen was Alaska nicht offiziell freigegeben hat, kann schon mal unerwartete negative Ereignisse provozieren.

Wegen der Arrays: Ich hatte ja von Alaska vor vielen Jahren mal Code und eine ch bekommen, um die Arraygröße aufzubohren. Verbunden mit dem Hinweis das man das System damit in die Knie zwingen kann, wenn man es übertreibt. Meine letzten Anfragen zu dem Thema waren für mich nicht so ganz eindeutig - einerseits sagt der Support mir, das es unter 2.0 diese Begrenzungen nicht mehr gäbe. Andererseits konnte der Support sich auch gar nicht mehr daran erinnern das es das mal gab, und das es diesen Workaround dazu gab. Ich stimme Dir aber zu das es bei extrem großen Array zwar länger dauert, die Satz für Satz aufzubauen statt es auf einen Schlag zu erzeugen. Daß das aber erheblich stabiler läuft als solch ein Array auf einen Schlag zu erstellen.

Ja, Fortran hab ich auch mal gelernt. Die allererste Sprache, die ich gelernt habe. Und dann halt auch gleich noch die erste Hochsprache, die es gab. Ich hab aber nie lange genug damit gearbeitet um in solche Probleme vorzudringen.

Meine erste Textverarbeitung war WordPerfect 5.5 für DOS. Die ebenfalls extrem große Dokumente verarbeiten konnte, im Gegensatz zu Word. Das war damals deswegen unter uns Studenten sehr beliebt, weil man damit die umfangreichen Haus- und Diplomarbeiten schreiben konnte. Schade, das (insbesondere) Novell und danach Corel das dann vor die Wand gefahren haben. Gibt es zwar auch heute noch, arbeite ich auch immer noch, aber leider ist die Weiterentwicklung etwas, sagen wir mal so, etwas lustlos.

Jan

[ramses]

ich finde es immer wieder überraschend, wie viele Leute tatsächlich noch mit solchen alten, nicht mehr supporteten System arbeiten. Da gibt es natürlich verschiedene Gründe für. Einer ist oftmals das die Software, die für diesen Prozess gebraucht wird, nicht auf neueren Systemen läuft. Es aber auch kein Update gibt auf eine Version, die auf aktuellem Windows lauen würde. Aber ja klar, oftmals ist das auch Faulheit, Gedankenlosigkeit, Geiz der Chefs oder Admins.

Hallo Jan

es ist nicht mal unbedingt nur das! Es gibt noch einen anderen wichtigen Grund. Es sind viele Zusatz Dll's im Einsatz die es nur als 32 Bit Version gibt. Die laufen zwar problemlos auf den neusten 64 Bit Windows im Verbund mit einer 32 Bit App aber eben nicht zusammen in einer 64 Bit App.

Hier ist es weder Faulheit, Geiz noch sonst was sondern es ist oft schlicht nicht möglich diese DLL's mit vertretbarem Aufwand (einige 10'000 $) in die 64 Bit Ebene zu bringen.

[brandelh]

Ich meine vor einiger Zeit gelesen zu haben, dass Microsoft selbst die 32 Bit Version von Office empfiehlt, wenn man nicht genau weiß warum man die 64 Bit Version benötigt.
Kann sein, dass das heute nicht mehr gilt, aber ich hatte nie Probleme bei M$ wegen zu wenig Speicher, eher weil das Teil macht was ES will und ich verzweifle bei dem Versuch das zu bekommen was ICH will.

Viel Eigenleben konnte ich dem Teil (2010) abgewöhnen, nun will es dauernd dass ich Geld ausgebe um auf die neue Mietversion umzusteigen

[Jan]

Carlo,

ungefähr das meinte ich mit meinem Satz

Oftmals mag das aber auch daran liegen, das es die zur Entwicklung der Software verwendeten Tools nicht als 64 Bit zur Verfügung stehen. Auch dann könnte man gekniffen sein.

Jan

[Jan]

Hubert,

ja, diese Aussage von MS über sein eigenes Office kenne ich auch.

Und ja, genau das hasse ich oftmals an MS-Office. MS meint dauern es wüßte es besser als ich, und will mir angelich Arbeit abnehmen indem die das tun was die für gut und richtig halten. Und mir damit erst richtig viel Arbeit machen, weil ich das irgend wie wieder rückgängig machen muß.

Jan

[Jan]

Gibt es eigntlich eine Möglichkeit auszulesen, welches Windows der anwedner nutzt? Ob 32 oder 64 Bit? OS() gibt das ja nicht her.

Jan

[brandelh]

OS(): Windows 10 2009 Build 19042     

SET:

ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files

die letzten beiden Zeilen sollten nur bei 64 Bit Windows existieren.

in der API ?

[brandelh]

API:

https://docs.microsoft.com/en-us/window ... w64process

Code: Alles auswählen

BOOL IsWow64Process(
  HANDLE hProcess,
  PBOOL  Wow64Process
);

Rückgabewert 0 = Fehler, # 0 ok
hProcess = Handle der EXE
Wow64Process = LONG per Referenz, also @nWow64Process übergeben.

Rückgabe # 0 wenn ein Win32 Bit Programm unter Windows 64 Bit (Emulation) ausgeführt wird.

EXTERN kann damit umgehen, aber da nur einfache Parameter benötigt werden, sollte auch DLLFunction() damit zurecht kommen.

[BJelinek]

ich benutze folgende Version:

Code: Alles auswählen

FUNC Is64Bit(nModus)

static lIst64Bit
local  xRet
nModus := if(nModus = nil,0,nModus)

if lIst64Bit = nil
 lIst64Bit := IF( FILE( GetEnv( "HOMEDRIVE") + "\WINDOWS\SysWOW64","D" ), .T., .F. )
endif

if     nModus = 1
 xRet := if(lIst64Bit,"64Bit","32Bit")
elseif nModus = 2
 xRet := if(lIst64Bit,"64 Bit","32 Bit")
else
 xRet := lIst64Bit
endif

RETURN xRet

[AUGE_OHR]

hi,

Allerdings habe ich mir angewöhnt, bei Jimmies Kommentaren direkt auszustigen, sobald er mit ot4xb oder harbour anfängt. Weil mir das einfach nichts bringt, das irritiert nur und lenkt von den wirklichen Fragen ab.

du lebst in einer Xbase++ Welt was vieles nicht kann. Du musst über den Teller-Rand blicken was Windows kann.
Xbase++ basiert auf Windows API und du kennst nur "das" was Alaska daraus macht.

wenn Alaska nun die Technik nicht beherrscht und nicht verwendet heisst das noch lange nicht das es nicht funktioniert was ich mit den Demos beweisen kann.

---

ich bezweifle sogar das Xbase++ jemals 64 Bit fähig wird.

es ist nicht nur die GUI LIB/DLL die man auf den Stand bringen müsste was eine Azubi "Fleiss-Arbeit" ist.
es muss auch XPP.EXE und ALINK.EXE auf 64 Bit gebracht werden der wohl P-CODE wie Cl*pper erzeugt ...

ich kennen aber keinen Compiler der P-CODE mit 64 Bit erzeugt ... den müsset Alaska erst "erfinden"

---

als ich mit Xbase++ angefangen habe ging es noch richtig ab bei Alaska. Da bestand Alaska noch aus vielen Personen.
mit der Zeit verschwanden die Personen und die Entwicklung ging immer langsamer voran.
mit der Man-Power ging auch Wissen verloren ... man fällt immer weiter zurück ... wie lange geht das weiter ?

[ramses]

es muss auch XPP.EXE und ALINK.EXE auf 64 Bit gebracht werden der wohl P-CODE wie Cl*pper erzeugt ...
ich kennen aber keinen Compiler der P-CODE mit 64 Bit erzeugt ... den müsset Alaska erst "erfinden"

Jimmy

das musst du nichs erfinden, der so heiss gelobte (kostenlose) xbase++ Ersatz von dem viele Leute so schwärmen macht ja noch immer
nichts anderes er erzeugt Tokens wie es Clipper vor 35 Jahren auch schon tat ..... einfach nur als 64 Bit Version.

du lebst in einer Xbase++ Welt was vieles nicht kann. Du musst über den Teller-Rand blicken was Windows kann.
Xbase++ basiert auf Windows API und du kennst nur "das" was Alaska daraus macht.

wenn Alaska nun die Technik nicht beherrscht und nicht verwendet heisst das noch lange nicht das es nicht funktioniert was ich mit den Demos beweisen kann.

Xbase bietet noch immer die Brücke in die Vergangenheit, Clipperprogramme aus 1985 bringst du damit noch heute sehr einfach in die Gegenwart.
Ich finde Alaska macht die Arbeit in Ihrem Segment sehr gut.
Es ist für viele Aufgaben ein Super Tool.

Du musst über den Teller-Rand blicken was Windows kann.

Was soll das bringen?
Einzig mit dem vorhandenen improvisieren und die gestelle Aufgabe lösen bringt Kohle von der man leben kann.
Natürlich muss man das auch wollen.
Mit zuviel über den Tellerand blicken wird man nur Wirr im Kopf ......
Und verbrät Zeit in der man die Aufgabe längst gelöst hätte.

[georg]

Hallo, Jimmy -

ich kennen aber keinen Compiler der P-CODE mit 64 Bit erzeugt ... den müsset Alaska erst "erfinden"

Du nicht - aber ich. Auf der iSeries (auch mal i5, S/38 oder AS/400 genannt) werkelt ein Compiler, der 64bit P-Code erzeugt. Und der ist für industriellen Einsatz geeignet. Übrigens schon seit Jahrzehnten.

Und weil Du so vieles noch nicht gehört hast, die IBM ist damals erst von 32bit auf 48bit umgestiegen. Und dann gab es sogar einen 48bit P-Code Compiler, der später von einem 64bit Compiler abgelöst wurde.

Sachen gibt's ...

[brandelh]

Für die allermeisten Entwickler, gibt es keine Probleme mit der 32 Bit Speicherbegrenzung.
Alle Zusatzbibliotheken auf 64 Bit umzustellen wäre eine Mamutaufgabe, mit LibXL und QuickPDF sollte es auch in 64 bit geben,
aber gerade viele kleinere Speziallösungen eben nicht.

Wenn man wirklich 64 Bit Adressraum benötigt, muss man halt Harbour oder gleich C/C++ oder Java nehmen und sich nicht über Xbase++ beschweren