Delphi 64

[DSCHUCH]

Es scheint ernst zu werden:

http://www.delphideveloperdays.com/descriptions.html

Day 2
8:30am - 9:15am 64-Bit Delphi Preview
Marco Cantù and Cary Jensen

[Daniel]

Ich will schwer hoffen, dass es ernster wird, aber: Marco Cantú und Cary Jensen sind "nur" zwei externe Freelancer - extrem gut informiert, aber dennoch keine EMBT-Mitarbeiter. Previews des 64bit-Compilers gab es zuletzt (?) auf den Delphi-Tagen und die waren damals noch nicht spektakulär im eigentlichen Sinne. Mittlerweile gab es auf Twitter und diversen Blog-Einträgen eine Reihe an Informationen, wie sich die 64bit-Welt hinsichtlich der Datentypen wohl darstellen wird und diese Infos werden in der von Dir verlinkten Session wohl vorgetragen.

Ich will das gar nicht schlecht reden - je schneller und besser dieses Projekt voranschreitet, desto lieber ist mir das. Ich würde jedoch keine zu hohen Erwartungen an diese eine Veranstaltung hängen.

[Sir Rufo]

Da seit XE die Default-Voreinstellungen für das Ausgabeverzeichnis

Code:

.\$(Config)\$(Platform)

ist, was sich dann z.B. so darstellt

Code:

.\DEBUG\Win32

lässt auch darauf schließen, dass es langsam ernst wird mit x64 (oder auch OSX).

Schön wäre es ja :)

[Assarbad]

Jetzt bin ich aber gespannt wie ein Flitzebogen was da alles zutage kommen wird.

Im Speziellen interessiert mich das Format welches für die Debugsymbole benutzt werden wird.

[Dezipaitor]

Vielleicht ist ja etwas durcheinandergekommen? :lol:

Code:

.\DEBUG\Win16

[Lemmy]

Hi,

Zitat:

Zitat von Daniel (Beitrag 1078719)

Ich will schwer hoffen, dass es ernster wird, ...
Ich will das gar nicht schlecht reden - je schneller und besser dieses Projekt voranschreitet, desto lieber ist mir das. Ich würde jedoch keine zu hohen Erwartungen an diese eine Veranstaltung hängen.

also ich weiß nicht, aber wenn ich das hier lese:
http://www.delphipraxis.net/1075511-post230.html

Zitat:

So ist auch der 64-Bit Compiler seit einigen Jahren in der Entwicklung. Mittlerweile können wir abschätzen, dass er denn auch wirklich dieses Jahr kommen wird

Zumindest bei der kostengünstigen Edition hat er Wort gehalten - warum denn dann nicht auch bei der 64Bit Version? Hier hat Borland über Codegear bis zu Embarcadero schon jedes Management mal ins Klo gegriffen, deshalb gehe ich davon aus, dass ME eine solche Aussage nur dann macht, wenn der 64 bit Compiler definitiv und spätestens am 31.12.2011 verfügbar sein wird...

Die einzige Frage bleibt: Was kann er dann wirklich und ist er für Feld-Wald-Wiesenprogramme anwendbar, sprich: hat er eine akzeptable Qualität, Stabilität und Performance...

Grüße

[Daniel]

Oh, da habe ich mich wohl missverständlich ausgedrückt: Ich wollte Matthias nicht auf die Füße steigen.

Ich teile Deine Einschätzung, dass der 64bit-Compiler aller Voraussicht nach in einer ersten Version dieses Jahr erscheinen wird und hoffe ebenfalls, dass das Dingens sich als stabil genug für einen produktiven Einsatz erweisen wird.

Nur sehe ich die Tatsache, dass es im Frühjahr einen Vortrag zu dem Thema gibt, jetzt nicht als Kriterium für den Grad der Fertigstellung dieses Compilers an. Mehr wollte ich gar nicht zum Ausdruck bringen. Anders wäre es, wenn wir dieses Thema auf den Veranstaltungen von EMBT sehen würden. Und wenn das vor den Delphi-Tagen was wird, fände ich das cool.

[Chemiker]

Hallo,

Zitat:

Und wenn das vor den Delphi-Tagen was wird, fände ich das cool.

Abwarten und Tee trinken, ich glaube erst dran, wenn ich in auf meinem eigenen Bildschirm sehe.

Bis bald Chemiker

[himitsu]

Zitat:

Und wenn das vor den Delphi-Tagen was wird, fände ich das cool.

Oder als Veröffentlichung auf den DT. :stupid:

[Insider2004]

Zitat:

Zitat von Lemmy (Beitrag 1078825)

Hi,
deshalb gehe ich davon aus, dass ME eine solche Aussage nur dann macht, wenn der 64 bit Compiler definitiv und spätestens am 31.12.2011 verfügbar sein wird...

Delphi kommt neuerdings immer Ende August raus...
Das könnte knapp werden.
Und Delphi OS-X ist auch noch in der Röhre.

[joachimd]

Zitat:

Zitat von Daniel (Beitrag 1078828)

