For a brief period, Windows 95 could run Windows 3.1 in a virtual machine

As the Windows 95 project started to come together, I was approached to undertake a special project: Run Windows 3.1 in an MS-DOS virtual machine inside Windows 95.

This was the ultimate in backward compatibility, along multiple axes.

First of all, it was a demonstration of Windows 95's backward compatibility by showing that it could even use an emulated MS-DOS virtual machine to run the operating system it was designed to replace.

Second, it was the ultimate backward compatibility ripcord. If you had a program that simply wouldn't work with Windows 95 for whatever reason, you could fire up a copy of Windows 3.1 in a virtual machine and run the program there.

To use it, you installed Windows 3.1 and Windows 95 into separate directories, and then made a few edits to the Windows 3.1 SYSTEM.INI file to replace the mouse and serial drivers with special versions. There were some other preparatory steps that had to be done, but eventually you got to the point where you could double-click the Windows 3.1 icon, and up came Windows 3.1 in an MS-DOS virtual machine.

Although you could in theory run Windows 3.1 in a window, the experience was pretty bad in practice for a variety of reasons. Computer systems of that era simply didn't have the computing horsepower to render the video fast enough. And you wanted keyboard hotkeys like Alt+Tab to switch among your Windows 3.1 windows, rather than treating Windows 3.1 as one giant program to be switched into or out of.

Running Windows 3.1 as a program inside Windows 95 served as a convincing technology demonstration, but the feature was cut shortly after it came together.

One reason is that running old programs in a virtual machine doesn't necessarily create a good user experience. There was no integration between Windows 3.1 and Windows 95. If you copied something to the Windows 3.1 clipboard and then switched back to Windows 95, then tried to paste from the clipboard, you didn't get what you copied from Windows 3.1, because Windows 3.1 and Windows 95 had separate clipboards. Similarly, if you had a Word document with a live link to an Excel spreadsheet, and you opened the Word document in Windows 3.1 but the Excel spreadsheet in Windows 95, not only did the live link not work, but the copy of Word running in Windows 3.1 would get a file sharing violation when it tried to access the Excel spreadsheet, resulting in confusing error messages. Because even though they ran in separate virtual machines, they shared a file system.

But perhaps the biggest reason for the feature to be cut was that its presence would undermine the compatibility story of Windows 95. Windows 95 was intended to be maximally backward compatible with all your Windows 3.1 programs. The compatibility would be so great you would never turn back. If there were this "Run Windows 3.1 in an MS-DOS virtual machine" feature, it would be an admission that we failed: We gave you a way to turn back.

Somebody managed to dig up this unfinished feature from a leaked build, so you can see what failure looks like. (The feature didn't make it very far past the science project phase, so don't expect to be impressed by the user experience.)

