7 ms·

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 to

• AshamedCaptain 2y ago
  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.
  • anyfoo 2y ago
    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.
  • EgoIncarnate 2y ago
    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 2y ago
      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 2y ago
        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.
  • akira2501 2y ago
    Prior to the internet vendor included features were significantly more important than they are now.