[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.