>>>>As a follow up post for anyone interested in using Crystal, it requires
>>>>
>>>>MFC42 && MFC Shared Library
>>>>MSVCRT.DLL && C Runtime
>>>>
>>>>which cannot be updated with Windows running. That pretty much sums up doing retro installs (unless you use installshield, etc.). If you have an installed base, plan on visiting each workstation or using the VFP report writer (which I have developed a new appreciation for since working with Crystal). It's too bad Microsoft doesn't invest additional time into it...it has a lot of potential with having to go to DLL hell.
>>>
>>>Anyone with functioning braincells realizes that (I know, it couldn't be this way) you can't do an adequate install of Windows apps using DOS-style copy activities. Using either Setup Wizard or VSI, the delayed copy and registration issues are handled neatly without any great difficulty; this is also the case with the dozens of capable third party installers (I use InstallShield, have clients using Wise and InstallShield Express, and have no complaints about these products.)
>>>
>>>If learning to do the install properly is too much trouble, and the two free tools provided by MS aren't adequate for your purposes, farm out the work of writing the install to someone who understands the issues.
>>
>>Hey Ed,
>>
>>What do you do about the situation that VS6/SP4 (for VFP6) updates the MSVCRT.DLL file, so you include that with your VFP6 setup wizard. Who's responsibility is it to update MSVCIRT.DLL? VFP6 doesn't use it.
>>
>>?????
>
>The company that spec's the change to the version of MSVCRT should publish the dependency information; Win2K handles the issue quite neatly by installing it side-by-side, assuming you use a proper installer.
>
>Does VFP6 actually update MSVCRT, or does it replace one of it's derivative files? I'll have to check the dependcy charts. I know it doesn't install it on Win2K boxes, Win98 or WinME boxes through InstallShield or Setup Wizard, because they check the version, and the version on the boxes here are all at 6.1.something, and the Setup Wizard provided copy is version 6.0.something; conditional installation handles the issue neatly. The VFP6 Setup Wizard generated install dependency indicates clearly that it's conditionally installed based only on the Wizard version being a later version than what's installed on the system:
>
>

[MSVCRT.DLL]
>Dest=$(WinSysPathSysFile)
>VFPSourceDir=SOURCE
>VFPSource=SYSTEM\MSVCRT.DLL
>VFPRefkey=MsvcrtDll
>VFPCompress=YES
>VFPVital=NO
>VFPReadOnly=NO
>VFPShared=NO
>VFPSystem=YES
>VFPSetupFile=YES
>VFPVersion=Yes
>VFPInfClass=VC Runtime
>
>[MSVCRT40.DLL]
>Dest=$(WinSysPathSysFile)
>VFPSourceDir=SOURCE
>VFPSource=SYSTEM\MSVCRT40.DLL
>VFPRefkey=Msvcrt40Dll
>VFPCompress=YES
>VFPVital=NO
>VFPReadOnly=NO
>VFPShared=NO
>VFPSystem=YES
>VFPSetupFile=YES
>VFPVersion=Yes
>VFPInfClass=VC Runtime

OK, we've not had a problem on W2K, but we have had a problem on W95/W98 (don't know about ME, yet). Our installer updated the MSVCRT.DLL, but didn't touch the MSVCIRT.DLL, so now the software that's dependant on that is broke. How do we "down grade" MSVCRT.DLL to match the MSVCIRT.DLL on the box?