>>>>Greetings!
>>>>
>>>>I created an EXE of a VFP6 application on our network. I'd like to know which DLLs are necessary in order to run it on a PC which does not already have VFP6 installed. Currently, I am getting a Fatal Error, with an Exception code of C0000005, as the application is closed.
>>>>
>>>>The DLLs I am using are VFP6R.DLL, VFP6ENU.DLL, and VFP6RENU.DLL. I am I missing a file? This application works correctly when compiled in VFP5, however I am migrating my applications to VFP6.
>>>
>>>Win95 machines will need to have DCOM installed before running a VFP application; Win98 and NT 4.0 systems should already have DCOM support installed.
>>>
>>>I'd suggest creating your install (at least the VFP 6 Runtime portion) with the Setup Wizard rather than attempting to copy files, since the VFP runtime files also have dependencies on other common libraries (like the various MSVCRT and MFC .DLLs) which need to be brought up to date properly. The Setup Wizard should handle this for you. Guessing at file dependencies and versions is a good way to mess up an install, and in some cases, a working system. If you do roll your own and don't use a third-party product like InstallShield to manage the installation of system components, you'll need some of the facilities of the Win32 Setup API to help in copying and registering .DLLs that may already be resident in memory.
>>>
>>>Unfortunately, Setup Wizard doesn't address the DCOM install, which can force a reboot during the install process; you can download the DCOM installs from Microsfot's Web page. If you need to encapsulte the entire install into a single process, you'll need a seaprate install scripter such as InstallShield or the Windows Scripting Host. It's simpler to do the DCOM install before attempting to run the VFP Runtime install created by the Setup Wizard.
>>
>>Thanks for writing, Ed!
>>
>>You are making a good point. The problem with using an installation process is that I have no idea who will be running the application on the network. I have a small launcher, written in Visual Basic, which is the starting point for the networked applications I create.
>>
>>When someone wants to run a VFP application, the launcher first checks if the required DLLs are present on their PC, and installs them if they're not found. Afterwards, the VFP application starts to load. This works flawlessly with VFP5 but, unfortunately, not so with VFP6 (apparently).
>
>This part is easy to deal with, and a bit of packaging can make things easier for you. Create a VFP Runtime install package with Setup Wizard, and place an image on the network. Your launcher can check if the VFP Runtime files are present, and if not, rather than copying them in place, fire the VFP install from the network image (silently if you like) via VB's Shell function or any of several API calls. I'd use CreateProcess() so that I could reliably monitor the install process via it's process handle. This not only will copy out the VFP RUntime components, but will also properly update the OLE and MSVC components for you. The install can be fired silently, without user intervention by addition of a couple of command line parameters. Silent installs can be completely automatic if the default actions for the install are acceptable or you modify the .INF file to your liking.
>
>You can also check the DCOM status (HKEY_LOCAL_MACHINE\Software\Microsoft\OLE has an EnableDCOM registry value you can look for) and fire DCOM95.EXE the same way. Be aware that the user may force a reboot after DCOM; you might want to create a RunOnce key to rerun your launcher before starting DCOM installation.
>
>Once the install completes, your launcher can run the application unless installation forces a reboot before returning control to the launcher.
>
>You can also have the Setup Wizard handle registration of OLE Automation components and ActiveX controls needed by your application. Again, better than copying and registering by hand where a later version might be in place already.
>
>Doing things right is better than fixing things that don't need to be broken...
>

Great! Thanks a LOT for the information, Ed. I'll see if I can make it work this way. I appreciate your time in helping me.

Take care!

Michael Reynolds