LV-Applikationen erstellen die VISTA kompatibel sind

Hallo,

Ich sollte LV-Applikationen erstellen die VISTA kompatibel sind, irgendwie geht das aber nicht. (obwohl LV > 8.2 für VISTA ist)
Es geht z.BSP. um die UAC-Virtualisierungsdienste. (siehe http://zone.ni.com/devzone/cda/tut/p/id/5702)

Nun ist es so, das ich die Datei „c:Programmeirgendwasirgendwas.ini“ lesen möchte.
Aufgrund der UAC liegt diese Datei aber in „C:UsersusernameAppDataLocalVirtualStoreProgram Filesirgendwasirgendwas.ini“

LV bemerkt davon aber nichts, und liest die Datei „c:Programmeirgendwasirgendwas.ini“ .
Diese Datei ist aber nicht die aktuelle INI Datei, sondern diejenige die bei der Installation des irgendwas-Programmes geschrieben wurde. (irgendwas.exe ist eine fremde Windows2000.exe, kein LV)

Dasselbe gilt auch, wenn ich meine LV-Applikation unter c:Programme... installiere.
Da der Benutzer nun Einstellung geändert hat, kann er diese nicht mehr in der INI Datei speichern.
LV melden dann Zugriffsfehler, sollte die INI-Datei aber in „C:UsersusernameAppDataLocalVirtualStoreProgram Filesmeine LV Applikation..“ speichern.

Mache ich da was falsch oder geht das nicht automatisch ?
Hat jemand Erfahrung damit und kann mir einen Tipp geben?

Anzeige

' schrieb:Mache ich da was falsch oder geht das nicht automatisch ?
Hat jemand Erfahrung damit und kann mir einen Tipp geben?

Ich hab schon des öfteren folgendes gehört:

Das hängt mit der Rechteverwaltung auf Betriebssystemebene zusammen und damit, dass bestimmte Verzeichnisse für den Anwender respektive das Programm tabu sind. Das geht soweit - wie du ja festgestellt hast - dass Files automatisch vom Betriebssystem in den User-spezifischen Pfad umgelenkt werden, ohne dass der User davon was merkt (Virtual!). Angeblich soll der Effekt weg sein, wenn das Programm respektive der User volle Adminrechte hat.

Vista ist mir bisher zum Glück erspart geblieben.

' schrieb:Das hängt mit der Rechteverwaltung auf Betriebssystemebene zusammen und damit, dass bestimmte Verzeichnisse für den Anwender respektive das Programm tabu sind. Das geht soweit - wie du ja festgestellt hast - dass Files automatisch vom Betriebssystem in den User-spezifischen Pfad umgelenkt werden, ohne dass der User davon was merkt (Virtual!).

Komisch ist ja nur das das "fremde nicht VISTA Programm" das schreiben in das Virtual automatisch kann, und meine LV-Applikation nicht.

' schrieb:Angeblich soll der Effekt weg sein, wenn das Programm respektive der User volle Adminrechte hat.

Das ist so, nur geht das aus diversen Gründen nicht, und sollte ja auch anders gehen.

' schrieb:Vista ist mir bisher zum Glück erspart geblieben.

Du glücklicher..

Hallo RoLe,

Zitat:Komisch ist ja nur das das "fremde nicht VISTA Programm" das schreiben in das Virtual automatisch kann, und meine LV-Applikation nicht.

Eine Variante wie es hierzu kommen könnte ist, das das "fremde nicht VISTA Programm" sich den Zielpfad aus den lokalen OS (VISTA) Umgebungsvariablen zusammensetzt.

z.B: Set-Info für
LOCALAPPDATA
(TEMP,TMP) alte Welt

oder die Registry befragt:
HKEY_CURRENT_USERVolatile EnvironmentLOCALAPPDATA
(HKEY_CURRENT_USEREnvironmentTemp
HKEY_CURRENT_USEREnvironmentTmp)

' schrieb:Eine Variante wie es hierzu kommen könnte ist, das das "fremde nicht VISTA Programm" sich den Zielpfad aus den lokalen OS (VISTA) Umgebungsvariablen zusammensetzt.

Danke ImExporty, das wäre eine Möglichkeit, aber ich denke das es nicht so ist.
Ich kann den Pfad auch noch mit dem VI- Konstante "Temp-Pfad" oder via API shel32.dll/SHGetFolderPathA abfragen.

Mit allen abfragen komme ich auf den folgenden Pfad: "C:Users<username>AppDataLocal"
Es kann ja nicht sein, das ich je nach OS den Pfad zusammenfummeln muss. (bei Vista kämme da noch "VirtualStoreProgram Filesirgendwas" dazu, und ich vermute, dass das "fremde nicht VISTA Programm" davon nichts weis.)

Grundsätzlich gilt scheinbar folgendes: (siehe http://zone.ni.com/devzone/cda/tut/p/id/5702)

Zitat:Vista stellt automatisch fest, dass der Anwender keine ausreichende Berechtigung hat, die Datei dort zu speichern.
Windows Vista kopiert dann die Datei (falls bereits vorhanden) in:
C:Users<your_account>AppDataLocalVirtualStoreProgram Files<application>Setup.ini
Windows Vista erlaubt dann die Fortsetzung des Schreibvorgangs in der neuen Datei im Ordner VirtualStore. Für spätere Schreib- und Leseoperationen wird dann immer die Kopie der Datei im Ordner „VirtualStore“ verwendet. Für die Anwendung scheint die Datei weiterhin im Ordner „Programme“ (Program Files) zu liegen

Dieser Mechanismus funktioniert scheinbar nicht mit LV-EXE's, es kommt die Fehlermeldung Nr.8 LabVIEW: File permission error. You do not have the correct permissions for the file.

Entweder mache ich was falsch, oder niemand wendet LV in VISTA richtig an.

Für weitere Tipps, Infos und Links bin ich dankbar.
Hasta la VISTA
RoLe

Hallo RoLe,

' schrieb:Ich kann den Pfad auch noch mit dem VI- Konstante "Temp-Pfad" oder via API shel32.dll/SHGetFolderPathA abfragen.

Das Du/LV dies kannst, steht sicherlich ausser Frage. Mein Vorschlag bezog sich auf eine "fremde (böse) Applikation", die sich nicht unbedingt an die Mircosoft Sicherheits Idee hält und intern mit "Admin-Rechten" arbeitet, jedoch nach aussen brav auf die aktuellen Benutzerinformationen zugreift. Wir haben hier einige Sriptsprachen, die das leider genau so machen und immer viel "Spass" mit Verwendung deren "Standardpfade" und dem daraus resultierenden Verhalten.

Zitat:Für weitere Tipps, Infos und Links bin ich dankbar.

Eine Idee wäre z.B.: das Deine Applikation unangepasste Rechte hat. => Manifest- Kontrolle
viel Erfolg

Anzeige

Ich benutze Registry zum Abfragen des AppData Pfades in LV und speichere dort meine INI (besser gesagt XML) Dateien ab.
Aber das Problem liegt woanders. Du willst also eine fremde INI Datei ändern und anpassen. Erstens ist es nicht so toll, aber auch egal, es kann ja auch dafür viele Gründe geben.
Was ich nicht verstehe, warum kann ein anderes (LV-fremdes) Prog auf INI Dateien in für den Nichtadminbenutzer gesperrte Dateien zugreifenund diese abspeichern?
Oder verstehe ich was falsch? Ich benutze Vista schon seit der Zeit, als es rauskam.

Gruß, eg

Hallo ImExPorty,

' schrieb:Das Du/LV dies kannst, steht sicherlich ausser Frage. Mein Vorschlag bezog sich auf eine "fremde (böse) Applikation", die sich nicht unbedingt an die Mircosoft Sicherheits Idee hält und intern mit "Admin-Rechten" arbeitet, jedoch nach aussen brav auf die aktuellen Benutzerinformationen zugreift.

Ich wollte damit nur sagen, das ich nirgens den Pfad zum Virtualstore abfragen kann, denn muss ich mir selber zusammenbauen.
Das sind keine "böse Applikationen", diese funktionieren ja so wie unter VISTA erwartet. VISTA steuert diese automatisch im Hintergrund auf den Virtualstore.
Bei LV-EXE funktioniert das eben nicht.

' schrieb:Eine Idee wäre z.B.: das Deine Applikation unangepasste Rechte hat. => Manifest- Kontrolle

Das muss ich mir mal noch genauer anschauen, aber so wie ich das sehe, sollte es eigentlich mit den default (asInvoker) auch funktionieren. Zudem verwende ich LV, das ich mit solchem nicht runschlagen muss/sollte.
Das einfachste ist sicher, die Sicherheits Ideen von M$ auszuhebeln (Programme nicht in c:programme installieren, als Admin ausführen, usw.).
Es geht mir aber darum, das richtig umzusetzen und nicht irgendwie zum laufen zu bringen.

Gruss
RoLe

Hallo eg,

' schrieb:Aber das Problem liegt woanders. Du willst also eine fremde INI Datei ändern und anpassen. Erstens ist es nicht so toll, aber auch egal, es kann ja auch dafür viele Gründe geben.
Was ich nicht verstehe, warum kann ein anderes (LV-fremdes) Prog auf INI Dateien in für den Nichtadminbenutzer gesperrte Dateien zugreifenund diese abspeichern?
Oder verstehe ich was falsch? Ich benutze Vista schon seit der Zeit, als es rauskam.

Da verstehst du was falsch, es ist viel einfacher, hab das wohl zu kompliziert beschrieben.
Ich ändere keine fremde INI Datei, ich möchte diese nur finden und lesen.

Die „nicht LV/nicht für VISTA Programme“ funktionieren alle wie in VISTA erwartet. Bei Einstellungsänderungen innerhalb dieser Programme wird deren INI Datei anstelle von c:Programme... in c:user......virtualstore.. gespeichert. Diese Programme kennen nur c:Programme.. als Speicherort, VISTA biegt das nun um nach VirtualStore.
Bei LV Programmen funktioniert das nicht, das ist mein Problem. Ich verstehe nicht warum dieser VISTA interne Mechanismus bei den anderen Programmen funktioniert, bei den selber erstellten LV-EXE geht das nicht.

Zudem möchte ich diese „fremden INI-Dateien“ lesen. Der Pfad zu diesen Dateien wäre c:Programme.. sind aber im ..Virtualstore. Auch hier funktioniert dieser VISTA Mechanismus nicht. Ich kann nicht mit dem Standardpfad in LV auf c:programmefremdAppfremdApp.ini zugreifen und VISTA lenkt das um nach..Virtualstore

LabVIEW funktioniert so nicht richtig mit VISTA, finde ich.

' schrieb:Hallo eg,

Da verstehst du was falsch, es ist viel einfacher, hab das wohl zu kompliziert beschrieben.
Ich ändere keine fremde INI Datei, ich möchte diese nur finden und lesen.

Die „nicht LV/nicht für VISTA Programme“ funktionieren alle wie in VISTA erwartet. Bei Einstellungsänderungen innerhalb dieser Programme wird deren INI Datei anstelle von c:Programme... in c:user......virtualstore.. gespeichert. Diese Programme kennen nur c:Programme.. als Speicherort, VISTA biegt das nun um nach VirtualStore.
Bei LV Programmen funktioniert das nicht, das ist mein Problem. Ich verstehe nicht warum dieser VISTA interne Mechanismus bei den anderen Programmen funktioniert, bei den selber erstellten LV-EXE geht das nicht.

Zudem möchte ich diese „fremden INI-Dateien“ lesen. Der Pfad zu diesen Dateien wäre c:Programme.. sind aber im ..Virtualstore. Auch hier funktioniert dieser VISTA Mechanismus nicht. Ich kann nicht mit dem Standardpfad in LV auf c:programmefremdAppfremdApp.ini zugreifen und VISTA lenkt das um nach..Virtualstore

LabVIEW funktioniert so nicht richtig mit VISTA, finde ich.

VISTA könnte da noch eine extra Sicherheit haben und einer Applikation nur diese Extrabehandlung zukommen lassen wenn sie ein INI File im selben Directory anpassen will als die Applikation selber ist.

Windows hat dafür auch ein spezielles API GetPrivatProfile....() and friends (die automatisch die INI Datei der Applikation anspricht). Ich gehe mal davon aus dass VirutalStore nicht ein Mechansimus ist der auf File API Niveau ausgeführt wird sondern auf oben genannten API and friends. LabVIEW verwendet aber für die INI File VIs nicht dieses API sondern implementiert dies auf den normalen File IO Primitives. Etwas anderes wäre im Sinne der Multiplatformkompatibilität der INI file VIs auch nicht möglich, da die PrivateProfile APIs kein arbiträres INI File zulassen sondern immer nur das Applikations INI File ansprechen (exename mit path und mit der exe Endung in ini umbenannt).

Rolf Kalbermatter

PS: wenn ich mich nicht irre wird die standard Behandlung des INI Files für die LabVIEW eigene INI schon beachtet da LabVIEW dafür die GetPrivatProfileAPI verwendet.

Rolf Kalbermatter