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 C:\ cd WINDOWS win
win, DOSBox crashes a few seconds later. How do I fix this?
Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.Sign up to join this community
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:
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.
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"
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?
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?
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:
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.