Luckie hat folgendes geschrieben :

Delphi-Laie hat folgendes geschrieben : Luckie, selten genug hast du eine Frage. Wie käme es wohl bei dir an, wenn ich dir dann reflexhaft entgegnen würde: Sind wirklich alle aktuellen Patches und Updates installiert? Auch fehlerhafte OS-Installationen (gleich zwei, die sonst wegen Kaumbenutzung langzeitstabil sind?!) und ein veralteter Prozessor, was ich mir hier alles als abenteuerliche Fehlerquellen entgegenhalten lassen mußte - mir war intuitiv gleich klar, daß das Murks ist, und das zog (s)ich durch die gesamte Diskusion) und ließ mich auch vehement werden. Wie kommst du darauf, dass es reflexartig war? Du hast keinerlei Angaben zu den Betriebssystemen gemacht.

Doch, ich nannte sie beim Namen und auf Nachfragen auch den groben Updatestatus.

Luckie hat folgendes geschrieben :

Auch ansonsten waren anfangs deine Informationen ziemlich spärlich.

Was gefragt wurde, wurde auch beantwortet.

Luckie hat folgendes geschrieben :

Und ich bewundere dich dafür, dass du alle Fehlerquellen intuitiv ausschließen kannst.

Alle? Das ist schon wieder unsachlich. In dem Falle allerdings ja. Zwei nahezu gleiche Windows 2000, einmal funktioniert es, einmal nicht. Zwei nahezu unbenutzte Windows, die beide fehlerhaft sein sollen? All' davon schrieb ich, da mußte irgendwo ein Wurm drinstecken! Soviel Intuition und garantiert noch mehr hättest auch du gehabt.

Laß es gut sein. Konzentrieren wir uns auf noch unerledigte Dinge. Gern stehe ich weiterhin für deinen XP Usermanager und damit letztlich auch dir zur Verfügung.

Delphi-Laie hat folgendes geschrieben :

Laß es gut sein. Konzentrieren wir uns auf noch unerledigte Dinge. Gern stehe ich weiterhin für deinen XP Usermanager und damit letztlich auch dir zur Verfügung.

Und nach diesem Schlusssatz bitte ich Euch, diesen Teil der Diskussion, falls doch noch Bedarf bestehen sollte, per PN fortzuführen.

Delphi-Laie hat folgendes geschrieben :

Ist das hier [...] der originale oder korrigierte Quelltext?

Das ist der originale. Ich habe aber schon mit Embt "gesprochen" und der Code gehört wirklich so herum. Was aber fehlt ist eine Prüfung, ob die CPU auch SSE1 unterstützt.

Da das der betreffende Prozessor nicht kann, erklärt das auch den Fehler, aber was hat dann dein Patch zur Folge?

AndyB hat folgendes geschrieben :

Delphi-Laie hat folgendes geschrieben : Ist das hier [...] der originale oder korrigierte Quelltext? Das ist der originale. Ich habe aber schon mit Embt "gesprochen" und der Code gehört wirklich so herum. Was aber fehlt ist eine Prüfung, ob die CPU auch SSE1 unterstützt.

Danke und ein Glück, daß ich Amateur mich doch nicht so weit aus dem Fenster lehnte - das wäre wahrscheinlich schiefgegangen.

Was Deine beiden geänderten Zauberbytes nun genau anrichten, hätte ich auch gern gewußt. Wie bist Du überhaupt darauf gekommen? Ich vermute(te), daß Du Original und geänderte Version (mit vertauschten Compilerschaltern) der Datei system.pas jeweils compiliertest und dann die Compilate verglichst. So scheint es jedoch nicht gewesen zu sein. Wenn die Compilerschalter doch stimmen, ist Deine gestrige Fährte umso rätselhafter (wenn sogar jaenicke, der fast nur antwortet anstatt fragt, sich danach erkundigt....).

Ich schätze, das wäre mit der Zeit auch anderen aufgefallen. Denn der "Donnervogel" ist immerhin ein Prozessor mit einer Taktfrequenz im Gigahertzbereich. Ihr alle wißt, daß es mit der Taktsteigerung nicht so wie geplant weiterging; ergo werden vermutlich doch noch deutlich mehr Computer damit ausgestattet sein, als mancher der "Poweruser" hier vielleicht glauben mag.

