If you were to build a modern x86 computer with completely modern parts, could you load MS-DOS 6.11 and Windows 3.11 onto it without any emulation or even with FreeDOS? I recently saw a video of it being done with Windows 95, a 32-bit OS, but can it be done with a 16-bit OS like Windows 3.1 or even lower?

  • 3
    Even if 16-bit compiled code can run on some modern 64-bit CPU, you still have the issues of support for modern hardware. Windows 3.1 doesn't support EFI boot, it doesn't support various types of hardware the new system would have (USB 2.0 keyboards?), etc. I think you would have trouble getting the install disk to recognize enough hardware to install the OS.
    – Romen
    Commented Jan 23, 2020 at 22:28
  • 1
    @John, It seemed to me that your answer was written as if it were answering the question "Can a 16-bit application run on a 64-bit OS without emulation?" This is about the ability for a 64-bit CPU to boot and run 16-bit operating systems, which would mean running 16-bit instructions on a 64-bit CPU. 32-bit instructions are supported on 64-bit CPUs so I suspect that 16-bit backwards compatibility at the machine-level is possible too.
    – Romen
    Commented Jan 23, 2020 at 22:31
  • 7
    "64-bit computer" -- There are other processor architectures besides Intel's x86, so don't be so PC-centric, and make an effort to at least mention x86.
    – sawdust
    Commented Jan 23, 2020 at 22:41
  • 9
    @sawdust - The question mentions MSDOS 6.11 and Windows 3.11 I think it's safe to say we are limited to the Intel 8086 family of products.
    – Ramhound
    Commented Jan 23, 2020 at 22:54
  • @Ramhound -- Given that there are broad questions such as this one, I'm not going to assume everyone is thinking of a restricted set of processors. You even commented on that post.
    – sawdust
    Commented Jan 24, 2020 at 0:45

4 Answers 4


Yes. 64-bit CPUs (the x86 kind) can run in x86 real mode, and this is what 16-bit application run on. You have all the limitations of it (640KB memory, 16-bit wide register, etc), but you have a processor speed hundreds if not thousand times faster than in the 80's, when these 16-bit operating systems were all the rage.

Hardware access is problematic though. Since in 2020 Intel plans on actively dropping support for legacy BIOS and even the Compatibility Support Module, your 16-bit application will not be able to rely on BIOS calls to do disk access, graphics, keyboard/mouse input, etc. You’d have to write 16-bit drivers for all of it, which isn’t really feasible, as most of the devices would not be addressable with 16 bits (the device PCI addresses would usually be around 3GB), and there is no way of telling your driver to "write this buffer data to address 0xEF000000" (because that would be what the driver expected).

If on the other hand you still have traditional BIOS present (or at least the UEFI CSM enabled), you can still run old 16-bit software. Hardware support will be limited, though, as all has to be provided by the BIOS, and BIOS manufacturers might cut down on broad support and only support a limited number of USB devices and also only a certain amount of SATA (or even NVMe) devices.

  • 3
    Strictly speaking, the ability to run real mode code is only part of what is needed. Windows 3.x runs in 16-bit protected mode, and emm386.exe causes MS/PC-DOS to run in v8086 protected mode.
    – JdeBP
    Commented Jan 24, 2020 at 18:48
  • 9
    "16-bit wide register" is not a limitation: the 66h prefix is still available. Even the 67h prefix is available (so you can use the convenient 32-bit addressing modes), although the segments are limited to 64K by default. Also don't forget the Unreal Mode you can switch to, still continuing execution of 16-bit code.
    – Ruslan
    Commented Jan 24, 2020 at 22:46

As CPUs and PCs have evolved, CPU manufacturers have been committed to maintaining backwards compatibility with previous instruction sets and software. You will still find some instructions on modern x86-64 CPUs that were introduced on the Intel 8086 (from the late 1970s).

The answer to your question is yes, modern x86-64 PCs can technically run 16-bit operating systems. As a matter of fact, here's a link to a video by popular YouTuber LGR showing him installing MS-DOS 6.2 on his new gaming PC.

There are some obvious limitations to doing something like this. In DOS, you won't be able to access more than 640K of RAM. Similarly, if you run a 32-bit OS on 64-bit hardware (or 32-bit hardware, for that matter), the programs you run will be limited to using 4GB of RAM.

