China DOS Union

Complete Guide to Replaying Old Games Under New Systems
December 10, 2003 Author: Popular Software “Tiandi Jie - You Shen Huan Yun”



An era of farewell, faded memories—Complete Guide to Replaying Old Games Under New Systems, reposted from Popular Software 2003 issues 8 and 9

Editor’s note: There is no need to erect monuments and write biographies for those classic games of the past. For old players, their meaning is no longer only the key that opened the door to computers, but even more a kind of memory about time—if you went through those years together with Popular Software, that memory may be even deeper. Of course, there are also many players now who only came into contact with some old games under special circumstances. Although they may no longer be able to make sound, and lack gorgeous animation even more, their wonderful plots and dialogue, rigorous design and art style may still give you a special attraction. But games are still application software after all, and any application software must strictly follow the rules laid down by the operating system it resides in. Therefore, as Microsoft released new operating systems year after year, countless software programs ended their once-glorious days under the new rules, and of course this included a large number of classic old games—yes, there is no need to sigh for them, because there will always be better software and more exciting games constantly appearing. It is just that, have these things of the past really already become—an era of farewell, faded memories? You might as well read this article with that question in mind.

　　“New” and “old” are of course relative, but before beginning it is necessary to define the scope of our discussion. Here “old” refers to operating systems before Win98, including DOS and Win32/95, while new systems refer to Win98/2000/XP. There is no doubt that many old games are very worth revisiting, but the methods of revisiting them vary. Some people will buy “antique-class” machines such as Pentium 133, specially for playing old games; but old PCs are not something everyone can buy, and being truly willing to make such a big move just to play old games counts as hardcore-player level. So the typical solution is to use multiple systems, with one system installed with MSDOS 6.22+Win32 or Win95. But this method will also run into the difficult problem of new video cards and sound cards being incompatible with old games.

　　In fact, most users will try old games on their existing systems. In this respect, users of Win98 seem to have more smiles than users of WinXP (the “older” the better? Whether this is accurate, please see below). Apart from some games with very good compatibility, most can no longer run, and even so-called highly compatible games basically cannot play the original game sound. So, to achieve a perfect revisiting effect, is it destined that we must adjust hardware and install multiple systems? After the author’s hard exploration, I found that this is not the case; most old games can still find suitable solutions under new systems.
　　
I. Replaying DOS games

　　Among the classic old games people encounter, DOS games undoubtedly account for an absolutely large proportion. Yet when games found with great effort are double-clicked on their main executable under Windows, all kinds of inexplicable situations appear. Under Win98 it is somewhat better, at least it lets you see an error message (of course, in general we do not understand that error message); as for Win2000/XP, often a black screen flashes past, and in some cases there will also be an illegal access-address prompt. In short, it leaves people baffled.

　　However, these various failures to run normally are not entirely due to incompatibility between new systems and old games. Users familiar with DOS all know that DOS is an open system, and software operation under it is not mostly “fool-style” as under Windows. In particular, multimedia software under DOS (such as games) often needs special settings for the running environment to run normally. If you only “double-click,” that of course does not fit the DOS “style.” Therefore, when a DOS game cannot be replayed under a new system, in essence both compatibility and settings may be problems. This also suggests some ideas for solving the problem.

　　Because the running environment of DOS games differs greatly under different systems, the following will mainly describe solutions under WinXP, and then return to the Win2000 and Win98 environments to discuss replaying methods. There is another reason for writing this way: in fact, from Win98 to 2000 and then to XP, the operating system’s compatibility with DOS keeps improving, which is the opposite of what we imagine—this will soon be seen below.
　　


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
KO’s words:
This post is very good, and many parts are explained very thoroughly. For example, the memory knowledge is very worth reading.
I couldn’t resist reposting it.
It is not only about solving the problem of playing old games; mainly, you can learn a lot of DOS knowledge. Recommended!!!

(I) Solutions for replaying DOS games under WinXP

　　WinXP has much in common with Win2000 in DOS support, so much of this section also applies to Win2000. But after all there are still some differences between the two, so after this section I will talk about where Win2000 differs. And although Win98 is far removed from WinXP, some principles are also shared.

　　First we need a simple understanding of the environment in which DOS commands run under WinXP. Most users familiar with this system will think that the so-called DOS environment is of course the Cmd.exe command-line window. In fact it is not so. Cmd.exe provides support for all types of programs in the system, including 32-bit and 16-bit; the true 16-bit DOS command window needs to be provided by Command.exe. In WinXP this file is located under the system drive\Windows\system32 directory. Figure 1 compares the Cmd and Command windows.

　　However, whether you execute 16-bit DOS commands in a Cmd window or directly open a Command window, in fact they are all supported under NT by a process named NTVDM.exe, which provides a DOS virtual machine (NT Virtual DOS Machine, abbreviated NTVDM). Therefore it can be said that WinXP has completely freed itself from dependence on 16-bit DOS. The so-called DOS program running environment on this system is only a completely virtual PC! Understanding this is very important, because it indicates that this virtual “PC” has nothing to do with your real hardware; all hardware environments are virtualized, so better compatibility can be achieved.

　　How does the virtual machine imitate the startup process of a real DOS system? Users familiar with DOS will have unspeakable joy and pain toward the two files Config.sys and Autoexec.bat—they are simply too important to system configuration. When DOS starts, it first configures drivers according to Config.sys, then executes commands in Autoexec.bat. Can their shadows still be found in NTVDM? Since it is said to be “truly virtual,” of course there should be: by default they are located under Windows\system32, only the names have been slightly changed, to Config.nt and Autoexec.nt respectively. You can open these two files with Notepad for editing, but it is best to back them up before editing, in case of accidents.

　　After understanding these things, we can begin trying to solve practical problems.

1. Solving memory problems

　　The reason most old games cannot run properly is that there is “not enough” memory. Users who did not come through the DOS era will surely be extremely skeptical about those words “not enough”, but in fact it really is not enough. DOS has its own unique memory usage scheme. This scheme is actually rather complicated, but it is crucial to solving the problem. Still, we do not need to understand every detail here, so a simple illustrated explanation follows (if it feels hard to grasp, you can skip this part first and come back to it later if the examples below are unclear):

　　As shown in Figure 2, if no special memory management tools are loaded, DOS can recognize at most only 1MB of memory. Of this 1MB, 384kB is reserved for things such as the system, hard disk controller, video memory, etc.; this is called the Upper Memory Block (UMB). The remaining 640kB is called Conventional Memory. But these 640kB are not all free either. After system startup, part of it is already occupied, so ordinary programs can only use the remaining Free part of conventional memory. Understanding this is very important.

　　However, the amount of memory provided by the virtual machine definitely exceeds 1MB. This part is called extended memory. Because its use must follow the eXtend Memory Standard, it is abbreviated as XMS. To use XMS, you must load the Himem.sys driver in Config.sys (now Config.nt). Of course, at the very bottom of extended memory, near that 1MB area just mentioned, there is nearly 64kB that DOS can access without using the XMS standard. This memory area is called the High Memory Area. DOS often keeps part of itself resident in this area (MS-DOS resident in High Memory Area), so as to leave as much conventional memory free as possible for applications.

