I got a call from our longest term customer. We have worked together for some 13 years. Normally I like getting a phone call from them. But I dislike the calls that go something like this: “Rick, long time no see…heh, my computer got hit by a virus when the grandson played an Internet game on it over the weekend. My hardware person said the computer is too old and not worth fixing. He is ordering me a new Windows 7 computer, and upgrading Office from Office 97 to 2010. You don’t think there will be any problems with your Visual FoxPro 5 app, do ya?”
This computer is the only computer for the company and is close to 8 years old, and really did need to be replaced. This customer is running a Visual FoxPro 5 app that I developed in 1997 and has run without major issues since then. The app is so reliable I cannot convince the customer to upgrade it to Visual FoxPro 9.
So let me see, how much could go wrong with VFP 5 on Windows 7 64-bit, using Aero? The app uses Excel to import records via a remote view, and automates Word to generate letters and envelopes via VBA in Office 97. Hmmm, a few versions of Office, lots of potential glitches with Aero, and a handful of ActiveX controls and FoxTools.FLL. My response was: “I don’t have any idea the number of things that could go wrong.”
My greatest concern was the 32-bit ODBC drivers for Excel, followed by the VBA automation, and then the User Interface glitches we have seen in newer versions of Visual FoxPro on Aero. I also used a couple ActiveX controls and had no idea how well it would work on Windows 7.
I did immediately think it was my opportunity to update to Visual FoxPro 9, which means no more Visual FoxPro 5 apps to support. {big evil grin}.
I arrived at my customer’s home. He literally runs his business out of his basement. I start up the app and it immediately crashes on “API library is not found.” Easy one, FoxTools.FLL is not loaded with the run-time files. It took me a little bit of time to track down the location of the VFP 5 runtime files, and copy over a copy of FoxTools. Run-times were in the Window’s SystemWOW64 folder instead of the System32 folder. App up and running FTW. I tested out most of the data entry forms and there are no UI glitches. Customer is happy to see the app running.
Celebration lasted about 2 minutes when we tried to import the Excel file. Hardware dude who moved over “everything” forgot to set up the ODBC driver. This is easy to overlook and I had good documentation on setting it up. I dig around and find the 32-bit ODBC Manager and set up the ODBC driver. Import routine works just fine. Another round of premature celebration follows.
Surely something is bound to go wrong, right? I mean, would I even dare write a blog post about a perfect scenario for an upgrade? Probably not. {g}
Off to test the letter generation code. CRASH! It is not what you are thinking if you are thinking the VBA code was not working. It crashed on the silly progress bar update that runs as the letters are generated. It crashed on the progress bar setting the value to zero, as in zero percent. Odd. I futzed with the code and tried a few things and eventually determined the progress bar was unnecessary for the moment. The VBA code actually ran without a single hiccup once I got past the progress bar not making progress. I am curious about the progress bar, but that battle is for another day. It was more important that the letters and envelopes are generating so the business can meet their commitments to their customers.
Oh, and thanks Microsoft for keeping backward compatibility with VBA and the Excel ODBC driver in Office 2010 on Windows 7. Nice job! Kudos to everyone on the Office team for not making my life miserable and showing the customer that his investment in Visual FoxPro and Microsoft Office was a well placed investment.
The only things I wished I had today was the current error handler we use, and time to dig into the progress bar issue. The error handler I wrote back in 1997 feels weak. The one we use today is way more robust. I am speculating that the progress bar only accepts integers and I am passing decimals, or it is looking for the percent.
The moral of this story is to add one more thing to consider the next time a customer calls and wants to upgrade to Windows 7: native Windows ActiveX controls. Silly thing is I avoid most of the Microsoft ActiveX controls these days because of the deployment headaches. Not a single issue I worried about materialized. It was the unexpected problem that consumed most of my time. That, should not be a surprise.
Thank You Rick! An offhand comment you make here combined with a blog post by Christoph (http://www.foxpert.com/knowlbits_200909_1.htm) fixed my runtime crashes today.
The problem was the conflicting version of the Resource File in SysWOW64 with the new Hotfix runtime. Got everything up-to-date in SysWOW64 and made damn sure all other versions were out of the path and everything’s working again.
My biggest frustration was that Windows7 wouldn’t find files anywhere despite my telling it that I wanted it to look everywhere. I may look back at Copernic or something.
Again, this has come into play for me but in a different way. You write “I dig around and find the 32-bit ODBC Manager and set up the ODBC driver” but you didn’t really expand on that. I lay it out in my latest post: http://saltydogllc.com/?p=356.
It’s Thanksgiving, and I am thankful for you and your posts.
Rick:
I’ve been programming for 39 years, and I’ve called vfox “home” for the last dozen. Win 7 is making me think about finding a new language. LOTS of problems. My current flagship desktop product uses VFP8, is networkable, and incorporates a number of third-party controls. Win 7 sets up the application normally, but refuses to utilize the tables that get installed. Instead, it makes copies of those files in a hidden directory, and USUALLY uses those. In a network situation, where those files get moved to a server folder during the first run, it does not delete those files during the move. With 2-3 sets of the tables and database containers, data is quickly corrupted. If uninstalled, the tables in use don’t get removed, any corrupt data stays around forever. Any fixes?
Hi Scott,
I sounds like you are running into Windows folder virtualization, which has nothing to do with Visual FoxPro. This was something introduced in Windows Vista so you are sort of lucky you are just getting bit by it now. Files that apps write to in the Program Files subfolders get virtualized in a different folder. The really bad part about this for VFP data is that it might only update and virtualize one of the three data files, for example the memo file might get virtualized, but not the DBF or the index file. Painful realization when you go to backup or gather the files to pass back to tech support.
Recommendation is to not load data in the Program Files subfolders. You can either load your app in a different directory structure, or leave the app in Program Files and make it smarter to look for the data elsewhere. Alternatively you can make the data folder so the user does not need the administrative rights.
And for what it is worth, I never let my uninstall process remove the user’s data. To dangerous if the user needs those files for another install or just want to keep their data around. It is easy to not uninstall using Inno Setup, which I highly recommend.
Thanks Rick. Yeah – I’ve got ~ 5000 active users of this program, and had few or no problems during the “Vista period,” probably because nobody liked Vista. 90% of the folks who run it on Win 7 have no problems either – unless they uninstall & reinstall, or change from stand-alone to networked shared data.
I tracked down the virtualization thing early enough, just never assigned the right name to it so I could find more information. If you don’t mind my asking – so that I don’t have to re-invent the wheel:
So that am I correct in understanding: You are saying that I can successfully install the data files anywhere outside the program files directory structure and they will not be copied/ redirected to the virtual folder for use? I’d certainly hate to create a solution that works on a test machine but fails on other machines.
Also – mostly as comments for all – my program creates various files for temporary use, mostly .html files to be viewed in a browser, or .csv files for export. It was probably bad judgement that I allowed these files to be created in whatever directory the program was working in at the time, knowing it would be deleted a few seconds later. This is obviously part of the same virtualization problem. Now our registration routine is a crap-shoot as to whether it will work on win 7, sometimes it does, sometimes not. – Just thought I’d warn folks not to practice this.
Also – I was dumbfounded the first time that a user told me that one of the controls we wrote off as “incompatible” for Win 7 operated fine on a win 7 64-bit system. (a control that sends email) We’d attempted to load those controls on a Win 7 machine and installation failed. It appears that sometimes if a control is installed as a member of the application’s directory, (not sent to be self-registered in the system directory) it works. Strange phenomenon???
I’ve got another app that runs a 2-D scanner to collect data. (PDF417 barcodes can contain up to 2000 characters of data, quite useful.) The manufacturer’s new 64-bit installation routine is absurdly “clunky” and we attempted to circumvent it by directing the proper components to their proper Win7 locations. Big failure. It appears Win 7 does not allow self registration of components??
Just thought I mention these things in case others run into them.
Lastly – I’ll look into Inno. Although I will comment that many of our users first install our software as a trial, placing bogus data in the system, then want to clean all the data when they purchase. It’s pretty handy have a re-install create fresh data files. Still – I think I’ll take your advice and create a routine that can perform this without uninstalling.
Thanks again. I gotta lotta programming to do now on many apps. – Scott
>>install the data files anywhere outside the program files directory structure and they will not be copied/ redirected to the virtual folder for use?< <
Yes. And the files you create in the app root folder are also going to be virtualized unless you move out of Program Files.
>>I was dumbfounded the first time that a user told me that one of the controls we wrote off as “incompatible” for Win 7 operated fine on a win 7 64-bit system.< <
All you have to do is install them as Administrator of the machine. Or use a Setup routine that is recognized by Windows to raise the rights to administrator. It is all about security, and naturally compatibility. Putting the controls in the app root folder does work, and you remove the dependency from the System32 folder where other apps load files that are potentially incompatible. Same for the VFP runtimes.
>>I’ll look into Inno.<<
You can have Inno always overwrite the data files so your install will refresh the trial users. I personally find this a bit problematic with users accidentally overwriting their production data. It might be easier to have a special “data refresh” install for the trial users to run once they are ready to move to production.
Rick
Here’s one. Visual Foxpro app 7.0 on an XP machine connecting to sql server 2000 database (as the back end) which is on on a win 2003 file server — no problem.
Upgrade to windows 7 client and program does not see sql server. I can connect via ODBC from Access to sql 2000 but not with VFP app.
The server was upgraded from win 2000 to win 2003 but I can run the app on XP and connect to sql server 2000 on the win 2003 fileserver. Just can’t with the foxpro app.
So the problem is connecting to sql server from the foxpro app using the Win 7 pc as client.
If the Win7 computer is 64-bit you have to make sure to use the 32-bit driver. If using the ODBC Manager make sure to run the one from the correct 32-bit folder.
OK Rick here is my problem. Using an old VFP Program “TeleMagic” on a Windows 7 64 bit professional client accessing a MS 2008 SBS Server. Program works fine stand alone on the client but cannot seem to find the “F:” drive on the server where the data is. In the Network situation the program and data are run from the server. As a work around I installed Virtual PC and XP Mode on the clients and it does find F: and seems to run pretty well although copy and paste from the Virtual mode back to Win 7 doesn’t always work and it has some problems crashing. When a crash happens it is much harder for the customer to know how to recover in Virtual XP mode. Any ideas what can be done so that VFP can see the correct mapping in the Windows 7 client? BTW it works fine in Win 7 premium but not in professional. Tried turning off the the firewall and giving Admin rights but no luck. Still getting either an “unknown” error or path not found.
Sounds backwards that mapping works with Window 7 Home Premium and not Windows 7 Professional. I am using Windows 7 Professional 64-bit and I can access servers just fine via a mapped drive.
I’m not much of a hardware or networking support person, but is it just the one machine or all Win7 64-bit machines? Is there something set funny for networking. Do other apps have trouble with the mappings? Is Windows losing the mappings? What about using UNC pathing to the data? Does the server recognize the client computer?
Sorry, more questions than answers from me.
I appreciate any ideas. This client got 14 new Win 7 professional 64 bit laptops and they all work ( not seeing the drive mapping from VFP) the same way. An existing XP machine works just fine with drive mappings and so does a win 7 premium laptop that I tested on the system. I tried taking one of the laptops out of the domain but that also did not solve the issue. I may have to keep using the Virtual XP mode if nothing else works. Seems like some type of security issue with Win 7 Pro but I have not found what to do to correct it yet.
Alguém poderia me orientar na instalação do Visual FoxPro 5.0 no Windows 7 – 64bits?
Grato,
Carlos Tavares
Carlos,
“Could anyone guide me to install Visual FoxPro 5.0 on Windows 7 – 64bit?”
You can install it just like you would any other 32-bit application. Or you can copy an existing install you have set up on another machine. Or you can run Visual FoxPro from a thumb drive.
If I can be so bold, my recommendation is to get Visual FoxPro 9 SP2 with all the latest hotfixes and use that. It is the most stable version of VFP ever.
While 9 may be the greatest in some folks mind, it is different aND has lotsa gothcas when trying to run older apps that are not object oriented and totally in tune with the MS Geekdom.
A necessary code snippet at the front of any of the old programs is:
IF “09.00″ $ VERSION()
_SCREEN.THEMES = .F.
SET ENGINEBEHAVIOR 70
ENDIF
Not doing the enginebehavoir thing breaks the SQL GROUP BY command — they made VFP9 compatible with Access/SQL Server and hence incompatible with VFP7 and before.
Similarly any SPR files for VFP7 and before when compiled/run causes the contents of the window to disappear with a mouse rollover unless the _screen.themes thing is in place.
Finally, a condidtion that I have not found a workaround for yet is that in VFP7 when in a browse window nothing would happen when the user clicked outside the browse window (only for would get you out) In VFP9, clicking outside the browse window closes the browse window just like you had hit . I think the themes thing has an impact here, but it seems to be the direct opposite effect to that with the mouse rollover majic disappearance feature.
All big BUMMERS…
We are having some issues with Windows 7 virtual store. Our VB6 Application gets installed in program files folder on client pcs. We use the application installation directory to create temporary files for various reasons.
We always create a FoxPro 2.6 database file for doing mail merges to Word or running some Crystal Reports. With windows 7 virtual store turned on, it seems that the FoxPro tables that do not have memo fields get created successfully but as soon as we attempt at creating a DBF file containing memo fields, the actual FPT file gets created but it has 0 bytes. I have looked at the actual FPT file in note pad and there is absolutely nothing there. However, all other files like DBF, INF and any CDX files get created successfully.
On the same pc, if we turn the virtual store off, everything works perfectly. Obviously, the files get created in the application installation folder rather than being virtualised.
I just cannot understand why all other INF, CDX and DBF files get virtualised correctly but the FPT file gets stuffed. I cannot open the DBF file because of the fact that the FPT file is corrup.
Would greatly appreciate anyone’s thoughts on this.
how to pack so overcome visual foxpro 9.0 can not find its location on windows 7. when installed in windows xp can,, made me dizzy