Program Files(x86) überhaupt noch sinngemäß

Habe jetzt den Installationspfad meines Programms (aller Programme) auf C:\User\UserName\AppData\Roaming verlegt weil unter Program Files(x86)
einfach zu viele Einschränkungen vorhanden sind die einen vernünftigen Start der Anwendung mit all seinen Dateizugriffen strikt verhindert.

Welche Funktion hat dieser Ordner noch? Bzw. was für eine Berechtigung noch zu existieren wenn am ende keine Anwendung die Vollzugriff auf Dateien oder der Registry benötigen nicht mehr richtig funktionieren.

Meine Meinung dazu! Keine! Er ist einfach sinnlos.

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.

Jetzt starte ich VB6 mit Adminrechten der Fehler kommt logischerweise nicht mehr vor dafür aber andere.
Ich kann dann mit meinem Programm die ITaskbarList3 nicht mehr debuggen weil keine Funktion warum auch immer weitergeleitet wird.
Starte ich VB6 ohne Adminrechte funktioniert alles bis auf diverse Probleme die VB6 selbst blockieren.
Ich kann dann zum Beispiel keine Anwendung mehr in meinem Anwendungspfad erstellen weil die benötigten rechte fehlen.

Program Files? Was für Program Files welche Daten soll man da noch ablegen wenn diese von allen Seiten vom System heraus in ihrer Funktionsweise blockiert werden.
Selbst Spiele Anwendungen die immer diesen Pfad zur Installation angeben funktionieren nicht mehr ohne Adminrechte.
Von daher ist es uninteressant für einen Anwender auf 1 Computer diesen Pfad überhaupt noch zu wählen..
Es ist etwas anderes wenn mehrere User den Computer verwenden aber wann ist das schon der Fall?

Also abschließend dieser Ordner hat für mich einfach keine Berechtigung mehr.
Wollte das nur mal loswerden.

gruss

**Daniel**

Naja, ProgramFiles ist halt immer noch der vom Hersteller vorgesehene lokale Ordner für Installationen. Ja, es gibt da besondere Einschränkungen, deren Sinnhaftigkeit sich bei manchen mehr, bei manchen weniger schnell erschließt.
Der Roaming-Ordner macht halt das, was er soll: Wenn die Infrastruktur es vorsieht, dass Benutzer mit ihren Profilen an mehren Rechnern arbeiten können, dann wandert der Inhalt dieses Ordners mit. Das ist in vielen Fällen durchaus sinnvoll, wird aber erschwert, wenn jeder alles in besagten Ordner kopiert. Dafür ist er nicht vorgesehen und ein Domänen-Admin kann einem da schnell mal quer kommen.

AppData ist keine Entsprechung zu ProgramFiles.

Zitat:

Dafür ist er nicht vorgesehen und ein Domänen-Admin kann einem da schnell mal quer kommen.

Ja durchaus schlüssig nur wann befindet man sich als Privat Anwender und das ist nun mal die Masse in einer Domäne?

Zitat:

AppData ist keine Entsprechung zu ProgramFiles.

Mag so sein aber die einzige Alternative damit man ohne Kontrolle, Einschränkung mit seinem\einem Programm arbeiten kann.
Ja ich kann mein Programm so auslegen das es alle Berechtigungen erhält.. NUR wie in meinem Beispiel selbst wenn funktionieren sie nicht mehr so wie sie sollen
denn irgendwo ist immer etwas anderes was dann nicht mehr funktioniert.

PS:
VB6 ist in der "Hall of Fame" und wird nach Aussagen von M$ mit jeder Windows Version kompatibel sein auch wenn es für die IDE keinen Support mehr gibt.
Wenn dem so ist.. dann sollten sie es richtig machen oder es ganz einstellen. (Nur so nebenbei)

gruss

**Dalai**

Programme haben schon aus einem einfachen Grund im %ProgramFiles% zu liegen: Damit Nutzer an den Executables und DLLs keine Änderungen vornehmen können, ihnen DLLs unterschieben können, um z.B. irgendwelche Lücken der Programme auszunutzen, um z.B. an höhere Rechte zu gelangen. Weiterhin werden Verschlüsselungstrojaner wirksam eingeschränkt, wenn an möglichst wenigen Stellen Schreibrechte vorhanden sind. Und: Software Restriction Policies lassen sich geordnet und erheblich einfacher umsetzen.

