When booting Win95, DOSBox suddenly closes before even the "Starting Windows 95..." dialog shows up. I entered these commands in DOSBox:

mount C C:\dos

After entering win, DOSBox crashes a few seconds later. How do I fix this?

  • 6
    Isn't DOSBox a still maintained software? So, if DOSBox crashes, wouldn't asking their support be the most appropriate place? Even then, it might be helpful to give basic information about the environment used, like what OS, distribution, setup, etc.
    – Raffzahn
    Jul 26, 2021 at 19:22
  • 9
    As of 2011, Windows 9x wasn't supported in DOSBox. The crashing is well-known as of 2017 – though this might be among the first times it's crashed just starting Windows.
    – wizzwizz4
    Jul 26, 2021 at 19:25
  • 3
    Wrong tool for this purpose. DosBox is meant to run games, not business software or another OS like Windows. There are much more suitable virtual environments to run Windows than DosBox.
    – Justme
    Jul 26, 2021 at 20:09
  • 1
    Given the answer, I actually think this is on-topic. (Yeah, yeah, the scope of the question shouldn't depend on the answers – but I learnt something about the subject matter that changes my opinion of the scope, so it doesn't count.)
    – wizzwizz4
    Jul 26, 2021 at 20:32
  • 6
    @wizzwizz4 The question is about DOSBox, and the reason it doesn't work (which might be what you learned) is due a component of DOSBox. There is no gray region here that would make it on topic in any way. The most relevant point here is that DOSBox is modern, supported software, so any support request should first go there - like with any other software.
    – Raffzahn
    Jul 26, 2021 at 21:33

5 Answers 5


Windows 95 sorta-kinda works on DOSBox. I went through the motions several times before I got it to work, but the main issue is that DOSBox doesn't really work out-of-the-box with Win95. There is another project called DOSBox-X which attempts to address some of the quirks that prevent Windows 95 from running on it and as such they have guides on how to do it. There are other web pages you can search on the web which will walk you through installation of Windows 95 on DOSBox (e.g. 'win95 on dosbox').

I imagine you simply have a disk image with Win95 on it and you're trying to run it. This won't work because most importantly the DOS emulation that DOSBox provides will NOT run Win95 - you'll need to actually install a real MS-DOS version to install and later run Windows. Windows 3.1 and later are all picky about what DOS they run on top of and will crash/halt/exit if you're using FreeDOS or DOSBox's DOS emulation.

General steps involved to get Win95 running are:

  1. Create a raw disk image for DOSBox. This has to be mounted as a disk image, i.e. you can't just mount a subdirectory on your host machine.
  2. Install real MS-DOS 6.22 on the image. This usually involves juggling of virtually inserted 3.5" floppy disk images with DOSBox to format and install on the raw disk image you created.
  3. Copying Win95 installation files over to your disk image so you can run that installer after you've installed MS-DOS on it.
  4. More juggling of disk images and such, but if you can get the installer to complete then you should be able to just boot the mounted disk image and enjoy Win95, although with scaling and mouse capture weirdness if you're not in full screen.

Best advice is go with the guides and start from scratch, but the general idea is that it is possible, though not as easy as you would hope.

  • 3
    This is a minor point, but IME Windows 3.1 and WfWG 3.11 don’t care all that much about the DOS version; I have them both running fine on plain DOSBox. Jul 27, 2021 at 8:17
  • 4
    @StephenKitt you're probably right - I just had in my head the phrase "Windows isn't done until DR-DOS doesn't run" and thought it was around the time of Windows 3.1.
    – bjb
    Jul 27, 2021 at 16:59
  • 1
    Yes, there was the AARD controversy, but non-beta versions of Windows worked fine on DR DOS, that’s what I used back then ;-). Jul 27, 2021 at 18:24
  • I don’t think copying installation files to the disk image is strictly necessary; the imgmount command can handle ISO images just fine. I assume the point is to avoid mounting the installer files as a directory. Aug 2, 2021 at 16:15
  • I ended up having to create a separate IMG file which I copied the contents of the installation CD-ROM ISO to, since I couldn't get DOSBox to recognize the ISO as a mounted CD-ROM. So in other words, I had two IMGs: 1/the one I would install Win95 to, and 2/the one which had the Win95 CD-ROM contents copied to it. I could mount both as drives and then 'boot -l c' into the first image, and then run setup from 'd'. Also, I could not successfully run Win95 setup from DOSBox's DOS emulation, thus the source of making this all so tricky. That being said, I DID use the DOS emulation to make 'd'.
    – bjb
    Aug 3, 2021 at 0:25

