Delphi XE2 - wo 64-Bit-Option?

[Delphi-Laie]

Hallo Delphifreunde!

Tut mir leid, hier die Anfängerfrage aller Anfängerfragen zum neuen Delphi XE2 zu stellen:

Wo kann man die 64 Bit für das Format des Compilates einstellen?

Ich suche mir den Wolf danach, sowohl im Internet als auch in der XE2-IDE.

Besten Dank für die Antwort(en)!

Viele Grüße

Delphi-Laie

[cookie22]

In der Projektverwaltung kannst du die Platform ändern. Einfach rechts Klick drauf und 64 Bit auswählen.

[Delphi-Laie]

Zitat:

Zitat von cookie22 (Beitrag 1121897)

In der Projektverwaltung kannst du die Platform ändern. Einfach rechts Klick drauf und 64 Bit auswählen.

Tausend dank!

Projektverwaltung findet man nicht unter Projekt->Verwaltung (gibt's nicht), sondern unter Ansicht. Nunja, eigenwillige "Logik", das kenne ich aber noch dunkel von früheren Versionen.

64 Bit erscheinen nicht per se von allein, man muß sie nach Rechtsklick erst einmal sichtbar/aktivierbar machen (falls jemand auch darob stolpert). Warum das so ist, erschließt sich mir (auch) nicht, auch so etwas führt zu tausenderlei Suchvorgängen und Nachfragen.

Ergänzung: Die Größen der Exe-Dateien nehmen sich auch nach dem Entfernen der Debuginformationen mit den Lazarus-/Freepascal-Compilaten auch nichts mehr, sind denen ebenbürtig.

[Stevie]

Zitat:

Zitat von Delphi-Laie (Beitrag 1121900)

Projektverwaltung findet man nicht unter Projekt->Verwaltung (gibt's nicht), sondern unter Ansicht. Nunja, eigenwillige "Logik", das kenne ich aber noch dunkel von früheren Versionen.

64 Bit erscheinen nicht per se von allein, man muß sie nach Rechtsklick erst einmal sichtbar/aktivierbar machen (falls jemand auch darob stolpert). Warum das so ist, erschließt sich mir (auch) nicht, auch so etwas führt zu tausenderlei Suchvorgängen und Nachfragen.

Sollte eigentlich ins Auge stechen, wo wohl 64bit zu finden ist, wenn unter deinem Project1.exe im Project Manager der komplett neue Punkt "Target Platforms (Win32)" steht.

[Delphi-Laie]

Zitat:

Zitat von Stevie (Beitrag 1121907)

Sollte eigentlich ins Auge stechen, wo wohl 64bit zu finden ist, wenn unter deinem Project1.exe im Project Manager der komplett neue Punkt "Target Platforms (Win32)" steht.

Wie gesagt, man muß erst einmal wissen, daß die 64 Bit unter Ansicht->Projektoptionen zu finden sind. Sie könnten doch genauso z.B. in den Projekt->Optionen->Compiler zu finden sein, nicht wahr?

Und die 64 Bit sind dort eben nicht zu finden, sondern zu finden ist dort nach Rechtsklick "Plattform hinzufügen". Warum die nicht als Standard mit erscheinen, ist unklar.

Den Mac als Zielplattform kann ich nicht hinzufügen, woran das liegt, ist unklar, für mich aber auch nicht wichtig.

[jaenicke]

Du musst da nichts im Menü machen. :gruebel:

Wenn du Delphi 2005 und höher startest, ist in der Standardeinstellung die Projektverwaltung direkt rechts sichtbar:

Anhang 35089

Mac OS als Zielplattform geht nur, wenn du eine Firemonkey-Anwendung und keine VCL-Anwendung erstellst.

[Ralf Kaiser]

Hab ich da was übersehen oder kann man in der Projektverwaltung zwar alle Projekte erzeugen aber nicht alle Plattformen?

Das heißt dann wohl in einer großen Projektgruppe alle Projekte manuell beim Build umstellen, oder? (OK, ihr habt ja Recht: normalerweise lässt man die Builds mit einem MSBuild-Script machen... :wink: )

[USchuster]

Zitat:

Zitat von Ralf Kaiser (Beitrag 1121916)

Hab ich da was übersehen oder kann man in der Projektverwaltung zwar alle Projekte erzeugen aber nicht alle Plattformen?

Das heißt dann wohl in einer großen Projektgruppe alle Projekte manuell beim Build umstellen, oder? (OK, ihr habt ja Recht: normalerweise lässt man die Builds mit einem MSBuild-Script machen... :wink: )

Ja Du hast da was übersehen. Mittels des Dropdown Menüs des Platformschalters im Projektmanager (letzter Schalter rechts unten) oder Ansicht | Konfigurations-Manager lässt sich die aktive Platform für alle Projekte umschalten (die diese unterstützen).

Build-Gruppen wären eine weitere Möglichkeit über mehrere Projekte mit bestimmter Konfiguration und Platform zu erstellen.

[Daniel]

Zitat:

Zitat von Delphi-Laie (Beitrag 1121900)

Ergänzung: Die Größen der Exe-Dateien nehmen sich auch nach dem Entfernen der Debuginformationen mit den Lazarus-/Freepascal-Compilaten auch nichts mehr, sind denen ebenbürtig.

Den FreePascal-Compiler hatte ich noch nicht am Wickel, allerdings einen C-Compiler und es ist so, dass 64-bit EXEn grundsätzlich größer werden, da einige der in ihnen enthaltenen Datentypen größer sind. Aus Faustregel kann man von etwa 25%-30% an Zuwachs ausgehen, wenn man ein 32-bit und ein 64-bit Kompilat der gleichen Anwendung vergleicht. Der Zuwachs betrifft prinzipiell alle Compiler, wie groß er tatsächlich ist, hängt natürlich auch von der Anwendung ab.

[Ralf Kaiser]

Zitat:

Zitat von USchuster (Beitrag 1121918)

Ja Du hast da was übersehen. Mittels des Dropdown Menüs des Platformschalters im Projektmanager (letzter Schalter rechts unten) oder Ansicht | Konfigurations-Manager lässt sich die aktive Platform für alle Projekte umschalten (die diese unterstützen).

Danke!

Wusste ich doch, dass ich wieder mal Tomaten auf den Augen hatte...

[Delphi-Laie]

Zunächst einmal danke für die regen Diskussionsbeiträge!

Zitat:

Zitat von Daniel (Beitrag 1121920)

Zitat:

Zitat von Delphi-Laie (Beitrag 1121900)

Ergänzung: Die Größen der Exe-Dateien nehmen sich auch nach dem Entfernen der Debuginformationen mit den Lazarus-/Freepascal-Compilaten auch nichts mehr, sind denen ebenbürtig.

Den FreePascal-Compiler hatte ich noch nicht am Wickel, allerdings einen C-Compiler und es ist so, dass 64-bit EXEn grundsätzlich größer werden, da einige der in ihnen enthaltenen Datentypen größer sind. Aus Faustregel kann man von etwa 25%-30% an Zuwachs ausgehen, wenn man ein 32-bit und ein 64-bit Kompilat der gleichen Anwendung vergleicht. Der Zuwachs betrifft prinzipiell alle Compiler, wie groß er tatsächlich ist, hängt natürlich auch von der Anwendung ab.

Daniel, das ist war mir natürlich auch vorher schon bekannt, schließlich sind 64 Bit mehr als 32, und mit Lazarus fand ich derlei schon bestätigt. Meine empirisch erworbene Faustregel: Die Größe des 64-Bit-Compilates beträgt eher das 1,5fache gegenüber der Größe des 32-Bit-Compilates, sowohl bei Lazarus/FPC als auch bei Delphi XE2.


In der allgemeinen XE2-Euphorie werde ich mir mit folgenden Schnellrésumé nunmehr keine Freunde machen: Das XE2 macht mit meinem Programm "Prozesse" beim 32-Bit-Compilat diverse Probleme auf diversen 32-Bit-NTx-Windows (teilweise bricht sogar der Start mit einer Fehlermeldung ab), die ich auch mit dem Turbo-Delphi-Compilat nicht hatte. Kurzum, ich halte dieses Produkt für nicht ausgereift. Demnächst werde ich das im entsprechenden Thema hochladen/einstellen. Das 64-Bit-Compilat macht hingegen keine Probleme, ich habe allerdings auch nur ein 64-Bit-Windows (7).

[MEissing]

Zitat:

Zitat von Delphi-Laie (Beitrag 1122254)

Das XE2 macht mit meinem Programm "Prozesse" beim 32-Bit-Compilat diverse Probleme auf diversen 32-Bit-NTx-Windows (teilweise bricht sogar der Start mit einer Fehlermeldung ab), die ich auch mit dem Turbo-Delphi-Compilat nicht hatte.

Windows NT? Version 3.xx oder 4.x?

[ChrisE]

Zitat:

Zitat von MEissing (Beitrag 1122273)

Windows NT? Version 3.xx oder 4.x?

naja, es gibt ja auch neuere Windows NT wie 5.x oder 6.x ;-)

Gruß, Chris

[MEissing]

Zitat:

Zitat von ChrisE (Beitrag 1122275)

Zitat:

Zitat von MEissing (Beitrag 1122273)

Windows NT? Version 3.xx oder 4.x?

naja, es gibt ja auch neuere Windows NT wie 5.x oder 6.x ;-)

