User-Treffen in Köln 2014

[Frank Wochatz]

- Umgehung von Speicherengpässen durch Modifikation des Loadheader von EXE oder DLL, um oberhalb von 512MB geladen zu werden, mit einer aktuellen Version von MARKEXE oder ABOVE512.

Aha. Wie genau funktioniert das, bzw. wie kann man das selber ausprobieren? Gibt es da schon etwas, oder es ist noch under construction?

[wilfried]

Roderick hat darauf hingewiesen, das in diesem Thema viel "trial and error" steckt, d.h. von den unmodifizierten Dateien vorher Sicherheitskopien erstellen.
Als heisse Kandidaten für diese Umstellung nennt er:
- XUL.DLL aus dem Mozilla-Bereich
- alle DLLs aus dem OpenOffice-Bereich

Diese Möglichkeit besteht schon länger, wurde aber bisher kaum angewendet. Problem: Nicht alle Programme können damit umgehen. D.h. hier darf noch Forschungsarbeit geleistet werden.

[wilfried]

Aha. Wie genau funktioniert das, bzw. wie kann man das selber ausprobieren? Gibt es da schon etwas, oder es ist noch under construction?

[Frank Wochatz]

Das Programm ist offenkundig von 2004. Ok - ich dachte, das ist nur ein Analyse-Tool...

Zum Glück benutze ich kein OO oder AO, deswegen läuft mein Rechner ev. auch so stabil , die Geschichte mit XUL ist natürlich nicht uninteressant.

Gespannter bin ich allerdings auf ev. Patche von Holger, was das Speichermanagement betrifft. War Holger eigentlich auch da?

[wilfried]

Ich kenne Holger nicht persönlich.

[LotharS]

- Hinweis auf einen aktuellen Fix im JFS, der auf arcanoae angeboten wird

Allein das (Roderick nannte es eine "Zeitbombe") war mir ein Grund, prompt bei arcanoae zu shoppen:
Zitat aus der Readme zum JFS-Fix:

1.09.06 - 23-Oct-2013 - David Azarewicz
---------------------------------------
Fixed a defect in the IFS which caused incomplete log entries to be written.
If the system crashed before the affected sectors were written to the disk,
a subsequent log redo would corrupt the disk and mark the disk as clean.

Ich hoffe aber, der Härtetest wird hier unnötig...

[Wolfie]

Hallo Leute,

nachdem ich diesen Beitrag fälschlicherweise im Beitrag "Usertreffen 2014" platziert hatte, hier nochmals an der richtigen Stelle.

Zu meinem Beitrag über der Apotop Wi-Reader möchte ich noch ergänzen, dass ich momentan gerade dabei bin, den Inhalt einer an dieses Gerät angeschlossenen 3,5"-40GB-Festplatte (NTFS-formatiert) auf meine über USB an den Laptop angeschlossene externe Festplatte (JFS-formatiert) zu kopieren. Da mein Laptop WLAN nur mit 54 MBit/s unterstützt, dauert dies natürlich etwas länger als bei direkt angeschlossenen Geräten. Für 9,5 GB habe ich 102 Minuten benötigt. Da die CPU aber nicht übermäßig stark belastet wird (etwa 35%), kann dies in Hintergrund laufen.

Bei meinen Ausführungen bezüglich ssh hatte ich noch den für meine Arbeit wichtigsten Aspekt vergessen. Es ist bei eingerichteter SSH-Verbindung nicht nur möglich, eine Textkonsole über ssh oder grafische Oberfläche via getunneltem VNC zu nutzen, sondern auch Daten in beide Richtungen zu kopieren. Dies geschieht kommandozeilengesteuert über das Kommando scp oder eingebettet in Netdrive über das ssh-Plugin. Ich würde wie versprochen die Dokumente für die Zugangsbeschreibung noch nachliefern. Wo kann ich die Dateien hinstellen? Alternativ oder zusätzlich könnte ich nächstes Jahr einen Vortrag zu diesem Thema vorbereiten.

Viele Grüße
Wolfgang

[ARoederer]

Moin

Du kannst die Dateien gerne hier im Forum hochladen (Neues Thema erstellen und dann als Anhang).
Wenn die zu groß werden, einfach mir per PM/E-Mail Bescheid sagen.

Andreas

[Wolfie]

Weitere Bilder vom Usertreffen und Antworten auf Fragen zu meinen Vorträgen

