Skip to main content

Verstehen der Anwendungskompatibilität

Es gibt verschiedene Gründe, warum eine Anwendung, die auf vorherigen Versionen von Windows funktionierte, auf Windows 8 erst einmal fehlschlägt, bis Sie das Problem behoben haben. Wie oft dies vorkommt, hängt weitgehend davon ab, welche Windows-Version Sie zurzeit verwenden. Die Umstellung von Windows XP auf Windows Vista war ohne Zweifel der schwierigste Umstieg der letzten Zeit. Windows 7 wies im Vergleich hierzu eine hohe Kompatibilität mit Windows Vista auf, und Windows 8 erweist sich als hochgradig kompatibel mit Windows 7. Wenn Sie also mit Windows Vista oder höher arbeiten, haben Sie wahrscheinlich Glück, und die Migration Ihrer Anwendungen auf Windows 8 gelingt weitaus leichter. Wenn Sie noch mit Windows XP (oder gar einer noch früheren Windows-Version) arbeiten, haben Sie wahrscheinlich etwas mehr Arbeit vor sich. Wie jedoch bereits zahlreiche Kunden bewiesen haben, lässt sich diese Herausforderung mit dem richtigen Ansatz für die Anwendungskompatibilität problemlos überwinden.

Warum stürzen Anwendungen ab, wenn Sie auf ein neueres Betriebssystem migrieren? Manchmal liegt es daran, dass eine Anwendung einen Bezug auf ein nicht dokumentiertes Verhalten des Betriebssystems enthält, entweder weil der Entwickler absichtlich eine nicht dokumentierte API verwendet hat, oder weil er sich versehentlich auf ein Verhalten verlassen hat, das sich als zufälliges statt als garantiertes Verhalten erweist. (Angesichts der umfangreichen Microsoft Developer Network (MSDN)-Dokumentation ist es zugegebenermaßen ziemlich schwierig, alle möglichen Verhalten des Betriebssystems vollständig zu verstehen.) Manchmal werden Features und Verhaltensweisen entfernt, was oft auf Sicherheitsbedenken zurückzuführen ist. Gründe dafür können jedoch auch mangelnde Marktakzeptanz oder Ersatz durch eine bessere Technologie sein. Leider ist die häufigste Ursache für Probleme mit der Anwendungskompatibilität jedoch eine Versionsüberprüfung. D. h., die Anwendung überprüft die Version des Betriebssystems und funktioniert nicht, wenn eine andere Version als die für die Ausführung vorgesehenen Versionen erkannt wird. Die Anwendung lässt Sie also gar nicht erst versuchen, sie auf dem neuen Betriebssystem auszuführen, selbst wenn sie problemlos funktionieren würde.

Wenn Sie an weiteren Informationen dazu interessiert sind, stellen wir Ihnen zur Erläuterung der Änderungen hinsichtlich der Kompatibilität gerne das Handbuch zur Anwendungskompatibilität mit Windows 8 und Windows Server 2012 zur Verfügung. Zielgruppe des Handbuchs sind jedoch Entwickler, die Code schreiben. In diesem Artikel werden die Probleme bei der Anwendungskompatibilität aus dem Blickwinkel von IT-Profis beleuchtet, die versuchen, ihre Organisationen auf Windows 8 zu migrieren. Darüber hinaus geht es um die Motivation hinter den in Windows 8 vorgenommenen Änderungen sowie die möglichen Auswirkungen dieser Änderungen.

Themen dieses Artikels:


Erhöhung der Zuverlässigkeit