DOSBox as a project generally targets games, and as such its built-in DOS implements only the subset of DOS used by games, which is mostly memory management (including XMS and EMS memory), high-level file system access (files and directories, not disk sectors, aside from the occasional PC booter) and process spawning. Other than that, games typically need access to sound, video and network hardware, with which DOS itself has little involvement. Windows 9x, on the other hand, requires a much larger and deeper API/ABI surface of DOS to function, some of which is very poorly documented and understood. As such Windows 9x is much more intimately tied to the version of MS-DOS it came with, unlike Windows 3.x, which can run pretty well even on DR DOS, despite Microsoft’s best intentions. It is for this reason that you need to install Windows 95 on a disk image and tell DOSBox to boot from it: so that the bundled version of MS-DOS is available to Windows, which provides the necessary interface.0 But then, because it was designed to run on real hardware and expects to read and write disk sectors directly, it will not be able to access directory mounts, which are normally provided by DOSBox.

And even with the right version of MS-DOS, DOSBox doesn’t emulate PC hardware with the necessary fidelity to allow Windows to run reliably, though an unofficial guide to make it work has been written. A fork, DOSBox-X, explicitly targets general DOS software and Windows 95, and provides much more stable hardware emulation. There is a thread on vogons.org detailing the improvements included in that fork. With the upstream DOSBox, I barely managed to run Windows 95 in Safe Mode (from a disk image), and even then it froze basically at first opportunity upon moving the mouse.

But what happens if you ignore all the above advice and attempt to start Windows from within DOSBox’s built-in DOS? When I followed the steps in the question, DOSBox exited and put this message in the log:

Exit to error: DOS:Illegal 0x33 Call  7

DOSBox terminates when it sees the guest attempt to invoke interrupt 0x21, service 0x3307. Here’s what Ralf Brown’s has to say about this call:

INT 21 — Windows95 — SET/CLEAR DOS_FLAG

  • AX = 3307h
  • DL = subfunction
    • 00h clear bit 5 of "DOS_FLAG"
    • 01h set bit 5 of "DOS_FLAG"

Return: ???

What is it supposed to do? I have no idea. RBIL has no idea. I presume DOSBox developers have no idea either, so they did not implement it. (There is actually a patch in the development branch which at least stops DOSBox from entirely exiting, but it is not part of any release yet.) Suppose, however, that it’s not actually very important: I can have a TSR turn it into a dummy call that does nothing. Is Windows 95 going to work then?

Registry File was not found.  Registry services may be inoperative this session.  XMS cache problem.  Registry services may be inoperative this session.

Windows 9x relies on MS-DOS to locate the Registry file. There is an actual dedicated system call for it. DOSBox, of course, does not implement it, triggering the error above. But that is also easily patched by a TSR, which can have it return a fixed path to SYSTEM.DAT. Will that make Windows work?

Cannot load a device file that is specified in SYSTEM.INI.  The performance of Windows should not be affected without this file.  C:\WINDOWS\SYSTEM\VMM32\IOS.VXD

This informs us of the failure to start up the I/O Supervisor, which is basically Windows 9x’s disk driver layer. Despite the relatively reassuring error message, it is pretty crucial component, without which Windows will not be able to run. Getting it to work will be much harder than a quick-and-dirty one-off TSR: one will probably have to implement a substantial amount of DOS’s disk services, not just calls that provide high-level access to files and directories.

If we also intercept calls to interrupt 0x2f service 0x4a17 to capture the text that Windows tries to direct to BOOTLOG.TXT, we see this:

LoadFailed = VTD

VTD stands for the Virtual Timer Device: this is a driver managing the system clock, and is also required to get Windows running. This driver fails to start because it depends on the underlying DOS providing the little-known CLOCK$ character device. Though somewhat obscure and rarely used, this device should be relatively easy to implement. DOSBox however doesn’t, since games make no use of it: if they ever need to read the system clock, interrupt 0x21 services 0x2a and 0x2c are just enough for their purposes.

