Grundlagen der LIBPATH-Syntax

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
User avatar
DonLucio
Posts: 288
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Grundlagen der LIBPATH-Syntax

Post by DonLucio » Sat 19. May 2018, 15:02

Ich dachte, nach 20 Jahren OS/2-Praxis wüßte ich Bescheid über LIBPATH, LIBPATHSTRICT und BEGINLIBPATH. Aber das scheint nicht der Fall zu sein.

Es geht (immer noch) darum, eine der neueren FF-Versionen (38 oder 45) zu installieren. Nachdem ich mit der 38 gescheitert bin (s. Thread "XUL mal wieder"), habe ich jetzt einen neuen Anlauf unternommen mit der neuesten Version 45.9.0. Habe das zip entpackt auf mein Laufwerk g:
G:
├──Firefox.45.9.0
│ ├──firefox
│ │ ├──browser
│ │ ├──defaults
│ │ ├──dictionaries
│ │ └──gmp-clearkey
│ └──nss
Da ich noch andere Mozilla-Software am Laufen habe, will ich den neuen FF 45 und seine DLL-Welt isolieren von den anderen, möglicherweise bereits geladenen DLLs. Dazu verwende ich folgendes Rexx-Script ("StartFirefox.cmd") zum Starten des Firefox 45:

Code: Select all

set LIBPATHSTRICT=T
set BEGINLIBPATH=g:\Firefox.45.9.0;g:\Firefox.45.9.0\firefox;G:\Firefox.45.9.0\nss;
g:
cd G:\firefox.45.9.0\firefox
firefox.EXE %1 %2 %3 %4 %5 %6 %7 %8 %9

set LIBPATHSTRICT=F
Der FF-Aufruf endet mit der Fehlermeldung:

Code: Select all

[G:\firefox.45.9.0\firefox]firefox.EXE
SYS1804: Datei NSPR4 kann nicht gefunden werden.
Ich habe mir die Augen wund geschaut, ob ich etwas übersehen habe, aber nein: Die Datei nspr4.dll befindet sich im Verzeichnis G:\Firefox.45.9.0\nss. Und dieser Pfad ist in meiner BEGINLIBPATH-Angabe enthalten.

Wo liegt mein Fehler?

Vielen Dank,
Don Lucio.

aschn
Posts: 623
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Sat 19. May 2018, 16:02

DonLucio wrote:
Sat 19. May 2018, 15:02
Dazu verwende ich folgendes Rexx-Script
Das ist ein CMD-Skript. REXX kommt darin nicht vor. Die letzte Zeile "set LIBPATHSTRICT=F" kannst Du Dir auch schenken. Als BEGINLIBPATH braucht nur der Pfad "G.\Firefox.45.9.0\firefox;" gesetzt zu werden. Statt "firefox.exe ..." kannst Du auch "CALL firefox.exe ..." schreiben. Das könnte für ein REXX-Skript hilfreich werden.

Ich sehe auch keinen Fehler. Zunächst wür ich aber mal aufräumen wie oben beschrieben.
Andreas Schnellbacher

User avatar
DonLucio
Posts: 288
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio » Sat 19. May 2018, 16:15

aschn wrote:
Sat 19. May 2018, 16:02
Das ist ein CMD-Skript. REXX kommt darin nicht vor.
Äh ... ja, du hast natürlich recht. Sorry.
aschn wrote:
Sat 19. May 2018, 16:02
Als BEGINLIBPATH braucht nur der Pfad "G.\Firefox.45.9.0\firefox;" gesetzt zu werden.
Ist das so? Das würde bedeuten, dass ein mit BEGINLIBPATH gesetzter Pfad *einschl.* seiner Unterverzeichnisse durchsucht wird?

Also gut. Ich habe jetzt den LIBPATH-Eintrag geändert auf:

Code: Select all

set BEGINLIBPATH=g:\Firefox.45.9.0\firefox;
Resultat jetzt: Eintrag in OS2POPUP.LOG:

Code: Select all

05-19-2018  16:17:48  SYS2070  PID 007b  TID 0001  Slot 0085
G:\FIREFOX.45.9.0\FIREFOX\FIREFOX.EXE
[b]XUL->PLDS4.26[/b]
182
Die Datei plds4.dll befindet sich in g:\Firefox.45.9.0\nss