Im Zuge der Verbesserung der gesamten Sicherheit und Zuverlässigkeit des Betriebssystems erkannte Microsoft, dass keine dieser Investitionen optimal genutzt werden konnte, solange die Mehrheit der Benutzer als lokale Administratoren ausgeführt wurde. Die Gründe dafür sind natürlich historisch bedingt. Bei MS-DOS und frühen Versionen von Microsoft Windows gab es das Konzept der gemeinsam genutzten Computer und Sicherheitsüberprüfungen noch nicht. Bei Windows NT wurde eine robuste Sicherheitsinfrastruktur eingeführt, gleichzeitig bot die Version Kompatibilität mit vorhandenen MS-DOS- und Windows-Anwendungen, die nie für ein sicheres Betriebssystem für mehrere Benutzer konzipiert waren. Viele Kunden vertrauten auf diese Anwendungen und ließen ihre Benutzer deshalb als lokale Administratoren eingerichtet. Administratorbenutzer sind jedoch erheblich teurer zu verwalten als Standardbenutzer, und Kunden weltweit forderten eine Möglichkeit, mehr Benutzer zu Standardbenutzern zu machen. Einigen gelang dies, doch der Prozess war fast immer teuer und aufwendig, und die Sicherheitskonfiguration des Betriebssystems musste mehrfach durchlöchert werden, um Anwendungen zu unterstützen, für die Administratorrechte benötigt wurden.

Mit Windows Vista führten wir die Benutzerkontensteuerung (UAC) ein. Damit wurde der Kreislauf durchbrochen, dass das Vorhandensein von lokalen Administratoren zu Anwendungen führte, die von lokalen Administratorrechten abhingen, weshalb wiederum mehr lokale Administratoren benötigt wurden. Am Ende erreichten die Kunden neben der verbesserten Sicherheitsstruktur einer Umgebung mit Standardbenutzern eine deutliche Senkung der Gesamtbetriebskosten. Dieses Feature war in erster Linie ein Kompatibilitätsfeature. Es bot automatisierte Lösungen für eine Reihe von Kompatibilitätsproblemen, wie Datei- und Registrierungsschreibvorgänge in geschützten Verzeichnissen, oder Fehler von Setupprogrammen, die zur Installation in globalen Verzeichnissen Administratorrechte benötigen. Es bot außerdem zusätzliche Wiederherstellungsoptionen, die manuell auf Anwendungen angewendet werden konnten, um weitere Kompatibilitätsprobleme im Zusammenhang mit der Ausführung von Anwendungen unter Standardbenutzerrechten zu beheben.

Neben der Fehlerbehebung für Anwendungen von Drittanbietern verbesserte die UAC zudem auf verschiedene Weise die Erfahrung von Standardbenutzern. So wurde beispielsweise für Standardbenutzer die Möglichkeit zum Ändern ihrer Zeitzone auf Reisen hinzugefügt (eine häufige Beschwerde von Kunden, denen die Bereitstellung von Standardbenutzern unter Windows XP oder früheren Versionen gelungen war). Außerdem wurde eine neue Sicherheitsinfrastruktur auf Grundlage der Vertrauenswürdigkeit der Anwendung sowie der Benutzeridentität eingeführt, was uns die Implementierung von Sandboxverhalten ermöglichte. Software wie Internet Explorer und Microsoft Office 2010-Anwendungen nutzten diese Sandboxes zur Erweiterung ihrer Sicherheit. Bei Windows 8 sorgen App-Container für eine zusätzliche Ausdehnung dieser auf Vertrauen basierenden Sicherheitsinfrastruktur.

Da die UAC die Sicherheitsinfrastruktur für App-Container bereitstellt, können Sie keine Windows Store-Anwendungen ausführen, wenn Sie die UAC deaktivieren. Deshalb empfehlen wir Kunden, die sich bei Windows Vista oder Windows 7 zur Deaktivierung der Benutzerkontensteuerung entschieden hatten, das Feature bei Windows 8 zu aktivieren, um so die Kompatibilitätsprobleme mit Standardbenutzern zu lösen, die sie vermutlich vorher veranlassten, die UAC zu deaktivieren.

Die UAC bietet auch für lokale Administratoren spürbare Vorteile. Durch Ausführen von lokalen Administratoren mit Sicherheitsanmeldeinformationen, die denen von Standardbenutzern sehr ähnlich sind, können die Benutzer, die am häufigsten auf lokale Administratorrechte angewiesen sind (z. B. Entwickler und IT-Administratoren) in einer Umgebung arbeiten, in der die von ihnen erstellten Softwareanwendungen und Skripts nicht zu weiteren unbeabsichtigten Abhängigkeiten von lokalen Administratorrechten führen. Diese Änderung hatte bereits erhebliche Auswirkungen für unabhängige Softwareanbieter (Independent Software Vendors, ISVs), die nun Software erstellen, die dank der UAC mit Standardbenutzerrechten fast immer einwandfrei ausgeführt werden kann. Dieselben Auswirkungen hat sie auch in Unternehmen.

