Ein Windows-/Linux-Netzwerk unter DOS nutzen
(Alle Rechte, insbesondere Copyright, liegen bei Gerd Röthig. ©Gerd Röthig 2002, 2004, 2005, 2007. Die in diesem Text verwendeten Marken- und Produktbezeichnungen sind Eigentum der jeweiligen Hersteller.)

Inhalt

  1. Benötigte Software
  2. Die Installation 
  3. Das Netzwerk einrichten
  4. Der Client unter Windows 95 
  5. Treiber ohne Setup manuell einrichten
  6. Internet-Applikationen
  7. Problembehebung
  8. Nützliche Links zum Thema

Mit der wachsenden Popularität von Netzwerken - jetzt auch im Heimbereich - und sinkenden Preisen für Netzwerkhardware kommt immer öfter der Wunsch auf, auch ältere Rechner in vorhandene Netzwerke einzubinden.

Da für diese Rechner oft kein moderneres Betriebssystem als DOS in Frage kommt, und dieses Betriebssystem für viele Anwendungen auch heute noch ausreicht, möchte man es nur wegen der fehlenden Netzwerkfunktionen nicht ersetzen.

Es gibt auch für DOS Möglichkeiten, Netzwerkfunktionen und sogar das Internet zu nutzen.

Der folgende Text soll beschreiben, wie man ein TCP/IP-Netzwerk unter DOS einrichtet.

Da DOS selbst keine Netzwerkfunktionalität bereitstellt, muß diese mittels externer Software nachgerüstet werden. Microsoft hat zu diesem Zweck das »MS Workgroup Addon« für MS-DOS geschaffen, das auch unter der Bezeichnung »MS- Client« bekannt ist und eine Version des MS-Lanmanagers darstellt.

1. Benötigte Software

  1. Der MS-Netzwerk-Client: DSK3-1.EXE und DSK3-2.EXE.
    Alternative (bei Problemen mit dem Microsoft-Server): DSK3-1.EXE und DSK3-2.EXE
  2. Erweiterungen für den MS-Client: NNET.EXE bzw. WG1049.EXE, alternativer Download: NNET.EXE, WG1049.EXE
  3. Das Programm NETSHARE zur Verwaltung von Freigaben: NETSHAR.EXE
  4. DOSMAX und SHELLMAX von P.Gardner: dosmax21.zip
  5. die TSR Utilities 3.5: tsrcom35.zip
  6. CuteMouse: ctmous19.zip, eine Alternative wäre dieser Maustreiber.
  7. Deutsche Tastaturtreiber mit wenig Speicherbedarf: GERKEYB von Sebastian Schuberth) oder dieser nur 400 Byte großer Tastaturtreiber.
  8. CD-ROM-Treiber: CDROM.ZIP und SHSUCDX als Ersatz für MSCDEX.EXE.
  9. Speichermanager: UMBPCI für PCI-Systeme
  10. Für Internet-Anwendungen unter DOS, die ein Packet Driver Interface brauchen: dispkt9.zip oder dispkt11.zip oder bei SimTel.
Sollte es mit den angegebenen Links Probleme geben (es gehört zu den Hobbies mancher Systemadministratoren, Verzeichnisstrukturen hin und wieder zu ändern), helfen Suchmaschinen wie Google weiter.
Zum Inhaltsverzeichnis

2. Die Installation

2.1. Vorbereitungen

Die beiden Dateien DSK3-1.EXE und DSK3-2.EXE, die den MS-Client enthalten, sind in zwei getrennte Verzeichnisse (Beispiel C:\MSCLIENT\DISK1 und C:\MSCLIENT\DISK2) zu entpacken.

Da der MS-Client, insbesondere mit TCP/IP-Unterstützung, sehr viel Speicher benötigt, sollte man zunächst viel freien Speicher schaffen. Dazu dienen die alternativen Treiber für Tastatur, Maus und CD-ROM-Laufwerk sowie DOSMAX/SHELLMAX und die TSR Utilities. Während die Treiber in CONFIG.SYS und AUTOEXEC.BAT ihren Platz finden, richtet man DOSMAX/SHELLMAX und die TSR-Utilities gemäß beiliegender Dokumentation ein. Die Einrichtung beschränkt sich auf das Entpacken des jeweiligen Archivs in ein separates Verzeichnis und den Aufruf der benötigten Programme. Ich entpackte die TSR Utilities nach C:\UT\TSR und DOSMAX/SHELLMAX nach C:\UT\DOSMAX.

2.2. Speicher optimieren, erster Teil

Zunächst schafft man sich also ein Maximum an freiem DOS-Speicher durch Einsatz speichersparender Treiber oder Weglassen von nicht benötigten Treibern. Treiber für CD-ROM-Laufwerke sind für ihren Speicherhunger bekannt, hinzu kommen dann immer noch mal reichlich 20 kB für MSCDEX.EXE, so daß man sich überlegen sollte, die CD-Treiber nicht zu laden bzw. auf die Alternativen auszuweichen, wenn man das Netzwerk nutzen will.

Die Auswahl der Konfigurationen kann über ein in der CONFIG.SYS einzurichtendes Startmenü vorgenommen werden. Um den Speicher für das Hochladen von Treibern verwenden zu können, benötigt man EMM386.EXE oder einen vergleichbaren Speichermanager wie QEMM von Quarterdeck, 386MAX oder das freie UMBPCI.

Mit dem DOS-Tool MSD.EXE kann man sich den freien Speicher anzeigen lassen (Menüpunkt "Memory"), alles, was schwarz dargestellt wird, kann im allgemeinen genutzt werden. Außerdem erhält man so die Werte für den I= Parameter, mit dem EMM386.EXE in der CONFIG.SYS aufgerufen wird.

MSD, Menüpunkt Memory

Allerdings muß man hierfür etwas rechnen. Ein Kästchen in der Anzeige von MSD entspricht 1024 Bytes; eine Reihe sind demnach 16384 Bytes oder 16 kB. Allerdings hat man bei den Adreßangaben eine Zehnerstelle weggelassen; pro Kästchen muß man also zu der links stehenden Zahl 40hex hinzuzählen. Ein Hexadezimalrechner ist an dieser Stelle recht hilfreich.

Im oben gezeigten Beispiel erhalte ich also einen freien Bereich von CD00-EFFF und von B000 bis B7FF. Ab dieser Adresse wird Speicher von der Grafikkarte eingeblendet, ein Ausdehnen des von EMM386 zu nutzenden Speichers auf Adressen im Bereich von B800-BFFF wird meist zum Absturz des Rechners, zumindest aber zu Darstellungsfehlern auf dem Bildschirm, führen.

Meine Zeile für die CONFIG.SYS lautet also

DEVICE=C:\DOS\EMM386.EXE NOEMS NOVCPI I=B000-B7FF I=CD00-EFFF

Wichtig ist die Großschreibung, da EMM386 sonst oft nicht richtig funktioniert. Ebenfalls sollte die Option NOEMS angegeben werden, da sonst 64 kB für den sog. "EMS-Seitenrahmen" (Page Frame) verloren gehen. Die allermeisten Programme funktionieren mit XMS, so daß EMS abgeschaltet bleiben kann.
Wer keine Unterstützung für VCPI (Virtual Control Program Interface; Erweiterung der EMS 4.0-Spezifikation; erlaubt die Koexistenz von Expanded Memory Specification (EMS)-Emulatoren und DOS-Extendern wie 286|DOS Extender) benötigt, kann sie mit dem Parameter NOVCPI abschalten und noch ein wenig Speicher sparen.

