Virtual OS/2 International Consumer Education
VOICE Homepage: http://de.os2voice.org 		November 2001

[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]

editor@os2voice.org

OS/2 Tips

Nach diesen kleinen Perlen durchforsten wir das ganze Web, das Usenet und die OS/2-Mailinglisten. Sind Sie über interessante Informationen über OS/2 oder eComStation gestolpert? Bitte teilen Sie doch Ihr Wissen mit unseren Lesern und schicken Sie Ihre Tipps an editor@os2voice.org. Wenn Sie an einer bestimmten OS/2-Mailingliste interessiert sind, so finden Sie weitere Informationen rund um das Abonnieren auf der VOICE Mailinglistenseite: http://de.os2voice.org/mailinglists.html

Anmerkung des Herausgebers: Diese Tipps sind von OS/2- und eComStation-Anwendern eingesandt worden und können nicht in jedem Fall von uns überprüft werden. Bitte seien Sie vorsichtig, und wenn Sie Sich nicht sicher sind, was Sie tun, so lassen Sie es lieber bleiben.

19. September 2001 - Der erste Tip dieses Monates kommt von Steven Levine, einer der bekanntesten Quellen für Informationen zu OS/2. Diesmal antwortet Steven auf eine Frage zur CONFIG.SYS-Anweisung DLLBASING=OFF, die in der eComStation@yahoogroups.com-Mailingliste gestellt wurde:
Damit wird der standardmäße Ladeadressenoffset von 0x10000, der in die meisten DLLs einkompiliert ist, außer Kraft gesetzt. Ansonsten verschwendet er pro DLL 64K linearen Adressraums. Allerdings muß die Laderoutine den Code nach dem Laden verschieben, wenn diese Option abgeschaltet ist, es kostet also etwas Zeit.

Details entnehmen Sie bitte der ConfigTool Datenbank (cfgtool*.zip bei Hobbes).

19. September 2001 - In comp.os.os2.apps erklärt uns Holger Veit endlich den Unterschied zwischen den Uni und W4 Kernels, die man von Zeit zu Zeit auf IBMs Testcase-Site sieht:
Tatsächlich gibt es nur einen einzigen Unterschied zwischen W4 und UNI: Bei Uni ist das DosSetThreadAffinity (Schreibweise?) API implementiert (das es erlaubt, einen Thread an einen Prozessor zu binden), während W4 'invalid function' zurückgibt. Das ist eine Methode um herauszufinden, welchen Kernel man hat. Da UNI nichts anderes ist als SMP für eine CPU - ein offensichtlicher Widerspruch der Begrifflichkeit - kann man dieses API natürlich nicht wirklich nutzen; aber wenigstens kann man damit Software, die extra für den Betrieb mit SMP ausgelegt wurde, auch mit einer einzigen CPU betreiben.
20. September 2001 - Jemand hatte ein Problem damit, das Java 1.3 Development Kit unter eComStation 1.0 installiert zu bekommen. Glenn Hudson hat in der ecomstation.support.install-Newsgruppe auf Mensys' eComStation Newsserver news.ecomstation.nl eine Lösung angeboten:
Das eCSguide Installationsprogramm funktioniert mit Java 1.3 nicht richtig. Die Java 1.3 Laufzeitumgebung und das Development Kit müssen gleichzeitig installiert werden. Erzeugen Sie auf Ihrer Festplatte ein Arbeitsverzeichnis. Kopieren Sie sowohl \softwarechoice\java13\javainrt.exe als auch \softwarechoice\java13\javaintk.exe von eCS CD 3 in das Arbeitsverzeichnis.

Wechseln Sie in das Arbeitsverzeichnis und führen Sie die folgenden Befehle aus:

javainrt -o

javaintk -o

install