Da mein Fotoapparat leider Bilder geliefert hat, die mich von der Qualität her ziemlich enttäuschten, stelle ich hier nur ein paar Panoramafotos vom Vortagsgeschehen im Raum Lille ins Netz, bei denen aufgrund ihrer Größe die mangelnde Qualität nicht so auffällt. Nach dem Zusammensetzen der Einzelbilder mit dem Programm Canon Photostich unter VirtualPC habe ich die Bilder übrigens noch mit Impos/2 nachbearbeitet, dabei insbesondere weiße Stellen in den Eck- und Randbereichen mit dem Überblendwerkzeug ausgefüllt.

Weiterhin sind Fragen zur IMPOS-REXX-Schittstelle und zum REXX-Internetradio im Röhrenradiodesign gestellt worden.
- Das Internetradio-Frontend ist downloadbar bei Hobbes und steht im Bereich /pub/os2/apps/internet . Der Dateiname ist irxradio-1.4.zip .
- Die Dateien zu meinem Vortrag über die Videoerstellung unter Zuhilfenahme der IMPOS-REXX-Schnittstelle (Präsentation, Programmcode und Fehlerkorrektur der Impos-Dokumentation) würde ich gern zur Verfügung stellen. Ich hatte bereits begonnen, dafür ein neues Thema zu erstellen. Leider lässt aber dieses Forum nicht zu, Dateien mit der Änderung PDF und TXT hochzuladen. Muss ich diese Dateien in ein ZIP-Archiv packen?

Viele Grüße
Wolfgang

[wilfried]

Hallo Wolfie,

- Das Internetradio-Frontend ist downloadbar bei Hobbes und steht im Bereich /pub/os2/apps/internet . Der Dateiname ist irxradio-1.4.zip .

Vielen Dank, habs gefunden. Bin gerade dabei die Senderliste mit meinen Favoriten anzureichern. Dabei fällt mir auf das man an irxradio.cfg nicht herankommt, während das Radio läuft.
Ich habe mir daher erlaubt, folgende Änderung einzubauen:

alt: call linein "irxradio.cfg" /* close */
neu: RC = STREAM("irxradio.cfg",'C','CLOSE')

Die von Dir benutze Methode funktioniert nur für 'LINEOUT'. Versteh das bitte nicht als Klugscheisserei oder Besserwessitum, ich hab am Samstag so viel von dir gelernt, dass ich froh bin eine Kleinigkeit zurückgeben zu können.

[Sigurd]

Hallo zusammen,

damit alles auch transparent und nachvollziehbar bleibt hänge ich Euch hier die Abrechnung ein, die ich von der Jugendherberge Heute erhalten habe:

Rechnung 2014.jpg (189.44 KiB) 13263 mal betrachtet

Wenn man hier die auf mich persönlich entfallenden Kosten abzieht:

Gesamtsumme: 332,50 Euro
abzüglich "mein" Zimmer - 51,50 Euro
abzüglich "mein" Essen - 6,00 Euro
abzüglich "mein" Internet - 5,00 Euro
abzüglich Internet "Wolfie" - 5,00 Euro (hat er mir schon direkt am Tag erstattet)

Summe verbleibend: 265,00 Euro

Ich gehe davon aus, dass sich die Kosten für 2015 - wenn überhaupt - nur geringfügig erhöhen werden, sodaß wir hier mit ähnlichen Werten rechnen können.

Da bereits 245,00 Euro "gespendet" worden sind ist also der Beitrag für 2015 bereits vollständig beisammen, den Rest übernehmen Thomas und ich selbstverständlich gerne.

Sobald ich neues von der Buchungsstelle der Jugendherberge höre, werde ich mich melden.

[Wolfie]

Antwort an Wilfried zu IrxRadio:

Hallo Wilfied, vielen Dank für Deinen Vorschlag. Ich habe unter "OS/2 & eCS - Apps" einen neuen Beitrag zum Thema IrxRadio erstellt.

Wolfgang

[Jörg Rustmeier]

Bin gerade dabei die Senderliste mit meinen Favoriten anzureichern.