Die oft als Geheimtipp gehandelte Option

HIGHSCAN
kann insbesondere auf moderneren Rechnern mehr Probleme verursachen, als sie löst. Den oft nicht gegebenen Zuwachs an freiem Speicher erkauft man sich mit einer verlängerten Ladezeit des EMM386 sowie mit einer oftmals erhöhten Absturzhäufigkeit, wenn nämlich eigentlich vom BIOS belegte Speicherbereiche als "frei" gemeldet werden. Bei korrekter Verwendung des I= Parameters kann man auf HIGHSCAN gut verzichten.

Als weitere Maßnahme räume ich etwas konventionellen Speicher frei, indem mit DOSMAX/SHELLMAX Teile des Systems in den "hohen Speicher" verlagert werden:

DEVICE=C:\UT\DOSMAX\DOSMAX.EXE /c+ /p-
shell=c:\ut\dosmax\shellmax.com c:\command.com /p

DEVICEHIGH /L:1 =C:\WINDOWS\IFSHLP.SYS

Dieser Treiber wird bei Windows für Workgroups mitgeliefert und für den MS-Client zwingend benötigt. Er ist auch beim MS-Client enthalten.

DEVICEHIGH /L:1 =C:\DOS\KEYBGR.SYS

Der bereits erwähnte deutsche Tastaturtreiber, der statt der über 6 kB der KEYB.COM von MS-DOS nur knapp 400 Bytes benötigt. Zu finden ist er beispielsweise hier.

Man beachte die Option /L:1 nach DEVICEHIGH, die DOS veranlaßt, diese Treiber in den ersten freien Bereich des "hohen Speichers" zu laden (im Beispiel der Bereich zwischen B000-B7FF). Auf diese Weise kann ich mir den Bereich zwischen CD00-EFFF für die großen Brocken frei halten.

Die CONFIG.SYS in der Zusammenfassung:

SWITCHES=/F
DEVICE=C:\WINDOWS\HIMEM.SYS /TESTMEM:OFF
DEVICE=C:\DOS\EMM386.EXE NOEMS NOVCPI I=B700-B7FF I=CD00-EFFF
DEVICE=C:\UT\DOSMAX\DOSMAX.EXE /c+ /p-
shell=c:\ut\dosmax\shellmax.com c:\command.com /p
DEVICEHIGH /L:1 =C:\WINDOWS\IFSHLP.SYS
DEVICEHIGH /L:1 =C:\DOS\KEYBGR.SYS

Zum Inhaltsverzeichnis

2.3. Der MS-Client

Als nächstes wird nun der MS-Client installiert. Dazu sollte man sich vorher vergewissern, daß man die DOS- oder Windows-3.11-Treiber für seine Netzwerkkarte parat hat, und sich das Verzeichnis aufschreiben, in dem sie auf der Treiberdiskette abgespeichert wurden. In diesem Verzeichnis sollte eine Datei mit Endung .DOS (der eigentliche Treiber) und eine Datei OEMSETUP.INF (Installationsinformation) existieren.
Für Windows 3.1 gedachte Dateien funktionieren hier ohne Probleme.
Dieses Verzeichnis muß später VON HAND eingegeben werden! Überdies ist die Bedienung des Setup-Tools sehr gewöhnungsbedürftig, so daß ich es nur dazu benutzte, um die Dateien zu installieren und anzulegen. Zunächst fragt das Setup nach dem Netzwerktreiber. Nur dann, wenn man keine der aufgelisteten Netzwerkkarten installiert hat (in diesem Fenster sollte man auch einmal scrollen, um sich davon zu überzeugen), wählt man "Other (not listed)" an und muß nun das entspechende Verzeichnis auf der Treiberdiskette manuell vorgeben, die jetzt im Laufwerk liegen muß.
Viele Karten ohne eigene Treiber laufen auch mit "Novell/Anthem NE2000 compatible". Wer diesen Treiber benutzt, sollte sich nicht wundern, daß nur wenige Einstellungen für den IRQ und die I/O-Adresse vorgegeben sind. Falls die eigenen Werte nicht anwählbar sind, hilft Angeben der Voreinstellungen (z.B. IRQ 5, I/O-Adresse 300) und Eintragen der richtigen Werte nach der Installation in die protocol.ini:

[MS$NE2000]
IOBASE=0x320
INTERRUPT=11

Anschließend fragt das Setup nach der "OEM Driver Disk".
Das ist nun nicht etwa noch mal die zur Netzwerkkarte mitgelieferte Diskette, sondern die zweite des MS-Clients, die man zuvor beispielsweise nach C:\MSCLIENT\DISK2 entpackt hat. Dieses Verzeichnis muß hier angegeben werden.

Nachdem alle Dateien kopiert wurden, folgt der Einstellungsdialog, der in zwei Fenster aufgeteilt ist, zwischen denen man mit <TAB> wechselt. Im oberen Fenster wählt man mit den Cursortasten aus, was bearbeitet werden soll, im unteren, was gemacht werden soll ("Change Configuration").

Mit Enter wird dann der jeweilige Konfigurationsdialog gestartet. Man braucht ihn, um TCP/IP als Protokoll hinzuzufügen, einzurichten und dem Rechner einen Namen und die Arbeitsgruppe zu geben. Als Redirector wählt man "basic" aus, das spart Speicher. Der Full Redirector ist nur notwendig, wenn man sich an einer Windows-NT-Domäne anmelden will.
Diese Einstellung kann auch nachträglich in der PROTOCOL.INI vorgenommen werden, in dem die dort vorhandene Einstellung

preferredredir=
entweder auf Full oder Basic gesetzt wird.

An dieser Stelle nochmals der Hinweis: Wer nicht unbedingt auf TCP/IP angewiesen ist, sollte bei zu knappem konventionellen Speicher (entsprechende Fehlermeldungen von DOS-Anwendungen) auf ein anderes Protokoll, z.B. IPX/SPX oder NETBEUI, ausweichen. Die Unterstützung für diese Protokolle benötigt deutlich weniger Speicher als die für TCP/IP. Außerdem sollte man sich in jedem Fall auf ein Netzwerkprotokoll beschränken.

Ich habe an dieser Stelle lediglich TCP/IP hinzugefügt und den Namen vergeben; es ist leichter, die PROTOCOL.INI im Verzeichnis des MS-Clients anzupassen, als sich durch das Setup zu hangeln. In diesem Fall muß man jedoch vermeiden, daß nach Beenden des Setup (Anwählen von "The Options are correct") und dem folgenden Rechnerneustart die AUTOEXEC.BAT abgearbeitet wird, es sei denn, im Netz befindet sich ein DHCP-Server. Ist ein solcher vorhanden, braucht man nichts weiter zu konfigurieren. Wenn nicht, nimmt man sich die PROTOCOL.INI im Verzeichnis des MS-Clients vor, der Abschnitt [TCPIP] muss etwa folgendermaßen aussehen:

