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