Gruß, Chris

Hast du auch das hier gelesen:

Zitat:

Seit seiner Version 5.0 wird Windows NT nicht mehr als Teil des Produktnamens sondern nur noch als internes Versionskürzel verwendet.

Wenn jmd von NT spricht schliesse ich auf NT 3.xx oder 4.x

[jaenicke]

Zitat:

Zitat von Delphi-Laie (Beitrag 1122254)

Das XE2 macht mit meinem Programm "Prozesse" beim 32-Bit-Compilat diverse Probleme auf diversen 32-Bit-NTx-Windows (teilweise bricht sogar der Start mit einer Fehlermeldung ab)

Mit welcher Fehlermeldung unter welchen Windowsversionen wäre dabei interessant.

Im Gegensatz zu Turbo Delphi sind mit Delphi 2009 und höher erstellte Anwendungen logischerweise nur unter unicodefähigen Windowsversionen lauffähig (falls du auch ältere Windowsversionen wie 9x ausprobiert hast). Unter NT 4.0 mag in der Richtung etwas funktionieren, aber unterstützt wird es AFAIK (logischerweise) ebenfalls nicht.

[ChrisE]

Zitat:

Zitat von MEissing (Beitrag 1122295)

Hast du auch das hier gelesen:

Zitat:

Seit seiner Version 5.0 wird Windows NT nicht mehr als Teil des Produktnamens sondern nur noch als internes Versionskürzel verwendet.