Deine Schwierigkeiten mit %ProgramFiles% sind außerdem keinesfalls allgemeingültig.

Grüße
Dalai

**Alallart**

Zitat von EWeiss:

Welche Funktion hat dieser Ordner noch?

Den Schutz der Daten. Das Problem ist nicht der Ordner Program Files(x86), sondern eher die der Programmierer, die falsch programmieren. Das Problem was du hast ist IMHO weniger das Problem das Ordners, als das Problem des Programmierers.

Die Daten im Ordner Program Files(x86) sind vom System geschützt. Niemand außer dem Administrator kann sie ändern oder löschen. So ist das gewollt. Deshalb gehören dort alle Daten die geschützt werden müssen, z. B. EXE-Files, usw.

Nur glauben viele Programmierer dort auch ihre Ini (oder Ähnliches) ablegen zu können. Dafür ist der Ordner aber nicht gedacht.

Wenn du also nun deine Programme in AppData\Roaming ablegst, kann jeder Virus sie kompromittieren. Denn dieser Ordner wird nicht vom System geschützt. Auch können andere Programme in den Ordner etwas reinschreiben und so die Funktionsweise ändern. Oder irgendwer löscht einfach den Ordner.

Kein Program Files(x86), kein Schutz durch das System (meine Meinung).

**Alallart**

Nochwas, ich habe das VB6 übersehen. Laut Wikipedia ist VB6 von 1998. Das ist die Zeit von Windows 95 und 98. Für die beiden Betriebssysteme galten noch andere Regeln. Die kannten zwar schon den Programme-Ordner, der war aber kein (vom System) schreibgeschützter (bzw. gesicherter) Ordner. Da konnte jeder noch reinschreiben. Die Probleme fingen erst mit Windows XP, denn da wurden NT (Profi-Betriebssystem) und 9x (Konsumenten-Betriebssicherstem) vereinigt.

Um auf den Punkt zu kommen, viele (selbst professionelle) Programme die vor 2001 entwickelt wurden haben mit dem Ordner ihre Probleme.

**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

**jaenicke**

Zitat von EWeiss:

Welche Funktion hat dieser Ordner noch? Bzw. was für eine Berechtigung noch zu existieren wenn am ende keine Anwendung die Vollzugriff auf Dateien oder der Registry benötigen nicht mehr richtig funktionieren.

Weil es nur verhältnismäßig wenige Programme gibt, die einen solchen Zugriff benötigen. Das sind in der Regel Systemtools wie Partitionierungstools usw. und die bekommen dann ja ohnehin Adminrechte.
Aber bevor man diese gibt, sollte man sich genau überlegen, ob die Software diese wirklich für den gedachten Anwendungsfall benötigt.

Ich habe nun nicht gerade wenig Software installiert. Aber die funktionieren alle problemlos mit einer Installation unter Program Files inklusive meiner eigenen. Es gibt zwar Software, die sich auch nicht unter Program Files installiert, aber das sind meistens Programme, die sich selbst aktualisieren wollen wie Google Chrome. Das ist zwar der falsche Weg, aber auch die funktionieren unter Program Files normal, brauchen dann aber einen Dienst zur Aktualisierung.

Ältere Software läuft bei mir in einer VM mit dem dazu passenden Betriebssystem. Wobei das aktuell im Grunde nur noch Delphi 1 bis XE, Windows 3.x usw. zu Testzwecken ist. Produktiv nutze ich keine ältere Software mehr. Ältere Software oder mit älteren Entwicklungsumgebungen erstellte Software haben mit aktuellen Systemen eben durchaus Probleme. Und das gilt eben auch für VB6.

Es würde aber ja auch niemand auf die Idee kommen die Scheinwerfer aus einem Trabbi in einen 5er BMW einzubauen, also warum wird so viel alte Software statt in einer VM versucht unter neuen Betriebssystemen einzusetzen...

