Pfadseparator unter Windows (und DOS) - "\" oder "/"

Immer und immer wieder sehe ich in Quelltexten, Frameworks, Bibliotheken und Anwendungen fuer Windows, dass Pfadangaben ueberprueft und vorwaerts gerichtete Schraegstriche automatisch in rueckwaerts gerichtete umgewandelt werden. In ganz schlechten Implementierungen passiert das sogar auf mehreren Ebenen, also fuer ein und die selbe Zeichenkette mehmals. Und das alles, um "Plattformunabhaengingkeit" zu schaffen.

Die Wahrheit ist aber, dass sowohl Windows als auch MS-DOS im Kern mit beidem umgehen koennen. Das Problem ist die Shell (und andere Programme). COMMAND.COM und CMD.EXE benutzen (aus historischen Gruenden, CP/M) den Vorwaertsschraegstrich fuer die Einleitung von Programmoptionen. Sieht der Interpreter also einen vorwaerts gerichteten Schraegstrich, so ist das fuer ihn keine Pfadangabe sondern eine Programmoption.

Hier ein Zitat aus der MSDN Library:

Note File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections.

Das heisst, der Kern tut's eh, also lasst es bleiben. Um wirklich plattformunabhaengig zu sein, benutzt der vorwaerts gerichteten Schraegstich als Pfadtrennzeichen, wie es auch im POSIX-Standard geschrieben steht und warnt den Benutzer, wenn er einen rueckwaerts gerichteten verwenden will.

Die daraus resultierenden Vorteile sind einerseits die Steigerung der Performance - Zeichenkettenoperationen sind teuer - und andererseits die Vermeidung von Inkompatibilitaeten mit Systemen, die einen rueckwaerts gerichteten Schraegstrich nicht akzeptieren (wahrscheinlich alle anderen ausser Windows und DOS). Letztere auch sind der Anlass fuer diesen Artikel. Dabei normalisiert eine in Python geschriebene Anwendung mit FTP-Server-Komponente einen vom Benutzer eingegeben Pfad. Alle "/" werden von Python automatisch durch "\" ersetzt und damit ein vorher wahrscheinlich gueltiger FTP-Pfad in einen ungueltigen ueberfuehrt.

Eine Moeglich waere es, die Python-Quellen zu modifizieren und selber zu uebersetzen; dann funtioniert es bei mir und bei allen die "meinen" Python-Interpreter verwenden. Die andere Moeglichkeit ist es, nach der Normalisierung wieder alle "\" durch "/" zu ersetzen. Und somit wird aus dem urspruenglichen Ziel, plattformunabhaengig zu sein, ein echtes Laufzeitproblem.