Community for Sid Meier's Gettysburg! Players

Homepages

Inside XP: Sid Meier's Gettysburg! on XP Service Pack 2/Direct X 9.0c

by Don V Wells, Jr.

June 16th, 2005

The game Sid Meier's Gettysburg! was originally a Win9x game by Firaxis Games which requires some modifications to its default installation to properly function outside of its original native Windows 9x environment. This document addresses the steps necessary to make this Win9x-era game fully functional on the now current Windows workstation standard, Windows XP (Pro), Service Pack 2, which incorporates DirectX 9.0c as standard.

The base-line requirements for Sid Meier's Gettysburg!:

The primary problem with attempting to play Sid Meier's Gettysburg! on Windows XP(SP2) is that the video clips which provide the explanatory story narrative no longer display, also some menu/display anomalies still occur even after the application of the Firaxis Windows 2000/XP Update. Finally, it appears that with the release of both the Gettysburg! v3 Patch and the Gettysburg! Windows 2000/XP Update that some confusion exists as to the load order and ultimately what EXE and DLL files should be present in the Gettysburg! sub-directory for proper operation.

Read on...

Some of the problems listed below have been addressed by Firaxis Games in a series of issued patches to correct problems with the game functionality and operating system support. However, some additional steps are still needed to correct issues created by Firaxis and changes in the Microsoft Windows environment of Windows XP (SP2).

The problems in executing "Sid Meier's Gettysburg!" on today's hardware and operating systems can be delineated in four areas: Hard-coded Win9x programming practices; the improper inclusion of Windows 9x-era system level Dynamic Link Libraries (DLL) files in the application installation sub-directory; the 'inadvertent' changes by Microsoft in CODEC support for the now deprecated 'Microsoft Video for Windows' API; the ever increasing speed of current/future x86 processors and its effect on critical timing sensitive game routines.

Firaxis corrected the Win9x hard-coding in Gettysburg! with the release of its Windows 2000/XP Update. Firaxis continues to host a series of patches for "Sid Meier's Gettysburg!" at its own web-site, the Firaxis Download page:

The necessary patches for 'Sid Meier's Gettysburg!' are as follows:

Each of the above files contains file necessary to update the Gettysburg! executable LEE.EXE, SOUND.DLL and some other supporting files. Here is what each patch contains:

The Gettysburg! v3 Patch: (SMGPATCH3.EXE)

The Gettysburg! Windows 2000/XP Update: (SMG_2000_XP_Compatibility_Update.exe)

So we have the following possible LEE.EXE and SOUND.DLL files from the original Gettysburg! CD-ROM, the v3 patch and finally the Windows 2000/XP update:

We need to end up with the Number 3 item versions listed above as the two files necessary to properly execute the Gettysburg! game engine, LEE.EXE and SOUND.DLL - no mix and matching will function properly. The year 2002 Win2K/XP updated versions of LEE.EXE and SOUND.DLL are the ones that all owners of Gettysburg! should be using, regardless of operating system version.

The use of the Firaxis provided "Windows 2000/XP Update" also eliminates the need to use any type of 'compatibility mode' fixes for the executable LEE.EXE to have Gettysburg! function properly under Windows XP(SP2). This does not hold true for Sid Meier's Antietam! or South Mountain add-on pack on Windows XP (Service Pack 1) or below.

Now on to the other DLLs which are placed in the Gettysburg! sub-directory by the SETUP.EXE installation program. These are the DLL files which exist in the Gettysburg! sub-directory. The only ones which should remain in the Gettysburg! sub-directory are the SOUND.DLL and MPGETTY.DLL. All other DLL files listed below should be deleted.

There is a structure to the way that supporting system and application DLLs are located and loaded by the Windows operating system when executing a Win32 application. This DLL search order and changes made to the functions supported by system-level DLLs over the past years can cause problems for applications when past programmers improperly included operating system-level DLLs in their release by either over-writing any existing Windows system directory DLLs, or by including such system-level DLLs in the application sub-directory. This approach functioned in the Windows 9x-era when the application release was close to the release dates of Win98, Win98SE and WinME as major Windows operating systems supporting DirectX and gaming. While Windows XP can protect itself from applications installing their own DLLs in the Windows system sub-directory, it can not stop applications from installing out-of-date system-level DLLs in the application sub-directory.

With the release of Windows XP (SP1) and Windows 2003 Server the traditional DLL search order was changed. There now exists a registry entry which controls how the DLL search order is defined, either the 'traditional' method or the new 'safe' method.

 (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SafeDllSearchMode)

