Wer mein Blog liest, der weiß, dass ich mich über das Fehlverhalten des Windows Explorers [1] unter Windows Vista als auch der aktuellen Beta von Windows 7 aufrege. Wie es aussieht, ist das ja alles so gewollt, und wir Deutsche müssen uns endlich abfinden, dass das eben nicht geht. (Oder doch nicht? Weiter unten ist die Lösung, für alle, die nicht weiterlesen möchten!)
Während meiner Tests habe ich die verschiedenen Sprachversionen noch einmal unter die Lupe genommen. Der übersetzte Begriff für Program Files kommt immer aus der desktop.ini:
[.ShellClassInfo] LocalizedResourceName= @%SystemRoot%\system32\shell32.dll,-21781
In der shell32.dll steht an Position 21781 eben Programme, im Französischen wird der Text Programmes genommen.
Um das fehlerhafte Verhalten in den Deutschen Versionen zu erklären, muss man eine ältere Windows Version installieren, z.B. Windows XP. Bei Windows XP hat man das Programme Verzeichnis auch so benannt, also das lag so wirklich auf der Festplatte. Im Französischen wurde Program Files verwendet, der übersetzte Text kam aus der desktop.ini.
Mit Windows Vista wollte man nun den besseren Weg gehen, Verzeichnisse sollte sprachunabhängig sein. Da es aber noch einige Programme gibt, die z.B. beim Installieren hart-kodiert C:\Programme verwenden, hat man die sogenannten symbolischen Verknüpfungen eingeführt. Diese sollten andere Programme automatisch auf die richtigen Verzeichnisse oder Programme umlenken.
Folgende Fehler gibt es bei den symbolischen Verknüpfungen:
Also, bei mir funktionieren die symbolischen Verknüpfungen nicht, oder ich habe den Sinn immer noch nicht verstanden.
* Endlich eine Lösung
Endlich habe ich mich getraut, und c:\Programme über die Kommandozeile gelöscht. Bitte nicht über den Windows Explorer, denn sonst erwischt man das echte Verzeichnis c:\Program Files.
Jetzt kann ich zwar keine alten Programme mehr verwenden, die direkt auf C:\Programme schreiben möchten, aber das will ich auch nicht.
Wer trotzdem den symbolischen Link braucht, kann diesen (wie auch eigene) mit folgendem Befehl wieder erstellen:
Toll, nach dem manuellen Ausführen von mklink.exe gehen auch alle meine .NET Testprogramme richtig. Wo ist nur der Fehler, warum geht das auf einem sauberen Windows Vista nicht richtig? Ich werde wohl doch keine Ruhe geben, und gleich einen virtuellen PC basteln, Nr. 1098.
Wie immer gilt, dass ich keine Garantie übernehmen kann. Also, vielleicht vorher alles ordentlich sichern oder so.