Bernd Rose schrieb:
> Am Fr, 18. Nov 2022 14:13:29 +0100, schrieb Takvorian:
>
>> Dialog [...] ist in der heutigen Zeit größtmöglicher Murks
>
> Schon richtig. Aber dann solltest Du die Großschreibung auch tatsächlich
> beachten: MURKS (= Masterful Usenet-Reading Keystone-Software). ;-P
Aha. :o)
> Btw.:
>> ein Programm, das in sein eigenes Programmverzeichnis schreiben will
>
> Dieser Ansatz ist auch heute noch normal und zulässig. Für die Umleitung
> der Schreibzugriffe der Nutzer auf AppData ist das System zuständig:
>
https://learn.microsoft.com/en-us/windows/apps/design/app-settings/store-and-retrieve-app-data
>| When an app is installed, the system gives it its own per-user data stores
>| for settings and files. You don't need to know where or how this data
>| exists, because the system is responsible for managing the physical
>| storage, ensuring that the data is kept isolated from other apps and
>| other users.
Aber nicht in der Art, wie es bei Dialog geschieht. Üblicherweise wird mit
erhöhten Rechten %ProgramFiles% beschrieben und danach im normalen Betrieb
nicht mehr beabsichtigt versucht, Daten dort abzulegen. Kein Entwickler, der
halbwegs bei Verstand ist, beabsichtigt sowas (Portable Apps ausgenommen =
Sicherheitsprobleme). Bei Dialog ist es so, Windows leitet es dann um nach
Virtual Store, dummerweise ist das Murks, funktioniert nicht richtig.
Was ebenfalls schlimmer Murks ist und leider aktuell praktiziert wird: das
Setup fragt heimtückisch, ob der User das Programm nur für sich installieren
möchte. Sagt er naiv "ja", kann es passieren, dass das Programm vom Setup
dann ohne erhöhte Rechte nach Appdata installiert wird, nicht nach
%ProgramFiles% und Malware ggf. dankbar problemlos Zugriff auf die
Programmdateien hat.
> Natürlich gibt es seit langem Spezialfunktionen (die Dialog noch nicht
> nutzt), mit denen Daten in AppData-Stores besser verwaltet werden können
> als durch systemseitig umgeleitete Schreibzugriffe, die ein Programm auf
> seine eigene Installations-Verzeichnisstruktur unternimmt. Aber Microsoft
> hat m. W. noch nirgends Anstalten unternommen, diesen "klassischen" Weg
> zu unterbinden.
Es unterstützt ihn sogar noch. Microsoft hat auch noch nie Anstalten
unternommen, OOBE ein sicheres System zu installieren, obwohl sie das
mühelos sofort machen könnten, via SRP zum Beispiel. Allerdings wären dann
alle Programme, die sich nicht an die Windows-Richtlinien halten, außen vor.
Statt dessen machen sie Wirrtualisierung, damit auch ja jeder üble Schrott
noch lauffähig ist.
> Die Probleme, welche Dialog mit UAC usw. hat,
Dialog hatte ja auch schon Probleme mit XP ohne UAC, hält halt grundsätzlich
nichts von Rechtetrennung.
> rühren nicht aus dem Programm
> selbst, sondern aus seinem Installer. Würde man sämtliche zu installierenden
> Dateien von Dialog in einen zeitgemäßen Installer packen, wäre das Problem
> vom Tisch.
Na denn, wer schreibt den Installer dafür? Freiwillige vor.
> Da dies schon aus Copyright-Gründen niemand machen wird,
Müsste man sich MM vorknöpfen. Es geht zwar das Gerücht, er sei nicht
erreichbar, aber das ist natürlich falsch. Es hat nur noch niemand wirklich
ernsthaft versucht.
Portable Installation dann aber bitte ohne die Setup.exe, sondern einfach
das schon fertige Programm als Archiv zum Download anbieten, das an
beliebige Stelle entpackt werden kann. Ich würde das sofort machen, dann
schaun mer ma, ob das MM aus Copyright-Gründen auf den Plan ruft.
IMHO geht eher das Kamel durchs Nadelöhr. <eg>