>>How do we "down grade" MSVCRT.DLL to match the MSVCIRT.DLL on the box?
>>>
>>>Not trivially, unfortunately. The easiest mechanism is going to be to insert code that fires as a part of the AUTOEXEC.BAT under Win9x, which fires up before the Win32 subsystem starts, to revert the copy to the old copy; alternatively, upgrade MSVCIRT.DLL to the version matching the MSVCRT.DLL you've installed. I believe that the current version of both is 6.1.8637.0, created back in December of 1999. The MSDN web site has a service that will allow you to check versioning and dependencies of various DLLs on-line through msdn.microsoft.com
>>>
>>>You can also write code to do delayed copy by updating an .INI file used by Win9x to perform the delayed copy operation; there's a whole Setup API available as a part of the Platform SDK that handles delayed copy, registration, decompression of LZH-compressed files available. Dino Espoisito covers how to use WSH for most of the necessary functionality in his "Windows Script Host Programmer's Reference" from Wrox Press.
>>
>>OK, so I could just boot these older systems to a DOS prompt and just copy the older and/or newer versions to the proper folders and copy the "correct" versions. There's nothing that needs registering for these files, a simple copy will do (as long as Windows isn't running)?
>>
>
>That's correct; neither has a COM interface. You may need to play with File Attributes. BTW, this will -not- work on Win2K; it's very protective of the files in system folders, and won't let you mung with them directly using blind copy techniques. It also handles the issue of side-by-side DLL versioning if you let an installer do the job it's supposed to do.

Great! W2K hasn't been a problem (so far). Thanks again!