Delphi 64

[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).