Win7: Virtualisierung austricksen?

[messie]

Moin,

beim Umstieg auf Win7 habe ich jetzt auch einige Dateien, die in "Eigene Dateien" , also C:\Dokumente und Einstellungen\Messie\Eigene Dateien... liegen. Die würde ich gerne weiter unter dem Pfad halten, die Virtualisierung verweigert das aber. Dateien unter C:\Benutzer werden mit den API-Abfragen "Eigene Dateien" scheinbar nicht gefunden.
Ich wollte dann lieber selbst "Dokumente und Einstellungen" anlegen, aber da bekomme ich die Meldung, dass es die schon gibt.
Es scheint also ein Verzeichnis "Dokumente und Einstellungen" zu geben. Kommt man da irgendwie dran?

Grüße, Messie

[Sir Rufo]

Wie der Pfad in Wirklichkeit heißt kann dir doch völlig schnuppe sein.

Lass Dir vom BS den Pfad zu den Dokumenten liefern, dass passt dann für jedes Windows-BS und du brauchst keinen Spagat zu machen.

[jfheins]

Die "Eigenen Dateien" von früher heißen jetzt (eigene) Dokumente und sind standardmäßig unter "C:\Users\xyz\Documents" zu finden.

[Sir Rufo]

Zitat:

Zitat von jfheins (Beitrag 1049342)

Die "Eigenen Dateien" von früher heißen jetzt (eigene) Dokumente und sind standardmäßig unter "C:\Users\xyz\Documents" zu finden.

Das ist eigentlich so nicht richtig.

Richtig ist (für alle Windows-Versionen): Die Dokumente liegen in dem Special-Folder mit Namen "CSIDL_MYDOCUMENTS"

Warum so? Weil man (der User) dieses auch umbiegen kann und dann befinden sich die Dokumente an einer Stelle, die nicht mehr vorhersehbar aber (wie man ja sieht) abfragbar ist.

Entscheiden muss man immer selbst.
Soll die Anwendung quasi immer funktionieren oder nur unter optimalen Bedingungen?

Im Anhang eine Unit, womit man die SpecialFolders sehr einfach abrufen kann.

Delphi-Quellcode:

function GetDirMyDocuments : string; // liefert den Pfad zu den Dokumeten

[messie]

Danke,

ich habe da auch schon ein paar Routinen aber nichts so Edles, was Deinem GetDirList enspricht :thumb:. Das habe ich gleich mal verwendet und habe mir die Pfade anzeigen lassen. Das Problem bestätigt sich: der alte Ordner "Eigene Dateien" (Personal) ist unter XP "C:\Dokumente und Einstellungen\Messie\Eigene Dateien" ist bei Win7 "C:\Users\Messie\Documents".
Nun liegt das Problem nicht in einer Software von mir, die relative Pfade wie Personal nutzt, sondern im Installshield, was absolute Pfade gespeichert hat. Und den Pfad "Dokumente und Einstellungen" kann wohl ich nicht anlegen, weil Win7 den selbst benutzt. Das heißt, "Dokumente und Einstellungen" (oder was auch immer nach dem internen XP-Redirect dahinter steht) müsste auch auf der Festplatte stehen. Wäre mal spannend, eine solche Platte in ein XP-System zu nehmen und sehen, was da wirklich steht.