Wenn ich aber diesen Pfad in LIBPATHSTRICT aufnehme, kriege ich wieder - s.o. - "NSPR4 nicht gefunden" (die aber ebenfalls in dem ...\nss-Unterverzeichnis liegt). Ich versteh's nicht.
Last edited by DonLucio on Sat 19. May 2018, 16:28, edited 1 time in total.

User avatar
Frank Wochatz
Posts: 828
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Sat 19. May 2018, 17:19

Unixroot ist gesetzt? Die Pakete sind korrekt installiert einschl. der Unixrootunterverzeichnisse? etc / usr und darunter?


Mein Startdatei sieht so aus (die ausgeREMten Sachen kann man bei Bedarf natürlich anpassen):
REM VIRTUALADDRESSLIMIT=2048

SET UNIXROOT=C:

REM SET MOZ_NO_REMOTE=1
REM SET MOZ_ACCELERATED=2
SET MOZ_NO_RWS=1
REM SET NSPR_NO_EXCEPTQ=1
REM SET MOZ_CONSOLE_LOG=1

firefox.exe -Safe-Mode
rem firefox.exe


Die Datei plds4.dll liegt bei mir in C:\ecs\dll (ist im Libpath)

User avatar
Frank Wochatz
Posts: 828
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Sat 19. May 2018, 17:21

PS: NSPR4.dll liegt bei mir auch in c:\ecs\dll

User avatar
DonLucio
Posts: 288
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio » Sat 19. May 2018, 19:44

Frank Wochatz wrote:
Sat 19. May 2018, 17:19
Unixroot ist gesetzt? Die Pakete sind korrekt installiert einschl. der Unixrootunterverzeichnisse? etc / usr und darunter?
Nein, natürlich nicht. Ich denke, wenn ich das YUM/RPM-Verfahren meide und stattdessen das herkömmliche ZIP-Verfahren wähle, dann brauche ich dieses unixroot-Zeugs nicht. Dafür habe ich ja meine OS/2-konforme libpath/beginlibpath-Methode eingesetzt.

Oder muß ich etwa davon ausgehen, dass die Linux-Portierungen ihre DLLs nicht über das normale OS/2-API laden sondern selbstgestrickt über die unixroot-Struktur?

Verzeih' meine Naivität...

User avatar
Frank Wochatz
Posts: 828
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Sat 19. May 2018, 20:22

Ohne Unixroot geht es imo seit einer Weile nicht mehr. Irgendwelche Daten müssen in den richtigen Unter-Unterverzeichnissen im Unixroot liegen. Ich kann Dir mal ein Listing schicken, bin aber erst am Dienstag wieder am OS2 Rechner.

Die Verzeichnsistruktur müsste die sein, wie in den auf http://os2news.warpstock.org/Warpzilla.html verlinkten Paketen, wenn ich mich richtig erinnere betrifft es fontconfig. Die relativen Pfade müssen stimmen.

User avatar
LotharS
Posts: 474
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Sun 20. May 2018, 16:51

Zur konkreten Problematik kann ich nicht beisteuern, deshalb nur ein paar indirekte Zeilen zum Vergleich:

Statt explizit LIBPATHSTRICT verwende ich RUN!.EXE. Damit sieht eines meiner gesammelten Firefox-CMDs z.B. so aus:

Code: Select all

@echo off
setlocal
set NSPR_OS2_NO_HIRES_TIMER=1
set moz_no_remote=1
set moz_plugin_path=e:\apps\moz_plug
set mozilla_home=f:\homedata
e:
cd \apps\firefox
firefox!KL.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 -UILocale de-DE
endlocal
cd \
exit
Hier auf eCS 2.1 schlummern mittlerweile 3 Fireföxe (Sammelwut oder Faulheit?? ;) ), jeweils mit eigener nspr4.dll im app-Verzeichnis, dazu - aus inzwischen ANPM - noch eine andere in %UNIXROOT%\usr\lib. Die Scripte tun hier jedenfalls was man erwarten darf.
An den letzten FF 45.* Beta ? habe ich mich allerdings doch noch nicht heranwagen wollen... - und wenn irgendwann doch, dann NUR per ANPM installiert.

