PDA

View Full Version : Internet access on a 286, WFW 3.1, 10M Ethernet



kishy
April 16th, 2010, 12:04 PM
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!

Raven
April 16th, 2010, 12:24 PM
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.

Mike Chambers
April 16th, 2010, 12:28 PM
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

kishy
April 16th, 2010, 12:33 PM
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?

Raven
April 16th, 2010, 12:34 PM
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.

Mike Chambers
April 16th, 2010, 12:44 PM
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.

Raven
April 16th, 2010, 12:49 PM
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. :)

Mike Chambers
April 16th, 2010, 12:54 PM
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.

kishy
April 16th, 2010, 12:58 PM
...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?

Mike Chambers
April 16th, 2010, 01:03 PM
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

kishy
April 16th, 2010, 01:13 PM
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")

Mike Chambers
April 16th, 2010, 01:16 PM
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.

kishy
April 16th, 2010, 01:35 PM
...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.

Mike Chambers
April 16th, 2010, 01:39 PM
...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.

Raven
April 16th, 2010, 01:39 PM
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.

kishy
April 16th, 2010, 02:32 PM
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.

Mike Chambers
April 16th, 2010, 03:22 PM
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?

Raven
April 16th, 2010, 03:23 PM
You want the file "TCPIP32B.EXE" from MS.

mbbrutman
April 16th, 2010, 03:41 PM
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.

kishy
April 16th, 2010, 04:03 PM
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?

Raven
April 16th, 2010, 04:13 PM
There is a Win3.x copy of Trumpet (iirc), as well as the DOS one (likely what you tried) that should work, but I have no idea what apps are available.

kishy
April 16th, 2010, 05:31 PM
There is a Win3.x copy of Trumpet (iirc), as well as the DOS one (likely what you tried) that should work, but I have no idea what apps are available.

Any chance of a link to a copy of this (that is verified to actually BE this), or at least a filename to look for?

And btw I more than likely had the Windows copy. Attempting to run the installer from DOS, without starting Windows yet, caused Windows to run first then the installer attempted to after, so it's a Windows mode program.

Mike Chambers
April 16th, 2010, 05:33 PM
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.

another nice thing about windows 9x and win 3.x is that if you have a spare NIC and a slot for it, you can have a packet driver for a second ethernet card loaded into RAM before windows starts. then DOS programs in a DOS console window can use that as long as you don't let windows use the card. i do that on an old P1 of mine with windows 98, it's great.

Raven
April 16th, 2010, 05:38 PM
There's a packet driver emulator for newer (NT) oses too, so you can test and dev (or just use) packet-driver-based apps through your ordinary network card under NT.

Ole Juul
April 16th, 2010, 07:18 PM
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.
It seems to me that if it's for a photoshoot all you need is a picture viewer. You can show a .png of any screen you like. :p Hehe

Anyway, if you do get a socket going, then I've got a copy of what I think is the ultimate antique browser: Cello 1.01. It's marked March16, 1994 and even supports gopher! AFAIK it was the first web browser for Microsoft Windows.

kishy
April 16th, 2010, 09:08 PM
Well, lol, perhaps not just for a photoshoot. Ultimately I just wanna do it for the sake of doing it, and grab a photo or two of it butchering some websites in the process.

Slightly O/T but relevant enough: Since PHP is handled server-side, won't even the oldest browsers get along with it, assuming the code being sent back to the browser is old enough?

I'll take a look at/for Cello like you've suggested...can't hurt to try it.

---

Again I ask, since it seems to have been put aside earlier, can someone direct me to a TCP/IP stack that will integrate with Windows for Workgroups 3.1? Perhaps you have a copy of one and can send it? This can't possibly be as difficult to find as it's proving to be...

Ole Juul
April 16th, 2010, 09:40 PM
kishy: Since PHP is handled server-side, won't even the oldest browsers get along with it, assuming the code being sent back to the browser is old enough?
It is _supposed_ to create clean and valid semantically correct XHTML-compliant pages which is supposed to mean the a browser which reads HTML won't know the difference.

