32bit computing arrived to the masses. Although it’s incredibly frail by modern standards, Windows 95 did deliver on the promises of OS/2. Depending on your apps, and drivers of course. Although OS/2 did have int13.sys to pass disk calls to a special v86 machine which then used the disk BIOS to make disk access possible, Microsoft and IBM stopped short there, not going all the way letting OS/2 use MS-DOS device drivers. Windows 95, however could.
This was always the winning strategy of Windows, is that it relied on the incredible OEM driver support for MS-DOS. Of course this would also be a catastrophic weakness. From my personal experience being able to leverage ancient MS-DOS drivers also helped squeeze as much as possible out of existing hardware. Case in point, the NDIS2 drivers for the AT&T Starlan 1mbit cards worked fine under Windows 95, additionally you could lost just the lower level drivers, and 95 could then load it’s protocols on top of that stack allowing you to have a TCP/IP network over that 1mbit Starlan stack letting you telnet into your 3b2 (or setup SAMBA, and doing file/print sharing).
If anything the biggest flaw of Windows 95 was not installing TCP/IP by default. However unlike many OS’s of the time, Windows 95 did include LAN and dialup stacks. There was plenty great about OS/2, but it’s refusal to integrate networking into the operating system hamstrung things like named pipes, peer, and larger apps, as you would have to buy and license a stack of stuff to bring OS/2 up to where it should be, while NT and 95 were complete out of the box.
Windows 95 was an excellent bridge OS for the era, until OEMs finally got around to writing drivers for Windows NT. Once the mainstream could finally take that leap, and leave MS-DOS far behind. But that didn’t really happen until Windows XP.
That being said, the favorite thing is to run Windows 95 in a browser. I found https://copy.sh/v86/ the fastest and best, as it loads a short 6MB compressed core image, and you are instantly teleported to the 95 desktop.
Try it out, play some solitaire and enjoy!
The mentioned driver’s name should be IBMINT13.I13. In fact networking was integrated earlier in OS/2. The old OS/2 Extended Edition Version 1.1 from late 1988 included the LAN Requester. And IBM’s OS/2 Warp Connect which included TCP/IP and LAN connectivity was shipped from June 1995.
How did the programmer interact with networking components?
What I liked about Win95/NT is they all had winsock.dll, so the programmer had a builtin API to call that was always present. The user could be using IPX or TCP/IP, on dialup or token ring, and the developer (largely) didn’t care. Earlier environments allowed for networking functionality to be installed, but developers ended up having to code for each potential networking add-on. While LAN Manager via extended edition was one option, a user could also install something like LANtastic, Netware, etc. Realistically those networking stacks ended up providing file sharing but not being used as a platform to support networked applications due to the lack of a generic and interoperable API.
For me it was a real game changer to view a network as a platform component that can host whatever service I can write.
Netware (and I’m sure others) was server based. They wanted you to write add-ons for the server itself. For many, the end goal was file and printer sharing along with e-mail. Apple tried “linked” applications with AppleShare, which they could easily do with their usually tight OS/hardware integration, but it went nowhere.
Windows 3.1x had winsock, but it was a mess. The API itself was stable but there was no generic system-wide version of the DLL. You had things like Trumpet Winsock and AOL replacing the DLL to pipe communications to their clients since there was no OS level method of doing it. WfW 3.11 fixed this with the VxD based networking stack, but it came too late.
This later caused problems with Windows 95, since AOL and others were slow to update their clients to 32-bit and thus didn’t support Win32 winsock clients. You were stuck using the 16-bit versions of Netscape until they did and that fancy built-in Internet Explorer browser didn’t work at all. AOL’s winsock stupidity made me try MSN (the original Explorer based one!) for a few months, and later switched to a dedicated dial-up ISP using the built-in DUN stack.
Windows 95 included peer-to-peer network and file/printer sharing. That killed third party networking products like Netware Lite (and small Novell Netware), Lantastic e.t.c.
I forgot that 95 has a Netware emulator as well, it just demands a NT server for authentication. And of course there is file & print services for NT that also emulates a Netware server.
For those that want to peek under the covered there’s: Unauthorised windows 95
This is a FANTASTIC book, I loved the examples that showed how to use the DOSX dos extender from Turbo C++, albeit in tiny mode only.
“Windows 95 was an excellent bridge OS for the era, until OEMs finally got around to writing drivers for Windows NT.”
Well… Only Server hardware OEMs went in the painful quest to write true NT “monolithic” device drivers and HALs. The rest was writting VxDs while waiting for the WDM Port/Miniport driver architecture (originated on MS-OS/2, and implemented fully in Chicago/Win95, ported to NT5 and then backported to Win98, as MS tech generally goes and backs). Yes, they wrote for WDM, not NT… And now they write for KDMF (WDM updated form).
Windows 95 was both a monumental achievement and a monumental achievement that it actually worked. Looking at the PC landscape in 1995, you had to deal with:
Multiple video card, sound card, and motherboard chipset vendors. Multiple CPU manufacturers (besides AMD and Intel). Multiple bus architectures (EISA, MCA, VLB, PCI). Even storage buses were a pain since you had legacy ESDI still floating around in addition to IDE, SCSI, and all those non-standard CD-ROM interfaces. One also had to contend with low-level stuff like APM and vendor specific extensions and the recently created (and buggy) ISA PnP specification.
Networking was still the wild west with multiple protocols in use (Novell IPX, TCP/IP, Banyan VINES, NetBEUI, AppleTalk, DECNet) with various bloated clients that hooked into the OS in fun and excitingly undocumented ways. Physical standards were all over the place too. Got someone running a LocalTalk ISA card talking to an AppleShare server? Gotta support that somehow.
All of this needed 32-bit protected mode drivers, developed and tested against each other for weird interactions. Windows 95 also bent backwards to support Windows 3.1x drivers for many classes of devices if a native driver wasn’t available, along with real mode DOS drivers.
Oh…..and they also had to test Win16 app compatibility AND make sure stuff ran properly in a DOS box. Raymond Chan’s “The Old New Thing” book and blog details what “fun” that was. We won’t get into long file names and the ways programs tried to destroy them.
In the end, the industry consolidated big time in terms of both hardware standards and vendors making things somewhat easier to OS writers. Lucky for Microsoft, most of this happened by the time Windows XP showed up and moved us off the “Protected Mode DOS Extender on steroids” mess that Windows 9x was.
What surprises me is that despite all the above, the transition away from DOS/Win 3.1x to 95 happened fairly quickly. It was THAT big of an improvement to deal with driver and hardware hell. Even businesses that had to deal with the added complexity of networking stacks moved fairly quickly….mostly to Microsoft’s advantage since many vendors dropped the ball in getting 32-bit clients released.
I know most people reading this blog already know this, but from a technical point of view it was a very phased transition, starting with Windows 3.0 as a DOS extender using DOS for all storage and networking drivers, then 3.1 using protected mode disk access, then 3.11 using a protected mode file system and networking drivers. These systems were all capable of falling back to DOS.
The situation isn’t hugely different comparing WfW 3.11 and 95. Although there were a zoo of devices, every new type of device had to support DOS + protected mode Windows to have any customers, and Win95 is still just DOS + protected mode Windows. I’d argue that moving to NT was still the much larger change, where the fallback isn’t there and every device needs a real driver.
That said, this also marks the 25th anniversary of the compatibility hacks like the tunnel cache which still exist to this day to mitigate DOS applications inadvertently destroying long file names.
“Protected Mode DOS Extender on steroids”
Again with this lie… I wonder how many time i will have to say… Win386 (the kernel/os used in win3x 386 mode and win9x) IS an OS on its own! NOT a d*mn DOS extender!
In other words… Win3x 386 mode and Win9x are DOS as Netware and OS/2 are…
The industry pivot to TCP/IP was amazing.
When I started networking professionally we had SNA, NetBEUI, IPX/SPX, DecNET and dead last was TCP/IP. With its biggest use being management of Cisco routers and access to the AIX compute grid.
The rise of commercial internet and Windows NT first started to destroy the plurality in the Data center with the removal of the VAX and decnet, and the removal of stuff like SQL and lotus notes on OS/2. Netware was being upgraded to 4 and still seen as viable, and all the Unix was safe.
But now our NT machines worked faster over netbeui but they could also find each other Over the wan faster with IP as IPX hit a breaking point with well north of 100,000 nodes (we had big offices world wide!). SNA scales as most people interfaces to a 3174 or directly to the FEP over carefully crafted token ring bridges.
The rumours and hope of Chicago grew so crazy in 1994 that 1995 opened the proverbial flood gates. It was now easy to setup a token ring card with ipx, IP and SNA. And again IPX hit it’s scale issue, while the only way to get that file from Tokyo to New York was to hit their NT server, first by IP then we got smart with WINS. It worked so well there was the beginning of regional domains and trusts. 95 was the thing that setup the next big push as now we had tcpip on the desk, and once NT 4.0 shipped the world pulled the plug on netware. By 1997 we were building pure IP networks. Even Cisco translational bridging had brought Token Ring to and end, combined with 100mbit switching Ethernet.
By 1998 it was over, the only devices on the Token Ring were the FEP, 3274s and SNA servers. It was down to a single switch.
IPX was gone and 95 was being rolled up to 98 on the mobile / laptop end and NT 4 workstation on the high end.
It was a perfect storm of PCI, Pentium, Windows, TCP/IP that wiped them all out.
One of my favourite Windows versions, along with 98 SE, 2000 and 3.11 WfW. Marked the beginning of my best childhood gaming days.
Anything after Windows 2000 was just a pure PITA to me. I can’t even use W10 without complaining about anything that was easier to do before or about the flooded “new” Start Menu. Windows Vista/7 was the reason why I moved to macOS and never looked back again.
Happy Birthday, Windows 95!
Catalina pushes me back to 10…
It’s amazing, load up 10.6 -even in a VM, and it’s so ducking fast on modern hardware. And it runs PowerPC so fast as well. Modern OS X is a dumpster fire compared to 10.6
I have zero interest in Surrey or whatever the new one is.
I’m interested in ARM Macs and Big Sur, and the opposite feels for x64 and Windows 10. BTW, it’s macOS Big Sur 11 😛
Although I also agree that previous OS X incarnations were pretty good too. Snow Leopard/Mountain Lion in particular.
Currently I am trying to find a way to run Windows 9x or XP with Direct3D acceleration on something other than VMware/Parallels, just to play Grand Prix 4, a game from 2001. Apparently there is no way to do that without VMware or Parallels. Damn.
I’m really trying to work on that. Boxedwine can run Windows programs on multiple platforms using Wine and a CPU emulator. I already have it working on a Raspberry Pi. Of course performance is an issue. But hopefully that will be improved. As for Direct3D acceleration, that works by Wine translating Direct3D to OpenGL and Boxedwine allowing the OpenGL to be passed through to the host. If Mac/ARM doesn’t do OpenGL, there is still hope with Vulkan.