• Please review our updated Terms and Rules here

Windows 3.1 and TCP/IP over Ethernet

Caluser2000 said:
No just upgrade from version 3.1 to 3.11. It's just half a dozen or so core files. 3.1 can do 32-bit enhanced mode but needs help on the networking side. There is a Windows 3.1/3.11 Workgroups upgade to WfW 3.11
Click to expand...
Yeah, this is correct based on everything I've read.

These are all products that exist(ed):
Windows 3.1Windows for Workgroups 3.1
Windows 3.11Windows for Workgroups 3.11

One might expect some symmetry in terms of features like the "for Workgroups" part just added LAN features on top of the base product, but according to Wikipedia and what I've read elsewhere, the only one of those that supported 32-bit file access for example was Windows for Workgroups 3.11. Wikipedia also seems to indicate that that's the only one that supported "a 32-bit stack add-on package (codenamed Wolverine)". There are references if someone wants to read further.
 
Zare said:
Nice find.
Btw, isn't splash screen in VGALOGO.RLE? Seems like no change there, so you still have 3.1 image.
Curious to what OS reports after that official upgrade procedure.
Click to expand...

I haven't checked it via an API, but the "about" menu items report 3.11 after the upgrade.

Although the boot logo still shows 3.1 as you surmised.

I did notice the 386 icon appeared after the upgrade, which I didn't see there before... I'd have to "unupgrade" though to check it.

Interestingly, I should be able to do that with a simple batch file. That might be something to play with :)

David
 
doshea said:
the only one of those that supported 32-bit file access for example was Windows for Workgroups 3.11.
Click to expand...

Maybe has to do with evolution of SMB (file sharing) protocol features.

I wonder why they released a 3.1 to 3.11 package in itself and not just sell a full 3.11 OS to 3.1 users at the price of that refresh package. Same also with Workgroups update.
As far as I know there were no such refresh packages in earlier MS releases, I certainly can't find one for Win 1.x or 2.x.

So if you went upgrading all the way from 1.0 to WfW 3.11 you can actually stop at full system upgrades at 3.1 and then use refresh packages.

An evil mind would connect release of Registry in 3.1 and henceforth full system upgrades yield a less performant system than if installed 'originally'.
 
The Windows 3.11 "refresh" doesn't include the one big internal feature of WfW 3.11... the 32-bit File Access driver. This is the protected mode VFAT and VCACHE driver that bypassed MS-DOS Int 21H and SmartDrive (if loaded).
 
Zare said:
Maybe has to do with evolution of SMB (file sharing) protocol features.

I wonder why they released a 3.1 to 3.11 package in itself and not just sell a full 3.11 OS to 3.1 users at the price of that refresh package. Same also with Workgroups update.
As far as I know there were no such refresh packages in earlier MS releases, I certainly can't find one for Win 1.x or 2.x.

So if you went upgrading all the way from 1.0 to WfW 3.11 you can actually stop at full system upgrades at 3.1 and then use refresh packages.

An evil mind would connect release of Registry in 3.1 and henceforth full system upgrades yield a less performant system than if installed 'originally'.
Click to expand...
The MS Windows was sold in boxes when the update accured but not marked as so iirc. Or had a 3.11 plonked on the boxes. The start up logo was change on these iirc as well.
 