Bei Windows Vista und höheren Versionen haben wir auch ein Feature namens Windows Resource Protection (WRP) hinzugefügt, das eine weitere Erweiterung der Windows-Sicherheitsinfrastruktur nutzt: die Möglichkeit, Ressourcen dadurch zu schützen, dass nur ein bestimmter Dienst darauf zugreifen darf, anstatt dies von der Identität des Kontos, unter dem der Dienst ausgeführt wird, abhängig zu machen. Das macht es sehr schwierig für eine Anwendung (meist ein Installationsprogramm, das bei Erstellung alle DLL-Abhängigkeiten enthielt), zusätzlich zu der von Windows 8 verwendeten Kopie versehentlich eine Kopie einer sehr alten Version einer System-DLL-Datei von Windows NT 4.0 (z. B. shell32.dll) zu schreiben, was ein ziemlich katastrophales Ergebnis hätte, wie Sie sich sicherlich vorstellen können. Stattdessen kann nur der Dienst, der Windows Update (den Windows Modules Installer-Dienst) verarbeitet, diese Dateien standardmäßig ändern. Außerdem wurden natürlich Wiederherstellungsoptionen für diese Anwendungen bereitgestellt, damit Fehler beim Schreiben auf diese Dateien nicht dazu führen, dass Ihre Anwendungen gar nicht mehr funktionieren.

Zurück zum Anfang


Verbesserung der Sicherheit

Schon von der Definition her führt die Erhöhung der Sicherheit dazu, dass bestimmte Dinge verhindert werden und Bösewichte davon abgehalten werden, bestimmte Vorgänge auszuführen. Es kann jedoch sein, dass Anwendungen darauf angewiesen sind, einige dieser Dinge tun zu können. Dies gilt besonders für ältere Anwendungen, die entwickelt wurden, bevor allgemein bekannt war, dass Unberechtigte Funktionen für böswillige Aktivitäten ausnutzen können. In einigen Fällen wurde eine Funktion zum Blockieren eines Verhaltens hinzugefügt, die es bisher nicht gab. In anderen Fällen haben wir die Standardeinstellungen so geändert, dass ein bestimmten Verhalten standardmäßig blockiert wird, während es zuvor standardmäßig erlaubt war und Sie das Blockieren explizit auswählen mussten.

Der geschützte Modus von Internet Explorer beispielsweise bietet eine Sicherheitssandbox, die dafür sorgt, dass die auf einer Seite gehosteten ActiveX-Steuerelemente nur unter bestimmten Umständen auf das Betriebssystem zugreifen können. Ab Internet Explorer 8 ist der geschützte Modus sowohl in der Zone „Internet“ als auch in der Zone „Eingeschränkte Sites“ standardmäßig aktiviert. Viele Kunden, die ActiveX-Steuerelemente benötigen, stellen fest, dass für ihre internen Formate die Zonenzuweisung zu der Zone „Lokales Intranet“ (die den geschützten Modus standardmäßig deaktivierte) nicht richtig funktioniert und halten diese Anwendungen daher für weniger kompatibel.

Mit Windows XP SP2 hat Microsoft Betriebssystemunterstützung für die Datenausführungsverhinderung (DEP) eingeführt. Die DEP ist ein Speicherschutzfeature, das von Software und Hardware unterstützt wird und Angriffe durch Schadsoftware auf das System mithilfe von Techniken wie Pufferüberlauf deutlich reduziert. Es schützt davor, dass schädlicher Code durch die Dateneinstiegspunkte einer Anwendung eingeschleust wird. Für maximale Kompatibilität ist die DEP auch bei Windows 8 so konfiguriert, dass sie ausgewählt werden muss. Bei neuen Windows Store-Anwendungen ist die DEP aktiviert, aber bei vorhandenen Desktopanwendungen werden DEP-Einschränkungen nur angewendet, wenn dieses Feature aktiviert wird. Bei Internet Explorer gab es ab Version 7 eine Auswahlfunktion für die DEP, und ab Version 8 war die Option standardmäßig aktiviert. Das bedeutet, dass für ActiveX-Steuerelemente, die dynamisch Code generieren und ausführen, aber deren Arbeitsspeicher nicht als ausführbare Datei markiert werden konnte, bei jedem Versuch zur Ausführung dieses Codes eine Ausnahme generiert wird (die, wenn sie von der Anwendung nicht behandelt wird, zu einem Absturz der Anwendung führt).