Nur sehe ich die Tatsache, dass es im Frühjahr einen Vortrag zu dem Thema gibt, jetzt nicht als Kriterium für den Grad der Fertigstellung dieses Compilers an.

Zumindest konnte man vor nicht allzulanger Zeit lesen, dass 64Bit eingecheckt wurde ... und damit so gut wie fertig ist.

[s.h.a.r.k]

Zitat:

Zitat von Sir Rufo (Beitrag 1078782)

Da seit XE die Default-Voreinstellungen für das Ausgabeverzeichnis

Code:

.\$(Config)\$(Platform)

ist, was sich dann z.B. so darstellt

Code:

.\DEBUG\Win32

lässt auch darauf schließen, dass es langsam ernst wird mit x64 (oder auch OSX).

Schön wäre es ja :)

Hab auch mal die Source in der XE-Version durchgeschaut und da sind schon einige Stellen bzgl. OS X und Posix drin. Kleiner Auszug aus der SysUtils:

Delphi-Quellcode:

{$IFDEF MSWINDOWS}
  Windows,
{$ENDIF MSWINDOWS}
{$IFDEF POSIX}
  Types, PosixBase, PosixDirent, PosixDlfcn, PosixFcntl, PosixErrno, PosixLanginfo,
  PosixLocale, PosixPthread, PosixSignal, PosixStdio, PosixStdlib, PosixString,
  PosixSysStat, PosixSysTime, PosixSysTypes, PosixTime, PosixUnistd, PosixUtime,
  PosixWchar, PosixWctype, PosixWordexp, PosixGlue, PosixTodo, PosixIconv, Unwinder,
{$ENDIF POSIX}
{$IFDEF MACOS}
  Mach, CoreServices, CoreFoundation,
{$ENDIF MACOS}
  SysConst;

{ If defined, we enable O/S hardware exception handling support on POSIX platforms
  that support it. }
{$IF Defined(LINUX) or Defined(MACOS)}
{$DEFINE ENABLE_SIGNAL_HANDLING}
{$IFEND LINUX or MACOS}

[Memnarch]

Naja, Delphi2010 beinhaltet auch auch schon Switches und einstellungen in der SysUtils für Linux/MacOSx + Posix.

PS: Wobei der Uses abschnitt bei weitem nicht so umfangreich ist.

[Florian Hämmerle]

Das wieder etwas vorwärts geht, hat man ja mit dem Release der Starter Edition gesehen. Die schon früher im Thread genannten Auffälligkeiten ($(Platform), uses-Abschnitt mit neuen Direktiven, etc.) deuten mal darauf hin, dass 64 im Werden ist. Schön wäre es natürlich, wenn 2011 noch etwas davon zu sehen ist. Und wenn es nur eine Preview ist, und dann 2012 Delphi mit 64 / Mac / etc. ausgeliefert wird, bin ich schon mehr als zufrieden ;)
Dann würde ich mich vielleicht auch dazu hinreißen lassen, mal etwas tiefer in die Geldtasche zu greifen um mir ein neues Delphi zuzulegen.

mfg Florian

[divBy0]

XE habe ich übersprungen, da mir mein D2010 ausreicht. Wenn aber 64-Bit und Cross-Plattform kommt, dann hole ich mir auf jeden Fall das Update. :thumb:

[mkinzler]

Zitat:

Schön wäre es natürlich, wenn 2011 noch etwas davon zu sehen ist. Und wenn es nur eine Preview ist, und dann 2012 Delphi mit 64 / Mac / etc. ausgeliefert wird

Das sollte schon 2011 mit XE2 der Fall sein

[michaelthuma]

Mit kleinen Einschränkungen im inline Assembler Eck ... aber ansonsten schaut es mal von den kommunizieren Inhalten mal sauber aus für diesen Herbst mit ein paar Ecken und Kanten die viele nicht mitbekommen werden. Final ist schon 2012, dann solls aber ganz ganz reibungslos auch mit 64bit Linux und Apple sein. Denn 32bit OS/X ist wenig in der Praxis und Linux nicht mal wirklich, obwohl dort keinen 32bit ärgern ... Für Windows wird das heuer brauchbar sein ... es wird schon langsam eng auf der Serverseite kann schon mit Server 2008 R2 ohne 32bit Subsystem installiert werden ... 2 Jahre sitzt das keiner mehr aus... aber inline Assembler gemischt mit Pascal Code braucht jetzt mal urgent keiner ... schön wäre noch wenn wenigstens eine ganze Prozedur in Assembler ginge ... angeblich läuft die Preview schon im engern Kreis ...

Zitat:

Zitat von mkinzler (Beitrag 1079295)

Zitat:

Schön wäre es natürlich, wenn 2011 noch etwas davon zu sehen ist. Und wenn es nur eine Preview ist, und dann 2012 Delphi mit 64 / Mac / etc. ausgeliefert wird

Das sollte schon 2011 mit XE2 der Fall sein

[QuickAndDirty]

@Michael: Woher weißt du das?

