Delphi 64

[bernau]

Zitat von mkinzler:

Das Problem ist, dass man sich entschlossen hat Integer bei 32Bit einzufrieren und den festen Typ NativeInt dynamisch zu machen, weil wohl VS/WinAPI das auch macht.

Auch das sollte nicht so tragisch sein. Da wo man es wirklich braucht, kann man ja den entsprechenden Type einsetzen.

[himitsu]

Blöd ist es nur, wenn man in "alten" Codes geziehlt "Integer" geschrieben hat, in dem Glauben man wäre damit zukunftssicher, da dieser mitwächst (was er ja nun nicht mehr macht).

[Bernhard Geyer]

Zitat von Assarbad:

Zitat von Bernhard Geyer:

Der fehlende 64-Bit Compiler verursacht aber auch schon Supportaufwand da für einen Oracle-Zugriff jeder Admin erstmal den 64 NET-Client auf Win64-Systemen installiert und es damit erstmal nicht geht.

Ließe sich das nicht mit Marshaling über ein COM-Objekt beheben, wenn's denn notwendig ist?

IIIIIH COM. Für Oracle ist das glücklicherweise kein Problem wenn man weis was eigentlich abläuft. Schnell mal den 32-Bit Instant-Client per X-Copy "installiert", Umgebungsvariable darauf umgebogen (oder batch-datei erstellt weche die Umgebungsvariable nur für den eigenen Prozess ändert) und gut ist. Hätte Oracle sich für den 64-Bit eine anderen Namen für die Umgebungsvariable ausgesucht könnten 32/64-Bit problemlos ohne Tricks parallel installiert sein.

[Assarbad]

Zitat von himitsu:

Blöd ist es nur, wenn man in "alten" Codes geziehlt "Integer" geschrieben hat, in dem Glauben man wäre damit zukunftssicher, da dieser mitwächst (was er ja nun nicht mehr macht).

Stimmt. Blöd gelaufen. Ist bei meinem alten Code genauso, wo ich davon ausging, daß PChar nicht geändert wird

[bernau]

Zitat von himitsu:

Blöd ist es nur, wenn man in "alten" Codes geziehlt "Integer" geschrieben hat, in dem Glauben man wäre damit zukunftssicher, da dieser mitwächst (was er ja nun nicht mehr macht).

Ja, ist nicht fein. Aber es ist besser, auf änderungen vorbereitet zu sein und diese treffen dann nicht ein, als umgekehrt.

Und dann darüber sich aufzuregen! (Gilt nicht für dich, sondern für die Allgemeinheit.)

[mleyen]

In einem Protokoll hab ich es wie Chemiker gemacht. Eigene Datentypen abstrahiert, die ich nachträglich in einer Zeile ändern kann.
Auch hilfreich für die Abwärtskompabilität:

Delphi-Quellcode:

type
  Int8  = Shortint;
  Int16 = Smallint;
  Int32 = Longint;
  Int64 = System.Int64;

  UInt8  = Byte;
  UInt16 = Word;
  UInt32 = LongWord;
  UInt64 = System.UInt64;
  
{$IF CompilerVersion > 22}
  Int = NativeInt; {In 18.5 = 64}
  UInt = NativeUInt;
{$ELSE}
  Int = Integer;                 
  UInt = Cardinal;
{$IFEND}

[Assarbad]

Zitat von mleyen:

In einem Protokoll hab ich es wie Chemiker gemacht. Eigene Datentypen abstrahiert, die ich nachträglich in einer Zeile ändern kann.

Genau so wird's gemacht

[Dezipaitor]

Zitat von bernau:

Ich verstehe das rumgeschreie nicht. Es ist doch gut, daß es seitens Embarcadero eine Weiterentwicklung gibt. Wenn wir ehrlich sind, liegt es nur an uns Programmierern, wenn die Software mit dem neuen Compiler nicht so funktioniert wie sie sollte.

Nur, dass Borland/CodeGear/EMB damit etwa 5 Jahre zu spät kommt ist wohl Schuld der Programmierer? Man hätte eben schon vorher Schreien müssen.

Zitat von cookie22:

Natürlich die Win64 Nutzer, sei es Vista oder Win7. Die Hälfte der Win7 Nutzer setzen auf 64Bit. Win7-64Bit Verbreitubg. Der Link ist vom Sommer letzten Jahres, mittlerweile sind es sicher einige Prozent mehr.

Und was willst du damit aussagen? Laut dem Chip Artikel :

Zitat:

Als Grund für die starke Verbreitung des 64-Bit-Windows nennt Microsoft die günstigen RAM-Preise der Vergangenheit. Kunden hätten deshalb vermehrt zu Rechnern mit 4 oder mehr GByte Arbeitsspeicher gegriffen, die sich nur unter einem x64-Betriebssystem problemfrei nutzen lassen

Das bedeutet aber nicht, dass Kunden 64Bit Software fordern! Ich behaupte mal, dass den allermeisten Kunden es egal ist, welche Plattformversion ihrer Software sie bekommen, hauptsache die Software funktioniert so wie sie es wollen.

Zitat von cookie22:

Zitat von Dezipaitor:

Was hat das mit Verschließen zu tun? Es geht um die objektive Einschätzung des Aufwand/Nutzen-Verhältnisses von Übersetzung von 32Bit- auf 64Bit-Anwendungen. Lohnt es sich eine 32Bit-Anwendung, die bis jetzt funktioniert hat nach 64Bit zu übersetzen?

Das hat wohl eine Menge damit zu tun, wie weit dein Programm verbreitet ist und was die Konkurrenz zu bieten hat. Wenn du alleine am Markt bist kannst du den Leuten aufs Auge drücken was du willst, wenn du nicht alleine bist und die Konkurrenz 64Bit hat, wirst du weniger verkaufen.

Mag sein, dass vereinzelte Kunden 64Bit vorziehen. Aber wenn dein Produkt qualitativ besser ist und das Drumherum auch stimmt, dann werden Kunden zu deinem Produkt tendieren. Im Verkauf einer Bibliothek für 32Bit und 64Bit separat, bei der ich dabei bin, haben wir selbst festgestellt, dass immernoch mehr nach 32Bit gefragt wurde als 64Bit. Bei Nachfrage wurde 64Bit als noch nicht notwendig erachtet.
Du kannst mir also nicht sagen, dass "nativ 64Bit" auf der Vorraussetungsliste der Kunden ganz oben steht. Wenn man 64Bit hat, dann kann man es nutzen, aber 32Bit läuft auch noch gut. IMO sind es die Werbeleute, die 64Bit einfach besser finden, weil es sich nach mehr anhört.

Zudem, wenn 64Bit wirklich immer so vorteilhaft wäre, warum spielen viele Spieler noch mit 32Bit (s. Chiplink)? Welche guten oder großartigen Spiele sind nativ 64Bit?

[JoBoCAD]

Hallo Zusammen,

da ihr gerade sehr tief in dem Thema 64 Bit seid stelle ich dem Forum eine eher simple Frage die für mich als
"Kleinstanwender/Programmierer" dennoch eine Große ist.

Ich arbeite derzeit auf XP mit Delphi 2005 XE.

Kann ich mit dieser DelphiVersion auch auf Windows 7 installieren und arbeiten.
Laufen meine bisherigen Programme die ich unter XP kompiliert habe.

Gruß
Joachim

[DeddyH]

Was denn nun, 2005 oder XE? Obwohl einerlei, beide sollten auch unter Windows 7 laufen, XE auf jeden Fall. Und ob Deine Programme funktionieren wird Dir niemand beantworten können, da wir ja den Code nicht kennen.