Only one I can recall is Bio Menace - works fine in DOS 6.2, freezes when you shoot your gun or are hit by an alien in DOS 7. It's been quite a while since I last tried to play it in DOS 7 however; I'll see if I can give it a try sometime soon.

I don't consider DOS 7 a proper DOS, since it is not a standalone OS, but rather the DOS-portion of Win 9x.
Because of this, it requires quite a bit more memory than standalone versions of DOS, and I have run into some problems because of that. It is physically impossible to free up enough conventional memory to run certain software under DOS 7.
But other than that I never encountered any software that wouldn't run on a particular version of DOS (although sometimes it required some tweaking to your boot sequence. I started using the boot menu features in DOS 6.0, and eventually I had some 6 configurations to choose from... EMS/XMS/HMA/no CD drivers etc)... I've used 3.21, 5.0, 6.0 and 6.22.

Especially if you have an existing Windows 9x installation and you're using MS-DOS mode there are a lot of hidden environment variables and other things going on. If you make a boot disc and create your MS-DOS 7.1 installation that way it's different.

Yes it takes up a bit memory (a few KB) but so far I haven't run into anything that doesn't run. I use the boot menu system as seen in many of my videos for easy of use 😀

Tried Bio Menace in DOS 7.0 and it does lock up/freeze as I remember. There is a fix though; when 3DRealms made this game available as freeware in December 2005, they included a patch file (biopatch.zip) to correct a similar issue in DOSBox back then. The same patch file also works in DOS 7.0, making Bio Menace playable again.

So far, no other DOS game I have shows any problems or incompatibilities between different DOS versions.

What about games using FCBs? On the Wikipedia is stated that FCB was deprecated in Windows 95 (when using FAT32 partitions), but I thought it was deprecated earlier.

Are there any known game that used FCBs to read files? I guess every game using FCB could qualify as incompatible with newer DOSes (and some of the olders).

Ultima II and III, as well as Trains use FCBs. FCBs were "deprecated" as early as DOS 2.0, but pretty much every DOS and Windows up to 98/ME supported them on FAT12/FAT16 partitions as long as the user does not include the line "FCBS=0,0" in CONFIG.SYS to save a few bytes of conventional memory.

I would assume that every game before 1986 or so that was not a booter (most of them were) would use FCBs. One should keep in mind that in the 1980s, people did not migrate to a new DOS just because it came out. I can't find it right now, but there was an ad by IBM which basically advised the buyer to choose their DOS according to which system they bought, and if they bought a 5150 PC without hard disk, they were advised to go with DOS 1.1 and not DOS 2.0, so apparently both were available for a time.

JayCeeBee64 wrote:

Tried Bio Menace in DOS 7.0 and it does lock up/freeze as I remember. There is a fix though; when 3DRealms made this game available as freeware in December 2005, they included a patch file (biopatch.zip) to correct a similar issue in DOSBox back then. The same patch file also works in DOS 7.0, making Bio Menace playable again.

Does Bio Menace work in DOS 7.0 when you do a clean boot or when you remove the line DOS=UMB from config.sys?

Calvero wrote:

Does Bio Menace work in DOS 7.0 when you do a clean boot or when you remove the line DOS=UMB from config.sys?

Nope, it still locks up/freeze 😐

EDIT: Okay, got the game working if I use JEMM instead of HIMEM/EMM386 and remove the DOS=UMB line in config.sys. Still, using a different memory manager for just one game hardly seems worth it; I'll just keep using the old 3DRealms DOSBox patch if I feel like playing Bio Menace in DOS 7.0 (I generally play all DOS games in DOS 6.2 anyway, works just fine for my needs 😀 ).

Bio Menace has a bug, you can work around it with that small program, or by setting a STACKS= in config.sys
(9,256 for example)

Already knew that Qbix (Bio Menace is indeed buggy and have been using the STACKS=9,256 line in config.sys since my first PC in 1994). Thanks anyway 😀

Scali wrote:

It is physically impossible to free up enough conventional memory to run certain software under DOS 7.

Not necessarily. It depends on how much conventional memory you require and what drivers you load in your Config.sys and Autoexec.bat files.
In my opinion, if you can free up just over 600KB, then most games will run.

I have two Win9x environments (one is running Windows 95 OSR2.5 and the other one Windows 98SE).
On both I've set up a boot menu that enables me to boot straight into DOS 7.1, bypassing the GUI.
I managed to free up 603KB (617840 bytes) of conventional memory on my Celeron 900 MHz (booting straight into DOS 7.1) with my AWE32 (AWEUtil), mouse & CD-ROM drivers loaded.
On my older 486 PC, I managed to free up 624KB (638912 bytes). The latter doesn't have an AWE32 and hence why I managed to have more conventional memory available.

