>>>You can use Windows Scripting Host for creating shortcuts too. This is an example how I create a Shortcut on the user's desktop.
>>>
>>>

>>>*-- Is Windows Scripting Host installed?
>>>*-- OK This You probably don't have as it is
>>>*-- a function-call to RickStrahls wwAPI.PRG
>>>*-- but I think it's not needed
>>>ll_IsScripting = IsComObject('WScript.Shell')    &&--> wwUtils, wwAPI
>>>

>
>You can code this without the use of Rick's library; you can use the FFC registry class to check for the existance of the registry key HKEY_CLASSES_ROOT\Wscript.Shell - you should also check to ensure that at least version 2.0 of the WSH is present (generally, it will be, but older OS versions may have version 1.0 installed. You can always install a current version from the self-installing executable available for download from the MS Web site referenced in my sig block.) A good sign of WSH 2.0 being present would be finding that HKEY_CLASSES_ROOT\VbScript.RegExp exists. You may want to look over the 5 part article that George Tasker and I did for VFUG back in the fall of 2000 for details.
>
>Since shortcuts are really nothing but .LNK files, you could simply examine the Desktop directory and step through the Start Menuer hierarchy looking for shortcuts; things become more complex where more than one user profile is involved, or where even if only one profile is active, that there is a Default and an AllUsers profile as well to consider. The basic logic would be to find the folders (you can use the SpecialFolders collection to find the current user and AllUsers desktop and Start Menu entries) and then examine each link using the Wscript.Shell CreateShortcut method (it will allow you to examine the content of an existing .LNK as well as create new ones.)
>
>I'd be careful about relying on automagically updating all shortcuts - there are sick people like me who drag them to new and interesting spots like the QuickLaunch bar, foldrs on the desktop, or the MS Office Taskbar, and being perverse, we sometimes rename them, too. Equally perverse behavior, such as changing the default way the app Window initially opens happens as well...

Interesting, promising information. So, Ed, I gave you also one point. Having read your notes on perversity I must admit that I'm somewhat perverse also. :)

What remains to be answered is the initial question: What's the harm of using VFP6R.DLL with an EXE that's built in VFP7. I guess it requires someone from MS to answer that question.