Die Migration von Unternehmens-PCs auf Windows 7 ist in vollem Gang. Ein Grund liegt in der häufig veralteten PC- und Notebook-Hardware - hier gab es in den letzten Jahren einen Investitionsstau. Im Zuge des Austauschs ihrer Geräte wechseln viele Firmen auf Windows 7. Von den von IDC befragten Unternehmen denken 43 Prozent bei der Einführung zusätzlich an Desktop-Standardisierung und -Virtualisierung als eine mögliche Lösung für Kompatibilitätsprobleme.

Probleme bei 16 Prozent

Dienstleister wie T-Systems adressieren diesen Markt und prüfen in eigenen Software-Testzentren, ob der Umstieg mit unterschiedlichen Business-Applikationen reibungslos funktionieren kann. "Unsere Kompatibilitätstests haben gezeigt, dass immerhin rund 16 Prozent der Kundenanwendungen nicht sofort und ohne Anpassungen mit der neuen Generation des Betriebssystems zurechtkommen", berichtet Michael Birzele, Leiter des Fachbereichs Frontend Services.

Die größte Herausforderung stellen dem Dienstleister zufolge die Rich-Client-Applikationen der Rechner dar. Ein einfaches Beispiel, wo es schon mal zu Schwierigkeiten kommen kann, ist die in Windows 7 intensiv verwendete Benutzerkontensteuerung, sagt Jan Quatram, Leiter des Testzentrums. Selbst wenn man als Administrator im System unterwegs ist, kommt immer wieder die Anfrage, ob ein Vorgang wirklich weitergeführt werden soll. Wenn da ein Schnittstellenprogramm zwischen zwei Applikationen läuft und dieser Hinweis zum wiederholten Mal aufpoppt, kann das zu technischen Störungen führen. Die Benutzerkontensteuerung lässt sich in diesem Fall so konfigurieren, dass sie nicht mehr auf die Administratorrechte zurückgreift und damit keine weiteren Probleme verursacht. Aus der Migrationspraxis heraus lis-tet T-Systems besonders häufig auftauchende Fehlerquellen im Umgang mit Windows 7 auf und gibt folgende Tipps:

Hart codierte Pfade wie C:\Programme gibt es unter Windows 7 nicht mehr. Hier heißen sie englisch Program Files. Verlässt sich die Anwendung darauf, dass C:\Programme existiert, läuft sie meist schon bei der Installation ins Leere. Sollte sie dennoch funktionieren, scheitern häufig Versuche, Daten aus C:\Programme nachzuladen, und die Anwendung läuft fehlerhaft. Da diese Störung oft erst spät auffällt, gestaltet sich die Suche nach den Ursachen meist schwierig.

Durch das neue Sicherheitsmodell im Internet Explorer 8 kommt es oft zu Interoperabilitätsproblemen mit Web-Anwendungen, die durch den neuen Kompatibilitätsmodus nur teilweise abgefangen werden können.

Benutzerrechte: Aufgrund des Wechsels von einem relativ offenen zu einem auf Sicherheit ausgerichteten System mit Windows 7 entfällt die Hauptbenutzer-Gruppe. Dadurch können Anwendungen nicht mehr in das eigene Verzeichnis schreiben. Besonders problematisch wirkt sich das bei Anwendungen aus, die sich selbst aktualisieren.

Schreiben in Systemverzeichnisse: Traditionell schreiben viele Anwendungen unter anderem DLL-Dateien in Systemordner (zum Beispiel C:\Windows\system32) und registrieren sie dort. Bringt eine neue Applikation eine gleichnamige Datei neueren Datums in das Verzeichnis, überschreibt diese die bestehende Version. Dadurch kann es passieren, dass ältere Anwendungen nicht mehr funktionieren. Das ist insbesondere in Unternehmen häufig der Fall, wenn die dort selbst entwickelten Applikationen über einen eigenen Installationsmodus anstelle des Windows Installers verfügen. Tipp: Die Programmierer solcher Anwendungen sollten darauf achten, dass die DLL nicht mehr in der Programmbibliothek, sondern im Applikationsverzeichnis abgelegt und registriert wird. Gleichnamige DLL-Dateien liegen dann jeweils voneinander getrennt vor. Somit funktionieren auch alle älteren Applikationen, da sie ihre DLL nach der Windows-Logik zuerst im Applikationsverzeichnis suchen und erst danach im System32.

Alte 16-Bit-Anwendungen sollten ersetzt werden. Sie laufen unter Windows 7 64 Bit nicht mehr und sind unter 32-Bit-Windows häufig fehlerbehaftet.

Man sollte benötigte Runtime-Komponenten wie die Microsoft-C++-Runtime nie mit eigenen Applikationen ausliefern, sondern das jeweilige "Redistributable Package" verwenden, um die technische Integrität der Windows-7-Plattform zu erhalten.

Anwender haben unter Windows 7 generell nur einfache Benutzerrechte. Unternehmen sollten eigene Applikationen gegebenenfalls so anpassen, dass sie unter Windows 7 mit Standardbenutzerrechten laufen, ohne dass erweiterte Befugnisse nötig sind. Zudem sollten sie die Applikation auf ihre Windows-7-Tauglichkeit testen lassen. Die wichtigsten Prüfkriterien hierbei: Was macht die Applikation bei der Installation, wo hinterlegt sie ihre Dateien, welche Berechtigungen benötigt sie an welcher Stelle, und kann der Benutzer die Anwendung mit seinen Standardrechten starten, ausführen und bearbeiten?

Viele Unternehmen prüfen Applikationen auf eine bestimmte Windows-Version hin. Ändert Microsoft diese zum Beispiel mit einem neuen Patch, lässt sich die Anwendung dann unter Umständen nicht mehr installieren, obwohl sie ansonsten unter Windows 7 läuft. Alternativ müsste der Anwender auf den neuen Patch verzichten. Abfragen im Hinblick auf bestimmte Windows-Versionen sollten Unternehmen daher unterlassen. Mit einem API-Aufruf können Nutzer die Version einfacher prüfen, da sich die APIs von XP und Windows 7 grundlegend unterscheiden. Bestimmte Aufrufe unter XP funktionieren unter dem neuen Betriebssys-tem nicht. So lässt sich etwa eine E-Mail aufgrund einer neuen API-DLL nur mit einem völlig anderen Befehl öffnen.

Generell ist für das Ausrollen neuer Applikationen eine Microsoft-konforme Programmierung wichtig: Was auf dem Desktop des Entwicklers funktioniert, läuft längst nicht auf jedem Arbeitsplatz. Am besten ist es, so weit wie möglich auf zusätzliche Applikationen zu verzichten. Nötige Erweiterungen sind möglich, sie sollten aber nicht mehr im System32-Verzeichnis, sondern im Applikationsverzeichnis liegen. (ue)