Comments (26)

  1. kantos says:

    And yet this was resurrected as the ill-fated XP-Mode later on. But I’m guessing that most people didn’t think about that at the time and most of these problems were solved by the fact that it did share a clipboard IIRC and had separate filesystems.

    1. Joshua says:

      Another department used XP mode for awhile, but that was to get this 16 bit development program to work on 64 bit machines. It was something about 32 bit drivers not being available.

    2. Entegy says:

      XP Mode did its job, and by then, personal computers had enough horsepower to run virtual machines, and things like guest additions allowed shared resources between host and guest. Remote Desktop was also invented and XP Mode used some RDP trickery to make apps running in XP Mode more seamless. This stuff just wasn’t available for Windows 95.

  2. BZ says:

    Was performance not an issue with this virtualized Windows 3.1? I mean we’re talking about a machine with 4 MB RAM running two OSs. Also, considering that many DOS applications needed rebooting into DOS to run properly, it’s amazing that Windows 3.1, probably the most complicated DOS app out there, could run within Windows 95. I remember in the days of DOSEMU running Windows was very difficult and certainly 386 enhanced mode wouldn’t work.

    1. cheong00 says:

      I think at time about Win95, the typical memory is around 8 – 32MB (my Win3.1 box has 4MB only. And because it’s for demo, you’d imagine Microsoft will run it on a better machine). Giving half of the memory of main system will allow Win3.1 to run with the recommended amount of memory.

      1. Yuhong Bao says:

        The amount of extra memory used should be less than to run Windows 3.1 in standard mode, so ~1MB should be enough for something that runs only program manager and file manager. And this would have been important in the era when 4Mbit DRAM chips was stuck at ~$12-14 for years.

  3. Mikko says:

    But perhaps the biggest reason for the feature to be cut was that its presence would undermine the compatibility story of Windows 95. Windows 95 was intended to be maximally backward compatible with all your Windows 3.1 programs. The compatibility would be so great you would never turn back. If there were this “Run Windows 3.1 in an MS-DOS virtual machine” feature, it would be an admission that we failed: We gave you a way to turn back.

    The story of OS/2.

    1. Alex Cohn says:

      OS/2 did run Win 3.1programs in a virtual machine, and supported clipboard sharing. There even was a ‘seamless’ mode, where Win 3.1 16-bit windows coexisted with the 32-bit desktop.

    2. Yuhong Bao says:

      The OS/2 2.0 debacle was more complex than that though. That being said, one of the well-known problems with running Win16 programs directly in Win9x was the Win16Mutex.

  4. florian says:

    Oh I could stare at these screenshots all day … what timeless designs, both Windows 3.1 and Windows 95, and all these wonderful, unforgettable icons … Windows is part of my life. A good part!

  5. IanBoyd says:

    In a someone related vein, there is a guy who is writing an emulator that lets you run 16-bit Windows applications on modern Windows. You rename your 16-bit application to MyApp.exe16, and his application is registered to handle the the extension.

    He virtually loads the 16-bit image, and maps all the imports to stub functions that turn around and call the real WinApi functions:

    – MessageBox
    – CreateWindow
    – etc

    The program, written in C#, is a 16-bit processor emulator. When it needs to call various API functions, they are translated to the full (64-bit) version by his Windows-on-Windows layer.

    [Why I’m writing a Windows 3 Emulator](

    1. kantos says:

      I honestly don’t think you need to even do that, if you wrote something that redirected the calls to a translation DLL that mapped the 32bit handle to a fake HANDLE for 16bit you’d probably be (mostly) fine. IIRC 16bit code will run fine in 32bit mode the main issue is just the OS primitives you’d have to translate for. That said there are probably also about a million backwards compatibility bugs you’d have to emulate too… like people using LoadLibrary and GetProcAddress to get undocumented functions. But in theory…. it could work.

    2. Hi, as an alternative you could try Wine, I have some old 16-bit Windows programs I need to run for customers, like Visual Foxpro, I run them in Wine on my 64-bit Ubuntu 18.04. Wine nowadays can run all the 16-bit programs I’ve tried.

      1. Reziac says:

        But not WinAmp 2.9x, the main thing I would really like to run in WINE (none of the near-misses cuts it for me). At least I can’t get it to work.

        Meanwhile, I still use some designed-for-Win3.0 software on XP with no difficulty.

        1. Scarlet Manuka says:

          For my important 16-bit apps (OK, games) that finally stopped working acceptably on Windows 10, I’m just using a VM running XP – I’d previously tried one running Win98 (low resources!), but that was a hassle due to things like Win98 not understanding NTFS, for example. XP seems to be a good compromise between “modern enough to be useful” and “old enough so that my old games run properly”. (And I had an XP CD lying around.) I have disabled the network adapter on the VM so it can’t see any network, though.

          I did have to use XP Mode for a while at work when we upgraded to Win 7. Eventually the software we had to use it for was updated, piece by piece, and then we didn’t have to use it any more. But it was essential during that period.

          1. Joshua says:

            I have to admit my choice would have been 3.1 VM.

  6. Yukkuri says:

    I love Windows 95 stories!

    1. Me, too! I have so many fond memories of Window 9x.

  7. Dosfreak says:

    For those wanting to run Windows 3.1 in Windows 95 you can use DOSBox 0.74. As long as you have IE4 w/ Active Desktop loaded then DOSBox will work and 3.1 even in enhanced mode will work fine. For share support make sure you install DOS and 3.1 on an image.

    Recently I’ve been working on improving the Windows host support of DOSBox. Among other things I’ve removed the Active Desktop requirement so you can use DOSBox on NT 3.50, NT3.51, 95 (without Active Desktop), NT4 (without Active Desktop). So if you want compatibility you’ve got it:

    Another project is BoxedWine:

    Boxedwine’s goal is to be to Win 3.1/95/98 games as DosBox is to DOS games.

  8. I’m surprised that the “mini Windows” environment used for Windows 95 setup and drive compression management tasks wasn’t also used for this…had this feature made it, of course.

    1. BZ says:

      Wasn’t mini-Windows only introduced with OSR2? As I remember it, the original Windows 95 was using text mode for maintenance.

      1. Yuhong Bao says:

        I don’t think that is true.

  9. Sometimes, you can’t keep your cake and eat it too. That’s true about virtual machines too.

    By the way, I don’t seem to be able to write a multi-paragraph comment in this blog anymore. I used to be able to.

  10. Klimax says:

    Looks like Compression API ( might work, because it has support for MSZIP. No idea how large difference from regular ZIP is.

  11. Julius Schwartzenberg says:

    I was recently trying this as well. Some limitations I found:
    – it only runs Windows 3.1 in standard mode, not in enhanced mode
    – DOS boxes do not work
    The executable used for this also works in DOSEMU and then it has the same limitations. The included mouse driver appears to be a generic int33 mouse driver, at least it also works in DOSEMU.

    I guess the comparison would also have been made to OS/2 at the time which ran Windows 3.1 in a more integrated way. This would not look so good in comparison then. It would probably have been a significant effort to just solve the above limitations as well.

  12. Anon says:

    I do like the way Parallels Desktop works – they’ve punched holes in the VM so that cut and paste works. They install a network driver in the VM so it can see the host network and they’ve even got filesystems on the host to be visible in the VM and vice versa. You can even click and exe file on the host and have the VM start up and run it.

    On the other hand it’s aimed at developers who want to a Microsoft OS on a Mac. I.e. I find it useful so I can build stuff in Visual Studio in an old MS OS on my Macbook. I’m not at all convinced that it’s something which you’d want to deploy as part of an OS to the average user. E.g. I know that I’ve got two OSs with different everything inside them, and to me that’s a feature. The average user would see it as a bug.

Skip to main content