Why wasn’t the Windows 95 shell prototyped on Windows NT?

Carlos wonders why the Windows 95 shell was prototyped as 16-bit code running on the still-under-development 32-bit kernel, USER, and GDI as opposed to being prototyped as fully 32-bit code on Windows NT.

There were a number of reasons, some good, some bad.

One reason was that the Windows 95 shell was being developed by the Windows 95 team, which was an outgrowth of the Windows 3.1 team. That meant that they had Windows 3.1-class hardware. And the hardware requirements of Windows NT were significantly higher than the hardware requirements of Windows 3.1. Here's a table for comparison:

Platform RAM
Minimum Recommended
Windows 3.1 2MB 4MB
Windows NT 3.1 12MB 16MB
Windows 95 4MB 8MB

The Windows 3.1 team adhered to the principle that the team members' machines, as a general rule, were as powerful as the recommended hardware requirements. If you asked really nicely, you were permitted to exceed that, but not by too much, with one notable exception. Think of it as performance dogfood. If Windows was unusable on the stated recommended hardware requirements, the entire team felt it because that's what they were running. (When Windows 95 shipped, my primary machine was a 486/DX50 with 8MB of RAM. My test machine was a 386 with 4MB of RAM. The combined computing power and storage capacity of all the machines in my office is now exceeded by your cell phone.)

Okay, so you just finished Windows 3.1, and all of the team members currently have 4MB machines, with a few lucky people that have a whopping 8MB of RAM. If you decided to do your prototype work on Windows NT, that would mean tripling the amount of memory in most of the computers just to meet the minimum requirements for Windows NT. And you can't say that "Well, you would have had to pay for all that RAM anyway," because look at that chart: Windows 95's final hardware requirements were still lower than Windows NT's minimum!

Spending all that money to upgrade the computers for something that was just a temporary situation anyway seemed like a bad way of spending your hardware budget.

From the software development side, prototyping the new shell on Windows NT was not practical because Windows 95 introduced a whole bunch of new features to Win32, features which didn't exist in Windows NT. Part of the goal of the prototype was to exercise these new features, things we take for granted nowadays like Register­Class­Ex and WM_MOVING and the Close button in the upper right corner. Those features didn't exist in Windows NT; if you wanted to develop the prototype on Windows NT, somebody would have had to port them and build a special "throwaway" version of Windows NT for the Windows 95 team to use. That means devoting some people to learning a whole new code base and development environment (and buying lots more hardware) to add features that they had no intention of shipping.

It was much more cost-effective to do the prototyping of the Windows 95 shell on Windows 95. You could see if a design led to poor performance and deal with it before things went too far in the wrong direction. You could use those fancy new functions in kernel, USER, and GDI, which is great because that meant that you would start finding bugs in those fancy new functions, you would start finding design flaws in those fancy new functions. If the shell team needed a new feature from the window manager or the kernel, they could just ask for it, and then they could start using it and file bugs when it didn't work the way they wanted. All the effort was for real. Nothing was being thrown away except for the stuff inside #ifdef WIN16 blocks, which was kept to a minimum.

All through the shell prototyping effort, the code was compiled both with and without #define WIN16, and as the kernel team worked on supporting 32-bit processes, they had this program sitting there waiting to go that they could try out. And not some dorky Hello world program but a real program that does interesting things. (They couldn't use any of the Windows NT built-in programs because those were Unicode-based, and Windows 95 didn't support Unicode.)

Maybe those were bad reasons, but that was the thinking.

