[erledigt] Pfad wird nicht gefunden

[Jan-Hendrik]

Ah okay, danke!

[Carsten Hölscher]

Ich war eigentlich recht sicher, dass das auch mit mehreren Nutzern ging, das wurde ja mit dem Testprogramm in allen möglichen Varianten getestet.

Carsten

[Judith Montgomery]

Ich bin jetzt auch mal dazugekommen, auf meinem "Problem-Netbook" das Testprogramm zu starten. Der Installer trägt den Datenpfad noch korrekt unter HKLM ein, aber dann wird es äußerst kurios: Auch bei kommt die Meldung "Fehler beim Lesen von HKLM/Software/Zusi3Test, und das Feld Datenpfad bleibt leer - trotz offensichtlich vorhandenem Eintrag mitsamt passender Leserechte.

Ich habe dann spaßeshalber mal händisch den Zusi3Test-Schlüssel unter HKCR/VirtualStore/MACHINE/SOFTWARE/ erstellt (was nur mit einem als Admin gestarteten Regedit und dem Umweg über HKU/<UID>_Classes/... ging), und der eindeutigen Erkennbarkeit halber mit einem abweichenden, nicht existierenden Datenpfad versehen. Den Eintrag unter HKLM habe ich auf einen anderen, nicht existierenden, Pfad geändert. Ergebnis: Zusi-Test kann den Registry-Schlüssel nun auslesen - liest aber nicht etwa den Wert aus dem VirtualStore, sondern just den unter HKLM, den es vor dem Eingriff verschmäht hat.

UAC ist auf dem Netbook übrigens auf Maximum gestellt, und die ganze Aktion lief mit einem eingeschränkten Benutzerkonto - ja, ich habe da leicht masochistische Neigungen, was das angeht. Warum die gleiche Operation unter augenscheinlich gleichen Voraussetzungen unter dem gleichen Betriebssystem in meiner virtuellen Maschine anstandslos funktioniert hat, muss ich nicht verstehen...

Auf die übrigen Schritt im Testprogramms habe ich verzichtet, ich nehme mal an, dass die funktionieren würden, nachdem auch die Zusi-3-Demo läuft (nachdem ich den Pfad per Symlink zurechtgebogen hatte).

Es scheint also in der Tat an der Verzeichnis- bzw. Registry-Virtualisierung zu liegen, und an der großartigen Heuristik von Windows 6.x, die wohl mal wieder auf grandiose Weise scheitert bei dem Versuch, zu erraten, ob ein Programm böse oder gut ist, ob es also folglich in den VirtualStore eingesperrt werden muss oder nicht. Musst Du Windows vielleicht mittels eines entsprechenden Manifests in der .exe-Datei glaubhaft versichern, dass Du Dir der Risiken und Nebenwirkungen bewusst bist, und nach aufmerksamem Studium der Packungsbeilage freiwillig darauf verzichtest, etwas Verbotenes zu tun (oder etwas, das nicht explizit erlaubt ist)?

Judith

[Carsten Hölscher]

Mit der Thematik habe ich mich bisher auch noch nicht befaßt. Läßt sich das wirklich per manifest-Datei regeln? Das wäre ja ein ziemlicher Witz, oder verstehe ich da was nicht?

Carsten

[Judith Montgomery]

Wirklich befasst habe mich damit auch noch nie, und die paar Fetzen, die ich zu dem Thema aufgeschnappt habe, sind lange her. Aber wenn ich das richtig verstanden habe, muss ein Programm Windows irgendwie zu verstehen geben, dass es über die verschärften Sicherheitsbestimmungen ab Vista bescheid weiß, damit es von Windows' Heuristik unbehelligt bleibt, die halt oft genug völlig grundlos zuschlägt.

Wenn ich mich recht entsinne, hatte ich mal so ein ähnliches Problem mit dem Programm "patch" - was ja fast so ähnlich wie "setup" klingen könnte, und deswegen zwangsweise mit erhöhten Rechten gestartet wurde, mitsamt Abfrage des Admin-Passworts. Das ließ sich durch nachträgliches Einbetten eines entsprechenden Manifests in die .exe-Datei beheben. Frag mich nicht nach Details - das habe ich damals streng nach Schritt-für-Schritt-Anleitung gemacht.