Mein Problem bleibt erhalten: ich kann die absoluten Pfade von XP nicht unter Win7 reproduzieren und meine Installshield-Projekte wären damit Schrott :(.

Grüße, Messie

Edit: das Redirect führt auf "Documents and Settings" und scheint bei Win7 auch noch dazusein. Denn unter XP pro englisch kann ich sehr wohl einen Ordner "C:\Dokumente und Einstellungen" anlegen, nicht aber unter Win7 deutsch.

[Sir Rufo]

Ok, dann.weiß ich jetzt warum ich auf InnoSetup umgestiegen bin.
Da sind relative Pfade kein Problem

[Luckie]

Such dir ein Setup welches die Pfade richtig ermittelt. Und lass den Mist mit irgendwelchen Workarounds.

[Bernhard Geyer]

Zitat:

Zitat von messie (Beitrag 1049356)

..., sondern im Installshield, was absolute Pfade gespeichert hat. ...

Da hast du entweder eine Uralt-Installshield-Version oder du verwendest Installshield falsch. IS dürfte auch schon seit Jahrzehnten die offiziellen WinAPI-Funktionen zur Bestimmung der entsprechenden Verzeichnisse verwenden.

[rollstuhlfahrer]

selbstverständlich solltest du mit Hilfe der Kommandozeile (cmd) den Ordner "C:\Dokumente und Einstellungen\" erstellen können. Der Explorer wird dann nur damit nicht klar kommen und ihn im schlimmsten Fall 2x anzeigen.
Windows 7 hat als Grundstruktur C:\Users\ und da sollen alle benutzerbezogenen Daten rein. Damit man nicht für jede Sprache Teile von Windows neu kompilieren muss, hat MS sich was tolles einfallen lassen: Überall werden die englischen Namen verwendet und in der jeweiligen Desktop.ini steht dann drinnen, wie der Explorer diesen Ordner anzuzeigen hat. Heißt: Den Ordner, auf den du zugreifst existiert gar nicht, du kannst es aber trotzdem. Genauso verhällt es sich mit Programme zu Program Files. Das eine wird angezeigt, letzteres existiert. Ob man das jetzt gut heißen will oder nicht: Man muss sich damit abfinden.
Und wenn der Installer jetzt auf "C:\Dokumente und Einstellungen" eingefahren ist, gehört er entfernt. Was ist denn mit denen, die Windows nicht auf C: sondern auf D: haben? - Geht ganz einfach (Win XP, eigene Erfahrung). Bei der Installation unabsichtlich nen USB-Stick stecken lassen und schon ist der USB-Stick C: und Windows findet sich auf D: wieder. Folglich gibt es sogar Systeme, die ohne C: auskommen. Wie willst du diesen Nutzern klar machen, dass die Windows auf C: haben müssen, nur weil dein Installer mit was anderem nicht zurecht kommt?

In Fachzeitschriften wird unter dem Stichwort SSD dazu geraten, die persönlichen Daten auf eine Scheibenfestplatte nach D: zu schreiben (auch die Profile dahin umziehen), damit die nicht auf der SSD liegen (C:). Spätestens da wirst du deinem Installer sagen müssen, dass Eigene Dateien eben ein variabler Pfad ist.

Bernhard

[messie]

Moin,

ob andere Setup-Umgebungen das besser können, weiß ich noch nicht. Ich werde Installshield auch irgendwann kicken.
Die absoluten Pfade betreffen aber nicht die Installation, sondern sind die absoluten Pfade der Ursprungsdateien, die relativ zu installieren sind.
Ich verwende derzeit noch Installshield 2008, was in Sachen Installation (also Ziel) durchaus brauchbar ist.
Ob Innosetup auch die Ursprungspfade der Dateien im Setup relativ behandeln kann, ist mir nicht bekannt.

Grüße, Messie

[Sir Rufo]

Ja, kann InnoSetup

[generic]

Wenn du auf einen neuen Installer ausweichst, dann empfehle ich dir einen zu nutzen, welcher auf dem Windows Installer basiert.
Hat viele Vorteile das Ding. Reparaturinstallationen, Transaktionen während der Installation, Patches und kann von Admins prima in Netzwerken verteilt werden.

Dafür gibt es auch kostenlose Tools, wie z.B. den WIX.
http://wix.sf.net

btw. ich kann mir nicht vorstellen, dass Installshield 2008 das nicht kann. Nutzt ihr es vielleicht falsch? Keine Pfadkonstanten genutzt (wenn es die dort gibt)?

[mkinzler]

Ich finde dies gerade ein Vorteil von innoSetup, dass es nicht auf MSI setzt!

[Sir Rufo]

Zitat:

Zitat von mkinzler (Beitrag 1049460)

Ich finde dies gerade ein Vorteil von innoSetup, dass es nicht auf MSI setzt!

Ja das sehe ich auch so, aber den Vorteil mit der administrativen Verteilung innerhalb einer Domäne sehe ich auch bei MSI.
Aber man kann halt nicht alles haben.

[messie]

Zitat:

Zitat von generic (Beitrag 1049458)

btw. ich kann mir nicht vorstellen, dass Installshield 2008 das nicht kann. Nutzt ihr es vielleicht falsch? Keine Pfadkonstanten genutzt (wenn es die dort gibt)?

Für die Ursprungsdateien gibt es die nicht, nur für das Zielsystem.

BTW: wenn Innosetup den MSI nicht nutzt, wie funktionieren da Updates oder nachfolgende Versionen? Kann man da auch für jede Datei festlegen "nur ersetzen bei höherer Dateiversion", "nicht ersetzen wenn vorhanden", "mit Gewalt ersetzen"?
Denn das ist ja mit dem MSI durchaus komfortabel.

Grüße, Messie

[Sir Rufo]

Ja das geht alles.

Allerdings machen meine InnoSetups beimInstallieren einen automatischen UnInstall der alten Version (wenn erforderlich) und dann den Install.
Aber ein Patch würde auch funktionieren ist aber OutOfTheBox nicht so komfortabel wie bei InstallShield.

Dafür basiert InnoSetup auf reinen Text-Dateien und die lassen sich perfekt in ein SVN hineinbringen.

[mkinzler]

Geht aber. es gibt hierfür auch Erweiterungen, die z.B. Programme, die die Datei verwenden beenden können

[messie]

Zitat:

Zitat von mkinzler (Beitrag 1049465)

Geht aber. es gibt hierfür auch Erweiterungen, die z.B. Programme, die die Datei verwenden beenden können

Das hab' ich nicht verstanden.

Wie viele Sprachen unterstützt Inno denn?

Grüße, Messie

[mkinzler]

Zitat:

Das hab' ich nicht verstanden.

Wenn eine Datei in Benutzung ist kann man diese ja nicht ersetzen, deshalb gibt es eine Erweiterung, die diese Programme auflistet und die Möglichkeit bietet diese zu beenden.

Zitat:

Wie viele Sprachen unterstützt Inno denn?

Es gibt einige offizielle Übersetzungen

Man kann aber eigen basteln
http://www.freewebs.com/valarry/downloads.htm

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1049460)