P.S.: Kann es sein das ich dich auf Englisch besser verstanden habe? (QuickAndDirty aka AndrewBranch)

[vagtler]

Zitat:

Zitat von QuickAndDirty (Beitrag 1079360)

[...] P.S.: Kann es sein das ich dich auf Englisch besser verstanden habe? [...]

Was jetzt nicht sonderlich verwunderlich wäre... ;)

[Robotiker]

Zitat:

Zitat von Memnarch (Beitrag 1079258)

Naja, Delphi2010 beinhaltet auch auch schon Switches und einstellungen in der SysUtils für Linux/MacOSx + Posix.

Und offenbar tut sich auch etwas an der Oberfläche, man war mal wieder auf Einkaufstour:
http://www.ksdev.com/

Sieht in der Tat so aus, als ob wir in zukünftigen Versionen eine Art WPF-ähnlicher GUI kriegen.

Allerdings dürften sich die heutigen Anwender dieser Komponenten nicht unbedingt darüber freuen, dass man die quasi vom Markt nimmt.

Edit mkinzler: Hierzu gibt es jetzt auch einen eigene Thread

[Dezipaitor]

Ich kann nur raten vorsichtig mit der ersten 64bit Version von Delphi zu sein. Die Entwickler haben vermutlich noch nicht genug Praxiserfahrung sammeln können, um wirklich ein für alle stabiles Produkt zu entwickeln. Zudem kann ich nur betonen, dass nur wenige Entwickler eine 64bit Version von ihrer Software benötigen (z.B. DB, Shell).

Eine weitere große Frage steht auch noch im Raum:

Wer portiert und testet die OpenSource Projekte? Also z.B. JCL/JVCL, Indy, JEDI API usw.
Ich kann mir nicht vorstellen, dass diese Projekte sofort mit der 64bit Version kompilieren und andstandlos funktionieren (einige haben Assembler, Zeigermanipulationen und andere 32bit Speicherausrichtungen). Für JEDI API kann ich sprechen und sie wird auf keinen Fall funktionieren, noch wird es möglich sein tausende von Funktionen und Strukturen für 64bit per Hand anzupassen.

Die Umstellung von eigenen Projekten wird daher auf jeden Fall viel Zeit, Aufwand, Stress und Geld kosten. Man sollte sich überlege, ob man 64Bit wirklich benötigt.

[Florian Hämmerle]

Ich denke, dass es in Firmen dann eben nicht wie bisher die Überlegung "Sollen wir von delphi auf C# / Java, etc. wechseln?" geben wird, sondern: "Sollen wir von Delphi32 auf Delphi-CrossCompiler wechseln?"

mfg Florian

[mkinzler]

Also kann sich Embarcadero weitere x Jahre Zeit lassen und sich auf wichtigere Entwicklungen, wie Skinning usw. konzentrieren. :mrgreen:

Zitat:

Eine weitere große Frage steht auch noch im Raum:

Wer portiert und testet die OpenSource Projekte? Also z.B. JCL/JVCL, Indy, JEDI API usw.

Deshalb ist imho deren recht verschlossene Politik bezüglich der Umstellung auch so schlecht. Hin und wieder liesat man hier und da Widersprüchliches, werden hier und da ein paar Details gesagt, welche ohne aber den ganzen Zusammenhang wenig aussagekräftig sind.

Zudem wird ja nicht von einem 32Bit auf einen 64Bit-Compiler umgestellt, sondern es wird zusätzlich einen für 64Bit geben.

[Dezipaitor]

Zitat:

Zitat von mkinzler (Beitrag 1079825)

Zudem wird ja nicht von einem 32Bit auf einen 64Bit-Compiler umgestellt, sondern es wird zusätzlich einen für 64Bit geben.

Trotzdem kann ich voraussagen, dass 64Bit als der Hauptgrund herausgestellt wird, um das neue Delphi zu kaufen. Doch viele Programmierer werden es garnicht benötigen und sich trotzdem gedrängt fühlen ihre Projekte mit viel Aufwand anzupassen, weil doch alle nun 64Bit benutzen.

Ich denke wir sollten eine Auflistung von Gründen machen, die genau ausführen, wann man als Entwickler/Projektleiter wirklich auf 64Bit umsteigen muss/sollte:

• Shellkomponenten für Windows 64Bit Explorer werden entwickelt (es reicht die DLL selbst als 64Bit zu verwenden. Nicht das gesamte Projekt)
• Allgemeine Plugins entwickeln für Dritthersteller (z.B. Photoshop, Windows Sidebar) (Kann die Beispiele jemand bestätigen?)
• Wenn man eigene Datenbanksysteme entwickelt oder in Delphi geschrieben DBSysteme verwendet und wirklich große Mengen an Datensätzen verwaltet oder sehr große Mengen an Anfragen bearbeitet werden müssen.
• Wissenschaftliche Berechnungen und Simulationen
• Wenn man den 3GB Schalter bereits benutzt
• Wenn man seinen Speicher selbst verwaltet (um mehr als 4GB ansprechen zu können durch Auslagerung)

Bitte fortführen...

