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 (which is to say, at the level files and directories rather than disk sectors, aside from the occasional PC booter or CD audio track) 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’s built-in DOS.
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?
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 a 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. Perhaps even a replacement VXD would have to be written.
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.