Ich finde dies gerade ein Vorteil von innoSetup, dass es nicht auf MSI setzt!

Genau. Wenn ich sehe wie viel Probleme wir schon mit MSI-Installern hatten ...
Schönster Fall (Tests in VM): Firewall mit MSI-Installer. Verkonfigurierte Firewall hat normalen Boot gestört (Absturz). Gestartet in abgesicherten Modus zum Deinstallieren. Jedoch in abgesicherten Modus kann die Firewall nicht deinstalliert werden da die für MSI nötigen Dienste nicht funktionieren.

[messie]

Na, dann werde ich mal eines der nächsten Projekte mit InnoSetup probieren.

Für die alten Setups werde ich das Installshield wohl auf die XP-Partition installieren, die ich für ein paar alte D6-Projekte brauche.

Der doppelte redirect von Win7 (C:\User\Messie -> C:\Dokumente und Einstellungen\Messie ->C:\Documents and Settings) ist trotzdem Pfusch

Danke, Messie

[xaromz]

Hallo,

Zitat:

Zitat von messie (Beitrag 1049483)

Der doppelte redirect von Win7 (C:\User\Messie -> C:\Dokumente und Einstellungen\Messie ->C:\Documents and Settings) ist trotzdem Pfusch

hierzu möchte ich noch ein paar Anmerkungen machen: Das Problem hierbei ist, dass es seit Vista eine Verbindung (Junction) gibt, die "Documents and Settings" auf "Users" mappt. In der deutschen Version gibt es eine zusätzliche Verbindung "Dokumente und Einstellungen" (einfach mal in der Shell "dir c:\ /a" eingeben). Deshalb kann man diese Ordner auch nicht erstellen, sie sind schon da. Die Rechte dieser Verbindungen sind aber so gewählt, dass normale User keinen Zugriff darauf haben. Deshalb bekommt man normalerweise auch ein "Zugriff verweigert".