Last edited:
hairyvisionary said:
In one beginning (there were several) there was MIT PC-IP which was a monolithic application supporting one TCP connection for its Telnet client (the TCP being ported from Xerox Alto TCP) with a basic terminal emulator (I'm thinking H19 and not VT100), UDP for TFTP and DNS, IP, and a 3C500 or 3C501 network card. When you were done you exited back to MS-DOS and the networking stack, being part of the application, was no longer executing.

I was told that some folks at TWG took the MIT PC-IP code and packaged it up with a manual in a small binder and maybe a slip case (can't remember) and that was WIN/PC Release 1, and that some of the people who worked on PC-IP at MIT saw an advertisement for it, recognized their code in it, and that's how FTP Software got started. They got a good deal on green three-ring binders and used those for their manuals for a while.

I'm not sure where HP got their PC stuff from (multiple beginnings) but it was doing TCP/IP over IEEE 802 framing using 3Com 3C501 cards, and it was a bunch of TSRs that took up about 150KB of your Vectra's RAM (supporting PC LAN stuff including shared access to network drives and printers) so now you needed an EMS board to open the larger 1-2-3 worksheets you'd done up back in the days before the LAN when the LaserJet was shared through a switchbox.
Click to expand...
I know this is going to sound crazy, but is there any other files besides the ones on bitsavers for MIT PC/IP? They don't include clean copies of the libc which they only have fragmented reverse patches for.. It's quite weird.

I've managed to cobble together a build system using 4.1BSD's ar/ranlib GNU's cpp/ld along with some of the other utilities to build the ping & telnet client, although the formatting is all wrong with more cr/lf issues for some reason. I think I need to re-base libc on the non 8087 one, along with the MIT PC/IP stack? I donno.

I've been able to connect to a test BBS at home just fine so at least I've been able to rebuild it all from source, which I guess counts for something.
 

Attachments

  • mit_pcip-tobbs.gif
    mit_pcip-tobbs.gif
    1 MB · Views: 11
neozeed said:
I know this is going to sound crazy, but is there any other files besides the ones on bitsavers for MIT PC/IP? They don't include clean copies of the libc which they only have fragmented reverse patches for.. It's quite weird.

I've managed to cobble together a build system using 4.1BSD's ar/ranlib GNU's cpp/ld along with some of the other utilities to build the ping & telnet client, although the formatting is all wrong with more cr/lf issues for some reason. I think I need to re-base libc on the non 8087 one, along with the MIT PC/IP stack? I donno.

I've been able to connect to a test BBS at home just fine so at least I've been able to rebuild it all from source, which I guess counts for something.
Click to expand...
No real idea. Some years ago I was looking around for the MIT PC/IP and all I could find on the Internet was the later CMU-improved version. I didn't do anything with it, just wanted to look at it, having looked at what it had turned into at TWG (it had been turned into a TSR that could handle multiple applications using it for network access and had a sockets-flavor API bolted on top, then had a bunch of stuff (including some basic TCP functionality) ripped out of the TSR to reduce its memory footprint.

I think that when I got to TWG (late 1989) the toolchain for the TCP/IP TSR was Microsoft C 5.1. I found a Manx Aztec C for MS-DOS box in the library so maybe that was used or evaluated, and have heard a story that the original WIN/PC 1.0 development was hosted on a VAX (not sure if VMS, Unix, or Eunice on VMS).

Remember that Unix C compilers (and their underpinnings for *printf()) will generate LF only for "\n", MS-DOS C compilers (and C code written for them) are more likely to generate CR LF. Something like that may explain some of the formatting I see in your GIF.
 
hairyvisionary said:
No real idea. Some years ago I was looking around for the MIT PC/IP and all I could find on the Internet was the later CMU-improved version. I didn't do anything with it, just wanted to look at it, having looked at what it had turned into at TWG (it had been turned into a TSR that could handle multiple applications using it for network access and had a sockets-flavor API bolted on top, then had a bunch of stuff (including some basic TCP functionality) ripped out of the TSR to reduce its memory footprint.

I think that when I got to TWG (late 1989) the toolchain for the TCP/IP TSR was Microsoft C 5.1. I found a Manx Aztec C for MS-DOS box in the library so maybe that was used or evaluated, and have heard a story that the original WIN/PC 1.0 development was hosted on a VAX (not sure if VMS, Unix, or Eunice on VMS).

Remember that Unix C compilers (and their underpinnings for *printf()) will generate LF only for "\n", MS-DOS C compilers (and C code written for them) are more likely to generate CR LF. Something like that may explain some of the formatting I see in your GIF.
Click to expand...
I managed to get it sorted out!

I'd written the full thing about it here:

With my github repo of all the ported tools and stuff here:
github.com

GitHub - neozeed/8086pcc: Old PCC port to the 8086 used in the MIT-TCP port

Old PCC port to the 8086 used in the MIT-TCP port. Contribute to neozeed/8086pcc development by creating an account on GitHub.
github.com github.com

basically, I wasn't sure of which or how to merge some libc updates or what was going on since it seems I wasn't sure where or if there was any documentation on the source.

With the updates I had more things just build and they look a lot more correct. Although it really hates interfacing with SLIRP, so I suspect it has old style classful routing & masks at heart. It's been ages since I've seen a 192.168.0.0 "0 bit mask" referred to as "377,377,377,0"

I'd seen some mention of a later one ported to Microsoft C, I suspect it might be the CMU version. I'll have to go digging around for it.

It's been a somewhat confusing but fun adventure, that is for sure! I guess for anyone else from the future want to see, I've attached a DOS 2.11 boot disk with enough compiled and setup for my home network. Good thing DOS 2.11 also went MIT licensed ;)
 

Attachments

  • dos211-mit-pcip.zip
    179.2 KB · Views: 0
neozeed said:
I managed to get it sorted out!

I'd written the full thing about it here:

With my github repo of all the ported tools and stuff here:
github.com

GitHub - neozeed/8086pcc: Old PCC port to the 8086 used in the MIT-TCP port

Old PCC port to the 8086 used in the MIT-TCP port. Contribute to neozeed/8086pcc development by creating an account on GitHub.
github.com github.com

basically, I wasn't sure of which or how to merge some libc updates or what was going on since it seems I wasn't sure where or if there was any documentation on the source.

With the updates I had more things just build and they look a lot more correct. Although it really hates interfacing with SLIRP, so I suspect it has old style classful routing & masks at heart. It's been ages since I've seen a 192.168.0.0 "0 bit mask" referred to as "377,377,377,0"
Click to expand...
You haven't lived 'til you've seen it represented as "C 192.168.000 000"
 
You must log in or register to reply here.
Back
Top