Mit Hilfe der Daten aus der Fritzbox habe ich mir einmal folgende irxradio.cfg gebaut:
------------------------------
AlternativeFM
-playlist http://www.alternativefm.de/afm_128.m3u
Austria Hitradio OE 3
-playlist http://mp3stream7.apasf.apa.at:8000/
Bayern 1
-playlist http://streams.br-online.de/bayern1_2.m3u
Bremen 1
-playlist http://httpmedia.radiobremen.de/bremeneins.m3u
BEL Studio Brussel
-playlist http://mp3.streampower.be/stubru-high
Bermana Kurdi
-playlist http://www.wdr.de/wdrlive/media/funkhau ... rdisch.m3u
die neue welle
-playlist http://www.die-neue-welle.de/dnw_128.m3u
Deutschlandfunk
-playlist http://www.dradio.de/streaming/dlf.m3u
Dradio Kultur
-playlist http://www.dradio.de/streaming/dkultur.m3u
Dradio Wissen
-playlist http://www.dradio.de/streaming/dradiowissen.m3u
IT Radio 101
-playlist http://players.creacast.com/creacast/r101/playlist.pls
Jazzradio
-playlist http://www.jazzradio.net/docs/stream/jazzradio.pls
Eins Live Diggi
-playlist http://www.wdr.de/wdrlive/media/einslivedigi.m3u
Funkhaus Europa
-playlist http://www.wdr.de/wdrlive/media/fhe.m3u
Radio Fritz
-playlist http://www.fritz.de/live.m3u
LUX RTL Letzebuerg
-playlist http://radio.rtl.lu/mp3.pls
Sputnik Livestream
-playlist http://www.sputnik.de/m3u/live.hi.m3u
SWR 3
-playlist http://mp3-live.swr3.de/swr3_s.m3u
Swissgroove
-playlist http://www.swissgroove.ch/listen.php
HR3
-playlist http://metafiles.gl-systemhaus.de/hr/hr3_2.m3u
NDR2
-playlist http://www.ndr.de/resources/metadaten/a ... u/ndr2.m3u
radioeins
-playlist http://www.radioeins.de/live.m3u
RadyoSunet
-playlist http://www.wdr.de/wdrlive/media/koelnradyosunet.m3u
------------------------------
Gruß, Jörg

[Holger]

Hallo zusammen,

Roderick hat darauf hingewiesen, das in diesem Thema viel "trial and error" steckt, d.h. von den unmodifizierten Dateien vorher Sicherheitskopien erstellen.
Als heisse Kandidaten für diese Umstellung nennt er:
- XUL.DLL aus dem Mozilla-Bereich
- alle DLLs aus dem OpenOffice-Bereich

Diese Möglichkeit besteht schon länger, wurde aber bisher kaum angewendet. Problem: Nicht alle Programme können damit umgehen. D.h. hier darf noch Forschungsarbeit geleistet werden.

nur, um Frust vorzubeugen hier nochmal die Info (für diejenigen, die es nicht mitbekommen haben):

- es geht nur mit 32-Bit Code/Daten
- es geht (derzeit) nur mit dem SMP-Kernel, der bei der ECS 2.2 Beta II oder neuer dabei ist

Der Grund für letzteres liegt darin, dass die anderen Kernelversionen einen Bug haben, der beim "unload" einer entsprechend markierten dll zu einem Trap im Kernel führen kann.

Problemlos hochladbar sind:
SOFTDRAW (nur Code, Daten lohnt nicht),
NETAPI32 (beides)
MMPM (Code)
PROCL (Code)
SCENTER (Code)
TCPIP32 (Code)
LIBC065 (nur Daten)
VPCWIN (nur Code)
Z! (beides)
ZDART (beides)

Aktuell teste ich die XFLDR mit hochgeladenem Code.

Apropos Shared Memory noch eine Empfehlung:
In der config.sys sollte folgendes stehen (OHNE SET):

MEMMAN=SWAP,NOPROTECT,NOPACK
DLLBASING=OFF

Die erste Anweisung (das NOPACK) verhindert, dass der Kernel Speicher für (kleine) 16-bit Dll's reserviert, um diese dort in einem speziellen gepackten Format ablegen zu können. Da es davon heute nicht mehr so viele gibt ist es besser, diese Dll's ganz normal laden zu lassen und keinen Speicher zu reservieren.

Die zweite Anweisung verhindert, dass bestimmte Dll's an vordefinierten Stellen im Speicher geladen werden. Das verlängert zwar (theoretisch) die Ladezeit (merkt man bei den heutigen Systemen nicht), vermeidet aber "Löcher" in der Speicherbelegung beim Systemstart (was viel entscheidender ist!).
Es nutzt überhaupt nichts, wenn 100 MB im Shared Memory frei sind, wenn dieser freie Speicher auf 100 einzelne Fragmente aufgeteilt ist. Damit eine weitere Dll geladen werden kann braucht der Kernel mindestens so viel Platz, dass er für alle Objekte in der Datei ein passendes freies Stück findet. Die einzelnen Objekte der Datei (Ressourcen, Code oder Datensegment) können vom Loader nicht geteilt werden.

Ich hoffe, meine Experimente mit den PM-Semaphoren bald abschließen zu können, dann gibt es einen neuen PM-Fixpack.

Grüße Holger

[wilfried]

