I also remember having to exit into DOS on my parent's PC running Windows 95 whenever I wanted to run MS-DOS games. I remember a PIF setting that allowed booting into DOS, directly running the program, and immediately rebooting into Windows upon closure, which bypassed the need to use DOS commands to execute the program. I was just a kid at the time, and I remember my dad buying cheap DOS games at the 98 Cent Store, which became the Dollar Tree sometime around 2000. One game I remember was a shooting game named Kiloblaster that I enjoyed a lot, and I also remember some educational titles, one teaching history and geography (I forget the name, unfortunately), and another teaching fractions. I also remember a MS-DOS version of PacMan.
If I remember correctly, Windows 95 was able to detect whether a DOS program would run well while Windows is running, or if it required booting directly into DOS. QBASIC was well-behaved and thus did not require a reboot.
This article brought back some pleasant childhood memories.
I have vague memories from the Windows 3.1 era of writing a batch file that would replace AUTOEXEC.BAT and CONFIG.SYS with stripped-down versions (after creating backup copies). This would save memory and allow some games to run that otherwise wouldn't.
I'd run the batch file, then reboot and play the game. When I was done, I'd run another batch file to rename the backup copies onto the original files, then reboot again and Windows would start.
The full incentive was never there for Windows 9x (nor NT) to run the most innovative DOS games since Windows was never popular until Windows 3 and it was mainly for offices to adopt the mouse. Windows 95 is when mice reproduced exponentially along with PC's once they were 32-bit and powerful enough for the GUI. Office people could pick the least unlikely choice from a menu, and lower-cost operators having far less ability or training could be utilized in force to compensate for the less common talent that was previously needed.
DOS gamers had already been well established with their IRQ's, joysticks and custom config.sys files.
And every non-NT Windows system was always actually just a dual-boot DOS/Windows installation, transparently defaulted to boot Windows at startup. They just tweaked so they could display the Microsoft bootmenu. Serious gamers, WordPerfect, or CAD/CAM operators had three main choices to run their DOS programs[0];
1. Right there in Windows, where you open a _DOS_ command prompt window then run your program, or double click on a DOS EXE and it opened a DOS window and ran. Some programs would run one way but not the other, behavior could be dependent on custom config.sys & INI files.
2. Dropping down from the Windows shell to the underlying DOS which is in memory already. INI & config.sys files still apply and behavior can be interesting. Higher performance with better graphics could sometimes be had.
3. Reboot to clean DOS, or choose it from a multiboot menu upon startup. Different INI & config files can be stored in different directories and apply to different boot paths, including Windows.
In the DOS-based Windows series, config.sys is your native Microsoft multiboot menu.
For one institution we're still required to run an '80's DOS enterprise masterpiece on the field laptops.
I'm just a science dude but IT came to me for this one. Probably just because I'm old or something.
I do remember the way I programmed the first effective battery-powered computer for my industry, but they didn't have laptops yet, or IBM-compatible PC's, not even the earliest real IBM desktops. So I used a TRS-80 with a one-line LCD, RS-232 interface, and mini printer/plotter.
It only did one thing, but at least the UI was less error-prone than what people usually settle for any more.
Anyway to validate an epic DOS program in increasingly virtual systems works pretty good if you have the right modern 64-bit PC configuration.
So I fixed up a PC where any time you want you can just boot bare metal to DOS, W9x, WXPx86, W10x86 or W10x64 the regular ordinary way, quickly and easily[1]. Partition1 is FAT32 which looks like it's made a comeback after patent expiry so everybody's doing it again now.
The DOS system was established fundamentally, then each Windows system could be made to run the program in a DOS window which could be minimized and restored full-screen, by running the same files residing on partition1. Enabling Windows feature NTVDM is what allows 16-bit programs to run on 32-bit Windows.
It all does fine after little tweaks when needed for a particular Windows version, running in Windows compatibility modes turned out not to be essential.
Networking and printing to the site resources could all be handled in Windows, like they had done with XP.
I even got them a mouse working which they never had before.
But no DOS in 64-bit Windows for you.
Until I tried Vdos, a nice emulator which turned out to perform as needed, paying attention to its particular options.
So it's just a regular PC that can run an '80's DOS program using any of 5 different generations of Windows/DOS which appeared over the 30-year period since then.
Glad this program was intentionally less bleeding-edge than many DOS games at the time, or I might not have gotten so lucky.
[0] It would be decades before most people knew what you were talking about if you called them apps.
If I remember correctly, Windows 95 was able to detect whether a DOS program would run well while Windows is running, or if it required booting directly into DOS. QBASIC was well-behaved and thus did not require a reboot.
This article brought back some pleasant childhood memories.