X-Authentication-Warning: delorie.com: mail set sender to opendos-bounces using -f Date: Wed, 10 Dec 2003 01:29:56 +0100 From: Matthias Paul Subject: Re: Arachne Web browser for DOS To: opendos AT delorie DOT com Message-id: <000301c3bf17$fd570f00$c03dfea9@atlantis> Organization: Aachen University of Technology (RWTH), Germany MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 X-Priority: 3 X-MSMail-priority: Normal References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id hBADhBut013995 Reply-To: opendos AT delorie DOT com On 2003-12-06, Gary Welles wrote: > The following excerpt from a DV technote may explain why TCP/IP > connection may or may not always work from TASKMGR. > >> ... As a general rule, loading non-DESQview specific network >> shells within a window is not recommended. The reasons are that >> network shells are actually interrupt arbitrators, re-directors, >> and/or repeaters. Depending on the shell configuration (and the >> application software) intended to run in the window, two primary >> factors must be considered. >> >> 1. A packet may arrive for the workstation while this window >> is not the current task. The network must retry sending >> the packet, causing network performance degradation (or the >> network may timeout and drop the work-station). >> >> 2. Only that window would be able to see the network. Loading >> the network shell in more than one window can also confuse >> the network unless the shell has been specifically written >> for this purpose. In regard to direct IPX/SPX calls issued under the task switcher, there is a partial solution to this problem in the form of the TASKID.COM/.MSG task identification program and the TBMI2.COM/.MSG task buffering driver shipping with Personal Netware 1.0, Novell DOS 7, and the "full" version of OpenDOS 7.01 or DR-DOS 7.02/7.03. You can get basic help on TASKID and TBMI2 in DOSBOOK if you search for these keyboards. Somewhere, I have some extra documents explaining all the details, but right now I could only find the German version of one of these files, which won't be of much help unless you'd understand German (I am still attaching it, just in case). But, maybe, if you search for these files as keywords in our list's archive or in Google, this may reveal enough information in order to make good use of them already. In regard to packet drivers, I seem to remember, there was a special packet driver (like PKTMUX or MUXPKT?) to address this problem (originally for use with Windows 3.0), wasn't it? But I have to admit, that it's eons ago, that I have used packet drivers, so I guess, others will have much fresher memory in regard to the details here. Anyone? For the multitasker you may have to add a line to the [Drivers] section of TASKMGR.INI in order to load the corresponding virtual device driver, for example a line like: vxd=c:\drdos.703\nwclient\vipx.386 vxd=c:\drdos.703\nwclient\vtcpip.386 vxd=c:\drdos.703\nwclient\vncomx.386 and increase the GlobalPages= values by some. (If you have a corresponding .386 VxD driver for use under Windows 3.xx, this will in many cases also work under the DR-DOS TASKMGR. Just try it.) Good luck, Matthias ######################################################################### TBMI2 Benutzerhandbuch Copyright 1990 Novell, Inc. Alle Rechte vorbehalten PUFFERVERWALTER FÜR PROZESSUMSCHALTUNGEN V2.0 ---------------------------------------- Der Pufferverwalter für Prozeßumschaltungen V2.0 für IPX/SPX (TBMI2) ist ein Programm, das in Multitasking-Umgebungen verwendet wird, um das Umschalten zwischen Peer-to-peer-Anwendungsprogrammen zu gestatten. Die NetWare-Programmdatei TBMI2.COM sollte verwendet werden, wenn ein DR DOS-Anwendungsprogramm, das direkte Aufrufe an IPX oder SPX absetzt (das wird Peer-to-peer-Anwendung genannt), unter NetWare in einer Multitasking-Umgebung (wie TaskMAX) läuft. TaskMAX erlaubt das Umschalten zwischen Anwendungsprogrammen (auch Auslagern oder Swapping genannt). Jedes Anwendungsprogramm läuft in einer eigenen DR DOS-Sitzung (manchmal auch als DR DOS-Prompt bezeichnet) in 640 KByte Speicher. Ein Teil dieses Speichers (genannt globaler Speicher) enthält Treiber und TSRs wie COMMAND.COM und, wenn Sie NetWare verwenden, IPX.COM und NETx.COM. Der andere Teil des Speichers (genannt der lokale Speicher) enthält das Anwendungsprogramm und dessen Daten. TaskMAX schaltet von einem DR DOS-Anwendungsprogramm zu einem anderen um, indem es den Inhalt der aktuellen DR DOS-Sitzung aus dem konventionellen Speicher auf die Platte verlagert und dann den Inhalt der neuen DR DOS-Sitzung in den konventionellen Speicher lädt. Nur der lokale Speicher wird umgeschaltet; der globale Speicher mit seinen Treibern und TSRs bleibt intakt und wird mit der neuen Sitzung weiterverwendet. Dies bedeutet, daß es verschiedene lokale Speichersegmente (eins für jede DR DOS-Sitzung) gibt, während nur ein globales Speichersegment existiert. Die meisten DR DOS-Anwendungsprogramme unter NetWare mit TaskMAX sprechen das Netzwerk vom lokalen Speicher (wo das Programm liegt) aus über DR DOS-Aufrufe an die Netzwerk-Shell (NETx), die im globalen Speicher liegt, an. Die Shell gibt den Aufruf an IPX oder SPX weiter, die den Aufruf dann an das Netzwerk weitergeben. Dieser Typ von Anwendungsprogrammen benötigt den Pufferverwalter für Prozeßumschaltungen nicht, da die Weitergabe der Aufrufe vom lokalen zum globalen Speicher zwischen dem Anwendungsprogramm und der Shell auftritt. Wenn ein Anwendungsprogramm (im lokalen Speicher), das auf IPX zugreift, direkt mit dem Netzwerk kommunizieren möchte, setzt es einen direkten Aufruf an IPX oder SPX (im globalen Speicher) unter Umgehung der Shell ab. IPX oder SPX geben den Aufruf dann an das Netzwerk weiter. Wird dann von dem Anwendungsprogramm auf ein anderes umgeschaltet, verliert IPX oder SPX den Kontakt mit dem Programm und ist nicht in der Lage, die Daten des Programms zu verwenden. Dieser Typ von Anwendungsprogrammen benötigt den Pufferverwalter für Prozeßumschaltungen, wenn das Programm in einer Umgebung mit Prozeßumschaltung ablaufen soll. Mit dem Pufferverwalter für Prozeßumschaltungen ruft das Anwendungsprogramm (im lokalen Speicher) IPX auf. Der Aufruf wird jedoch vom Pufferverwalter für Prozeßumschaltungen (im globalen Speicher) abgefangen und an IPX oder SPX und dann an das Netzwerk weitergeleitet. TBMI2 verwaltet einen Puffer im globalen Speicher, um Aufrufe aus den verschiedenen lokalen Segmenten zu halten und dann diesen Puffer auf die verschiedenen Sitzungen abzubilden, wenn in diese umgeschaltet wird. TBMI2 (im globalen Speicher) erhält auch ID-Informationen von TaskMAX, so daß es erkennt, welche Sitzung die Aufrufe abgesetzt hat. Ohne TBMI2 kann aus dem Anwendungsprogramm nicht auf ein anderes ohne die Gefahr eines Fehlers umgeschaltet werden. Es besteht keine Notwendigkeit für die Verwendung von TBMI2 in DR DOS-Sitzungen, wenn Sie nicht zwischen Anwendungsprogrammen umschalten müssen. Sie brauchen TBMI2 auch dann nicht, wenn Ihre Anwendungsprogramme nicht direkt mit IPX kommunizieren. Wenn Sie nicht sicher sind, ob Ihr Anwendungsprogramm direkte Aufrufe an IPX absetzt, starten Sie TBMI2; es beeinflußt andere Operationen in keiner Weise, außer daß es ein wenig Speicher belegt. Nachdem das Anwendungsprogramm eine Zeit lang gelaufen ist, geben Sie das Kommando TBMI2 /D ein und sehen sich den Wert an, der mit dem Feld "Far Call Usage" verbunden ist. Dieser Wert gibt an, wie oft TBMI2 tatsächlich Aufrufe abgesetzt hat. Ist der Wert gleich Null, dann benutzt Ihr Anwendungsprogramm TBMI2 nicht; Sie können Ihr Anwendungsprogramm also in Zukunft ohne TBMI2 sicher laufen lassen. HINWEIS: Sie müssen IPX auf V3.02 aktualisieren, bevor Sie TBMI2 verwenden können. TBMI2.COM Dieses Programm stellt die Datenpuffer zur Verfügung, die benötigt werden, um die Aufrufe eines in einer DR DOS-Sitzung laufenden Anwendungsprogrammes an IPX und SPX zu virtualisieren. Da diese Puffer angelegt werden müssen, bevor TaskMAX startet, muß TBMI2 vor TaskMAX aufgerufen werden. Es gibt folgende Kommandozeilenparameter: /? oder /H Anzeigen von Hilfe- oder Benutzungsinformation. /C= Laden von TBMI2 unter Verwendung dieser Konfigurationsdatei. Geben Sie z.B. "TBMI2 /C=TBMI2.CFG" auf der Kommandozeile ein. /D Anzeigen von Diagnoseinformationen und aktuellen Belegungsgrenzen. /I Anzeigen von Versionsinformationen. /U Entfernen von TBMI2 aus dem Speicher nach Beendigung von Windows. Dieses Programm liest Konfigurations-Informationen aus einer Konfigurationsdatei im aktuellen Verzeichnis. In jeder Zeile der Konfigurationsdatei steht genau ein Parameter. Der Name der Datei ist standardmäßig NET.CFG; ein anderer Name kann mit dem Parameter /C in der Kommandozeile angegeben werden. Es gibt folgende Parameter in der Konfigurationsdatei: INT 64 Ist ähnlich zum Parameter der IPX-Konfiguration. Gibt an, daß TBMI2 Interrupt-64h-Aufrufe an IPX und SPX unterstützen soll. Sollte entweder auf ON oder OFF gesetzt werden. Geben Sie z.B. die Zeile "INT 64 = ON" in die Konfigurationsdatei ein. Der Standardwert ist ON für maximale Kompatibilität. INT 7A Ist ähnlich zum Parameter der IPX-Konfiguration. Gibt an, daß TBMI2 Interrupt-7Ah-Aufrufe an IPX und SPX unterstützen soll. Sollte entweder auf ON oder OFF gesetzt werden. Geben Sie z.B. die Zeile "INT 7A = ON" in die Konfigurationsdatei ein. Der Standardwert ist ON für maximale Kompatibilität. ECB COUNT Gibt an, wie viele nondata event control blocks (ECBs) für die Benutzung durch DR DOS- Programme, die Virtualisierung benötigen, belegt werden. Diese ECBs gelten für die meisten AES-Ereignisse. Wenn TBMI2 keine weiteren nondata ECBs verfügbar hat, können data ECBs belegt und verwendet werden. Wenn keine ECBs aus der Menge der in TBMI2 angelegten ECBs belegt werden können, tritt eine Fehlerbedingung ein, die einen Endekode von FEh (oder -2) zurückliefert. Der kleinste mögliche Wert für diesen Parameter ist 10, der größte ist 255 und der Standardwert ist 20. Geben Sie z.B. die Zeile "ECB COUNT = 20" in die Konfigurationsdatei ein. Jeder angelegte ECB belegt 52 Bytes Speicher; die 20 Standard-ECBs benötigen also 1040 Bytes. Die maximale Anzahl hängt auch vom verfügbaren Speicher ab. Die Gesamtgröße aller ECBs muß kleiner als 64 KB sein, wodurch die Anzahl der ECBs normalerweise auf unter 255 beschränkt wird. Verwenden Sie den Kommandozeilenparameter /D, um sich die aktuellen Werte anzusehen. DATA ECB COUNT Gibt an, wie viele data ECBs für die Benutzung durch DR DOS-Programme, die Virtualisierung benötigen, belegt werden. Diese ECBs gelten für die meisten IPX- und SPX-Sende-und-Empfangs-Pakete. Wenn ein nondata ECB angefordert wird, und keiner zur Verfügung steht, wird ein data ECB verwendet. Wenn keine ECBs aus der Menge der in TBMI2 angelegten ECBs belegt werden können, tritt eine Fehlerbedingung ein, die einen Endekode von FEh (oder -2) zurückliefert. Der kleinste mögliche Wert für diesen Parameter ist 10 und der Standardwert ist 60. Das theoretische Maximum ist 255, aber die praktische Grenze liegt bei 89. Geben Sie z.B. die Zeile "DATA ECB COUNT = 60" in die Konfigurationsdatei ein. Jeder angelegte data ECB belegt 628 Bytes Speicher; die 60 Standard-ECBs benötigen also 37680 Bytes. Die maximale Anzahl hängt auch vom verfügbaren Speicher ab. Die Gesamtgröße aller ECBs muß kleiner als 64 KB sein, wodurch die Anzahl der ECBs normalerweise auf unter 255 beschränkt wird. Verwenden Sie den Kommandozeilenparameter /D, um sich die aktuellen Werte anzusehen. Verwendung von TBMI2 Sie starten TBMI2 folgendermaßen: 1. Starten Sie TBMI2 durch Eingabe von "TBMI2" auf der Kommandozeile, gefolgt von den oben erwähnten optionalen Kommandozeilenparametern. 2. Starten Sie das Programm TaskMAX wie gewohnt. Fehlerbehebung in TBMI2 Wenn Sie Probleme feststellen, während Sie TBMI2 verwenden, müssen Sie evtl. die TBMI2-Konfiguration auf Fehler prüfen. Verwenden Sie den Kommandozeilenparameter /D, um sich Diagnose-Informationen und aktuelle Belegungsgrenzen anzusehen. Prüfen Sie die mit "Max Buffers Used" verbundenen Werte, die angeben, wieviele Puffer benutzt werden, und "Configured Data ECBs", die angeben, wieviele verfügbar sind. Wenn die Anzahl der benutzten Puffer nahe der Anzahl der verfügbaren Puffer oder gleich dieser ist, sollten Sie die Anzahl der verfügbaren Puffer mit den Parametern ECB COUNT und DATA ECB COUNT in der Konfigurationsdatei erhöhen. Wenn der "Unavail buffer count" einmal größer als Null ist, sollten Sie ebenfalls die Anzahl der verfügbaren Puffer mit den Parametern ECB COUNT und DATA ECB COUNT in der Konfigurationsdatei erhöhen. Die Dienstprogramme COMCHECK und RCONSOLE verwenden zuviele Puffer und können nicht mit TBMI2 verwendet werden. ################################################################### -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org "Programs are poems for computers."