Seit einiger Zeit habe ich auf meinem Entwicklungsrechner das Problem, dass beim Windows-Start nach der Eingabe des Kennworts noch etwa 30 Sekunden vergehen, bis der Willkommensbild durch den Desktop ersetzt wird. Als Schuldiger kam dafür eigentlich nur eines der Programme in Betracht, die kürzlich installiert wurden.

Der Zweitrechner musste nun nochvom RC auf die finale Windows 7-Version aktualisiert werden. Direkt nach der Installation habe ich dann den Desktop und die Farben angepasst. Nach einem Neustart hatte ich dann auf der frischen Installation den gleichen Effekt. Zwischen Eingabe des Kennworts und der Anzeige des Desktops vergingen wieder 30 Sekunden. Diesmal konnte kein fremdes Programm schuld sein, es war nämlich noch keines installiert.

Daraufhin aktivierte ich wieder das Standard-Aerodesign, quasi den Auslieferungszustand. Erstaunlicherweise erschien der Desktop nun wieder sofort nach Eingabe des Kennworts. Nach etwas Herumspielen hatte ich dann die problematische Einstellung gefunden. Sobald der Desktophintergrund auf Einfarbig gesetzt wird, kommt es zu dieser Wartezeit. Ein Hintergrundbild zeigt dagegen keine Verzögerung.

Auf meinem Entwicklungsrechner machte ich dann die Gegenprobe. Dort war seit einiger Zeit wieder ein einfarbiger Hintergrund aktiviert. Nach der Umschaltung auf ein Hintergrundbild war die Wartezeit bei der Anmeldung auch hier verschwunden.

Auch auf dem Laptop lässt sich dieser Effekt reproduzieren. Ein möglicher Workaround ist die Erstellung einer einfarbigen Bilddatei, die dann als Hintergrundbild gewählt wird. Die Betaversion sowie der Releasekandidat haben dieses Problem nicht gehabt, hier konnte man ohne Einschränkungen einen einfarbigen Hintergrund aktivieren.

Könnt ihr dieses Verhalten bei euch auch nachvollziehen?

Gestern bei der Installation der Checked Build von Windows 7:

Und weiter geht’s…

Habe mich dann doch für die normale Ultimate entschieden.

Seit 19.00 Uhr können sich MSDN-Abonnenten die englischsprachigen Versionen von Windows 7 herunterladen. Folgende Fassungen sind verfügbar:

• Windows 7 Starter (x86)
• Windows 7 Home Basic (x86)
• Windows 7 Home Premium (x86 und x64)
• Windows 7 Professional (x86 und x64)
• Windows 7 Ultimate (x86 und x64)

Dazu gibt es noch die Debugsymbole, das Windows Automated Installation Kit und das Windows Driver Kit. Das Windows SDK wird wie schon beim RC in drei Fassungen angeboten (x86, x64 und ia64). Das deutsche MUI-Pack kann ebenfalls heruntergeladen werden.

Die SHA1-Prüfsummen für die Ultimate-ISO lauten übrigens überraschenderweise

• x86: 5395DC4B38F7BDB1E005FF414DEEDFDB16DBF610
• x64: 326327CC2FF9F05379F5058C41BE6BC5E004BAA7

Die Downloadgeschwindigkeit ist erwartungsgemäß wieder unter aller Sau. Der vorgezogene Vertrieb über die Tauschbörsen scheint also keine Entlastung zu bringen.

Update: Über die Top-Downloads (Akamai Download-Manager) geht es deutlich fixer.

Seit dem Erscheinen von Windows 95 waren auf meinem Entwicklungsrechner immer mehrere Betriebssysteme installiert. Das war auch bitter nötig, denn Virtualisierer waren damals noch ein Fremdwort. Entwickelt habe ich weitgehend unter NT4, unter Windows 95 brauchte man dazu gute Nerven. Fast jede Schutzverletzung hat das Betriebssystem in’s Schwitzen gebracht, häufig musste anschließend das System neu gestartet werden. Ab und zu musste der Debugger aber auch mal unter Windows 95 angeworfen werden. In Hochzeiten waren fünf Systeme nebeneinander installiert (Windows 95, 98, ME, NT4 und Windows 2000).

Heute sind es nur noch drei (Windows XP x64, Windows Vista x64 und Windows 7 x64). Das aber nur, weil es Virtual PC nicht schafft, ein 64-Bit Betriebssystem zu installieren. Vor einiger Zeit habe ich mir deshalb mal wieder VMWare Workstation angeschaut, das neben der Unterstützung für 64-bit Gastsysteme auch eine viel bessere Snapshot-Verwaltung bietet. Mit der Remote Debugging-Funktion von VS 2008 ist so das Debuggen auf den verschiedensten Systemen ein Kinderspiel, zudem hält man sich immer in der gewohnten Arbeitsumgebung auf.

