Montag, 23. Januar 2012, 10:45
VirtualStore
Da hat mich vergangene Woche der Windows 7 VirtualStore doch tatsächlich erwischt
Für alle, die es bis jetzt noch nicht kannten: Windows 7 speichert unter bestimmten Umständen die Daten von Programmen nicht unter
Für alle, die es bis jetzt noch nicht kannten: Windows 7 speichert unter bestimmten Umständen die Daten von Programmen nicht unter
c:\Programs[Bla]\
sondern unter C:\Users[Benutzername]\AppData\Local\VirtualStore\Program Files
(obwohl die Applikation meint, es würde ins eigne Programm-Verzeichnis schreiben).
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Pascal
flo
Kai Pautsch
Sven
Es ist genau umgekehrt. Alle Programme die nach %programfiles% schreiben wollen werden redirecten, es sei denn, das Programm sagt explizit sei kompatibel (Manifest oder bspw. Compiler-Flag).
Dadurch wird sichergestellt, dass alte Programme eben nicht brechen und bei neuen Programmen der Hersteller eben sagen kann, sein Programm tut das nicht, er ist mit den Guidelines vertraut.
Wäre es so wie du es sagst, würden ja alle alten Programme gnadenlos brechen...
Kai Pautsch
Schreib mal ein Test-Programm in C oder C++, dass in C:\Programme\iwas versucht reinzuschreiben, es gibt in der Regel eine AccessViolation...
Kai Pautsch
Sven
Rate mal was hier Standard-Einstellungen sind... Richtig: Aktueller Compiler, Manifest... also gehen wir davon aus, der Programmierer hat ein aktuelles Programm, weswegen wir explizit Kompatiblitätshilfen wie den VirtualStore abschalten
Müsste jeder Entwickler von sich aus manuell sagen, "Mein Programm ist Windows Vista und besser geeignet", wäre es in meinen Augen zwar sauberer.
Da Microsoft aber gewisse Flags und Manifeste allgemein haben will, weil sie damit noch weitere Dinge steuern, hat man sich eben so entschieden. Das aktuelle Entwicklungsumgebungen bei neuen Projekten folglich diese Standards setzen, sollte nicht verwundern und ist richtig. Somit erklärt sich auch deine Beobachtung.
Da eben ein Hersteller sein Programm von vor Windows Vista ganz sicher nicht in einer aktuellen Umgebung neu übersetzen wird (wenn er etwas patchen wird, dann wird er anschließend in seiner gewohnten BUILD-Umgebung, die er vom RELEASE her hat übersetzen). Und wenn er das doch tut, weil er bspw. von den neuen Compiler-Flags wie DEP, ASLR und besserer Performance der Binaries profitieren will, dann zwingt Microsoft ihn eben auch dazu den Code dahingehend anzupassen. Tut er es nicht, bricht seine Anwendung eben mit einem Access Denied... was dann aber okay ist, schließlich gibt der Hersteller ja vor eine aktuelle Anwendung zu haben - dann muss er sich auch an aktuelle Guidelines halten (übrigens gab es die schon zu XP Zeiten... da hat sich nichts geändert, nur eben ist es auf Grund fehlender Benutzerrechte nur noch mit Aufwand möglich, dagegen zu verstoßen).
Bspw. glaubt man nicht, wie viele kleinere Software-Schmieden einfach ein Manifest in die Anwendung geklatscht haben, was Admin-Rechte anfordert. Damit war für die Hersteller das Problem gelöst und sie halten ihr Produkt für Windows Vista und besser geeignet. Da kann man nur hoffen, der Anwender nervt den Support und sucht sich bessere Alternativen.