　　Finally, the concept of expanded memory EMS (short for Expanded Memory Standard) is very important but also rather hard to understand. Simply put, it is a deceiver of the CPU: to the CPU it “looks like” it is in the UMB (within 1MB, freely usable), but in reality it is in XMS, being part or all of XMS. In this way, programs can effectively use extended memory beyond 1MB. But to make the CPU recognize expanded memory, an Expanded Memory Manager, EMM, must be loaded in Autoexec.bat (now Autoexec.nt); under DOS this is generally EMM386.exe. One thing must be noted here: because EMS occupies XMS space, the Available part of XMS will decrease. Old DOS was a very free system, and games running on it could freely decide whether to use EMS, or even how much EMS they wanted. Otherwise... hehe, they would simply strike.

　　From the above, there are two kinds of memory closely related to our topic: conventional memory and expanded memory. These two also happen to be the “killers” for countless DOS programs running under new systems. Fortunately, now that we know both ourselves and the enemy, we can go to war. The examples below were all done under WinXP Pro SP1.
　　
　　(1) Correct configuration of expanded memory EMS

　　Example 1: Zhongguancun Revelations

　　In the game installation directory h:\dosgame\ZGC there is a Play.bat batch file. Double-clicking it will run it. However, doing so only results in a black window flashing by. But how could we let such a famous game slip away so easily? We had to get to the bottom of it. So right-click the icon corresponding to Play.bat and choose “Edit”. The system calls Notepad to open the file, and inside are two commands: runqbj and go, corresponding to Ruqbj.com and Go.bat in the same directory. Clearly Go.bat is also a batch file. Opening it in Notepad shows 3 more commands: univbe, game, and univbe/u. These 3 correspond to two executable files: Univbe.exe and Game.exe. To find the cause, I executed the runqbj, univbe, and game commands one by one.

　　In the “Start” → “Run” dialog box, enter “command” and press Enter. In the opened Command window, change to the game installation directory and enter the 3 command lines one by one. After executing Univbe, it reports that it cannot find a supported graphics card (Figure 3). Ignore that for now. After executing the final command Game, a line appears on screen: EMS memory manager not found. So could it be that WinXP’s NTVDM simply does not load EMM by default?

　　That is exactly the case. In the Config.nt file mentioned earlier, in the section describing EMS, I found this passage (Figure 4): the size of EMS is determined by the Pif file. This Pif file is either the shortcut of the DOS program, or by default _default.pif in the Windows directory of the system drive. If EMS is set to “0” in the Pif file settings, then EMM will not be loaded.

　　Everyone is surely familiar with Pif files and their icons. Since the Win3X era, in order to provide DOS programs with customized memory settings in the windowed environment, Microsoft designed the concept of “Pif”. It looks like just a shortcut to the original program, but in fact a large number of custom settings can be made inside it. Since no Pif file could be found in the game installation directory, according to the explanation above, double-clicking would use the settings in _default.pif. So we find _default.pif, right-click it, and choose “Properties” from the pop-up menu (Figure 5). In the dialog box that opens, click the “Memory” tab, and there we find EMS set to “None” (Figure 6)! Zhongguancun Revelations requires EMS support to run, so of course this setting causes errors. And Command.com, which we ran just now, follows the same rule; its memory page in the properties dialog is exactly the same as Figure 6.

　　So you have probably already thought of the solution. Since WinXP cannot configure memory for .bat files, you can: 1. change the memory settings in _default.pif; 2. change the memory settings of Command.com, and run Play.bat in its window. But changing _default.pif is clearly not advisable, because this file is the default Pif configuration for all DOS programs. Some programs do not need EMS, and some will not run if EMS exists at all. So let us try setting both EMS and XMS in the memory configuration of Command.com to “Auto” (Figure 7). Then open the Command window again, go to the installation directory as above, and enter the “play” command. After pressing Enter, the game’s opening screen appears to our delight (Figure 8).

　　So what exactly does “Auto” mean? Enter the Command window again and execute the command line “mem”. This command shows the current memory allocation and usage (Figure 9). It turns out that “Auto” defaults to allocating 4MB of EMS and 19MB of XMS (of which only 15MB is available). Incidentally, the first line shown is the 640kB conventional memory mentioned earlier, and the third line is very important: it indicates the remaining conventional memory after NTVDM starts, which of course is also the Largest executable progaram size.

　　Still, every time going through Command and then finding Play.bat is somewhat troublesome. There is actually a simpler way. Since the first line in Play.bat, runqbj (qbj? Qiu Bojun? hehe), corresponds to Runqbj.exe (remember, not a .bat file), right-click the file icon of Runqbj.exe and enter “Properties”. Set its memory page the same way as Figure 7 (of course, you can also set EMS to a value above 4MB). After confirming, a Runqbj.pif file will be generated in the current directory. After that, double-clicking Play.bat will enter the game smoothly.
　　
　　Reinforcement: Romance of the Three Kingdoms IV

　　In the game installation directory San4 there are two run files: san4.com and san486.com. Clearly the latter is configured for 486 machines and should have better game performance when run. However, after clicking it, although the KOEI opening screen appears normally, afterward the screen flashes and then shows a line: Not Enough Memory. At this point you should have some understanding of those words “not enough”. Since this was launched by direct double-clicking, one may guess it is still an EMS problem. Following the method above, set EMS for san486.com to Auto, and the game will run smoothly (Figure 10).
　　
　　Reflection and summary: Problems of this kind are fairly concentrated. Because directly double-clicking an executable starts NTVDM with no EMS support by default. For .exe and .com files, just set EMS properly in Properties. If it is a .bat file, then refer to the indirect modification method described above.
　　
　　(2) Correct configuration of conventional memory

　　Example 2: Dragon Knight 4 (Dra4)

　　This game, produced by ELF, won the appreciation of many players through its clever plot design. Let us see whether it can run normally under WinXP. First, according to the game instructions, it must be installed in the root directory of drive C. Enter the installation directory c:\dra4 and double-click Play.bat. Again the result is only a black screen flashing by. So, using the method from Example 1, open Play.bat with Notepad. It turns out it contains only one line: dra4 start.mes H x C. This is a command run with parameters; the main program is dra4. But in the installation directory there are two executable dra4 files: dra4.com and dra4.exe. Here you need to know that .com files have a higher execution priority than .exe. So we modify the properties of dra4.com and set EMS to 8192kB. But contrary to our wishes, after double-clicking Play.bat the black window still flashes by...

　　So let us return to the memory knowledge we just discussed. Besides EMS, another memory killer is conventional memory. Do you still remember the “Largest executable program size” in Figure 9 above? Is it possible that even 581 120 bytes of memory is still not enough for dra4.com? We might as well try clearing out some space from conventional memory.

　　Here we first need to check what programs are loaded by default when NTVDM starts. Again enter “command” in the “Run” dialog to open a DOS command line window, and type “mem /c |more” to view detailed current memory usage page by page (Figure 11. Users familiar with DOS may ask why not use the “/p” parameter. That is because this parameter is no longer supported in NTVDM, so we have to use “|more” instead). From the figure, several big occupants of Conventional Memory can be seen: MSDOS, MOUSE, DOSX, especially DOSX, which alone takes up 33.9kB. You should know that every inch of conventional memory is contested territory.

