So in response to some messages here over the last few weeks (I guess after SW Fox), I tried to set up Visual FoxPro Advanced (ie. VFP '10') and run it through some basic Web Connection tests. The good news is, it works and I can get it to run through all of the Web Connection demos and the message board so that's a good sign.

It works even in COM mode...

The above is running the Web Connection .NET Core Web Server locally, in COM mode, running the Web Connection server as out of process COM objects.

Experience Sucks

Installing VFP Advanced sucks. It depends on an existing Visual FoxPro 9 installation that has to be patched to the latest version. What exactly is required is not actually mentioned on the site. You have to manually copy files if you need to update to VFP Hotfix 3 and VFP Advanced basically creates a new patched version of VFPA.exe from your VFP9.exe and the runtime dlls.

Eric Selje's article from SW Fox is the best reference for getting started - the 1980's style Web site has almost nothing in the way of how this is supposed to work.

Using Eric's notes I was able to get VFP updated, but I ran into a problem with a mismatched version of VFP resource files after a fresh VFP install of VFP 9 -> SP2 and the Hotfix 3. The VFPA installer didn't want to work with my resource files. I couldn't work around this with no idea where to get the later resource files. It only worked after Eric was kind enough to send me his files. Neither of us has any idea what needs to be installed for these resource files (The vfprenu.dll and vfpenu.dll files).

If you need to get the IDE installed on a few machines it's going to be painful to remember exactly what needs to happen and what needs updating since the installer isn't doing it for you. Even runtime installation will require installation of the VFPA patch tooling, unless you use the explicit Runtime Compiler that bundles everything for you.

It Runs...

While the application itself runs there are a few little problems with the IDE I noticed even in the first few minutes of using it. This one is annoying since I use config.fpw for most of my path configuration:

• config.fpw doesn't get loaded on VFP startup, so all environment settings didn't work from there. It doesn't load by default out of the launch folder or an explicitly assigned folder with -c.

Also noticed that the desktop icons were not always showing up when running the application either in file more or in COM (interactive) which is weird. Just showed an empty icon spot.

If I ran into these issues in just a few minutes of usage what other things are actually not working correctly? I can't imagine that I would trust a monkey patched runtime which even under the most ideal conditions and rigorous testing would be extremely error prone. But alas - that's a chance you have to take with this. The fixes seem very focused although the >2gb file limitation removal has to be affecting a lot of the data engine - that's probably the most scary fix and probably one of the main reason anybody would want to use it.

Bottom line - Web Connection runs under VFP Advanced it works to process requests even in COM mode, which I would have throught to be problematic. I also checked:

• Various Win32 DLL interactions
• wwDotnetBridge interaction (important at this point)

and all that seems to work. Since wwIPStuff.dll which is a heavily used component of Web Connection, is 32 bit, one has to use the 32 bit version. I can hardly see when the 64 bit version would make sense since if you're using VFP UI components or any of the existing ActiveX controls they are all going to require 32 bit operation (like the WebBrowser control or MS Common Controls).

Personally I wouldn't recommend using this even if it does work. There's just too much potential for something to be subtly wrong giving you the appearance of correctly working until it doesn't. I guess time will tell...

If you're going to play with this make sure to read Eric's White Paper - he goes through what works, what's updated and some of the ethical/business issues which are a little more favorable than mine.

For now, those that want to try this with Web Connection - you be the guinea pigs 😄!

+++ Rick ---

Hi Rick,

Those results are encouraging...like you said in a previous post many folks are likely wondering whether the 64 bit version will work with webconnection. You noted there are several 32 bit dependencies. I just came across a site on VFPadvanced that has a paper that indicates that the 64 bit version will work in a mixed mode and be able to handle both 32 bit and 64 bit com. If this is the case, it would seem like webconnection would work in the 64 bit environment. Here's the website with the paper:

http://www.annibalefreda.com/vfp_advanced/VFP%20Advanced%20project.pdf

Excerpts as follows:

For the out-of-process .exe automation server (for example, Microsoft Word, Excel), VFP Advanced 64-bit can use the 64-bit COM objects and the 32-bit COM objects.

For the in-process .dll automation server, VFP Advanced 64-bit can only use the 64- bit COM object. The COM+ applications

For the COM+ applications, VFP Advanced 64-bit can use the 64-bit COM+ applications and the 32-bit COM+ applications.

Just wondering whether I'm understanding this correctly? Thanks

Greg

