2021 2020 2019 2018 2015 Quick Links
Originally encoded on August 23rd, 2015 and published the same day
Given I had so few network cards I could count on to use with MS-DOS and Windows 95 reliably at the time, making this thing was such a pain in the ass. In fact, all I really had was some random SMC ISA network card and a couple of other PCI-based cards, even one which was only rated at 10Mbps! Somehow that didn't deter me from doing a ton of experimentation with networking over the course of 2014 and 2015.
I started off just trying to see if I could connect my 486 computer to a shared folder on Windows 7, and then I stepped up to the challenge of running a domain controller on Windows NT Server 4.0. Some more videos about this were planned, and I do have some footage making headway into them, but constant fatigue prevented me from ever finishing such things. For the longest time, much of my knowledge of networking on old computers was secluded to my bedroom, but knowing I would have to make seven videos about Windows 95 at this point, it was only a matter of time before more of that knowledge would start to leak out.
Having finally broke free from the dreadful clutches of school, I knew I had a lot more time to work on what I wanted to by day or night, and learn far more than I possibly could have back there. Taking a slight cue from some videos like "Using some old computer or operating system for a week", I originally intended for Hardcore Windows 95 to be something like "Windows 95 in a week", where every day would bring a new idea to the table.
But I was still going by my old style of making videos, preferring to not spend too much time on a video and get it online as soon as I can. With all the problems I ran into when trying to get a network card detected as well as the time it took to encode the whole video, there was no way I was ever going to be able to meet that goal of one video per day, so I ditched that idea by the third segment. It was disappointing, but more time allotted to working on these videos meant I could ensure they were of the highest quality I could offer around that time.
I tried using my Am5x86 build to get an installation over LAN working, and I tried a 3Com 3C905B-TX earlier - a network card that's prized for having a great driver, yet I could not get mine to work in Windows 95! One such reason for this was that I could not find the right driver, and I'd also blame the fact that I had the PnP ICU enabled in the BIOS settings; even if you are using Windows 95, I strongly advise you do not do this. Instead, just let the BIOS configure all PnP devices instead of letting Windows 95 directly manage some of them. Again, for best results, always set "PnP OS Installed" to NO.
I ended up settling on some lesser SMC1208 network card. The whole thing was a mess, and I never really did end up getting the installation to chug along smoothly... but at the very least, it worked. I just had to pick up a lot of the scraps myself. Given all the problems I was running into, being able to install Windows 95 over the network felt like nothing short of a miracle, but the troubles that came with it forced me to flat out ignore it for another couple of years, and so I would continue to rely on optical media like everyone else. At least post-Setup networking saved me the trouble of dealing with moving floppy disks, CD-ROMs, and USB flash drives around.
The Unsung Hero
In order to even be able to do an installation of Windows 95 over LAN, the client needs a server to connect to. Previously I was using a virtual machine, first with Windows NT Server 4.0 and then with Windows 2000 Server. In the case of virtualization, I found more favorable simply because it didn't eat up 1-2 entire cores on the host CPU thanks to proper implementations of power management in APM and ACPI.
Quite a bit had changed over the course of 2015, though. Months prior to making this video, I got back my old friend, the Asus K7M build from 2000. It had been sitting dormant underneath a staircase for a full decade, so you could guess how exciting it was to finally have this back, this time all to myself to further expand upon the room I had for experimentation. The original video card was failing and had to be replaced, but soon enough I had that thing running as another powerful Windows 98 machine for a while.
But given my Dell Dimension XPS T600r I used to have was already filling in that role, I ended up turning the Athlon-based computer into a relatively simple domain controller. Since Windows NT 4.0 provided the most straightforward path to install Windows 95 over the network and just looked much cooler, I settled on that, and this time around the APM BIOS could fill in for power saving features where Windows NT was lacking!
There are three ways one would be expected to deploy Windows 95 over the network. The first method is probably the easiest, as it just takes comparably old computers already networked and running Windows 3.1x. All you have to do is push the Windows 95 installation to the existing clients through a logon script, or by instructing users to run the setup program. In combination with an INF batch script, essential information can be automatically filled out, and this is something I did try later on, but I never thought to put the two together until much later. For computers built in early 1995 or earlier, Windows 95 would have enough drivers to take care of everything from there.
The second involves the use of an RPL ROM installed on one of a select few network cards Windows NT supports. Theoretically, an RPL ROM should be very convenient as it outright eliminates the need for any floppy disks or CD-ROMs at all, but I've found them to be more trouble than they're worth due to cryptic struggles in establishing connections. Moreover, the rarity of RPL ROMs and difficulty in finding a ROM image from the internet to flash means they'll be too far out of reach for most people, anyway. I might touch on it again later, but certainly not now.
I settled on the third option, where I would use Windows NT's Network Client Administrator program to create a network installation startup disk. Although this program is actually quite modular with some know-how, it doesn't really convey that, and it only comes with two options upfront: either you can create an over-the-net installer of the MS-DOS network client, or a minimal floppy disk that kickstarts a Windows 95 installation.
Creating a LAN Installation Disk
Once you've got the Network Client Administrator files loaded somewhere, either straight from the CD-ROM or preferrably onto a hard disk somewhere, you can start configuring how you want your floppy disk to be. However, you must keep in mind that Windows NT will not make your floppy disk bootable! You have to do that yourself; in some MS-DOS environment, you'll want to format a new floppy disk and have it copy the system files using the command FORMAT A: /S. You can also do this in Windows 95 or 98, and starting with 95 OSR2, you get the added bonus of FAT32 support, a necessity for large hard disks in these later operating systems.
If you have an ISA network card supported by the MS-DOS network client out of the box, you'll have a much easier time getting things going, but anything else will require some extra work once you're done. Since I do not have any of the network cards listed in the Network Client Administrator, that is exactly where I have to go.
Either way, the next form asks you to supply some information for the computer you plan to install Windows 95 to. Make sure you enter a computer name that is unique to your network, as Windows 95 Setup will take this from the boot disk and use it for the installation. You'll also need to specify a user that has permission to read the contents of the share containing the setup files. A password is not specified here; that is done when you boot the computer. You probably don't need to specify a domain here, as workgroup networking can get the same job done.
I strongly advise you use the NetBEUI protocol for all of your network boot disks. The reason for this is that it's very lightweight, and doesn't take up so much conventional memory like TCP/IP does. Plus, DHCP can be kind of a hit or miss when you're dealing with something like MS-DOS, Windows 3.1x, and even Windows 95 in some instances. Part of this has to do with a Y2K-related bug in leasing an IP address. Just make sure that the NetBEUI protocol is actually installed on the server which provides the relevant network share.
Floppy disks are slow, so the file copying process will take a while, but once that's done, you should be ready to boot the target machine with the new disk unless you need another driver.
To load another driver, you'll need to copy the .DOS file to the disk. That's all the network client needs to get it going, but you'll also need to modify PROTOCOL.INI and SYSTEM.INI.
For PROTOCOL.INI, it's as simple as performing a find and replace operation on the driver name. Usually this will be something like ELNK if you haven't chosen anything different. A text file supplied with the driver should contain the driver name you need to apply, being SMC8000 in my case.
In SYSTEM.INI, find a line that reads netcard=. If there's text on the same line after the equals sign, remove it. The value of this variable should be the filename of your NDIS driver, something like SMC8000.DOS.
haha it crash funy!!!
That right there in the video is another amusing example of how Windows 95 can crash. When it hits a point where every pixel of movement in the mouse triggers a short beep, you know you fucked up bigtime. Everyone loves to shit on Windows 95 for seemingly random crashes, but 90% of them are really just caused by bad drivers or system configurations, which can affect ANY operating system.
Windows 9x is a unique specimen when it comes to the kernel. Even though 32-bit x86 operating systems have been around since the late 80's, 386 PCs were still kind of underpowered compared to other high end computers, and were more often used as XTs on steroids. They are competent CPUs for sure, but something like a GUI can put massive strain on it without some form of hardware acceleration, which I don't think was readily available then. For sure, Windows NT supported the 386 for a while, but a Pentium CPU is the ideal minimum specification for anything related to that, as it was a very forward-thinking operating system once intented to run on many platforms.
To make full 32-bit multitasking available to more consumers who may be hard-pressed on system resources to run Windows NT feasibly, Windows 95 took control of many of the computer's resources, but many layers of abstraction and advanced features like Unicode were foregone so as to allow programs to directly control some parts of the system, which seems to improve performance in some areas and certainly reduces the memory footprint. Case in point: using the DEBUG program in an MS-DOS prompt, you can manipulate the APM BIOS in pretty much all the ways that are possible on your system by writing lines of API calls in assembly after disconnecting Windows 95's own link to it. Go ahead, try forcibly shutting off the computer with the debug utility in both Windows 95 and NT and see which one lets you do it. Just type a cs:100 and then the following lines:
mov ax,5304 xor bx,bx int 15 mov ax,5301 xor bx,bx int 15 mov ax,530e xor bx,bx mov cx,0102 int 15 mov ax,5307 mov bx,1 mov cx,3 int 15 mov ax,4c00 int 21
Then leave a blank line, enter g, and see what happens. A system running Windows 95 will shut off instantly, while one running Windows NT will do absolutely nothing. This should give you an idea of how Windows 95 and NT vary greatly in the levels of control they allow to programs. If you are using a computer with an AT power supply, replace mov cx,3 with mov cx,2 before the last int 15 to activate suspend mode instead.
No other operating system developer could be in the same position as Microsoft, having to support millions of computer users of all classes while trying to execute the transition from 16-bit to 32-bit, which is why Windows 95 is the way it is. It should be taken as nothing short of a miracle that an operating system that starts off with a DOS kernel is able to reliably handle so many processes running at once (including those system tray bloatware programs that cause excessive swapping), as well as utilize the complete set of Win32 functions found in Windows NT and yet more. Even the Macintosh was 32-bit from the start when it moved from the 68K series to PowerPC.
247 unique views here since June 23, 2021