• Please review our updated Terms and Rules here

Internet access on a 286, WFW 3.1, 10M Ethernet

kishy

Veteran Member
Joined
Aug 22, 2009
Messages
1,065
Location
Windsor, ON Canada
I KNOW these types of topics exist but the search is obviously broken or something, I either get a whole bunch of nonrelevant posts or nothing at all, so here goes...

I have a 286, as many know, and I've placed a D-Link DE220 16-bit ISA Ethernet card in it. I want to get this machine up and "talking" on my network hopefully with the ability to share files with my Windows XP computers, and definitely with the ability to access the internet, either by TUI or GUI browser, I'm not picky in that regard. The machine does have the original implementation of VGA as it is a PS/2 30 286. It would be nice to have it lease an address via DHCP from my router but static is fine too (probably a bit less overhead at startup this way).

I've installed Windows for Workgroups 3.1 (not 3.11; I do not want to try to modify it to work on a 286). I've found a DOS driver (and WFW 3.1 driver - are these one in the same though?) for this card and it appears to initialize correctly on bootup.

Apparently this is a "packet driver", so I still need a TCP/IP stack. The commonly available Microsoft one needs 3.11 and is 32 bit, apparently (according to itself).

The D-Link drivers claimed to include their own, but when I added it with a device= line in config.sys, I found it just loaded a second instance of the driver...

Can anyone point me in the right direction here? I'd like a TCP/IP stack that will fully integrate into the operating system so that when an application wants out, out it will go.

Thanks!
 
Last edited:
Get Arachne, and get mTCP (mbbrutman wrote it, google it, third or fourth result). Arachne handles web browsing full-graphics 8086 and up, quite modern for a DOS/w3x browser. mTCP includes a nice IRC client, FTP client, and some other tools. Between Arachne and the FTP client of mTCP you should be all set. With WFW3.1 you can natively share files over SMB too, but make the WFW computer the server or create a special account with no password or the WFW3.1 box won't be able to log into the other boxes due to password scheme evolution.
 
yep i agree with all the above. there's also the LeetIRC client i wrote a few years ago for DOS. it can be a little slow on an 8088, but it will run quite happily on a 286. mbbrutman's client works nicely too, but it was designed for speed rather than unnecessary features. mine was designed for unnecessary features. :p

color code support, DCC receive, logging, and stuff like that.

http://www.rubbermallet.org/software/leetirc.html
 
Alright, thanks guys, this helps confirm I'm not totally way off track.

I've looked at mTCP before but I can't see how to integrate it into the OS...looks like just a collection of utilities rather than a "driver" the OS installs...and I have read or at least skimmed all the docs I found with it. Would a more thorough reading show me how or is it expected that someone using it will already know how to integrate it?
 
Does LeetIRC support multiple channels properly? That's the only deficit I have with IRCjr.

Edit: I refreshed and saw your post kishy. The way mTCP is designed is as a statically linked library, i.e., the TCP/IP stack is compiled into each app separately, it doesn't run in the background. Saves memory and runs faster this way I believe. All that you have to do is make the bare-bones mtcp.cfg file, set your environment variables, run dhcp.exe, and you're good to go.
 
raven, if by "properly" you mean separate log buffers for channels, no it doesn't. it's pretty easy to switch between the channels you want to send text to with /query though. the reason is simply that there isn't enough memory in DOS to comfortably be able to do that. it would of course be very possible if the software to use something like a hard drive file to do all this, but that slows stuff down on these old machines and will quickly wear out older drives. it's best to not even deal with it.
 
I primarily use 486 machines, so memory and speed aren't as much of a problem for me. That level of support is good enough though - I spoke with mbbrutman about his IRCjr's support for multiple channels and you have to use lowlevel IRC server commands to send to different channels (query is far better!). Does LeetIRC mark a message as to which channel it originated from? If so I think I've found myself a new IRC client. :)
 
I primarily use 486 machines, so memory and speed aren't as much of a problem for me. That level of support is good enough though - I spoke with mbbrutman about his IRCjr's support for multiple channels and you have to use lowlevel IRC server commands to send to different channels (query is far better!). Does LeetIRC mark a message as to which channel it originated from? If so I think I've found myself a new IRC client. :)

yep! it does. it'll look like:

<#inthischannel:fromthisnick> blah, blah, blah DOS is neat!

one thing to be weary of is that DCC file receive sometimes will crash the app when they start, but usually it works. i never looked too deep into that bug.
 
...Edit: I refreshed and saw your post kishy. The way mTCP is designed is as a statically linked library, i.e., the TCP/IP stack is compiled into each app separately, it doesn't run in the background. Saves memory and runs faster this way I believe. All that you have to do is make the bare-bones mtcp.cfg file, set your environment variables, run dhcp.exe, and you're good to go.

