Fehlerhafte (nur 32-Bit-?)Delphi-XE2-Compilate?

[USchuster]

Der QC Eintrag für den SSE1 Befehl ist QC 99715.

[Daniel]

Danke

[Delphi-Laie]

Das soll jetzt KEIN "Pushen" sein...

Zitat von USchuster:

Der QC Eintrag für den SSE1 Befehl ist QC 99715.

Ja, auch von mir besten Dank für diese Mühe!

Das ist letztlich der zweite Bugreport, der ursprünglich auf meine Fehlerwahrnehmung zurückgeht, das sei dem mitlesenden Anonymtrollignoranten noch mit auf den Weg gegeben....

[Luckie]

Zitat von Delphi-Laie:

das sei dem mitlesenden Anonymtrollignoranten noch mit auf den Weg gegeben....

Genau das war von SirThornberry gemeint. Was soll das Nachtreten jetzt noch?

[Daniel]

Wir sollten es dabei bewenden lassen, dass hier ein Fehler samt eindeutiger Ursache gefunden wurde und der Bugreport dazu im EMBT-System zu finden ist. Mehr können wir an dieser Stelle eh nicht tun.

[Delphi-Laie]

Daniel, ich stimme Dir zu, schließlich bat ich schon vor längerem um die Schließung dieser Diskussion (bestimmen kann ich das nicht). Da ich jedoch gefragt wurde, soll es noch eine Antwort geben:

Zitat von Luckie:

Zitat von Delphi-Laie:

das sei dem mitlesenden Anonymtrollignoranten noch mit auf den Weg gegeben....

Genau das war von SirThornberry gemeint. Was soll das Nachtreten jetzt noch?

Einen Denkanstoß geben, ob man als offizieller Vertreter eines Unternehmens (!), der von den Produkten, um die es hier geht, und von den Kunden, zu denen auch ich vielleicht einmal wieder gehört hätte, von denen man also letztlich lebt, bei berechtigtem Unmut über mangelhafte Produkte und Produktinformationen dieses Unternehmens (der gar nicht an ihn adressiert war), in übliche Wörter der Umgangssprache verpackt, wirklich so reagieren sollte oder gar muß.

[Bernhard Geyer]

Hallo Delphi-Laie

wenn ich deinen ersten Satz im Ersten Beitrag im Delphi-Forum sehe:

Zitat:

M.E. ist es eine Bananensoftware wie fast jede anderer Software auch.

kann ich schon verstehen das hier andere etwas ebenfalls (für Ihre Position) unpassend Antworten.

Dann der Punkt

Zitat:

Dann wurde bei neuen Stilen ("Styles") der Stringgrids (nur bei denen?) gepfuscht

Wurde auch wiederlegt, da eigentlich eine fehlenden Anpassung im Theming-Verhalten korrigiert wurde und jetzt Implementiert ist. Es wurde auch gezeigt das man über ein Property das auf altes Verhalten zurückstellen kann.


Das Problem das Delphi-Compilate gleich gekracht haben auf älteren System hatten wir auch glaube ich bei D6/7 da hier durch die eigene Implementierung des Variant-Typs diverse Sachen nicht mehr geklappt haben.

Was man Ihnen hier vorwerfen kann ist das nicht die Test auf älterer HW ohne entsprechende Befehlssatzerweiterungen getestet hat. In Zeiten von VM ware der Test auf älterer HW entsprechend Aufwendiger (Dein Prozessor ist ja schon 10 Jahre alt - Bei Apple gäbe es schon seit 5 und mehr Jahren überhaupt keinen Support mehr).


Aber z.B. Problem Fehler in Kernfunktionen zu Patchen.
Solange diese nicht schon beim Initialisieren zuschlagen kann ma mal in den TNTWare-Controls nachschauen. Dort wurde ein Mechanismus implementiert um auch Funktionen aus der System.pas im laufenden Betrieb patchen zu können. Ist eigentlich sehr hilfreich um Fixes von neueren Delphi-Versionen auch auf ältere Versionen zurückportieren zu können).

[cookie22]

Was mich interessieren würde, gibt es einen Workaround dafür?

[Bernhard Geyer]

Zitat von cookie22:

Was mich interessieren würde, gibt es einen Workaround dafür?

Im Delphi-Forum hat AndyB einen Fix beschrieben:

Zitat:

Du kannst aber auch die System.dcu (win32\release und win32\debug) mit einem Hex-Editor (HxD) binär patchen.

1. Beide System.dcu wegsichern
2. Nach der Byte-Sequenz "6A 00 0F AE 1C 24" suchen
3. Aus "0F AE" ein "90 90" machen

patchen der System.pas wird nix bringen da man bei solchen Basis-Units den Compiler eigentlich nicht dazu überreden kann die geänderten Units beim Compilieren zu verwenden (bei "höherlevigen" Units kann man diese Patchen und dann z.B. ins Projektverzeichnis kopieren).