Web Connection won't work under 64 bit because it uses a 32 bit DLL (wwIpstuff.dll) to provide various framework support features. wwDotnetBridge, various encoding/decoding features - all that requires 32 bit access. So it won't run 64 bit. It's not about COM access as COM invocation is in a separate process anyway so that can be either 32 or 64 bit without a problem.

Why 64 bit?

I really want to understand why anybody really needs a 64 bit version - of anything. Even in .NET where I can safely build 64 bit applications, I find that 32 bit apps tend to be more stable, use less memory and perform better because of the lesser mem usage.

32 bit works and will continue to work in Windows. Just because the OS is 64 bit doesn't mean 32 bit doesn't or won't work. Windows has a 32 bit subsystem that's a core part of the OS and there's no way that will go away. Most of us today run 64 bit versions of Windows and we run many, many 32 bit apps every day. The only way I see that going away is when Microsoft decides to build an ARM version of Windows in which case no Win32/64 apps are likely to run anyway (only runtime apps like .NET/Java or some other JIT compiled platform).

For VFP Advanced for 64 bit I think the only real difference is that you get the larger memory space. Everything else also works in 32 bit. 64 bit has only downsides: Namely that you'll run into compatibility issues. Any 32 bit DLL you call from 64 bit won't work. ActiveX controls, DLL Interfaces, custom FLLS, ODBC drivers you used before may not work. COM may, but direct DECLARE access will not. For desktop apps I'll bet 32 bit ActiveX is a problem: Like the WebBrowser control, Treeview, ListView, RichText... etc.

+++ Rick ---

Always appreciate your feedback and insight Rick. Thank you!

Maybe SQLServer or some other SQL Backend is the best way to break the 2GB barrier. Obviously there's a lot of work involved with converting a VFP App to work with SQLServer. I did it many years ago and I am so glad I did. Ever since, my VFP App can use either VFP Tables or SQLServer. I either use Local Views (VFP), or Remote Views (SQLServer). Most of my clients still use VFP Tables, but some use SQLServer. One great side benefit from the conversion, for me at least, is using Table Buffering = 5 on the VFP Tables almost completely eliminated any table corruption issues. Maybe part of that is improvements in Windows, maybe some of it is improvements in VFP, not sure.

Thanks again for the feedback.
Steve

FWIW, since V 10.15 (Catalina), Mac OSX no longer supports 32-bit apps.
I bet Windows will follow the same route, as soon as MS has migrated all its internal apps to 64-bit

Perhaps, no one knows what the future holds.

However, how many companies would that negatively impact across the globe, if M$ stopped supporting 32-Bit Apps? As a vendor (M$), would I want to put my customers in a position where I force them to re-engineer their entire way of doing business? How many business processes (i.e., software applications) would get broken by such a decision by M$? And, if I (the Customer) have to put forth that type of effort and change the tools that I use to run my business, wouldn't I be foolish not to look at alternative platforms? MAC, Linux, Google, etc....??? If a vendor forces me to go through this exercise, and forces me to incur this type of expense and headache, that vendor would move to the back of the list as a viable option in my book. So, I hope that M$ will look at this not only from a technical perspective, but just as importantly from a business perspective and the potential impact. I think they will, and I think they do. I always say, "Windows runs the business world". I've always loved Windows, from the first time I saw version 3.0. I hope to never have to seriously consider a switch to another platform. However, it's always an option.

Thanks for your perspective and all of your great contributions!!
Steve

Hi Promises are binding only on those who believe in them!

I beleive that 32 bits will be abandoned, it is in the order of things as it was the case for 16 bits.

ARM platforms will naturally accelerate this process of abandoning 32 bits.

Now on a human scale and especially for all Foxpro developers, we will have already retired before seeing 32 bits completely disappear, for others the migration to 64 bits is essential in the short or medium term!

Regards

Gilles

Yes, all good points.

M$ seldom considers installed base when deciding to dump a product… remember VFP?

I don't think you understand the scope of 32 bit applications. Take a look at your Program Files (x86) folder and see what's in there. Tons of stuff that you might not expect to be 32 bit.

32 bit works seamlessly on 64 bit Windows today and it's a natively supported part of the Windows eco system (via SysWow which is an integral part of Windows). Microsoft internally is moving their server products to 64 bit, which makes sense (larger memory requirements etc.) but on client Windows OS's 32 bit is still easily a third of apps running. Heck you can run 8 and 16 bit DOS applications on 64 bit Windows and that still works! Just because the OS is 64 bit doesn't mean you can't run 32/16/8 bit code.

