VFP9 Error Compiled In a Different Version

Hello all. I have an exe that is generating the following error:
Object file ***.exe was compiled in a different version of FoxPro.

This error is only appearing when running the exe on Windows 8 64 bit. Not sure about Vista, as I don't have a PC available with Vista

It does not appear on W2K, XP or 7.

The project is several years old, with the oldest code originating from within VFP 6.
Most of that code has been replaced over the past several years with code generated inside VFP 9. The exe was compiled in VFP 9.

The exe is then Re-Foxed, so it's compiled again, and then Inno Setup is used, so it's compiled once more. Don't know if this would have anything to do with the error message generated or not, since the error seems to be indicating that it's the VFP compiler that's different.

Just looking for some help or suggestions to try.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Olaf DoschkeSoftware DeveloperCommented:
Did you "recompile all"? FXPs are used as they are, if you don't

Also, how do you start the exe? If you start an EXE with DO some.exe it's not starting a new process and so uses the runtime already loaded.

I also assume your Win8 machine only has VFP9 runtimes installed, while other computes also include installations of previous runtimes. That would explain it, too.

Bye, Olaf.
formadmirerAuthor Commented:
I recompile all everytime I build, just always have.

But based upon some tips I found elsewhere about this problem I've even tried Rebuild Project and Regenerate Component IDs. Neither of which did anything.

Another suggested rebuilding the fpw file, but I'm not using one.

As far as how I start the exe, I'm not sure what you mean (my ignorance is showing!). The prog gets installed, the desktop icon is clicked and it starts. The main.prg is really pretty minimal with little more than SET SCREEN OFF and SET RESOURCE OFF followed by calls to about four small prgs that setup the environment before the main form is called.

All of the PCs were VFP virgins, none had ever had FP code installed before.
And it's not clear from my post, but there are two different Win 7 machines, one 32 bit and one 64 bit, the error shows on neither.

It really puzzles me that on Win8 it initially shows the error and stops the exe, but when you restart the exe the second time the prog runs just fine.
Olaf DoschkeSoftware DeveloperCommented:

must be something new from Windows 8, I'm not aware of, yet. Another twist of User Account Control and file access and or registry redirection/virtualisation.

How do you install runtimes, do you use the Merge Modules coming with Installshield Express coming with VFP9? It may be better to manually add the runtime files to your program directory and not use the merge module. Since Installshield Express isn't even Vista aware.

Also at  another forum (I think MSDN forums) someone had problems with an MSI installer on a 64bt Windows, which I think is because MSI packets are always handled as 64bit software. At least the msi file extension is associated with a 64bit dll used to trigger the Windows Installer system and that may mean runtimes go to the 64bit directory, while they best are not installed in a system dir at all, you better have them side by side by your EXE, then you only need to register foxhhelp9.exe

Well, I think I pointed to the fox wiki runtimes page often enough. fox.wikis.com/wc.dll?Wiki~VFP9RuntimeFiles.

It also has some hints on registration of the runtimes. Mainly that's optional when the dlls are installed in the program files directory of your app, the only thing needing registration for SET HELP to work is the registration if foxhhelp9.exe. Side by Side installation also has the benefit you can ensure the right service pack level DLL is used by your app.

That said I myself am changing oppinion back and forth, if you google. Anyway I have to maintain software in a company causing 1000s of copies of the DLLs via xcopy in a LAN, where that also is limited via the xcopy switch to only copy newer files, but then also have to bring an update through a 1Mbit VPN tunnel leased line and that's best limiting the software update to not contain the runtimes and have them preinstalled, which I advise via the Prolib runtime installers. And this registers them at the central system folders foreseen for c++ and vfp runtime.

Everything has it's pros and cons. With Win8 it seems you best go for runtime side by side installation again.

Bye, Olaf.
Protecting & Securing Your Critical Data

Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage

formadmirerAuthor Commented:
I did quite a bit of research when I was building the installer, which is handled with Inno Setup, which I run in 32 bit install mode regardless of the OS/architecture.

I found two different Runtime Files installers, but opted instead to find out what files are needed and to place them where they need to be myself, while registering those that need to be registered.

I'm pretty sure the issue is somehow tied to the Win 8 64 bit architecture, although I'm not sure why I don't see the error on Win 7 64 bit.  I say this because I am still a little confused as to where to place various dlls in a 64 bit install.

Here's what I'm doing now:

Source: "C:\myapp\msvcr71.dll"; DestDir: "{sys}"
Source: "C:\myapp\msvcr71.dll"; DestDir: "{cf}\Microsoft Shared\VFP"
Source: "C:\myapp\gdiplus.dll"; DestDir: "{app}"; Flags: ignoreversion
Source: "C:\myapp\gdiplus.dll"; DestDir: "{cf}\Microsoft Shared\VFP"
Source: "C:\myapp\vfp9r.dll"; DestDir: "{app}"; Flags: ignoreversion
Source: "C:\myapp\vfp9r.dll"; DestDir: "{cf}\Microsoft Shared\VFP"; Flags: regserver 32bit
Source: "C:\myapp\vfp9t.dll"; DestDir: "{app}"; Flags: ignoreversion
Source: "C:\myapp\vfp9t.dll"; DestDir: "{cf}\Microsoft Shared\VFP"; Flags: regserver 32bit
Source: "C:\myapp\vfp9renu.dll"; DestDir: "{app}"; Flags: ignoreversion
Source: "C:\myapp\vfp9renu.dll"; DestDir: "{cf}\Microsoft Shared\VFP"
Source: "C:\myapp\msxml3.dll"; DestDir: "{sys}"; Flags: regserver 32bit
Source: "C:\myapp\msxml3r.dll"; DestDir: "{sys}"
Source: "C:\myapp\msxml4.dll"; DestDir: "{sys}"; Flags: regserver 32bit
Source: "C:\myapp\msxml4r.dll"; DestDir: "{sys}"

Open in new window

{sys} is system32. I believe that when a 64bit system is detected they are placed instead into syswow64
{cf} is common files
{app} is my app's directory
the regserver flag registers the dll, in this case as 32 bit

I am installing no other exe, only the exe for my app. I had read a forum post elsewhere about this problem being caused by re-foxing and including more than one exe. So that's not the cause.

It's still very puzzling, and it's difficult to tell people to just ignore the error message and restart the program a second time to get it running. Doesn't look all that good...

it can also be an antivirus program which blocks an access to the EXE file. I suppose the error is reported on some NEWOBJECT or DO or similar command which has the EXE specified as one of parameters. If the antivirus blocks an access to the file then VFP can identify it as a different version... And antivirus can work different way the first time than later...

What EXE is reported in the message? Does the app uses it? Or are there stars in the place of EXE name?

Maybe you could tell what command causes this error. Maybe you could switch the antivirus off and test the app again etc. etc.

A dirty work around:  Start the application again if such error occurs.
Olaf DoschkeSoftware DeveloperCommented:
Is it really just the exe? No external code in fxp, dbc, frx, which still is not recompiled?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
formadmirerAuthor Commented:
I wasn't able to resolve this and had to move on. At some point in time I'll have to revisit the issue, but for now I'm closing this. Thanks for the help.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Applications

From novice to tech pro — start learning today.