[TCPIP]
NBSessions=6
DefaultGateway0=192 168 0 1
SubNetMask0=255 255 255 0
IPAddress0=192 168 0 2
DisableDHCP=1
DriverName=TCPIP$
BINDINGS=MS$NE2000
LANABASE=0

Man beachte, daß die Adressen nicht durch Punkte, sondern durch Leerzeichen getrennt werden. An dieser Stelle läßt sich die IP-Adresse auch ohne größeren Aufwand schnell ändern.

Konnte der TCP/IP-Stack erfolgreich geladen werden, stehen jetzt die üblichen Netzwerkfunktionen zur Verfügung, die man sich am besten mit

NET HELP | MORE ansieht. Eine detailliertere Hilfe lässt sich zu den einzelnen Befehlen abfragen, so zeigt NET HELP USE Informationen zum Zugriff auf Netzwerkfreigaben an.

Mit NET VIEW sollten sich beispielsweise die Freigaben der anderen Rechner im Netz anzeigen lassen.

Zum Inhaltsverzeichnis

2.4. Speicher optimieren, zweiter Teil

Wenn man mit geladenem TCP/IP den freien Speicher mit

MEM/C/P

anzeigen läßt, bekommt man meist erst mal einen Schreck.

Weniger als 500 kB frei!

Was für Programme laufen denn da noch?

Nicht mehr viele.

Glücklicherweise kann man das Ganze noch etwas optimieren, indem man viele der Treiber hochlädt.


Um den MS-Client nur bei Bedarf laden und auch wieder entladen zu können, lagerte ich die vom Installationsprogramm erstellten Einträge in eine separate Datei namens NETSTART.BAT aus:

@echo off REM *** Informationen fuer Entladen des Clients speichern ***
C:\UT\TSR\MARKNET.EXE /Q C:\UT\TSR\SYSTEM.MRK
REM *** DOS-TCP/IP-Stack laden ***
LH /L:2 C:\NET\NET INITIALIZE
C:\NET\netbind.com
LH /L:2 C:\NET\tcptsr.exe
LH C:\NET\tinyrfc.exe
LH C:\NET\nmtsr.exe

Man beachte wiederum die Aufteilung auf die beiden Speicherbereiche; einige der Treiber suchen sich selbst ihr Plätzchen und bedürfen keiner Sonderbehandlung. Gleiches trifft auf den Maustreiber CTMOUSE zu, bei dessen Aufruf sogar das "LH" weggelassen werden kann.

Mit Speichermanagern wie 386MAX oder QEMM dürfte dieses Problem leichter in den Griff zu bekommen sein.

Sowohl UMB.COM als auch EMSBFR.EXE kann man im allgemeinen weglassen. Das spart Speicher, den man für TCPTSR.EXE auch dringend braucht. Bisher ergaben sich mit dieser Konfiguration keine Probleme.
Hat man zusammenhängend mehr als genügend Speicher für TCPTSR.EXE, TINYRFC.EXE und NMTSR.EXE, kann man statt der LH-Befehle auch UMB.COM verwenden. Das Programm sorgt in diesem speziellen Fall für das Hochladen aller Treiber. (Danke für diesen Hinweis an H.v.d. Bosch aus Holland, <hvdb@moba.nl>.)
Damit bildet UMB.COM den LH-Befehl für ältere DOS-Versionen, wenn auch unvollständig, nach. Da LH aber durch seine Parameter die größere Flexibilität bietet und bei MS-DOS-Versionen ab 6.0 bereits eingebaut ist (kein zusätzliches TSR-Programm notwendig), empfehle ich die Verwendung des LH-Befehls, wann immer möglich.


Zum Inhaltsverzeichnis

3. Das Netzwerk einrichten

3.1. Freigaben oder DOS als Server

Wenn man auf dem DOS-Rechner Laufwerke, Verzeichnisse oder Drucker freigeben will, benötigt man die schon weiter oben erwähnten Dateien NNET.EXE oder WG1049.EXE. Diese enthalten eine aktualisierte Version von NET.EXE (eigenartigerweise mit älterem Dateidatum als das Original). Man entpackt NNET.EXE in das Verzeichnis, in das der MS-Client installiert wurde und überschreibt damit die Originalversion von NET.EXE und NET.MSG.

Falls es es Probleme mit dem Drucken im Netz gibt, sollte man statt NNET.EXE die WG1049.EXE einsetzen.

Als nächstes ist die SYSTEM.INI zu editieren:

FileSharing=Yes
PrintSharing=Yes

Mit dem Programm NETSHARE aus dem Archiv NETSHAR.EXE, das problemlos ins Verzeichnis des Clients (z.B. C:\NET) entpackt werden kann, lassen sich nun die Freigaben einrichten; <TAB> schaltet hierzu zwischen den einzelnen Eingabefeldern um.

Selbstverständlich lassen sich die Freigaben auch innerhalb von Batchdateien oder auf der Kommandozeile einrichten; hierfür steht der Befehl

net share

zur Verfügung. Mit

net share DOSC=c:\user /FULL

gibt man dann beispielsweise das Verzeichnis C:\user mit Vollzugriff frei, es wird im Netz unter DOSC sichtbar. Wichtig: Vor und nach dem Gleichheitszeichen in diesem Befehl dürfen keine Leerzeichen stehen. Andere Rechner können dann beispielsweise mit

net use g: \\dos-rechner\dosc

auf die Freigaben zugreifen.

Die Freigaben lassen sich mit

net share freigabe /delete /yes

auch wieder aufheben.


Zum Inhaltsverzeichnis

3.2. Netzwerkfunktionen nutzen

Dazu steht folgendes in der AUTOEXEC.BAT oder (wie bei mir) der separaten NETSTART.BAT:

c:\net\net.exe time \\der_kleine /set /yes > nul

Damit wird die Zeit auf dem DOS-Client mit einem anderen Rechner synchronisiert. Um Fehler durch abweichende Systemuhren zu vermeiden, sollte man dauerhaft vernetzte Rechner regelmäßig (beispielsweise einmal täglich) miteinander synchronisieren. Außerdem erfolgt dann die Sommer-/Winterzeitumstellung automatisch :) .

LH c:\DOS\SHARE.EXE > nul

Auf diese Art und Weise wird die für die Freigabe von Laufwerken auf dem DOS-Rechner unerläßliche SHARE.EXE geladen.

c:\net\net.exe share /yes

Damit werden die mit NETSHAR eingestellten Freigaben aktiviert.
Wer dieses Programm nicht benutzt, muß den Befehl entsprechend anpassen.
Einrichtung von Netzwerkdruckern:

c:\net\net use lpt1: \\printserver\hpdeskjet /persistent:no /yes
c:\net\net use lpt2: \\printserver\hplaser /persistent:no /yes

Verbindung von Netzlaufwerken:

c:\net\net use f: \\der_kleine\c /persistent:no /yes
c:\net\net use g: \\der_kleine\d /persistent:no /yes
c:\net\net use h: \\schreiber\c /persistent:no /yes
c:\net\net use i: \\schreiber\d /persistent:no /yes

Wird das Netzwerk nicht mehr benötigt, kann der MS-Client mit einer kleinen Batchdatei komplett wieder entladen werden (vielen Dank für diesen Hinweis an Ralf Buschmann <ralf@backmagic.de>) .