Roderick hat darauf hingewiesen, das in diesem Thema viel "trial and error" steckt, d.h. von den unmodifizierten Dateien vorher Sicherheitskopien erstellen.
Als heisse Kandidaten für diese Umstellung nennt er:
- XUL.DLL aus dem Mozilla-Bereich
- alle DLLs aus dem OpenOffice-Bereich

Diese Möglichkeit besteht schon länger, wurde aber bisher kaum angewendet. Problem: Nicht alle Programme können damit umgehen. D.h. hier darf noch Forschungsarbeit geleistet werden.

So aus der (Speicher) Not heraus habe ich mal angefangen zu experimentieren.
Für Thunderbird und Firefox habe ich folgendes geändert:
ABOVE512 DLL xul.dll -c

Damit wird nur der Code über die 512MB-Grenze angehoben. Ein Versuch auch den Datenteil nach oben zu schieben schlug fehl.
Die Modifikation habe ich gemacht nachdem ich die entsprechenden DLL's kopiert und bevor ich die entsprechenden Programme gestartet hatte.
Nachmachen auf eigene Gefahr!

[wilfried]

So aus der (Speicher) Not heraus habe ich mal angefangen zu experimentieren.
Für Thunderbird und Firefox habe ich folgendes geändert:
ABOVE512 DLL xul.dll -c

Damit wird nur der Code über die 512MB-Grenze angehoben. Ein Versuch auch den Datenteil nach oben zu schieben schlug fehl.
Die Modifikation habe ich gemacht nachdem ich die entsprechenden DLL's kopiert und bevor ich die entsprechenden Programme gestartet hatte.
Nachmachen auf eigene Gefahr!

Auf keinen Fall nachmachen, wenn man SMP Kernel 105 hat, so wie ich! Muss Thunderbird neu installieren, weil meine Mail-Accounts nicht mehr erkannt werden.

[aschn]

Für Thunderbird und Firefox habe ich folgendes geändert:
ABOVE512 DLL xul.dll -c

Damit wird nur der Code über die 512MB-Grenze angehoben. Ein Versuch auch den Datenteil nach oben zu schieben schlug fehl.

Ich hab's jetzt ein paar Tage mit dem aktuellsten SeaMonkey getestet: Mit hochgeladenem Code läuft es bei mir nicht stabil. Das Beenden hatte häufiger zu Traps geführt. Auch ein Kernel-Trap war dabei, trotz Kernel 14.106.

[wilfried]

Schade, dann müssen wir uns bzgl. Parallelarbeit wohl etwas einschränken.

[Guzzi]

Für Thunderbird und Firefox habe ich folgendes geändert:
ABOVE512 DLL xul.dll -c

Damit wird nur der Code über die 512MB-Grenze angehoben. Ein Versuch auch den Datenteil nach oben zu schieben schlug fehl.

Ich hab's jetzt ein paar Tage mit dem aktuellsten SeaMonkey getestet: Mit hochgeladenem Code läuft es bei mir nicht stabil. Das Beenden hatte häufiger zu Traps geführt. Auch ein Kernel-Trap war dabei, trotz Kernel 14.106.

Dave Yeo schrieb in mozilla.dev.ports.os2:
"All builds are also built against a newer libos2 which may behave better when marking xul.dll for high memory. Here it seems to work fine for Firefox but nor for SeaMonkey."

Dass betrefft https://bitbucket.org/dryeo/dry-comm-es ... .en-US.os2.

Dass problem is bekannt und wahrscheinlich geloest: https://github.com/bitwiseworks/mozilla-os2/issues/89

Uebrigens, ich habe die ganze RPM usr\lib Verzeignis mit highmem.exe fuer code hoch markiert, ohne Probleme, teste dass schon seit September 2014. Mann muss natuerlich nach YUM update highmem nochmals ausfuehren fuer diese Verzeichnis, am besten nach starten von ein maintenance Partition. Wenn mann sowas nicht hast, zuerst unlock*.dll, dann highmem -c *.dll, dann neustart
Highmem.exe ist neuer als above512 und im openoffice4\program Verzeichnis.

update LIBC066 in usr\dll hochladen geht nicht.

[aschn]

Dave Yeo schrieb in mozilla.dev.ports.os2:
"All builds are also built against a newer libos2 which may behave better when marking xul.dll for high memory. Here it seems to work fine for Firefox but nor for SeaMonkey."

Dass betrefft https://bitbucket.org/dryeo/dry-comm-es ... .en-US.os2.

Dass problem is bekannt und wahrscheinlich geloest: https://github.com/bitwiseworks/mozilla-os2/issues/89

[...]

LIBC066 in usr\dll hochladen geht nicht.

Danke. Ich hatte SeaMonkey mit und ohne Flash getestet. Ich bin gespannt auf die nächste Version.