User avatar
DonLucio
Posts: 288
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio » Tue 22. May 2018, 12:01

LotharS wrote:
Sun 20. May 2018, 16:51
Statt explizit LIBPATHSTRICT verwende ich RUN!.EXE
Habe ich etwas übersehen? Ich finde in deinem CMD-Skript kein RUN!.exe

Gruß,
Don Lucio.

_diver
Posts: 131
Joined: Fri 27. Jun 2014, 10:57

Post by _diver » Tue 22. May 2018, 12:41

DonLucio wrote:
Sat 19. May 2018, 19:44
Frank Wochatz wrote:
Sat 19. May 2018, 17:19
Unixroot ist gesetzt? Die Pakete sind korrekt installiert einschl. der Unixrootunterverzeichnisse? etc / usr und darunter?
Nein, natürlich nicht. Ich denke, wenn ich das YUM/RPM-Verfahren meide und stattdessen das herkömmliche ZIP-Verfahren wähle, dann brauche ich dieses unixroot-Zeugs nicht. Dafür habe ich ja meine OS/2-konforme libpath/beginlibpath-Methode eingesetzt.

Oder muß ich etwa davon ausgehen, dass die Linux-Portierungen ihre DLLs nicht über das normale OS/2-API laden sondern selbstgestrickt über die unixroot-Struktur?

Verzeih' meine Naivität...
da du ja ArcaOS nutzt frage ich mich wie du das ganze YUM/RPM zeugs meiden willst. Einiges von ArcaOS wird via yum installiert und braucht es auch. Ohne das gehen einige Programme nicht. Ausser man installiert das dann auch von Hand. Kann man tun, sollte man aber besser nicht. Und warum auch, wenn ANPM einem doch so schön behilflich ist. Und nein ich möchte kein weiteres pro/contra YUM/RPM anzetteln hier. Ich verstehe nur nicht warum man es nicht nimmt, wenn man eh schon ArcaOS hat.

User avatar
LotharS
Posts: 474
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Tue 22. May 2018, 13:59

DonLucio wrote:
Tue 22. May 2018, 12:01
Habe ich etwas übersehen? Ich finde in deinem CMD-Skript kein RUN!.exe
Schau mal unter x:\sys\doc\RUN, die Original RUN!.exe steht unter x:\sys\bin, falls alles noch wie ausgeliefert. Ist jedenfalls hier so. Mein FF-Icon ruft bereits 'firefox!KL.exe' auf und somit unter LIBPATHSTRICT, ob's bereits so ausgeliefert war oder von mir sofort so eingerichtet, ist zu lange her...
Meine Scripte dienten eigentlich nur dazu, vorübergehend lokal unterschiedliche Umgebungsvariablen zu setzen.

Im übrigen hast Du das ganze "Unixroot-Zeugs" und rpm/yum bereits in ArcaOS fertig installiert und mit ANPM bequem zu bedienen. Ich hatte rpm/yum-zu-Fuss ja genauso "gehasst", aber warum sollte ein moderneres OS/2 denn komplizierter aufzufrischen sein als heutzutage Win$ oder Linux - da guck'ste auch nicht mehr durch und tut trotzdem ...
Obwohl ok, echter Nerd tippt ja am flottesten auf Kommandozeile; da stehe ich gern staunend daneben ;)

User avatar
Frank Wochatz
Posts: 828
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Tue 22. May 2018, 15:24

Offenbar funktioniert es ja nun nicht wie es soll. Und nun entsteht genau die Situation - man steht im Regen und weiß nicht was man machen soll, weil es undurchschaubar ist...

User avatar
LotharS
Posts: 474
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Tue 22. May 2018, 19:27

