Echter Ordnername für c:\Programme ab Vista

[gmc616]

Hallo DP,

meine Anwendung soll die Möglichkeit bieten, per Butten eine fremde Anwendung zu starten.
Um die Echse, welche gestartet werden soll, zu finden, schaue ich in der Registry nach, denn dort hinterlegt diese Anwendung ihren Anwendungsordner "AppPath".

Dummerweiße steht dort aber z.B. 'C:\Programme\TheApp' drin. Wie wir ja alle wissen gibt es ab Vista den Ordner 'C:\Programme' nicht mehr, sondern nur noch 'C:\Programm Files' bzw. 'C:\Programm Files (x86)'. Ein Aufruf per "ShellExecute" schlägt somit fehl.

Nun die Frage: Gibt es eine Möglichkeit den Ordnernamen 'C:\Programme\TheApp' in den korrekten, existierenden Ordnernamen zu wandeln?

Die Fremdanwendung muß nicht zwingend in 'C:\Program Files' liegen, genauso könnte irgendwo unter 'C:\Users' oder einen 'ganz normalen' Ordner liegen.

Meine Idee mit SHGetLocalizedName bringt mir immer nur '%SystemRoot%\system32\shell32.dll' zurück, wobei sich mir allerdings nicht erschließt, wieso diese Funktion mir immer den Path zur "shell32.dll" zurück gibt. Aber egal. Diese Funktion ist m.E. eh die falsche, da (wenn ich es richtig verstanden habe) sie mir den übersetzten Path aus den realen Path zurückt gibt. Ich bräuchte es aber genau umgekehrt. Funktionieren müsste das Ganze unter XP-SP3/Vista/7/8 32bit sowie 64bit.

Jemand Ideen?

Danke und Grüße
gmc

[Sir Rufo]

Also diese andere Anwendung trägt einen völlig falschen Ordner als AppPath in der Registry ein?

Na dann baust du hübsch eine Kristallkugel in dein Programm ein und hoffst, dass du die Anwendung irgendwo findest.

Die Frage solltest du umbenennen in

"Wie bekomme ich aus einer falschen Information die richtige?"

[gmc616]

Im Prinzip schon, aber so falsch ist die Angabe nun auch wieder nicht.
Schließlich wissen Du, ich und mit Sicherheit alle DPler hier, wo sie bei der Angabe "C:\Programme" nachzuschauen haben. Auch ohne Kristallkugel!
Auch Win7 startet unter START->"Programme/Datei durchsuchen" bzw. ->Ausführen die korrekte Anwendung, wenn ich sie mit "C:\Programme\TheApp\start.exe" rufe.
Wenn Windows dafür ein Kristallkugel nutzt, dann hätte ich gern die API darauf.

Diesen Thread umzubenennen hilft mir nicht weiter

[jaenicke]

Ein CreateFile funktioniert auf Dateien in diesem Ordner durchaus. Die Junction c:\programme ist nur so angelegt, dass man nicht direkt darauf zugreifen kann, aber das System kann damit durchaus etwas anfangen... nur eben nicht immer offenbar.

[Der schöne Günther]

Ich will ja nichts sagen, aber ShellExecute funktioniert bei mir sowohl mit dem Parameter "C:\Programme\7-Zip\7zFM.exe" als auch "C:\Program Files\7-Zip\7zFM.exe". Das nur als kleiner Test. Was verstehe ich falsch?

[jaenicke]

Ich war ja eigentlich auch der Meinung, dass das System das intern schon behandelt...
Wie sieht denn der Quelltext an der Stelle aus?

[gmc616]

Au man oh man! Scheuklappen!!

Da habe ich mich so auf die Ermittlung des korrekten Ordnernamens versteift (da der ja "völlig falsch" war) und dabei übersehen, das ShellExecute ein HRESULT > 32 (=42, warum auch immer ???) zurück gibt, was bedeutet, das der Aufruf funktioniert hat.