All of that being said, 64-bit operating systems cannot natively run 16-bit software like they can 32-bit software. A strange quirk, but that's how the computer chip cookie has crumbled.

  • 12
    Some corrections: DOS can access more than 640KiB of RAM with various extenders, famously HIMEM.SYS and EMU386.EXE. 32-bit OSs definitely can use more than 4GiB of RAM, for example: 32-bit Windows Server 2003 supports up to 64GiB of RAM. Linux has a similar limit. The limit is on virtual memory for a single 32-bit process, not the OS. Commented Jan 24, 2020 at 16:09
  • 1
    I knew about the 4GB exceptions, hence why I included that blurb in my answer :) I didn't know about the DOS extensions though, that's interesting!
    – Sam Forbis
    Commented Jan 24, 2020 at 17:30
  • 1
    The 4GiB limit is on an individual process, though, and not on the OS itself. I don't know of a single 32-bit OS that cannot address more than 4GiB of RAM. So I don't think this ability is an "exception"... it's the "rule". Commented Jan 24, 2020 at 17:33
  • 1
    @CodyGray : "It is only true in the context of 64-bit Windows and is due to the fact that 64-bit Windows"... "There is nothing preventing executing 16-bit code with the CPU"... - to clarify, the issue is not Windows-specific. The issue is that AMD64/Intel64 CPUs have multiple modes, and the fastest 64-bit enhanced mode drops support for 16-bit code. So any 64-bit OS which puts the CPU in the most optimum 64-bit mode won't run 16-bit code. Running 16-bit code requires booting into a slower compatibility mode, typically switched to by rebooting. (Things a college course taught about x64 Asm!)
    – TOOGAM
    Commented Jan 25, 2020 at 15:16
  • 4
    @TOOGAM CPUs can switch modes without rebooting (the only x86 CPU which needed to be reset to change modes in some cases was the 80286). It is possible for a 64-bit kernel to run 16-bit protected mode code. It is even possible to use a hypervisor to run 16-bit real-mode code. Commented Jan 25, 2020 at 22:40

Yes. Modern x86-64 CPUs are still fully backward-compatible back to even the first generation (8086)

Full backward compatibility is particularly important in computer instruction set architectures, one of the most successful being the x86 family of microprocessors. Their full backward compatibility spans back to the 16-bit Intel 8086/8088 processors introduced in 1978. (The 8086/8088, in turn, were designed with easy machine-translatability of programs written for its predecessor in mind, although they were not instruction-set compatible with the 8-bit Intel 8080 processor as of 1974.


It even starts up from real mode which is the mode that DOS runs on. After starting up the boot loader or kernel will switch to 32 or 64-bit mode as it wishes

x86 processors that support protected mode boot into real mode for backward compatibility with the older 8086 class of processors. Upon power-on (a.k.a. booting), the processor initializes in real mode, and then begins executing instructions. Operating system boot code, which might be stored in ROM, may place the processor into the protected mode to enable paging and other features. The instruction set in protected mode is similar to that used in real mode.


So it's definitely possible to install all DOS versions in all x86 CPUs and suffer from all DOS limitations such as the addressing mode or the number of address lines. Windows 3.x is in fact just a GUI app running on top of DOS (although in a different 16-bit mode), so you'll also be able to run it on modern machines

However one major difference in the previous modes and 64-bit mode (A.K.A long mode) is that once the CPU switches to long mode, it can't transition back to the virtual-8086 mode so you can't run 16-bit DOS apps inside 64-bit Windows. For those you have to run on the bare-metal machine (so running it in a bare VM would also work)

See Is it possible to run 16-bit code in an operating system that supports Intel IA-32e mode?

That said, although the CPU supports the full 16-bit instruction set, booting up the system may be difficult due to the lack of modern hardware support as others have said

  • 1
    I would not call it "fully", the CPU might still have the 16 bit instructions, but BIOS service routines and device drivers in 16bit mode might certainly not be available for all new parts, or even for crucial parts like Keyboards.
    – eckes
    Commented Jan 24, 2020 at 9:30
  • 3
    Actually, since the 80386 processors have started up in unreal mode, and later switched to real mode. superuser.com/a/345333/38062
    – JdeBP
    Commented Jan 24, 2020 at 20:33
  • 2
    "still fully backward-compatible" — not actually fully. Small incompatibilities are introduced more and more. See e.g. IA32_MISC_ENABLE bit 2 (ENABLEFOPCODE — x87 FPU Fopcode Compatibility Mode Enable), which is 0 by default (moreover, newer CPUs don't even support this bit).
    – Ruslan
    Commented Jan 24, 2020 at 23:07
  • 1
    @supercat: HW virtualization does make it possible for the guest to be in v8086 mode, even if the hypervisor uses 64-bit long mode. With a smart enough hypervisor that "knows about" the guest (or is providing its own WINE-like OS layer), presumably it can hook 16-bit Windows system calls to put 16-bit apps in their own window on the host. You can do the same kind of thing with some remote-desktop stuff like VNC, or with WINE for letting Windows programs run in their own window under Linux. Commented Jan 25, 2020 at 5:47
  • 1
    @supercat: Because Windows is "just" a kernel not a hypervisor. Apparently it chooses not to include code to run a 16-bit guest VM. I don't know any of the details of how VMWare does it. Perhaps MS's Hyper-V could do the same thing if they chose to add that feature. Commented Jan 25, 2020 at 7:26

I recently saw a video of it being done with Windows 95,

Windows 95 is a 16-bit operating system (MS-DOS) with a 32-bit shell, so you've seen it done already.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .