Multiplefirefoxloader.exe oder FirefoxLoader.exe

  • Nur nochmal so am Rande - der "multiplefirefoxloader" ist veraltet und wurde durch das aktuelle "FirefoxLoader.exe" ersetzt. "multiplefirefoxloader" fragt sinnfrei die Registry nach einem installierten Firefox ab, den Code habe ich grad nicht vorliegen, aber wenn man den portable Firefox laden will, ist der Nachfolger die richtige Wahl. Das Ergebnis ist das gleich, nur ohne Umwege. Weg vom alten Geraffel, ob es nun noch funktioniert oder nicht, was aufgrund eines fehlenden Protokolls nicht ermittelt werden kann. Ich hatte das neulich schon so (ähnlich) beschrieben mit Link zu stadt-bremerhaven, wo das so zu lesen war.

    Eine Anmerkung zu #270 mit der Verwendung des Starters.

    Der Starter gibt jeglichen Parameter an Firefox weiter, der dort unter \Firefox angelegt ist. Wenn man allerdings ein Profil aus der profiles.ini nutzen will, reicht der Verweis auf <laufwerk>:\<pfad>\firefox.exe, da ist der Starter komplett überflüssig und das ist auch mit einem regulären (empfohlen!) machbar. Eine Portable stellt in dem Sinne eine bedrohte Version dar, die ist nicht vom System geschützt ist, auch das Profil nicht. Man kann allerdings via profiles. ini einen jeglichen Profilpfad nutzen (geschützt oder nicht).

    Was der portable Starter nicht beachtet, warum die Nutzung von Scripten fehlschlagen kann - der Starter setzt nicht das Arbeitsverzeichnis zu Firefox.exe, es gibt Programme, die das zwingend benötigen, weil sie es als Root für alle (relativen) Zugriffe benötigen. Ohne es getestet zu haben, könnte Firefox so ein Programm sein. Wenn das Arbeitsverzeichnis auf dem Starter-Verzeichnis sitzt, müssen Zugriffe auf Scripte fehlschlagen, weil das ein anderes Verzeichnis ist, als wo firefox.exe liegt und dort keine Scripte existieren. Es hat also mindestens einen triftigen Grund, warum eine Portable als dauerhaft genutzte Version zu meiden ist. Leider wissen das zu wenige.

    Wir sind keine Beschwerdestelle, hier gibt es nur Lösungen! Meine Glückszahl hier: 93.

  • Hast du bereits Ergebnisse oder testest du noch?

    Nach ersten Testergebnissen kann ich den Loader für mich nicht nutzen.

    Grund:

    Ich nutze ein Script womit ich aus dem Browser einen anderen Browser öffnen kann.

    Sieht dann so aus:

    Eingetragen im Script ist jeweils dafür:

    Code
    const BrowserPath = {
        "Nightly  ":        "D:\\Nightly 64\\NightlyMultiLoader.exe",

    Und das funktioniert einwandfrei.

    Ändere ich den Loader wie von dir gesagt, bekomme ich eine Fehlermeldung:

    Profil nicht gefunden.

    Der Loader funktioniert aber einwandfrei, wenn ich ein Profil direkt damit starten will.

    Ich müsste mir wahrscheinlich neue Profile dafür erstellen mit neuen Verknüpfungen etc.

    Da ich die port. Version aber nur mal zwecks Test für etwas nutze, ist mir der Aufwand dafür zu groß.

    Wenn ich das doch mal ändern sollte, dann installiere ich mir die jeweiligen Versionen direkt auf den PC.

    Aber danke für deine Erklärung zu den beiden Loadern.

  • Ändere ich den Loader wie von dir gesagt, bekomme ich eine Fehlermeldung:


    Profil nicht gefunden.

    Ich denke, wir reden von "MultipleFirefoxLoader", den Zitronella bei sich hosted?

    Da ist allerdings der falsche Code auf pastebin verlinkt - der MFL ist in NSIS geschrieben, nicht in AutoIt. Ich konnte allerdings das richtige Script dazu extrahieren. Leider ist deine Aussage richtig, warum und wieso, muss ich im Code noch finden. Denn auch Caschy hat das so geschrieben:

    Zitat
    https://stadt-bremerhaven.de/portable-firef…comment-page-3/


    Andere [...], die multiple Instanzen benötigen, können selbstverständlich einen modifizierten Loader (MultipleFirefoxLoader.exe) von mir bekommen, der eine Instanz des fest installierten und des portablen Firefox zulässt.

    Eben den Code schnell durchgeschaut. Also die Zugriffe auf die Registry sind da, aber auf einen nicht mehr genutzten Zweig

    (hkcu/software/mozilla.org, neu: hkcu/software/mozilla)

    Das kann nicht mehr funktionieren.

    Was aber gesetzt wird zur Laufzeit ist das Flag MOZ_NO_REMOTE und deswegen kannst du verschiedene Profile nutzen, das wird im anderen Starter (in keinem anderen Starter, meiner auch nicht) gesetzt.

    Funktionsweise wird hier recht gut erklärt:

    Run beta and release at the same time ? • mozillaZine Forums

    Ich müsste das ausprobieren für meinen Starter, ob der das ohne diese Variable umsetzen kann und andere Instanzen direkt mit -no-remote starten muss, ob das reicht. Neuer Starter

    Was ich aber für kritisch halte, dass der MFL in die prefs schreibt (und andere Dateien). Ist für mich ne Zeitbombe, auch wenn es bislang keinen nicht behebbaren Schaden anrichtet. Und es beinhaltet noch Routinen für Plugins und ähnlich altem Plunder, den es schon sehr lange nicht mehr gibt.

    Nachtrag:

    Eben den Code von mir mit zwei Portables getestet, ein Firefox (-no-remote, kein Zusammenhang) lief insgesamt schon vorher. Der Aufruf wurde stets mit

    firefox.exe -no-remote -profile Profilordner

    ausgeführt. Und die liefen mit dem jeweils hinterlegten Profil.

    Diese Umgebungsvariable kann temporär gesetzt werden, in zB Batch, aber auch unter Windows selbst permanent eingetragen werden. Das Ergebnis ist für mich das gleiche wie mit -no-remote. Der Starter von mir berücksichtigt andere laufende Instanzen. Startet man den Starter aus Versehen nochmal, kommt von Firefox die besagte Meldung mit dem Profil, das ist Absicht. Ich müsste nochmal ausprobieren, ob ich durch den Starter weitere Parameter an die laufende Instanz weiterreichen kann, Parameter werden generell durchgereicht.

    Wir sind keine Beschwerdestelle, hier gibt es nur Lösungen! Meine Glückszahl hier: 93.

    Einmal editiert, zuletzt von .DeJaVu (21. Oktober 2021 um 22:06)

  • 2002Andreas 22. Oktober 2021 um 16:29

    Hat den Titel des Themas von „FirefoxMultiloader - FirefoxLoader“ zu „Multiplefirefoxloader.exe oder FirefoxLoader.exe“ geändert.
  • Nur eben nicht in Verbindung mit einem von mir genutzten Script

    Was brauche ich, um das nachzustellen? Bitte in Details, weil ich damit bislang nichts am Hut hatte. Was ich vermute, hatte ich oben schon mal erwähnt, einen anderen Unterschied habe ich nicht erkennen können. Und ich könnte dir meinen Starter zukommen lassen als weiteren Test.

    Wir sind keine Beschwerdestelle, hier gibt es nur Lösungen! Meine Glückszahl hier: 93.

  • Was brauche ich, um das nachzustellen?

    Ich nutze u.a. dieses Script:

    Damit kann ich direkt aus dem Browser einen anderen der eingetragenden starten.

    Sieht dann so aus im Kontextmenü:

    Und das funktioniert nicht mit deinem Loader.

  • Und das funktioniert nicht mit deinem Loader.

    Und dabei ist völlig egal, wo sich der Loader befindet, in beiden Versionen, in der mit dem Script, oder der zusätzlich zu startenden Version. Kommt der Loader ins Spiel, so lässt sich keine zweite Instanz mehr starten.

    Grüße vom FuchsFan

  • Also das, was Andreas mir gesagt hat, ist zum einen glaubhaft und zum anderen ist die Ursache im Code ersichtlich. Im Anhang der (dekompilierte) Code des Multiloaders.

    Carsten hat sich damals die Arbeit gemacht, das recht unübersichtliche Konstrukt von portableapps.com (J. Haller) auf maximal 2 Ebenen zu vereinfachen, und sogar dessen Struktur zu berücksichtigen, falls man nur den Starter ersetzt. Man kann auch als Laie erkennen, welche Dateien manipuliert werden und ich hatte diesbzgl. ja schon Bedenken geäussert, wann es zu Fehlfunktionen deshalb kommt. Vom veralteten Rest zu schweigen. Firefox hat sich auch weiterentwickelt, vieles ist nicht mehr vorhanden oder geändert. Inwiefern man "mimeTypes.rdf" - heute: handlers.json behandeln sollte, um mit dem Gastsystem zu korrelieren, ich würde es sein lassen. Deshalb sieht die extrem gekürzte Variante auch so aus:

    Code
    Name "FirefoxStarter"
    ICON "starter2.ico"
    OutFile "FirefoxStarter.exe"
    Section ""
    SectionEnd
    Function .onInit
      Exec '"Firefox\firefox.exe" -no-remote -profile Profilordner'
    FunctionEnd

    Zitronella hat es auch in Batch und später via BAT2EXE bereitgestellt

    start "" Firefox\firefox.exe -no-remote -profile Profilordner

    Hinweis: BAT2EXE-Resultate können im schlechten Fall eine Falschmeldung des genutzten Antivirus erzeugen.

    Unter Linux (Bash o.ä.) dürfte es wohl ähnlich aussehen. NSIS und Autoit sind nicht direkt auf Linux lauffähig, allenfalls unter WINE o.ä.

    Der Nachfolger von Caschy hat einst (2018) ein Problem hervorgerufen:

    bigpen
    8. Januar 2018 um 22:10

    Problem ist nicht der Aufruf, der das -no-remote hinzufügt, sondern die veraltete Prozesserkennung, die ich im anderen Thema neu geschrieben habe.