Entwickler-Ecke
Programmierwerkzeuge - Delphi 64 Bit unter Windows 7 64 bit ?
Hochhaus - Sa 24.04.10 15:56
Titel: Delphi 64 Bit unter Windows 7 64 bit ?
Ich bin neu hier. Zu Beginn eine "dumme" Frage: Gibt es ein 64 bit-Delphi für Windows 7 64 bit ? Oder erst Beta-Versionen ?
Besten Dank im Voraus für die Antworten. Wo kriegt man es, falls es existiert ?
Moderiert von 
Kha: Topic aus Sonstiges (Delphi) verschoben am Sa 24.04.2010 um 16:57
Moderiert von Gausi: Topic aus Programmierwerkzeuge (Library) verschoben am So 25.04.2010 um 12:13
Moderiert von Narses: Überflüssige Zeilenumbrüche/Leerzeilen entfernt.
Gausi - So 25.04.10 11:19
Delphi für 64 Bit gibt es noch nicht. Wann es das gibt, ist unklar (it's done, when it's done).
Du kannst mit den 32-Bit-Versionen auch unter Win64 programmieren, das Compilat ist dann ebenfalls 32bit. Alternativ kannst du Lazarus verwenden, ein OpenSource-Projekt, das einigermaßen kompatibel zu Delphi ist und neben 64Bit auch Linux und Mac unterstützt.
Hochhaus - Do 30.12.10 08:32
Gausi hat folgendes geschrieben  : |
Delphi für 64 Bit gibt es noch nicht. Wann es das gibt, ist unklar (it's done, when it's done).
Du kannst mit den 32-Bit-Versionen auch unter Win64 programmieren, das Compilat ist dann ebenfalls 32bit. Alternativ kannst du Lazarus verwenden, ein OpenSource-Projekt, das einigermaßen kompatibel zu Delphi ist und neben 64Bit auch Linux und Mac unterstützt. |
Inzwischen sind 8 Monate vergangen /Gibt es jetzt ein Delphi 64 Bit ? Danke im Voraus für die Antworten .
jaenicke - Do 30.12.10 09:33
Ein Delphi, das selbst 64-bittig ist, wird es so schnell nicht geben. Eine Version, die 64-Bit Exen erstellen kann, ist für 2011 angekündigt (Delphi XE2).
Ich benutze Delphi 2006 bis Delphi XE ganz normal unter Windows 7 64-Bit, die erstellten Exen ebenfalls, die sind eben nur keine echten 64-Bit Exen. Warum ist dir das so wichtig, gibt es da ein spezielles Problem?
Hochhaus - Do 30.12.10 10:17
| jaenicke hat folgendes geschrieben : |
Ein Delphi, das selbst 64-bittig ist, wird es so schnell nicht geben. Eine Version, die 64-Bit Exen erstellen kann, ist für 2011 angekündigt (Delphi XE2).
Ich benutze Delphi 2006 bis Delphi XE ganz normal unter Windows 7 64-Bit, die erstellten Exen ebenfalls, die sind eben nur keine echten 64-Bit Exen. Warum ist dir das so wichtig, gibt es da ein spezielles Problem? |
Delphi 64 Bit kann vermutlich mehr Hauptspeicher adressieren. Oder nicht ? Das ist der Grund, weshalb ich danach frage.
jaenicke - Do 30.12.10 10:28
Das stimmt, aber da musst du dann wirklich auf Delphi XE2 warten oder Lazarus oder eine andere Sprache verwenden. (Da ist eigentlich nur die Frage, ob du derart viel Speicher wirklich brauchst.)
SvenAbeln - Do 30.12.10 10:45
| Hochhaus hat folgendes geschrieben : |
Delphi 64 Bit kann vermutlich mehr Hauptspeicher adressieren. Oder nicht ? Das ist der Grund, weshalb ich danach frage. |
Unter 64bit Windows kann man mit FastMM auch jetzt schon 4GB adressieren, mehr geht dann wirklich erst mit einem 64bit Delphi.
jaenicke - Do 30.12.10 10:53
| SvenAbeln hat folgendes geschrieben : |
| Unter 64bit Windows kann man mit FastMM auch jetzt schon 4GB adressieren |
Der FastMM Speichermanager ist doch ohnehin in Delphi integriert. Das sollte dann also auch direkt gehen.
(Außer in den ganz alten Versionen bis Delphi 7/2005.)
Lemmy - Do 30.12.10 11:23
Hi,
| jaenicke hat folgendes geschrieben : |
| Ein Delphi, das selbst 64-bittig ist, wird es so schnell nicht geben. |
wie kommst Du darauf bzw. Was ist der Grund dafür? Die IDE ist in Delphi programmiert, der Compiler wenn mich nicht alles täuscht doch aus. Was spräche dann dagegen zumindest die IDE umzustellen?
Grüße
SvenAbeln - Do 30.12.10 11:49
| jaenicke hat folgendes geschrieben : |
Der FastMM Speichermanager ist doch ohnehin in Delphi integriert. Das sollte dann also auch direkt gehen.
(Außer in den ganz alten Versionen bis Delphi 7/2005.) |
Mit dem integrierten Speichermanager habe ich es noch nicht getestet, in dem entsprechenden Projekt verwenden wir den normalen FastMM.
| FastMM4.pas hat folgendes geschrieben: |
| Supports up to 3GB of user mode address space under Windows 32-bit and 4GB under Windows 64-bit. Add the "$SetPEFlags $20" option (in curly braces) to your .dpr to enable this. |
platzwart - Do 30.12.10 12:29
Was mich da interessieren würde: Wozu muss man bei einer Delphi-App mehr als 4GB adressieren?
Bernhard Geyer - Do 30.12.10 12:40
| platzwart hat folgendes geschrieben : |
| Was mich da interessieren würde: Wozu muss man bei einer Delphi-App mehr als 4GB adressieren? |
Wenn du ein Plugin für ein 64-Bit Programm entwickeln wirst (Office 2010, Alle CAD-Programme) geht das nur mit einem 64-Bit Compiler. Auch tritt das Problem mit Speicherfragmentierung (Windows läd x-DLLs in deinem Adressraum nicht mehr auf. Dieser kann dazu führen das du keinen zusammenhängenden Speicher > 500 MB anfordern kannst.
Delete - Do 30.12.10 12:52
Aber mal ehrlich in wie vielen von hundert Fällen hat man das Problem? Ich hatte zum Beispiel noch nie das Problem, dass ich zu wenig Speicher gehabt hätte. Speicherprobleme bekommt man eigentlich nur dann, wenn man nicht auf seinen Speicher achtet und vergisst Speicher wieder freizugeben.
Gausi - Do 30.12.10 13:26
Ich hatte die Tage zufällig mit jemanden kurz darüber gesprochen. Derjenige ist Mathematiker im Versicherungsbereich. Für Risiko-Abschätzungen u.ä. werden da sehr umfangreiche Simulationen laufen gelassen. Wenn ich richtig verstanden habe, ist die in Delphi geschriebene Software dafür hauptsächlich damit beschäftigt, Daten auf Platte auszulagern und wieder davon zu lesen - die 4GB reichen halt nicht wirklich aus für die Datenmengen, die da benutzt werden.
Ist zwar ein recht spezieller Anwendungsfall, aber das kommt durchaus vor.
Delete - Do 30.12.10 13:32
Da stellt sich aber die Frage, ob Delphi die richtige Sprache für so was ist.
jaenicke - Do 30.12.10 14:07
| Lemmy hat folgendes geschrieben : |
| wie kommst Du darauf bzw. Was ist der Grund dafür? Die IDE ist in Delphi programmiert, der Compiler wenn mich nicht alles täuscht doch aus. |
Richtig, aber soweit ich das verstanden habe bleibt die IDE 32-Bit Windows. 64-Bit, Mac und später dann auch Linux Programme kommen nur aus dem entsprechenden Backend des Compilers heraus.
Der Grund ist vermutlich ganz einfach, das es keinen Grund gibt, das zu ändern. :nixweiss:
Delete - Do 30.12.10 14:22
Hinzukommt, dass die Portierung nicht ganz trivial ist.
Lemmy - Do 30.12.10 14:44
Hi,
| jaenicke hat folgendes geschrieben : |
| Der Grund ist vermutlich ganz einfach, das es keinen Grund gibt, das zu ändern. :nixweiss: |
Zumindest der Aufwand für Vertrieb und Support wäre bei 2 unterschiedlichen Versionen höher.
| Luckie hat folgendes geschrieben : |
| Hinzukommt, dass die Portierung nicht ganz trivial ist. |
Portierung von was? IDE oder Compiler? Und vor allem: Welcher Aufwand ist denn zu erwarten? Auch in Bezug auf eigene Anwendungen? Um es "einfacher" zu machen: Bleiben wir bei Win32/Win64 ohne Linux und ohne Mac. Kann ich davon ausgehen, dass ich über eine Projektoption einstellen kann welche Exe beim kompilieren erstellt werden soll oder davon, dass es eine VCL32 und eine VCL64 geben wird...??
Grüße
jaenicke - Do 30.12.10 15:19
| Lemmy hat folgendes geschrieben : |
| Welcher Aufwand ist denn zu erwarten? Auch in Bezug auf eigene Anwendungen? |
Man muss schon einiges umstellen, z.B. aufgrund der 64-Bit Datentypen. es sollte sich aber im Rahmen halten, wenn man nicht Meta-Typen wie Real oder so benutzt hat. Ein wenig dazu kannst du auch bei Twitter von den Entwicklern lesen.
| Lemmy hat folgendes geschrieben : |
| Um es "einfacher" zu machen: Bleiben wir bei Win32/Win64 ohne Linux und ohne Mac. Kann ich davon ausgehen, dass ich über eine Projektoption einstellen kann welche Exe beim kompilieren erstellt werden soll |
Ja, du schaltest damit das Backend des Compilers um, das den entsprechenden Code erstellt. Dafür wurde der Compiler neu mit Front- und Backend geschrieben. Wenn du in den Quelltext der D2010+ Units schaust, siehst du auch überall ifdefs für Linux, Mac, ...
Lemmy - Do 30.12.10 16:43
Hi,
| jaenicke hat folgendes geschrieben : |
| Lemmy hat folgendes geschrieben : | | Welcher Aufwand ist denn zu erwarten? Auch in Bezug auf eigene Anwendungen? |
Man muss schon einiges umstellen, z.B. aufgrund der 64-Bit Datentypen. es sollte sich aber im Rahmen halten, wenn man nicht Meta-Typen wie Real oder so benutzt hat. Ein wenig dazu kannst du auch bei Twitter von den Entwicklern lesen. |
Ok, das hätte ich vielleicht sagen sollen - das mit den Integer bzw. Datentypen allgemein ist so weit klar, auch die Problematik bzgl. Dateien und unterschiedlicher Länge. Datenbanken udn vergleichbares lassen sich hier ggf. ebenso einfach auf die korrespondierenden umstellen bzw. hier gibts jettz schon die Möglichkeit die fundamentalen Typen zu verwenden, die sich nicht ändern.
| jaenicke hat folgendes geschrieben : |
| Ja, du schaltest damit das Backend des Compilers um, das den entsprechenden Code erstellt. Dafür wurde der Compiler neu mit Front- und Backend geschrieben. Wenn du in den Quelltext der D2010+ Units schaust, siehst du auch überall ifdefs für Linux, Mac, ... |
ah.. muss ich gleich mal schauen.... Danke für den Tipp...
Delphi-Laie - Do 30.12.10 17:16
| jaenicke hat folgendes geschrieben : |
Ein Delphi, das selbst 64-bittig ist, wird es so schnell nicht geben. Eine Version, die 64-Bit Exen erstellen kann, ist für 2011 angekündigt (Delphi XE2).
Ich benutze Delphi 2006 bis Delphi XE ganz normal unter Windows 7 64-Bit, die erstellten Exen ebenfalls, die sind eben nur keine echten 64-Bit Exen. Warum ist dir das so wichtig, gibt es da ein spezielles Problem? |
Das Problem sehe ich weniger in Delphi, sondern in den Compilaten. 32-Bit-Programme sind unter 64 Bit im Prinzip ebenso schmalspurig und - oft genug leider auch - funktionseingeschränkt, wie es die 16-Bit-Programme unter Windows 32 waren und sind.
platzwart - Do 30.12.10 17:50
Das Problem ist mir in der Praxis allerdings so gut wie garnicht vorgekommen...
Delphi-Laie - Do 30.12.10 17:58
| platzwart hat folgendes geschrieben : |
| Das Problem ist mir in der Praxis allerdings so gut wie garnicht vorgekommen... |
Dann benutze mal einen globalen Hook oder eine so relativ systemnahe Funktion wie "CreateToolHelpSnapShot" oder versuche das Lesen/Setzen der Prioritäten oder Beenden beliebiger Prozesse/Threads - und schon sind 32-Bit-Compilate mit ihrem Latein weitgehend am Ende.
platzwart - Do 30.12.10 18:35
Aber auch nur weitgehend und all das wird nur in 0,01% aller Programme benötigt werden...
Gausi - Do 30.12.10 18:40
Zu den 0.01% gehören dann z.B. Player, die einen Hook auf die Multimediatasten installieren wollen. Oder solche, die ein Deskband in die Taskleiste integrieren wollen. Das kann man mit Delphi aktuell vergessen.
Nur um mal zwei Beispiele aus der Praxis zu nennen. ;-)
Chemiker - Do 30.12.10 18:56
Hallo,
das ist die gleiche Diskussion wie bei der BS Umstellung von 16 auf 32 Bit. Arbeitet heute von euch noch ernsthaft einer mit einem 16Bit BS?
Wenn man DLLs für MS-Office schreiben will, kann man zur Zeit Delphi auch vergessen, weil einige schon die 64Bit Versionen einsetzen.
Bis bald Chemiker
Delphi-Laie - Do 30.12.10 20:09
| platzwart hat folgendes geschrieben : |
| Aber auch nur weitgehend und all das wird nur in 0,01% aller Programme benötigt werden... |
Also, ich schrieb in meinem Leben noch nicht allzuviele größere Delphi-Programme (etwa "eine Hand voll"), aber schon bei zweien davon war unter Windows 64 Bit mit Delphi irgendwann "das Ende der Fahnenstange erreicht", so daß ich teilweise oder ganz auf Lazarus umschwenkte (mit dem ich mich heute noch umherärgere, eine wahre Freude ist das im Vergleich zu Delphi nicht).
Was habe ich Laie (!!) dann wohl für ein Talent (auch Glück?), 0,01% aller Programme zu tangieren (bei mir ist diese Quote eher bei 40 %, und, da es meine beiden größten Programme sind, vom Programmieraufwand noch mehr)?
Konsequenterweise äußerten mithin auch meine Vorredner Bedenken, wie schnell man mit den 32 Bit heutzutage am Ende sein kann.
platzwart - Do 30.12.10 20:50
Wenn alle nur noch 60% ihrer Programme mit Delphi umsetzen können, dann gibt es wohl niemanden mehr, der Delphi kauft und das Forum hier kann dann ja ruhig dicht gemacht werden...
jaenicke - Do 30.12.10 21:49
| Delphi-Laie hat folgendes geschrieben : |
| Was habe ich Laie (!!) dann wohl für ein Talent (auch Glück?), 0,01% aller Programme zu tangieren |
Ein großes Talent. Weder beruflich noch privat hatte ich da bisher oft dieses Problem. Für ein einziges kleines Projekt brauchte ich Lazarus (ein 64-Bit Dienst, und genau dort hat Lazarus einen Fehler, dass nicht einmal das Beispiel direkt funktionierte...). Alles andere hätte sich mit Delphi leicht machen lassen, bezogen auf Desktopanwendungen für Windows.
Dass ich auch immer wieder mal C# oder noch was anderes benutzt habe, liegt eher daran, dass ich damit auch was machen wollte.
Hochhaus - Fr 10.06.11 08:35
Inzwischen sind wieder 5 - 6 Monate vergangen. Gibt es jetzt ein 64-Bit Delphi ? Wo kriegt man es ?
Herzliche Grüsse
Hochhaus
Gausi - Fr 10.06.11 08:48
Nein, noch nicht.
jaenicke - Fr 10.06.11 09:11
Es kommt aber auf jeden Fall dieses Jahr, ob genauere Daten schon veröffentlicht wurden, weiß ich nicht. ;-)
spawn89 - Fr 10.06.11 10:09
Beta läuft ja, und ich hab schon öfters Oktober gelesen.
Hochhaus - Sa 08.10.11 18:53
| spawn89 hat folgendes geschrieben : |
| Beta läuft ja, und ich hab schon öfters Oktober gelesen. |
Jetzt ist es Oktober. Ist es jetzt da ?
Delete - Sa 08.10.11 21:11
| Hochhaus hat folgendes geschrieben : |
| Jetzt ist es Oktober. Ist es jetzt da ? |
Man hätte auch einfach mal googlen können.
Hochhaus - Mo 10.10.11 06:38
Danke für die Hilfe ! Ich habe es gefunden, heruntergeladen und installiert. (Die 30 Tage Trial-Version)
Nur finde ich nicht, wo man beim Compilieren zwischen der 32- und 64-Bit EXE umschalten kann !
Herzliche Grüsse,
Hochhaus
Regan - Mo 10.10.11 08:39
Dafür musst du im Projekt Manager (Widget rechts oben) bei Target Platforms einen Rechtklick machen und eine neue Zielplattform hinzufügen.
Hochhaus - Mo 10.10.11 09:06
| Regan hat folgendes geschrieben : |
| Dafür musst du im Projekt Manager (Widget rechts oben) bei Target Platforms einen Rechtklick machen und eine neue Zielplattform hinzufügen. |
Danke ! Das hat funktioniert. Nur kommen jetzt beim Compilieren meiner 32-Bit-Anwendung Dutzende von Fehlermeldungen, die vorher nicht da waren ... ...
jaenicke - Mo 10.10.11 09:33
Was sind das denn für Meldungen?
Wenn es um die Units geht, müssen da die entsprechenden Prefixe davor, wenn noch welche fehlen.
Hochhaus - Mo 10.10.11 09:43
| jaenicke hat folgendes geschrieben : |
Was sind das denn für Meldungen?
Wenn es um die Units geht, müssen da die entsprechenden Prefixe davor, wenn noch welche fehlen. |
Undeklarierter Bezeichner "CrHourGlass" in Zeile 154
Undeklarierter Bezeichner „mrYes“ in Zeile 328
etc. etc.
jaenicke - Mo 10.10.11 09:56
Das sollte die Unit Controls sein, also jetzt vermutlich (kann grad nicht schauen) VCL.Controls, liegt die in den uses?
Hochhaus - Mo 10.10.11 10:08
| jaenicke hat folgendes geschrieben : |
| Das sollte die Unit Controls sein, also jetzt vermutlich (kann grad nicht schauen) VCL.Controls, liegt die in den uses? |
Nein.
Gruss, Hochhaus
Hochhaus - Mo 10.10.11 10:17
| jaenicke hat folgendes geschrieben : |
| Das sollte die Unit Controls sein, also jetzt vermutlich (kann grad nicht schauen) VCL.Controls, liegt die in den uses? |
Ich habe die VCL.Controls eingebunden. Jetzt funktioniert es weitgehend. Aber jetzt kommen neue weitere Fehlermeldungen
[DCC Fehler] CHILD.PAS(350): E1012 Konstantenausdruck verletzt untere Grenzen ...
in : --> Zeile := RichEdit1.Perform(EM_LineFromChar, -1, 0) + 1; {Dies lässt sich unter Delphi 6 PE problemlos compilieren}
Danke im Voraus für die Hilfe !
Hochhaus
P.S. Wie ich inzwischen gemerkt habe, gibt es einen grösseren Arbeitsaufwand, um ein bisheriges 32-Bit-Programm auf 64 Bit umzustellen. Der Texteditor läuft nun "fast" unter 64 Bit. Wenn ich ein neues Kindfenster öffne, kommen chinesische Zeichen auf den Bildschirm. Eine bestehende Datei wird mit grauenhaft verzerrtem Schriftfont dargestellt usw. usw.
Bin ich der Einzige mit solchen Problemen ?
Hochhaus - Mo 10.10.11 18:29
Hiermit poste ich das Beispielprojekt "TextEditor". Dann können Andere nachvollziehen, was es alles an Problemen gibt. (64 Bit-Version)
Chemiker - Mo 10.10.11 19:43
Hallo Hochhaus,
wenn der Code unter Delphi 6 gelaufen ist dann wirst Du ein Problem mit UNI-Code haben das seit Delphi 2009 implementiert worden ist. Das bedeutet z.B. das String unter Delphi 6 jetzt AnsiString unter Delphi XE2 ist.
Bis bald Chemiker
jaenicke - Mo 10.10.11 20:42
Da sind auch ein paar richtig schöne Fehler drin. Zum Beispiel hier in FindX gehst du davon aus, dass ein Zeichen ein Byte groß ist statt es mit SizeOf(Char) zu verrechnen:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
| GetMem(Ft, Length(FindText) + 1);
StrPCopy(Ft, FindText);
PGroesse := RichEdit1.GetTextLen + 1;
GetMem(Puffer, PGroesse);
RichEdit1.GetTextBuf(Puffer, PGroesse);
... |
Hochhaus - Di 11.10.11 07:17
Moderiert von Narses: Komplett-Zitat des letzten Beitrags entfernt.
Vielen Dank ! Hochhaus
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!