DOS compatibility however wasn't that great. I recall using OS/2 (2.1 first, then Warp 3) DOS terminals to build and test Clipper programs. It was much a better experience, also for being able to emulate two networked DOS machines, which had some limitations and stability problems when using Windows 95 terminals.
During the beta of Windows 95 I was working at a company that had made a DOS extender for Clipper, and we got reports That the apps in 16 bit protected mode did not work. Looking in to it, there was a bug in the 16 bit FAT driver, I think, things are fuzzy from that long ago, which wasn’t used by a lot of things. I actually managed to get a bug report in, talked to the guy working on the driver, and had a build Fedexed to me a couple of days later to verify the fix.
Yes! Right click on the exe file and change the startup options to do a full reboot into DOS. Definitely needed for the games that were hard coded to use the first MB of RAM
Or for any games at all on a low/mid-range machine of the time. The overhead of Win95 crippled almost all DOS games on my machine. They might as well not have bothered with compatibility.
That is true, but my goal was to have two DOS terminals in which I could emulate two DOS networked machines sharing files, both running a client/server software I wrote, to emulate how they would work at a customer of mine shop. While it worked perfectly on OS/2, I encountered some stability problems on Windows 95, which also (if memory serves) required some more steps to allow DOS terminals to share their storage.
By using OS/2 I could effectively replicate two machines in a single one and compile both client and server in a single take with 100% confidence that it would work once installed at the customer shop.
How would that work? From my recollection the computer booted up in DOS ran through your config.sys and autoexec.bat. The final line typically in the autoexec.bat was win. Which would start up windows 95.
Also when you shutdown windows 95 it would leave you at a DOS prompt. So no restart was actually needed.
Windows 95 didn’t have “win” in the autoexec.bat, it autoloaded it. The behaviour was controlled in msdos.sys, which on 9x had various startup options including BootGUI (DOS was entirely in io.sys).
IIRC “MS DOS mode” could either just exit Windows, or reboot the entire system depending on config (presumably if you wanted custom config.sys / autoexec.bat)? But I might be wrong, it’s been years since I used 9x.
This is correct. msdos.sys was a text file with configuration values, which could be set to either auto-start Windows after running autoexec.bat, or not. In the former case, exiting Windows would stop at the "now safe to turn off your computer" screen. In the latter case, startup would go to a DOS command prompt, and Windows could be started from there, and exiting it would go back to DOS.
Those two cases got conflated by the ability to start Windows from within autoexec.bat, which wasn't the Microsoft default but was a fairly common setup from some OEMs. To the OS, that's the case of starting Windows separately, but to the user, it looks like the auto-starting case.
You could also make it "boot into DOS" by adding command.com as the last thing autoexec.bat would invoke. That way you end up in the shell, and exiting it would boot Windows.
Don't know about gracefully (some drivers might not cleanly shut down), but Win95 did indeed exit to DOS. It left the screen in graphics mode with the message "It is now safe to turn off your computer", but you could blindly type some command to reset it to text mode.
DOS compatibility is inherently very hard because its de facto API, such as it was, involved poking into hardcoded addresses in memory and other such stuff.
Even then, things that stuck to DOS syscalls (INT 21h etc) would generally work.