Frank Wochatz wrote:
Tue 22. May 2018, 15:24
Offenbar funktioniert es ja nun nicht wie es soll.
Hm. Hab' FF-45.9.0 GA1.1 soeben installiert und läuft..., sogar mit deutschem Sprachpaket. Tippe dies gerade darin :D
Problemchen( :?: ): in den "RPM_REQUIREMENTS" fand yum die *.pentium4-Pakete nicht, habe ersatzweise 'i686' genommen. K.A., ob sich das negtiv auswirkt oder nicht.
Problem( :!: ): Die CPU kocht am oberen Anschlag (99,9%). Gefällt mir allerdings gar nicht. :( Mein Standard-Browser wird _der_ jedenfalls nicht. Edit: Die 99,9% kommen offenbar durchs Editieren im Forum zustande (was wohl kaum am Forum liegt).
man steht im Regen und weiß nicht was man machen soll, weil es undurchschaubar ist...
Wenn man sich aber enger nach dem "Beipckzettel" gerichtet hat, schaut nach ev.Ticket-Meldung eher ein Entwickler drauf und durch :)
Last edited by LotharS on Tue 22. May 2018, 19:33, edited 1 time in total.

aschn
Posts: 623
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Tue 22. May 2018, 21:03

LotharS wrote:
Tue 22. May 2018, 19:27
Problem( :!: ): Die CPU kocht am oberen Anschlag (99,9%). Gefällt mir allerdings gar nicht. :( Mein Standard-Browser wird _der_ jedenfalls nicht.
Da sollte sich die letzten Tage was verbessert haben: #266, #248, #265, und hier die Bugs zum Milestone.
Last edited by aschn on Tue 22. May 2018, 21:31, edited 2 times in total.
Andreas Schnellbacher

User avatar
DonLucio
Posts: 288
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio » Wed 23. May 2018, 12:22

LotharS wrote:
Tue 22. May 2018, 19:27
Hm. Hab' FF-45.9.0 GA1.1 soeben installiert und läuft...,...
Problem: Die CPU kocht am oberen Anschlag (99,9%). Gefällt mir allerdings gar nicht.
Mir auch nicht! Und genau das passiert bei meinem bisher installierten FF 31 genauso und war der Grund dafür, dass ich auf eine neuere Version 45 umsteigen wollte.

Aber wenn das Problem der 99,9% CPU-Last beim 45er FF noch genauso besteht, dann kann ich mir ja weitere Quälereien, aka Installations-Versuche, ersparen.

Noch ein Nachsatz:
Einige Foristen hier fragen sich verwundert, warum ich einen Bogen um das YUM/RPM-Thema mache, wo es doch schon in ArcaOS integriert ist und einfach nur benutzt zu werden braucht. Dazu nur soviel: Unmittelbar nach Installation des ArcaOS 2.0.1 lief auch alles, auch der (nicht ganz so aktuelle) FF 38, recht zufriedenstellend. An 99,9% CPU kann ich mich nicht erinnern. Leider bekam ich nach einiger Zeit einen WPS-Crash (aus bisher unbekannter Ursache), und ich sah mich genötigt, ein Archiv zurückzuholen. Danach lief zuerst der FF 38 nicht mehr und das von vielen hier empfohlene ANPM war nicht vorhanden ("unbekannter Dateiname"), ebenso wie YUM oder RPM.

Frank Wochatz wrote: Offenbar funktioniert es ja nun nicht wie es soll. Und nun entsteht genau die Situation - man steht im Regen und weiß nicht was man machen soll, weil es undurchschaubar ist...
Genauso sehe ich das auch ...

P.S.
ich schreibe diesen Post immer noch mit meinem alten FF 31. CPU-Last unauffällig. Alles gut. Insofern habe ich kein Problem. Wehe aber, ich besuche Seiten wie spiegel.de, Amazon, welt.de .... um nur einige zu nennen, da läuft nach wenigen Sekunden nix mehr, System hängt sich auf, manchmal kommt noch die Meldung "Ein Javascript antwortet nicht... Abbruch oder warten?"

Gruß,
Lutz Wagner

User avatar
LotharS
Posts: 474
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Wed 23. May 2018, 12:41

Noch einmal zurück auf "Los":
DonLucio wrote:
Sat 19. May 2018, 15:02
Ich dachte, nach 20 Jahren OS/2-Praxis wüßte ich Bescheid über LIBPATH, LIBPATHSTRICT und BEGINLIBPATH. Aber das scheint nicht der Fall zu sein.

Es geht (immer noch) darum, eine der neueren FF-Versionen (38 oder 45) zu installieren. Nachdem ich mit der 38 gescheitert bin (s. Thread "XUL mal wieder"), habe ich jetzt einen neuen Anlauf unternommen mit der neuesten Version 45.9.0. Habe das zip entpackt auf mein Laufwerk g:
G:
├──Firefox.45.9.0
│ ├──firefox
│ │ ├──browser
│ │ ├──defaults
│ │ ├──dictionaries
│ │ └──gmp-clearkey
│ └──nss
Von welcher Quelle hast Du denn dieses ZIP bezogen?? Meine Verzeichnisstruktur sieht nämlich schon anders aus...

Meine FF-45-Version stammt von hier: https://github.com/bitwiseworks/mozilla ... _OS2_GA1_1.
Das 7z-Archiv mittels Arc(hive)Tool nach \var\temp ausgepackt und der Anleitung "Installing from a ZIP archive" gefolgt. Dabei:
- aus der Datei 'RPM_REQUIREMENTS' ein gleichnamiges .cmd-Script gebastelt: vor jede Zeile ein 'yum install ' gesetzt, in den Paketnamen pentium4 durch i686 ersetzt, am Ende ein 'yum update' angefügt, gespeichert und los; 2-3 Pakete wurden nachinstalliert.
- Infrage kam für mich die dortige Variante (6), also insoweit "OS/2-üblich". Zwar habe ich mit ArcaOS sehr wohl UNIXROOT, mag aber vorsichtshalber nicht auf die Variante (7) steigen. (Nach einigem Grübeln was mit der dortigen Fallunterscheidung wohl wirklich gemeint sein könnte...)
- Das Verzeichnis 'firefox-45.9.0' aus dem ausgepackten ...\@unixroot\usr\lib kopiert nach exist. C:\Programs, zum Aufrufen ein Programmobjekt angelegt mit diesem Pfad. Das vorhandene 'c:\programs\firefox' noch optisch umbenannt in '..firefox38' sowie exist. 'Firefox'-Objekte ebenso und Pfade angepasst. FF-45 scheint tatsächlich ohne LIBPATHSTRICT bzw. RUN! auszukommen, im Ggs. zu FF-38.
Das war's schon...

Dass mir die Performance noch inakzeptabel ist (99,9% CPU nur zum Editieren im Forum...), ist ein anderes Thema.

User avatar
LotharS
Posts: 474
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Wed 23. May 2018, 13:13

DonLucio wrote:
Wed 23. May 2018, 12:22
Leider bekam ich nach einiger Zeit einen WPS-Crash (aus bisher unbekannter Ursache), und ich sah mich genötigt, ein Archiv zurückzuholen. Danach lief zuerst der FF 38 nicht mehr und das von vielen hier empfohlene ANPM war nicht vorhanden ("unbekannter Dateiname"), ebenso wie YUM oder RPM.
Dann hole Dir doch rasch den aktuellen ANPM: https://www.arcanoae.com/resources/down ... e-manager/. Aber besser zuvor alles durchlesen ;)

User avatar
DonLucio
Posts: 288
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio » Wed 23. May 2018, 13:51

LotharS wrote:
Wed 23. May 2018, 12:41
Von welcher Quelle hast Du denn dieses ZIP bezogen??
Von hier: http://os2news.warpstock.org/Warpzilla.html. War Tip hier aus dem Forum.
LotharS wrote: Meine FF-45-Version stammt von hier: https://github.com/bitwiseworks/mozilla ... _OS2_GA1_1.
Danke für den Hinweis auf diese Quelle und auch deine weiteren Erklärungen. Werde also asap versuchen, damit einen neuen Anlauf zu machen.

Gruß,
Lutz Wagner

User avatar
ak120
Posts: 827
Joined: Thu 8. May 2014, 12:50
Location: Demmin

Post by ak120 » Wed 23. May 2018, 14:53

DonLucio wrote:
Wed 23. May 2018, 13:51
LotharS wrote:
Wed 23. May 2018, 12:41
Von welcher Quelle hast Du denn dieses ZIP bezogen??
Von hier: http://os2news.warpstock.org/Warpzilla.html. War Tip hier aus dem Forum.
Die komplizierte Verzeichnisstruktur und unzählige BEGINLIBPATH-Anweisungen kann man sich meist ersparen. Ohne Angaben zum aktuellen Inhalt von LIBPATH ist es schwierig einen umfassenden Lösungsweg aufzuzeigen.

1. Sämtliche DLL-Dateien aus den oben erwähnten Archiven direkt in das Programmverzeichnis der Mozilla-Anwendung kopieren. Dann ist es unerheblich ob "." oder der explizite Pfadname am Anfang von LIBPATH stehen.
2. Nur die notwendigen Dateien aus dem fontconfig-Archiv als UNIXROOT-Struktur auspacken. DLL-Dateien siehe Punkt 1.
3. UNIXROOT (und evtl. BEGINLIBPATH) setzen und die entsprechende Anwendung ausführen.

Sollten andere Umgebungsvariablen, welche die Mozilla-Anwendungen betreffen, bereits höherrangig festgelegt worden sein - bspw. in der CONFIG.SYS, dann können diese Werte ebenfalls unter 3. zurechtgebogen werden. Komfortabler ist es natürlich diese Einstellungen bei der Benutzeranmeldung an die Domäne durchzuführen.

User avatar
LotharS
Posts: 474
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Wed 23. May 2018, 16:31

DonLucio wrote:
Wed 23. May 2018, 13:51
War Tip hier aus dem Forum.
Kann man nicht genug von kriegen... Eine meiner Lieblings-Schmökerseiten ist http://ecsoft2.org/, Gabriele gibt sich echt Mühe. Dort fand ich übrigens meine Links.
Viel Erfolg!

User avatar
LotharS
Posts: 474
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS » Wed 23. May 2018, 18:31

ak120 wrote:
Wed 23. May 2018, 14:53
1. Sämtliche DLL-Dateien aus den oben erwähnten Archiven direkt in das Programmverzeichnis der Mozilla-Anwendung kopieren. Dann ist es unerheblich ob "." oder der explizite Pfadname am Anfang von LIBPATH stehen.
Der folgerichtige Brüller wäre sodann, die Entwickler zu bitten, sämliche libs _statisch_ mit in die exe hineinlinken zu lassen, damit selbst solche lästige Kopiererei entfällt und zugleich keine dll-Duplikate entstehen, die einen in die "Hölle" schicken. Was wollen wir auch mit moderneren Systemen. :twisted:
(Sorry, der Gag musste mal raus :P )
Die komplizierte Verzeichnisstruktur und unzählige BEGINLIBPATH-Anweisungen kann man sich meist ersparen.
Soweit allgemein abstrakt ok, falls das konkret weiterhelfen würde.
Die Verzeichnisstruktur sähe im konkreten Fall tatsächlich etwas einfacher aus, wenn den Entwicklern gefolgt wäre; BEGINLIBPATH erzielt man indirekt einfacher durch RUN!.exe. Kommt wie immer auf den konkreten Fall an, diesmal ginge es (bzw. in FF45 sogar unnötig).
Aber was soll's, es ging um Hilfe und nicht ums Rechthaben. Aufs Helfen kommt man natürlich konkret erst dann, wenn man sich (hier) mit ArcaOS mindestens ein wenig praktisch beschäftigt hat und nicht höchstens davon gelesen.

User avatar
ak120
Posts: 827
Joined: Thu 8. May 2014, 12:50
Location: Demmin

Post by ak120 » Wed 23. May 2018, 21:09

LotharS wrote:
Wed 23. May 2018, 18:31
Der folgerichtige Brüller wäre sodann, die Entwickler zu bitten, sämliche libs _statisch_ mit in die exe hineinlinken zu lassen, damit selbst solche lästige Kopiererei entfällt und zugleich keine dll-Duplikate entstehen, die einen in die "Hölle" schicken. Was wollen wir auch mit moderneren Systemen.
Dynamische Bibliotheken gab es schon immer unter OS/2. Und am grundsätzlichen Verfahren hat sich in den letzten 20 Jahren auch nichts geändert. Ich habe keine Ahnung was mit "sämliche libs" unscharf umschrieben wird. Doch erscheint diese Aussage äußerst unsachlich. Etwas mehr Sorgfalt und Vernunft bei der Erstellung einer Antwort wäre angebracht. Ohne Verständnis der Grundlagen lassen sich auch keine "moderneren Systeme" sinnvoll nutzen.

aschn
Posts: 623
Joined: Wed 25. Dec 2013, 22:47

Post by aschn » Wed 23. May 2018, 22:38

LotharS wrote:
Wed 23. May 2018, 18:31
Der folgerichtige Brüller wäre sodann, die Entwickler zu bitten, sämliche libs _statisch_ mit in die exe hineinlinken zu lassen, damit selbst solche lästige Kopiererei entfällt und zugleich keine dll-Duplikate entstehen, die einen in die "Hölle" schicken. Was wollen wir auch mit moderneren Systemen. :twisted:
(Sorry, der Gag musste mal raus :P )
So schlecht wär die Idee nicht, wenn OS/2 nicht diese 32-Bit-Beschränkung hätte (oder wenigstens PAE könnte). ;-) Aktuell führt so ein Vorgehen natürlich bereits viel eher als sonst dazu, dass ein Speicherbereich zu Ende ist. Wichtig in diesem Zusammenhang sind:

