Unix mit Microsoft: Windows Services for Unix 3.5

Interix emuliert ein Single-Rooted-Dateisystem, das echte und symbolische Links unterstützt. Das Root-Verzeichnis des emulierten Dateisystems ist das SFU-Installationsverzeichnis, wo Windows-Laufwerke als Geräte (Devices) dargestellt werden, so dass beispielsweise D: zu /dev/fs/D wird – wenn Dateien von separaten Windows-Datenträgern an leichter zugänglichen Stellen im Interix-Dateisystem erscheinen sollen, muss man sie per Hand verknüpfen. Es gibt ein paar Probleme mit Verzeichnispfaden und Dateinamen, die Leerzeichen enthalten, da einige Unix-Programme einige dieser Pfade nicht korrekt lesen können, obwohl Leerzeichen in Unix-Dateinamen generell gestattet sind und die mitgelieferten Shells mit Leerzeichen arbeiten können.

Die einzige Scriptsprache, die mit SFU ausgeliefert wird, ist Perl. Man kann Perl in der Unix-Umgebung installieren und, wenn man das ebenfalls bereitgestellte ActiveState Perl unter Windows installiert, Perl-Programme unter beiden Systemen laufen lassen. Allerdings arbeiten die beiden nicht zusammen, sodass in der einen Umgebung installierte Programmbibliotheken in der anderen nicht unbedingt verfügbar sind. Mit ein paar Tricks bei den symbolischen Links lässt sich das ändern, die Voreinstellung sieht dies aber nicht vor.

Interix behauptet, vollständig POSIX-kompatibel zu sein, was hier nicht bestritten werden kann. Das allein scheint aber nicht auszureichen, um Anwendungen von einer bestehenden Unix-Plattform auf Interix zu portieren. Im Test ließen sich GNU-Anwendungen nicht ohne Überredungskünste konfigurieren, kompilieren und installieren. Zum Beispiel ließ sich die Standard-Unix-Distribution von Python trotz erfolgreicher Kompilierung nicht installieren. Der Umstand, dass Interop Systems für zahlreiche GNU-Anwendungen spezielle Pakete zur Verfügung stellt, zeugt davon, dass eine Portierung von Anwendungen auf SFU nicht ganz so einfach ist, wie behauptet wird.

Alternativen

Es gibt durchaus Alternativen für den Betrieb von Unix-Anwendungen unter Windows, allerdings enthalten sie nur selten die anderen Services, die Microsoft hier bietet. Es wäre wohl möglich, selbst ein ähnliches Toolkit aus Produkten von Drittanbietern zusammenzustellen, aber das macht mehr Arbeit, als einfach SFU herunter zu laden. Man kann auch die Komponenten von SFU und anderen Toolkits miteinander mischen, um schließlich die gewünschte Kombination von Eigenschaften zu erhalten – vielfach muss man die Komponenten nicht einmal auf demselben Rechner installieren und hat doch dieselben Funktionen zur Verfügung.

Windows Services for Unix 3.5 ist ein nützliches Werkzeug für Entwickler, die in einer heterogenen Umgebung arbeiten, da man vom Desktop aus Scripts laufen lassen kann, die ansonsten auf einem separaten Host laufen müssten. Ebenso können Unix-Systemadministratoren einige Bestandteile von SFU verwenden, um Aufgaben genauso wie auf ihren Unix-Rechnern zu lösen. Wenn man sehr viel mit dem GNU-Toolkit arbeitet, ist man von SFU wahrscheinlich weniger beeindruckt, da man bei vielen Paketen erst dafür sorgen muss, dass sie korrekt installiert werden – keine unmögliche Aufgabe, aber eine, die den einen oder anderen Kunstgriff erfordert.

SFU ist interessant, weil es eine Art Einblick in die Pläne gewährt, die Microsoft für Windows hat – etwa mehr Administration über Befehlszeilen. Es ist unwahrscheinlich, dass SFU zum entscheidenden Faktor für eine Massenmigration bestehender Unix-Installationen zu Windows wird, wenn man sich aber bereits entschlossen hat, ganz auf Windows umzustellen, ist es gewiss eine Erleichterung. Wenn man Aufgaben, die normalerweise einen Unix-Rechner erfordern, unter Windows ausführen möchte, ist SFU ein annehmbares Toolkit.