If there will be an ARM version of Windows, it's much more likely that no x86/x64 apps will work, than only x64 apps working.

Look at what the M1 on MacOS is doing. Even there you can still run X86 Mac applications via Rosetta and from the looks of it it actually performs nearly as well as a native x86 processor.

We've been in a 64 bit world for more than 10 years now on Windows where the majority of OS shipments have been 64 bit, and yet 32 bit is not close to dead. So I wouldn't put any credence on 32 bit disappearing even on an x64 platform.

And this discussion in the face of FoxPro is so utterly ridiculous. Here we are with a 12 year out of support product and we're worried about it not running on x64? This is your worry? There are a much more structural issues that we have to worry about like UI issues (which are already a problem in the ever so dated IDE and the funky FoxPro Window UI mechanism) and file access issues due to non-updated file/network protocol (SMB) support.

+++ Rick ---

Dear Rick,
I am happy you tested VFP 10.
I have many customers and many projects based on VFP+WC, applications work very well, so I do not want spend years to recoding to migrate on SQL Server.
I needed to overcome 2 Gb limitation, so I adopted VFP 10.1 32-bit, because it solve the limitation without change any line of code.
Moreover, VFP 10.2 32-bit will use 32 Gb of memory before the end of year and I confide it will be a sprint to applications.
I have found no problems to update VFP 9 to the build 9.0.0.7423 and no problems to install VFP 10.1 32-bit on my development machine.
On Server I brought only the 2 runtime files (VFPAR.DLL, VFPAT.DLL), recompiled executables and all is right.
Every applications functionality has been preserved, so I can only speak well about the new VFP 10.
Moreover, the developer of VFP 10 gives full support and this too is comforting.
If Web Connection was a new life for FoxPro, then FoxPro Advanced is another one.

I've had this post drawn to my attention by VFPA's author Chuanbing Chen asking if I can reproduce any of the issues...

Basically I couldn't reproduce these faults. We've been using VFPA for all commercial apps for years as well as VFP C++ Compiler processing millions of transactions without issue.

In fairness, I first installed Chuanbing's work in 2010 before there was an installer, and it's possible I faced similar glitches that are long-forgotten. However, I'm being contacted regularly by people who got VFPA installed quickly after my 2020 SWFox presentation and now just want reassurance that others have done OK with it.

As an experiment, today I installed VFP9 onto a test machine, applied HotFix, VFPA installs flawlessly. Config.fpw set up with command= to add dev menu; runs fine at startup.

One thing to watch: because UAC can break class browser and other VFP functions that need to write into the launch folder, VFPA has started moving writeable config and other files (foxuser.dbf/foxcode.dbf/foxtask.dbf etc) to %appdata% where they belong. It's worth checking Options\file Locations to make sure that any edits or custom settings are added to %appdata%\Microsoft\Visual FoxPro Advanced rather than the launch folder as in VFP9.

The purpose of the installer is not just a licensing check so VFPA will only install if VFP9 is already installed, VFPA also needs to harvest files from the VFP9 folders (as you note) and there can be issues if unexpected/wrong versions are present. So now the installer won't proceed unless VFP9 dependencies have 7423 file version. If people have special dependencies that aren't patched by Hotfox3, I suppose the installer might refuse to proceed.

I'm very happy to act as guinea pig if people have steps that don't lead to installation success, and/or need it to work with special VFP9 installs. It's for mutual benefit that VFPA installs properly in as many cases as possible and my experience is that Chuanbing is unbelievably quick to resolve issues once he can reproduce them.

Finally, re documentation at the website: most everything needed is there somewhere, but maybe it's time to offer a hand getting a "quick install" document going? I'll check with one or more of those who contacted me to see whether it's fresh enough in their minds to create a "how to" that can accompany the installer. Failing that, I can have a go myself.

Look all I can tell you is:

• Started with a clean machine (just installed at the time)
• Installed FoxPro from ISO
• Installed SP2
• Installed HotFix 3 (that shouldn't even be necessary - given that there's no official download location for this even)

When done ran FoxPro to make sure I could run and build existing applications (ie. ensure SP2 runtime is valid etc.). Then went to install VFPA and it refused to install. That's about as straight forward as it gets. Complains about the runtimes not being up to date.

But it doesn't stop there. After I got Erik's files I was able to get VFPA installed, but then it wouldn't recognize my config.fpw file - explicitly or implicitly, just gets ignored. Maybe this is a small thing, but if the first thing I try (launching!) doesn't work that doesn't exactly inspire confidence.