Bei mir heißt diese Datei NETSTOP.BAT:

@echo off
echo Netzwerkverbindung wird getrennt...bitte warten.
c:\net\net stop /yes > nul
REM *** MS-Client aus dem Speicher entfernen ***
C:\UT\TSR\RELNET.EXE /H /R /Q C:\UT\TSR\SYSTEM.MRK

Die beiden Programme MARKNET und RELNET sind Bestandteil der TSR-Utilities (siehe Tools zur Speicheroptimierung).

Damit kann man den MS-Client rückstandsfrei wieder aus dem Speicher entfernen, auch Windows läßt sich hernach problemlos starten. Eine Funktionsgarantie kann nicht gegeben werden; die ASCII-Datei TSR.DOC enthält jedoch viele nützliche Hinweise.

Da Windows (getestet mit 3.11 für Workgroups) nach Beenden den Speicher leider nicht in dem Zustand verläßt, wie es ihn vorgefunden hat, funktioniert das anschließende Aufrufen des MS-Clients nicht immer. Als Abhilfe wird auch Windows über eine Batchdatei gestartet:

C:\UT\TSR\MARKNET.EXE /Q C:\UT\TSR\WIN.MRK
REM Falls man mal Parameter mitgeben möchte...
WIN %1 %2
C:\UT\TSR\RELNET.EXE /H /R /Q C:\UT\TSR\WIN.MRK

Damit ist ein problemloses Umschalten zwischen Windows und DOS, beide mit voller Netzwerkunterstützung, möglich.


ACHTUNG:

Einige Netzwerkkartentreiber setzen die Register der Netzwerkkarten nicht zurück, wenn sie auf diese Weise entladen werden. Das führt bei einem erneuten Versuch, den Client zu laden, zum »Aufhängen« des Rechners beim ersten Aufruf von NET USE.... Abhilfe: Den Rechner mit STRG+ALT+ENTF neu starten, in hartnäckigen Fällen hilft der Resetknopf oder vielleicht ein besserer Netzwerktreiber.

Überhaupt sollte man sich immer um einen aktuellen Treiber für die Netzwerkkarte bemühen. Hilfestellung geben die Downloadseiten der jeweiligen Hersteller oder Suchseiten wie
http://www.drivershq.com/
,http://www.treiber.de/, http://www.driverguide.com/.

Ein weiteres Beispiel für den Einsatz der TSR-Utilities findet sich auf http://www.backmagic.de/support/techtalk/preboot.htm

Zum Inhaltsverzeichnis

4. Der MS-Client unter Windows 95/98

Viele Leute möchten TCP/IP auch unter dem bei Windows 95/98 mitgelieferten DOS nutzen. Für dieses DOS ist die Einrichtung des Clients die gleiche wie unter MS-DOS 6.22 , mit einigen kleineren Besonderheiten.

4.1. Probleme mit der DOS-Version

Diese Probleme bekommt man vor allem mit SHARE.EXE. Diese Datei muß von einer älteren DOS-Version besorgt werden, da sie bei Windows 95/98 nicht mehr enthalten ist. SHARE.EXE von DOS 6.22 läuft aber nicht ohne weiteres unter DOS 7; man muß dem Programm zunächst mit

SETVER SHARE.EXE 6.22

ein DOS 6.22 vorgaukeln.
Dazu muß SETVER in der CONFIG.SYS mit

DEVICEHIGH /L:1 =C:\WINDOWS\SETVER.EXE

geladen werden. In der Windows-Standardeinstellung (DOS=AUTO) wird SETVER übrigens immer mit geladen, man sollte also testen, ob man nicht auch ohne diesen Eintrag auskommt.
Das FreeDOS-Projekt entwickelt derzeit einen Ersatz für die nicht ganz unproblematische SHARE.EXE von MS-DOS. Dieses Programm vermeidet Versionsprobleme und soll auch mit dem Dateisystem FAT32 zurechtkommen.

Die übrige Konfiguration entspricht der weiter oben beschriebenen mit der Ausnahme, daß ab Windows 95 B kein SHELLMAX mehr benötigt wird. Das Betriebssystem lädt COMMAND.COM von sich aus in den »hohen Speicher«, wenn in der Datei C:\MSDOS.SYS die Zeile

LocalLoadHigh=1

steht.
Außerdem stehen ab Windows 95B die Befehle

  buffershigh
  fcbshigh
  fileshigh
  lastdrivehigh
  stackshigh
zur Verfügung, die durch Hochladen der einzelnen Variablen in den UMA-Speicherbereich auch einige Bytes an konventionellem Speicher einsparen können.
Statt z.B.
stacks=9,256
schreibt man in der CONFIG.SYS jetzt
stackshigh=9,256

Wer SHARE.EXE von FreeDOS unter dem DOS von Windows 95/98 verwendet, könnte durch den Eintrag
 DOS=NOAUTO
in der CONFIG.SYS noch etwas Speicher einsparen, denn SETVER.EXE wird in diesem Fall nicht benötigt. Allerdings müssen dann die beiden Einträge
DEVICE=C:\WINDOWS\HIMEM.SYS
DEVICEHIGH=C:\WINDOWS\IFSHLP.SYS

wieder vorhanden sein.

Zum Inhaltsverzeichnis

4.2. Die grafische Windows-Oberfläche

Auf einen Start der grafischen Oberfläche von Windows 95/98 sollte nach dem Laden des MS-Clients verzichtet werden, da der Client sich nicht mit der Windows-eigenen Netzwerkunterstützung verträgt. Auch die für den Client notwendigen Maßnahmen zur Speicheroptimierung sind für Windows 95/98 nicht notwendig oder sogar gefährlich. Empfehlenswert ist deshalb also immer ein Neustart des Rechners vor dem Laden der Windows-Oberfläche.

Als Alternative zu dem zeitraubenden Neustart bietet sich die weiter oben beschriebene Verwendung der Tools MARKNET und RELNET an, die auf den meisten Systemen in der Lage sein sollten, den Client vollständig zu entladen.

Zum Inhaltsverzeichnis

4.3. Auswahl verschiedener Konfigurationsmöglichkeiten

Wer beim Start des Rechners die Auswahl zwischen verschiedenen Konfigurationen haben möchte (mit/ohne Netzwerk) hat unter Windows 95/98 verschiedene Möglichkeiten der Realisierung:

4.3.1. Starten von MS-DOS 6.x

Dazu schreibt man in die C:\MSDOS.SYS nach Aufhebung ihres Schreibschutzes unter

[Options]
BootMenu=1
BootMulti=1

und kopiert vom alten DOS die Dateien IO.SYS, MSDOS.SYS und COMMAND.COM nach C:\, wichtig ist aber, vorher die Endungen der Dateien auf .DOS zu ändern.

Beispiel:

copy A:\COMMAND.COM C:\COMMAND.DOS

Jetzt kann man in einem Startmenü »Vorherige MS-DOS-Version« wählen und nach dem Starten von DOS auch eine CONFIG.SYS und AUTOEXEC.BAT erstellen, die Windows-Dateien werden dabei nicht überschrieben.