　　In fact DOSX is the command executed by NTVDM in order to support DPMI (Dos Protected Mode Interface) type programs. Protected mode allows programs to obtain more memory resources, but games using DPMI must all come with a DOS extender, usually DOS/4GW v1.96, filename DOS4GW.exe. So to determine whether a game needs DOSX support, you only need to check whether there is a DOS4GW.exe file in its installation directory.

　　Clearly no DOS4GW.exe was found in the Dra4 directory, so it is judged that these 33.9kB occupied by DOSX can be completely freed. But by what method? Do you still remember the Autoexec.nt and Config.nt mentioned earlier? I said just now that these are two initialization files that bring both joy and sorrow. Let us see what kind of joy they can bring us here.

　　Because these two files are very important to the whole NTVDM system, you should be careful when modifying them. Of course you can back them up, but the best method is still to use the custom initialization file function provided by Win2000/XP. First copy Autoexec.nt and config.nt from System32 into the c:\dra4 directory. Then find the dra4.com file, enter its Properties dialog as before, and on the Program tab click the “Advanced” button (Figure 12). In the Windows PIF window that pops up, specify dedicated initialization files again (Figure 13), changing their locations to “c:\dra4\autoexec.nt” and “c:\dra4\config.nt” respectively, then click “OK” twice.

　　Next we need to modify these two custom initialization files. Open Autoexec.bat with Notepad, and you will find a whole bunch of lines beginning with “REM” (meaning these lines are comments and will not be executed). It is worth noting that there are 3 lh commands (Figure 14). These load the following programs into upper memory as much as possible (not guaranteed to succeed). Here, mscdexnt.exe, redir, and dosv provide NTVDM with support for CD-ROM, network (so you can even play network versions of classic games!), and DPMI respectively. In this example none of the three are needed, so add “REM” in front of each of these 3 lines to disable them (in fact, removing DOSV alone would be enough, but let us go all the way). After editing, remember to save. Then return to the Dra4 directory and double-click Dra4.com. You will find it works immediately, just as expected (Figure 15). One reminder: while modifying Autoexec.nt, you still need to configure the memory parameters of Dra4.com properly, especially EMS.
　　
　　Reflection and summary: This example does not require DPMI support. But what if you run into a game that needs DPMI and still cannot get enough conventional memory? We still have a way. Just modify the Config.nt file and add a line “EMM = RAM”. With this configuration, programs such as MOUSE and DOSX will be moved partly or completely from conventional memory into upper memory, thereby freeing a large amount of conventional memory (Figure 16. This is the result viewed with the “mem /c |more” command after modification. As can be seen, DOSX has entered upper memory, and the available conventional memory has reached as much as 615.3kB). Finally, it should be noted that EMS and available conventional memory obviously have a potential resource conflict. The reason the system does not set EMS to “Auto” by default is that after EMS is enabled, some programs that originally resided in upper memory will be pushed into conventional memory instead, causing available conventional memory to decrease. Therefore, whether to use EMS should be chosen according to the needs of the DOS program.

2. Solving sound and other compatibility problems

　　From the explanation above, memory problems under WinXP can only be counted as configuration difficulties, while this section deals with true compatibility problems. First of all, it should be made clear that the sound card here does not mean the sound card in your real machine, but the sound card emulated by NTVDM.

　　From WinNT to Win2000, the virtualized DOS version was always 5.0, and the hardware provided by NTVDM matched that DOS version, so in effect the “configuration” was fairly low. As a result, support for DOS games was also poor. Most crucially, it did not support the standard compatible sound card mode since the DOS 6 era—Sound Blaster. WinXP, however, made a breakthrough in this respect. Its NTVDM has direct built-in support for Sound Blaster 2.0, so compatibility with DOS programs is much better. In addition, WinXP inherits from Win2000 the default drivers for mouse, CD-ROM, network card, and DOS/4GW.

　　However, WinXP’s sound card support is both a blessing and a curse: although a sound card is provided, it only provides 2.0 support, while most DOS programs support Sound Blaster 16, so there may be potential conflicts. In good cases, even if the program cannot detect the sound card, it still runs normally. But some games may crash directly.

　　Besides that, other compatibility problems may also exist in WinXP, for example, programs may be unable to make arbitrary settings to the floppy drive, and the example below will reflect this comprehensively.
　　
　　Example 3: Richman 3

　　This was one of the DOS era games most loved by girls. Even today it is still very enjoyable. However, when you go to the game directory c:\rich3 and double-click Play.bat, after a lot of fussing by the system and even seeing the opening SoftStar animation, it still ends with a frozen black screen. Never mind, we are already used to it. So use Notepad to open Play.bat and see what is going on. Inside is a command line: “subst a: .” Users familiar with DOS know this command is used to map the current directory as drive A, and the game will treat drive A as the CD-ROM. This will naturally lead to compatibility problems, because the virtual machine cannot directly access hardware, and the floppy drive under WinXP control obviously cannot be mapped so casually.

　　So I thought of disabling the floppy drive first. Fortunately, WinXP can disable the floppy drive without rebooting. Right-click “My Computer” and choose “Properties” to open the system properties dialog. Then choose “Hardware” → “Device Manager” in sequence (Figure 17). In Device Manager, expand “Floppy disk drives”, right-click “Floppy disk drive” in the menu, and choose “Disable” (Figure 18. After the game ends, do not forget to repeat this process and choose “Enable” here). After confirming, go back to the rich3 directory and double-click Play.bat again. This time it can already enter the opening screen (Figure 19), but as soon as you select a character and start the game, the entire NTDVM system crashes—not just part of it, but a total crash. After ending the task, even Command.com cannot run, and only a reboot can solve the problem.

　　This puzzled me for a while, but since video could be output, the problem was very likely with the sound card virtualized by NTDVM. So I opened Autoexec.nt under System32 with Notepad. The last part of the file is a description of the built-in sound card (Figure 20). As mentioned earlier, it explains that WinXP’s NTDVM provides only Sound Blaster 2.0 support. At the end of the file it explains that this sound card can be disabled, so following the instructions, I added “REM” before the line “SET BLASTER=A220 I5 D1 P330 T3”, and at the same time removed the “REM” before the line “SET BLASTER=A0”. Double-click Play.bat again, and indeed it enters the game smoothly (Figure 21).

　　Disabling the sound card can solve quite a few cases where games cannot run normally. But at this point we discover that not a single game has yet been able to produce sound normally. What kind of replaying of the old days is that, if memory itself loses its color? Although I once managed through certain settings to make a few classic games such as A-Mao and A-Gou produce sound normally (a very good feeling), the great majority of games do not fully support Sound Blaster 2.0. For example, in Empire of the Angel 2, even though the voice is normal, the background music cannot be heard at all. Therefore I will not go on here about how to reproduce sound through system configuration. But the more crucial reason is that we can use one software tool. It not only completely solves sound card compatibility problems, but more importantly, it resolves the greatest limitation of the NTDVM system—it can almost completely reproduce the original sound of DOS programs. This software is VDMSound.