Anschließend kann das Programm dann trotzdem machen, was es will, denke ich - im Zweifelsfall kommt halt eine Fehlermeldung wie "This operation requires elevation", oder so, wenn es nicht von sich aus zur passenden Zeit erhöhte Rechte anfordert. Aber es wird nichts mehr ins Nirvana - äh, ich meinte in den VirtualStore umgeleitet.

Eine kurze Anfrage bei der Suchmaschine meines geringsten Misstrauens warf ein paar Links aus, die vielleicht interessant sein könnten:

http://msdn.microsoft.com/en-us/library/bb756960.aspx
http://msdn.microsoft.com/en-us/library/bb756929.aspx
http://math.nist.gov/oommf/software-pat ... dows7.html

[Carsten Hölscher]

In den nächsten Tagen werde ich nicht dazu kommen. Falls jemand Luist hat, da mal etwas genauer zu forschen, wäre das super.
Wenn ich die Schreibdichte mancher Leute hier anschaue, dann scheint es durchaus noch freie Energie zu geben.

Carsten

[Mirko]

Hi,

habe eben Zusi 3 auf dem Laptop installiert. Bei der Installation wird man ja nach dem Pfad fürs Arbeitsverzeichnis gefragt. Da ich das nicht in den Windows-Dokumenten haben will, habe ich den Pfad auf D:\Zusi3Demo\Dokumente gelegt. Dort wurde es auch angelegt und die Dateien rein installiert, aber Zusi hat in seinen Einstellungen noch C:\Users\Public\Documents\Zusi3\ stehen. Änderungen kann man an den Pfaden auch nicht vornehmen, das Eingabefeld ist tot.

Mirko

EDIT: mit dem Druck auf "Senden" gefunden - dass man zum Einstellen von Programmoptionen ein separates Verwaltungsprogramm öffnen muss ist *ähm* unintuitiv, zumal wenn man es nur muss, weil die Installation den Wunschpfad halb umsetzt und halb nicht, man also nur die Installation korrigieren muss.

[Hopper]

Da ist wohl etwas schiefgelaufen. Was ist denn, wenn du Zusi3 nochmal neu installierst? Mit regedit kennst du dich aus?

[Carsten Hölscher]

Ich schiebe es mal in das Thema, was vermutlich dieselbe Problemstellung diskutiert.

Carsten

[Judith Montgomery]

Läßt sich das wirklich per manifest-Datei regeln?

In der Tat, so ist es - und zwar mit folgender:

Code: Alles auswählen

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
	<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
		<security>
			<requestedPrivileges>
				<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
			</requestedPrivileges>
		</security>
	</trustInfo>
</assembly>

Das Zauberwort ist wohl der requestedExecutionLevel asInvoker. Eingebunden per

Code: Alles auswählen

cd \Pfad\zu\Zusi3Test
mt -manifest manifest.xml -outputresource:Zusi3Test.exe;1

von einem Visual-Studio-Command-Prompt aus (also halt einem, bei dem die Platform-SDK-Binaries im Pfad sind), lässt das Test-Programm den albernen Umweg über den VirtualStore brav sein, und liest den Daten-Pfad direkt aus HKLM, wie sich das gehört.

Das gleiche Manifest in ZusiSim.exe eingepflanzt bewegt selbigen ebenfalls dazu, sein Datenverzeichnis auf direktem Wege zu finden, ohne Umweg über Symlinks oder ähnliche Verrenkungen. Dafür erkennt der Fahrsimulator damit die DirectX-Version nicht mehr richtig: im Info-Fenster steht nun statt 4.09.00.0904 nur lapidar -unknown- - was der Funktion des Simulators aber keinen Abbruch zu tun scheint. Vielleicht habe ich mit der Transplantation nur das vorhandene Manifest zerstört (ich habe natürlich versäumt, vorher zu überprüfen, ob ZusiSim.exe bereits ein Manifest hat)?

Das Manifest-Tool mt ist bei Visual Studio dabei, und sollte (angeblich) auch beim Platform SDK dabei sein. Keine Ahnung, ob die Delphi-IDE das auch von sich aus kann bzw. dabei hat. Bei Bedarf kann ich Dir auch gerne die gepatchten .exes zukommen lassen.