None of those functionality gaps are inherently insurmountable (though getting IOS to work may be harder than the rest), but since they fall outside DOSBox’s scope, you should not expect DOSBox to cover them any time soon; upstream DOSBox developers are known to reject patches that don’t address problems with a specific DOS game (not general software, game). These issues are most probably not the only ones that prevent running Windows 95 under DOSBox’s DOS: they were just the ones easiest to discover. DOSBox is just the wrong DOS, and the wrong box.

0 It is also this bundled version of MS-DOS which produces the ‘Starting Windows 95...’ message, not the WIN.COM loader itself, as is implied by the question.


As the other answers touched on - DOSBox is intended to support/run games, not emulate MS-DOS faithfully. An example I came across is that DOSBox does not support batch loops (eg FOR commands).

PCem is designed to emulate PC hardware - this might be your best bet

PCem is an impressively versatile emulator, capable of emulating a wide range of IBM compatible PCs. From XT 8088 based machines up to Late Pentium I MMX era machines, making it a viable alternative to DOSbox and virtualization.


  • I feel this is kind of missing the point of the question; this is not tagged as software-recommendation after all. Answers should focus on the problem asked, not on proposing alternatives. Aug 4, 2021 at 7:40
  • 1
    It should, though, if the requested configuration is known as problematic and unsupported by the emulator developer
    – scruss
    Aug 4, 2021 at 21:34
  • PCem, in June 2021, suffered the loss of its primary developer (not dead, just not working on it any more). As of December 2021, I believe she'd found someone to take over so it may not be a problem any more. And on the "appropriate answer" point, sometimes the best answer is "find another way". Such as writing an OS in COBOL, or an accounting app in assembler, or anything in Pascal :-)
    – paxdiablo
    Mar 19, 2022 at 4:24

While DOSBox can run some "heavy" softwares (I successfully installed "Borland Pascal for Windows 7" and "Windows 3.11" on mine, for example), there is some MAJOR flaws in the built-in DOS...

In order to get a game running properly, I needed to hack inside the process - that's why I installed BPW, to get "Turbo Debugger" - and I noticed that int 21h had an emulation problem with function 57h/01h (which is "set file date and time using handle", BTW)... It can't do what it was able to do on a real machine - don't know if it's because of the underlying NTFS partition or a real flaw in emulation, but anyway, it doesn't work properly, and won't work properly on most machines since few modern system would use a FAT12/FAT16 filesystem.

I don't even speak about the BATCH interpreter, which is more a DOS 3.x than anything else on some aspects - it kills instantly some old "applications" written mostly in Batch, for example.

So through hacks and unofficial forks, you MAY be able to run Win95 on it... But it won't provide you a proper emulation, and you'll always wonder why you just crashed your DOSBox - underlying DOS? Windows itself? Missing support in DOSBox itself?

As I said, Windows 3.x works perfectly fine on DOSBox, even applications like Word or Excel run fine, only drivers are a bit tricky to get/install but it isn't an ordeal anyway. Despite it needs DOS behind, Windows 95 was anyway designed as a whole operating system, not just a graphical interface like Windows 3.11 and older were. In particular, it installs its own version of DOS...

Usually, most people who needs a working Windows 95 use either PCem, VMWare or VirtualBox - not DOSBox.

I understand that it is probably not the answer you wished for, but if you NEED a running Win95 without annoying bugs and/or lack of functionalities, DOSBox isn't the right choice at all.


I think you may have a fundamental misunderstanding of the expected use of DOSBox, it's meant to run DOS software (and, even then, games). Otherwise it would surely be called WinBox :-)

Specifically, see this link on the DOSBox forums, specifically these sections:

This thread is for forum posters to suggest features for DOSBox.


  • Windows 9x support as a guest. (Use QEMU if you want Windows 9x support)

So, while it may be possible to coerce DOSBox to run Win95, you'll almost certainly get no real support (either features to allow it, or help when it doesn't work) from the developers.

You must log in to answer this question.

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