VB6 sollte eben besser in einer VM mit XP laufen und damit erstellte Software auch nicht unter Vista oder höher eingesetzt werden.

**Bernhard Geyer**

Program Files(x86) überhaupt noch sinngemäß - Ja, sehr.
Programm die darunter nicht laufen fliegen bei mir wieder runter.
Ebenfalls wird man das auch bei diversen Firmen haben.

Ein Programm das dies noch nicht kann hat scheinbar die letzten 20 Jahre nicht so richig mitbekommen.
Seit NT sind die Regeln bekannt.
Ab Vista wurden die Regeln mit der UAC verschärft eingesetzt.

Zitat:

Ein Programm das dies noch nicht kann hat scheinbar die letzten 20 Jahre nicht so richig mitbekommen.

VB6 wird von M$ weiterhin in allen Versionen von Windows unterstützt (Abgesehen von der IDE selbst) du scheinst etwas miss zu verstehen denn es ist legitim auch heute noch VB6 Anwendungen zu programmieren.

Mache es mal oder versuche es nur einmal in kleinem Stil dann wirst du erkennen das nicht alles so leicht dahingeklatscht werden kann wie in Delphi.
Es gibt kein Windows, System, Classes oder was ihr sonst noch so alles Vordefiniert bekommt da ist Handarbeit angesagt
auch einer der Gründe wo ich erkenne das viele Delphi Programmierer meist mit der WinApi32 überhaupt nicht zurecht kommen halt nur mit dem was Die Entwickler Umgebung von Delphi bereitgestellt hat ansonsten seit ihr doch aufgeschmissen.
Versuche doch mal die ITaskarList3 oder die Core Audio, IShellInterface in VB6 zu implementieren wenn du nichts hast.. Ich glaube da wärst du aufgeschmissen und wirst versagen..
Sorry aber so sehe ich das.

VB6 hat nun mal den Installation Pfad unter Program Files(x86) und das macht alle daraus resultierenden Probleme fast nicht lösbar was sich wie im Besipiel genannt schon beim kompilieren der Anwendung bemerkbar macht.
Aber das soll mich nicht davon abbringen mein Programm weiterhin zu nutzen und funktionstüchtig zu machen auch wenn das Resultat dieses ist das ich die Installation in einem nicht System spezifischen Order erstelle.
Glücklicher weise muss ich dich damit nicht behelligen so das du meine Anwendung erst gar nicht aus deinem System entfernen must.

Nebenbei das hat nichts mit dem Programmierer zu tun sondern mit den Gegebenheiten.
Das ich programmieren kann muss ich nicht erst noch beweisen bei meinen hier vorgestellten Projekten.

Zitat:

Für einen Musikplayer sollte doch ein einfacher Zugriff reichen

Bist du sicher? Mit meinen TypeLibs, ActiveX Dll's, OCX usw.. wenn dem so wäre würde mein Programm und VB6 unter besagten Pfad auch korrekt funktionieren.
Dem ist leider nicht so denn es ist immer wieder etwas anderes.
Zudem ist es kein Musikplayer sondern ein Multimedia Player mit dem ich sogar unter Win7 noch auf meinem PC Fernsehen konnte.
Leider musste ich diese Funktion deaktivieren da die Treiber unter Win10 nicht mehr funktionieren. (Nun Win10 mal wieder

)

Zitat:

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.

Nein ist es nicht.
Wenn ich in Delphi eine DLL dynamisch lade spielt es keine rolle wo sich diese befindet.
Bsp. MediaInfo.dll
In VB6 muss sich diese Datei um die Anwendung debuggen zu können im Pfad von VB6.exe befinden und zusätzlich im Anwendungspfad ansonsten wird sie nicht gefunden.
Du siehst also ich habe immer wieder irgendwelche negativen Einflüsse auf das verhalten von VB6 wenn die Anwendung unter Program Files(x86) kompiliert und oder Debuggt wird.

Bisher laufen meine Delphi Programme alle unter Program Files(x86) toi, toi aber selbstverständlich ist das nicht.
Wie gesagt irgendwie sinnlos dieser Ordner.

gruss