o Code, der mehrfach genutzt wird, in DLLs auslagern.
o Diese DLLs mit der Versionsnummer im Namen für OS/2 unterscheidbar zu halten.
o Unterstützung von älteren Versionen dieser DLLs durch Verweis-DLLs, die nur auf die Funktionen in den neuesten, abwärtskompatiblen Versionen verweisen.
o Möglichst hoch automatisiertes Paketmanagement dafür.
o DLLs, die sich lohnen, "hochladen".
o Den richtigen Kernel dazu verwenden und darin noch enthaltene Bugs durch Patches fixen.

Das passiert gerade mit bww und Arca Noae.
Andreas Schnellbacher

User avatar
ak120
Posts: 827
Joined: Thu 8. May 2014, 12:50
Location: Demmin

Post by ak120 » Thu 24. May 2018, 17:06

aschn wrote:
Wed 23. May 2018, 22:38
o Code, der mehrfach genutzt wird, in DLLs auslagern.
Diese Idee mag sinnvoll sein. Nur sollte es auch der Wirklichkeit entsprechen. Wenn nur 40% des Codes innerhalb gewisser DLLs überhaupt genutzt werden, ist es reine Verschwendung auch die restlichen 60% zu laden. Dies sind nur Näherungswerte in der Annahme, daß sämtliche Instruktionen auch unter OS/2 wirklich nutzbar sind. Je nach verwendetem Linker und Kompilierer könnten es In den Mozilla-Anwendungen selbst u.U. auch 70-80% Speicherverschwendung sein. Und selbst der größte Brocken XUL.DLL wird nur von der jeweiligen einzelnen Anwendung verwendet.

