Centurios Blog

Unglaublich. Ich habe gestern bestimmt 6 Stunden damit verbracht, den Fehler zu finden.

Folgende Situation: Mein Macbook Pro hat eine ATI X1600, die schnell genug ist für aktuelle Spiele wie Command and Conquer 3 Tiberium Conflict oder auch CS:S. CS:S habe ich schon seit einiger Zeit unter Windows XP SP2 mit BootCamp und den BootCamp Treibern Version 1.4 gespielt.

Dann habe ich vor einiger Zeit beinahe es gewagt VMWare Fusion mit meiner BootCamp Partition bekannt zu machen. Ich habe es aber nicht damit Booten lassen, sondern nur mit Parallels 3.

Na jedenfalls habe ich gestern ganz normal ne Runde Spielen wollen, aber ich habe merkwürdigste Grafikfehler bekommen. Nachdem ich dann stundenlang Spiele installiert, gepatcht, probiert, deinstalliert und neuinstalliert habe, bin ich nicht weiter gekommen.

Frustriert habe ich dann es gewagt, die Apple Ati Treiber mit der Offiziellen Version von der Ati Seite zu befüllen, das brachte aber auch nichts. Denn die Karte wurde gar nicht erst erkannt. Also nächster Versuch mit den bekannten Omega Corner Treibern. Die haben es dann doch tatsächlich die Karte erkannt und ich hatte die Treiber drauf.

Also neuer Versuch mit dem Spiel, aber die Grafik war immer noch gestört.

Frustriert habe ich mich dann beschäftigt mit dem mitgelieferten Diagnosetool dxdiag, das man einfach über “Start, Ausführen” starten kann. Dort kann man verschiedene Tests starten. Das fängt bei Dateiintegrität und Versionskonflikten an und geht auch hin zu einfachen 3D Tests.

Zwei Dateien namens “D3D8.DLL” und “D3D9.DLL” sind dabei besonders aufgefallen. Beide waren nicht wie die restlichen Dateien aus dem Jahr 2004, sondern Ende September 2007 (also vor nicht allzulanger Zeit). Auch scheiterte der einfache 3D Test und hing.

Verzweifelt habe ich DX9.0c neuinstalliert, die Dateien waren immer noch die gleichen. Die letzte Chance bestand nur noch darin, die Dateien von Hand mit den “Originaldateien” zu ersetzen. Die habe ich mir dann von einem anderen Rechner kopiert und habe meine Dateien ersetzt. Dabei ist mir dann aufgefallen, dass meine Dateien lediglich 55kb groß waren, und der Name “WINE” darin auftauchte (Eigenschaften der DLL-Datei). Die Original Dateien haben aber etwa 1,5MB Größe.

Naja jedenfalls habe ich die Dateien ersetzt, und nochmal dxdiag aufgerufen. Und siehe da, es geht wieder, ALLES!

Was war das nun? Ich weiß es nicht genau, ich bin nur glücklich, dass es so einfach zu beheben war. Denn diesen Oktober sind keine neuen BootCamp Installationen mehr möglich und ich brauche meine Windows Installation, damit ich auf der Junien spielen kann…

Mich nervt in letzter Zeit folgendes Problem:

Ich arbeite Tagelang mit Mac OS X 10.4.11. Dann starte ich einmal ins Windows mittels BootCamp und spiele dort ein paar Runden. Wenn ich dann wieder ins Mac OS zurückkehre, ist die Systemzeit um 2h in die Zukunft verschoben.

Den Grund dafür kenn ich: Windows und *nix/BSD handhaben die Uhrzeit Einstellung anders. Für Gewöhnlich verwenden die *nix/BSD Betriebssysteme die GMT (Greenwich Mean Time), also die Zeit der Zeitzone direkt an der Sternenwarte in London. Windows hingegen orientiert sich an der Zeitzone und der damit verbundenen Zeitverschiebung (in Westeuropa z.B. +1 Stunde gegenüber GMT).

Dann haben wir noch gerade Sommerzeit, so dass die Uhren eine Stunde vorgestellt wurden, so dass wir effektiv bei +2 Stunden Zeitverschiebung angelangt sind.

Wechsele ich jetzt zu Windows, orientiert sich Windows irgendwie anhand der Bootcamp Treiber auf die richtige Uhrzeit, wechsele ich ins Mac OS, habe ich eine Zeitverschiebung, da die Hardware Uhr von Windows neu eingestellt wurde (um +2 Stunden in die Zukunft).

Erst ein automatischer Abgleich mit einem NTP Zeitserver stellt die Uhrzeit richtig ein. Da dies aber eine Systemweite Umstellaktion ist, verlangt sie root Rechte. Dadurch, das meine Systemeinstellungen gegen versehentliche (oder von irgendwelche Schadprogrammen) Umstellungen geschützt ist (über das Schlosssymbol), geschieht dieser Abgleich nicht automatisch.
Nur nachdem ich das Schlosssymbol angeklickt und mich authentifiziert habe, stellt sich die Uhrzeit (richtig) neu ein.

Dies ist ein ziemlich nerviger Zustand, möchte ich doch nicht auf den Schutz verzichten, aber zeitgleich auch nicht immer erst einen Uhrenvergleich durchführen müssen. Das Problem ist jedenfalls bekannt. Felix empfahl mir nen Shell Script einfach mit dem Befehl:
sudo ntpdate time.euro.apple.com
und die Rechte dann root geben mit chown root skript.sh und setuid0 flag mit chmod +s skript.sh. Vielleicht mal gleich ausprobieren, soweit aber schon mal danke Felix

Update: Hier ist eine Lösung und Erklärung, wie man Windows entsprechend konfiguriert, dass es sich an die Universal Zeit UTC einstellt.