[nytaiceman]

Für mich interessant wäre die Möglichkeit, für Windows PE 64bit zu programmieren.
Oder auch der "direkte" Zugriff auf die 64bit Registry (Ohne Umweg über SystemRedirection etc.)

Aber bis Delphi endlich für 64bit genutzt werden kann, gilt es halt zu warten.

[Chemiker]

Hallo Dezipaitor,

normaler weise brauchen die wenigsten User 32 Bit, die meisten würden auch mit 16Bit weiter arbeiten können. Ich schreibe meine Briefe in Office 2010 genauso wie vor 10 - 15Jahren mit Wordperfect auch die Tabellenkalkulation habe ich vor 10-15 Jahren mit Lotus 1,2,3 gemacht. Ich kann noch nicht einmal sagen welche Funktion ich jetzt brauche die es vor 10 – 15 Jahren nicht gab.

Die ganze Diskussion ist müßig und ist im Grunde schon bei der Umstellung von 16Bit auf 32 Bit geführt worden.

Da Du aktiv an den Jedis mitarbeitest ist die Umstellung natürlich hart, aber sie wäre auch in 2 Jahren nicht so ohne weiteres möglich. Irgendwann muss man eben einen Schnitt machen, wenn nicht jetzt wann dann?

Bis bald Chemiker

[mkinzler]

Wenn man noch ein Weilchen wartet ( seite EM) dann ist die Umstellung überflüssig ...

[cookie22]

Zitat:

Zitat von Dezipaitor (Beitrag 1080016)

Zitat:

Zitat von mkinzler (Beitrag 1079825)

Zudem wird ja nicht von einem 32Bit auf einen 64Bit-Compiler umgestellt, sondern es wird zusätzlich einen für 64Bit geben.

Trotzdem kann ich voraussagen, dass 64Bit als der Hauptgrund herausgestellt wird, um das neue Delphi zu kaufen. Doch viele Programmierer werden es garnicht benötigen und sich trotzdem gedrängt fühlen ihre Projekte mit viel Aufwand anzupassen, weil doch alle nun 64Bit benutzen.

Ich denke wir sollten eine Auflistung von Gründen machen, die genau ausführen, wann man als Entwickler/Projektleiter wirklich auf 64Bit umsteigen muss/sollte:

• Shellkomponenten für Windows 64Bit Explorer werden entwickelt (es reicht die DLL selbst als 64Bit zu verwenden. Nicht das gesamte Projekt)
• Allgemeine Plugins entwickeln für Dritthersteller (z.B. Photoshop, Windows Sidebar) (Kann die Beispiele jemand bestätigen?)
• Wenn man eigene Datenbanksysteme entwickelt oder in Delphi geschrieben DBSysteme verwendet und wirklich große Mengen an Datensätzen verwaltet oder sehr große Mengen an Anfragen bearbeitet werden müssen.
• Wissenschaftliche Berechnungen und Simulationen
• Wenn man den 3GB Schalter bereits benutzt
• Wenn man seinen Speicher selbst verwaltet (um mehr als 4GB ansprechen zu können durch Auslagerung)

Bitte fortführen...

Man kann sich auch mit Gewalt neuen Technologien verschließen. Seit mittlerweile 5 Jahren ist X64 Standard.

Wer jetzt nicht auf Unicode und X64 setzt wird in wenigen jahen keine konkurrenzfähige Software verkaufen können und seht dann wie der Ox vorm Berg, weil man zu spät umgestellt hat.

Der Hauptgrund für einen 64Bit Compiler ist doch, dass mittlerweile mehr als die hälfte der Leute 64Bit fähige Computer haben. Alleine das reicht schon. Viele Leute wollen 64Bit Programme einfach nur weil sie glauben sie laufen schneller, stabiler oder was auch immer. Bring denen mal bei, dass dein 32Bit genauso gut ist. Die kaufen dann wo anderes, nämlich bei jemandem der 64Bit unterstützt.

Um die liste zu vervollständigen.

• Ohne 64Bit Support verliert man ein komplettes Marktsegment.

[Dezipaitor]

Zitat:

Zitat von Chemiker (Beitrag 1080099)

Hallo Dezipaitor,

normaler weise brauchen die wenigsten User 32 Bit, die meisten würden auch mit 16Bit weiter arbeiten können. Ich schreibe meine Briefe in Office 2010 genauso wie vor 10 - 15Jahren mit Wordperfect auch die Tabellenkalkulation habe ich vor 10-15 Jahren mit Lotus 1,2,3 gemacht. Ich kann noch nicht einmal sagen welche Funktion ich jetzt brauche die es vor 10 – 15 Jahren nicht gab.

Fange doch nicht bei Adam und Eva an. Deine Briefe könntest du genauso mit der Hand schreiben, wenn es denn sein muss.

Zitat:

Zitat von Chemiker (Beitrag 1080099)

Die ganze Diskussion ist müßig und ist im Grunde schon bei der Umstellung von 16Bit auf 32 Bit geführt worden.