After taking another look it actually turns out that config.fpw is selectively loading some settings, but not others. PATH is not working, neither is _vfpstart but common SET variables MEMOWIDTH, DEVELOPMENT etc. are. In short even more confusing then not working at all!

I don't want to take away from what VFPA is and does because technically it's a major tour de force. But just because you can, doesn't mean you should. You should have very good reasons for using this tooling and most people I've seen here discussing use of it have no idea what the actual benefits are and they aren't interested in those. It almost always comes back to exceeding the 2gb limit - and that's misguided on so many levels in the first place.

To me this is simple:

The risk to benefit factor is way to high with something that's built based on coding by patching - this is basically the approach used by software crackers do to circumvent copy protection schemes. Not saying that this nefarious or anything (although certainly not legal even if Microsoft is for now choosing to look the other way). Impressive, but is that a sustainable platform to modify and enhance a very complex and 40 year old codebase? It was difficult enough for the Fox team in the late stages to introduce new features without breaking existing functionality. That was with the proper source code and regression testing infrastructure in place. Chen may be brilliant, but brilliant alone does not make for a solid product. To me doing this at the decompiled code level with a few people testing, is just an insane proposition. The potential for something going horribly wrong there - in what is mission-critical software for many - is enormous.

For me this is not a risk I'm willing to take, for a benefit that I don't need. There's nothing in these VFPA updates that make feel like I'm missing out - the only reason I'm looking into it at all is because people here have asked about it and I should at least see if it works. It does, but beyond that I'm leaving it up to each user test what works and what doesn't.

+++ Rick ---

Thanks, Rick

Re 7424 Hotfix: available at the VFPA download site here: http://baiyujia.com/f_download.asp

However, I take your point that it might be better to check for any version of VFP9 and then deploy correct 7424 resources to the new VFPA folder as part of the install. I'll check with Chuanbing how many 7424 dependencies he relies on- there aren't that many.

Re vfpenu/vfprenu.dll: embarrassed to report these were not installed for me with VFP9, but I think I have an explanation:

• various pre-7424 SP2 installers contain vfp9renu.dll, e.g. version 5721 in one I have here
• 7424 SP2 installer does not contain vfp9renu.dll

Therefore if you run more than just the 7424 SP2 on a clean VFP install, you may end up with old versions of some dlls like vfp9renu.dll. I will ask Chuanbing whether the installer version check applies a vfp*.dll skeleton which would explain perfectly. As per above, can be avoided if the installer deploys required versions since I expect vfprenu.dll version isn't critical.

For the rest: many people point to one or more resolved bugs to justify use. We've talked about VFP9's SQL Server field type bug (for which you came up with a cast workaround) and there's also report snafus caused by dpi settings on UXGA monitors that appear regularly on VFP boards. There's also some math fixes and brute force solutions for latest OS that sometimes report momentary delete or rename failures. VFPA will try x times (where you control x) before throwing an error. This is pretty important for batch interfaces or anything processing files quickly. So while I agree in principle with what you say; in practice, we're pretty pleased and distribute rock-solid apps. As for legality: advice I paid for was that bug fixes and interoperability improvements and a few others have US common law justifications for third party remedy if the vendor won't do it, which actually is acknowledged in the EULA. If people are unsure, lawyers are always delighted to advise!

FWIW, VFP C++ Compiler absolutely requires at least one C++ compiling environment and some people have huge difficulties with that... which is what most of the "can't install" emails I get are about. I did some heavy testing and debugging of VFP Compiler with WW and when I eventually provided steps to reproduce the sort of COM glitch you mention here, Chuanbing was able to remedy it as quickly as usual.

@RvBoy,

Thanks for your explanations - I know you're making full use of VFPA and have been since the beginning. We've talked about this before and you're surely taking advantage of all there is to use of the updated features. I doubt thought that most people would take advantage in the same way you do...

The HotFix 3 Dilemma

As to HotFix3 and installation: The problem is that the HotFix doesn't contain updated Resource files (the language specific resources like vfp9renu.dll). That's the files the installer was choking on. So my sequence: Full VFP Install + SP2 doesn't produce the resource files that VFPA expects. I still don't know where the updated resource files come from.

Note here's what I get in my install:

Note neither of these match the HotFix3 runtimes. Without Eric's version the ENU file was the same 5721 which did not work with the installer.

SP2 install has it at 5721 while Eric's version that worked to get the installer to work is 5815. Neither of us has any idea where the updated 5812 resource file is coming from. What do you install to get that? Apparently VFPA's installer only looks at the active locale (ie ENU in my case) and doesn't care about the other resource files.

