Firefox installieren - aber wie genau?

[Gerhard]

Hallo zusammen,

Da aber außer UPS.com auch die Shop-Seite der Deutschen Post Probleme bei einzelnen Funktionen bereitet, wollte ich mal den neuen Firefox installieren. Ich bin aber zu doof und will auch nicht auf Teufel komm raus herumexperimentieren (!)
Frage: Gibt es eine einfache, verständliche Anleitung zum Installieren des Firefox auf ArcoOS 5.0.2 ? Die Anleitung die ich gefunden habe finde ich sehr merkwürdig - zum Beispiel beim Punkt "Pfade erstellen" etc.

Zum Verständnis noch etwas: Eure Tips zum Firefox in den anderen Threads waren war zwar sehr gut, aber haben mich bei diesem grundlegenden Problem nicht weiter gebracht.

Vielen Dank für Input,
Gerhard

[LotharS]

Die Anleitung die ich gefunden habe finde ich sehr merkwürdig - zum Beispiel beim Punkt "Pfade erstellen" etc.

Welche Anleitung genau? Ein so lautender Punkt ist mir noch nicht begegnet...
Oder meintest Du doch diese? Ich war dem Abschnitt "Installing from a 7Z archive" gefolgt, Ziffern.1-5.
Dort liegt mein FF45.9.0 erstmal nur zum Spielen, denn so recht zufrieden bin ich noch nicht (u.a. bis zu 99% CPU). Mein Browser-"Workaround" ist: gezielt neben mein VM-Fenster zu klicken, pssst

[Gerhard]

Danke.
Ja, genau diese Anleitung meine ich. Es läuft bei mir so:

{0}[c:\] yum install firefox
arcanoae-rel | 1.9 kB 00:00
arcanoae-rel/primary | 13 kB 00:00
netlabs-rel | 2.9 kB 00:00
Einrichten des Installationsprozess
Kein Paket firefox verfügbar.
Fehler: Nichts zu tun

Am Wochenende werde ich mich mal genauer damit beschäftigen müssen.
Viele Grüße,
Gerhard

[LotharS]

Das FF45.9.0-rpm ist offenbar vorerst nur für speziell registrierte Tester verfügbar. "Programmieren und Dokumentieren ist zweierlei..."
Aber die 7z herunterladen und entsprechend vorgehen scheint hier aber "bei allen" irgendwann geklappt zu haben
Viel Erfolg!

[Gerhard]

Hmmm...

warum sagt mir denn niemand dass es genau so ist wie bei den bisherigen Versionen von Seamonkey und Firefox???

Die gezippte Datei habe ich mit Zippy entzippt und dann den neuen Ordner "Firefox-45.****" an die Stelle des bisherigen Ordners "Firefox" im Ordner "Programs" geschoben. Genau gleiches Vorgehen mit der neuen Version von Seamonkey... und alles funktioniert perfekt. Naja, die langen Ordnernamen "Firefox-45.****" habe ich einfach auf "Firefox" und auf "Seamonkey" gekürzt.

Herzlichen Dank an Euch für die obigen Tips und vor allem auch dem /den Ersteller/n der neuesten Versionen!

Viele Grüße,
Gerhard

[ajunra]

Hmm. Ich habe den Firefox hier geladen und nach der dort zu findenden Anleitung zu installieren versucht.
System: eCS 2.1 auf IBM T43 mit 1 GB RAM

Code: Alles auswählen

