Start per RunDll32.exe arbeitet nicht korrekt

[_Joerg_]

Auch unter XP gibt es Programme (z.B. OpenOffice), die solche Widestring-Einträge machen. Gerade Sytemprogramme sind oft mit Systemvariablenin in der Verknüpfung gespeichert. Win7 hat ja auch noch so eine dynamische Verknüpfung. Wenn mich nich alles täuscht, verfolgt das System dann direkt Verschiebungen der Zieldatei und ermöglicht weiterhin den Zugriff über den Link.
Ich finde, da hat MS einen ziemlich komplizierten Kram, für eine eigentlich einfache Sache entwickelt...

[AHT]

Trotzdem finde ich deinen Lösungsansatz sehr interessant. Im Augenblick ist es mit 32Bit Programmen nicht möglich, den korrekten Pfad von 64Bit Verknüpfungen auszulesen, wenn dieser in %ProgramFiles% verweist. Eventuell bekommt man über deinen Lösungsansatz was funktionierendes zustande.

[_Joerg_]

Hier ist eine sehr gut lesbare Beschreibung des Dateiformates:
WHITE PAPER: The Windows Shortcut File Format
und hier Delphi-Code zum Auslesen. da steig ich aber nicht durch:
http://www.delphipraxis.net/111350-v...-auslesen.html

[AHT]

Danke dir! Hier lohnt sich auf jeden Fall das Weiterbasteln.
XProfan unterstützt keine Interfaces. Auch der Delphi Code funktioniert unter Windows7 64Bit nicht korrekt. Die OLE Umsetzung gibt es bereits als Code in XProfan (dein Delphi Link) - durch ein selbstgestricktes Interface. Funktioniert aber, wie gesagt, von 32Bit auf 64Bit nicht korrekt, da %ProgrammFiles% nicht korrekt ermittelt werden kann.

Die virtuelle XP-Maschine kann z.B. nicht gefunden werden, denn Microsoft verwendet zum Starten doch glatt rundll32 und natürlich Systemvariablen.

Beispiel:
Pfad: C:\Windows\system32\rundll32.exe
Argument: %SystemRoot%\system32\VMCPropertyHandler.dll,LaunchDefaultVM
Kommentar: Vorkonfigurierte Windows XP Mode-Umgebung
IconPfad: %SystemRoot%\system32\VMCPropertyHandler.dll
Icon nummer: icon number: 1009

Dieser Pfad wird von Ole auch nicht gefunden. Unicode Links habe ich eigentlich noch keine in meinem System gefunden. Selbsterstellte Links werden von Windows 7 auch alle in Ansicode erstellt.

Ich denke man muss sich mal bei Wotsit.org umschauen, ob es eine Beschreibung gibt um alles direkt am offset auszulesen.

[_Joerg_]

Ich wette, von Uwe "Pascal". Ich hab aber nur was zum Erstellen von Links gefunden. Weißt Du, wo der Code zum Auslesen ist?
-- Ich hab's gefunden und hatte recht...

Ich hatte gerade mal Zeit und rundll32 auf meinem 64 bit Windows 7 getestet. Es funktioniert genau so gut und zuverlässig wie unter 32 bit, auch mit 64 bit Anwendungen. Also reine Panikmache. Man kann unbesorgt weiterhin

winexec("RUNDLL32.exe url.dll,FileProtocolHandler " + execute$,1)

benutzen.

[ts-soft]

Hat nichts mit Panikmache zu tun und wenn es die einzige Lösung ist,
dann soll man es doch so machen, aber irgendetwas ist doch dran verkehrt,
wenn ich als Programmierer zum Ausführen einer DLL-Funktion eine andere
Exe aufrufe . Die Exe ist nunmal nicht für Programmierer erdacht, sondern
für diejenigen, die keine Programmiersprache zur Verfügung haben und somit
keine DLL laden und deren Funktion ausführen können.
Profan kann aber DLLs laden und deren Funktionen ausführen und somit wäre
mir die Nutzung von RunDLL32.exe zumindest etwas peinlich.

Hab leider keine Doku zu "FileProtocolHandlerA" gefunden, der benötigt
anscheinend 4 parameter.

[Frabbing]

Zitat von Unregistriert

Ich hatte gerade mal Zeit und rundll32 auf meinem 64 bit Windows 7 getestet. Es funktioniert genau so gut und zuverlässig wie unter 32 bit, auch mit 64 bit Anwendungen. Also reine Panikmache. Man kann unbesorgt weiterhin

winexec("RUNDLL32.exe url.dll,FileProtocolHandler " + execute$,1)

benutzen.

Dieter, man sieht an Volkmar doch, dass es nicht immer geht. Ich würde nicht unbedingt blind darauf vertrauen, nur weil es am eigenen Computer funktioniert. Mal abgesehen davon, das die Lösung auch nicht gerade schnell ist, eine Exe aufzurufen, die dann eine Dll-Funktion aufruft, welche wiederum die gewünschte Exe startet. Das sagt mir mein gesunder Menschenverstand, dass sowas nur eine Notlösung sein kann. Aber es gibt ja andere Lösungen.

ich teste das alles nicht nur auf meinen 3 Computern, von denen sogar einer ein Tablet-PC ist.
Obwohl man davon ausgehen könnte, dass wenn etwas auf 3 unterschiedlichen PCs läuft, es auf anderen, wenn alles normal ist, auch laufen müsste.
Ich denke mal, Volkmar hat oder hatte ein grundsätzliches Problem mit seinem Computer oder Mediaplayer, das nichts mit der Rundll32 zu tun hat. Er hat ja auch ein 32 bit Betriebssystem.
Für meinen Teil halte ich es nicht für peinlich oder zu langsam. Es ist halt die beste Möglichkeit mit einer Routine einfach alles zu starten. Simple die Datei oder url übergeben, fertig. (Siehe starten einer *.lnk Datei) Was im Übergabeparameter drin steht, ist gerade mal egal, wenn es ein gültiger Pfad ist, wird es gestartet.
Ist ja auch egal, jeder kann das handhaben wie er will. ich werde es weiterhin benutzen.

[Volkmar]

Bei mir betrifft es ja nur den Windows-Media-Player. Mit anderen Playern und anderen Dateitypen klappt's auch bei mir. Ich denke mal, da hat sich irgendwo ein Fehler eingeschlichen, der auch nicht durch Neuzuweisen der Standards an Programm und Dateityp zu beheben geht.
Aber es ist schon was Wahres dran, RunDLL ist eigentlich gedacht für DLL-Funktionen, die dann in Scripten eingebaut werden können, ohne daß der Scriptinterpreter externe Funktionen importieren können muß. Wenn ich die Funktion kenne, kann ich sie mit XProfan und anderen Sprachen direkt aufrufen.

Gruß Volkmar

[Frabbing]

Ist ja auch egal, jeder kann das handhaben wie er will.

Ganz genau.