Für Kunden, die noch von Windows XP oder früheren Versionen migrieren, kann Sitzung 0-Isolierung beim Umstieg auf Windows 8 immer noch eine Herausforderung darstellen. Ein Windows-Dienst wurde bisher in Sitzung 0 ausgeführt, und dies ist auch heute noch so. Bei Windows XP und früheren Versionen wurde auch der erste Benutzer, der sich bei dem Computer anmeldete, in Sitzung 0 ausgeführt. Als die Computerressourcen noch sehr begrenzt waren, war dies ein effizienterer Ansatz. Doch obwohl sparsam mit den Ressourcen umgegangen wurde, entstand dadurch doch eine ziemliche Angriffsfläche für die Sicherheit, da Anwendungen, die in der Regel mit Berechtigungen für das lokale System ausgeführt wurden, neben anderen Anwendungen vorhanden waren, die mit weitaus weniger Berechtigungen ausgeführt wurden – eine verlockende Gelegenheit für Rechteerweiterungen. Deshalb werden Benutzer nicht mehr in Sitzung 0 angemeldet, diese Sitzung ist nur noch für Dienste vorgesehen. Dienstanwendungen, die erwarten, direkt mit dem Benutzer oder seinen Programmen kommunizieren zu können, müssen oft neue Mechanismen für diese Kommunikation finden.

Wir fügen Internet Explorer weiterhin neue Sicherheitsfeatures hinzu, da dies der Bereich des Betriebssystems ist, der am häufigsten mit möglicherweise bösartigen Programmen verbunden wird. Das Feature „Tracking-Schutz“ in Internet Explorer 9 und Internet Explorer 10 beispielsweise hilft Benutzern beim Schutz ihrer Privatsphäre, indem bestimmte Tracking-Programme blockiert werden. Viele der Seiten, die das Onlineverhalten nachverfolgen, stellen jedoch auch Funktionen für Webanwendungen bereit. Deshalb können viele Skripts möglicherweise nicht geladen und ausgeführt werden, wenn sie sich in einer von Ihren Listen für den Tracking-Schutz blockierten Domäne befinden.

In ähnlicher Weise schützt das Feature „SmartScreen-Filter“ in Internet Explorer Sie vor schädlichen Downloads. In Internet Explorer 8 schützt der SmartScreen-Filter Sie vor einer Liste bekannter schädlicher Downloads. Ab Internet Explorer 9 wurde mit dem SmartScreen-Filter auch die Zuverlässigkeit geprüft, sodass Downloads erst eine gewisse Zuverlässigkeit beweisen mussten, bevor sie als gut bewertet wurden. Andernfalls wurde eine Warnung generiert, dass es sich um einen neuen Download handelte, über den noch nicht genug bekannt war. Bei Windows 8 wird dieses Konzept auf das Betriebssystem übertragen. Auf diese Weise sind Sie vor Downloads geschützt, die noch nicht als zuverlässig bewertet wurden, unabhängig vom Browser, über den der Download bezogen wird. Dies kann jedoch in einigen Fällen zu Fehlern führen, wenn Sie häufig geänderte, aber nicht signierte ausführbare Dateien herunterladen, oder wenn es sich um seltenere Downloads handelt und über die Zuverlässigkeit der Anwendung noch nicht genug bekannt ist.

Zurück zum Anfang


Verbesserung von Leistung und Funktionen

