Linux and growth of Internet

Steven M Jones wrote: There's another thing that I think everyone has missed: a standard API for network applications on each personal computer operating system platform. Remember the joys of TCP/IP on MS-DOS in the late 1980s? Each vendor's TCP/IP stack had its own interface to network drivers, and its own interface for applications. So you had to choose your network cards based on what your TCP/IP stack vendor had drivers for, and you had to choose your TCP/IP stack vendor based on what applications you wanted to run. And your application vendor wasn't liking life much either, because the MS-DOS TCP/IP stack vendors didn't always maintain API compatibility across versions of the TCP/IP stacks. The earliest things I remember were monolithic applications that included a network card driver, TCP/IP stack, and application(s). For example, there was the MIT PC/IP stuff, which comprised a driver for the 3Com 3C500 card, a TCP/IP stack that supported a whopping one TCP connection, a Telnet client with H19 terminal emulator, and a TFTP server. The idea was that you would telnet to your Unix box and use its TFTP client to control file transfers. (The initial entry of The Wollongong Group into this market was a repackaging of the MIT PC/IP as WIN/PC with a manual and a box, and there's a story that some folks at MIT saw the advertisement and said "hey, we could do that", found a good deal on some green three-ring binders, and thus was born FTP Software.) Eventually this split up into TSR-based network card drivers and TCP/IP stacks. Some of the MS-DOS TCP/IP stack vendors grew BSD-like sockets-flavored APIs, but they were often implemented as libraries that had to be linked with the application, and they weren't all completely compatible with each other nor with BSD sockets. (The Wollongong Group's WIN/TCP for DOS and PathWay Runtime for DOS worked this way, at least.) This continued into the 1990s. First there were interfaces defined so that protocol stacks could talk to network cards: FTP Software pushed the packet driver specification, Novell pushed ODI, and MICROS~1 pushed NDIS. This was basically the protocol stack vendors pushing the responsibility for the network card drivers to the network card vendors, because developing and maintaining network card drivers was starting to cost serious money as more hardware vendors got into the network card business. Then in 1990 this Windows thing took off, and the MS-DOS TCP/IP stack vendors noticed. I know TWG had a "SOCKDOS.DLL" that provided a DLL-based sockets-flavor API for Windows applications. There was some other company, JSB or something like that, that had a sort of "API harmonizer" that provided a consistent API across various DOS/Windows TCP/IP stacks. Eventually someone got the idea that the TCP/IP stack stack vendors could be providing a common DLL-based API and that is how the Windows Sockets specification came about. That's where you got to the point that someone could write a Windows-based TCP/IP application and reasonably expect it to work on any vendor's TCP/IP stack that had a WINSOCK.DLL implementation, and people did! Without that, I don't think there would have been, say, Netscape or Eudora for Windows; there certainly wouldn't have been just one of each. Of course the next step was for MICROS~1 to provide a TCP/IP stack with a WINSOCK.DLL implementation in Windows 95. There was no longer any need for third-party TCP/IP stack vendors for Windows. I think the only company in that business that has survived to date is Netmanage (who bought FTP Software). I saw a lot of this, working at The Wollongong Group starting in December 1989. I didn't get involved in it 'til very late, late 1993 or so; the market for WIN/TCP for MPE/V was winding down and I got pushed (not entirely unwillingly) into working on the TCP/IP stack for MS-DOS and then for Windows. Those of you who used PathWay Runtime 4.0 on Windows can blame me, the TCP/IP and Winsock were my primary responsibilities for that release. -Frank McConnell