Ursache des Ganzen ist:
Die Fremdanwendung muss offensichtlich aus ihrem Arbeitsverzeichnis gestartet werden, sonst beendet sie sich sofort wieder, ohne Meldung oder sonst was. Gebe ich dem ShellExecute zusätzlich im Parameter "lpDirectory" das korrekt Verzeichnis mit, funktioniert die ganze Geschichte.

Kaum macht man's richtig - schon funktioniert's @Sir Rufo

Der Thread ist zwar nicht beantwortet, aber mein Problem gelöst.
Danke für die Kopfnuss

[silver-moon-2000]

Zitat von gmc616:

Im Prinzip schon, aber so falsch ist die Angabe nun auch wieder nicht.
Schließlich wissen Du, ich und mit Sicherheit alle DPler hier, wo sie bei der Angabe "C:\Programme" nachzuschauen haben. Auch ohne Kristallkugel!

Ähm, nö?

Vielleicht ist das nicht die feine englische wie ich das mache, aber ich habe ein paar (alte) Programme, die keine Leerzeichen im Pfad mögen, bzw. die ins Programmverzeichnis schreiben wollen (und die sich trotz Virtualisierung aufhängen, wenn sie das nicht können).
Also kann ich sie nicht in "C:\Program Files {(x86)}" installieren.
Zu diesem Zweck habe ich ein weiteres Verzeichnis namens "C:\Programme" angelegt, in die ich dann diese Problemkinder installiere.

Worauf ich raus will: Davon auszugehen, dass "C:\Programme" automatisch nach "C:\Program Files" umleitet, kann manchmal in die Hose gehen.

[OT]
Gibt's eine bessere Möglichkeit, wo diese Problemkinder unterzubringen sind? Ins User-Verzeichnis will ich sie nicht installieren...

[gmc616]

Zitat von silver-moon-2000:

Worauf ich raus will: Davon auszugehen, dass "C:\Programme" automatisch nach "C:\Program Files" umleitet, kann manchmal in die Hose gehen.

Ja, sicherlich.
Und man könnte sich bestimmt auch noch 1000 andere Dinge einfallen, die Standards des OS auszuhebeln.

Die Frage des Threads war ja, ob es möglich ist, aus dem z.B. im Explorer angezeigten Ordnernamen den realen Verzeichnisname zu ermitteln. Vermutlich funktioniert das aber nicht oder es gibt keine Möglichkeit. War ja auch nur ne Frage.

Wie es sich schlußendlich heraus gestellt hat, war nicht der Ordnername zur Echse das Problem, sondern das _nicht_ angegeben Arbeitsverzeichnis im ShellExceute.

Abgesehen davon habe ich es auf meiner Win7-Kiste auch als Admin nicht hingekriegt unter "C:\" einen Ordner Names "Programme" anzulegen. Computer sagt: Nein!

Code:

C:\>md Programme
Ein Unterverzeichnis oder eine Datei mit dem Namen "Programme" existiert bereits.
C:\>

[jaenicke]

Zitat von gmc616:

Abgesehen davon habe ich es auf meiner Win7-Kiste auch als Admin nicht hingekriegt unter "C:\" einen Ordner Names "Programme" anzulegen. Computer sagt: Nein!

Code:

C:\>md Programme
Ein Unterverzeichnis oder eine Datei mit dem Namen "Programme" existiert bereits.
C:\>

Das ist auch richtig, die Junction existiert genau deshalb auch in der Form.

Unter Windows 7 ist das Handling versteckter Ordner anders als unter XP und früher. Damals hieß versteckte Dateien anzeigen, dass nur versteckte angezeigt werden und bei Systemdateien aber noch ein paar mehr manchmal interessante Dateien dabei waren. Bei Windows 7 sind die aber alle schon bei den versteckten dabei, so dass das reicht die anzuzeigen.

Die Systemdateien sind heute nur noch die, die man wirklich nicht sehen sollte und in aller Regel auch nicht will. Dazu gehören diese Junctions und z.B. die desktop.ini Dateien, die dann z.B. nervend auf dem Desktop sichtbar sind.
Blendest du die Systemdateien aber mal ein, siehst du auch die Junction Programme und kannst die auch umbenennen oder entfernen (auch wenn man das nicht machen sollte).