Eine der Änderungen, die von Unternehmenskunden häufig als Grund für die Migration auf die neueste Windows-Version genannt werden, ist die Möglichkeit, die Funktionen und die Leistung eines 64-Bit-Betriebssystems zu nutzen. Die 64-Bit-Version bietet die Möglichkeit, Anwendungen auszuführen, die Zugriff auf große Mengen an Arbeitsspeicher benötigen, und eine große Menge an RAM zu nutzen. Dies kann jedoch auch Auswirkungen auf die Kompatibilität haben. Die 64-Bit-Version von Windows kann Ihre vorhandenen 32-Bit-Anwendungen ausführen, aber nicht Ihre vorhandenen 16-Bit-Anwendungen. Auch vorhandene 32-Bit-Gerätetreiber werden nicht unterstützt. Wenn Sie über Geräte ohne 64-Bit-Gerätetreiber oder kritische 16-Bit-Anwendungen verfügen, müssen Sie diese auf einem 32-Bit-Betriebssystem ausführen.

Weitere mögliche Auswirkungen für das Unternehmen bei der Ausführung von 64-Bit-Versionen von Windows sind die Auswirkungen auf .NET-Anwendungen, die mit systemeigenem Code zusammenarbeiten, entweder über COM Interop oder P/Invoke Interop. Die Standard-Compilereinstellung für .NET-Anwendungen lautet „Jede CPU“. Das bedeutet, dass diese Anwendungen auf einem 64-Bit-Betriebssystem zu 64-Bit-Anwendungen werden, auf einem 32-Bit-Betriebssystem jedoch zu 32-Bit-Anwendungen. Wenn sie in systemeigenem Code aufrufen, muss der systemeigene Code vom selben Typ (64- bzw. 32-Bit) wie die aufrufende Anwendung sein. Wenn die Anwendung also in nativen Code aufruft und dieser systemeigene Code als 32-Bit-Code kompiliert ist, kann die DLL mit diesem Aufruf nicht geladen werden. Glücklicherweise lässt sich dieses Problem relativ einfach lösen, entweder indem die Compilereinstellung geändert wird, oder indem die ausführbare Datei mithilfe des CorFlags-Dienstprogramms direkt geändert wird. Es soll lediglich auf das Problem hingewiesen werden, da es recht häufig Auswirkungen auf die Anwendungen von Unternehmenskunden hat.

Bei Windows Vista wurde ein neuer Anzeigemodus namens Desktopfenster-Manager (DWM) eingeführt. Der DWM änderte das herkömmliche Modell, bei dem Anwendungen direkt in Onscreen-Arbeitsspeicher gerendert wurden. Stattdessen wurden Anwendungen jetzt in Offscreen-Bitmaps gerendert, die dann vom DWM zusammengesetzt wurden, um die Anzeige für die Benutzer zu erstellen. Dieser Ansatz bietet beträchtliche Vorteile, sowohl in Bezug auf die Leistung als auch in Bezug auf die Benutzerfreundlichkeit. Verschiedene Arten von Anwendungen waren jedoch mit dem DWM nicht kompatibel. Für Unternehmen bestand die größte Auswirkung im Remoting von Anwendungen, die häufig Spiegeltreiber zum Umleiten der Anzeige verwendeten. Ab Windows 8 kann der DWM nicht mehr deaktiviert werden, da er nun eine zentrale Komponente der Betriebssystemumgebung darstellt. Wir haben unser Bestes getan, damit die meisten Anwendungen funktionieren. Es ist jedoch möglich, dass Anwendungen, die weiterhin auf älteren Ansätzen basieren, nicht immer funktionieren.

