Will VFP6 have issues with Windows 7 64-bit workstations and 32-bit Server? 1

[KarenLloyd]

Hi there Gurus

Could I have some help please? I have just had some questions regarding renewing the hardware for one of my clients.

Q1 - Is VFP6 compatible with Windows 7 64-bit?
Q2 - And what if they keep the 32-bit Server - will that work?

I'm definately no hardware buff, so in short my answer was - I don't know, yet.

I have tested one VFP6 app on a Windows 7 64-bit laptop - but not extensively.

The VFP6 application in question regularly uses automation for Excel, Outlook (and sometimes Word). AND it also uses ghostscript for PDF printing... So I would have to test all of these things next.

I have seen varying sources of information that say that it is not without issue, and installing a 32-bit app for 64-bit computers can mean tweaking various things that I do not think I can get into.

Does this have the potential to become a nasty can of worms? Or is it nothing to worry about?

Any thoughts please?

Karen

 

[Olaf Doschke]

It's more towards nothing to worry about. As you most probably already saw your app is working.
Of course you install all runtime files needed, but that's true for any underlying OS.

Some of the hurdles to take are UAC, restricted rights to registry and folders. Testing all functionality with office automation and ghhostscript will tell that.

You will have optical differences, because you cannot control Themes with VFP6, and there are known bugs with Aero, which are fixed since VFP9 SP1 only, so you would need your users to turn off aero rendering of forms to not be affected. The looks are not really that important, but there also was a visibility bug with listboxes on pageframes showing through, even when the pageframes were not active.

There are many things better with VFP9 anyway, of course.

Your 32bit app would need 32bit ODBC drivers, if there are any involved. Any drivers only available 64bit will not be seen by th VFP runtime or your process, as it's 32bit. But since VFP is pretty much self contained with native DBF file access you don't depend on much. You can even automate 64bit Office apps, as far as I know. Cetin Basoz reported problems to make use of VFPOLEDB from within VBA in Word2010 64 bit, but that is the inverse problem, of course a 64bit office application can't see the 32bit VFP OLEDB Provider. That same limitation applies to VFP9 still, it's also just 32bit of course.

VFP6 needs an older C runtime, than what is present due to the OS, but that most probably already was a problem with XP and VFP6, since VFP6 needs the Msvcrt.dll version 6.00.8168 (also see thread184-1706588). That's no problem as you will distribute that DLL already anyway, if you don't rely on the C runtime being present. You will find it on your development PC as it comes with VFP6/Visual Studio 6.

There's the one or other hurdle to take for sure, eg usage of API functions, if you do so, have to be checked to work in Win7, too. Things you add via DECLARE-DLL, eg declaration of ShellExecute, CreateProces, GetDefaultPrinter or such functions. Many of them still work the same way and still are part of Win7, but some may have deprecated.

So testing all functionalities is the core thing to do.

Bye, Olaf.

 

[KarenLloyd]

Olaf

Thank you for the thread link and for reminding me about the API calls, which I had forgotten.

I will make sure that they have the older C runtime on the newer computers, but the application itself will remain on a 32-bit Server. Obviously I have a lot to test - so I will have to start building myself a list.

I appreciate your quick response.

Thank you.

Karen

 

[Mike Lewis]

Olaf,

I was interested in your remark, re API functions: "Many of them still work the same way and still are part of Win7, but some may have deprecated."

I had never thought about deprecated API functions, so I did a bit of research. I found this list:

    Active Scripting
    Collaboration Data Objects for Windows NT Server
    Dynamic Data Exchange
    Older data access technologies
        Microsoft Jet Database Engine
        Data object
            Data Access Objects (DAO)
            Remote Data Objects (RDO)
        Remote Data Services (RDS)
    Setup API
    Windows API's old versions: Win16, Win32s

Source

I don't think these will affect many of us, but I thought I'd post it here in case it does.

Mike





__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[JRB-Bldr]

The VFP6 application in question regularly uses automation for Excel, Outlook

With Win7 you are most likely now having to automate a newer version of MS Office (maybe 2007/2010).
Maybe you tackled this before the Win7 change, but if not, it depends on what you might be Automating.

For example: If you were using Automation to have an Excel file do a SaveAs... into DBF format, that is now gone in Office 2007/2010.
You would have to change it to do the SaveAs... into another format (such as CSV) and then use it.

If you were using 32-bit ODBC drivers they would need to be installed into the C:\Windows\SysWOW64 directory (see:

http://community.spiceworks.com/how_to/show/2795-odbc-for-32-bit-applications-on-windows-7-x64)

And you will have to check that the directories that you are using now have the appropriate rights - a number of the directories that we used to use are now 'protected' Win7 directories.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

Hi Mike,

Wikipedia is one of the better sources. I'd look into details in the MSDN, as it does not only state deprecation, but also changes and better suited alternatives, Ansi and Unicode variantes of the same function etc. I remember from 2007 you had to reimplement functions for getting systemfolders, due to the new Known Folder GUIDs since Vista.

I also doubt there is little to fear in that range, but the recent Win8 shift to a totally reshaped API is telling me there is more deprecation to be expected in future Windows versions. I don't have any insight, though, not even under NDA. So this is merely a feeling and oppinion. But running dependency walker on the vfp9r.dll reveals quite a lot dependencies on system DLLs, more than I expected.

Bye, Olaf.

 

[KarenLloyd]

Hi JRB-Bldr

I don't think we'll have problems with the automation side, but you have given me some more useful information for me to check out.

Thank you.

Karen