Program Files(x86) überhaupt noch sinngemäß

[jfheins]

Zitat von EWeiss:

Bsp.
Ich starte die IDE VB6 aus Program Files(x86)\Microsoft Visual Studio\VB98 mit meinem VB6 Projekt.
Die erste Meldung VB6 kann nicht auf die Registry zu greifen.
Gut und schön, oder auch nicht.

Ich weiß nicht, ob VB6 hier das beste Beispiel ist. Aber der grundsätzliche Gedanke ist ja: Binaries nach C:/Programme und Daten nach Dokumente/AppData/ProgramData oder so. IN einer perfekten Welt würden sich die Programme dann gut starten lassen (C:/Programme wird ja vor Änderungen geschützt) und diese Programme können dann Daten (Word-Dokumente, Musikdateien/ Zeug) in anderen Ordnern lesen/schreiben.

Eine IDE ist hier nicht anders: Die IDE selbst sollte unter C:/Programme sein und die Nutzerdaten woanders. Dabei ist absolut nebensächlich, dass diese Nutzerdaten wieder kompilierte Programme sind.
Visual Studio legt die Daten unter "C:\Users\xxx\Documents\Visual Studio 2017\Projects" ab. Dort kann man auch ohne Adminrechte schreiben und schnell mal ne Änderung testen.

Leider kann man dort auch im gleichen Verzeichnis wie die Anwendung Daten speichern, was die Entwickler verführt, dies zu tun. Aber später (wenn ein Release veröffentlicht wird) sollte die Software beim Endnutzer ja wieder in C:/Programme landen. (oder dem Äquivalent "C:/Programme (x86)")

Kurzum: Bei alten Delphis kann man glaube ich den Standard-Projekte Ordner selbst einstellen, sobald man den nicht mehr unter C:/Programme hat, sollte es auch ohne Adminrechte gehen. Ich vermute bei VB6 ähnliches.

Zitat:

Anwendung die Vollzugriff auf Dateien oder der Registry benötigen

Oha, "Vollzugriff" gleich o.O ISt das dann ein Low-Level Datenrettungstool? Für einen Musikplayer sollte doch ein einfacher Zugriff reichen