　　VDMSound is free software conforming to GNU standards, and the author’s free development spirit is admirable. The latest version is 2.0.4. The sound platform it provides for NTDVM includes the MPU-401 interface (for high-quality MIDI sound effects), the Sound Blaster compatible interface (compatible with SBPro 1/2, SB 1.5/2.0/16/AWE 32/32/64, and able to provide digital and FM/AdLib sound), and even a game control interface (so you can use gamepads and joysticks)! VDMSound has nothing to do with the real sound card in your machine. It can even output the sound information generated by DOS programs into disk files. Let us now talk specifically about how to use it.

　　For software download, you may refer to: http://www.onlinedown.net/vdmsound.htm. At the same time, it is recommended that you download the patch package provided by the author: http://vdmsound.sourceforge.net/files/VDMSound.2.0.4.update1.zip. The software installation process is fairly simple: just click “Next” all the way. For convenience of explanation below, let us assume this software is installed in the d:\vdmsound directory. After installation, extract all the files in the patch package and copy them into d:\vdmsound, overwriting the original files.

　　The specific method of use is even simpler. Still using Richman 3 as an example, just right-click Play.bat and choose “Run With VDMS” from the menu (Figure 22). On first use, the software will pop up a small Tips window (Figure 23). I suggest that if conditions allow, you read every tip in it carefully (the software has a small bug in that it does not automatically change Tips, so reading them one by one is better). You can learn quite a lot from it. Next the software quickly does a bit of initialization work. Once the black DOS screen passes, you can hear the familiar music!
　　
　　Example 4: Empire of the Angel II

　　Now that we have VDMSound, of course we want to use it to launch Play.bat in the game installation directory. But unexpectedly, amid the lively sound we are greeted by a beautiful prompt screen (Figure 24): it turns out this game requires at least 575kB of conventional memory. According to the explanation above on memory configuration, first check whether there is DOS4GW.exe in the game installation directory—none is found, so it can be determined that it does not use DOSX. But VDMSound is being used. Do we still modify the Autoexec file in the same way?

　　The answer is yes, except that now both it and Config have moved to the d:\vdmsound directory, and the file extension has changed to “vdms”. However, the author was very thoughtful and already registered this extension to open with Notepad by default. Thus the modifications we discussed above, such as disabling DOSV, can still be carried out smoothly. You can open Autoexec.vdms and add “REM” before the line “lh %SystemRoot%\system32\dosx.exe”. However, below I will provide a method that makes this process simpler.

　　The author of the software also provided a graphical configuration plug-in for VDMSound: VDMSoundLanchPad. For its download address, you may refer to: http://vdmsound.sourceforge.net/files/VDMSLaunchPad.v1.0.0.7.zip. After downloading, extract all the files in this archive into the d:\vdmsound directory, then run install.bat inside it. When the registration prompt appears, click “OK” to complete installation (Figure 25). Below, using Empire of the Angel II as an example, I will explain how to configure it through the graphical interface.

　　1 Right-click Play.bat in the game directory, and choose “Run With VDMS” with the music mark from the right-click menu (Figure 26).

　　2 In the settings window that pops up, since special settings are needed, choose “Setup a custom configuration”, then click “Next” (Figure 27).

　　3 In this step, choose “Create a new configuration from scratch”. Of course, if this is not your first time using it, and you already have a previous game configuration identical to the one needed now, you can also choose “Reuse an existing configuration” (Figure 28).

　　4 In this step, click “Advanced” to enter advanced settings (Figure 29).

　　5 This should look familiar, right? In fact the author simply integrated the Properties items designed by Windows (Figure 30).

　　6 Enter the “Compatibility” tab for compatibility settings (Figure 31). Here EMS and XMS can be configured. We accept the default settings of 4MB and 16MB. Below that there is also an option for basic VESA support (Enable Basic VESA Support) (this is especially useful in Win2000, because it does not support VESA window mode). In addition, it includes support for CD-ROM and network, and of course also DPMI (DOSV). If you still remember, you will notice the latter 3 items correspond exactly to the 3 LH commands in Autoexec.nt mentioned earlier in this article. Because Empire of the Angel II does not need DOSX, the DPMI item can be unchecked.

　　7 “Sound Blaster” is used to configure the Sound Blaster card. For example, the IRQ here is 7, while some games default to using 5—in short, if you still cannot get sound even with VDMSound, you can make some changes here (Figure 32).

　　8 There are more settings here, and I will not go through them one by one. Everyone can explore on their own. Click “OK” to return to the interface in Figure 29, choose “Next”, and in the final dialog box you can select “Remember my settings”, so that this configuration can be used as the default next time (Figure 33). Click “Finish”, and the software will guide you into the game screen (Figure 34), while also generating a Play.vlp icon in the game directory. In the future, clicking this icon will enter the game using the configuration just made. If you want to modify it, you can right-click it, enter the “VDMSound” tab in the properties dialog, and click the “Advanced” button.

　　Example 5: Uncharted Waters 2

　　This example is mainly to explain how to work with VDMSound to solve the problem of games running too fast. The Uncharted Waters 2 chosen here is truly a nostalgic classic, and this game has very good compatibility. It can run smoothly even under WinXP’s default settings. The only flaw is that on my machine, with a Celeron 1.8GHZ CPU, once you leave port, the speed becomes astonishingly fast, making it impossible to control the direction of the ship at all—and in a blink several days have passed. In the end there was no way around it but to sail step by step in a “targeted” manner, yet a large part of the fun of the Uncharted Waters series lies precisely in wandering around at sea, so being forced into this kind of stepping mode really loses a lot of fun.

　　To solve this problem, special software for slowing things down is needed. Here I chose Speedset, also written by the author of VDMSound. The reference download URL is: http://vogons.zetafleet.com/attachment.php?s=&postid=4739. After downloading, first extract the two files Speedset.dll and Speedset.exe from the archive into d:\vdmsound. Next we will use it together with VDMSoundLanchPad to achieve the slowdown function.

　　Right-click Play.bat in the installation directory of Uncharted Waters 2, and follow the method above to enter the VDMSound advanced configuration interface. Enter the “Dos Enviroment” tab, and you will find that additional command lines can be added in Config and Autoexec. Here you need to add the Speedset.exe command just mentioned in the Autoexec section. Parameters should be added after Speedset to change the speed. After many tests, the parameter after it should be set to “+1”. The exact command line to add is “lh d:\VDMSound\speedset.exe +1” (Figure 35; you may set it according to your own situation). Next choose the “Performance” tab, select “Try to reduce CPU usage”, and drag the slider above it all the way to the left to “Low usage”. This option makes the game run more smoothly. At the same time, ordinary WinXP users had better adjust the “DMA Servicing” below from 5/15 to a slower rate, such as 5/10 (Figure 36).

　　After adjusting it this way and clicking “OK”, the game is entered smoothly (Figure 37). The sailing speed is indeed reduced, and control becomes smoother as well. Finally, it should be noted that although after using LanchPad the configuration becomes very simple in the above two examples, this does not mean VDMSound and Speedset can only be used through the graphical interface. In fact both commands can be called directly in the Command command line window. Using my installation path as an example, you only need to switch to the d:\vdmsound directory before running the program, type the commands “VDMSRun” and “Speedset” respectively and press Enter, then run Play.bat. This can likewise achieve sound and slowdown.

II) Additional notes on Win2000 relative to WinXP