Ein wichtiger Leistungsaspekt für mobile Benutzer ist die Akkulaufzeit. Beim neuen Modell für Windows Store-Anwendungen in Windows 8 sind Anwendungen nicht nur Vollbildschirmanwendungen, sie werden außerdem angehalten, wenn sie nicht sichtbar sind. So belegen sie keine CPU-Leistung und tragen nicht zur Entleerung des Akkus bei. Bisher war es so, dass vorhandene Anwendungen immer ausgeführt wurden und dabei ab dem Zeitpunkt des Starts bis zum Schließen sowohl CPU- als auch Akkuleistung verbrauchten. Um selbst bei vorhandenen Desktopanwendungen längere Akkulaufzeiten zu ermöglichen, worauf die Benutzer hoffen (und was sie auch erwarten), werden vorhandene Dienstanwendungen bei Windows 8 gedrosselt, indem die Menge an CPU-Ressourcen, die verbraucht werden dürfen, begrenzt wird. Darüber hinaus werden inaktive Anwendungen angehalten, wenn sie nicht verwendet werden, und der Bildschirm wird geschlossen. Dies entspricht den Erwartungen der Benutzer (wenn Sie die Ein/Aus-Taste Ihres mobilen Geräts betätigen, erwarten Sie, dass Ihre Anwendung nicht mehr mit voller Leistung ausgeführt wird), kann jedoch bei Anwendungen, die nicht darauf ausgelegt sind, angehalten zu werden, zu einem Problem führen. Glücklicherweise sind diese Auswirkungen relativ gering.

Zurück zum Anfang


Erhöhung der Benutzerfreundlichkeit

Computerbildschirme enthalten immer mehr Pixel auf immer kleinerer Fläche. Deshalb ist es wichtig, den Bildschirm so zu verändern, dass die Anzeige größer wird, aber immer noch die volle, nicht interpolierte Auflösung des Bildschirms gewährleistet ist. Windows unterstützt seit mehreren Versionen hohe DPI-Werte, und diese Unterstützung wird mit jeder neuen Version verbessert. Ab Windows 7 war die Unterstützung für einen hohen DPI-Wert stabil genug, um mit der Ermittlung und standardmäßigen Verwendung von besser geeigneten DPI-Einstellungen je nach Bildschirm zu beginnen. Es gibt jedoch immer noch ein paar Anwendungen, bei denen hohe DPI-Werte ein Problem darstellen, und wenn ein Großteil der Geräte, die Sie bereitstellen möchten, von hohen DPI-Werten profitieren würde, empfehlen wir Ihnen, Ihre Anwendungen in diesem Szenario zu testen.

Zurück zum Anfang


Entfernung von veralteten Komponenten

Wir tun alles dafür, um auch weiterhin Kompatibilität mit älteren Anwendungen zu bieten. In einigen Fällen ist die Unterstützung bestimmter Features jedoch nicht mehr sinnvoll, entweder weil wir dann keine bessere Alternative bereitstellen können, oder weil ein Feature Schwächen hat, die verhindern, dass wir unsere gesteckten Ziele in Sachen Leistung, Zuverlässigkeit und Sicherheit erreichen. Ist dies der Fall, wird das Feature abgeschafft. Es ist zwar keine lange Liste, aber es gibt ein paar veraltete Features, die in Unternehmen zu Kompatibilitätsproblemen geführt haben und deshalb hier erwähnt werden sollen.

Seit Windows Vista bieten wir keine Unterstützung mehr für Kernelmodus-Druckertreiber. Grund dafür ist die Zuverlässigkeit, denn ein Fehler bei einem Kernelmodustreiber führt zu einem schwerwiegenden Absturz des gesamten Systems, während ein Fehler bei einem Benutzermodustreiber nur zum Absturz des Treibers führt. Wir haben so viele Funktionen wie möglich aus dem Kernelmodus entfernt – insbesondere aus Zuverlässigkeitsgründen –, ohne Abstriche bei unseren Leistungsversprechen machen zu müssen. Während die meisten Kunden keine Drucker mehr haben, die nur Kernelmodustreiber bereitstellen, sind diese manchmal noch bei High-End-Druckern und Plottern zu finden, die aufgrund ihres Preises eine längere Lebensdauer haben. Häufiger treten bei virtuellen Druckern Probleme auf, z. B. bei Druckern, die PDF-Dateien generieren. Ältere Versionen dieser Drucken nutzen oft Kernelmodustreiber, die nicht mehr ausgeführt werden.