Well, this creates a problem. I want full integration so that applications "just go", with no modification to them.

Unless of course applications of that time frame are EXPECTING to have you provide such a library...

So let's say I track down an antique copy of Netscape. I want to open Netscape, enter an address, and hit enter...and be there. How do I get to this end goal from where I am now?
 
Well, this creates a problem. I want full integration so that applications "just go", with no modification to them.

Unless of course applications of that time frame are EXPECTING to have you provide such a library...

So let's say I track down an antique copy of Netscape. I want to open Netscape, enter an address, and hit enter...and be there. How do I get to this end goal from where I am now?

well, in WINDOWS that's how it will work. just like newer windows versions, the ethernet driver and TCP stack are universal to all windows programs. as long as you have those set up you're ready to go with netscape or anything else. DOS software is different. most DOS network programs will use the same packet driver, but TCP stacks tend to be different for different programs. some have built-in stacks, and some require a TSR to be started for it beforehand.

don't expect too much convenience in the world of DOS networking. ;-9
 
well, in WINDOWS that's how it will work. just like newer windows versions, the ethernet driver and TCP stack are universal to all windows programs. as long as you have those set up you're ready to go with netscape or anything else. DOS software is different. most DOS network programs will use the same packet driver, but TCP stacks tend to be different for different programs. some have built-in stacks, and some require a TSR to be started for it beforehand.

don't expect too much convenience in the world of DOS networking. ;-9