+++ Rick ---

Hi Rick,

On reflection, status quo probably is safer to require latest VFP9 installed before VFPA will install, as this honors the principle that VFPA is an add-on for Microsoft's licensed product that VFPA does not supply, it only patches it.

When you unzip the VFPA installer, from vba\readme.txt:

     The setup program will check the following files:

     File name                                                              Version     Date        Size       Description
     ----------------------------------------------------------------------------------------------------------------------------------------------
     C:\Program Files (x86)\Microsoft Visual Foxpro 9\Vfp9.exe              9.0.0.7423  2009-4-3    5,783,552  VFP9 IDE
     C:\Program Files (x86)\Microsoft Visual Foxpro 9\Vfp9enu.dll           9.0.0.5815  2007-10-15  1,507,328  VFP9 IDE language resource file
     C:\Program Files (x86)\Common Files\Microsoft Shared\VFP\Vfp9r.dll     9.0.0.7423  2009-4-3    4,734,976  VFP9 Runtime
     C:\Program Files (x86)\Common Files\Microsoft Shared\VFP\Vfp9t.dll     9.0.0.7423  2009-4-3    3,907,584  VFP9 Multi-threaded Runtime
     C:\Program Files (x86)\Common Files\Microsoft Shared\VFP\Vfp9renu.dll  9.0.0.5815  2007-10-15  1,187,840  VFP9 Runtime language resource file

The easiest way to get the correct versions is:

Browse to http://baiyujia.com/f_download.asp then