20. September 2001 - In der ecomstation.support.smartsuite-Newsgruppe hatte jemand ein Problem mit der Installation der Lotus SmartSuite 1.6. Tom Troughton, der dieses Problem aufgeworfen hatte, fand selbst die Lösung:
Smartsuite mag es nicht, wenn das Laufwerk, auf das sie installiert werden soll, sehr viel freien Platz hat. Ich habe mir Spacehog von Hobbes (http://hobbes.nmsu.edu/pub/os2/util/disk/spacehog.zip) besorgt, space32.exe ausgeführt und dann ohne Probleme installiert. Keine Notwendigkeit, die Programme mit execmode zu behandeln, keine Probleme mit dem Dateisystem, nichts. Ich habe den Verdacht, daß sich dieses Installationsproblem auf sehr unterschiedliche Weise äußern könnte.
22. September 2001 - Hier haben wir etwas, das bei einem kleineren Problem mit Sysbar und dem SDD Grafiktreiber helfen könnte. Dank an Brian aus comp.os.os2.apps für den Tip:
Ich habe kürzlich auf den SDD (IBM) Treiber umgestellt und alles funktioniert ziemlich gut, abgesehen davon, daß ich alle Icons im Sysbar Task Switcher verloren habe. Zufällig fand ich die CUSTOM-Funktion in Sysbars Einstellungsnotizbuch (unter Display). Ich habe etwas mit den Zahlen herumgespielt und meine Icons zurückbekommen. Nicht alle Zahlen geben Ihnen die Icons zurück, Sie müssen es ausprobieren.
25. September 2001 - Wenn Sie einer von den Leuten sind, die ColorWorks V2 mit der schön gebundenen Anleitung gekauft haben und sich fragen, ob es dafür Einführungen gab, hat Mike O'Connor aus der os2user@yahoogroups.com-Mailingliste folgendes für Sie:
So hatte auch meine - eine schöne Sache - sowohl CW als auch die Anleitung. Leider gibt eine keine Unterstützung mehr von SPG für OS/2. Falls es noch andere gibt, die V2 mit nur 7 Online-Einführungen haben - Sie können auf Hobbes etc. nach cworkslesson8.zip (~3MB) suchen, das "TECH8.INF - working with image masks" enthält.
Anm.d.Hrsg.: Die sieben Einführungen auf meiner Colorworks-CD sind andere als die auf Hobbes erhältlichen. Es lohnt sich, sich diese auch zu besorgen.
30. September 2001 - Ich verbringe eine Menge Zeit im Kanal #voice des WEBBnet IRC-Netzwerkes und helfe dort OS/2-eCS Anwendern, wo ich kann. Kürzlich hat mir DSOM_eCS im IRC sehr geholfen. Immer, wenn ich meine InCharge-Dateien auf meine über das Netzwerk angebundene JFS-Sicherungspartition sichern wollte, erhielt ich eine Fehlernachricht von zip.exe.. Nachdem ich mein JFS auf die neueste Version JFS0622 von IBMs Testcase-Site aktualisiert hatte, verschwand das Problem. Danke DSOM :-)
<DSOM_eCS> Etwas wie zip warning: new zip file left as: zia00058?
<DSOM_eCS> zip I/O error: Permission denied.
<madodel> Etwas wie das.
<DSOM_eCS> zip error: Could not create output file (was replacing the original zip file).
<DSOM_eCS> Ja, das Problem habe ich auch gesehen....aber es ist kein Problem mit Norman....das ist ein tiefgreifender JFS Fix.
<madodel> Die erzeugten ZIPs sind ok, sie haben nur seltsame Namen und es gibt diese Fehlernachrichten.
<DSOM_eCS> Ich habe das Problem gelöst, indem ich auf JFS0622 umgestellt habe, das JFS-Volume gelöscht habe, ein neues JFS-Volume angelegt habe und es "lang" als JFS formatiert habe.
<DSOM_eCS> Jau, die zia00058 etc. Dateien sind temporäre ZIP-Dateien....ich denke, daß es also am System des Anwenders liegt, ob sie komplett sind.
30. September 2001 - Andrew Lundgren hat den folgenden Tip in der ecomStation@yahoogroups.com Mailingliste über eine praktische Schriftensammlung, die er auf Hobbes gefunden hat, veröffentlicht:
Ich habe die folgende Datei auf Hobbes gefunden:

mswbfnts.zip

Aus dem README:

"Dies sind alles TrueType-Schriften, die aus Microsoft's "TrueType core fonts for the web" Paketen stammen, die unter http://www.microsoft.com/typography/fontpack/default.htm
erhältlich sind.

Ich habe dieses Paket zusammengestellt, da die Schriften auf MSs Website nur als selbstextrahierendes Win32-EXE verfügbar sind, worauf die meisten OS/2-Anwender nicht zugreifen können. Hier sind sie also in einer einfachen ZIP-Datei."

2. Oktober 2001 - Pete Milne schickte den folgenden Tip an tips@os2voice.org darüber, wie man IBM Works auf einem nach-Warp 4 OS/2 System (MCP/ACP/WSeB/eCS) einrichtet.
Es ist bekannt, daß IBM Works auf dem Warp Convenience Pak "nicht funktioniert" - obwohl das Paket auf eCS läuft, die eigentlich das gleiche ist.

Das Ausführen des Skriptes ibmwdesk.cmd nach der Installation des CP für Warp 4 stellt die Objekte der Arbeitsoberfläche und die CONFIG.SYS-Einträge für IBM Works wieder her, aber die Programme laufen nicht.

Der Grund dafür ist anscheinend, daß die Dateien ien30pde.dll und fpwrec.dll fehlen. Man findet sie bei einer nicht-CP Warp 4-Installation in \OS2\DLL, oder in \OS2IMAGE\FI\BONUSPAK\IBMWORKS auf der Warp 4 CD. Anstatt nach <CP_Laufwerk>:\OS2\DLL habe ich sie nach \BonusPak\IbmWorks kopiert, um das Konfliktrisiko zu verringern. Bis setzt sieht alles in Ordnung aus...

Ich habe das praktische Programm PMDLL von Arthur van Beek und Steven Levine benutzt, um dies herauszufinden.

4. Oktober 2001 - In comp.os.os2.networking.tcp-ip fragte jemand nach einem potentiellen Sicherheitsproblem bei der Ausführung von Perlskripten unter OS/2, da man perl.exe im cgi-bin Verzeichnis haben muß. Simon Bowring hat folgenden Vorschlag:
Eine Möglichkeit zur Vermeidung ist die Verwendung von OS/2s wenig bekanntem EXTPROC Befehl, mit dem man einen externen Kommandoprozessor zur Bearbeitung der Perl-Skripte angeben kann.

Sie müssen Ihre Perl-Skripte in *.CMD-Dateien umbenennen und am Anfang eine Zeile wie EXTPROC W:\MeinPfad\perl.exe einfügen.

Dadurch wird OS/2 W:\MyPath\perl.exe aufrufen, um das Skript auszuführen. Allerdings müßte der Interpreter wissen, daß er die EXTPROC-Zeile ignorieren muß - möglicherweise tut die OS/2-Version dies, ich habe keine Ahnung, ich habe sie nicht! Geben Sie help EXTPROC ein, um weitere Hilfe zu erhalten.

Das entspricht Unix' "#!/bin/myshell" Geschichte.

Und Martin Vorlaender fügte hinzu:
Er tut es. Aus README.OS2:

Wenn Sie anderenfalls eine OS/2-mäßige Shell wie CMD oder 4OS2 benutzen, plazieren Sie folgendes am Anfang Ihres Perl-Skriptes:

extproc perl -S -meine_optionen
Benennen Sie Ihr Programm in foo.cmd um und starten es, indem Sie folgendes eingeben:
foo arg1 arg2 arg3
Denken Sie daran, daß Sie den Schalter -S  benutzen müssen und das Skript sich im PATH befinden muß, da aufgrund dummer OS/2-Beschränkungen der volle Pfad bei Verwendung von EXTPROC nicht zur Verfügung steht. Auf der positiven Seite: Wenn Sie den vollen Pfad zu Ihrem Skript kennen, können Sie es immer noch über
perl ../../blah/foo.cmd arg1 arg2 arg3
starten (beachten Sie, daß das Argument -meine_optionen durch die extproc Zeile in Ihrem Skript bearbeitet wird, lesen Sie dazu das Kapitel über "extproc in der ersten Zeile").
4. Oktober 2001 - Lorne Sunley hatte in comp.os.os2.setup.misc den folgenden Hinweis zu nicht ladenden WinTV Karten-Treibern parat:
Der Treiber erkennt die Karte nur, wenn sie im PCI-Bus 0 steckt. Einige Geräte haben PCI-Bus 0 und PCI-Bus 2.

Motherboards mit mehr als 4 PCI-Steckplätzen haben zwei über eine PCI-to-PCI-Brücke verbundene PCI-Busse. Wenn das Motherboard bootet, zeigt die Liste der PCI-Geräte die Bus-Nummer in der ersten Spalte, dann die Geräte-ID und andere Sachen. (Zumindest diejenigen, die ich habe.) Die ersten paar PCI-Steckplätze (mindestens 4) liegen auf PCI-Bus 0, der AGP-Steckplatz auf PCI-Bus 1 und die weiteren PCI-Steckplätze auf Bus 2.

Der OS/2 WinTV-Treiber erkennt die Karte nicht auf dem Bus 2 (das ist ein Fehler...). Stecken Sie die Karte einmal in einen Steckplatz neben Ihrer AGP-Karte, diese liegen normalerweise auf Bus 0.

Dies trifft übrigens auch auf einige Soundkarten zu, z.B. auf solche mit Aureal Vortex 1-Chip (Terratec XLerate u.a.).

[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org