Vorsicht Bug! Manche Windows95-Versionen benötigen hierfür einen Patch, sonst läßt sich der Rechner nach einem DOS-Start nicht mehr neu booten.

Zu finden beispielsweise bei http://win95.winware.org .
Den Bug kann man umgehen, indem man die DOS-Dateien weiter umbenennt:

copy A:\IO.SYS C:\IBMBIO.COM
copy A:\MSDOS.SYS C:\IBMDOS.COM

Die akzeptiert Windows 95 problemlos als »alte DOS-Version«.

Zum Inhaltsverzeichnis

4.3.2. Programm für den MS-DOS-Modus konfigurieren

Alternativ kann man auch unter Windows 95 eine Verknüpfung zu einem DOS-Programm anlegen, es für den DOS-Modus konfigurieren (»Eigenschaften« des Programms; rechte Maustaste, dort Registerkarte Erweitert) und ihm seine eigene CONFIG.SYS und AUTOEXEC.BAT geben.

Beim Start über eine solche Verknüpfung fährt Windows herunter, startet mit der neuen CONFIG.SYS und AUTOEXEC.BAT, lädt das DOS-Programm und startet sich nach dessen Ende wieder neu.

Zum Inhaltsverzeichnis

4.3.3. DOS-Startmenü

Wie unter MS-DOS 6.22 läßt sich auch unter Windows 95/98 ein Startmenü in der CONFIG.SYS anlegen, um den Rechner mit verschiedenen Konfigurationen zu starten.

Dazu editiert man die Datei C:\MSDOS.SYS, deren Schreibschutz man vorher aufgehoben hat, und fügt unter [Options] folgendes ein:

BootGui=0

In der CONFIG.SYS steht dann beispielsweise:

[Menu]
Menuitem=Normal, Normal
Menuitem=Netz, Netz
Menudefault=Normal, 10
[Normal]
[Netz] DEVICE=C:\WINDOWS\HIMEM.SYS /testmem:off
DEVICE=C:\DOS\EMM386.EXE NOEMS NOVCPI I=B000-B7FF I=C800-F7FF
DEVICE=C:\UT\DOSMAX\DOSMAX.EXE /c+ /p-
DEVICE=C:\WINDOWS\SMARTDRV.EXE /DOUBLE_BUFFER
DEVICEHIGH /L:1 =C:\WINDOWS\IFSHLP.SYS
DEVICEHIGH /L:1 =C:\DOS\KEYBGR.SYS
shell=c:\ut\dosmax\shellmax.com c:\command.com /p
SET PATH=C:\WINDOWS;c:\;c:\windows\system;C:\NET;C:\DOS;C:\UT;C:\XL;c:\ultraedt;c:\inet\netscape\program
[Common]
buffers=30,0
FILES=40
stacks=9,256
DOS=HIGH,UMB
LASTDRIVE=Z
FCBS=4,0

In der AUTOEXEC.BAT steht zum Beispiel:

@ECHO OFF
goto %CONFIG%
:Netz REM *** DOS-TCP/IP-Stack laden ***
LH /L:2 C:\NET\NET INITIALIZE
C:\NET\netbind.com
LH /L:1 C:\NET\umb.com
LH /L:2 C:\NET\tcptsr.exe
LH C:\NET\tinyrfc.exe
LH C:\NET\nmtsr.exe
C:\NET\net start c:\mouse\ctmouse /r55
goto end :Normal win :end

Eine ähnliche Konfiguration mit dem MS-Client unter DOS 6.22 läuft hier nun schon seit vielen Monaten ohne Störungen.

Als wesentliche Nachteile sind neben den Speicherproblemen unter DOS vor allem vergleichsweise geringe Performance bei Dateitransfers und dem Drucken ins Netzwerk zu nennen.

Zum Inhaltsverzeichnis

5. Treiber ohne Setup manuell einrichten

Auf einigen Rechnern und mit moderneren Netzwerkkarten weigert sich das Setup des MS-Clients, die passenden Treiber zu installieren, selbst wenn eine entsprechende *.INF-Datei in dem Verzeichnis des DOS-Treibers (*.DOS) existiert. Neben der im nächsten Abschnitt erwähnten Möglichkeit der Erstellung einer eigenen passenden *.INF- Datei gibt es noch eine wesentlich einfachere Variante, die ich erst vor kurzem ausprobieren mußte, da Setup die OEMSETUP.INF auf meiner Treiberdiskette nicht erkennen wollte:

Man läßt das Setup einen der mitgelieferten Treiber (beispielsweise 3Com Etherlink) installieren. Der Treiber hat den Namen ELNK.DOS. Jetzt kopiert man sich den Treiber zu seiner Netzwerkkarte ebenfalls in das Verzeichnis des MS-Clients. Bei mir hieß die betreffende Datei EL90X.DOS .

Um den Treiber nun zu »installieren«, reichte es, alle Vorkommen von "ELNK" in den Dateien SYSTEM.INI und PROTOCOL.INI in meinem Fall durch "EL90X" zu ersetzen.

Abschließend schaut man, ob in der PROTOCOL.INI ein Abschnitt [MS$EL90X] existiert (für mein Beispiel mit EL90X.DOS, nach dem $-Zeichen steht der Dateiname des *.DOS-Treibers ohne die Endung *.DOS). Benötigt der neue Netzwerktreiber Einstellungen, wie Interrupt oder IO- Adresse, kann man diese hier ändern. Manche Treiber wollen hier keine Schlüsselworte haben (entsprechende Fehlermeldung beim Laden), hier muß man den gesamten Abschnitt entfernen. Bei anderen wird eine Beispiel- PROTOCOL.INI mit den gültigen Einstellungen mitgeliefert (einfach mal auf der Diskette danach suchen). Die betreffenden Schlüsselworte wären dann also an dieser Stelle in die PROTOCOL.INI des MS-Clients zu übernehmen.

Zum Inhaltsverzeichnis

6. Eine Beispiel-OEMSETUP.INF

Auf vielen moderneren Netzwerktreiber-Disketten findet man zwar noch den DOS-Netzwerkkartentreiber (eine Datei mit Endung .DOS), allerdings fehlt dann die passende OEMSETUP.INF, damit dieser Treiber vom Setup des MS-Clients gefunden werden kann.

Da sich die betreffenden Dateien sehr ähneln, kann man eine OEMSETUP.INF einer anderen Netzwerkkarte entsprechend anpassen, zum Beispiel diese hier:

;; DOS-Netzwerkclient
;; OEMSETUP.INF für SURECOM EP-312V Ethernet Adapter [disks]
; Das ist die Bezeichnung der Diskette, frei wählbar
1=.,"SURECOM EP-312V Ethernet Adapter WFW Driver Disk", disk1
[netcard]
; key = description, MSID, type, media, mode, install, protini, style
EP312="SURECOM EP-312V Ethernet Adapter",0,ndis,ethernet,0x07,EP312,EP312_nif
[EP312]
;Auf diesen Dateinamen kommt es an, ggfs. entsprechend ersetzen!
ndis2=1:EP312.dos [EP312_nif]
;Die im Setup anwählbaren Einstellungen für die Karte
;Der Treiber-Name entspricht dem Dateinamen ohne Endung,
;dafür wird ein $-Zeichen angehängt - ggfs. ändern!
DriverName=EP312$
io=IOBASE,,text,"0x240,0x280,0x2C0,0x300,0x320,0x340,0x360",0x300
irq=INTERRUPT,,text,"3,4,5,9,10,11,12,15",5
param=PNPID,"PNPID (0=First PNP adapter found)",chars,14,0
param=EARLYRECEIVE,"Early Receive (0=Disable,1=Enable)",text,"0,1","0"
param=EARLYTRANSMIT,"Early Transmit (0=Disable,1=Enable)",text,"0,1","0"
param=FULLDUPLEX,"Full Duplex (0=Disable,1=Enable)",text,"0,1","0"