Selbstverständlich :-) War ja auch nicht böse gemeint. Wollte ja nur zum Ausdruck bringen, dass auch 2000, XP, Vista, Win7 (Servervarianten) immer noch als NT-Betriebssysteme laufen :P

Zitat:

Zitat von MEissing (Beitrag 1122295)

Wenn jmd von NT spricht schliesse ich auf NT 3.xx oder 4.x

Is ja auch in erster Instanz richtig - aber wie gesagt :-)

Gruß, Chris

[MEissing]

OK.

Das die NT Familie mit Windows 7/2K8R2 seinen aktuellen Höhepunkt gefunden hat, war/ist mir schon klar :-)

[Delphi-Laie]

Danke für das lebhafte Interesse!

Also, um das erst einmal aufzuklären (ich hatte schon bei Schreiben ein komisches Gefühl): NT ist für mich eine Baureihe, und mit NTx meinte ich x=5 b und x=5.1 (oder: x:=5 und x:=5.1), oder ganz einfach: 2000 & XP. Auf einem 2000 und einem XP läuft es, auf dem jeweils anderen nicht.

Zitat:

Zitat von jaenicke (Beitrag 1122298)

Zitat:

Zitat von Delphi-Laie (Beitrag 1122254)

Das XE2 macht mit meinem Programm "Prozesse" beim 32-Bit-Compilat diverse Probleme auf diversen 32-Bit-NTx-Windows (teilweise bricht sogar der Start mit einer Fehlermeldung ab)

