2022 2021 2020 2019 2018 2015 Quick Links
How I Got Here
The creation of Windows 95D Lite stems from a wide range of other projects, some which triumphed and others that fell flat. Any of my experiments that could remotely resemble what this remaster of Windows 95 would become can be traced back all the way to the beginning of 2018, when I started trying out a very obscure program hidden in plain sight on the Windows 98 CD-ROM.
Before I get there, though, I'm sure you know the usual routine to installing Windows 95, right? You get a standard install CD, which is NOT BOOTABLE so you also need a boot floppy... then, once you complete Setup, you will most likely have to spend a lot more time installing a bunch of drivers as well as some additional update packages if any software you want to use requires them. You'll probably luck out and not have to do any of that if you use a 386 or 486 computer with only ISA/VLB cards or a very narrow selection of PCI cards, but for anything Pentium or later, you may very well have to go through that extra trouble.
But Windows 98 has vastly improved out of the box support for more devices and software from 1998 or earlier as well as a refined kernel, and so the second edition is the preferred choice for a lot of old systems... even classic Pentiums. In fact, so many users just go with it that not many seem to consider Windows 95 as being practical for a Pentium II build. Why is that, now?
OSR2 Clarifications
Windows 95's version log is a bit complicated if you're new to the whole thing. There is, of course, the original version from 1995 that was sold both as retail packages and bundled with new computers, but several others exist from 1996 and 1997 as well, and their underlying differences may not be immediately apparent.
Of all versions, only the gold release was ever made available for purchase by end users as a standalone package - either as an upgrade for Windows 3.1 users on either floppy disks or a CD-ROM, or for computers only running MS-DOS or no operating system at all on floppy disks only. Even as Windows 95 Gold was falling way behind rapidly evolving hardware throughout the late 90's, it continued to be sold as is supposedly as late as 1999 before it was pulled off the shelves. The retail package was only ever updated to include a separate Internet Explorer 4 installer.
OEM Service Release 2 was quietly made available to commercial system builders one year after Windows 95's release, and introduced a number of subtle changes primarily focused on supporting more hardware. It also installed Internet Explorer 3. Another year after that, OSR 2.1 was released. This didn't actually change the core operating system, but included a USB supplement package OEMs could integrate to add support for new system buses like USB and AGP. Collectively, these are also referred to as "Windows 95B". It's argued to be the best version of Windows 95, and the one I've tended to stick to for as long as I have.
OSR 2.5, or Windows 95C, is more of a rehash of Windows 95B that attempts to install Internet Explorer 4 as well as some additional updated components. Compared to 95B, 95C was very cheaply put together in the rush to topple Netscape as the dominant web browser, as most everything 95C offers has to be installed after you reach the desktop. This, of course, means you can avoid such a forceful installation fairly easily with a bit of prodding, but you'll still have Internet Explorer 3 on hand. The only real thing that is automatically installed is an updated VMM32.VXD which seems to handle the P6 architecture better.
Do A Repetition
The creation of the video beige dream was really fun. I got to install Windows 95 on seven computers, and in turn make some kind of forced aesthetic with them. At the same time, it was terrible having to go through the same process so many times! Because Windows 95 was being installed on such a wide variety of hardware going up to a 600MHz Pentium III, it was pretty much a given that no appropriate drivers would be preloaded. I did burn several CDs of Windows 95A, 95B, and 95C, which sort of cut down on setup time, but it was still optical media, making it as much of a hassle as it always has been.
As I was making beige dream, some people asked me why I wasn't using Windows 98, especially given the video was set in the year 1999. To that, I say there's no reason why so many users wouldn't still be using Windows 95 this late. Windows 98 was garbage especially in a time where many systems still had 32MB of RAM or less. To use that would just be asking for virtual memory swapping nightmares, all which can be easily mitigated by simply using the old Explorer interface. None of the systems used in the video were so dry on memory, of course, but Windows 95 is a lot better anyway.
There had to be some other way things were done, given how many machines were concentrated in larger organizations. You can't just assume that the tech guy at a computer lab had to settle for loading the same new ATI Rage driver on some 30 self-built computers with matching configurations. Moreover, if Windows 95 can automatically detect a Tseng Labs ET4000, why can it not also do the same with a 3dfx Voodoo3? There's something being overlooked here...
First Stop: Eliminate Physical Installation Discs
Come 2018, it was time to start thinking more about how the promised Hardcore Windows 98 series would play out. I wanted to revisit the idea of installing Windows over the network, a thing I tried once in Windows 95 only for it to go haywire as a result of some bad BIOS settings and using the wrong drivers for some cards. That's something I pulled off back in 2015, but given how much of a mess it was, I didn't think much of the idea until something struck me... hey, maybe PXE could come into play?
Installing Windows 95 using a Network Client Startup Disk
I gave it a spin on January 2nd, 2018, after configuring TFTP and PXELINUX in such a way where I could pick whatever floppy image I needed to boot from on any particular system. The first thing I turned to was a premade solution on some other website. It worked, but it was not versatile enough; it could only be used with FAT16 partitions, and the amount of steps I had to go through made it more cumbersome than I would've liked it to be. I ended up devising my own routine immediately after, using a boot disk generated by Windows NT's Network Client Administrator as a starting point.
I made my first attempt to install Windows 98SE without copying cabinet files to a local hard disk the following day, using a 3Com 3C905C network adapter integrated into a Toshiba NetDock station for my Tecra 8100. It was going well for a while until I reached a dead end where the network could not be reached in a later stage of Setup. Clearly, the driver this adapter would need was too new for what Windows 98SE could've possibly included. At the very least, I got somewhere with it, and I suppose if I had just stuck to an ISA network card in some desktop I wouldn't have needed to worry about anything more.
Integrating New Drivers!
So that didn't quite produce the results I needed, but shortly after, I found a rather intriguing program on the Windows 98 setup CD called INF Installer. There wasn't all that much documentation about that program on the internet, but for what all I did read into it, it's supposed to automatically add new drivers to a writable Windows 98 setup directory, which could be a network share or a template for a new CD-ROM. That might just be the answer to all of my problems with installing fresh new copies of Windows...
A few weeks later, I got some of the new drivers loaded into the network share. Now it was time to see if this program was all it had promised to be... sure enough, drivers for a 3dfx Voodoo3, an Intel PRO/1000 MT network card, and VIA AC'97 onboard audio were all set to go right out of the box, just as if Windows 98 had been installed on all 1997 hardware. It was at that point that I knew I had something special, something nobody had seen on YouTube before, something that could be revolutionary for saving so much time on deploying legacy computers. Little did I know that as this new approach continued to evolve, it would completely change my outlook of Windows 98 forever.
I could've left it at that, but I wasn't really satisfied with the results I got. Another run was conducted on February 11th with small additions, but I ended up setting aside the operation for some time as there were other things I wanted to tend to.
I returned to the operation again on May 21st, and this time I was willing to show off a lot more with the equipment I acquired in the time gap. I picked up more of the same network card, which helped to make mass deployment much easier. The operation was largely a success, but that run would end up being scrapped from the upcoming video series due to another "little" project beginning production on June 25th: Arowana!
Rather than being squarely focused on Windows 98, this project would use network installations to deploy eight different versions of Windows. Later versions of Windows had greatly improved official deployment customization tools, but Windows 95 and NT4 still required a lot of manual work, the former due to Windows 98's INF installer demanding to be used with a Windows 98 setup directory. Windows 95 had an INF installer too, but it was hardly useful; at best, it was only something that did what it would've been expected to do when you integrated Service Pack 1 or some networking software using clunky Server-Based Setup tools found on the resource kit or certain Windows 95 CDs.
Still, Arowana provided a deeper background into installing Windows over LAN, and it helped that Windows 95 was more forgiving when it came to not having a new network driver handy, for it would happily fall back to an existing DOS-based NDIS2 driver if need be. With the bulk of that out of the way, a new deployment run of Windows 98 to six computers over LAN would be conducted on September 17th, which turned out mostly successful with a number of hiccups. I did find out that enabling "PnP OS Installed" in the BIOS settings was a bad idea no matter what, as it botched device detection on some systems which had it enabled.
All Eyes on Windows 95
So, Windows 95 and 98 are fairly similar underneath the surface, so why can't Windows 95 get the same treatment? After having finished every segment of Hardcore Windows 98, I was now free to focus on something more archaic, and see what I could do with it. Around January 21st, 2019, I undertook the task of getting a network driver integrated into Windows 95 Setup, using some extremely obscure INF file that ended up in a web file index and the Windows 95 Resource Kit for reference.
It was mainly a matter of appending to the setup batch script generated by Windows Batch Setup under the [Install] section; the setup program needs to be told to copy additional INF files to \WINDOWS\INF. This directory is full of driver information files, and is the first thing Windows refers to when it detects new hardware. The new corresponding driver files were stored by themselves inside the same Windows 95 setup directory.
That worked out well enough, but I was bound to run into yet more hurdles, and with no reference to refer to anywhere, I was forced to isolate any faults I could on my own, leading to a number of incorrect speculations along the way. At least the driver integration thing was sorted out, but Windows 95 is still ill-equipped to run some newer software without the help of updates... could something be done about that?
For sure! On March 3rd, I successfully created a batch file that could bring a FAT16 partition on a 500MHz computer from being empty to having Windows 95A loaded with DCOM95, OpenGL, DirectX 7, Dial-Up Networking 1.4, and all the drivers I needed on the target system in just seven minutes. Now I was really onto something here, as I managed to pull off something I hadn't really ever done when I was automating Windows 98 Setup!
If you know how Windows 9x Setup works, it displays this dialog in the second half that indicates what task is currently being carried out at the moment, whether it be converting program groups, asking you to specify a time zone, or whatever may be. These are all laid out by a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\Setup. More programs can be executed inside the RunOnce key on its own, but RunOnce\Setup takes precedence and displays a descriptive list of items. An entry specified in MSBATCH.INF would look something like this:
[Install] AddReg=RunOnce [RunOnce] HKLM,"%RunOnceSetup%","DCOM95 Update",,"\\BELUGY\UPDATES\DCOM95.EXE /R:N /Q:U" [Strings] RunOnceSetup="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\Setup"
As can be inferred, %RunOnceSetup% is used as a shorthand for the full path defined in the [Strings] section. This is not only a convenience, but also a very important space saving technique when you're dealing with large INF files. Because Windows 95 uses a 16-bit setup engine, INF files can only be as large as 64KB, sometimes less. The registry entry also assumes the client will have network access at an early stage. If it cannot, DCOM95.EXE needs to be copied to a local directory ahead of time and executed there.
I've been wanting to make a written INF tutorial for this site for a long time, but haven't made room for that at the moment. The important thing to know is that I was starting to gain a lot more control over Windows 95's setup process at this point. Of course, to take better advantage of later hardware, this process would have to be replicated for OSR2, and adjusted to allow for installing the USB supplement as well. The next day, I got that all worked out. Now, I could go from an empty FAT32 partition to having full AGP support and running GLQuake in just ten minutes! Sometimes you have to do some guesswork as to whether certain programs should be run in RunOnce or RunOnce\Setup; the USB supplement had to go in the former. In any case, batch setup is not officially supported in Windows 95 OSR2, but it works just as well there.
Gettin' Spicy
Just as the functions of Windows Setup can be changed, so too can the cosmetics. Adding visuals to Windows 95 Setup is not really useful in any way and I've moved away from that later on, but I figure it's worth sharing the details regardless.
Of course I've already explained how one can add color to a monochrome bitmap, which is exactly what the Windows 95 setup program uses to minimize space usage while still providing some flavor. The bitmap is stored in WINSETUP.BIN and can be overwritten with eXeScope or a hex editor with the following starting/ending offsets:
- Windows 95A: 1D6F0 to 26CF0
- Windows 95B/C: 1D830 to 26E40
With all that in mind, I was able to give Windows 95 a setup wallpaper that would more accurately reflect all the new stuff it was being geared towards on March 31st. I would end up trying to do the same with Windows 98, but because that setup program insists on loading a dull, 50% gray blue background in 16 color mode, I turned to splicing a generic high color VGA driver in MINI.CAB, then used VBEMP for the second half of Setup. This would prod Setup into loading the actual SUBACK.BIN bitmap image (and yes, this time around it is nothing more than a standalone BMP file, which can be any resolution and any color depth). These two things would be accomplished the following day, but not without strange side effects. I would advise against trying this yourself if you do not want Setup to become unusable.
Of course, you don't want to be reckless with this, either. Having the VBEMP driver overwrite the default VGA.DRV driver WILL cause Windows to fail to load USER.EXE, which spells death for the installation. The safest approach is to tell SYSTEM.INI to point to VBEMP.DRV as is, without overwriting critical system files. This all can be accomplished by adding these lines starting at the [Install] section in a Windows 98 batch setup file:
[Install] UpdateInis=Vbemp.IniUpdate CopyFiles=Vbemp.Copy [SourceDisksNames] 201="CustomFiles",,0 [SourceDisksFiles] VBEMP.DRV = 201 [DestinationDirs] Vbemp.Copy = 11 ; typically \WINDOWS\SYSTEM [Vbemp.Copy] VBEMP.DRV [Vbemp.IniUpdate] %25%\system.ini,boot,,"display.drv=vbemp.drv"
%25% is a symbol for an LDID value. LDID values are regularly used in INFs, and allow the setup engine to be more versatile so as to always point to the correct instance of the user's SYSTEM directory just in case it is not inside the usual C:\WINDOWS. A list of LDID values can be found in the Windows 95/98 resource kits, the former which exists on certain Windows 95 setup CDs in the form of WinHelp files.
More! MORE!!!
But perhaps some aesthetics are needed to really turn up the SICK factor on this endeavor. We've got the updates, we've got the drivers... but there's something else that many Windows 95 users would like to have installed, but perhaps not want to go through the trouble of installing themselves. It's a little something that really gives Windows 95 that slice of life. What am I talking about here now? Of course, Microsoft Plus!!
Of all the Windows companion packages that have been released, the one for Windows 95 is perhaps the most useful. It comes with new high color icons and other subtle visual enhancements (dragging windows without outlines, yeah!), desktop themes, a task scheduler, a dial-up server, improved drive compression, and a task scheduler. Of course, only some of these are really of use today, but who can't get enough of that golden, futuristic More Windows theme? I set off to figure out how to integrate high color icons and desktop themes into Windows 95's setup process.
So comes July 5th... by this point, the methodology to expanding Windows 95's setup process had grown a lot more complex. An entire separate batch script was introduced as a workaround against an issue where executing an INF via RunOnce itself causes the whole thing to get stuck in an infinite loop. At the same time, I was able to get away with applying more discrete updates like the fast CPU fix for Windows 95. It was only a matter of plopping all the applicable files for 95A in the setup directory, didn't even need to modify any INFs! The same cannot necessarily be said of 95B since NTKERN.VXD comes from the USB supplement, so the installation package for that has to be reworked, of course.
The following day, I had a new routine all set up, employing the START /W command regularly in the post-Setup batch script. At this stage it was still pretty rocky since sound components refused to install with a PCI sound card, some new fonts hadn't been explicitly registered, and I did hit a BSOD, but I was really starting to get somewhere now.
But how exactly did I get something like Microsoft Plus integrated? How did I figure out which registry values I'm supposed to add? When I got started with that earlier on July 3rd (or maybe it could have been the month before when it was all in MSBATCH.INF, I don't remember off hand), I started off with something relatively simple - just add the visual enhancements, being high color desktop icons and the extra display properties tab. This does require setting a lot of new registry values, and the way I ended up finding them was by brute force, searching the whole registry on a clean installation with only a minimal Plus installation. However, these values are clearly defined in PLUS.STF on the setup CD if you're willing to go through 120KB worth of text. I've saved you the trouble by posting VISUAL.INF here in case you want to experiment with it.
So that should bring it on the level of Windows NT 4.0 and some early Memphis builds! You can see how all of that came together in the video linked below.
More Windows 95 Setup Automation
Less Handlebars
Whew! When I got started with tweaking Windows 9x Setup all the way back at the beginning of 2018, I didn't envision I would be continuing to evolve my approach for this long, but here we are!
Windows 95A: Show Me What You're Made Of
On July 11th, it was time to show the world what I had managed to pull off over the last few months, after significant interest had been garnered over giving Windows NT 4.0 the same treatment to a lesser degree. Could so many of the essentials for Windows 95 really be installed hands-free? See for yourself in the linked video below...
Windows 95A Unattended Setup on Pentium Computer with ST32550N SCSI Hard Drive
There it was, a full-fledged installation of Windows 95A that came with everything one could ask for in roughly 20 minutes on a classic 200MHz Pentium. Imagine that! With all the new stuff that was automatically being crammed in there, well... I was starting to question if using Windows 98 was still worth it. It comes with a lot of everything that was loaded in this video and more in a vanilla installation, but is that really something I'd want anymore when I can get much of that AND a leaner Explorer interface?
Regardless, there was still something yet to be addressed. Partitioning and formatting the hard disk was still a manual process, and sooner or later that would have to change as well.
Windows 95B: Powered by Linux!
What exactly was the best way to partition and format a FAT16 or FAT32 partition automatically, and complete both in less than a minute for that matter? FDISK includes some hidden switches that allow you to perform an operation on a partition table non-interactively, but you still have to run a full format on them. Third party partitioning programs for MS-DOS do exist, but how can I be sure of which one I'd need for a hands-free installation? Is there even any such thing?
I ended up turning to a Linux Gazette article from 1999 for inspiration. As described in the article, some shell script and a number of GNU utilities used non-interactively helped a health provider in Texas replace over 2,000 486-based computers running MS-DOS with significantly more powerful Pentium-powered machines running Windows NT Workstation 4.0. Ths process was mainly designed to address a problem with deploying Windows NT on NTFS partitions of varying sizes as the custom routine deploys that operating system rapidly.
Still, if it could be done with an operating system as stubborn as Windows NT using solutions from two decades ago, it definitely could be done now with Windows 95. Initially I tried stripping down FreeBSD to a size that would be small enough to fit in any typical vintage computer's memory, but the elaborate effort required for that wasn't worth wasting so much time on, even if it had potential to be lighter in the end. I ended up going with Tiny Core Linux as a foundation for what would end up being an early incarnation of Hierma.
The process I devised took four days to complete after numerous failed attempts, many of which stem from the fundamental differences between DOS and Linux. Eventually I figured out that in order to get it to run all the way to the first login to the desktop, a stripped down 360KB boot image of MS-DOS 6.22 or Windows 95B would have to be loaded by a local installation of SYSLINUX with MEMDISK, and that boot image would be responsible for automatically rewriting the boot sector in a way that Windows 95 likes.
To ensure the script would complete successfully on a system with only 64MB of RAM (that is, Pentium 1-based systems), I had to do something a little crafty where I wouldn't have most of the Tiny Core extensions integrated upfront, rather they would be downloaded via TFTP and installed at that point. It seemed to cooperate with that solution.
The new script also retrieved a simple plain text database on the server to get information about which operating system to install, which partition format to use, and what hostname to use for the computer, all based on the MAC address the network card has. It was awesome being able to go from a totally empty disk to a well-updated Windows 95B installation with all the drivers, and I even extended the script's reach to Windows NT later on, much like the original article explained. You can see exactly how that works in the video linked below.
Windows 95B Unattended Installation on Athlon and P3 Tualatin with Voodoo3, SCSI
Windows 95C: Closing Up the Gaps
Even with all of that, there were still a number of small hurdles I needed to get past, like avoiding the password confirmation dialog. I already automated half of the logon process by assigning a temporary username and password to use during the setup routine, and it just so happens that autologon function was sourced from Tweak UI of all things. What if logging on could be bypassed altogether?
It turns out there's a pretty straightforward solution to disabling logons even when a network card is installed, and it amounts to a DWORD value in the registry. Basically, under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Network\Real Mode Net, AutoLogon must be set to 0. Some OEMs used this in their own restoration routines, and a number of sites back then used that to show users how to "get rid of that annoying logon prompt, never have to click Cancel again!"
Of course, when that registry value is set, network shares are no longer accessible, and so one must turn to the old-fashioned style of copying Setup files to the local hard disk. This shouldn't really be a problem given how spacious they all are, unless of course you're wanting to install Quake III Arena right from the start as well. Doesn't that have some long filenames as well? No matter! An FTP client can be loaded to copy all the required files to a hard disk, which, in fact, is faster than directly accessing the setup files over the network from MS-DOS.
Normally, Windows 95C would try to install Internet Explorer 4, but of course I stripped that out because it's ugly, so it is more or less the same Windows 95B, just with a standard-issue memory management bugfix. Either way, FINALLY it was possible to install Windows 95 hands-free with everything I wanted! But it's not like it could just fit everyone else's needs... so I spent two more months reworking Hierma into a full-blown interactive set of scripts in the hopes that it would be usable for anyone.
Unfortunately, Hierma never really took off since at that point it was consuming too much memory, had a number of other issues, and was never used by anyone, anyway. There was another way to go about with everything, though...
Windows 95C Automated Network Setup Voodoo4 Voodoo5 Quake III 1v1
A Diversion
As I was just about ready to record a video depicting the automated installation of Windows 95C on August 7th, some forgotten function in Memphis build 1387 was unearthed by Blue Horizon, creator of the Blue OS Museum. It turns out that gradient title bars existed well before build 1400, all without the new IE shell at that. The feature was just really hard to find because of how strangely it was implemented, and the fact that it wasn't enabled by default. This ended up opening the floodgates to a whole bunch of ideas.
What if this functionality could be backported to Windows 95? Well, could it? Considering the two are hardly far apart at that stage, it may just be as simple as backporting a number of system files. To our delight, it worked, and I wanted to combine this with my knowledge in integrating updates to create Windows 95D, with the intent of having it be a step up from the official Windows 95 releases. For a while, it seemed to be quite promising, but as development progressed, it was proving to be a house of cards, and I couldn't sustain it anymore. Development was immediately abandoned on December 30th when the first and only release of Windows 95D was published. More details about how that went can be found on its own hub.
I saw that the future would have to rest in a remaster of Windows 98 with the classic Explorer in place as a modern solution to such problems often faced in dealing with old computers. Before I got started on that, though, an in-between solution was devised...
Welcome to Windows 95D Lite
There was strong potential for a new version of Windows 95 that included many useful updates right out the gate, I knew that much. With existing update rollups being unsatisfactory, I found myself compelled to make Windows 95D Lite, and pitched the idea on June 23rd, 2020, with the initial intent of cutting out unnecessary stuff found in Windows 95D while keeping its conveniences such as update integration. Three days later, I got to work on the thing, stripping out unnecessary stuff like Internet Explorer 3 and integrating a lot of the updates from the original Windows 95D.
The approach to be taken with integrating new files into Windows 95D Lite was quite different from that of the original Windows 95D. If you take a look at the file structure of the original Windows 95D, you'll see that a lot of the new stuff included is either totally uncompressed or placed in cabinets separate from the mainline WIN95_*.CAB files. In turn, you could easily strip out many of the things that make up Windows 95D and turn it back into Windows 95B.
Ripping Into the Heart of It All
Windows 95D Lite opts to rebuild the mainline cabinet set from the ground up, creating a very clean setup directory containing only a lineup of .CAB files and a few files which absolutely need to be outside of cabinets. This provides a number of significant benefits:
- More space is saved, which is very important when downloading the CD image and copying the setup contents to a hard disk
- Redundancy is eliminated, as there is no need to have a matching uncompressed file override the old one in the cabinets
- The setup directory is easier to browse for those just trying to find a program they immediately need, like FORMAT or EXTRACT
"Lite" comes from a number of things, being the elimination of said redundancy, the removal of unnecessary Memphis relics, and a much more efficient setup process that doesn't need a whole post-Setup batch script and so many RunOnce entries to install all the practical updates one would need to get going with the software they want to use right out of the gate.
There are a number of things to be mindful of when building a cabinet set for a Windows 95 installation: one, you cannot use the tighter LZX algorithm found in MAKECAB, as Windows 95 does not recognize it. MSZIP may be valid, but its compression is weak, and I would find it only suited for compressing files for Windows 3.1 and ACME installers.
The solution is to use an earlier cabinet creation utility called the Diamond Disk Layout Tool. You might be wondering why it's even called that of all things; it mainly has to do with the fact that it was designed with floppy disk sets in mind. As CD-ROMs were not as widely prevalent in 1995 as they were a few years later, software vendors like Microsoft still had to take computers without CD-ROM drives into account, and the most cost-effective way to do so was by tightly compressing the files to be used while making use of every single sector available on a formatted floppy disk. That is why those .CAB files you find in the setup directory are as small as they are. Even then, distributing Windows 95 on floppies still would've been costly if not for the 1.72 MB DMF format they introduced to cut down on the number of disks needed (and making certain things like sound schemes be CD-ROM exclusives).
Using the QUANTUM algorithm is exactly what you need to compress files as tightly as possible for Windows 95's SETUPX.DLL to be able to read. It compresses files a lot more slowly than MAKECAB, but that's the reality you have to accept to get the best results. Even then, creating the directive file for DIAMOND and building the mainline cabinet set with it is only the first step.
If you try to use the cabinets starting from PRECOPY1.CAB all the way over to WIN95_??.CAB, you're bound to run into an out of memory error. The way it's expected to be set up is that the WIN95_??.CAB files must link backward to the PRECOPY?.CAB files, but the latter cannot be forward-linked to the former. As such, you have to create a separate, stripped down directive file that rebuilds ONLY the precopy cabinets.
But if you leave the existing layout files in PRECOPY2.CAB as is without appending to them, it's gonna be impossible to install extra files even if they are in the cabinets. The setup engine is very crude and requires one or more plain text layout files to know where each file is located. You'll have to remove the original LAYOUT?.INF files when rebuilding the cabinet set and let the Diamond utility generate new layout files to be spliced into PRECOPY2.CAB right when the precopy set is being rebuilt. Since these files aren't copied in the initial cabinet set, the first directive file must also tell the program to write lines for the LAYOUT?.INF files in the layout file at the right spot.
Then, if you have too many files at once, the layout file is going to grow too large for the 16-bit setup engine to digest. You could split the layout file into two or three by hand, but that's definitely bound to grow super tedious with every rebuild. I already had a batch script responsible for handling all the steps I needed in rebuilding the cabinets, but since neither cabinet creation tool has a layout file size limiter, I had to devise an automated solution from scratch... that is, a small program of my own called LAYTSPLT. This program does not split files on its own (although it should now that I think about it), but it will read ;LAYTSTRT and ;LAYTEND comments to know where it needs to split a layout file while still writing a tad bit of common starting information all the layout files need. It's not much, but it goes a long way.
As prereleases were being trickled out, more RunOnce entries were eliminated as update packages were extracted and slipstreamed directly into the main setup procedure. As I worked my way through the updates, they became increasingly more complex to handle. DirectX 7.0a was by far the most complex of the INF-based updates due to all the separate INFs that were in the package, but all of them were small enough that I could consolidate them into a completely overwritten MSDX.INF, the INF file in PRECOPY2.CAB that was originally responsible for installing DirectX 2.0a.
As for the MSI installation engine (Windows Installer 2.0 I think), that required a ton more brute force. I could extract the exact files I needed, of course, but once again I found myself having to find all these damn things that INSTMSIA.EXE added to the registry by hand since I don't really have an easy way on hand to retrieve every single one of the registry values it sets in a directive list or something. I was able to get it chugging along in a matter of hours, though.
Now Available on CD-ROM!
To really make Windows 95D Lite a more intriguing experience all around, I wanted to replicate the original structure of the Windows 95 retail CD-ROM in my own way. While many of the original CD-ROM materials like Microsoft Exposition were cut out, I added tons of new things like the Tweak UI PowerToys, the Windows NT administration tools for Windows 95, and three different versions of Internet Explorer (as I stripped out IE3 from the base distribution except for some program dependencies like WININET.DLL). I even went through the trouble of adding several new Cinepak videos!
To really complete that CD-ROM experience, of course, I wanted to change up the Autorun program, that thing that displays the famous Clouds wallpaper with a transparent CD-ROM graphic. I was able to transform most of the program in Resource Hacker with a lot of rebranding help from TheOneGoofAli, but one thing that got me in a snag was trying to get the program to allow upgrading from something like Windows 95 RTM to 95D Lite. Autorun compares the system's version number of Windows against its own internal number, and if it's too high, some important functions are disabled. Since I wasn't able to change what I needed to change in Resource Hacker, I pulled out HxD and found that the value B6 03 00 04 (applicable to RTM's Autorun) needs to be replaced with BC 04 03 04 in both instances so as to make Autorun compare against build 1212 rather than 950.
Of course I wasn't going to stop there, as there's a number of other desirable things some users might want to spice up their experience. Can't forget about that 3D Pinball and the desktop themes from Microsoft Plus! I even held a contest in which some people could create their own themes to submit to the final release of Windows 95D Lite. I only got five themes in, but it was worth having that extra variety in there.
The Releases
First, I put out the alpha release of Windows 95D Lite on June 30th, 2020. The installation went by pretty well for some people, but IntelliPoint and color schemes weren't set up properly. A full week later, the 95D Lite "Small Beta" was released, correcting many of the alpha's problems, creating a customized boot floppy and a new readme file. "Small" means this doesn't have any of the CD-ROM extras, just the base Windows 95 distribution. The "large" beta, released on July 17th, doesn't change much apart from being better equipped to run software without the need to install IE3 or later, but starts to include many of the CD-ROM goodies.
On August 8th, greater strides were taken in getting Windows 95D Lite to take its optimal form with the delta release. This release tightly integrated more updates like DirectX 7.0a, and included a number of new drivers that could be installed immediately when the appropriate devices were detected. Driver integration seems to be where a lot of 95D Lite's more confusing Setup-related issues kicked in, as simply dropping drivers into the package can sometimes break the PnP detection process so much that no devices are actually loaded. ICH2-based chipsets seem to be notorious for doing this, much as VIA chipsets are.
Version 1.0
I decided on a final release date of August 24th, the 25th anniversary of Windows 95's original release. I was working around the clock trying to get whatever else I could throw in there, like some all new WinHelp documents, a few more drivers, and tighter integration of the MSI installation engine. I also wanted to try my own hand at creating the most full-featured desktop theme I could. Screensavers are still way out of reach for me, but eventually I had myself a theme that included not only a fancy wallpaper, color scheme, and some sounds taken from the Windows 98 Plus theme, but also custom icons and cursors created with the help of Greenfish Icon Editor Pro.
After finding myself in crunch time one day before release, I eventually got the first actual release out there. I wasn't sure if I would change 95D Lite much beyond that point, but it turned out that's exactly what I was gonna have to do on and off for the next ten months...
Version 1.1
The initial release was a lot buggier than I hoped it would be depending on the hardware it was installed to. Tons more work had yet to be done if this thing was expected to be reliable in the long run. I found that some lines in a few of the Intel chipset INFs were different from the rest, containing ExcludeFromSelect=* rather than the value being set to the specific device. Doing away with that seems to have fixed a lot of problems with device detection on later chipsets like the Intel 815E. With that resolved, tons more drivers could finally be integrated, including the VIA chipset drivers used in Super Socket 7 and Slot A motherboards.
95D Lite 1.1 also took a bold step in more tightly integrating some very low-level updates like the eXtended USB Supplement and the 3GB memory patch. Before, these patches were applied post-Setup, which had the potential for an installation to fatally crumble on certain legacy ISA systems (as Windows 95 may not require a reboot after Setup in such cases). I had to step into uncharted territory by doing away with static VxD linking, something Windows 95 normally applies. This opened the door to integrating brand new, butchered VxDs that offered the functional enhancements I'd want to have available right out of the gate. It was a matter of commenting out every single CombineVxDs line in every precopy INF so as to avoid the placebo error message "Windows was unable to combine VxDs". I wasn't sure how that would turn out, but over time, I found that there seems to be no real consequence to disabling static VxD linking! I published 95D Lite 1.1 on September 19th.
Version 1.2
Thanks to one video in particular, Version 1.2, released on October 8th, was the first popular version of Windows 95D Lite. Good thing it was that, too, as a number of necessary polishings were done to this one, like fixed up INFs, a leaner first boot procedure, a fixed FDISK program reporting partitions over 64GB correctly, and the removal of some excess branding. It's not much, but it was a fairly stable release.
Version 1.3
Even with all that I've went through trying to fix up as many bugs as I could, some people were still reporting issues with the mouse. I tried fixing up some drivers and disabling UltraDMA in the hopes that would do anything for them, but I ended up breaking a lot more than I wanted to with that. 1.3 was kind of a mess and rushed out there in the hopes that I could leave it all behind and focus on Redtoast entirely, but that new project was proving to be very rocky in itself.
Version 1.4
So, I eventually got back to fixing up Windows 95D Lite by doing all that Windows 95D lite was meant to do, but now for drivers! Many lines for Intel chipset drivers were already spliced into MACHINE.INF prior to version 1.4, but for the first time, yet more drivers were about to be more tightly integrated into the distribution, eliminating further redundancy and excess INFs by directly modifying some of the base INFs for certain drivers from vendors like S3, Matrox, Cirrus Logic, Creative, Yamaha, 3Com, and a few others. Doing this helped to greatly reduce the chances of Windows 95 Setup breaking on that trusty Tualatin test machine, and in turn allowed for yet more devices to be integrated.
Yet more firsts for 1.4 include making it useful for laptops with new PCMCIA drivers and supporting NTLMv2 logons right out of the box. Version 1.4 was released on February 1st, 2021 with great pride in all the new steps taken to make this thing more robust.
Of course, I ended up running into several more bugs pertaining to a Toshiba laptop's PCMCIA bus, so I had to get that fixed up and do yet more INF cramming. Eventually, version 1.4a was published on February 14th. In response to continued reports for broken mouse detection, I also added VMOUSE.VXD from IntelliPoint 4.0 in place of the one from 3.2 in a last ditch effort to address these reports. So far I haven't heard anything about broken mouse detection since then, so that seems to be reassuring...
Version 1.5
And now here we are again. I never thought I would be taking a whole year to get Windows 95D Lite in the most optimal state I possibly could, but once again I got to work on fixing up some things. At this point I've already gotten myself quite a bit into Redtoast's development reset, but I also wanted to address a bug regarding joystick usability in 95D Lite. It turned out to be a very simple fix, as I had installed the wrong VJOYD.VXD. I pushed out a hotfix for existing users during the wait for version 1.5.
Alongside that, I made some more necessary polishings. Support for later Matrox cards was greatly improved, IntelliPoint cursors were finally tied to the Cursors optional component, NDIS2 drivers were added for some network cards, and some unnecessary stuff was cut out from the main distribution. To further emphasize on fixing joystick-related problems, I changed up some stuff in WAVE.INF to make the joystick driver for the Sound Blaster Live work properly.
As it became clear that there wasn't much left for a drastic enhancement of Windows 95, I figured now I could be more certain that I'm ready to make 1.5 the real last version. The demand for bringing all of the conveniences of 95D Lite over to a Windows 98 distribution and more is too strong to justify continuing to maintain this little thing.
So, naturally, I ended up putting a lot of work into making a new theme for this release. Still no new screensaver, but I pulled out my old Casio ToneBank keyboard to create the sound scheme from scratch! At first I wasn't sure if it would sound all that great, but when I started applying everything into the theme, everything I recorded appears to have fit in nicely.
With that, I think I've finally managed to perfect the Windows 95 setup process. Any such bugs found now will most likely be addressed with hotfixes exclusively, at least unless there becomes so many of them that 1.6 has to be a thing. At this point, however, Redtoast is of higher priority.
Version 1.6
Version 1.6 was developed on and off over the course of the latter half of 2022 to commemorate the Windows 95 launch event and attempt to cover more hardware ground. It was initially going to be referred to as version 1.5b, particularly because I never really had intentions of pushing myself much further with Windows 95 remastering. It mainly serves to fill in a few extra gaps that had been left unchecked previously.
I had hopes of releasing this version on August 24th, but couldn't for a plentiful of reasons. At least now that it's out of the way, I do not expect any future updates to this software unless it is absolutely necessary.
The Future Lies in Redtoast
The idea for Redtoast came long before Windows 95D Lite ever started development this whole time, but Windows 95D Lite was a much needed stopgap in figuring out how to approach the Windows 98 setup files. Moreover, a lot of the work I've done for 95D Lite could easily carry over to Redtoast - all those updates I was struggling to break down before, and my layout file splitting program, to name a few. All that I needed to do now was ensure that I could actually get Windows 95's Explorer working in Windows 98 on my own, as well as strip out any sorts of undesired components. In only a couple of days, I had a partially working alpha ready to publish on August 30th, 2020.
Naturally, the bug reports starting walking in, and so I spent the next few days sorting those out and integrating a lot of new updates, including many of those from Windows 95D Lite as well as a few new essentials like NUSB. Alpha 2 released on September 4th. It worked great for systems with USB 1.1 chipsets, but USB 2.0 support was broken, as was the PnP detection routine due to a new SYSDM.CPL from Windows ME being installed.
Since Windows 98 is a clusterfuck and outlooks on it are inconsistent, I am also forced to provide freedom of choice, and so the previously stripped out Internet Explorer was added back in for Alpha 3, only this time it was version 5.5. More underlying improvements were made, like fixing USB 2.0 support and supporting SATA devices (in theory anyway, never tested it myself). This release was published on November 14th.
Still, there was quite a long way to go. The IE 5.5 reintegration as an optional component had a ton of holes, and Office 2000 failed to install completely. I did what I could to salvage the thing, and even started adding some Intel chipset drivers in. Alpha 3a was released on December 24th, but as time went on, it became clear that the working structure of Redtoast was a wreck. There was no certainty anymore over whether I could rely on what I had put together up to that point.
I told everyone that I would have to pull a Longhorn and completely reset development to the vanilla 98SE distribution, and sure enough, I started to do just that on May 3rd, 2021, coincidentally right after Bill Gates got divorced. While it's been a long time since a new Redtoast release was issued, I've put together a development miniblog that aims to keep everyone up to date on what's going on with the project whenever it is being worked on. I do think I know how to fix the Office 2000 installation troubles at this point, so now it's just a matter of getting that sorted out, optionalizing Internet Explorer once more, and bringing the whole distribution back to a state matching up with the last release. Someday, Alpha 4 will be ready to deploy!
In the meantime, there is always the more refined Windows 95D Lite still as readily available as ever to put on your Pentium II build. Thanks for helping get that into its prime!
