Basically, the moniker "VFPA" is three things: a) the regular 32Bit VFP9 enginge, patched with 30+ bugfixes b) same as a), but with a 64bit engine c) a true 64bit compiler, which doesn't need the runtime etc
BTW, the "A" in VFPA is the next HEX sign after 9, or a 10 in Dec. But it also fits with the "Advanced" tag :) VFPA is already around since several years, and Mr.Chen seems to be very knowledgable with Assembler and debugging C++ machinecode :) Personally I use the regular 32bit version without any problems at my customers site. It behaves just as a usual VFP9 without some quirks. I was bitten by those report-engine bugs as well as the Grid-Optimize problem, and with VFPA this stuff just works. You just do a "recompile all" on your project, put your EXE and that single VFPAR.DLL to your customer and that's all. One caveat: VFPA hast he language-Resource-DLL included, thus you need different VFPAR.dll for different langauges. (Personally I don't like that approach, since you can't run in a multi-language scenario anymore, where VFP picks the language DLL according to the user settings) Also I'm not really convinced about the need for the 64bit version. At least not for existing desktop applications. As soon as you have some FLLs or OCXs included, you're basically toasted, since you need those as a 64bit version. Since most of the VFP specific addons are already 15 years old, the chances to get those vendors to compile their old stuff into a 64bit version are somewhat desillusional. Then: what do you gain from a 64bit version? You don't get over the 2Gb limit for DBFs, it's just that it can address more RAM. Ok, when did you ran out of RAM with a VFP version, where the engine was built to work even on PCs with as little as 64MB RAM? You also have a marketing plus, because you're now a native 64bit app. And it may run a little bit faster because of the unneeded 32Bit layer in Windows. As long as you don't need any of your old addons.... But it does have a valid usecase for Middle-tier applications, like ActiveFoxProPages or AFPX or FIC, where the VFP engine connects directly to 64bit WebServers. BTW: @ChristofWollenhaupt: did you already compiled the AFP engine with VFPA? The third option, a true compiler, is stil work in progress. It does work, but stil has the same restrictions as option b). Mr.Chen is working to enhance the limitations at various parts like max. Stringlength, max DBF size etc, but there are a lot of complications. woOdy _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/00b501d35243$ccd194d0$6674be70$@wondzinski.de ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
