VFP apps fails on W10 64-bit 1

[k2a]

Will there be problems running VFP 9 apps on a Windows 10 64-bit system, because doing so an error message appears telling that "DLL/OCX is not registered: RegSvr32".

What i found around here is that there is no VFP 64 bit version available. Does that mean VFP 9 apps will only run on 32-bit platforms?

That would be very bad news for me.

Hoping someone here can shed some light on it.

Thanks

 

[Mike Lewis]

Will there be problems running VFP 9 apps on a Windows 10 64-bit system ....

No. There have been several threads here recently about this. If you peruse them, you will see that there should be no inherent problems.

... because doing so an error message appears telling that "DLL/OCX is not registered: RegSvr32".

The message means what it says. VFP is looking for a component that is not present, or is present but not registered. The message should tell you which component is the culprit (not merely "DLL/OCX"). It doesn't mean that VFP itself cannot run.

What i found around here is that there is no VFP 64 bit version available.

Correct, but that doesn't mean you can't run VFP perfectly happily on a 64-bit computer, including under Windows 10. Many of us here are doing that every day.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

DLL/OCX is not registered: RegSvr32"

I wonder about that message, if it is missing regsvr32 itself, that would be very odd. Missing OCXes like the ms common controls you are allowed to redistribute, may be due to a setup not thinking about their redisttribution, as they were very commonly available in older OS versions and via Office installations. VFP came with Installshield Express since Version 7 and that includede merge modules for VFP runtimes, C++ runtimes and also the capability to detect the need for adding OCX merge modules for at least those standard components like Slider or Treeview. You can fix that from outside by adding an OCX only setup or manually registering an OCX. If there is a line of code inside the VFP application using regsvr32.exe to register some OCX such a thing won't work since Vista, as UAC prevents an executable even when you started it as administrator, to create further processes with elevated privileges, you better setup OCXes at install time, not in a first run or similar fashion.

In regard of 64bit, up until now every Windows 64bit system has a 32bit subsystem and runs 32bit applications, too. You only have a problem running 16bit since a few versions of Windows.

Most of what I said, if not even all of it, also is valid since Vista 64bit. Windows 10 hasn't changed much in regard of VFP compatibility.

Bye, Olaf.

 

[k2a]

Thanks for your quick response.

The good new for the moment is that vfp9 apps should run on a 64-bit computer.

The app which fails while being installed on a 64-bit Windows 10 runs perfectly on 32-bit computers including Windows 10.

In fact the error message looks like this:
C:\Program Fiels (x86)\Common Files\Microsoft Shared\VFP\vfp9r.dll

DLL/OCX could not be registered: RegSvr32 call failed with Exit-Code 0x3.

When i continue with ignore it ends up with this message:

Cannot locate the Microsoft Visual FoxPro support libray.

My understanding is that the Visual FoxPro support libray is included in the apps setup.exe programm.

If this is not the case, how do i get Microsoft Visual FoxPro support libray onto the 64-bit Windows 10?

 

[Olaf Doschke]

Well, a setup.exe should install the runtimes so no error like that is shown, makes me wonder, as the vfp9r.dll can be registered (to be found anywhere), but does not need registering (when put into the EXE folder or some system locations an EXE looks for it anyway).

C:\Program Files (x86)\Common Files\Microsoft Shared\VFP\ is the place the VFP installation itself puts the runtime and indeed also registers it, there, as that's not among the paths any VFP exe looks for runtimes. It's not wrong there, but an Installshield Express would install to C:\Windows\SysWOW64 AFAIK. Also when registering it would do that at setup and not when starting the EXE, and using the regsvr32.exe from there and not from C:\Windows\System32.

So what you could try is manually doing what was missed at setup: Registering the runtime dll where it is now. First step is running cmd.exe elevated (this will show in its title bar "Administrator:Commandprompt"). To do so find cmd.exe in the start menu and don't simply start it with click, but choosing "Run as Administrator" from the start tile right click context menu. Now you can do many things like registering DLLs with success and not just seeming success.

You are at such a command prompt now? Then CD C:\Program Files (x86)\Common Files\Microsoft Shared\VFP\ and then do %SYSTEMROOT%\SysWow64\regsvr32 vfp9r.dll

If the setup has such a problem of not registering DLLs with the correct regsvr32.exe, it has that problem since Vista and only not in 32bit Windows versions, where there is only one regsvr32.exe, the problem could be the setup.exe was done with something else, maybe a full version of installshield or inno setup in a 64bit version. 64bit setups use the 64bit regsvr32.exe and therefore register into the 64bit registry. The 32bit application exe then does not find the runtime.

Bye, Olaf.

 

[Olaf Doschke]

A detail you should know is System32 and SysWow64 folders have opposite meanings than one would deduct from their name

SysWow64 is short for SystemWindows32onWindows64 and thus has all 32bit system tools.
System32 is named that for compatibility reasons.

In both system folders tools like regsvr32.exe can be found, and again for compatibility reasons have the same name with 32 suffix, also the 64bit versions.

And to top this UAC redirection takes place if a 32bit process wants to run System32\regsvr32.exe, it runs SysWow64\regsvr32.exe, which is correct. But if a setup creation tool creates a 64bit setup this will use System32\regsvr32.exe without redirection and thus register into the 64bit registry, where the information is lost to a 32bit executable looking for it.

Bye, Olaf.

 

[k2a]

Thanks so much Olaf for excellent help.

Just did what you ask me to do running the command like this:
C:\Program Files (x86)\Common Files\Microsoft Shared\VFP\ and then do %SYSTEMROOT%\SysWow64\regsvr32 vfp9r.dll

Big surprice this fixed the problem. Now my app runs flawlessly and afterwards could install other vfp apps without any error messages.

Your findings are amazing, thanks again!

 

[Olaf Doschke]

>afterwards could install other vfp apps without any error messages
That's an advantage of a separate runtime folder with registered vfp9r.dll, any EXE done with VFP9 finds it.

One downside is, there is no differentuiation of VFP SP0 (original),SP1 and SP2 versions in how an EXE tries to find its runtime, so the one you installed with the first application is found and used for others too. Technically that is working, the entry points in the runtime DLL SP versions all are equal, but I had problems specifically with SQLBUFFERING causing C5, if a SP2 EXE was run with an SP0 runtime DLL, so there is a little "DLL hell" about this way of installing. No reason to change anything, just watch out in case you experience errors.

Seems you're ready to go, simpler apps don't need much more than the vfp9r.dll


The best practice is to install EXE + runtimes in each application folder, no matter how many copies of VFP runtimes that means.

If your application uses HELP or combines the application itself with a CHM helpfile, then the foxhhelpp.exe also needs registering, as this is an exe it's done via a call of itself with /register command switch in admin mode cmd.exe. And then there is the foxhhelpps9.dll which needs registering as the vfp9r.dll

If you also create DLLs in VFP you may operate them (depending on build settings) with the mult threaded vfp9t.dll

What is simply found from the registered vfp9r.dll is gdiplus.dll and msvcr71.dll, they don't need extra care.

Bye, Olaf.

 

[Dan Olsson]

I agree with Olaf. From way back in W95 and up to W10 I have ALWAYS put the runtimes, msvcr71.dll etc in the applications directory. No problems what so ever with registering or so...