　　In terms of memory configuration, Win2000 and WinXP follow exactly the same system, so there is no need to say more. As for NTVDM, the biggest difference between Win2000 and WinXP lies in support for sound card and video card standards. As already mentioned earlier, Win2000 provides no sound card support at all, so there is no possibility of sound, and naturally no possibility of sound-card-related conflicts either. The same old sentence applies: it is both a blessing and a curse. Fortunately there is VDMSound, so basically in this respect there is no difference from WinXP anymore.

　　Relatively speaking, support for video card standards is Win2000’s fatal weakness. The standard video programming interfaces in the DOS era were VESA 1.2/2.0, and many DOS games used these standards in programming. WinXP supports both quite well, so there is no need to worry. Win2000 also provides some support for the VESA standard, but it must be in full-screen mode! For example, the 486 version of “Romance of the Three Kingdoms IV” and “Zhongguancun Apocalypse” mentioned in this article cannot be run by double-clicking under Win2000 even if memory has been configured properly (Figure 38; the error message says it cannot find the VESA BIOS). The reason is that after double-clicking, the program starts running in windowed mode first. Of course, you can run Command.com (remember to modify Command.com’s properties so that it supports EMS), then press Alt+Enter to switch to full-screen mode, then change to the game installation directory and execute the corresponding command. In this way you can enter the game smoothly (you can also run VDMSRun in the VDMSound installation directory beforehand to get sound effects). But the annoying thing is that once the picture appears, the mouse has a problem: it can only move within less than the upper half of the screen, so naturally the game cannot be played normally.

　　The author of VDMSound once revealed the idea of developing a VESA-compatible interface, but there has never been any follow-up. I have also never been able to find a suitable solution. Fortunately, WinXP will sooner or later be the upgrade choice for home Win2000 users. But users who are still working under Win2000 for the time being will just have to endure the pain of this compatibility problem.
　　
　　Editor’s note: this article has actually explored how to play DOS games under the NT system. The next part will have a new focus: DOS game solutions under Win98, the restoration of Win32/Win95 games under WinXP/2000/98, and an in-depth introduction to the ultimate solution, Virtual PC—the content is wonderful, so do not let it pass you by.

(3) Solutions for replaying DOS games under Win98

　　To summarize the above, the most fatal bottleneck for DOS games is memory management, followed by compatibility support for new hardware. But for Win98, the solutions are somewhat different from those under the NT systems above. Generally speaking, they require you to have a fairly good understanding of basic DOS knowledge.

　　1. Solutions for memory management

　　As mentioned earlier, because the DOS system is unlike Windows, which can manage memory intelligently, its memory management settings must all be adjusted manually. In the examples of solving memory problems above, you will find that when games report insufficient memory, we generally solve it by modifying the specific settings in Autoexec and Config. This method is equally applicable to Win98, but there are some practical differences.

　　Everyone knows that when Win98 was introduced, it was advertised as coming with DOS, which Microsoft called DOS 7.0. In the “Programs” group of the Win98 Start menu, you will see a shortcut called “MS-DOS mode”, pointing to “c:\windows\command”. In fact this is only a pseudo-DOS, but it is quite different from the DOS Command Prompt under the NTVDM system in WinXP/2000/NT.

　　Old versions of DOS (6.22 and earlier) always loaded the management programs in Config.sys and Autoexec.bat after startup, for memory management and system configuration. But from Win1.0 to Win98, the startup of the windowing system was always based on DOS, that is, DOS starts first, and then Windows starts. Win32 users all know that Windows startup is achieved by typing the “Win” command at the DOS command line. In order to execute this Win.com, Config and Autoexec had to load the memory manager EMM386.exe and the high memory driver Himem.sys, etc. However, by the time of Win98, Win.com still exists (but it executes automatically at startup by default), and it has become intelligent enough that no settings in those two initialization files are required for normal operation. Therefore, you can see that these two files in the root directory of drive C are empty (Config.sys is a system file and hidden by default; this needs to be changed in “Folder Options”: Figure 1).

　　But Config and Autoexec in Win98 are still important, because they control the memory and system configuration of “MS-DOS mode”. In other words, when you open an “MS-DOS mode” window in Windows, or run the Command.com command, or even double-click the icon of a DOS program, the system will choose Config and Autoexec for this DOS running in compatibility mode—and they are located in the root directory of drive C. However, it should be explained that if you modify these two files, you must reboot the system before the changes take effect. Specific examples follow. In the examples we will try to use the same games as above as much as possible, so that everyone can compare and analyze them.
　　
　　(1) Correct configuration of expanded memory EMS

　　Example 6: Romance of the Three Kingdoms IV

　　Different from what was described above, if no adjustments have been made, when you enter the properties of San486.com you will find that under Win98 you cannot set EMS memory at all, because the system has not automatically loaded memory management tools (Figure 2). So if you run it, the game will of course report “not enough memory”. Therefore we first need to add the setting item for expanded memory EMS. Open the Config.sys file on the system drive with Notepad, and add the following two command lines (Figure 3):

　　DEVICE=C:\WINDOWS\HIMEM.SYS

　　(This line is very important. It means loading high memory management so DOS can use high memory.)

　　DEVICE=C:\WINDOWS\EMM386.EXE ram

　　(EMM386.exe is used to manage expanded memory. Common parameters are “ram” and “noems”. The latter can free more conventional memory than the former, but many DOS programs do not support the “noems” parameter, so its range of use is narrower.)

　　After saving the file, reboot the machine, then open the properties of San486.com again. The expanded memory EMS setting item is back (Figure 4). According to the earlier explanation, just set it to “Auto”. That solves the problem of expanded memory EMS, and double-clicking San486.com will let the game run smoothly (Figure 5).
　　
　　(2) Correct configuration of conventional memory

　　Example 7: Dragon Knight 4 (Dra4)

　　As mentioned earlier, this game has very high requirements for conventional memory, almost close to 590kB, and it also needs EMS support. But after EMM386.exe is normally loaded, the remaining conventional memory after DOS startup cannot meet the requirement. So once again, try editing Config.sys to free more conventional memory.

　　Before editing, let us first, in Win98’s DOS compatibility mode, type the command “mem /c /p” to view the detailed memory allocation (Figure 6). From the figure, we can see that 577kB of conventional memory remains. The system’s other resident programs are all loaded into conventional memory, while upper memory is empty, so we should load some resident programs into upper memory as much as possible, thereby freeing conventional memory. So modify Config.sys as follows (Figure 7):

　　DOS=HIGH,UMB
　　DEVICE=C:\WINDOWS\HIMEM.SYS
　　DEVICEHIGH=C:\WINDOWS\EMM386.EXE ram
　　(“DEVICEHIGH” means loading the EMM386 file into upper memory)
　　DEVICEHIGH=C:\WINDOWS\IFSHLP.SYS

　　In fact, what needs to be done here is simply to load into high memory and upper memory, as much as possible, the programs that appeared in conventional memory in Figure 6. Save the file and reboot. Then type the command “mem /c /q” again to check (Figure 8). Sure enough, at this time conventional memory has reached 592kB. Running Dra4.com for Dragon Knight 4 now poses no problem either.
　　
　　(3) Configuration of ultra-large conventional memory