However, to achieve this you have to load EMM386.exe (or a similar memory manager) and load as many drivers as you can into the Upper Memory Blocks (UMB) using the Devicehigh (under Config.sys) and Loadhigh (under Autoexec.bat) commands.
The order in which you load your drivers (especially in your Autoexec.bat file) also plays a factor in how much you can squeeze into the Upper Memory Region.
Try and load the drivers that takes up the largest memory first and then move down to the ones that takes up less memory (use the "mem/c |more" command to see which drivers takes up the most memory).
If your graphics card is not using the monochrome memory region (which most graphics card didn't since the late 80's), then you can also add the following line to your EMM386.EXE that you load in your Config.sys file: I=B000-B7FF.
For the latter, I have two options in my boot menu, which is one that does free up the monochrome region and one that doesn't (in case I do come across an application that requires it).

jesolo wrote:

Scali wrote:

It is physically impossible to free up enough conventional memory to run certain software under DOS 7.

If your graphics card is not using the monochrome memory region (which most graphics card didn't since the late 80's), then you can also add the following line to your EMM386.EXE that you load in your Config.sys file: I=B000-B7FF.
For the latter, I have two options in my boot menu, which is one that does free up the monochrome region and one that doesn't (in case I do come across an application that requires it).

I usually use a SVGA card in my 486 and have the EMM386.EXE line in my config.sys which uses I=B000-B7FF. Then I had to insert a Hercules graphics card to test something my text disappeared after DOS finished booting. I could not see anything I typed nor could I see the command prompt. I thought something I was loading in DOS may be interfering with the card, once I renamed both autoexec.bat and config.sys so they wouldn't load, text worked fine. It took a few days before it dawned on me that this was the reason. You would think EMM386.EXE would have a sanity check and ignore stuff like this if it detects a monochrome/hercules card.

i thougt fifa99 Crash under Dos Mode of Win98. Under Dos 6.22 it works.

Great Hierophant wrote:

jesolo wrote:

Scali wrote:

It is physically impossible to free up enough conventional memory to run certain software under DOS 7.

If your graphics card is not using the monochrome memory region (which most graphics card didn't since the late 80's), then you can also add the following line to your EMM386.EXE that you load in your Config.sys file: I=B000-B7FF.
For the latter, I have two options in my boot menu, which is one that does free up the monochrome region and one that doesn't (in case I do come across an application that requires it).

I usually use a SVGA card in my 486 and have the EMM386.EXE line in my config.sys which uses I=B000-B7FF. Then I had to insert a Hercules graphics card to test something my text disappeared after DOS finished booting. I could not see anything I typed nor could I see the command prompt. I thought something I was loading in DOS may be interfering with the card, once I renamed both autoexec.bat and config.sys so they wouldn't load, text worked fine. It took a few days before it dawned on me that this was the reason. You would think EMM386.EXE would have a sanity check and ignore stuff like this if it detects a monochrome/hercules card.

The potential problem is not limited to a secondary MDA/Hercules card. EGA/VGA/SVGA will emulate an MDA card when mode 7 is set, and converting the B000-B7FF range to upper memory will conflict in that case.

ripsaw8080 wrote:

The potential problem is not limited to a secondary MDA/Hercules card. EGA/VGA/SVGA will emulate an MDA card when mode 7 is set, and converting the B000-B7FF range to upper memory will conflict in that case.

True, hence why I have the two options in my boot menu (in case I do run into a scenario like this).

The Lost Treasures of Infocom floppies will not install on DOS 6.22. You can get around it by using SETVER to add the installer executable to the version table. I set it to 5.0.

The biggest issue I've found wrt conventional memory on both PC-DOS 7.1 and MS-DOS 7.x is that HIMEM.SYS is a pig with 64MB of RAM, taking about 30kB of conventional memory. For some reason 32MB is significantly less problematic.

Well, the main limiter for DOS conventional RAM is indeed a videocard.
As the example - if I boot my test PC in DOS 7.1 (Win98 boot floppy with custom config.sys/autoexec.bat) with Radeon HD2600 Pro - there are no UMBs at all if I use EMS. The EMS frame grabs all upper memory.
If I boot it with Matrox Mystique - I get around 90 kB UMBs. And can use UMBs with the full EMS frame. And this videocard IS UniVBE 5.x compatible...

P.S. It looks like Archimedean Dynasty not like DOS 7/8. Freezes after running, all 3 executables.
P.S.S. Maybe the reason is the lack of soundcard (Audigy 2 ZS not have DOS support unfortunately, same for Soundmax AD1985)...

gdjacobs wrote:

The biggest issue I've found wrt conventional memory on both PC-DOS 7.1 and MS-DOS 7.x is that HIMEM.SYS is a pig with 64MB of RAM, taking about 30kB of conventional memory. For some reason 32MB is significantly less problematic.

Interesting. At first I thought you were talking about this bug, but that one shouldn't depend on the total amount of RAM:
http://www.helpdoc-online.com/SCDMS01EN1A83P2 … ropean-OSR2.htm

"In some localized non-English versions of Windows 95 OEM Service Release 2 and 2.1 (OSR2), there may be less conventional memory available to MS-DOS-based programs. In these versions, the MEM /C command may show Himem.sys occupying approximately 44K of conventional memory. In the English version of OSR2, the MEM /C command shows Himem.sys occupying approximately 1K of conventional memory. This issue is known to affect the following language versions of OSR2: Brazilian, Danish, Dutch, Finnish, French, German, Italian, Norwegian, Portuguese, and Spanish."