Aktuell \\FRANK-AT-WORK\$D\... womit es weniger Probleme gab, als wie mit \\?\D:\...
\\.\D$ ... sollte unter Umständen auch funktionieren. Der Punkt ist hier Platzhalter für den aktuellen Rechnernamen. Ist vielleicht etwas unkomplizierter als diesen vorab zu ermitteln.
Übrigens würde ich allen, die des Englischen mächtig sind, folgende Lektüre ans Herz legen:
The Definitive Guide on Win32 to NT Path Conversion. Das erklärt einiges rund um das Thema, wenn auch nicht exakt die Frage oben. Einiges davon kann man sich dann auch näher mit meinem
ntobjx oder mit WinObj von Sysinternals anschauen. Ach ja und
das hier ist vielleicht auch noch sinnvoll.
Ja, der Grund warum eine Anwendung selbst (über das Manifest) kundtun sollte, daß sie lange Pfadnamen versteht, sollte klar sein. Schaut man sich Funktionen wie
GetFullPathName sind dokumentiert mit
MAX_PATH als maximal zulässiger Länge. Wenn sich also die Entwickler daran hielten, haben die auch nur das
was damals MAX_PATH war reserviert. Bei dieser Funktion wäre es unproblematisch, aber ich entsinne mich, daß es Funktionen gibt, bei denen als Eingabe
keine Maximallänge des Puffers vom Aufrufer mitgegeben wird und dann fehlt der aufgerufenen Funktion natürlich die Info, ob das Programm bereits mit langen Pfaden kompatibel ist oder nicht. Daher ist das Manifest eine sinnvolle Möglichkeit dem
OS zu kommunizieren was Fakt ist.
Daher bringt der Manifest-Eintrag wohl eher längerfristig was, wer aktuell mit langen Pfaden arbeiten möchte muss wohl die \\?\ verwenden.
Das ist richtig.
Für mich lasse ich aber momentan lieber die Finger davon - solange das
OS keine vollständige Unterstützung bietet ist das Risiko Daten damit zu verstümmeln einfach zu groß.
Kannst du das bitte nochmal erklären? Das erscheint mir auf einem Mißverständnis aufzubauen. Wenn du
Unicode schon heute benutzt, kannst du sinnvollerweise schon heute davon profitieren, aber eben mit nem Präfix. Da verstümmelt dir das
OS nix. Das
OS unterstützt so einiges, was
Win32-Programmierer üblicherweise nicht zu Gesicht bekommen (bspw. Datei-/Pfadnamen die sich nur in Groß-/Kleinschreibung unterscheiden). Mit dem Präfix bist du sozusagen näher am
OS, aber der einzige Grund warum MAX_PATH früher 260 Zeichen war, ist, daß Windows 9x/Me auch unterstützt werden mußte. Und so hat man aus Kompatibilitätsgründen die Pfadlänge der
Win32-Funktionen auf NT begrenzt. Viele Beschränkungen auf den NT-basierenden Systemen sind dieser dogmatischen Rückwärtskompatibilität geschuldet. Hier hätte Microsoft auch den Weg von SUS/POSIX einschlagen können und bspw. ausschließlich auf Quelltextkompatibilität setzen können. Allerdings hättest du dann für jede größere neue Windowsversion ne eigene EXE auszuliefern.
Wer hält dich davon ab einen PWideChar-Puffer immer mit \\?\ vorzubefüllen? Du kannst ja beim Aufruf der entsprechenden
API-Funktionen ganz einfach diese 4 "verbrauchten" Zeichen abziehen und @lpPath[4] übergeben, oder? Ohnehin schreiben Pfade ja quasi danach als Objekte behandelt zu werden. So gesehen böte sich an die eigenen Pfadklassen einfach aufzubohren - da muß niemand tausende Quelltextstellen anpassen
Abgesehen davon ist die maximale Pfadlänge ohnehin eine eher verschwommene Angelegenheit. Die 32767 Zeichen sind Maximum und haben damit zu tun, daß
UNICODE_STRING (der gezählte Stringtyp der bspw. in der NT Native
API und damit auch im Kernelmode benutzt wird) eine 16-bittige vorzeichenlose Ganzzahl als Zähler (in Bytes! nicht Zeichen!) benutzt. Davon kann man pauschal gleich schonmal die vier Zeichen für den Präfix abziehen und eins für die
ASCII-Null am Ende. Und der Präfix wird normalerweise auch nochmal expandiert (siehe verlinkter Artikel oben und ntobjx).