Damit entfällt nun die Notwendigkeit, auf dem Entwicklungsrechner verschiedene Betriebssysteme installieren zu müssen. Mit der Aktualisierung auf die finale Version von Windows 7 gibt es dann nur noch ein Betriebssystem auf der Festplatte. Der Rest findet in einer VM statt.

In Arbeitspausen schicke ich meinen Rechner immer per Tastendruck in den Standby-Modus (S3), um Strom zu sparen. Mit dem neuen Rechner zeigten sich hier aber unter Windows 7 unerwartete Probleme. Manchmal ließ der Rechner ordnungsgemäß in den Standby schicken, öfters schaltete er sich aber nicht richtig ab und ließ sich ohne Reset auch nicht mehr aufwecken. Es stellte sich heraus, dass der Standby-Modus immer genau einmal pro Sitzung funktionierte. Beim zweiten Versuch war der Rechner dann weg.

Wartet man nach dem Hängenbleiben etwas ab, dann taucht nach ein paar Minuten ein Bluescreen mit der Meldung DRIVER_POWER_STATE_FAILURE auf. Der Callstack im Minidump ließ auf Netzwerkprobleme schließen, da hier tcpip.sys und andere Treiber auftauchten.

Mit deaktivierter Netzwerkkarte war das Problem plötzlich verschwunden, nach erneuter Aktivierung war wieder nur ein Standby pro Sitzung möglich. Auch ein Einspielen anderer Treiber half nicht.

Irgendwie kam ich dann auf die Idee, in den Energieeigenschaften der Netzwerkkarte wieder alle Optionen zu aktivieren. Normalerweise sind das mit die ersten Einstellungen, die ich nach einer Neuinstallation deaktiviere. Ansonsten kann es passieren, dass der Rechner nach dem Wechsel in den S3-Modus sofort wieder hochfährt, weil die Netzwerkkarte irgendein Paket aufgeschnappt hat. Außerdem sollte die Netzwerkkarte ja auch keinen Grund haben, den Rechner von sich aus in den Standby zu schicken.

Nach der Aktivierung konnte der Rechner plötzlich beliebig oft zwischen Normalzustand und S3-Modus umschalten. Nach ein paar weiteren Tests stellte sich heraus, dass die Option Computer kann das Gerät auschalten, um Energie zu sparen unbedingt aktiviert sein muss. Ist sie deaktiviert, dann lässt sich der Rechner nachvollziehbar nur einmal sicher in den S3-Modus schicken. Jeder zweite Versuch hängt ihn auf.

Verstehen muss man das wohl nicht. Aber falls einer ein ähnliches Problem hat, dann hilft ihm vielleicht dieser Eintrag etwas weiter.

Wenn man in Windows 7 ‘winver’ aufruft, wird man damit überrascht:

Wie war gleich noch mal die Begründung für den Namen ‘Windows 7′? Es sei die siebente Windows-Version. Ich frage mich jetzt, woran Microsoft das genau festmacht. Windows 1, 2 und 3 sind eigentlich unstrittig. Windows 9x/ME und NT 4.0 liefen unter der Versionsnummer 4.0. Windows 2000 war dann das fünfte Windows (5.0). XP müsste man trotz 5.1 eigentlich als das sechste Windows zählen. Windows Vista bekam eine neue Hauptversionsnummer (6.0) spendiert und sollte damit als Nummer 7 durchgehen.

Damit wären wir nun bei Windows 8 angelangt. Oder bei Windows 7, wenn man XP aufgrund der .1 nicht mitzählt. Aber warum zählt dann Windows 7 trotz .1 wieder als volle Version? Warum hat man die Hauptversionsnummer dann nicht auf 7.0 gesetzt, was besser zum Namen gepasst hätte? Fragen über Fragen. Habt ihr Antworten darauf?

Irgendwie fühle ich mich an alte ISDN-Zeiten erinnert:

Vor zwei Jahren habe ich den Akamai-Downloadmanager noch verflucht. Er war zwar schrottig zu bedienen, brachte dafür aber wenigstens eine akzeptable Geschwindigkeit. Bin mal gespannt, wie heute abend die Geschwindigkeit bei der öffentlichen W7-Beta ist. Vermutlich ist diese schneller auf meiner Festplatte als die MSDN-Version, die ebenfalls gerade geladen wird. Mit der ist nämlich erst in 70 Stunden zu rechnen, wenn es in dieser Geschwindigkeit weitergeht.