Gruß
xaromz

[H4ndy]

InstallShield kann schon seit Jahren mit den Windows-Pfaden umgehen, wir bis vor kurzem noch ein Uralt-IS (glaub sogar Express) aus der Zeit von Delphi 5 oder 6 im Einsatz gehabt und konnten damit problemlos auch auf Vista/7 installieren (inkl. Dateien, welche in die "Common Appdata" mussten, welche unter XP unter All Users\Anwendungsdaten\ und unter 7 in ProgramData verweilen). Also irgendwas musst du da falsch gemacht haben ;)

Setzen übrigens aktuell auf IS 2010 und bauen damit MSI-Only-Installer ohne Probleme.

[messie]

Zitat:

Zitat von H4ndy (Beitrag 1049498)

InstallShield kann schon seit Jahren mit den Windows-Pfaden umgehen, wir bis vor kurzem noch ein Uralt-IS (glaub sogar Express) aus der Zeit von Delphi 5 oder 6 im Einsatz gehabt und konnten damit problemlos auch auf Vista/7 installieren (inkl. Dateien, welche in die "Common Appdata" mussten, welche unter XP unter All Users\Anwendungsdaten\ und unter 7 in ProgramData verweilen). Also irgendwas musst du da falsch gemacht haben ;)

Setzen übrigens aktuell auf IS 2010 und bauen damit MSI-Only-Installer ohne Probleme.

Ja, auf dem Zielsystem. Hier geht es aber um das Quellsystem. Eine Datei aus "Eigene Dateien" wird beim Öffnen des Projekts unter Win7 nicht gefunden.

[Die Muhkuh]

Zitat:

Zitat von H4ndy (Beitrag 1049498)

InstallShield kann schon seit Jahren mit den Windows-Pfaden umgehen, wir bis vor kurzem noch ein Uralt-IS (glaub sogar Express) aus der Zeit von Delphi 5 oder 6 im Einsatz gehabt und konnten damit problemlos auch auf Vista/7 installieren (inkl. Dateien, welche in die "Common Appdata" mussten, welche unter XP unter All Users\Anwendungsdaten\ und unter 7 in ProgramData verweilen). Also irgendwas musst du da falsch gemacht haben ;)

Das kann ich bestätigen. Den Installer von Delphi 5 hatten wir bis vor kurzem auch noch im Einsatz.

Allerdings sind wir dann auf InstallAware, welches auch MSI-Installer erzeugt, übergegangen.

[H4ndy]

Zitat:

Zitat von messie (Beitrag 1049500)

Ja, auf dem Zielsystem. Hier geht es aber um das Quellsystem. Eine Datei aus "Eigene Dateien" wird beim Öffnen des Projekts unter Win7 nicht gefunden.

Aso, es kommt hier auf die Machine an, die den Installer erzeugen soll. Sorry, dann war meine Antwort quasi überflüssig.
In dem neueren IS kann man Projekte als XML abspeichern statt Binär und dann von Hand per Suchen & Ersetzen die Pfade anpassen. Wäre zumindest eine Möglichkeit.

[messie]

Im Prinzip geht es ja hier nur beispielhaft um das Problem, dass man absolut gespeicherte Special-Folders-Pfade nicht von XP nach Win7 portieren kann, also die Virtualisierung nicht abwärtskompatibel ist. Ich habe zum Glück mit Vista nur getestet, sonst hätte ich mich schon ein paar Jahre früher drüber geärgert :-D