Aber die Diskussion muss immer wieder geführt werden. Schließlich generiert eine Umstellung beträchtliche Kosten und erzeugt neue Fehlerquellen. Deshalb und auch weil Windows 64Bit noch Jahrelang 32Bit unterstützen wird (16Bit wurde ja auch noch unterstützt, zumindest bei 32Bit Windows) müssen die Entwickler informiert werden, dass nicht alles gekauft werden muss, was angeboten wird.
Ich sehe voraus, dass 32Bit in diesem Jahrzehnt noch lange nicht ausgedient haben wird.

Zitat:

Zitat von Chemiker (Beitrag 1080099)

Da Du aktiv an den Jedis mitarbeitest ist die Umstellung natürlich hart, aber sie wäre auch in 2 Jahren nicht so ohne weiteres möglich. Irgendwann muss man eben einen Schnitt machen, wenn nicht jetzt wann dann?
Bis bald Chemiker

Wie soll das gehen? Einen Schnitt machen? Da verlieren wir doch alle Zeit und Geld an den alten Komponenten. Wie groß war denn der Aufschrei als PCHAR plötzlich zu PWideChar wurde? Kein zurück mehr auf Ansi.

Zitat:

Zitat von nytaiceman (Beitrag 1080064)

Für mich interessant wäre die Möglichkeit, für Windows PE 64bit zu programmieren.
Oder auch der "direkte" Zugriff auf die 64bit Registry (Ohne Umweg über SystemRedirection etc.)

Aber bis Delphi endlich für 64bit genutzt werden kann, gilt es halt zu warten.

Man kann Redirektion von Anfang an ausschalten.

Zitat:

Zitat von cookie22 (Beitrag 1080110)

Man kann sich auch mit Gewalt neuen Technologien verschließen. Seit mittlerweile 5 Jahren ist X64 Standard.

Wer jetzt nicht auf Unicode und X64 setzt wird in wenigen jahen keine konkurrenzfähige Software verkaufen können und seht dann wie der Ox vorm Berg, weil man zu spät umgestellt hat.

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?

Ich rede allerdings nicht von Neuentwicklungen! Darum geht es nicht.

Zitat:

Zitat von cookie22 (Beitrag 1080110)

Der Hauptgrund für einen 64Bit Compiler ist doch, dass mittlerweile mehr als die hälfte der Leute 64Bit fähige Computer haben. Alleine das reicht schon. Viele Leute wollen 64Bit Programme einfach nur weil sie glauben sie laufen schneller, stabiler oder was auch immer. Bring denen mal bei, dass dein 32Bit genauso gut ist. Die kaufen dann wo anderes, nämlich bei jemandem der 64Bit unterstützt.

Hast du dazu eine Studie gemacht oder woher kommt diese Einschätzung? Würde mich interessieren. Wenn ein Produkt angeblich deshalb nicht mehr gekauft wird, weil es kein 64Bit ist, dann frage ich mich vielmehr ob das Problem nicht eher am Produkt selbst liegt als an der Plattform.

Zitat:

Zitat von cookie22 (Beitrag 1080110)

Um die liste zu vervollständigen.

• Ohne 64Bit Support verliert man ein komplettes Marktsegment.

Welches Segment ist das genau? Alle Kunden, die im Irrglaube sind 32Bit Anwendungen wären schlechter als 64Bit Anwendungen? Dass es solche Kunden gibt, spreche ich dir nicht ab, jedoch sind nur wenige Delphientwickler wirklich davon betroffen, denn ihre 32Bit Anwendungen laufen transparent auch auf 64Bit Windows Systemen. Und das lange Zeit.


Letztendlich muss man genau abwägen, ob es sich wirklich lohnt aktuelle Anwendungen auf 64Bit zu portieren. Besonders bei Delphi nutzen Projekte doch auch viele Drittherstellerkomponenten, die nicht unbedingt sofort als 64Bit Code funktionieren. Der Aufwand wäre besser in die Qualitätssicherung gesteckt als in die oftmals unnötige 64Bit Portierung.
Daher hatte ich die Idee ein paar Gründe für die Portierung aufzustellen. Das heißt aber nicht, dass ich generell gegen 64Bit wäre! Ich bin nur Realist.

Wer den Aufwand und die Kosten nicht scheut, den werde ich nicht davon abhalten sein Projekt zu portieren. Ich wollte nur als Orientierung dienen.

[p80286]

Zitat:

Zitat von cookie22 (Beitrag 1080110)

Viele Leute wollen 64Bit Programme einfach nur weil sie glauben sie laufen schneller, stabiler oder was auch immer. Bring denen mal bei, dass dein 32Bit genauso gut ist.

Dumme Frage, "Ist das nicht so?"
Nach der Faustformel je größer die Register, desto schneller die Verarbeitung, hat zumindestens bei der 16/32Bit-Umstellung gestimmt.

Was den Unicode angeht, solange auch heute noch das eine oder andere Programm Umlaut-Unfähig ist, (ein paar sind auch mit 8Bit darstellbar), solange wird es auch keine "selbstverständliche" Unicodeunterstützung geben.