The traditional DLL search path: (SafeDllSearchMode is 0):

The new WinXP(SP1)+ DLL search path: (SafeDllSearchMode is 1):

Source: MSDN: Dynamic-Link Library Search Order

Notice that in both DLL search order cases that the Directory from which an application is loaded is still searched FIRST before the (new & old) DLL search rules are applied. Therefore any older system level DLLs which are co-located in the 'Gettysburg!' sub-directory where the executable "LEE.EXE" is located will be used before the Windows XP(SP2) operating system can provide the proper system-level DLLs from the "%windir%\System32" sub-directory.

Listed below are some of the DLL dependencies for the executable "LEE.EXE" according to version 2.1.3623 of the Microsoft Dependency Walker for Win32(x86). The complete DLL listing will show while many of the system-level DLLs are being properly provided by WinXP(SP2) from the "%windir%\System32" sub-directory, two system-level DLLs are being loaded from the application execution sub-directory, which is a cause of some problems. The Firaxis issued Windows 2000/XP update for 'Gettysburg!' recognized the DLL problem because it attempts to delete the MSVFRW32.DLL file from the application execution sub-directory. It misses the MSVCRT20.DLL file, plus the other Win98-era system level DLLs which still reside in the application sub-directory.

Here are the files that the executable LEE.EXE loads from its own installation directory. The only one which should be available is the SOUND.DLL file, as the MSVCRT20.DLL and the MSVFW32.DLL files should be supplied by the WinXP operating system via the "%windir%\System32" sub-directory.

c:\program files\firaxis games\sid meier's gettysburg!\LEE.EXE
c:\program files\firaxis games\sid meier's gettysburg!\MSVCRT20.DLL
c:\program files\firaxis games\sid meier's gettysburg!\MSVFW32.DLL
c:\program files\firaxis games\sid meier's gettysburg!\SOUND.DLL

If the out-of-date MSVFW32.DLL file is located in the same sub-directory as the LEE.EXE executable, then the error message from LEE.EXE will be displayed: "The procedure entry point UnMapLS could not be located in the dynamic link library KERNEL32.dll." This same error will occur when attempting an AutoRun install of the original Gettysburg! CD-ROM, requiring a manual execution of the SETUP.EXE file on the CD-ROM to successfully complete an installation.

The proper setup for Gettysburg! for DLL support would have only the latest SOUND.DLL and the obsolete MPGETTY.DLL (for the obsolete MPLAYER.EXE) files in the Gettysburg! sub-directory. No other DLLs should be present, so delete all of the unnecessary system-level DLLs from the Gettysburg! sub-directory.

The integrated in-game support for the Gettysburg! video clips can fail under WinXP(SP2), eliminating one of the cheesy/charming atmosphere aspects of Sid Meier's Gettysburg! gameplay. The audio from the clip will be heard, but the video portion of the clip will not be displayed, but the message "Video not available, cannot find 'vids:IV41' decompressor" will be displayed. Microsoft is aware of the "iv41" CODEC problem, but suggests the installation of the proper Indeo CODECs, which are included in a WinXP(SP1) download. These suggested Indeo CODECs are the same ones which are included with WinXP(SP2) and the Gettysburg! video clip display problem still exists. If the Windows Media Player 9/10 is used to play one of these video clips directly from the Gettysburg! CD-ROM, the video plays normally. Why will those same video clips not play properly in the Gettysburg! game itself?

Windows XP(SP2) provides audio/video CODEC support for past and current applications via two API mechanisms. The first and oldest method was the original 'Microsoft Video for Windows' code base which was grafted onto the Win9x and WinNT4 operating systems with CODECs supported as DLL files in the Windows system directory. The current method for Windows XP(SP2) support for older applications which rely on the WVfW interface is to get their CODECs DLL support from the files located in the "%windir%\System32" directory. The Registry defines the installed CODECs, their description and location for those applications which need CODEC support via the WVfW API mechanism.

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

The second and current method of providing CODEC support by WinXP(SP2) is via DirectShow Filters, with the registration of the COM component CODECs in the form of 'SomeCodec.AX' file structure. These files with the "AX" file extension are COM component DLLs by another name. The DirectShow API interface is a superset of the VfW API and provides a 'wrapper' around older VfW DLL CODECs for those applications which make DirectShow requests for the services of older CODECs. Microsoft therefore had no need to re-write the code from the third-parties who provided the CODECs in years past.

