>It's 02 Aug 97 20:57:54,
>discussion of Adding DOS systems to w'95 peer-peer network...
> tn> However, although it installs properly (ie. it sees the network card)
> tn> and appears to log on, every time I do a 'NET VIEW' it complains it
> tn> cannot see any other machine on the network (even in the same
> tn> workgroup) nor can I see the DOS machine via the network neighbourhood
> tn> on the w'95 machines.
To see the DOS machines in NN they will have to share some device. Now
making the DOS client share is a trick of the trade. I took the the
advice of Bruce Feuchuk, and it worked;
Get the DOS Workgroup Client from ftp.microsoft.com, in directory
/bussys/clients/MSCLIENT. Get both files. They're self-extractors.
Extract all the files, run SETUP. Now your DOS machine is a client on
your Windows P-t-P network.
Go back to ftp.microsoft.com, and get WG1049.EXE, from
It's another self-extractor. Run it in your /NET directory, and let
it overwrite whatever it wants to.
Now you HAVE TO enable the sharing of their Hard drive (and LPT's if
If you take a look in SYSTEM.INI you will see the two lines near the
These two lines are NO as the default... just change them to YES.
Note that IF you make any future changes via SETUP (for the dos
client/server) it WILL change things back to NO (trust me on this
Also in your Autoexec.bat file you have to tell the system what to
what it's name is. An example is:
net share Printer=Lpt1 /full /yes
net share C-Drive=C:\ /full /yes
In other words, you 'assign' C-Drive as the log in name for other
system to map to (ie: map E: as \Sys2\C-Drive)...
And as you can see, you 'NEED' to assign a name for your LPT1 as wall.
In the example above, I've assigned 'printer' for LPT1 and 'c-drive'
for the Hard drive (this is what is needed for mapping and port
capturing - identical as for Windows Networking).
Once you've assigned the above, AND your SYSTEM.INI file has the
correct Dos machine Name and Workgroup, then you 'should' be able to
see the Dos machines!
Here is an example of my System.Ini for the above:
We have 12 machines (RFA1 to RFA12). This machine is used for a Laser
Server (so instead of a User 'name' like BRUCE, I call it PLOTTER).
And we use the default Workgroup name.
Though I had the experience that after setting up the shares ones, the
command 'NET SHARE' was enough after starting up the client.
Quote:>I use MSClient regularly. It's been solid and reliable, if a little
>lacking in some error messages ;) )
And a lotta lacking in docs..
> tn> I set up the DOS client with the IPX protocol. I've also tried 802.2 &
> tn> 802.3 frame types. However, the last I left it, I also noticed that
> tn> the win95 frame type was set to AUTO. Would changing this make any
> tn> difference?
>IPX usually works fine. I found I had to fiddle the frame type (I
>think 808.2 worked for me on a NT based network, where the frame type
>was auto on the nt boxes). I've also successfully used it with NetBEUI
>and TCP/IP (the latter is a memory hog though).
I might add my fiddling trying to make IPX go;
Give it a network address, like '123'.
I also specified 802.2 at first, but now its gone back to 'auto' which
gives no problems.
If your W95 machine is the Browse Master, choose 'enabled' over 'auto'
in the file & printer sharing for MSN.
> tn> Does anyone have any clues!? Am I using the right client software, or
> tn> is there any others out there I can try? I downloaded this one from
> tn> the Microsoft ftp site.
>It does work. However, you may need to manually look at your
>AUTOEXEC.BAT and PROTOCOL.INI files. Sometimes SETUP gets a little
>confused when installing the client, from my experience (it totally
>screwed up TCP/IP and I had to fix it by hand).
> tn> Apologies for the questions. I only half understand what I'm doing,
> tn> being fairly new to networking! I'm on a bit of a learning curve...
> tn> Any help would be appreciated.
>No probs. Try NetBEUI and see if you can contact machines on your
>subnet. Also, check the basics like your network card's I/O address and
>IRQ (though you usually get a message saying "The hardware is not
>responding" in this case). Make sure you're not running another network
>driver which would conflict with MSClient (e.g. packet driver for TCP/IP
>apps). If you need another driver to co-exist, you'll need a shim of
I checked this part of USENET for a month or so now. This and other
topics come up again and again, and I can 't detect the results of any
action ever taken to collect the shared know-how in a document like a
Is this right ?
| X | Amsterdam, Holland
| X | The ultimate medium for the loudmouth & obsessed: USENET