RE: Getting a Windows 98 game to run on modern windows
January 15, 2019 at 5:57 am
(This post was last modified: January 15, 2019 at 5:57 am by FlatAssembler.)
In my experience, there are 3 basic reasons preventing programs for Windows 9x to work on modern versions of Windows:
1) The programmers assumed the most efficient method of doing Just-In-Time compilation is to store the machine code in .COM files and executing them. That was true in MS-DOS and Windows 3.x. That was not true in Windows 95 (since they were 32-bit, it involved putting the processor in the virtual 8086 and back into normal, which was inefficient), it's even less true on 32-bit Windows NT (because it involved running NTVDM, which was even less efficient), and it's even less true on 64-bit Windows (which doesn't have NTVDM, so the program that tries to invoke a .COM file crashes). A work-around is to use a 32-bit Windows rather than 64-bit.
2) The programmers assumed their programs would always be run on Windows 9x, rather than on Windows NT or its descendants (such as Windows 2000-10), so they didn't make it possible for them to deal with NTFS. That is, they made those programs rely on being able to modify their own files on the fly, which NTFS doesn't allow if a program is installed in "Program Files". Modern programs that do that need to invoke the User Account Control to ask for permission. Oddly enough, simply invoking "fopen" from MSVCRT.DLL to open a file, that is considered by NTFS to be a system file (since it's in "Program Files", the same directory the program itself is usually in), for writing, doesn't by itself invoke User Account Control, but instead returns a null-pointer and sets "errno" to 5. A very simple work-around is not to install the program into "Program Files", but into, for example, "My Documents".
3) The programmers assumed the then-current version of Windows would be the last one and programmed that program to try to detect an operating system itself instead of the available features. That's especially true for Direct-X-based games, because Windows 2000 supported less DirectX than Windows ME did. So, now that program tries to detect an operating system, incorrectly detects a modern OS as non-complying and refuse to run on it. A work-around is to set the "Compatibility Mode".
1) The programmers assumed the most efficient method of doing Just-In-Time compilation is to store the machine code in .COM files and executing them. That was true in MS-DOS and Windows 3.x. That was not true in Windows 95 (since they were 32-bit, it involved putting the processor in the virtual 8086 and back into normal, which was inefficient), it's even less true on 32-bit Windows NT (because it involved running NTVDM, which was even less efficient), and it's even less true on 64-bit Windows (which doesn't have NTVDM, so the program that tries to invoke a .COM file crashes). A work-around is to use a 32-bit Windows rather than 64-bit.
2) The programmers assumed their programs would always be run on Windows 9x, rather than on Windows NT or its descendants (such as Windows 2000-10), so they didn't make it possible for them to deal with NTFS. That is, they made those programs rely on being able to modify their own files on the fly, which NTFS doesn't allow if a program is installed in "Program Files". Modern programs that do that need to invoke the User Account Control to ask for permission. Oddly enough, simply invoking "fopen" from MSVCRT.DLL to open a file, that is considered by NTFS to be a system file (since it's in "Program Files", the same directory the program itself is usually in), for writing, doesn't by itself invoke User Account Control, but instead returns a null-pointer and sets "errno" to 5. A very simple work-around is not to install the program into "Program Files", but into, for example, "My Documents".
3) The programmers assumed the then-current version of Windows would be the last one and programmed that program to try to detect an operating system itself instead of the available features. That's especially true for Direct-X-based games, because Windows 2000 supported less DirectX than Windows ME did. So, now that program tries to detect an operating system, incorrectly detects a modern OS as non-complying and refuse to run on it. A work-around is to set the "Compatibility Mode".