Wir haben außerdem schrittweise WinHelp-Dateien als Hilfedateiformat entfernt. Dieses Dateiformat wurde 1990 für Windows 3.0 eingeführt. Mit Internet Explorer 4.0 haben wir 1997 das Nachfolgeformat, nämlich die HTML-Hilfedatei, bereitgestellt. Wir boten zunächst weiterhin Unterstützung für WinHelp-Dateien, entschieden uns aber ab Windows Vista aufgrund der zusätzlichen Angriffsfläche für die Sicherheit dafür, WinHelp aus den Betriebssystemeigenschaften zu entfernen. Die Hilfedateiinhalte waren so leistungsstark in diesem Format, dass sie einer ausführbaren Datei entsprachen. In Anbetracht der großen Menge von WinHelp-Inhalten, die in mehr als zwei Jahrzehnten Support generiert wurden, bieten wir jedoch weiterhin herunterladbaren Support für Windows Vista und Windows 7, und werden diese Unterstützung auch für Windows 8 bereitstellen.

Die Methode zur Anmeldung bei Windows ist seit langem erweiterbar, doch der Mechanismus, den wir verwendeten, erlaubte nur jeweils einen Anbieter. Dieser Mechanismus erforderte auch, dass die Anbieter sämtlichen Code entwickelten und die gesamte Benutzerumgebung für den Anmeldeprozess erstellten. Ab Windows Vista ersetzten wir dieses Modell durch das Anmeldeinformationsanbieter-Modell, bei dem die Entwickler nur den Teil der Authentifizierung implementieren müssen, der von dem bereits bereitgestellten abweicht, und das zudem die Möglichkeit der Zusammenarbeit mehrerer Anbieter bietet. Für diese Architekturänderung müssen jedoch alle Anwendungen mit alternativen Methoden zur Anmeldung bei Windows XP oder früheren Versionen neu entwickelt werden.

Zurück zum Anfang


Zusammenfassung

In diesem Artikel wurden einige Investitionen in Windows vorgestellt, die sich möglicherweise nachteilig auf die Kompatibilität Ihrer vorhandenen Anwendungen auswirken. Die Kompatibilität ist seit langem ein grundlegender Aspekt bei der Entwicklung von Windows, und wir nehmen Kompatibilitätsregressionen sehr ernst. Wir hoffen, dass dieser Artikel die Motivation hinter diesen Änderungen erklärt und ein besseres Verständnis der Kompromisse, die wir und auch Sie finden müssen, ermöglicht wird.

Beim Umstieg auf Windows 8 von Windows XP oder früheren Version kommt es häufig zu einer Fehlerquote von 20 Prozent oder mehr (wenn Sie besonders alte Software verwenden und lokale Administratordesktops ausführen), es stehen jedoch zahlreiche Wiederherstellungsoptionen zur Verfügung, mit denen ein Großteil dieser Fehler schnell behoben werden kann und die Ihnen Zeit zur Konzentration auf die Anwendungen verschaffen, die umfassendere Einriffe erfordern. Die Fehlerrate von Windows Vista oder höher auf Windows 8 liegt bislang im niedrigen einstelligen Bereich (und die Hauptursache dafür sind die lästigen hartcodierten Versionsüberprüfungen!). Insgesamt ermöglicht Ihnen Windows 8 aber, einen noch größeren Nutzen aus Ihren Investitionen in Softwareressourcen zu ziehen. Viel Glück bei Ihren Bemühungen um die Anwendungskompatibilität!

Zurück zum Anfang

Wichtige Aufgaben

Der Autor

Foto von Chris JacksonChris Jackson, auch als „ The App Compat Guy“ bekannt, ist Principal Consultant und Technical Lead des Windows Application Experience SWAT-Teams. Jackson ist ein weithin anerkannter Experte auf dem Gebiet der Windows-Anwendungskompatibilität. Die von ihm verfassten technischen Dokumente sowie seine Schulungs- und Dienstangebote werden bei Microsoft und auch in anderen Unternehmen genutzt und basieren auf langjähriger praktischer Erfahrung mit Unternehmenskunden und unabhängigen Softwareanbietern.

Er ist Autor und Mitautor einer Vielzahl von technischen Dokumenten und Artikeln zur Anwendungskompatibilität und schreibt Beiträge für das TechNet Magazine. Jackson ist auch Redner auf wichtigen Branchenkonferenzen auf der ganzen Welt, einschließlich TechEd, IT Forum und Microsoft Management Summit.

Verwandte Ressourcen

Bleiben Sie auf dem Laufenden