[EgoIncarnate]

In OS/2, you can run any version of DOS, or even multiple different versions at the same time, and I think possibly any real-mode OS that doesn't do anything too crazy with the hardware.

In Windows, you are limited to the version of DOS that Windows is running on. Windows does not expose the ability to run any other version of DOS or other OS; nor does Windows API expose any of its virtualization functionality that would be useful in doing so.

[AshamedCaptain]

And so you can on any other DOS box, including Windows ones. That is, again, a necessary requirement of a DOS box: you have to emulate a full (real mode) PC. Every DOS box is its separate VM, so it couldn't care less if you run different versions of DOS on different instances. For example, you can run FreeDOS, and even real mode Windows 3 itself on a 9x DOS box. You can do int13h disk access from a DOS box and completely wreck your disks. This is _required_ by any minimally effective DOS box, otherwise FDISK wouldn't work! Keyboard, mouse, even sound have to be emulated as if they're were real devices, too. Otherwise, your fancy "DOS" game (that happens to call practically no DOS interrupts) would not work .

As I was saying, there's practically no difference between a DOS program and a real mode operating system. How would the VM manager notice you weren't running (MS)DOS, much less care?

> Windows does not expose the ability to run any other version of DOS or other OS; nor does Windows API expose any of its virtualization functionality that would be useful in doing so.

You really do not need _any_ functionality to boot another OS from DOS. It's one int 19h away -- or copy the bootloader in memory and jump to it. It's a shorter program than the vga.com program used in this article.

In fact, the moment you run the author's vga.com on a DOS box, even from command.com, you are effectively no longer running DOS: you have already bootstrapped your own non-DOS operating system on a Windows DOS box.

If you want to be nitpicky, it's likely your "non-DOS" OS has to keep certain DOS structures in the usual places, specially if you want to use e.g. host filesystem level accesses (not full disk), but this will most definitely also be the case for a OS/2 DOS box.

[EgoIncarnate]

The context was you asking what the OP meant by "internal" to Windows ("What does this mean?"), not what was technically possible.

In OS/2 it was a native, natural, advertised capability to run other versions of DOS, including file system access by including a supplied device driver.

In Windows, the supported, advertised, native method was to run the version booted from. While it be possible to hack together running under some other version of DOS, it isn't what was expected, or exposed in the UI.

I believe that's what the OP meant by "internal".

[AshamedCaptain]

Understood, but I would still argue this is at the very least highly misleading -- the virtualization is there, it is exposed to users (you can change all the parameters in the PIF file, for example). If it doesn't really advertise you can use it to run a "different version of DOS or a different OS altogether" it's mostly just that, advertising, and likely done due to monopolistic reasons.

Because the ability to boot another OS from a DOS command prompt is hardly hacking -- see LOADLIN. It is more or less the way DOS works.

[EgoIncarnate]

Why is it "highly misleading" to characterize technically possible but undocumented and unsupported capabilities as "internal". Internal APIs are often undocumented and unsupported, how is this different?

I don't think it's just a monopoly thing. Does the PIF file under Windows (16 bit derivatives and Win9x) allow you to specify kernel, config.sys, autoexec.bat?(1) Without those capabilities I don't see the Windows DOS environment as comparable to OS/2 where you are basically booting DOS in a virtualized BIOS environment.

In Windows you might be able to modify the provided DOS environment after the fact, but as far as I know you are going to be starting from the DOS provided by Windows. The level of DOS integration was actually a benefit in later versions as portions of the DOS kernel got replaced with 32 bit counterparts.

I think LOADLIN worked more because of the lack of security in DOS. As far as I know it generally doesn't work in any of the virtualized DOS environments, so I (somewhat ironically) consider it at the very least highly misleading for LOADLIN to be characterized as "more or less the way DOS works".

It's sometimes possible with security vulnerabilities to red pill modern versions of Windows and insert some other kernel underneath, but I don't think that would typically be considered 'the way Windows works'.

(1) I know NT allows config.sys and autoexec.bat, but it's not "booting" a real DOS environment, but using the files as part of an emulated DOS environment.

[AshamedCaptain]

> Why is it "highly misleading" to characterize technically possible but undocumented and unsupported capabilities as "internal". Internal APIs are often undocumented and unsupported, how is this different?

Because, again, the virtualization _is there_, exposed for all users to use, and the PIF does allow you to change parameters for the virtualization such as the amount of memory, and this is very well documented. My very original message says that you _require_ this virtualization to run any meaningful DOS program, so it is definitely there.

Sure, it's hardwired to boot a specific DOS version. And while true, this "limitation" is practically meaningless in the big context of being able to run DOS programs since DOS programs tend to be _more complicated_ than real mode kernels.

> The level of DOS integration was actually a benefit in later versions as portions of the DOS kernel got replaced with 32 bit counterparts.

This is irrelevant, in part because DOS programs _like to replace portions of the DOS kernel too_, which implies that whatever you do you must still support the ability to entirely replace whichever OS is being run in the VM.

> Does the PIF file under Windows (16 bit derivatives and Win9x) allow you to specify kernel, config.sys, autoexec.bat?

No, but it does allow the user to replace parameters for the virtualizer, for example. And you can still trivially load device drivers (e.g. using devload) and/or TSRs, which again are going to override/replace parts of the loaded DOS , and this is the normal way of life for DOS.

> I think LOADLIN worked more because of the lack of security in DOS

You have to understand something: this is way _every DOS program works_. They'll hook DOS interrupts, they'll hook hardware interrupts, they do whatever they want with the operating system. Some DOS office programs even literally swap out the DOS kernel to disk to gain a couple extra KB of RAM.

You still seem to think that this is something rare and thus make the wrong analogy with vulnerabilities in the Windows kernel. But this is just the wrong view. DOS is a _minuscule_ OS in comparison , so it is actually _more common_ for programs to replace, hook and extend it than it is for them not to do it. At least for every program larger than a hello world. It is, indeed, the way DOS works.

Whatever DOS game you can think of is almost 100% certain to be bypassing DOS _entirely_ and banging the hardware on its own.

There's a reason FreeDOS has to keep some undocumented DOS memory structures literally in the same memory addresses. Practically nothing would run otherwise.

This is the reason _all_ DOS boxes that want to have a modicum of compatibility with real DOS software have to basically be a full PC virtualizer, and you can't just ship say a modified version of DOS that redirects input/output to your new OS and can run DOS programs as native processes (e.g. like Wine does for Win32).

Loadlin does work in a DOS box, but Linux won't (it expects a 386). I have used it to boot other kernels from time to time. But otherwise it is just to show that once DOS loads your program you have full control of the computer, and that is no different from your average DOS program.

[anyfoo]

As some added context, that is probably[1] true for any Windows version that uses v86 (which implies at least a 386 and enhanced mode windows), not so much for any earlier, non-enhanced Windows, or any Windows running on anything less than a 386.

In those, a DOS box is relatively far from a "separate VM".

But the same would apply to OS/2.

[1] I say "probably" because I haven't verified the limitations that Window may apply on its v86 tasks. It's at least possible that there's some tight integration between the DOS version that Windows is "running on" (which remained a thing for any non-NT-based Windows, including 95,98,me) and the "DOS inside the DOS box". Which, yes, would limit what software you can run, but then so does for example the need of protected mode DOS software to use DPMI/VCPI to be able to run in a DOS box, already. Some games just would not run in DOS boxes, that's why you could still boot "DOS mode" in Win95 and later. It's also possible that there is tight integration between Windows and the DOS box in other ways that also adds limitations.

[akira2501]

Prior to the internet vendor included features were significantly more important than they are now.