Comments (21)
  1. BC_Programmer says:

    And then the NT folks got jealous so we got the Shell Desktop Update for Windows NT 3.51, which later became Windows NT4 and brought much of the two systems (9x/NT) together as the baby steps towards the merged consumer/professional codebase that MS would work towards with XP.

  2. kinokijuf says:

    @BC_Programmer: I tend to think of Windows 2000 as THE merged consumer/professional database. Look at the features it introduced to NT that were already in 9x. ACPI. Plug and Play. Support for >8GB system partion. FAT32. USB. Failsafe mode. Also, it was the first NT system that was secure by default and not just „secur-able” (NT4 gave Everyone full control over Program Files!).

  3. Guest says:

    Hmm….the Shell Technology Preview (NewShell Beta 1) and Shell Technology Preview Update (NewShell Beta 2) :-)

  4. Joshua says:

    (They couldn't use any of the Windows NT built-in programs because those were Unicode-based, and Windows 95 didn't support Unicode.)

    Considering that FreeCell from NT 3.? works under Win32s, I'm surprised it didn't work on Win95.

  5. Dave Bacher says:

    The practice of developers having under-powered or at recommended spec machines used to be quite common; at one place that I worked for a while, developers received hand-me-downs from the other departments.  

    In order to compensate for the fact that it could take hours or days to compile, we had build servers and you just commandeered a build server for a couple minutes to build and test your software.  The actual editing part (laying out Windows/screens, etc.) doesn't really need ultra-fast computers, if the projects are modular enough.

    That having been said, the "scale it up" combined with truncation in various spots in Windows 32 CP/M edition — often caused by third party code that wasn't Microsoft's fault — led to all sorts of interesting problems when you needed Win32 code to work on both NT and 95.  

    Also, on a performance note, on lower end machines, try replacing whatever virus scanner is installed with MSSE.  Just did that for the 3rd machine that was brought to me with performance issues in the last week, and all 3 (people's personal machines) have had marked improvements.  In this last case, it was taking between 5.5 and 6 hours (I was only checking every 30 minutes) to get from the Windows login screen to the desktop.  After removing the other virus scanner (a 2011 edition of a "use-at-home" license of a major commercial product), and installing MSSE, it's 12 seconds.  

  6. jon says:

    That practice can back-fire though – I remember a bug in Windows we encountered that only occurred with multiple monitors. When we reported it the "explanation" was that the team in question only had single monitor systems!

  7. Joe says:

    @jon: That exact problem was what convinced the powers-that-be to get me 2 monitors. I was the coolest coder in codertown!

  8. > When Windows 95 shipped, my primary machine was a 486/DX50 with 8MB of RAM

    Stunned. I remember being aghast in Sept '95 when I was given a new machine with only 8MB of RAM running W95. Everyone knew you really needed 16MB. I'm amazed the dev team were able to ship something while running sub-par hardware.

    [Windows 95 ran quite well in 8MB. My guess is that OEM shovelware is what made the machines unusably slow. On the development team, we obviously didn't have any of that OEM shovelware crap on our machines because the OEMs weren't shipping Windows 95 yet! -Raymond]
  9. Csaboka says:

    @rbirkby: I agree. I've first used Win95 on my 386 with 4MB of RAM, and it wasn't anything pleasant — it took several minutes to get to the desktop, and that's without counting the DOS boot. It was easy enough to convince it not to boot right away, though, but stop at the DOS command line, so you could use your DOS stuff as usual and start it with win.com when you wanted to use Windows programs.

    I remember how I followed a walkthrough in a computer magazine that taught you how to change win.com to return to the DOS prompt instead of staying at the "It's safe to shut down your computer now" screen. With the previously mentioned DOS prompt trick, it let you use Win95 like Win 3.1 worked, starting and quitting from the graphical shell at will. We've definitely come a long way since then — I don't want to drop back to a pure command-line interface ever since WinXP.

  10. Joshua says:

    [Windows 95 ran quite well in 8MB. My guess is that OEM shovelware is what made the machines unusably slow. On the development team, we obviously didn't have any of that OEM shovelware crap on our machines because the OEMs weren't shipping Windows 95 yet! -Raymond]

    My testing in VMs indicated that 17mb was the smallest amount at which it did not page.

    Considering I was able to run Word 2000 on a Win95 box with 16mb comfortably (Excel had a little trouble) indicates that paging is not really a good indicator.

  11. I remember a horror story from a team that did not follow the rule of developers using recommended hardware requirements (or maybe they did, but it was a server product, and two-CPU systems were already common is servers):

    The test team reported a hang, where the system would not ever do anything. Many testers could reproduce it, but none of the developers had this bug. After investigation, it turned out the system created a "thread pool" of size (cpu-count – 1). And no developer had a single-CPU system to find the problem.

  12. xpclient says:

    The first computer I owned at home (before that I had used Windows at my school since WfW 3.0 and NT 3.1) was a Pentium MMX, 16 MB EDO RAM, 1 GB Quantum Fireball HDD, Cirrus Logic graphics with 1 MB memory and sound card capable of 16-bit sampling. Windows 95 and Office 95 flew on it, until I installed the Desktop Update years later which made it grindingly slow. I wish the Shell team still did "Desktop Updates" though. Plenty of things in Vista/7's shells need fixing. The shell is really the most poorly done component of NT 6.x (tons of removed and broken features thanks to Longhorn I think).

    Btw I love such nostalgia inducing posts. But no mention of the NewShell CTPs for NT and why they were created? Wasn't NewShell whisked away from the NT team to Brad Silverberg's team?

  13. Anonymous Coward says:

    I think those were excellent reasons, and I think I'm willing to go one step further, although that clearly wasn't doable back then…

    If you are developing desktop software right now, your developers should test on ten year old hardware. (Still test on modern hardware though.)

  14. Raphael says:


    There was also the cool trick of replacing vmm32.vxd or krnl386.exe (or something like that) with command.com. That would give you a command line were the Windows drivers (notably long file names and cache) would already be running.

  15. Yuhong Bao says:

    You can also put command.com inside winstart.bat.

  16. Dave says:

    Platform RAM

    Minimum Recommended

    Windows NT 3.1 12MB 16MB

    Ugh, I remember NT 3.1's "minimum 12 MB RAM".  Our (at the time) maximum-capacity machine had 8MB of RAM.  We tried to install NT 3.1 on it and it said "I need 12MB in order to install" and wouldn't go any further.  After some searching and eventually stripping down a spare server, we got it up to 12MB.  Halfway through the install it said "When I said I needed 12MB what I really meant was that I need 16MB and not 12MB" and wouldn't go any further.  Grrr….

  17. Terry A Davis says:

    LoseThos doesn't work well with 256Meg.  You really need 512 Meg or more.  This should absolutely not be a problem, since all 64-bit machines have more than this.

  18. 640k says:

    At my first employer i didn't have large enough disk to compile the whole source code, I had to copy obj-files from other team members.

    Thankfully that company doesn't exist any more. Now I work on the fastest computer money can buy, updated about twice a year. And boy am i more productive (with raided ssds, 3x monitors, …).

  19. Stephen Eilert says:

    The first machine I used Win95 on was a 486DX4-100, with 8MB RAM.

    Then one of the memory sticks failed and it wouldn't boot. It appears that Win95 had to use a different (kernel/HAL/whatever) on low memory machines.

    After reinstalling, the system worked fine. I even opened to .AVI files at the same time (!!!) to demonstrate how smoothly everything ran.

  20. laonianren says:

    Thanks for the answer.

    — The commenter formerly known as carlos/Carlos (and changed because there was another one).

  21. Neil says:

    Windows 95 may have needed 17MB to avoid paging, but a bare Windows 95 would start up in 4MB without continually paging. (Once you started adding useful stuff such as networking or running applications you needed 8MB).

    I guess my Windows 95 has acquired crap on it, because I currently only have 34MB of 128MB free physical memory.

Comments are closed.