As for Cello, having been locked away in a box for 16 years, when you open the door to the modern web, will probably pee itself when it sees what's there now. Haha. I guess you'll be the one to tell us if it works. :)

Ole Juul
April 16th, 2010, 10:24 PM
It just occurred to me that Simtel might be a good place to look for "antique" windows stuff. I only go there for DOS, but try their Windows 3.x winsock collection:
http://www.eunet.bg/simtel.net/win3/winsock-pre.html
or even their Windows 3.x internet collection:
http://www.eunet.bg/simtel.net/win3/inet-pre.html

Edit: I see they have both trumpet winsock, and the alternative twinsock.

kishy
April 17th, 2010, 08:39 AM
It is _supposed_ to create clean and valid semantically correct XHTML-compliant pages which is supposed to mean the a browser which reads HTML won't know the difference.

As for Cello, having been locked away in a box for 16 years, when you open the door to the modern web, will probably pee itself when it sees what's there now. Haha. I guess you'll be the one to tell us if it works. :)

That'd be the problem lol, I don't want it to be spitting out valid current HTML. It needs to spit out 15-or-so year old HTML if it's going to work.


It just occurred to me that Simtel might be a good place to look for "antique" windows stuff. I only go there for DOS, but try their Windows 3.x winsock collection:
http://www.eunet.bg/simtel.net/win3/winsock-pre.html
or even their Windows 3.x internet collection:
http://www.eunet.bg/simtel.net/win3/inet-pre.html

Edit: I see they have both trumpet winsock, and the alternative twinsock.

I'm definitely going to check that site out; thanks for the links. Hopefully I can find a winsock that'll work, since the Windows version of Trumpet seems to not work (could it be because I only have 2.6MB of RAM? Who knows...)

Ole Juul
April 17th, 2010, 01:38 PM
Getting a little OT here but

That'd be the problem lol, I don't want it to be spitting out valid current HTML. It needs to spit out 15-or-so year old HTML if it's going to work.
I don't understand what you're talking about. Valid HTML is what you want because it is backwards compatible. I spend a lot of time in DOS and often use a simple renderer from the earliest days of markup, and it works just fine on "modern" code. :)

