4 ms·

I seem to recall that common practice for playing games in the 3.1 and 95 eras was to exit windows and just run DOS. A few games, but hardly all, worked in the

I seem to recall that common practice for playing games in the 3.1 and 95 eras was to exit windows and just run DOS. A few games, but hardly all, worked in the virtualized full screen mode. It was rare that any decent game would run windowed. By the time 98 rolled around it was less common to want to play a game that wasn't already targeting Win32/DirectX.

linguae 6y ago
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.
- dehrmann 6y ago
  > at the 98 Cent Store, which became the Dollar Tree sometime around 2000 That's inflation for ya.
- JoshTriplett 6y ago
  I remember Kiloblaster, and many other old DOS games (and edutainment). https://archive.org/details/Kiloblaster https://archive.org/details/Kiloblaster
- fuzzfactor 6y ago
  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. [1] How-to available on request.
- beervirus 6y ago
  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. Good times.
pjmlp 6y ago
Microsoft did made an earlier attempt to a games API for Windows 3.x, but only a few games bought into it, WinG. https://en.wikipedia.org/wiki/WinG https://en.wikipedia.org/wiki/WinG https://www.gamasutra.com/view/feature/3199/a_whirlwind_tour_of_wing.php https://www.gamasutra.com/view/feature/3199/a_whirlwind_tour... I guess I was one of the few people that bothered to use it.
- bitwize 6y ago
  WinG allowed you to blit a bitmap from user memory directly into a window. It was a bit like the XShm extension from X11, where compatible pixmap data can be copied directly into the drawable from client memory. Normally when you transferred image data from a bitmap in user memory (called a DIB) into a GDI drawable such as a window or bitmap with a call to SetDIBits or StretchDIBits, it's slow because there's a conversion step that has to take place: GDI bitmaps were typically held internally in a planar format (on EGA and VGA anyway), and DIB data was chunky. Also, as DIBs were identical to the BMP format, they were scanned from the bottom up instead of the top down (the first pixel in the DIB pixel buffer was the lower left rather than the upper left). This, I believe, was a holdover from OS/2, because IBM decided they wanted proper Cartesian coordinates in their bitmaps? Needless to say, most users and most video cards do not lay out bitmap image memory in that format. With the proliferation of 256-color graphics cards, WinG became possible because 256-color modes typically had a chunky format. So you could draw your game screen in a buffer and use the WinG calls to write that buffer directly to the screen. WinG provided for additional DIB formats including top-down, so that memory could simply be copied from the DIB buffer straight from the screen on a blit call. WinG even supported accelerated blitting on cards with hardware acceleration. The other DirectX predecessor is a bit less well known, and is called DISPDIB.DLL. DISPDIB allowed you to suspend GDI calls to the screen, put the screen in mode 0x13, and draw directly from a DIB into the display, giving you a 320x200, 256-color full-screen display -- just like DOS. The window would also capture all keyboard and mouse input while it was active. Some early pre-DirectX Windows 95 games, including Earthworm Jim and Pitfall: The Mayan Adventure, used DISPDIB.
  - pjmlp 6y ago
    Might have been, sometimes it is ironic how OS/2 gets so much praise, when around this time the APIs were quite similar (given its historical relation). Most likely from devs that never actually coded for OS/2. :) Thanks for the DISPDIB.DLL overview, I wasn't aware of it.
iforgotpassword 6y ago
Not in my experience. Off the to of my head some games that worked fine on 95: Duke Nukem 3D (build games in general) Stunts Death rally Settlers 2 Transport Tycoon Warcraft The biggest problem was accidentally hitting the Windows key which minimized the game and that crashed most of them. That is one thing that improved on 98. You could restore most of these games there with a 90% success rate.
- nitrogen 6y ago
  IIRC one of the biggest factors in whether a game would work under Windows was whether it tried to change the interrupt rate of the timer from the 18.2Hz default.
