>>George,
>>
>>Your reply let me to SET PATH TO and SET DEFA TO and try again just to see. With no PATH and no DEFA it worked. Trying the other combinations I found that the DEFA isn't the culprit but the PATH is.
>>
>>I have Windows installed on D: and the DEFA was set to C: but that didn't cause any problems. The PATH, however, was set to my development enviornment where I am presently working.
>>
>>PATH = C:\MAILER25\AUTOMAIL, PRGS, DBFS, FORMS, MENUS, SYSTEM, MAILBOXES, GRAPHICS
>>
>>This, apparently, is causing the problem.
>>
>>GETENV('PATH'), however, does return D:\WINNT\system32;D:\WINNT;D:\WINNT\System32\Wbem;D:\Program Files\Resource Pro Kit\
>>
>>So why can't Windows find D:\WINNT\system32 when it is in the enviornment? Why would VFP's PATH disrrupt Window's ability to find this one .dll? Windows can find all other Windows dll files that I reference but not this one.
>>
>>A real mystery.
>>
>Ed,
>
>I know why now the WScript.Shell doesn't have a problem. It's an out of process server. I'm wondering one thing, which may provide the answer. Namely: Was VFP installed after Win2K? If not, was the original version of Windows in the same location and was it NT?

George,

As a test I compiled the ShellExecute code into my app and then ran the compiled exe file on this same machine and everything worked fine. That at least takes the worry away about the code running on some machines and bombing on others. Unless you can think of something that I can do to correct the problem while I'm in development mode, I'll just have to code around it.

Thanks for all of your help. I stopped asking "Why me?" a long time ago. I'm used to it now :-(>>>>.

Ed