1. firefox-45.9.0-4.oc00.pentium4.7z in ein temporäres Verzeichnis Entpacken
2. Den ANPM aufgerufen; [Verwalten]>[YUM-Werkzeuge...]>[Import der Paketliste]>=RPM_REQUIREMENTS
3. (Fehlermeldung: ein Paket (...686) kollidiert mit bereits installiertem Paket (...386); ignoriert und nach Anweisung System u. ANPM neu gestartet
4. die im entpackten Paket enthaltenen Dateien in die entsprechenden Verzeichnisse von "unixroot" geschoben (bei mir "SET UNIXROOT=E:")
5. Dann die Firefox.exe aufgerufen

Folge: XUL.DLL kann nicht geladen werden. (Bild unten)
Ich habe zwar verschiedene xul.dll (alte firefox; thunderbird; jedoch keine in einem im Path/Libpath liegenden Verzeichnis sondern immer im entsprechenden Programmpfad.
Wo liegt mein Denkfehler? Wie bekomme ich den Firefox 45 zum laufen?

P.S. Die hier: https://ecsoft2.org/firefox verlinkte Version für Pentium M optimiert von Dave Yeo (vom 26.Mai 2019) funktioniert genauso wenig.

[aschn]

Hier, auf meinem Hauptsystem (HW ist 13 Jahre alt), lässt sich die Version 45 auch nicht starten. Davor ging alles. Dies ist ein ANPM-System, aber die HW ist völlig veraltet. Ich bin hier noch mit SM 2.35 (entspricht FF 38) unterwegs. Interessant ist, dass auf diesem System alle Testversionen kurz davor liefen, nur eben die danach nicht.

Mit den RPM-Paketen ist alles in Ordnung, mit ANPM auch. Ich kann es mir nicht erklären. Vielleicht ist es bei Dir ähnlich. Wegen dieser negativen Erfahrung hat bei mir nicht mal die Energie dafür ausgereicht, es auch einem anderen System zu testen. (Auch mit ArcaOS bin ich drei Versionen zurück und hab's noch nicht mal probiert.)

[Werner.S]

Bei mir läuft diese Version
https://bitbucket.org/dryeo/mozilla-os2 ... m-SUa2.zip
Mein Rechner ist von 2009

Werner

[Andi B.]

Alle libs sind sicher installiert? Auch ffmpeg? Mit pmdll xul.dll angesehen und alle dlls werden gefunden? Wenn ich mich recht erinnere, fehlte irgendwann mal in der mitgepackten library liste eine.

[ajunra]

Alle libs sind sicher installiert?

Hmm. Eigentlich ja. Aber: mozsqlt3.dll und LGPLLIBS.DLL werden nicht gefunden; und das trotzdem sie im selben Verzeichnis wie xul.dll stehen. Im PATH und LIBPATH der config.sys sind der Punkt (.) als erstes vorhanden...

Code: Alles auswählen

Verzeichnis von E:\USR\LIB\FIREFOX-45.9.0

 6.10.19  1.30          <DIR>    557 ----  .
 3.10.19 21.13          <DIR>    635 a---  ..
 6.10.19  1.23         28.097      0 a---  0075_01.TRP
21.05.18 12.42            419    124 a---  application.ini
 3.10.19 21.13          <DIR>    124 a---  browser
20.05.18 17.33          8.712    124 a---  CHANGES.OS2
 3.10.19 21.13          <DIR>    124 a---  defaults
21.05.18 17.03              9    124 a---  dependentlibs.list
 3.10.19 21.09             28    168 a---  dictionaries
 6.10.19  1.30            625      0 a---  dir.txt
21.05.18 17.17         51.129    124 a---  firefox.exe
 3.10.19 21.13          <DIR>    124 a---  gmp-clearkey
21.05.18 17.17         49.678    124 a---  lgpllibs.dll
20.05.18 17.33            389    124 a---  LICENSE
20.05.18 17.33         10.527    124 a---  MozSounds.cmd
21.05.18 17.17        382.604    124 a---  mozsqlt3.dll
21.05.18 17.16      9.648.466    124 a---  omni.ja
21.05.18 17.13             51    124 a---  platform.ini
21.05.18 17.17         37.696    124 a---  plugin-container.exe
20.05.18 17.33         31.008    124 a---  README.OS2
21.05.18 17.17     29.398.067    124 a---  xul.dll
        21 Datei(en)  39.647.505 Byte belegt
                     1.836.998 K Byte frei

Code: Alles auswählen

LIBPATH=.;E:\USR\LOCAL\LIB;E:\USR\LIB; usw.
PATH=.;E:\usr\sbin;E:\usr\bin; usw.

Auch seltsam: Wenn ich den firefox mit pmdll untersuche, erscheint nirgends die xul.dll ?! Beim Firefox erscheint NICHTS rot...

[Sigurd]

Hatte lange Zeit genau dasselbe Problem, als ich FF 45 ohne den ANPM mit Warp 4.52 nutzen wollte. Hatte alle doppelten DLLs rausgeschmissen usw usw.

Endlich geklappt hatte es, nachdem ich in der config.sys das Verzeichnis für Mozilla Home mit SET eingetragen bzw. ergänzt hatte. Dann liefen auch alle anderen (SM, TB).

Fehlt das evtl. bei Dir auch?

[aschn]

Wenn ich den firefox mit pmdll untersuche, erscheint nirgends die xul.dll

Es gibt mehrere Möglichkeiten DLLs zu laden. PMDLL kann nur eine untersuchen.

Beim Firefox erscheint NICHTS rot...

xull.dll ist auch am aussagekräftigsten.

[aschn]

Fehlt das evtl. bei Dir auch?

Nein. Es gibt aber auch einen Fallback-Wert, falls MOZILLA_HOME nicht gesetzt ist.

[ajunra]

Endlich geklappt hatte es, nachdem ich in der config.sys das Verzeichnis für Mozilla Home mit SET eingetragen bzw. ergänzt hatte. Dann liefen auch alle anderen (SM, TB).

Fehlt das evtl. bei Dir auch?

Nö. Bei mir steht schon lange
SET MOZILLA_HOME=E:\HOME\DEFAULT
in der config.sys. Funktioniert mit den älteren Füchsen und dem Donnervogel problemlos.

Könnte es an dem langen Verzeichnisnamen (...\lib\Firefox-4.9.0\...) liegen? Werde ich mal umbenennen; 's ist ja wohl eh der letzte Feuerfuchs auf unserem System...

P.S. gerade getestet: Erfolglos. PMDLL zeigt auch identische Probleme an.
Ich hänge mal die entstandenen TRP-Datei ran. Vielleicht sagt sie ja jemanden etwas...

[Andi B.]

Code: Alles auswählen

LIBPATH=.;E:\USR\LOCAL\LIB;E:\USR\LIB; usw.
PATH=.;E:\usr\sbin;E:\usr\bin; usw.

Finde ich persönlich nicht gut. .; sollte besser hinter E:\USR\LOCAL\LIB;E:\USR\LIB; stehen. Der Grund ist der, solltest du ein Programm installiert haben welches fälschlicherweise eine der dlls mitgeliefert hat welche auch in \usr\lib liegt, dann wird diese alte dll geladen wenn du das "alte" Programm startest. Neuere Programme welche die aktuelle dll gleichen Namens in \usr\lib brauchen, arbeiten dann aber auch mit der alten. Es kommt dann immer darauf an, welches Programm du vorher startest und je nachdem wird die alte oder doch die aktuelle dll geladen. Solche Fehler (doppelte dlls) findet man schwer.

Ein fiktives Beispiel, ich hab hier -

Code: Alles auswählen

P:\Seamonkey2.14\freebl3.dll

Die richtige Version welche z.B. FF braucht, liegt aber hier in meinem %UNIXROOT% Pfad -

Code: Alles auswählen

P:\usr\lib\freebl3.dll

Würde ich nun Seamonkey2.14 vorher starten und den . am Anfang haben, würde die alte freebl3.dll vom SM Verzeichnis in den Speicher geladen. Will ich nun auch den neuen FF starten, kann der die richtige \usr\lib\freebl3.dll nicht laden weil eh schon eine freebl3.dll geladen ist. Unendlich viele Fehlerbilder können daraus entstehen.

Hab ich aber den Punkt hinter den x:\USR\LOCAL\LIB;x:\USR\LIB; Einträgen, wird immer die aktuellste von dort geladen. Der alte Seamonkey2.14 läuft auch mit der neuesten P:\usr\lib\freebl3.dll. Und der FF läuft auch weil eh die neue dll im Speicher ist.

Ich weiß, es gibt dazu unterschiedliche Ansichten. Aber ich finde es ist besser wie eben beschrieben. Damit laufen alle aktuellen Programme weil die eh mit den aktuellen (yum/rpm) dlls getestet wurden. Sollte ein altes Programm wirklich mal eine spezielle alte dll brauchen, dann merke ich das genau dann, wenn ich das alte Programm starte. Und dann kann ich immer noch dieses mit Libpathstrict zum Laufen bringen. Im anderen Fall ist es Zufall (naja es entscheidet die Startreihenfolge und ob man alle Programme welche die dll brauchen vorher schließt oder nicht) ob die richtige/aktuelle dll geladen wird, oder irgendeine alte.

Mit meiner Methode ist es dann auch nicht mehr sooo wichtig ob wirklich alle doppelten dlls gelöscht werden. Im Zweifelsfall wird sowieso die aktuellste aus \usr\lib geladen.

Aber: mozsqlt3.dll und LGPLLIBS.DLL werden nicht gefunden;

Und was sagt "pmdll mozsqlt3.dll" und "pmdll LGPLLIBS.DLL"?

Btw. den . im PATH verstehe ich nicht. Für was braucht man das?

[ajunra]

Und was sagt "pmdll mozsqlt3.dll" und "pmdll LGPLLIBS.DLL"?

Alles schwarz bzw. blau; also alles i.O.
Morgen werde ich beide mal ins \lib\-Verzeichnis kopieren und mal sehen ob sich etwas ändert. Da der . am Anfang steht müsste das ja eigentlich für andere Programme keine Rolle spielen, oder...?

[aschn]

Der Punkt im PATH ist völlig überflüssig. Wenn Programme gesucht werden (z.B. über Befehlszeile oder Programmobjekte), dann wird sowieso zuerst im aktuellen Verzeichnis gesucht. Ausnahme ist, wenn man den Pfad mit angegeben hat.

[Andi B.]

Da der . am Anfang steht müsste das ja eigentlich für andere Programme keine Rolle spielen, oder...?

Doch. Die erste dll (das Programm welches eine dll aus seinem Verzeichnis als erstes lädt) gewinnt. Es kann nur eine dll mit gleichem Namen gleichzeitig im Speicher geladen und genutzt werden. Eine einzige Kopie der dll mit einem bestimmten Namen steht im Speicher auch allen anderen Programmen zur Verfügung. Das ist ja der Sinn von dlls. Programme "teilen" sich die gleichen Routinen einer einzigen dll mit diesem Namen. Mehrere dlls mit gleichem Namen sind widersinnig und eins der größten Probleme welches wir unter OS/2 heute haben. Dlls mit gleichem Namen werden nicht mehrfach geladen.

Über die Ausnahme mit LIBPATHSTRICT und den daraus resultierenden Problemen, will ich hier und jetzt nicht diskutieren. Dieses Thema ist offensichtlich auch so schon schwer verständlich.

[erdmann]

P.S. gerade getestet: Erfolglos. PMDLL zeigt auch identische Probleme an.
Ich hänge mal die entstandenen TRP-Datei ran. Vielleicht sagt sie ja jemanden etwas...

Deine TRP Datei zeigt Probleme mit dem Druckertreiber PSPRINT an, Firefox hat wohl versucht die Druckereinstellungen abzufragen. Du solltest vielleicht mal die neuesete PSPRINT Version von Alex' Webseite installieren bzw. noch mal installieren:
http://www.altsan.org/os2/printing/psprint-30_907.zip

Lars

[ajunra]

Doch. Die erste dll (das Programm welches eine dll aus seinem Verzeichnis als erstes lädt) gewinnt.

Na ja, sag' ich doch. Andere Programme suchen dank des Punktes an erster Stelle zuerst in ihrem eigenen Verzeichnis, so daß sie - zumindest wenn sie zuerst aufgerufen wurden - erst mal ihre eigene dll benutzen. Daß das natürlich nicht optimal ist, weiß ich. Aber beim Experimentieren...

Deine TRP Datei zeigt Probleme mit dem Druckertreiber PSPRINT an

Ahhh, das bedeutet die Erwähnung... Ich nahm an daß das aufgeführt wurde um die Systemumgebung zu beschreiben. Na ja, ich kann mit solchen Dateien halt nichts anfangen...

Gut, habe den Treiber (mit Manage Printers) aktualisiert (von 30.905 auf die derzeit aktuelle 30.907).
Folge: Firefox startet nicht; aber jetzt ohne Fehlermeldung. Dafür rödelt die Festplatte aber relativ lange kommentarlos vor sich hin.
Im Anhang die aktuelle TRP-Datei. (Firefox wurde erst nach Neustart nach Druckertreiberaktualisierung aufgerufen)

Ich habe mal mit pmdll wieder die xul.dll aufgerufen: es sind weiterhin die bereits genannten Dateien rot/nicht gefunden.
Bei libcn0.dll zeigt pmdll keine Probleme. Allerdings wurde eine libcn0.logchk angelegt (3,9MB?!) wobei mir das Dateisystem seltsame Daten bezüglich Erstellung/letzte Benutzung angibt:

P.S. Gerade noch zwei mal getestet. Beide male kam jetzt kurzzeitig ein Fenster welches sagt, daß die Plugins geprüft werden. Dann ein Fehler-Pieps und selbst das rödeln der Festplatte ist vorbei... das wars.

[_diver]

P.S. Gerade noch zwei mal getestet. Beide male kam jetzt kurzzeitig ein Fenster welches sagt, daß die Plugins geprüft werden. Dann ein Fehler-Pieps und selbst das rödeln der Festplatte ist vorbei... das wars.

lösch/verschiebe mal alles aus dem "SET MOZ_PLUG" Verzeichnis in ein anderes. Weil es sieht so aus als ob du da alten Schrott drin hast.
Entweder in der config.sys nach "SET MOZ_PLUG" suchen um das Verzeichnis zu erhalten, oder in einem OS/2 Fenster "SET MOZ_PLUG" eingeben.

[ajunra]

Danke! Jetzt läuft der Browser!
Habe das MOZ_PLUG-Verzeichnis in der config (erstmal) geändert und läuft jetzt...!

Nach dem zweiten Start ist sogar die Oberfläche auf deutsch! Toll! Danke an die Entwickler!
Einziges Manko: 99,9% Prozessorlast. (ca. 99,3% Benutzerlast; ca. 0,6% IRQ-Last)

...
In der config.sys muß
SET MOZ_NO_RWS=1
SET NSPR_OS2_NO_HIRES_TIMER=1
eingetragen sein, wie von MikeK schon erwähnt.
...

Habe ich in der config.sys stehen.