　　However, no matter how you configure Config.sys, because upper memory is limited and EMM386.exe must also be loaded under the Windows environment, you have almost no way to make conventional memory exceed 590kB. Although at this point the vast majority of old DOS games can be played, there are still some “abnormal” games that require 590 or even more than 600kB of memory, and many professional game sites recommend simply giving up. In fact, the problem can still be solved.

　　One method is to start in pure DOS mode, that is, press F8 before Win98 runs and choose startup from the command line (Figure 9). Since this is no longer the windowing environment, fewer resident programs are loaded by default, and as long as Config and Autoexec are properly configured, conventional memory can reach more than 600kB.

　　Another method is to use third-party memory management driver software. Here I will introduce UMBPCI 3.41 (download address: http://www.uwe-sieber.de/files/umbpci_e.zip). The whole file is only 30kB, and it is a very useful upper memory (UMB) extension driver program (note: some motherboards may not yet be supported). It can be loaded directly in Config.sys with the Device command, and can provide as much as over 160kB of UMB. Suppose the compressed file is extracted into a folder UMBPCI on drive C. Then add this line to Config.sys: “DEVICE=C:\UMBPCI\UMBPCI.SYS”. Note that it needs to be placed after the Himem.sys line (Figure 10). Then when the system starts, Umbpci.sys will be called. If the file is called correctly, you should see related information at startup (Figure 11). At this time, after startup, the machine’s conventional memory can usually easily reach or exceed 600kB (Figure 12).

　　However, this situation is suitable for DOS games that do not require EMS expanded memory, because at this time EMM386 is disabled by default. If by any chance a game both requires more than 600kB of conventional memory and also requires EMS expanded memory, then we must make special settings to load both UMBPCI and EMM386 at the same time.

　　First we must know the exact situation of upper memory used by the machine. This can be checked with the Umbchk.exe tool included with UMBPCI. The method is: when the machine starts, press F8 and choose the last item to skip Config and Autoexec, enter DOS 7.0, and then execute Umbchk.exe to view the free upper memory situation of the machine (Figure 13), and record it. Then in Config.sys, modify the line that loads UMBPCI to “DEVICE=C:\UMBPCI\UMBPCI.SYS /I=XXXX-YYYY”. This means we hand the upper memory address range “XXXX-YYYY” over to UMBPCI to handle. But this is not the main point. What we need to solve is the problem of loading UMBPCI and EMS at the same time. The author of UMBPCI recommends loading EMS into a specific 64kB memory segment. As long as that segment is available, it is best to force it to be specified as the loading area for EMS. Usually this address range is C800-D7FF, so Config.sys should be written as follows:

　　DOS=HIGH,UMB
　　DEVICE=C:\WINDOWS\HIMEM.SYS
　　DEVICE=C:\UMBPCI\UMBPCI.SYS /I=D800-EFFF
　　DEVICE=C:\WINDOWS\EMM386.EXE X=D800-EFFF X=B800-C7FF I=C800-D7FF I=B000-B7FF RAM M3 D=256 AUTO （note: no line break）

　　In this way, we can load UMBPCI and EMS at the same time. Another possible situation is if your graphics card has a 48kB BIOS and cannot use C800-D7FF (for example NVIDIA GeForce). Then try modifying the parameters as follows:

　　DEVICE=C:\UMBPCI\UMBPCI.SYS /I=DC00-EFFF
　　DEVICE=C:\WINDOWS\EMM386.EXE X=DC00-EFFF X=B800-C7FF I=CC00-DBFF I=B000-B7FF RAM M3 D=256 AUTO

　　Of course, the system may still fail to start properly at this point. Generally this is because the page frame for EMM386 cannot be loaded. Then we can add the “FRAME=NONE” parameter to the loading line: DEVICE=C:\WINDOWS\EMM386.EXE FRAME=NONE X=D800-EFFF X=B800-C7FF I=C800-D7FF I=B000-B7FF RAM D=256 AUTO。

　　With this kind of adjustment, MS-DOS under Win98 can simultaneously support EMS and have extremely high free conventional memory (Figure 14). It should be noted that there are also some DOS games that cannot run when no page frame is loaded; in that case, one can only use the first method.

II. Replaying Win95/32 games

　　Compared with DOS games, Windows games are often more convenient to install and run, but on the other hand, they are less transparent to the user. It is hard for the user to understand the game's operating environment, and even less possible to "improve" that environment through Config and Autoexec. Therefore, replaying old games on Windows is even harder.

　　If Win32 was more like a quasi-graphical operating system based on DOS, then Win95's graphical operation was already quite complete. However, it still depended heavily on DOS, and like DOS itself, it was also a 16-bit operating system. This determined that programs running on it, including games, were all 16-bit, while Win2000/XP/98 are all 32-bit operating systems, so running 16-bit programs inevitably involves some compatibility problems. Win98 has relatively good compatibility with Win95/32, and generally old games will not run into too many problems. Starting from Win2000, however, Microsoft officially ended development of the Win9X series and turned the operating system completely toward the "NT" architecture. The result of carrying out this plan was the all-around compatibility promoted by WinXP. So let us still begin our analysis with WinXP, and afterwards supplement it with notes about Win2000/98.
　　
　(1) Solutions for replaying Win95 games under WinXP

　　Example 1: "Uncharted Waters Gaiden Chinese Edition"

　　When running the program, we see a dialog box full of garbled text (Figure 30), and startup fails. To understand the reason for the failure, we first need to read the text on the dialog box. Obviously, the text is in Big5 encoding. For NT-based operating systems, don't think about using those encoding conversion tools, because Win2000 and WinXP both have a complete encoding system. For this game, we might as well first try the system's own function.

　　Open "Control Panel" → "Regional and Language Options", enter the "Regional Options" tab, and select "Taiwan" in the drop-down menus for "Standards and formats" and "Location". Then enter the "Advanced" tab page, set "Language for non-Unicode programs" to "Taiwan" (this item is required), and confirm that "Traditional Chinese Big5" is selected in "Code page conversion tables" (Figure 32). After setting this and rebooting the machine, the system will be able to display Chinese characters in Big5 internal encoding, while the system itself and most programs in other encodings can still be used normally, though the fonts may look a bit ugly. The drawback of this method is that every change requires a reboot.

　　So is it fixed now? We can finally read it clearly: the pop-up window is telling us to use 256 colors (Figure 33). Do we still have to change the color setting in display properties? No need to make it that troublesome. Now it's WinXP's turn to show off its compatibility settings: right-click the game's main executable or its shortcut, choose "Properties", then in the window that pops up select the Compatibility tab and check "Run in 256 colors" (Figure 34; some games also require selecting other options such as "Run this program in compatibility mode for". In this way the game can run smoothly (Figure 35). While the game is running, the desktop will automatically switch to 256 colors, and after the game exits it returns to its original state. Very convenient indeed.

　　Compatibility settings can also be applied to read-only files on a CD, because this setting does not modify the file's own properties. Rather, it records the environment required when the file runs, and that record is stored in the system. In fact, WinXP has very good support for multiple encodings, so this game and "Taiko Risshiden 2" later on can both be replayed without changing Regional and Language Options; although there is garbled text in the windows, it basically does not affect understanding.

　　Review and summary: From this example we can see that many old games have problems with color depth and resolution when run on new systems, so when a problem appears, you may as well try the Compatibility tab first. In addition, if the desktop resolution is the same as the game's resolution (640×480), and the game also requires its own window to stay in the foreground, then in "Taskbar and Start Menu Properties" you also need to remove the check mark from "Keep the taskbar on top of other windows" (Figure 36). This characteristic is also fairly universal.
　　
　　Example 2: "Romance of the Three Kingdoms: Kongming Zhuan" and "Civilization II"

　　These two classic games both produce the same error when run: Wing.dll not found (Figure 37). From the extension we know that Wing.dll is a dynamic link library file, but what exactly is it? In the early days of Windows game development, the hardware requirements for game graphics were still very low, let alone any 3D. At that time, simple graphics acceleration functions were implemented through a dynamic link library file, namely the Wing.dll mentioned above.

　　For the download, refer to: http://xf-trans.hb.cninfo.net/sanguogame/download/tools/wing.rar，解压后安装即可（图38）。简单安装之后《文明Ⅱ》的运行就完全正常了（图39）。而《三国志孔明传》（图40）则较郁闷，由于WinXP的视频输出接口不能很好地兼容这款游戏，导致输出的画面时常无法自动刷新，具体表现就是变换场景时可能会黑屏，就算等待也无效，这种情况下，我们只能强制刷新，比较有效的方法就是将窗口最小化，再最大化，画面就出来了——这当然算不上解决方案，只是想说明出现这种问题就是绝症了 Just extract and install it (Figure 38). After this simple installation, "Civilization II" runs completely normally (Figure 39). But "Romance of the Three Kingdoms: Kongming Zhuan" (Figure 40) is rather depressing. Because WinXP's video output interface cannot very well support this game, the output image often cannot refresh automatically. Specifically, when changing scenes, the screen may go black, and waiting does no good. In this situation, we can only force a refresh. A relatively effective method is to minimize the window and then maximize it again, and the screen will appear. Of course this does not count as a solution, only as an illustration that when this kind of problem appears, it is terminal.
　　
　　Example 3: "Taiko Risshiden 2"

　　We use this example to show the complexity of the situation faced by Win95 games under new systems. If readers can gain something from it, then all this trouble will not have been in vain. Running this game produces a typical XP illegal operation window (Figure 41). After choosing "Don't Send", the program terminates. Afterwards, trying compatibility settings was of no use at all. We even downloaded Windows Application Compatibility Toolkit 3.0 from Microsoft's website, a toolkit specially intended for solving program compatibility problems. It contains many complex compatibility settings, but because many of them are highly specialized, ordinary users have difficulty getting started with it. It is more for programmers debugging old programs. Fortunately, its database includes compatibility information for many common old programs, and to our surprise we found "Taiko Risshiden 2" in it (Figure 42). But after the brief joy came harsh reality: even in its simulated compatibility environment, the game still could not run normally. In fact, none of our attempts with this toolkit succeeded. Hopefully it is not really so "completely useless". If readers run into compatibility problems in the future, it may still be worth a try. Download address: http://download.microsoft.com/download/a/6/f/a6f42077-eae3-4d4c-8df6-7ac402594127/act30pkg.exe

　　Still, it's better to "do it yourself and have enough to eat and wear." Start with the error message. In the lower-right corner of the error window there is a link called "Please click here". Do so, and a more detailed error report pops up. From there we can see that it is all the fault of a dynamic link library called "MCIAVI32.dll" (Figure 43). And what kind of "library" is this? MCI is short for Media Control Interface. Most files connected with this term have to do with video and audio control. In fact that is exactly the case here: it is a 32-bit AVI media driver, so we judge that the cause of the error is that an old Windows program called a new system interface, but the driver pointed to by that interface was different, which resulted in the error.

　　Since it is an AVI-related driver, we believe it is very likely used to play the opening animation. The opening animation has no direct relation to the game itself, but if we cannot get past this stage the game cannot continue. So can we simply skip this part altogether? Whether to watch the opening animation is a trivial matter. So we decided to delete MCIAVI32.dll. This file is in the System32 directory. Deleting the file directly won't work, because WinXP has file protection, and after rebooting the file will be restored automatically.

　　Of course, you can also find "it" in another place. Double-click the "System" icon in Control Panel, then choose "Hardware" → "Device Manager", expand "Sound, video and game controllers" → "Media Control Devices", double-click it, and under the "Properties" tab that file is listed. Select the file and click the "Properties" button in the lower right, and you can set it to be compatible with 16-bit (Figure 44). But even after doing this, the problem still cannot be solved (so after all that, was it all nonsense?). Don't worry. I mention these things so everyone can understand more clearly the role and location of this file in the system. To really remove it, you need to use the registry editor: run "regedit" through the Start menu, and find the following two items. Don't forget to back them up before editing (right-click the item icon and choose "Export":

　　HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\drivers.desc
　　HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI32

　　Under these two items, delete the strings "MCIAVI32.dll" and "AVIVideo" respectively (Figure 45). This does not actually delete the file, but the system already believes it does not exist. Run the game again, and success (Figure 46)! But after you're done playing, don't forget to restore the registry.

　　Review and summary: From this we can see how complex it is to solve the problem of old Windows games not running under WinXP. In fact this is also because Windows systems are far more complex than DOS. For ordinary players, once a game still cannot be played even after Wing.dll is installed and language and compatibility have been set properly, it is basically time to give up on solving it through system settings. At that point, a better compatibility solution is still virtual machine software. Presumably Microsoft also realized this, which is why it acquired Virtual PC. In issue 7 of this magazine in 2003, we already gave a preliminary introduction to using virtual machine software. After this section, we will discuss this software at a deeper level.

(II) Additional notes on Win98/2000 relative to WinXP

　　The situation for games under Win2000 is roughly the same as under WinXP. Although Win2000 has no compatibility settings, as long as you adjust desktop resolution and color depth as required, things will work; it is only a bit more troublesome because you have to switch them manually each time. However, the settings for Regional and Language Options in Win2000 are slightly different (Figure 47). As for playing Win95 games under Win98, there is almost no resistance at all. As long as Wing.dll is installed, and when encoding conversion is needed you install tools such as NJStar, that is enough. This shows that Win98 is truly a close relative of Win95.
　　
　(III) Additional notes on Win32 games relative to Win95 games

　　Because Win32 was in fact a transitional product, although it was very successful, there were not many games designed specifically for it. However, the compatibility of the games we were able to find turned out to be unexpectedly good. They do not even require Wing.dll to be installed (because they do not use Wing.dll at all). As long as you simply change the desktop resolution to 640×480 and 8-bit color depth (that is, 256 colors), they can all run smoothly under WinXP/2000/98.
　　

3. Limitations and application tips of virtual machine software

　　With the complicated introduction above, plus your own efforts and experimentation, I believe most old games can already regain their youth on your new system. But you can also see that although Microsoft and the authors of related software have made all kinds of efforts, compatibility problems always remain: under Win98, old games must directly face the graphics cards and sound cards of a real PC; under Win2000, display mode problems are quite annoying; and although WinXP supports more display and sound card modes in terms of virtual hardware, for the DOS to Win95 era spanning several years, this support is far from enough.

　　But perhaps nostalgia is only an emotion, and spending time researching compatibility is not something driven by commercial interests. For the author of VDMSound or the designers of Microsoft’s NTVDM, just a few more steps forward would solve even more problems, and yet in reality perhaps the steps stop here. Fortunately, however, there is still virtual machine software represented by VMWare and Virtual PC. Fortunately, while solving issues such as running multiple operating systems on one machine, they also happen to touch on solving compatibility problems between old and new systems.
　　
　(1) Limitations of virtual machine software

　　It should be said that if virtual machine software completely virtualizes the corresponding old operating system, then the problem of replaying old games should be solved perfectly. However, this conclusion can only be said to be too absolute. The vast majority of games should run smoothly under a virtual machine, especially Win32/95 games. After using virtual machine software, many problems that are hard to solve under new systems can almost be easily overcome. But there are also unexpected situations—although of course this kind of unexpected thing is actually to be expected.

　　Friends who have read this magazine’s issue 7 article this year, “Returning to the DOS Chinese Paladin Era — One Use of Virtual PC”, will certainly understand that virtual machine software virtualizes a PC, not an operating system. Since it is a PC, it will certainly have its own hardware configuration (equivalent to assembling a machine yourself). As far as old games are concerned, the graphics card and sound card are the most crucial here.

　　Taking Virtual PC 5.1 as an example, the graphics card it virtualizes is the S3 Trio 32/64 PCI. Although this graphics card has very good compatibility, in actual operation it was still found that some games such as The Legend of Heroes 4 — A Tear of Vermilion Blood and Richman 3 display a stretched game screen with only half visible when run (Figure 48). If, referring to the graphics card compatibility problem under Win98 discussed earlier, one tries to use SDD, this reveals another problem of virtual software: defects in virtual hardware. Simply put, it cannot achieve truly complete virtualization. Under a virtual machine, SDD cannot once again virtualize hardware that is already itself virtualized. As a result, this problem cannot be solved at all on Virtual PC. The help documentation of another famous virtual software, VMWare (taking version 3.2 as an example, Figure 49), also mentions that software using DirectDraw and Direct3D graphics technologies cannot run on it, though that is not very relevant to the topic discussed here.

　　Compared with graphics cards, compatibility problems on the sound card side may be fewer. Throughout the whole process of our testing with Virtual PC, we did not find sound card compatibility problems. However, many games ask for sound card parameters to be set when run for the first time (or you can also set them manually), so the parameters of the virtual sound cards in Virtual PC and VMWare are listed below. Virtual PC 5.1: Creative Labs Sound Blaster 16, Port 220，IRQ 5，8-bit DMA 1，16-bit DMA 5；for VMWare 3.2, all are the same as Virtual PC 5.1 except that the 16-bit DMA parameter is 7.
　　
　　(2) Application tips for virtual machines

　　Many friends using virtual machines for the first time feel that transferring data between the host and the virtual machine is very troublesome. This feeling of trouble is just like facing two unrelated computers. Of course, besides using floppy drives and CD-ROMs, virtual machines can also transfer data by creating .iso and .vfd image files—but it is still troublesome. Then, by the same analogy, we discover that using the network is a very natural solution!

　　Below, Virtual PC is used as an example. In fact, after the software is installed and set up, a virtual network card will be installed on the host for establishing a network connection with the virtual machine (Figure 50). Of course, we do not need to manually establish a LAN between the new and old systems, since that would require far too much specialized knowledge. The Virtual PC installation package already provides additional tools for DOS and Windows respectively to achieve this function (similar tools for VMWare must be downloaded separately).

　　Let us first look at how to use this tool on a virtual machine after DOS has been installed. Taking MSDOS 6.22 as an example, after starting the virtual machine, click the menu “Floppy” → “Capture Image”, and in the pop-up window find the folder extracted the first time from the software package, then go in sequence to “Additions” → “Dos Additions” → “Dos Addition.vfd” (Figure 51). This is the additional function floppy disk image specially designed for DOS. Return to the DOS virtual machine interface, enter drive A, and type “dosadd” to begin installation (Figure 52). Afterward, release “Dos Addition.vfd” from the “Floopy” menu and reboot. In this way, when this DOS virtual machine starts up, it will automatically load a driver called “Folder Sharing”, and it will also load a universal CD-ROM driver. In essence, this sharing function indirectly uses the system’s network function to map a certain folder on the host as a certain drive on the virtual machine.

　　Next click the menu “Edit” → “Settings” to open the settings dialog for this virtual machine, and find “Shared Folders” (Figure 53). Initially it is empty. Click the “Share Folder” button on the right, and in the dialog that pops up select the files you need to access directly under DOS, such as “E:\dosgame”（ in this example (Figure 54). Under “Drive letter” below, choose the drive letter after mapping; in this example we accept the default setting “Z”. If you want this directory to be shared every time the virtual machine starts, check “Share every time”. After confirming, type “Z:” in the virtual machine, and you can access the E:\dosgame directory on the host.

　　There are two notes here: (1) If the shared folder function is used under DOS, its driver will occupy conventional memory space, causing the memory available to the game to decrease. Therefore it is recommended that you copy all needed files first, then open “Autoexec.bat and “c:\cntx\fshare.exe” in the c:\cntx\idle.com” under the root directory, and add “rem” before them to disable their execution (Figure 55). Of course, modifications under DOS must be done with the Edit command, which requires you to have some understanding of DOS. (2) In Win95 or later versions, installing the additions is even simpler. Through the menu “CD” → “Capture Image”, select the VPCAdditions010021.iso file in the same “Additions” directory as above, install Setup.exe from the CD in the virtual machine, reboot after installation, and then similarly select shared folders to complete the mapping (Figure 56). Of course, after Windows has the additions installed, there is an even more practical function: you can drag and drop files freely between the host and the virtual machine!

　　There are also some other application tips. For example, friends unfamiliar with DOS editing can attach the DOS installation disk as a second hard disk to another virtual machine with Win98 installed, and use the graphical interface to edit files. Or, when the virtual machine is temporarily not needed, you can press the key combination right Alt+P to pause the virtual machine and release part of the memory. You can even cooperate with Virtual PC and game modification software such as GameMaster to modify games that normally cannot be modified (Figure 57). These specific operations are left for everyone to study carefully on their own.

Conclusion: the month-long special feature is finally complete, and the two colleagues in the review room are almost worn out. (Interested friends may refer to Yan Feng’s work notes written in a “Spring and Autumn style” in this issue’s “Casual Talk”.) Readers will probably find it hard to imagine the hardship behind this article. What we faced was a massive number of old games spanning an entire era. For every single game, going from not being able to run to being successfully replayed could make the reviewer turn from hate to love. But at last all of this has become a finished product—it sits here quietly, waiting for your judgment. Old games on new systems actually involve deeper principles of system design that are rarely discussed. Going from games to becoming a computer expert is a path many people in the industry have walked, and through this article we also wanted to show our understanding of that path. In fact, no one can bring every single game back from the “dead”, but if this article can arouse everyone’s desire to solve problems hands-on, that will be our greatest wish. Oh, and if you discover any new solutions, do not forget to share them with everyone—through us.