Gruß
K-H

[cookie22]

Zitat:

Zitat von Dezipaitor (Beitrag 1080126)

Welches Segment ist das genau? Alle Kunden, die im Irrglaube sind 32Bit Anwendungen wären schlechter als 64Bit Anwendungen? Dass es solche Kunden gibt, spreche ich dir nicht ab, jedoch sind nur wenige Delphientwickler wirklich davon betroffen, denn ihre 32Bit Anwendungen laufen transparent auch auf 64Bit Windows Systemen. Und das lange Zeit.

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.

Zitat:

Zitat von Dezipaitor (Beitrag 1080126)

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.

[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. Es gibt Datentypen die sind veränderlich und es gibt fixe Datentypen. Und das muss man beim Programmieren berücksichtigen. Ein Integer ist je nach Plattform 16,32 oder in Zukunft 64-Bittig. Ein string war unter 16Bit 255 Zeichen lang unter 32Bit schon bedeutend länger und jetzt ist es eben Unicode. Also einmal an die eigene Nase fassen, tief durchatmen und zukünftig die Flexibilität dieser Datentypen berücksichtigen. Was bin ich froh, daß ein Integer damals von 16 auf 32-Bit mitgewachsen ist. Wenn ich mir vorstelle, daß ich jedes intege in ein 32-Bit integer hätte umwandelm müssen, dann wäre das garantiert mehr Arbeit gewesen, als die potenziellen Fehlerhaft deklariereten Integers, die 16Bit sein "müssen". Das gleich gilt auch für strings. Ein Großteil meines Codes arbeitet automatisch mit Unicode und funktioniert. An den stellen, wo es nicht funktioniert war es meine Schulde und ich muss nacharbeiten. Pech. Wäre der String ein Ansistring geblieben, dann wäre es wesentlich mehr arbeit, alles auf Unicode umzustellen. Also alles mal ganz locker sehen. ;-)

[himitsu]

Zitat:

Ein Integer ist je nach Plattform 16,32 oder in Zukunft 64-Bittig

Falsch (liegt aber nicht an dir)

Microsoft hat sich gedacht, sie lassen den Integer in ihrem 64 Bit-Compiler einfach 32 Bit klein und führen stattdessen einen neuen 64-Bit-Integer-Typen ein. :wall:
Und Emba wird das vermutlich genauso bescheuert nachmachen.

[mkinzler]

Zitat:

Zitat von bernau (Beitrag 1080144)

Ein Integer ist je nach Plattform 16,32 oder in Zukunft 64-Bittig.

Eben nicht.

Zitat:

Zitat:

Ein string war unter 16Bit 255 Zeichen lang unter 32Bit schon bedeutend länger und jetzt ist es eben Unicode.

Nein, ein ShortString war 255Bit ein String = AnsiString war schon immer länger.
Also einmal an die eigene Nase fassen, tief durchatmen und zukünftig die Flexibilität dieser Datentypen berücksichtigen.

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.

[Chemiker]

Hallo,

Zitat:

Zitat von Dezipaitor

Fange doch nicht bei Adam und Eva an. Deine Briefe könntest du genauso mit der Hand schreiben, wenn es denn sein muss.
Schließlich generiert eine Umstellung beträchtliche Kosten und erzeugt neue Fehlerquellen. Deshalb und auch weil Windows 64Bit noch Jahrelang 32Bit unterstützen wird (16Bit wurde ja auch noch unterstützt, zumindest bei 32Bit Windows) müssen die Entwickler informiert werden, dass nicht alles gekauft werden muss, was angeboten wird.

ich habe ja schon indirekt geschrieben, dass ich selbst mit den 16Bit Anwendungen noch heute wahrscheinlich arbeiten könnte, ehrlich gesagt wenn es nach mir gehen würde ich komme auch ohne Probleme mit 32 Bit zurecht, aber Stillstand bedeutet Rückschritt.

Zitat:

Zitat von Dezipaitor

Ich sehe voraus, dass 32Bit in diesem Jahrzehnt noch lange nicht ausgedient haben wird.

Das wäre sehr schön, dann haben wir mehr Zeit für die Umstellung. Meine Befürchtung ist aber, dass es Plötzlich ganz schnell gehen kann. Ich sehe voraus, dass wenn die Wirtschaft in Deutschland weiter wie zur Zeit brummt, dass kurz vor Jahreswechsel einige Fa. auf 64Bit umstellen werden die bis jetzt den Schritt aus Kostengründen nicht vollzogen haben, um nicht zu viel Steuern zu bezahlen.

Zitat:

Zitat von Dezipaitor

Ich rede allerdings nicht von Neuentwicklungen! Darum geht es nicht.

Aber wie willst Du eine Neuentwicklung ohne 64Bit Compiler durchführen?

Zitat:

Zitat von Dezipaitor

Daher hatte ich die Idee ein paar Gründe für die Portierung aufzustellen. Das heißt aber nicht, dass ich generell gegen 64Bit wäre! Ich bin nur Realist.

