Grundlagen der LIBPATH-Syntax

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Grundlagen der LIBPATH-Syntax

Beitrag von DonLucio »

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: Alles auswählen

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: Alles auswählen

[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.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

DonLucio hat geschrieben: Sa 19. Mai 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
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

aschn hat geschrieben: Sa 19. Mai 2018, 16:02Das ist ein CMD-Skript. REXX kommt darin nicht vor.
Äh ... ja, du hast natürlich recht. Sorry.
aschn hat geschrieben: Sa 19. Mai 2018, 16:02Als 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: Alles auswählen

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

Code: Alles auswählen

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.
Zuletzt geändert von DonLucio am Sa 19. Mai 2018, 16:28, insgesamt 1-mal geändert.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

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)
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

PS: NSPR4.dll liegt bei mir auch in c:\ecs\dll
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

Frank Wochatz hat geschrieben: Sa 19. Mai 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...
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

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.
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

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: Alles auswählen

@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.
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

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

Gruß,
Don Lucio.
_diver
Beiträge: 306
Registriert: Fr 27. Jun 2014, 10:57

Beitrag von _diver »

DonLucio hat geschrieben: Sa 19. Mai 2018, 19:44
Frank Wochatz hat geschrieben: Sa 19. Mai 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.
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

DonLucio hat geschrieben: Di 22. Mai 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 ;)
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

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...
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Frank Wochatz hat geschrieben: Di 22. Mai 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 :)
Zuletzt geändert von LotharS am Di 22. Mai 2018, 19:33, insgesamt 1-mal geändert.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

LotharS hat geschrieben: Di 22. Mai 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.
Zuletzt geändert von aschn am Di 22. Mai 2018, 21:31, insgesamt 2-mal geändert.
Andreas Schnellbacher
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

LotharS hat geschrieben: Di 22. Mai 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 hat geschrieben: 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
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Noch einmal zurück auf "Los":
DonLucio hat geschrieben: Sa 19. Mai 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.
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

DonLucio hat geschrieben: Mi 23. Mai 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 ;)
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

LotharS hat geschrieben: Mi 23. Mai 2018, 12:41Von welcher Quelle hast Du denn dieses ZIP bezogen??
Von hier: http://os2news.warpstock.org/Warpzilla.html. War Tip hier aus dem Forum.
LotharS hat geschrieben: 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
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

DonLucio hat geschrieben: Mi 23. Mai 2018, 13:51
LotharS hat geschrieben: Mi 23. Mai 2018, 12:41Von 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.
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

DonLucio hat geschrieben: Mi 23. Mai 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!
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

ak120 hat geschrieben: Mi 23. Mai 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.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

LotharS hat geschrieben: Mi 23. Mai 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.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

LotharS hat geschrieben: Mi 23. Mai 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
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

aschn hat geschrieben: Mi 23. Mai 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
Beiträge: 306
Registriert: Fr 27. Jun 2014, 10:57

Beitrag von _diver »

DonLucio hat geschrieben: Mi 23. Mai 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.
Antworten