Für seine Geheimniskrämerei ist Microsoft hinlänglich bekannt: Windows enthält seit jeher unzählige undokumentierte Schnittstellen und Protokolle, die dem Softwareriesen unter anderem Vorteile bei der Anwendungsentwicklung gegenüber Konkurrenten verschafft haben. Während Drittanbieter im Wesentlichen gegen die offizielle Windows-Schnittstelle "Win32" programmieren, existieren Möglichkeiten, unter Umgehung dieser Schnittstelle mittels direkter Systemaufrufe exklusive Funktionen zu nutzen und so etwa die Geschwindigkeit von Programmen zu erhöhen.
Vor Jahren ging zum Beispiel das Gerücht um, Microsoft habe mit der ersten Version seines Web-Servers "Internet Infomation Server" ein deutlich schnelleres Produkt auf den Markt bringen können als Netscape, weil die Konkurrenz gewisse Schnittstellen nicht kannte. Auch die Open-Source-Implementierung "Samba" des File-Server-Protokolls SMB kämpft seit Jahren mit Microsofts Geheimpolitik. Immer wieder hat der Softwareriese Details seines nicht offen zugänglichen Protokolls abgeändert. Das Samba-Projekt musste frei nach dem Hase-und-Igel-Prinzip in mühsamer Kleinarbeit die Kompatibilität mit Hilfe überarbeiteter Versionen wiederherstellen.
Entwickler helfen sich selbst
Doch so weit, wie vielfach kolportiert, ist es mit den geheimen Schnittstellen nicht her. Auch wenn Microsoft bisher seinen Windows-Quellcode nicht offen gelegt und APIs geheim gehalten hat, so haben doch Legionen von Entwicklern einen großen Teil der Schnittstellen durch Reverse Engineering entschlüsselt. Bestes Beispiel ist das Wine-Projekt, das durch die Nachbildung des Win32-API (Application Programming Interface) Windows-Programme unter Linux zum Laufen bringt.
Manch ein Windows-Experte ordnet die Debatten um die geheimen Schnittstellen sogar dem Bereich der Verschwörungstheorien zu. So etwa Mark Russinovich, der wie einige Fachkollegen ausführliche Informationen über die sagenumwobene "Native API" von Windows NT publiziert hat. Diese kaum dokumentierte API stellt Betriebssystem-Dienste auf Kernel-Ebene bereit und sitzt unterhalb der Win32-API, die im besser abgeschotteten User-Modus agiert. In seinem Beitrag "Inside the native API" schreibt Russinovich: "Die Native API offenbart einige Nuancen, die über dokumentierte APIs nicht verfügbar sind, aber die Mehrzahl der Funktionen sind auch über dokumentierte Wege zugänglich." (www.sysinternals.com/ntw2k/info/ntdll.shtml).
Eine pikante Note erhält Microsofts Ankündigung der API-Öffnung durch ein kleines Tool: Einige wenige Schnittstellen sollen laut Microsoft aus Sicherheitsgründen von der Veröffentlichung ausgenommen werden, darunter auch die Funktion "Windows File Protection" (WFP), die Systemdateien vor dem Überschreiben mit potenziell manipulierten Dateien schützt. Diese API ist jedoch bereits vor einiger Zeit von einem Insider entschlüsselt worden. Im Web kursiert ein Tool, das darauf basiert und den Windows-Dateischutz auf Wunsch aufhebt.
Während Microsoft vor dem Hintergrund der kartellrechtlichen Auseinandersetzungen mit der Offenlegung von technischen Dokumenten gute Stimmung machen will, sind nicht unbedingt alle Experten und Geschäftspartner von diesem Schritt begeistert. So haben Gateway, HP oder Sony etwa die restriktiveren Lizenzbedingungen beklagt.
Während der Softwarehersteller nämlich 272 APIs veröffentlicht, die von fünf so genannten Middleware-Anwendungen - darunter "Internet Explorer" und "Windows Messenger" - genutzt werden, hat das Unternehmen für 113 interne Protokolle ein kostenpflichtiges Lizenzprogramm ersonnen.
Skeptisch äußerte sich auch der Windows-Entwickler und Buchautor Matt Pietrek gegenüber COMPUTERWOCHE zur neuen Microsoft-Politik. Entscheidend ist für ihn die Frage, in welcher Form Microsoft den Code veröffentlicht, etwa als komletten Quellcode für verschiedene Dynamic-Link-Library-(DLL-)Dateien oder nur in Auszügen. Falls Microsoft den Quellcode weitgehend offen legt, wären Drittanbieter in der Lage, ihre eigenen Versionen von DLLs für kritische Systemfunktionen zu schreiben. "Dieser Umstand könnte zu massiven Stabilitätsproblemen führen, wenn Bibliotheken unterschiedlicher Hersteller auf einem System in Konflikt geraten", so Pietrek.
Neue Offenheit mit Haken
Eine andere wichtige Frage für Pietrek ist, wie der offen gelegte Code genutzt werden kann. "Wenn man über eine Funktion Bescheid weiß, heißt das nicht, dass man sie unkompliziert nutzen kann." Die internen Funktionen können nämlich nicht einfach aufgerufen werden, ohne Versionierungsfragen zu berücksichtigen.
Eine entscheidende Bedeutung scheinen die betroffenen APIs und Protokolle für Microsofts Strategie jedenfalls nicht mehr zu haben. Ohnehin sind die Redmonder mit .NET längst von den systemnahen Schnittstellen wie Win32 abgerückt, die strategischen Fragen der Zukunft stellen sich auf der .NET-Plattform um Standards wie Soap, XML oder die Common Language Infrastructure (CLI) neu.