Das ist eine sehr gute Idee!
Für die Liste:
Zusammenarbeit zwischen Delphi und MSOffice 64Bit zurzeit werden beide Versionen also 32 und 64Bit von MS ausgeliefert.
Und hier muss ich nicht nur eine Portierung auf 64Bit realisieren, sondern arbeite jetzt schon mit VS C++64Bit damit ich nicht auf den Trockenen stehe, wenn es Emba. nicht schafft einen 64Compiler dieses Jahr auf den Markt zu bringen.
Vielleicht sollte man in diesem Zusammenhang auch darüber nachdenken, wie man bis zum Erscheinen des 64bit Delphi mit den Datentypen umgeht. Ich zum Beispiel habe mir eine Unit gemacht und schreibe mir meine eigenen Datentypen da rein, die ich dann anschließend in den Projekten nur einbinde, ob das sinnvoll ist weis ich nicht, aber es schont die Nerven. Solange ich keine sicheren Informationen habe wie die einzelnen Datentype später aussehen sollen.

Bis bald Chemiker

[Assarbad]

Zitat:

Zitat von himitsu (Beitrag 1080154)

Zitat:

Ein Integer ist je nach Plattform 16,32 oder in Zukunft 64-Bittig

Falsch (liegt aber nicht an dir)

Microsoft hat sich gedacht, sie lassen den Integer in ihrem 64 Bit-Compiler einfach 32 Bit klein und führen stattdessen einen neuen 64-Bit-Integer-Typen ein. :wall:
Und Emba wird das vermutlich genauso bescheuert nachmachen.

Aha? Solche Halbwahrheiten kann ich nicht stehenlassen:

Zitat:

Zitat von http://de.wikipedia.org/wiki/Integer_(Datentyp)#H.C3.A4ufige_Speicherformen

Ein Integer besteht in der Regel aus 8, 16, 32, 64 oder 128 Bits (also 1, 2, 4, 8 oder 16 Bytes) – entsprechend der Wortbreite der jeweiligen CPU. Historisch wurden auch andere Werte (12, 48, … Bit) verwendet. In Programmiersprachen sind die Bezeichnungen dieser Zahlen teilweise genormt: In Java werden sie als byte (8), short (16), int (32) und long (64 Bit) bezeichnet. In C gibt es dieselben Bezeichnungen, jedoch sind die Größen architekturabhängig, mit C99 wurden architekturunabhängige Typen definiert (stdint.h). Dafür unterstützt C auch die vorzeichenlose (unsigned) Variante, die von den meisten Mikrocontrollern und Mikroprozessoren in Hardware unterstützt werden.

Also mach dich mal locker und mach nicht MS für alles Schlechte in der Welt verantwortlich ...

Selbst ein Byte ist nicht auf allen Architekturen 8 Bit breit, nur um mit diesem Vorurteil auch aufzuräumen. Aus diesem Grund wird in Protokollen oder anderen Spezifikationen gern der Begriff "Oktett" (engl. octet) verwendet.

Zitat:

Zitat von Chemiker (Beitrag 1080169)

Aber wie willst Du eine Neuentwicklung ohne 64Bit Compiler durchführen?

Ein erster Schritt hätte sein können, daß die Spezifikation für den Compiler schon bei Ankündigung veröffentlicht worden wäre und daß entsprechende Warnungen hätten aktiviert werden können (wäre auch für die Unicode-Umstellung m.M.n. notwendig gewesen).

Zitat:

Zitat von Chemiker (Beitrag 1080169)

Ich zum Beispiel habe mir eine Unit gemacht und schreibe mir meine eigenen Datentypen da rein, die ich dann anschließend in den Projekten nur einbinde, ob das sinnvoll ist weis ich nicht, aber es schont die Nerven. Solange ich keine sicheren Informationen habe wie die einzelnen Datentype später aussehen sollen.

Das ist ohnehin immer besser, obwohl sicherlich in der behüteten Monokultur "Delphi" der Bedarf für diese Abstraktion selten sichtbar wurde. Wenn man aber obige Aussagen zu den Datentypen nimmt, sollte klar sein, wieso viele Leute Headerdateien pflegen in denen für spezielle Compiler und Platformen die jeweilige ("korrekte") Typisierung mit einem bestimmten Namen belegt wird und innerhalb des eigenen Codes benutzt wird. Gut, mit C++ ist das nun überflüssig, aber leider gibt es auch noch eine Menge C-Code der durch den Compiler gejagt wird ... :stupid:

Zitat:

Zitat von mkinzler (Beitrag 1080155)

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.

Die lahmste Ausrede überhaupt. Wenn man betrachtet, daß PChar (oder aufgrund der Unabhängigkeit von Groß-/Kleinschreibung: PCHAR) für lange Jahre in Delphi als einziger Typ war welcher Pointerarithmetik zuließ (ja, bei PBYTE ging das nicht immer ... ich sag nur Delphi 4) und sich dann betrachtet, daß die "tolle" Unicodeumstellung PChar einfach mal locker flockig umdefiniert hat und damit jeglichen älteren Code der sich auf Pointerarithmetik verließ mal schön versaut (siehe hier: "Use of PChar() casts to enable pointer arithmetic on non-char based pointer types") ... dann ist die Ausrede "MS hat das so gemacht" an Dreistigkeit kaum zu überbieten.