BTW, I looked around some more and found the Advisory Group on Computer Graphics (http://www.agocg.ac.uk/contents.htm) which also has a good page on World-Wide Web Browsers (http://www.agocg.ac.uk/reports/mmedia/handbook/hndbk3.htm) where they mention the EINet and GWHIS Browsers.

kishy
April 17th, 2010, 02:32 PM
Well to be clear, in a modern context, I'd think it's implied that "HTML" emcompasses HTML, CSS, and perhaps JS and of course PHP. Anything a browser is likely to run across in the course of daily internet travels, is what I had meant.

Ole Juul
April 17th, 2010, 03:37 PM
Well to be clear, in a modern context, I'd think it's implied that "HTML" emcompasses HTML, CSS, and perhaps JS and of course PHP. Anything a browser is likely to run across in the course of daily internet travels, is what I had meant.To me those are very different protocols serving different purposes. Some browsers under current development don't do all those. Web pages can look unrecognisably different in different browsers because it is, by definition, up to the client to chose what information it wants to use and how it want to show it. Anyway, we still need to get an internet connection before any of that comes into play. :)

Marrr
April 19th, 2010, 05:26 AM
I have a 286
I think this is your problem.
While it's not a problem to use TCP/IP under Windows 3.1 running on a 386 (you can even run fairly modern stuff on that, like Netscape Communicator 4.x), but I've never seen any Windows-based networking on a 286.
I've even checked the ancestor of all GUI web browsers - NCSA Mosaic 0.6b (1993): "We more or less require running Windows in Enhanced Mode, so you will need an absolute minimum of an 80386SX-based machine."

kishy
April 19th, 2010, 05:48 AM
Certainly there is a way...

Raven
April 19th, 2010, 05:51 AM
There's plenty of ways, but they all involve using DOS programs afaik.

What I'd do is just go crazy trying every browser you can get your hands on: Opera 3.62, Netscape 4, IE3, IE5, and so on - to see if they will install and run. If any of them will, you're set. The documentation is likely sparse for this kind of thing, which is why I suggest trial and error.

kishy
April 19th, 2010, 09:41 AM
I'm thinking to not bother with installing if I get a successful TCP/IP stack going...installers may refuse to install based on not finding an OS they want, but it's possible the application itself may still run (perhaps with a low level of stability), so maybe install a bunch in a virtual machine with Win95 then copy the program folders over.

But yeah, finding a stack first, gotta keep things prioritized. I'm sick and school obligations are buiilding up, so this might be on pause for a while.

Marrr
April 19th, 2010, 08:02 PM
Opera 3.62, Netscape 4, IE3, IE5
On a 286? Sorry, but I can only laugh at this idea :mrgreen:
If there is any chance of running TCP/IP with 286 Windows, you need the really early stuff. I've found some such stuff here:
http://www.vectorbd.com/bfd/winsock/index.html
Start with "winsock.zip 120569 bytes Peter Tattam's Trumpet Winsock ver 1.0" - this is the oldest Winsock implementation I managed to find. If it works, then start trying applications like ftp, telnet, and so on...

But don't expect much, back then modern Windows software usually required 386 Enhanced Mode.

framer
April 20th, 2010, 09:12 AM
On a 286? Sorry, but I can only laugh at this idea :mrgreen:
If there is any chance of running TCP/IP with 286 Windows, you need the really early stuff. I've found some such stuff here:
http://www.vectorbd.com/bfd/winsock/index.html
Start with "winsock.zip 120569 bytes Peter Tattam's Trumpet Winsock ver 1.0" - this is the oldest Winsock implementation I managed to find. If it works, then start trying applications like ftp, telnet, and so on...

But don't expect much, back then modern Windows software usually required 386 Enhanced Mode.

I'll 2nd that. I was able to log on to a XP or Vista share and download and upload from my 5170 using win3.1 standard mode with a DOS based manager. I have not been successful with opening a share on the 5170 to log on to from a Vista, XP or any other OS. I just got a copy of WFW3.1 which might allow that to happen but do I want to mess with what I currently have. I can ftp to different internet sites and download also. I wasted lots of time with old browsers if you have a shot it will be with an old DOS based browser. Don't expect to see much.

my thread is here http://www.vintage-computer.com/vcforum/showthread.php?20079-286-win-3.1-networked-to-Vista

framer

Raven
April 20th, 2010, 09:55 AM
For everybody's reference I've used Windows 3.11 for Workgroups *quite* a lot in modern environments, and it works perfectly fine as a server for newer systems to connect to as clients. Windows 3.11 for Workgroups can also connect to newer machines as a client, but has trouble with Vista and 7 due to new hashing and such. I don't recall if it worked well with XP or not, but it's possible to get it to work with even the latest iteration by dumbing down the security to not require a password, as the username authentication part of the process remains the same from Win3.11fw->Win7.

kishy
April 20th, 2010, 11:24 AM
...which spawns the question of what exactly differs between WFW 3.1 and WFW 3.11? Obviously there were some differences, given that the second refuses to run unmodified on a 286, but the first will.

Raven
April 20th, 2010, 11:37 AM
Well one thing they changed is "we're too lazy to make the kernel run in so many modes, so we'll just stop supporting some of them".

They likely optimized it for the 386 so it would run better, and thus there was no point in backporting since the other version was already optimized for a 286 as good as it could get. WFW3.1 is likely a backport of the networking features from WFW3.11 to a version of Win3x that supports 286 mode still.

Edit: Oh, and WFW3.11 was supported until like 2007 for embedded deployment, so it may have had a few network tweaks here and there while WFW3.1 was likely dropped far sooner. WFW3.11 enjoyed an extraordinarily long embedded lifespan, nearly double that that XP did as a desktop OS which was quite long as well. All of this makes for a goldmine of awesome for those like me who enjoy Win3x.