>>Hi Rick,
>>
>>After your reply I tried this path+file (opposed to file-only) way of retrieving. And indeed it retrieved the version number. How's the situation on your machine if you leave out the path? Point is, I know of no way to retrieve the full path of the vfp runtime lib that's used for the running application.
>
>Peter,
>Indeed it also "failed" on my system when leaving off the path info. I guess one way of finding out where the files reside, would be to walk through the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs\ and find the file. They all seem to be "registered" here. (I'm sure someone has posted code to do this before.)
>
>Rick

Rick,
In my registry I find many many entries for vfp?r.dll, each specifying a different map. I guess aGetFileVersion() concludes something like "huh, I don't know which one to use, so I act as if I didn't find any" if no path is specified and it finds so many entries for that file.

The explanation for so many same-filename entries in my registry is the fact that the setup of the application distributes the vfp?r.dll to a user-specified map, not necessarilly to the windows\system map. Being a developer I make many test setups, therefore I get many entries. The application is started using the -d startup parameter to specify the runtime dll. (I'm not responsible for the introduction of this construction.)

Ok, now we have a plausible explanation for the fail. In my opinion it's not the solution to write a routine that 'manually' searches in the registry. The routine would encounter the same problem as aGetFileVersion() encounters: "Which one must I choose?".

I guess the solution is to give aGetFileVersion() the path-info indeed. But that's only possible if there's a method that tells us the path of the actually used (runtime) dll. The ADLLS() function is helpful only with regard to dll's that are declared using DECLARE. DLL's like olepro32.dll aren't handled by that function. But I finally have found the function that tells me the location of the runtime dll! It's SYS(2004). So, my biggest problem can now be solved.

Hope this info is of help to others as well. Rick, thanks for your time and effort.