Und ja, dumm gelaufen daß PCHAR in Turbo Pascal schon existierte und dann zufällig auch als Win32-Typ existierte. Aber die Hauptplattform war und ist Windows.

[himitsu]

Zitat:

Zitat von Assarbad

Aha?

Zitat:

Zitat von mkinzler

weil wohl VS/WinAPI das auch macht.

VS und die WinAPI kommen doch von MS,
also haben die es doch (im Windowssystem) so eingeführt?

Nja, da Emba es nur nachmacht und sie garantiert nicht mit diesem Integer-Chaos, durch ihr (noch) nichtvorhandenes 64-RAD, angefangen haben, sind sie zur Abwechlung mal an nichts Schuld, außer am Mitläufersyndrom. :angle2:

Zitat:

Zitat von Wikipedia

jedoch sind die Größen architekturabhängig

Hmm, also sind nun Intel dran Schuld?
Ich wußte nicht, daß die CPU-Hersteller die "Bezeichnungen" der Typen vorgeben. :shock:

Oder heißt das einfach nur "32 Bit-CPU/Architektur = 32 Bit-Integer" und "64 Bit-CPU/Architektur = 64 Bit-Integer" ?
Demnach müßte der Integer ja auf 64 Bit anwachsen. :stupid:

[Bernhard Geyer]

Zitat:

Zitat von cookie22 (Beitrag 1080110)

Wer jetzt nicht auf Unicode .. setzt wird in wenigen jahen keine konkurrenzfähige Software verkaufen können

In unseren Segment ist für einige Kunden Unicode schon seit Jahren zwingend notwendig. Glücklicherweise konnte ich mit dem ElPack, XDOM und diversen anderen Kompos schon seit 2002 die nötigen Kundenanforderungen umsetzen. Ohne das wäre es mit Codepages/Charsets um Welten schwieriger geworden ...
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.

Das Borland den "normalen" Weg geht und int bei 32-Bit lässt ist m.E. vollkommen ok. Damit muss man sich bei Kommunikation mit .NET/Java/WinAPI nicht jedesmal fragen ob nun integer ein 32-Bit oder 64-Bit darstellt. Hätte man die bisherige Logik weiter gefahren hätte man bei jeder API-Portierung das nicht vergessen dürfen.

[himitsu]

Da man für Delphi/Pascal die Typen eh konvertieren muß, bzw. Delphi für einige C-Typen schon übersetzungen mitliefert, hätte man das da mit einbauen können und dann INT zu LongInt gemacht ... soooooo viel mehr hätte man da nun auch nicht zusätzlich denken müssen. :angle2:
Aber OK.

Jetzt an diesem 32 Bit-Integer was ändern zu wollen ... ist eh zu spät dafür (wo dieses ja schon vor sehr vielen Jahren entschieden wurde, ohne die Delphianer zu fragen ... wozu auch, wir konnten/können eh nicht mitreden)

[Assarbad]

Zitat:

Zitat von himitsu (Beitrag 1080189)

VS und die WinAPI kommen doch von MS,
also haben die es doch (im Windowssystem) so eingeführt?

Architektur -> PowerPC, MIPS, x86, x64, IA-64 ...

Zitat:

Zitat von himitsu (Beitrag 1080189)

sind sie zur Abwechlung mal an nichts Schuld, außer am Mitläufersyndrom.

Sehe ich anders, siehe meine Antwort auf Markus' apologetisches Argument ;)

Zitat:

Zitat von himitsu (Beitrag 1080189)

Hmm, also sind nun Intel dran Schuld?
Ich wußte nicht, daß die CPU-Hersteller die "Bezeichnungen" der Typen vorgeben.

Intel ist auch ein Compiler-Hersteller, wenn's recht ist ;)

Aber: Nein, es heißt alles nur, daß du die vorige Aussage absolut verneint hast, obwohl diese absolute Verneinung weder angebracht noch korrekt war. Ich habe nicht mehr getan als dies zu berichtigen ... deswegen von meiner Seite auch der Begriff "Halbwahrheiten", weil du um das Argument einzufahren eben die andere "Hälfte" unterschlagen hast ...

Zitat:

Zitat von Bernhard Geyer (Beitrag 1080195)

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?

Zitat:

Zitat von Bernhard Geyer (Beitrag 1080195)

Das Borland den "normalen" Weg geht und int bei 32-Bit lässt ist m.E. vollkommen ok. Damit muss man sich bei Kommunikation mit .NET/Java/WinAPI nicht jedesmal fragen ob nun integer ein 32-Bit oder 64-Bit darstellt.

Ganz richtig. Heimatplattform von Delphi ist und bleibt Win32 (wobei das 32 im Namen nicht als Hinweis auf die Bittigkeit verstanden werden sollte).