Mit welcher Fehlermeldung unter welchen Windowsversionen wäre dabei interessant.

Unter 2000 kommt die Feherlmeldung:"....exe hat Fehler und geschlossen und wird geschlossen. Starten Sie das Programm neu. Ein Fehlerprotokoll wird erstellt." Die Suche nach letzterem blieb erfolglos.
Unter XP kommt die Fehlermeldung: "....exe hat ein Problem festgestellt und muß beendet werden....", und nach Wegklicken derselben ein Runtime Error 255 at 00404916. Das bedeutet, daß die erweiterten Attribute (welch immer das konkret auch sein mögen) inkonsistent sind. Naja.. Unter XP kommt man hingegen leicht an den Inhalt des Fehlerberichtes, doch den stelle ich hier nicht zur Schau, er ist viel zu lang und auch nicht Thema dieser Diskussion.

Ist auch egal.

Mir kam schon in den Sinn, daß es evtl. am fehlenden .Net liegen könnte, allerdings wird nicht, wie bei C#-Programmen, die fehlende DLL moniert (deren Namen ich gerade nicht weiß). Bitte gestattet mir dazu noch zwei Fragen:

1. Benötigen die Delphi-XE2-Compilate .Net, und, falls ja, in welcher Version?
2. Falls die erste Frage bejaht werden muß: Wie ermittelt man, ob und ggf. welche .Net Version auf einem Windows installiert ist?

[ChrisE]

Zitat:

Zitat von Delphi-Laie (Beitrag 1122325)

1. Benötigen die Delphi-XE2-Compilate .Net, und, falls ja, in welcher Version?
2. Falls die erste Frage bejaht werden muß: Wie ermittelt man, ob und ggf. welche .Net Version auf einem Windows installiert ist?

Ich lehne mich jetzt mal ganz weit aus dem Fenster und sage zu 1 nein, wenn du eine Win32-Anwendung erstellst mit Delphi XE2.

Gruß, Chris

[EDIT]Also eine native Anwendung[/EDIT]

[Bernhard Geyer]

Sind die System Full-Patched, Also aktuelles SP installiert?
Mit "nackten" W2K oder XP werden die Delphi-Compilate nicht zurecht kommen.

[Lemmy]

Zitat:

Zitat von Delphi-Laie (Beitrag 1122325)

1. Benötigen die Delphi-XE2-Compilate .Net, und, falls ja, in welcher Version?
2. Falls die erste Frage bejaht werden muß: Wie ermittelt man, ob und ggf. welche .Net Version auf einem Windows installiert ist?

"normale" Delphi Compilate brauchen kein .NET - es handelt sich ja um native Win32/Win64 Programme. Und die .NET Version bekommst Du fürs erste über die Verzeichnisse raus die so rum liegen (C:\WINDOWS\Microsoft.NET\Framework) da gibts dann bei einem installierten .NET div. Ordner mit entsprechenden Versionsnummern...

Grüße

[ChrisE]

Hallo Delphi-Laie,

nur ganz kurz, weil es ja der Thread-Titel hergibt: Es liegt aber nicht daran, dass du ein 64-Bit-EXE erstellst und auf einem 32-Bit-Windows ausführen möchtest? Nicht böse gemeint, aber würde wie gesagt zum Thread-Titel passen :-)

Gruß, Chris

[Delphi-Laie]

Zitat:

Zitat von ChrisE (Beitrag 1122335)

Hallo Delphi-Laie,

nur ganz kurz, weil es ja der Thread-Titel hergibt: Es liegt aber nicht daran, dass du ein 64-Bit-EXE erstellst und auf einem 32-Bit-Windows ausführen möchtest? Nicht böse gemeint, aber würde wie gesagt zum Thread-Titel passen :-)

Gruß, Chris

Nein, also sooo dämlich bin ich nun wirklich nicht. Es ist das 32-Bit-Compilat.

Das mit den "nackten" 2000/XP könnte allerdings hinkommen, es sind vor Jahren aufgespielte, die ich nur zu Testzwecken benutze und nicht warte/pflege. Muß ich gleich mal nachschauen.... Ergänzung kommt bald in diesem Beitrag.