Kipters 6y ago
This seems a good occasion to plug Raymond Chen's blog where he also shares some war stories about his time working on Windows 95's backwards compatibility, especially for games https://devblogs.microsoft.com/oldnewthing/ https://devblogs.microsoft.com/oldnewthing/

linguae 6y ago

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.

dehrmann 6y ago
> at the 98 Cent Store, which became the Dollar Tree sometime around 2000 That's inflation for ya.
JoshTriplett 6y ago
I remember Kiloblaster, and many other old DOS games (and edutainment). https://archive.org/details/Kiloblaster https://archive.org/details/Kiloblaster
fuzzfactor 6y ago
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. [1] How-to available on request.
beervirus 6y ago
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. Good times.

pjmlp 6y ago

Microsoft did made an earlier attempt to a games API for Windows 3.x, but only a few games bought into it, WinG. https://en.wikipedia.org/wiki/WinG https://en.wikipedia.org/wiki/WinG https://www.gamasutra.com/view/feature/3199/a_whirlwind_tour_of_wing.php https://www.gamasutra.com/view/feature/3199/a_whirlwind_tour... I guess I was one of the few people that bothered to use it.

bitwize 6y ago
WinG allowed you to blit a bitmap from user memory directly into a window. It was a bit like the XShm extension from X11, where compatible pixmap data can be copied directly into the drawable from client memory. Normally when you transferred image data from a bitmap in user memory (called a DIB) into a GDI drawable such as a window or bitmap with a call to SetDIBits or StretchDIBits, it's slow because there's a conversion step that has to take place: GDI bitmaps were typically held internally in a planar format (on EGA and VGA anyway), and DIB data was chunky. Also, as DIBs were identical to the BMP format, they were scanned from the bottom up instead of the top down (the first pixel in the DIB pixel buffer was the lower left rather than the upper left). This, I believe, was a holdover from OS/2, because IBM decided they wanted proper Cartesian coordinates in their bitmaps? Needless to say, most users and most video cards do not lay out bitmap image memory in that format. With the proliferation of 256-color graphics cards, WinG became possible because 256-color modes typically had a chunky format. So you could draw your game screen in a buffer and use the WinG calls to write that buffer directly to the screen. WinG provided for additional DIB formats including top-down, so that memory could simply be copied from the DIB buffer straight from the screen on a blit call. WinG even supported accelerated blitting on cards with hardware acceleration. The other DirectX predecessor is a bit less well known, and is called DISPDIB.DLL. DISPDIB allowed you to suspend GDI calls to the screen, put the screen in mode 0x13, and draw directly from a DIB into the display, giving you a 320x200, 256-color full-screen display -- just like DOS. The window would also capture all keyboard and mouse input while it was active. Some early pre-DirectX Windows 95 games, including Earthworm Jim and Pitfall: The Mayan Adventure, used DISPDIB.
- pjmlp 6y ago
  Might have been, sometimes it is ironic how OS/2 gets so much praise, when around this time the APIs were quite similar (given its historical relation). Most likely from devs that never actually coded for OS/2. :) Thanks for the DISPDIB.DLL overview, I wasn't aware of it.

iforgotpassword 6y ago

Not in my experience. Off the to of my head some games that worked fine on 95: Duke Nukem 3D (build games in general) Stunts Death rally Settlers 2 Transport Tycoon Warcraft The biggest problem was accidentally hitting the Windows key which minimized the game and that crashed most of them. That is one thing that improved on 98. You could restore most of these games there with a 90% success rate.

nitrogen 6y ago
IIRC one of the biggest factors in whether a game would work under Windows was whether it tried to change the interrupt rate of the timer from the 18.2Hz default.

Kipters 6y ago

This seems a good occasion to plug Raymond Chen's blog where he also shares some war stories about his time working on Windows 95's backwards compatibility, especially for games https://devblogs.microsoft.com/oldnewthing/ https://devblogs.microsoft.com/oldnewthing/