Zum Inhaltsverzeichnis

7. DOS- und Linux-Rechner miteinander verbinden

Mit der entsprechenden Software ist der Zugriff von einem DOS-Rechner auf Dateien eines Linux-Rechners und umgekehrt recht leicht zu bewerkstelligen.

Von Linux nach DOS

Achtung:

Diese Lösung konnte ich leider nicht zum Funktionieren bringen. Die Ursache dürfte in der unvollständigen Unterstützung des SMB-Protokolls durch den MS-Client liegen.

Wer Abhilfe weiß, bitte unbedingt melden!

Throretisch wird das Programm smbmount und eine Unterstützung für SMB im Linux-Kernel benötigt. Falls man eine aktuelle Distribution einsetzt, findet sich womöglich ein Treiber; mit

insmod smbfs

kann man testen, ob dem so ist. Wenn nicht, müßte man sich einen neuen Kernel übersetzen, der diese Option bietet.

War das Laden des smbfs-Moduls erfolgreich, sollte ein

smbmount //doskiste/freigabe /mnt

funktionieren, es könnte dann auf die Freigabe wie auf ein Verzeichnis des Linux-Rechners zugegriffen werden. Allerdings werden keine langen Dateinamen unterstützt. Leider unterstützt smbmount in der mir vorliegenden Version eine solche Lösung nicht, nach Abhilfe suche ich noch.
Eine Möglichkeit wäre vielleicht der Einsatz des Full Redirectors (siehe hier), leider kann dies aber zu Problemen wegen zuwenig freien Speichers führen.

Von DOS nach Linux

Diese Richtung erfordert ein wenig mehr Aufwand bei der Konfiguration. Zunächst muß das samba-Paket installiert werden; weitere Informationen und Download gibt es auf http://de.samba.org/samba/samba.html.

Nachdem dieses Paket installiert wurde, muß die Konfigurationsdatei /etc/smb.conf angepaßt werden,

man smb.conf

gibt Auskunft über mögliche Einstellungen.

Hier ein kurzes Beispiel:

; /etc/smb.conf
;
; Sample configuration file for the Samba suite for Debian GNU/Linux
;
; Please see the manual page for smb.conf for detailed description of
; every parameter.
; [global]
printing = bsd
printcap name = /etc/printcap
load printers = yes
guest account = nobody
invalid users = root
character set = ISO8859-1
security = share
workgroup = Meine
server string = %h (Samba %v)
socket options = IPTOS_LOWDELAY TCP_NODELAY SO_SNDBUF=4096 SO_RCVBUF=4096
encrypt passwords = yes
wins support = yes
; Damit wird Samba zum Master Browser. Nur auf einem Rechner auf yes setzen!
os level = 65
domain master = yes
local master = yes
preferred master = yes
name resolve order = hosts lmhosts host wins bcast
dns proxy = no
; Name mangling options
preserve case = yes
short preserve case = yes
; This boolean parameter controls whether Samba attempts to sync. the Unix
; password with the SMB password when the encrypted SMB password in the
; /etc/samba/smbpasswd file is changed.
unix password sync = false
; For Unix password sync. to work on a Debian GNU/Linux system, the following
; parameters must be set (thanks to Culus for pointing this out):
passwd program = /usr/bin/passwd %u
passwd chat = *New\spassword:* %n\n *Re-enter\snew\spassword:* %n\n *Password\schanged.* .
max log size = 100
[homes]
comment = Home Directories
browseable = no
; By default, the home directories are exported read only. Change next
; parameter to "no" if you want to be able to write to them.
read only = no
; File creation mask is set to 0700 for security reasons. If you want to
; create files with group=rw permissions, set next parameter to 0775.
create mask = 0775
; Directory creation mask is set to 0700 for security reasons. If you want to
; create dirs. with group=rw permissions, set next parameter to 0775.
directory mask = 0775
[printers]
comment = All Printers
browseable = yes
path = /tmp
printable = yes
public = yes
writable = yes
create mode = 0775
[c]
comment = Windows-Partition
writeable = true
public = yes
path = /dosc
browseable = yes
[linux]
comment = Linux-Freigabe
writeable = true
public = yes
path = /var/freigabe
browseable = yes

Samba wird durch Aufruf der beiden Daemonen

nmbd smbd

als root gestartet, sinnvollerweise bringt man diesen Aufruf in die beim Systemstart ausgeführten Skripte unter (die meisten Distributionen haben das bereits erledigt).

Nach Änderungen an /etc/smb.conf muß das Neueinlesen der Datei veranlaßt werden:

killall -HUP smbd nmbd

Von DOS aus sollten jetzt Befehle wie

net use e: \\linuxrechner\freigabe

funktionieren.

Zum Inhaltsverzeichnis

8. Internet-Applikationen

8.1. Vorbereitung

DOS-basierende Internet-Programme verwenden allesamt ein so genanntes Packet Driver Interface. Der MS-Client bietet von sich aus jedoch nur NETBIOS über TCP/IP an, eignet sich also nur für die Arbeit mit Datei- und Druckerfreigaben im »Microsoft-Netzwerk«.

Glücklicherweise läß sich dem abhelfen, wie in c't, Heft 21/1999, Seite 310 ff, erwähnt wird, dazu braucht man den bereits weiter vorn erwähnten NDIS Packet Driver.

Zusätzlich sind noch einige weitere Einstellungen vorzunehmen. (Vielen Dank für diese Hinweise an Michael Vogl <michael_vogl@web.de>.)
Der in README.TXT vom Workgroup Add-on (MS-Client) beschriebene "Advanced Button" wurde leider nicht implementiert, so daß man die Datei TCPUTILS.INI im Verzeichnis des MS-Clients manuell editieren muß.

TCPUTILS.INI
; alle Vorkommen von TCPIP_XIF ändern in TCPIP
[tcpglobal]
...
hostname=username
;und einen neuen Eintrag hinzufügen
[dnr]
drivername=DNR$
bindings=TCPIP
;ip-Nummer ohne Punkte
nameserver0=0 0 0 0

Der im Verzeichnis des MS-Clients enthaltene Treiber DNR.EXE muß zusätzlich via AUTOEXEC.BAT bzw. NETSTART.BAT geladen werden:

LH C:\NET\DNR.EXE

Zum Inhaltsverzeichnis

8.2. Der NDIS Packet Driver

