NAN Error nach Windows Update

[Der schöne Günther]

Heißt ich hatte Recht 😎

[mjustin]

Descha wü

Why 1.99 suddenly no longer equals 1.99
https://mikejustin.wordpress.com/200...hy-is-199-199/

"TIBDataBase.Create(nil) changes the value of Get8087CW from $1372 to $1272 ..."

[stalkingwolf]

Zitat von Der schöne Günther:

Heißt ich hatte Recht 😎

halb War halt nicht der Druckertreiber, sondern die Integration vom Internet Explorer durch TWebbrowser, welcher einem durch die neuesten Update vom Betriebsystem untergejubelt wird.

[TurboMagic]

Ja und, hat jetzt jem,and von euch geprüft, ob das bereits in QP erfasst ist und falls nicht es erfasst?

[TiGü]

Zitat von TurboMagic:

Ja und, hat jetzt jem,and von euch geprüft, ob das bereits in QP erfasst ist und falls nicht es erfasst?

Schon mal drüber nachgedacht, dass nicht alles im Emba-Spielfeld liegt?
Hier hat Microsoft doch ein bestehendes Verhalten kaputt gemacht.

[TurboMagic]

Zitat von TiGü:

Zitat von TurboMagic:

Ja und, hat jetzt jem,and von euch geprüft, ob das bereits in QP erfasst ist und falls nicht es erfasst?

Schon mal drüber nachgedacht, dass nicht alles im Emba-Spielfeld liegt?
Hier hat Microsoft doch ein bestehendes Verhalten kaputt gemacht.

Naja, es mag ja sein, dass Microsoft jetzt das x87 Optionen Register vermurkst,
aber evtl. könnte EMBT drum herum arbeiten?

Ginge vielleicht so etwas wie alten Wert vor Aufruf merken und direkt nach diesem
Aufruf wieder setzen? Oder ist der Aufruf ein direkter COM-Aufruf ohne einen Wrapper drumherum?
Dann ginge sowas natürlich nicht.

Grüße
TurboMagic

[Der schöne Günther]

Zitat von TurboMagic:

Ginge vielleicht so etwas wie alten Wert vor Aufruf merken und direkt nach diesem
Aufruf wieder setzen?

Das ist eigentlich Aufgabe von demjenigen der es ändert, also in diesem Fall des Fremdcodes (TWebBrowser oder was auch immer es jetzt war). Embarcadero/Delphi hat hier echt keine Schuld.

[TurboMagic]

Zitat von Der schöne Günther:

Zitat von TurboMagic:

Ginge vielleicht so etwas wie alten Wert vor Aufruf merken und direkt nach diesem
Aufruf wieder setzen?

Das ist eigentlich Aufgabe von demjenigen der es ändert, also in diesem Fall des Fremdcodes (TWebBrowser oder was auch immer es jetzt war). Embarcadero/Delphi hat hier echt keine Schuld.

Grundsätzlich richtig, nur wer informiert diesen Hersteller, damit der das repariert?
Wer hat einen Draht zu dem? Evtl. EMBT? Falls dem so ist, sollte in einem QP report
drinstehen, dass das Problem an der Wurzel beseitigt werden sollte und EMBT da ruhig
seine Kommunikationskanäle nutzen kann um den Verursacher auf das Problem aufmerksam
zu machen.

Alternativ jemanden von EMBT kontaktieren, der das Problem weiter trägt oder direkt
den Verursacher kontaktieren. Ansonsten sind wir evtl. noch in 10 Jahren dazu gezwungen
den Workaround zu benutzen der derzeit wo dokumentiert ist?
Richtig, m.W. nur in diesem Delphipraxis.net Thread...

Oder sehe ich da was falsch und wir sollen unsere Software mit Workarounds zupflastern?

Grüße
TurboMagic

[Fritzew]

[QUOTE=TurboMagic;1450749][QUOTE=Der schöne Günther;1450724]

Zitat von TurboMagic:

Oder sehe ich da was falsch und wir sollen unsere Software mit Workarounds zupflastern?

Grüße
TurboMagic

Tja, das Problem ist nicht neu.... David H hat das oft auf Stackoverflow thematisiert.
Solange sich nicht alle daran halten die FPU-Flags wieder zurückzusezen nach einer Änderung, kommt man nicht darum herum
genau das zu machen. Ist nicht schön, aber....
Noch schlimmer ist, das die Flags auch in Threads geändert werden können. Habe gerade bei uns mal geschaut,
Wir haben über 1000 Calls zu reset FPU..... (Bin im CAD-CNC)