Well that's the thing, I'm trying to figure out how to set up for example mTCP such that it WOULD be universal to all applications, but it looks like mTCP is specifically designed to work a bit differently (being "integrated" with each application that wants out, rather than the OS such that it's "just there")
 
Well that's the thing, I'm trying to figure out how to set up for example mTCP such that it WOULD be universal to all applications, but it looks like mTCP is specifically designed to work a bit differently (being "integrated" with each application that wants out, rather than the OS such that it's "just there")

it's just not possible. and you can't run DOS network apps at ALL in a command prompt box from within windows, because the windows driver will then be using the ethernet card meaning the DOS packet driver can't use it.
 
...then what is mTCP here (in this thread) for? I'm confused now...

I don't care about DOS, I care about Windows, and Windows GUI applications. DOS is a bonus but of next-to-no priority compared to GUI applications running inside of Windows.
 
...then what is mTCP here (in this thread) for? I'm confused now...

I don't care about DOS, I care about Windows, and Windows GUI applications. DOS is a bonus but of next-to-no priority compared to GUI applications running inside of Windows.

mTCP is a set of DOS network utilities/clients, and is also the name of the TCP stack that powers them. you don't have to do anything special if you don't want DOS connectivity then. All you need is a proper windows driver for your network card, and the windows TCP/IP stack. that will work how you want it.
 
Because there are no viable modern apps to use from within Win3.x for networking. The best web browser is Opera 3.62 which processes maybe 10% of the web properly (Arachne will do 100% save flash), and the best IRC is mIRC for Win3x which is really... annoying... but it will work if you feel like hunting down a registration key. If you need an Opera 3.62 key I have one, it was given out as free back when Opera changed to free software.
 
I've no intention of "using" (that is, applying a functional use) the machine on the internet. I just want it connected for a photoshoot, and crappy antique browsers are half the fun.

Windows For Workgroups 3.1 does not have a TCP/IP stack that I can bind to the adapter. It's just not there to be selected for installation.
 
I've no intention of "using" (that is, applying a functional use) the machine on the internet. I just want it connected for a photoshoot, and crappy antique browsers are half the fun.

Windows For Workgroups 3.1 does not have a TCP/IP stack that I can bind to the adapter. It's just not there to be selected for installation.

yep, it does not come with one. you can download it from microsoft though. at least, there's a winsock for wfw3.11 -- not sure if that one will work in 3.1, i've never really used 3.1 .. there's always trumpet winsock if it doesn't?
 
Hi,

This has already been pointed out, but just to make sure it is clear ..

The best way to look at mTCP is as a collection of TCP/IP enabled applications. Each application (FTP, Telnet, Netcat, Ping, etc.) is a stand-alone program designed to run under DOS. The TCP/IP stack is built into the program - it gets loaded with the program, and it is only available while the program is running. It is designed for DOS only.

For Windows you want a TCP/IP stack that adds TCP/IP to windows for all applications to use. This means that each application can reuse the one DLL or loaded piece of code, instead of each application having their own copy of the TCP/IP code. That makes it an extension of the OS, just just part of a single problem.

For DOS the closest you can get to a reusable TCP/IP stack would be a TSR that programs can access via a software interrupt. The TCP/IP code gets loaded once into memory, and then the applications use the copy in memory. The applications know how to call the TCP/IP TSR and they don't include a copy of the TCP/IP code themselves. Trumpet (NTCPDRV) does this, but it is a difficult to make this code bug proof and high performance.

Two examples:

  • My IRC client uses my TCP/IP code, and has it built into the program. After you load the packet driver you load the IRC client, and off you go ..
  • Mike Chamber's IRC client doesn't have TCP/IP built into it, but it expects to find the Trumpet TCP/IP TSR in memory. You load the packet driver and Trumpet, and then run Mike's program.

With Windows 2000, XP and probably later versions you can use a special build of "DOSbox" to run mTCP programs under Windows. It's just emulating a DOS machine, and the mTCP code thinks that it is on a real machine. DOXbox emulates a machine with an NE2000 card, and routes the NE2000 traffic through whatever network adapter you actually have. In this setup the DOSbox gets it's own IP address and simulated MAC address, and it is essentially a separate machine.

Under Windows 95/98/Me you can also run this code - there is a piece of code out there that resembles a packet driver, but instead of sending packets out to a real Ethernet device it uses the existing operating system TCP/IP stack to send and receive the packets. This allows you to run DOS apps that use a packet driver, funneling the traffic through the standard TCP/IP stack on the system. It is not a separate emulated machine like DOSBox, so you get to share the same IP address as the main OS. Fred Macall (of DosLynx fame, http://www.users.ohiohills.com/fmacall/ ) pointed this code out to me.
 
yep, it does not come with one. you can download it from microsoft though. at least, there's a winsock for wfw3.11 -- not sure if that one will work in 3.1, i've never really used 3.1 .. there's always trumpet winsock if it doesn't?

I can't find the one for 3.1, and as stated in OP the one for 3.11 doesn't work. Trumpet's installer won't run, it just spawns an illegal operation dialog box.

You want the file "TCPIP32B.EXE" from MS.

As stated in the OP, this does not work.

Hi,

This has already been pointed out, but just to make sure it is clear ..

The best way to look at mTCP is as a collection of TCP/IP enabled applications. Each application (FTP, Telnet, Netcat, Ping, etc.) is a stand-alone program designed to run under DOS. The TCP/IP stack is built into the program - it gets loaded with the program, and it is only available while the program is running. It is designed for DOS only.

For Windows you want a TCP/IP stack that adds TCP/IP to windows for all applications to use. This means that each application can reuse the one DLL or loaded piece of code, instead of each application having their own copy of the TCP/IP code. That makes it an extension of the OS, just just part of a single problem.

For DOS the closest you can get to a reusable TCP/IP stack would be a TSR that programs can access via a software interrupt. The TCP/IP code gets loaded once into memory, and then the applications use the copy in memory. The applications know how to call the TCP/IP TSR and they don't include a copy of the TCP/IP code themselves. Trumpet (NTCPDRV) does this, but it is a difficult to make this code bug proof and high performance.

Two examples:

  • My IRC client uses my TCP/IP code, and has it built into the program. After you load the packet driver you load the IRC client, and off you go ..
  • Mike Chamber's IRC client doesn't have TCP/IP built into it, but it expects to find the Trumpet TCP/IP TSR in memory. You load the packet driver and Trumpet, and then run Mike's program.

With Windows 2000, XP and probably later versions you can use a special build of "DOSbox" to run mTCP programs under Windows. It's just emulating a DOS machine, and the mTCP code thinks that it is on a real machine. DOXbox emulates a machine with an NE2000 card, and routes the NE2000 traffic through whatever network adapter you actually have. In this setup the DOSbox gets it's own IP address and simulated MAC address, and it is essentially a separate machine.

Under Windows 95/98/Me you can also run this code - there is a piece of code out there that resembles a packet driver, but instead of sending packets out to a real Ethernet device it uses the existing operating system TCP/IP stack to send and receive the packets. This allows you to run DOS apps that use a packet driver, funneling the traffic through the standard TCP/IP stack on the system. It is not a separate emulated machine like DOSBox, so you get to share the same IP address as the main OS. Fred Macall (of DosLynx fame, http://www.users.ohiohills.com/fmacall/ ) pointed this code out to me.

Thank you for the more thorough explanation. It would seem then that mTCP is more desirable to someone building a piece of software or modernizing a particularly vintage one rather than an end user attempting to do what I'm attempting to do?

Aside from Trumpet and the MS one for 3.11, can you think of a TCP/IP stack that I should try that would integrate with WFW 3.1?
 
Back
Top