Ergänzung: Also das 32-Bit-Compilat funktioniert (nicht):

Windows 2000 Windows XP
funktioniert 500.2195 SP4 Rollupdate 1 SP3
funktioniert nicht 500.2195 SP4 (Rollupdate 1?) SP1

[ChrisE]

Zitat:

Zitat von Delphi-Laie (Beitrag 1122339)

Nein, also sooo dämlich bin ich nun wirklich nicht. Es ist das 32-Bit-Compilat.

Also ich wollte sicher damit nicht sagen, dass du dämlich bist - eher, das Fehler passieren ;-)

Gruß, Chris

[jaenicke]

Die genannten Fehlermeldungen deuten eher darauf hin, dass du explizit API-Funktionen benutzt und dadurch Unicodeprobleme entstehen oder ähnliches. Da hilft nur debuggen, ggf. remote.

Das Fehlerprotokoll ist das ganz normale von Windows, keins der Delphianwendung.

Zitat:

Zitat von ChrisE (Beitrag 1122335)

Es liegt aber nicht daran, dass du ein 64-Bit-EXE erstellst und auf einem 32-Bit-Windows ausführen möchtest?

Dann käme die Meldung, dass es keine gültige Win32-Anwendung ist. ;-)

[Luckie]

Warum sollte eine native Delphi Anwendung nicht auf einem nackten Windows 2000 oder Windows XP laufen? also mir ist nichts bekannt, dass eine Delphi Anwendung ein bestimmtes Service Pack voraussetzt.

[DeddyH]

Manchmal genügt es doch schon, dass der IE nicht in einer bestimmten Mindestversion installiert ist.

[Bernhard Geyer]

Zitat:

Zitat von Luckie (Beitrag 1122342)

Warum sollte eine native Delphi Anwendung nicht auf einem nackten Windows 2000 oder Windows XP laufen? also mir ist nichts bekannt, dass eine Delphi Anwendung ein bestimmtes Service Pack voraussetzt.

AFAIK gibt's bei XP einen Bluescreen wenn man ein Manifest verwendet das das XP ohne SP nicht mag.
Und manchmal werden Treiber-Inkompatitlbitäten/Fehler erst durch Delphi-Apps offensichtlich (Toolbar-Icon-Problem bei Win9x und alten Delphi).

[Delphi-Laie]

Zitat:

Zitat von Luckie (Beitrag 1122342)

Warum sollte eine native Delphi Anwendung nicht auf einem nackten Windows 2000 oder Windows XP laufen? also mir ist nichts bekannt, dass eine Delphi Anwendung ein bestimmtes Service Pack voraussetzt.

Wegen des lebhaften Interesses lade ich hier mal auf die Schnelle meinen Problemkandidaten hoch. Mag sein, daß Ihr überhaupt nichts bemerkt. Also, bei funktioniert er nur auf 50% aller 32-Bit-NTx.

Auch wenn mein Programm an sich natürlich nicht sonderlich interessant sein dürfte, so doch die evtl. Startschwierigkeiten mit XE2, die für die Profis unter Euch sicher von Belang sind.

[Lemmy]

Hi,

Windows 2000 und XP Prof, beide ziemlich aktuelles Patchlevel, bei beiden keine Fehlermeldung...

[jaenicke]

So auf den ersten Blick:

Delphi-Quellcode:

MyConvertSidToStringSid:function(Sid:PSID;var StringSid:PChar):LongBool;stdcall=nil;
MyConvertStringSidToSid:function(StringSid:PChar;var Sid:PSID):Boolean;stdcall=nil;

  {@}MyConvertSidToStringSid:=GetProcAddress(lib,'ConvertSidToStringSidA');
  if not assigned(MyConvertSidToStringSid) then result:=false;
  {@}MyConvertStringSidToSid:=GetProcAddress(lib,'ConvertStringSidToSidA');

PChar <-> ConvertSidToStringSidA
... ;-)
Vielleicht auch noch an anderer Stelle.

War meine erste Vermutung ja nicht ganz falsch. :mrgreen:

[Delphi-Laie]

Zitat:

Zitat von jaenicke (Beitrag 1122355)

So auf den ersten Blick:

Delphi-Quellcode:

MyConvertSidToStringSid:function(Sid:PSID;var StringSid:PChar):LongBool;stdcall=nil;
MyConvertStringSidToSid:function(StringSid:PChar;var Sid:PSID):Boolean;stdcall=nil;

  {@}MyConvertSidToStringSid:=GetProcAddress(lib,'ConvertSidToStringSidA');
  if not assigned(MyConvertSidToStringSid) then result:=false;
  {@}MyConvertStringSidToSid:=GetProcAddress(lib,'ConvertStringSidToSidA');

PChar <-> ConvertSidToStringSidA
... ;-)
Vielleicht auch noch an anderer Stelle.

War meine erste Vermutung ja nicht ganz falsch. :mrgreen:

Danke, jaenicke! Ich werde mich damit eingehender beschäftigen. Allerdings ist es erstaunlich, daß es mal klappt und mal nicht (falls es überhaupt daran liegen sollte).

[ChrisE]

Hallo,

Programm läuft scheinbar ohne Probleme auf:
XP 32Bit
Vista 32Bit / 64Bit
Win7 32Bit / 64 Bit

Alle auf aktuellen Patchlevel.

Gruß, Chris

[Delphi-Laie]

Zitat:

Zitat von ChrisE (Beitrag 1122374)

Hallo,

Programm läuft scheinbar ohne Probleme auf:
XP 32Bit
Vista 32Bit / 64Bit
Win7 32Bit / 64 Bit

Alle auf aktuellen Patchlevel.

Gruß, Chris

Danke!

Hallo jaenicke und die anderen!

WidePChar hin, AnsiString her, mich wunderte, daß

- mein Programm auf manchen NTx läuft, auf anderen nicht (wenn Fehler, dann kann es doch generell nicht laufen),
- die Ansi-/WidePcharfunktionen zum Programmstart doch noch gar nicht aufgerufen werden.

Also einfach eine "leeres" Programm (nacktes Formular) erstellt und - siehe da - das gleiche Problem (hat also mit meinem Programmierinhalt gar nichts zu tun).

Inwiefern zwei meiner vier 32-Bit-NTx-Windows nun eine "Macke" haben, ist fraglich und so nicht ermittelbar. Früher, mit Compilaten früherer Delph-Compiler, gab es derlei Schwierigkeiten nie. Läßt sich also vortrefflich streiten, wer nun Schuld hat bzw. schuld ist. Das StringGrid hat auf einem XP (dort, wo mein Programm läuft) bei der Zeilenselektion den Effekt, daß die Zeile nicht etwa dunkelblau hinterlegt wird, sondern weiß wird und die Zelleninhalte verbirgt. Graphiktreiberproblem? Auch so etwas hatte ich mit früher erstellten Compilaten noch nie. Kurzum, ich bleibe dabei: Am XE2 wird vermutlich noch etwas oder gar einiges nachzubessern sein.

[Union]

Zitat:

Zitat von Delphi-Laie (Beitrag 1122387)

Das StringGrid hat auf einem XP (dort, wo mein Programm läuft) bei der Zeilenselektion den Effekt, daß die Zeile nicht etwa dunkelblau hinterlegt wird, sondern weiß wird und die Zelleninhalte verbirgt

Kann ich leider bestätigen bei 5.1.2600 SP3, bei 6.1.7601 SP1 geht es.

[Delphi-Laie]

Zitat:

Zitat von Union (Beitrag 1122392)

Zitat:

Zitat von Delphi-Laie (Beitrag 1122387)

Das StringGrid hat auf einem XP (dort, wo mein Programm läuft) bei der Zeilenselektion den Effekt, daß die Zeile nicht etwa dunkelblau hinterlegt wird, sondern weiß wird und die Zelleninhalte verbirgt

Kann ich leider bestätigen bei 5.1.2600 SP3, bei 6.1.7601 SP1 geht es.

Wie schon gesagt, habe ich auch nur auf EINEM der beiden Windows, auf dem mein Programm läuft. Unter 2000 funktioniert es tadellos, unter XP SP3 hat es dieses Problem. Vielleicht liegt irgendeine Inkompatibilität mit den ATI-Graphikkartentreiber vor?