>I tried a handful of DOS games I had lying around, and always ran into one compatibility bug or another. Do the most popular ones even work for you? Doom, Duke Nukem, Quake, etc.?
Naturally FreeDOS was tested with popular (and unpopular) games. People being what they are, games are the front-line compatibility test for any OS in a replacement situation. Doom was always one of the first applications for stress testing on memory managers, not just under native DOS but running under Qemu and VPC 2004. Dukem Nukem, also. Quake, I don't explicitly remember, but other programs using the Quake engine were successfully tested by developers. Obviously, the larger count of end-users try a far greater range of programs and offer a stream of feedback on those.
It's difficult to address your comments in detail without knowledge of what you tested and when, but they sound as if they are based on versions of FreeDOS from two or more years ago. Probably the biggest breakthrough for running the Doom et al games with the standard FreeDOS EMM386 was when VCPI support was added a couple of years ago -- prior to that you could only run DOS-extended games under HIMEM or,if supported, without any memory manager. That restriction hasn't been necessary for a while now.
For the last year, most changes to FreeDOS have been to improve compatibility with more and more applications and clear up edge conditions, e.g. fix problems with free XMS memory >512M for DPMI hosts. If anything, I think the claims of FreeDOS compatibility for running different DOS applications has generally been understated. (COMMAND shell and Windows/advanced environment extensions compatibility, not so much, although I understand that improvements in those areas remain under vigorous development). At least twice in the past an open invitation has been made on the development and user lists to report ANY programs which failed to execute under FreeDOS, but worked with MS-DOS. Too, FD Bugzilla has been scoured for reports of failing applications which did not fail under MS-DOS, with all reports tracked, tested, and debugged if the application was available. I don't recall seeing your report there, but I might have missed it.
What some may not understand is that FreeDOS has to match completely undocumented MS-DOS behaviors and quirks to run well-known applications. I can give two examples I personally know the details on. First, some DOS-extended Borland applications depended upon an internal version of DOS to be set to a particular value, not because it wanteed that value, but because the Borland DPMI host didn't properly set CX and expected a zero CX value to drop through -- as it did with MS-DOS -- or else it blew the stack. And a compatibility fix for QuickBASIC 4.0 compiled programs was made immediately prior to FD 1.0's release because QB4 depended on MS-DOS allowing a re-release of a freed block of memory without error while spanning multiple unrelated memory management calls. Tracking those sorts of problems can be painful, but it's been done, and those are just two examples of non-FreeDOS-sourced problems successfully resolved. And for that matter, I know of one class of DOS-extended applications which run better under FreeDOS than MS-DOS because the applications made inappropriate assumptions about memory that FreeDOS works around.
All in all, there has been a great deal of effort made to make FreeDOS run all applications that MS-DOS will run. Doubtless a few problematic applications remain, and certainly particular user environments or setups may have issues as well. But I don't think calling out a list of popular games or other DOS programs will trigger a general failure report across most systems.
Slashdot Mirror
Naturally FreeDOS was tested with popular (and unpopular) games. People being what they are, games are the front-line compatibility test for any OS in a replacement situation. Doom was always one of the first applications for stress testing on memory managers, not just under native DOS but running under Qemu and VPC 2004. Dukem Nukem, also. Quake, I don't explicitly remember, but other programs using the Quake engine were successfully tested by developers. Obviously, the larger count of end-users try a far greater range of programs and offer a stream of feedback on those.
It's difficult to address your comments in detail without knowledge of what you tested and when, but they sound as if they are based on versions of FreeDOS from two or more years ago. Probably the biggest breakthrough for running the Doom et al games with the standard FreeDOS EMM386 was when VCPI support was added a couple of years ago -- prior to that you could only run DOS-extended games under HIMEM or,if supported, without any memory manager. That restriction hasn't been necessary for a while now.
For the last year, most changes to FreeDOS have been to improve compatibility with more and more applications and clear up edge conditions, e.g. fix problems with free XMS memory >512M for DPMI hosts. If anything, I think the claims of FreeDOS compatibility for running different DOS applications has generally been understated. (COMMAND shell and Windows/advanced environment extensions compatibility, not so much, although I understand that improvements in those areas remain under vigorous development). At least twice in the past an open invitation has been made on the development and user lists to report ANY programs which failed to execute under FreeDOS, but worked with MS-DOS. Too, FD Bugzilla has been scoured for reports of failing applications which did not fail under MS-DOS, with all reports tracked, tested, and debugged if the application was available. I don't recall seeing your report there, but I might have missed it.
What some may not understand is that FreeDOS has to match completely undocumented MS-DOS behaviors and quirks to run well-known applications. I can give two examples I personally know the details on. First, some DOS-extended Borland applications depended upon an internal version of DOS to be set to a particular value, not because it wanteed that value, but because the Borland DPMI host didn't properly set CX and expected a zero CX value to drop through -- as it did with MS-DOS -- or else it blew the stack. And a compatibility fix for QuickBASIC 4.0 compiled programs was made immediately prior to FD 1.0's release because QB4 depended on MS-DOS allowing a re-release of a freed block of memory without error while spanning multiple unrelated memory management calls. Tracking those sorts of problems can be painful, but it's been done, and those are just two examples of non-FreeDOS-sourced problems successfully resolved. And for that matter, I know of one class of DOS-extended applications which run better under FreeDOS than MS-DOS because the applications made inappropriate assumptions about memory that FreeDOS works around.
All in all, there has been a great deal of effort made to make FreeDOS run all applications that MS-DOS will run. Doubtless a few problematic applications remain, and certainly particular user environments or setups may have issues as well. But I don't think calling out a list of popular games or other DOS programs will trigger a general failure report across most systems.