So we have a situation where the Microsoft Windows Media Player 9/10 can properly display the Gettysburg! AVI video files, but the LEE.EXE program file cannot do so... First off is identifying the missing 'iv41' labeled CODEC - it is the Intel Indeo Video 4.x Decompression filter. This CODEC exists in the WinXP(SP2) "%windir%\System32" sub-directory as the DirectShow Filter file: IR41_32.AX, which explains why the Microsoft Windows Media Player 9/10 can properly display the Gettysburg! AVI video files. Now look in the WinXP(SP2) registry locations listed above for the VfW support. The WinXP(SP2) registry entries will properly identify the VfW 'iv41' CODEC as ir41_32.dll, but no such file is to be found in the "%windir%\System32" sub-directory of WinXP. If only a copy of that apparently missing CODEC file IR41_32.DLL could be placed into the WinXP(SP2) "%windir%\System32" sub-directory, then all would be well with the video clips playing properly in Gettysburg! by the application LEE.EXE, the main program file executable.

Wait a minute, DirectShow Filters are a 'superset' of VfW CODECs... That means that the IR41_32.AX file could easily support the VfW 'ir41' CODEC requirements... What if the file IR41_32.AX in the WinXP(SP2) "%windir%\System32" sub-directory was simply COPIED as the duplicate file IR41_32.DLL??? Could the answer be as simple as having two identical Intel Indeo files: IR41_32.AX (DirectShow Filter) and IR41_32.DLL (VfW CODEC) in the "%windir%\System32" sub-directory?

Yes, it's that simple... Now the 'in-game' Gettysburg! video clips work perfectly.

Many of the timing routines in the code of Gettysburg! are not processor dependent, however the ones that are processor speed dependent impact the user interface for moving about the complete map using today's much faster x86 processors. When using the mouse to navigate around the map by placing the mouse pointer at one of the four edges of the display 800x600 screen, the map is redrawn so quickly that it is sometimes hard not to 'overshoot' the intended map destination. With no coding modifications to LEE.EXE on the horizon, the only solution seems to be a combination of making the x86 processor do as much work as possible during the game, plus adding some sort of slow-down utility to the workstation to allow for a more reasonable speed of the user interface.

For the in-game slow downs, go to the Gettysburg! F9 preferences and make sure that the following items are set to ON:

Normal Trees and Houses
Map Scrolling Enabled
Maximize Graphic Detail
Full Draw on Scroll

This will at least make the x86 processor work as hard as possible in drawing the 2D images and sprites which are the center of the Gettysburg! graphics sub-system. Probably the simplest 'slowdown' coding fix would to be to cause any DirectDraw screen redraws performed on a map scroll to be executed twice in a row. This would waste CPU time, but that is after all the objective...

The following web page titled "The NEW PC Slow Down Page!" has various DOS and Windows x86 CPU slow-down utilities. The site is by DeBray Bailey and includes a free copy of the Microsoft DirectShow SDK utility 'CPU Grabber'. This Microsoft "CPU Grabber" utility and the shareware "CPUKiller! v3.0" are probably the best utilities for slowing down the faster x86 CPUs now in use. The utility "CPUKiller! v 3.0" is hyper-threading and multiprocessor aware, but does cost if you like the time-limited demo.
[New link is to archived version of geocites called reocities]

[See also here]

The final software recommendation would be Daemon Tools CD-ROM emulator a free CD-ROM emulation program which will allow an ISO CD-ROM image be used instead of the actual Gettysburg! CD-ROM. Very good at speeding up access to the video clips when there is a need to run them at the conclusion of a scenario. It also helps that you don't have to go looking for the CD-ROM just to play Gettysburg!, it's just an ISO image stored on the hard drive...

If you do use a CD-ROM emulator to host the Gettysburg! CD-ROM image file, be sure to actually install the game from the emulated CD-ROM drive. The Windows Registry maintains this "installed from CD drive" letter and expects to find the actual CD-ROM (or image) at that drive letter for the game to properly function.

If the Gettysburg! and Antietam! engines were just re-coded to support 1024x768 screen resolution @32bit color with the processor dependent timing fixed, it would be enough for me...

Hope this helps,

dvwjr

Credit: Marc Swaby (via the Gettysburg! Online Society Forums) for the idea that SETUPAPI.DLL in the application sub-directory was part of the cause of the problem with the Sid Meier's Antietam! lack of sound operating under WinXP(SP2).

Publishing with kind permission of Don V Wells, Jr.