Hope this helps.
Judith

[Carsten Hölscher]

Besten Dank, mein Delphi wird das vermutlich nicht direkt unterstützen. Das sollte ich aber schon selbst hinbekommen können, sonst wird's kompliziert in der Handhabung.
Externe manifest-Datei wie bei .Net geht nicht?

Carsten

[Audisline]

Wenn ich Zusi 3 Starte als Admin dann klappt es auch. Aber trozdem zeigt er mir den Zeitstrahl nicht an. Ich habe das Testprogramm von Carsten auch mal laufen lassen.

Als Admin:

Microsoft Windows NT Version 6.01.7601
Leseversuch: HKEY_LOCAL_MACHINE/Software/Zusi3Test/DatenDirDemo
erfolgreich: HKEY_LOCAL_MACHINE/Software/Zusi3Test/DatenDirDemo
Versuche Invertierung: C:\Users\Public\Documents\Zusi3Test\\ZusiTestverzeichnis\zugassistent.bmp -------------
Geladen: C:\Users\Public\Documents\Zusi3Test\\ZusiTestverzeichnis\zugassistent.bmp
Invertiert gespeichert: C:\Users\Public\Documents\Zusi3Test\\ZusiTestverzeichnis\zugassistent.bmp
Versuche Dateierzeugung: C:\Users\Public\Documents\Zusi3Test\\ZusiTestverzeichnis\test\neuedatei.txt -------------
Verzeichnis erzeugt: C:\Users\Public\Documents\Zusi3Test\\ZusiTestverzeichnis\test
Datei erzeugt: C:\Users\Public\Documents\Zusi3Test\\ZusiTestverzeichnis\test\neuedatei.txt
Versuche Dateiänderung: C:\Users\Public\Documents\Zusi3Test\\ZusiTestverzeichnis\test\neuedatei.txt -------------
Datei gelesen: C:\Users\Public\Documents\Zusi3Test\\ZusiTestverzeichnis\test\neuedatei.txt
Datei geschrieben: C:\Users\Public\Documents\Zusi3Test\\ZusiTestverzeichnis\test\neuedatei.txt
Schreibversuch: HKEY_LOCAL_MACHINE/Software/Zusi3Test/DatenDirDemo
erfolgreich: HKEY_LOCAL_MACHINE/Software/Zusi3Test/DatenDirDemo
Leseversuch: HKEY_LOCAL_MACHINE/Software/Zusi3Test/DatenDirDemo
erfolgreich: HKEY_LOCAL_MACHINE/Software/Zusi3Test/DatenDirDemo


Als Benutzer:
Microsoft Windows NT Version 6.01.7601
Leseversuch: HKEY_LOCAL_MACHINE/Software/Zusi3Test/DatenDirDemo
erfolgreich: HKEY_LOCAL_MACHINE/Software/Zusi3Test/DatenDirDemo
Versuche Invertierung: \ZusiTestverzeichnis\zugassistent.bmp -------------
Versuche Dateierzeugung: \ZusiTestverzeichnis\test\neuedatei.txt -------------
Verzeichnis erzeugt: \ZusiTestverzeichnis\test
Datei erzeugt: \ZusiTestverzeichnis\test\neuedatei.txt
Versuche Dateiänderung: \ZusiTestverzeichnis\test\neuedatei.txt -------------
Datei gelesen: \ZusiTestverzeichnis\test\neuedatei.txt
Datei geschrieben: \ZusiTestverzeichnis\test\neuedatei.txt
Versuche Invertierung: \ZusiTestverzeichnis\zugassistent.bmp -------------
Schreibversuch: HKEY_LOCAL_MACHINE/Software/Zusi3Test/DatenDirDemo
erfolgreich: HKEY_LOCAL_MACHINE/Software/Zusi3Test/DatenDirDemo
Leseversuch: HKEY_LOCAL_MACHINE/Software/Zusi3Test/DatenDirDemo
erfolgreich: HKEY_LOCAL_MACHINE/Software/Zusi3Test/DatenDirDemo


Lg Dennis

[Alwin Meschede]

Die Probleme mit Verzeichnisrechten müssten seit der Demo 3.0.6 abschließend erschlagen sein.