1. Download and install VFP 9.0 SP2 [9.0.0.5815 VERSION] ( http://baiyujia.com/f_downloadproc_vfp9sp2.asp )

2. Download and install VFP 9.0 SP2 Hotfix3 [9.0.0.7423 VERSION] ( http://baiyujia.com/f_downloadproc_vfp9sp2hotfix3.asp )

Since Chuanbing's site began counting downloads, today's tallies show that of the 42,632 people who downloaded VFPA, fewer than 10% also downloaded the service packs/hot fixes and of those, it appears that hundreds didn't apply 5815 first:

VFP 9.0 SP2 [9.0.0.5815 VERSION] (downloaded 3678 times)

VFP 9.0 SP2 Hotfix3 [9.0.0.7423 VERSION] (downloaded 3979 times)

Not everybody is as resourceful as you and some of them will have given up. Therefore I have recommended a readmefirst!.txt file in the root install folder that focuses on these specific instructions. In addition, it would not hurt to provide a link to this file when VFPA detects wrong versions.

• J

Hmmm... yes it looks like my SP2 install I have here (downloaded some years ago and what I always use) is not the same as the download that the install page redirects to. I had re-downloaded SP2 but apparently there must be two versions on the MS site because the re-install from the fresh download originally didn't update my VFP resource files.

Installing from the linked SP2 installer and re-installing seemed to get the right files installed though.

+++ Rick ---

LOL, you're not alone: all of these must have come from the MS website at some stage:

• VFP9.SP2.4611\VFP9SP2OCTCTP.EXE
• VFP9.SP2.5015\VFP9SP2FEB2007CTP.EXE
• VFP9.SP2.5411\VFP9SP2BETA-X86-ENU.EXE
• VFP9.SP2.5721\VFP9SP2.EXE
• VFP9.SP2.5815\VFP9_SP2.EXE
• VFP9.SP2.6303\VFP90SP2-KB948528-ENU.EXE
• VFP9.SP2.6602\VFP90SP2-KB952548-ENU.EXE
• VFP9.SP2.7423\VFP90SP2-KB968409-ENU.EXE

Those last three are associated with MS KB entries that still can be found if you dig around, though the downloads are gone.

Anyway, I expect Chuanbing will add something to the root install folder for future easy access.

• J

I think the message needs to be:

Minimum install requirements:

• VFP 9 SP 2 (Version 5812 or later)
• HotFix 3

The links are there but when I looked I think the version was not (not that that would have helped most likely unless there were specific notes to check the SP2 Version explicitly). If I see SP2 as a requirement I think any version would work. In fact - I know I have SP2 installed so I think - Ok I'm good on that.

Unless this is very explicit people will likely make the same mistake and just speed read past the SP2 installand end up with the wrong version.

Just to make sure I double checked what a search brings up for SP2 and it's the same link provided on the VFPA site and that version is in fact different than the one I had. Yet the date for that thing is 2007! Yikes.

+++ Rick ---

Hi,

FWIW, a global, one-step update package is available here (In French, albeit Google Translate should cope): http://www.vfp.fr/myvfpuptodate.asp

Hi Rick,

Just to confirm that Chuanbing has uploaded a new VFPA installer that includes readmefirst!.txt instructions in the root install folder. Content below.

This sort of responsiveness is one of the reasons I'm confident in use of these products. - J

                 ----------------------------------------------------
                       VFP ADVANCED 32-BIT VERSION README FIRST
                                January 2021
                 ----------------------------------------------------
                                    CCB



VFP9 is a licensed Microsoft product. VFPA offers enhancements, bug fixes and interoperability improvements for VFP9.

You cannot install VFPA unless you have VFP9 installed. In addition, you need the latest SP2 version because VFPA patches are for that specific version.

The files that VFPA checks for/patches are:

     File name                                                              Version     Date        Size       Description
     ----------------------------------------------------------------------------------------------------------------------------------------------
     C:\Program Files (x86)\Microsoft Visual Foxpro 9\Vfp9.exe              9.0.0.7423  2009-4-3    5,783,552  VFP9 IDE
     C:\Program Files (x86)\Microsoft Visual Foxpro 9\Vfp9enu.dll           9.0.0.5815  2007-10-15  1,507,328  VFP9 IDE language resource file
     C:\Program Files (x86)\Common Files\Microsoft Shared\VFP\Vfp9r.dll     9.0.0.7423  2009-4-3    4,734,976  VFP9 Runtime
     C:\Program Files (x86)\Common Files\Microsoft Shared\VFP\Vfp9t.dll     9.0.0.7423  2009-4-3    3,907,584  VFP9 Multi-threaded Runtime
     C:\Program Files (x86)\Common Files\Microsoft Shared\VFP\Vfp9renu.dll  9.0.0.5815  2007-10-15  1,187,840  VFP9 Runtime language resource file

Installation cannot proceed unless these VFP9 versions are present.

The easiest way to get the correct versions is:

Browse to http://baiyujia.com/f_download.asp
Download and install VFP 9.0 SP2 [9.0.0.5815 VERSION] ( http://baiyujia.com/f_downloadproc_vfp9sp2.asp )
Download and install VFP 9.0 SP2 Hotfix3 [9.0.0.7423 VERSION] ( http://baiyujia.com/f_downloadproc_vfp9sp2hotfix3.asp )

If you have a working VFP9 install, applying these service packs overcomes almost every reported issue with VFPA installation.

For more information, please refer to the file vfpa\readme.txt.

Any questions or suggestions, please send me an email at ccb2000@163.com.

I think if you have to look at a Readme.txt it's often too late especially if the Web site also has instructions. Better to have that on the Web site just below the download links. If install is tricky that should be pointed out along the lines of - hey, pay attention here, don't just robo-install like we do with most software.

Just a thought.

I know from personal experience that most (including myself unless something doesn't work first) don't RTFM or anything beyond the Install button.

+++ Rick ---

Many thanks to both of you for this thread... I had trouble installing VFPA too and simply gave up so this exploration and summary is perfect.

I think it's clear that the versions of the existing hotfix files should be checked by the VFPA installer to avoid frustration by others.

most (…) don't RTFM or anything beyond the Install button.

+1

Rick/Thierry,

I passed on your concerns wrt RTFM: VFPA installer now displays readmefirst!.txt if wrong versions are present.

Also, VFP C++ Compiler demo had been causing ructions with people struggling to install a C++ compilation environment; VFP C++ Compiler now comes with distributable VC6 and VC7 make runtimes. This means you can install and immediately try out compilation of a VFP app, though if you want a contemporary VC++ version you still need to get it installed.

I have WW apps with hundred/s of form scripts compiled and working with VFP C++ Compiler fwiw. - J

Just to be sure, are you John Ryan?
If so, why do you use this strange pseudo while you use your real name on other forums?

Hi Thierry,

This ID dates back over 10 years, to comparisons of VFP's Remote Views vs NET Typed Datasets and Stored Procedures. Fancying myself as a practitioner of the Royal Society's "Nullius in verba" (Take nobody's word for it) this ID confirmed contrarian stance. Who would have expected that. 😉 All these years later if it still annoys, I will figure out how to change it...

Starting in about 2010 I've been using and recommending Chuanbing's work. Probably I need to offer a VFP C++ Compiler SWFox deep dive session showing how to build AES and/or compression into your app (no additional external libraries needed, C++ built into the same dll as your app) as well as doing away with the VFP runtimes...