VFP 6 on Windows 7 1

[MMund]

I support over 100 VFP apps currently running on Windows XP. Most of these are VFP 6, a few VFP 3, and a few VFP 9, all of which were written by programmers who left before I was hired. We are getting ready to make the jump to Windows 7. My question: Generally speaking, will these apps run OK on Windows 7? Would it help to convert the ones that aren't already VFP 9?

Thanks in advance,
MMund

 

[Olaf Doschke]

Talking about Foxpo itself, the IDE:

VFP9 is good to go on Windows 7.
VFP6 is harder to install, but will work, you will find it hard to get SP5.
VFP3, no idea.


Talking about applications programmed IN foxpro and compiled:

You need the C++ runtime, FoxPro Runtimes (correct SP), you may need to copy over some OCXes and register them, but VFP.EXEs in themself can run from Win95 up to Win8, there is no incompatibility in sight.

Bye, Olaf.

 

[Mike Lewis]

Olaf,

You said "VFP.EXEs in themself can run from Win95 up to Win8,".

Actually, I think Win95 is no longer supported. From VFP 7.0, the minimum OS for VFP executables is Win 98.

Not that it matters one jot as far as this particular question is concerned. I just thought I'd mention it, as I've been very quiet lately.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

You're right. I think it was someone mentioning you can also get foxpro exes to run on w95b, if gdipluls is added. There may be some other stuff needed, but it's rather theoretical anyway, it just demonstrates how few dependencies foxpro has into the OS, it just makes use of some very central kernel functions eg for memoery management and of gdiplus for drawing, Winforms libraries, Ole of course, to support activex, but that's already about it.

That's what I wanted to emphasize.

You will likely introduce more dependencies via DECLARE DLL using something only available since XP or higher. And of course as mentioned ActiveX control uage, even of MS Common Controls, and MAPI (we had a thread about that recently, see there)

Another hint: Simply cope the Home() dir of a VFP installation to a USB stick, then attach it to a new Win7 PC and run the main VFP9.exe (or of course VFP6 or 3) with /regserver swtich, while having UAC turned off and with admin rights.

Then registry settings and file associations should be fine and VFP is good to use. Could be a good test also for VFP6 and 3. And you spare reinstalling and searching VFP6 SP5 and whatever needed for VFP3.

Bye, Olaf.

 

[craigber]

Mike: There's a difference between "supported" and "won't run" in Microsoft speak. Supported means you can't call Microsoft for support and ask about. Won't run means just that. Do you want to clarify your statement?

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Mike Lewis]

Good point, Craig.

"Not supported" was my own choice of words. I'll amend the statement to "won't run".

That said, I've never actually tried to do this (run, in Win 95, an executable produced by a recent version of VFP) - and I probably never will.

The Wikipedia article on VFP (

http://en.wikipedia.org/wiki/Visual_FoxPro)

says that Windows 95 is not a "supported windows version" for VFP 8 and 9, and is supported for run-times only for VFP 7. VFP 6 is supported for all versions from NT 4.0 to 7 (presumably the article hasn't been updated for 8).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[MMund]

Compatibility with Windows 8 is not a big issue for us at this point, as we're just getting ready to move to 7, and will likely be there for some time. Also, some of the old VFP3 apps may no longer be used, and if they are, I'll probably just convert them to VFP6.

 

[Dan Freeman]

Note also that there's a difference between "exe will run" and "application will work" (which is the question asked).

If the application writes data to the app's folder in %Program Files% or another "protected" location, for instance, there can be configuration issues at the very least.

The real answer is "it depends".

 

[Olaf Doschke]

While it's true, what dan says, writing into %Program File% and reading from there is redirected to a "VirtualStore" folder of a users profile, so to a program reading and writing in %Program File% succeeds, while it happens somewhere else.

A problem is, that an installation indeed CAN and WILL put data into %Program Files%, as installations can write there. But this also is taken care of by the redirection mechanism: The redirection will detect there is no VirtualStore file at first and read from %Program Files% and then write to VirtualStore, and in the next run the data is read from VirtualStore, so it's like it's always been there instead of %Program Files%.

What MS did not think of is, every user has it's own VirtualStore. So each user will see and modify the initial database and have their seperate database in their Virtualstore in the end, even if the data in %Program Files% was meant as shared data of multiple computer users.

If you have normal multiuser apps, the data would rather be on a server share, anyway, so I don't see this as a big problem

And if all else fails, you can still set folder permissions to enable writing into %Program Files% or turn off UAC for a temporary arrangement. In a company using self written software, the software distribution may also not be done via setups, and so if you get these problems can also be answered with "it depends".

This is what Doug Hennig said about Vista, which still holds for Win7:

http://doughennig.blogspot.com/2007/12/where-should-data-go-in-vista.html

The situation he thinks of here is single user with local data, again. And he says he mainly uses this writable data folder within Program Files for a configuration ini:

The main thing stored there is an INI file that contains a setting specifying the location of the data files.

We solve this by a centraly stored config dbf, which contains config for any foxpro applications in that company regarding paths or sql server connection strings.

The only hardcoded path needed is the location of that dbf. Everything else can be read from there: paths, connection strings. Of course you can also store a path to another/additional config file. This solution for configuration applicable to your situation quite well, so perhaps your company already does something similar.

Bye, Olaf.