_diver
Posts: 131
Joined: Fri 27. Jun 2014, 10:57

Post by _diver » Thu 24. May 2018, 17:26

DonLucio wrote:
Wed 23. May 2018, 12:22
Noch ein Nachsatz:
Einige Foristen hier fragen sich verwundert, warum ich einen Bogen um das YUM/RPM-Thema mache, wo es doch schon in ArcaOS integriert ist und einfach nur benutzt zu werden braucht. Dazu nur soviel: Unmittelbar nach Installation des ArcaOS 2.0.1 lief auch alles, auch der (nicht ganz so aktuelle) FF 38, recht zufriedenstellend. An 99,9% CPU kann ich mich nicht erinnern. Leider bekam ich nach einiger Zeit einen WPS-Crash (aus bisher unbekannter Ursache), und ich sah mich genötigt, ein Archiv zurückzuholen. Danach lief zuerst der FF 38 nicht mehr und das von vielen hier empfohlene ANPM war nicht vorhanden ("unbekannter Dateiname"), ebenso wie YUM oder RPM.
Und genau hier liegt der Hase im Pfeffer. So wie es aussieht ist das Archiv unvollständig oder kein ArcaOS 5.0.1 (nicht 2.0.1 wie du schreibst, denn das gibt es nicht) Archiv.
Und um ein reibungsloses System wieder zu erlangen, muss das Archiv vollständig zurück. Weil ohne das kannst du einige Dinge in ArcaOS nicht mehr benutzen. Weil wie gesagt, einiges auf yum/rpm zurückgreift.