Aus den entsprechenden Archiven wird jeweils nur DIS_PKT.DOS bzw. DIS_PKT9.DOS benötigt. Diese Datei entpackt man in das Verzeichnis des MS-Clients. Anschließend muß die Datei PROTOCOL.INI in eben diesem Verzeichnis angepaßt werden (genauere Infos bieten die in den Archiven enthaltenen Textdateien mit der Endung .DOC), es wird ein neuer Abschnitt [pktdrv] erstellt:

[pktdrv]               ; Für den Packet Driver erforderlicher Eintrag
drivername = pktdrv$   ; Formaler Treibername (nicht ändern)
bindings = wd8003xmac  ; der netzwerkkartenspezifische NDIS-Treiber
                       ; (sollte bereits bei der Installation des
                       ; MS-Clients eingerichtet worden sein)
intvec = 0x63          ; Softwareinterrupt des Packet Driver
                       ; (60h..7fh)
novell = no            ; Optional: Wenn y(es), dann wird zwischen
                       ; dem älteren Novell 802.3 Paketformat auf der
                       ; Leitung und dem Typ 8137 für die Anwendung
                       ; konvertiert.
                       ; Die Konvertierung ist per Voreinstellung
                       ; bzw. bei Weglassen dieser Zeile ausgeschaltet

Damit der Treiber beim Starten automatisch mitgeladen wird, muß nun noch folgendes in die SYSTEM.INI eingetragen bzw. ergänzt werden:

[network drivers]
netcard=rl2000.dos                         ; Treiber der verwendeten Netzwerkkarte
transport=tcpdrv.dos,nemm.dos,dis_pkt9.dos ; bzw. dis_pkt.dos

Normalerweise sollte der Treiber beim Starten automatisch mitgeladen werden, die Dokumentation empfiehlt allerdings einen Eintrag in die CONFIG.SYS wie:

DEVICE=C:\NET\DIS_PKT9.DOS

was aber wohl eher für ältere Versionen (»LAN-Manager«) des Clients zutreffen dürfte.

Zum Inhaltsverzeichnis

8.3. Internet mit Arachne

Um jetzt den grafischen WWW-Browser Arachne unter DOS nutzen zu können, muß er zunächst in ein separates Verzeichnis entpackt werden.

Anschließend wird nach dem Laden des MS-Clients SETUP.EXE ausgeführt. Das Setup bietet drei Konfigurationsmöglichkeiten an; man entscheidet sich für die mittlere (Netzwerkkarte als Icon).

Nach einem Klick auf "Weiter" sollte das Setup nun melden, daß ein Netzwerktreiber gefunden wurde.

Es wird jetzt die manuelle Konfiguration gewählt. Da Arachne einen eigenen TCP/IP-Stack mitbringt, muß eine neue IP-Adresse gewählt werden, die noch nicht im Netz vergeben ist. Erfolgt der Zugang ins Internet über einen Gateway (z.B. Linux-Router), so müßte das Konfigurationsfenster folgendermaßen ausgefüllt werden:

Subnet-Mask   255.255.255.0
1. Nameserver 192.168.0.1
1. Gateway    192.168.0.1

Alle anderen Eintragungen werden auf 0.0.0.0 gesetzt. Insbesondere der Eintrag für den DNS-Server hängt jedoch von der Art des Routers/Kommunikationsservers ab. Läuft auf diesem beispielsweise NAT32 (www.nat32.com), so wäre der Eintrag auf 192.168.0.100 zu setzen. Genaueres erfährt man wie immer in der Dokumentation zu den einzelnen Programmen.
Interessant wäre in diesem Zusammenhang auch die Frage, ob man für Arachne nicht auch wieder auf das vom MS-Client mitgebrachte TCP/IP verzichten könnte, da es, wie bereits gesagt, eine eigene Implementierung dieses Protokolls ("TCP/IP-Stack") mitbringt. Dies würde nicht nur Konfigurationsprobleme mit mehreren IP-Adressen vermeiden, sondern sicher auch Speicher sparen und Arachne stabiler laufen lassen. Siehe dazu auch den nächsten Abschnitt.

Zum Inhaltsverzeichnis

8.4. Andere Anwendungen

Wenn die Anwendung keinen eigenen TCP/IP-Stack mitbringt, ist für das Packet Driver Interface laut beiliegenden Informationen ein spezieller TCP/IP Stack erforderlich; die Dokumentationen zu ndis_pkt empfehlen PC/TCP. Weitere Informationen zu diesem kommerziellen Produkt finden sich bei NetManage.

Allgemeinere Informationen und Links zum Thema TCP/IP unter DOS lassen sich hier abrufen.

Da man aber auf diese Weise zwei TCP/IP-Stacks im Speicher hat, empfiehlt es sich, für "Internet" eine spezielle Startkonfiguration anzulegen, bei der MS-TCP/IP nicht mit geladen wird. Um Probleme mit diesen beiden unterschiedlichen Konfigurationen zu vermeiden, sollte der MS-Client hierzu komplett in ein neues Verzeichnis kopiert werden. Per Batch-Datei bzw. CONFIG.SYS-Startmenü ließen sich dann entsprechende Auswahlmöglichkeiten einrichten.

Hier noch ein (ungetesteter) Vorschlag mit einigen Beispieldateien für TCP/IP über Packet Interface, als TCP-Stack wird PC/TCP von FTP Software (aufgekauft von NetManage) verwendet:

CONFIG.SYS:
DEVICE=protman.sys          <----- der Protokoll Manager (muss zuerst geladen werden)
DEVICE=your-ndis-driver.dos <----- der NDIS-Netzwerkkartentreiber
DEVICE=dispktpm.dos         <----- der Packet Treiber, der auf NDIS aufsetzt
DEVICE=ipcust.sys           <----- der PC/TCP Protokollstack
DEVICE=ifcust.sys

PROTOCOL.INI (ergänzen):
[PKTDRV]
DRIVERNAME = PKTDRV              <----- erforderlich
BINDINGS = your-ndis-driver-here <----- der NDIS-Treiber
INTVEC = 0X65                    <----- Softwareinterrupt für den Packet Driver

Als freie Alternative könnte prinzipiell WATTCP verwendet werden. Sowohl auf der offiziellen Homepage als auch in der Dokumentation zum Webbrowser Arachne sind einige Informationen zur Einrichtung eines Internetzugangs mit WATTCP zu finden.


Zum Inhaltsverzeichnis

7. Problembehebung

Viele Probleme und Ungereimtheiten lassen sich mit Eigenarten des im »Microsoft Netzwerk« verwendeten SMB-Protokolls erklären. Hierbei ist immer einer der Rechner der so genannte »Browse Master «, der die Liste der im Netzwerk freigegebenen Ressourcen verwaltet. Leider funktioniert die Aktualisierung dieser Liste nicht immer reibungslos. Außerdem müssen sich die Rechner im Netzwerk auch erst mal einigen, welcher von ihnen die Liste überhaupt führen darf; diese "Election" kann bis zu einer halben Stunde dauern.

7.1. DOS-Server taucht nicht in Netzwerkumgebung auf

Hier hat der »Browse Master« es noch nicht geschafft, die Liste der Freigaben entsprechend zu aktualisieren. Wichtig: Es müssen Freigaben auf dem DOS-Rechner eingerichtet sein, denn sonst wird er nicht angezeigt.
Im allgemeinen hilft es schon, mit einem Rechtsklick auf »Netzwerkumgebung« unter »Computer suchen...« nach dem DOS-Rechner zu suchen.
Alternativ funktioniert auch die Kommandozeile (MS-DOS-Eingabeaufforderung), man tippt