90 ist der OpCode für "NOP", also "no operation" - "tue nichts" (hier 2mal hintereinander). Was dieser Patch macht, ist also diese Anweisung einfach "wegzulassen".

Die Instruktion 0FAE selber kann in ihrer Bedeutung per ModRM umgeschaltet werden, aus dem Funktionsnamen tippe ich mal dass hier STMXCSR gemeint ist. Die Quellen zum Nachgucken habe ich auch nicht.

Mit andern Worten wird DefaultMXCSR auf was undefiniertes initialisiert. Solange keine SSE-Routinen benutzt werden, die etwas wiederherstellen wollen sollte das egal sein. Ob irgendwelche Standardfunktionen das tun, oder ob das nur "pro forma" gemacht wird weiß ich nicht.

Martok hat folgendes geschrieben :

90 ist der OpCode für "NOP", also "no operation" - "tue nichts" (hier 2mal hintereinander). Was dieser Patch macht, ist also diese Anweisung einfach "wegzulassen".

Das war mir schon klar, die Frage zielte eher darauf ab, ob jemand sagen kann was das im Programm für Folgen hat.

jaenicke hat folgendes geschrieben :

ob jemand sagen kann was das im Programm für Folgen hat.

Wenn du die in XE2 neu eingeführten Funktionen ResetMXCSR, SetMXCSR und GetMXCSR sowie die Variable DefaultMXCSR nicht nutzt, dann hat das überhaupt keine Auswirkung.

Moderiert von Martok: Doppelpost zusammengefasst

Delphi-Laie hat folgendes geschrieben :

Wie bist Du überhaupt darauf gekommen?

Ich habe einfach eine neue VCL Form Anwendung erstellt, kompiliert und ausgeführt. Dann die Programmausführung unterbrochen (Pause-Button) und mit Menü "Suchen/Zur Adresse springen..." die im Event-Log angegebene Speicheradresse eingegeben. Und schon stand ich in System.GetMXCSR. Und da das eine Assemblerfunktion ist, sind die Bytes nicht schwer zu ermitteln. HxD angeworfen und in System.dcu nach den Bytes gesucht und überprüft, dass die Sequenz nur einmal vorkommt.

AndyB hat folgendes geschrieben :

Delphi-Laie hat folgendes geschrieben : Wie bist Du überhaupt darauf gekommen? Ich habe einfach eine neue VCL Form Anwendung erstellt, kompiliert und ausgeführt. Dann die Programmausführung unterbrochen (Pause-Button) und mit Menü "Suchen/Zur Adresse springen..." die im Event-Log angegebene Speicheradresse eingegeben. Und schon stand ich in System.GetMXCSR. Und da das eine Assemblerfunktion ist, sind die Bytes nicht schwer zu ermitteln. HxD angeworfen und in System.dcu nach den Bytes gesucht und überprüft, dass die Sequenz nur einmal vorkommt.

Danke, ich verstehe es nur ungefähr.

Ich verstand es aber so, daß der Fehler doch nicht im Quelltxt der system.pas liegt, jedenfalls nicht an Deinem Codeschnipsel, dann vielleicht woanders? Oder es gelangen Dinge zusätzlich (?) in die dcu, die nicht im Quelltext stehen? Einiges sicherlich...

Es gibt natürlich noch einen anderen, simple(re)n Weg der Fehler"bereinigung": Embarcadero gibt nicht mehr nur die Softwareanforderungen bekannt, sondern schiebt endlich auch noch die Hardwareanforderungen der Compilate als offizielle Produktinformation nach.

Delphi-Laie hat folgendes geschrieben :

Ich verstand es aber so, daß der Fehler doch nicht im Quelltxt der system.pas liegt

Doch das tut er, und zwar in der Funktion GetMXCSR. Diese nutzt den SSE1 Befehl "STMXCSR", den deine CPU nicht kennt.



Und diese Funktion wird von _InitializeControlWord aufgerufen. Durch das gepatchte "NOP; NOP" (90 90) liefert GetMXCSR nun immer 0 zurück.