net use l: \\doskiste\freigabe

ein, sollte dieser Versuch fehlschlagen, so ist die dann erzeugte Fehlermeldung meist aussagekräftiger als »Das Netzwerk kann nicht durchsucht werden.«.

7.2. Fehlermeldung "The list of servers for this workgroup is not available"

Auch hier gibt es ein Problem mit der Browse List, leider bleibt einem hier nichts anderes übrig, als abzuwarten oder einen der beteiligten Windows-Rechner neu zu starten. Wenn man Glück hat, erzwingt das eine neue "Election", an deren Ende dann wirklich ein Rechner als Verwalter der Freigabeliste festgelegt wurde.

Zum Inhaltsverzeichnis

7.3. Fehlermeldung "Cannot bind"

Hier liegt im allgemeinen ein Hardware- oder Treiberproblem vor; oft konnte einer der beteiligten Treiber des MS-Clients nicht ordnungsgemäß geladen werden. Zur Fehlersuche sollte man erst einmal alle Treiber in den konventionellen Speicher laden und auf eventuelle Fehlermeldungen achten. Erst wenn das wieder funktioniert, kann man versuchen, die Treiber wieder in den hohen Speicher zu laden.

7.4. Fehlermeldung "An error occurred accessing the security-settings file"

Die Microsoft-Knowledgebase hilft hier weiter:
Aus irgendeinem Grund ist die Datei WFWSYS.CFG im Installationsverzeichnis des MS-Clients beschädigt, nicht vorhanden oder inkompatibel mit der Datei SHARES.PWL im gleichen Verzeichnis.

Abhilfe:
Die Datei WFWSYS.CFG wird leider erst vom Setup erstellt und ist nicht in den Installationsdateien zu finden. Deshalb bleiben neben einer Neu- bzw. Parallelinstallation des Clients über SETUP.EXE nur wenige Möglichkeiten, um an die Datei zu kommen.
Falls das Löschen aller *.PWL-Dateien im Installationsverzeichnis des MS-Clients nicht hilft, muss WFWSYS.CFG ersetzt werden.
Wer eine funktionierende Windows-3.x-Installation hat, findet WFWSYS.CFG eventuell im Windows-Verzeichnis dieser Installation. Die MS-Knowledgebase empfiehlt, die Datei von einer Windows-NT-4.0-Server-Installations-CD zu kopieren. Die dritte Möglichkeit bietet der Download meiner WFWSYS.CFG .
Unter anderem auf http://www.bovistech.com/disks.htm finden sich fertige Bootdisketten-Images, mit denen man ein DOS mit Netzwerkunterstützung durch den MS-Client starten kann. Alle notwendigen Dateien, so auch WFWSYS.CFG, sind selbstverständlich enthalten. Im Abschnitt Nützliche Links dieser Seite findet man weitere Bezugsmöglichkeiten für derartige Diskettenimages.
Nachdem man die Datei ins Installationsverzeichnis des Clients kopiert hat, muss noch die Datei SHARES.PWL, sofern vorhanden, gelöscht werden. Sie wird beim nächsten Neustart neu erstellt.
Wer noch die Installationsdisketten von Windows for Workgroups 3.11 oder die CD besitzt, kann die Datei ADMINCFG.EX_ von Diskette 8 mit EXPAND ins Installationsverzeichnis des Clients entpacken:

expand admincfg.ex_ c:\net\admincfg.exe

Dieses Programm gestattet, neben der Änderung gespeicherter Passwörter auch weitere Einstellungen in WFWSYS.CFG zu ändern. Nach erfolgten Anpassungen wird eine neue WFWSYS.CFG erzeugt.

Zum Inhaltsverzeichnis

7.5. Passwort für die Freigabe "IPC$" wird verlangt, jede Eingabe ist aber falsch

Dieses Problem tritt auf, wenn man Freigaben auf einem Rechner mit NT-basierendem Betriebssystem (Windows NT 3.51, Windows NT 4.0, Windows 2000, Windows XP) nutzen will. Diese Windows-Versionen erfordern zwingend, dass man sich mit Namen und Passwort eines Benutzers anmeldet, der auf dem NT-Rechner auch existiert (lokal eingerichtet) ist.
Allerdings kann der Fehler auch auftreten, wenn der betreffende Benutzer auf der NT-Maschine existiert und auch das Passwort stimmt. Dann sind einige interne Verschlüsselungsinformationen der NT-Maschine veraltet; es hilft hier nur das "Auffrischen" des Passworts (Passwort neu vergeben; selbst neu vergeben des bereits verwendeten Passworts hilft bereits!).

Zum Inhaltsverzeichnis

7.6. Den MS-Client mit Windows XP/Windows Server 2000/2003 verwenden

Ab Windows 2000, XP und den zugehörigen Serverversionen hat Microsoft ein neues, verschlüsseltes Anmeldeverfahren für Netzwerkclients eingeführt. Der MS-Client für DOS unterstützt dieses Verfahren nicht, und es ist auch nicht vorgesehen, daran etwas zu ändern - was nicht weiter überrascht.
Aus diesem Grund muss dieses verschlüsselte Verfahren (SMB Signing) auf dem Server deaktiviert werden, um dem DOS-Rechner die Anmeldung und Nutzung von Server-Freigaben zu ermöglichen.

Dazu gpedit.msc starten (über Start, Ausführen...) und bis zum Knoten

Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen

gehen. Hier die Einstellung

Microsoft-Netzwerk (Server):Kommunikation digital signieren (immer)

auf "deaktiviert" stellen.
Weiterhin muss die Unterstützung für das richtige Authentifizierungsprotokoll aktiviert werden.
Windows Server 2003 bietet als Authentifizierungsprotokolle Kerberos, NTLM, NTLM V2 und LM, das hier für DOS erforderliche Protokoll ist LM (=LanManager). In der Domain Group Policy nun noch sicherstellen, daß LM als Protokoll erlaubt ist.
Dazu an gleicher Stelle in gpedit.msc die Einstellung

Netzwerksicherheit:LAN-Manager-Authentifizierungsebene

auf "LM und NTLM-Antworten senden" stellen.

Weitere Informationen:

http://support.microsoft.com/default.aspx?scid=kb;en-us;555038

Zum Inhaltsverzeichnis

8. Nützliche Links zum Thema

An dieser Stelle entsteht eine kleine Sammlung von Webadressen mit weiterführenden Informationen zum Thema Netzwerke unter DOS. Wer eine Seite gefunden hat, die in diese Liste aufgenommen werden sollte: Bitte Mail an mich (Mailformular)!

Seitenname URL Bemerkungen
BackMagic http://www.backmagic.de/ Universelle Backuplösung, Bootdisketten mit Netzwerkunterstützung
Bovistech Bootdisks http://www.bovistech.com/disks.htm Bootdisks mit dem MS-Client

Zum Inhaltsverzeichnis

In der Hoffnung, daß dieser Text dem einen oder anderen eine Hilfe und nicht nur Kopiervorlage sein möge

Gerd Röthig
Zurück zur Homepage