Similarities to Paradox

How similar is VFP to Paradox? can they inter relate,I believe PDX can open VFP tables?

Just to add some more clarity to this thread. Paradox and VFP are pretty different animals. Yes, both can access the same data sources using common techniques like ODBC, but the features directly in common end there.

VFP "is" like Paradox in that it serves primarily as a desktop database with features like table management, form and report creation, query capabilities, etc. However, VFP is truely object oriented and creates true native EXE applications that do not require a runtime.

I hope that helps!

Hi Fred,
I thought you told me that you only need to distribute a few DLLs? In my world, if you can distribute an EXE that you created and that EXE does not require another EXE to be running, then it is true executable.

Here is a bit more from my world. What I'm talking about is that both Access and Paradox require a striped down version of the product running first, then you load up your form or script. If I understand VFP correctly, it simply needs a few DLLs and the EXE just like VB 1-6 did.

Yes, technically it's still a runtime system, but for that matter so is every DotNet application because it requires the DotNet framework.

I guess you could even say that every Win-32 C++ app is also a runtime app too because it requires the Win-32 API. So, what I'm talking about is whether you create an EXE and how many EXE's you need to load in order for your app to run. For Paradox, you need to first load either the full version or the runtime version of Paradox, then open a form or script. No developer-created EXE even exists. MS Access is similar.

To me, VFP is a better solution and as good as Delphi and Visual Studio.Net. Yes, I prefer Delphi and Visual Studio.Net over VFP, but that's another thread.

Thanks Fred,
Yep PDX has a OBDC driver.

Originally posted by Paul Castelow: How similar is VFP to Paradox? can they inter relate,I believe PDX can open VFP tables?

I do not know enough about Paradox to answer that question. VFP is much like VB (with lots of data management goodies)if thats any help. If there is an ODBC or ADO/OLEDB driver available for Paradox then VFP can read its data. VFP does provide these drivers for other apps to access its data.

Fred Stevens

Actually compiled VFP .EXEs do need runtime library support.
FS

Aloha Mike,
I would like to think that we inhabit the same world, although I am not always sure . I was responding to your statement "[VFP] creates true native EXE applications that do not require a runtime."

All versions of VFP are capable of producing a compiled .EXE file that will directly execute on Windows-based PCs. However, without a group of files collectively labelled "VFP runtime support" available, an error message is immediately generated: "cannot locate VFP support files" and the program terminates.

Each release of VFP requires a different set of runtime files to be available. Up until recently (ie version 8) these included a small executable file (a loader?) called VFPnRUN.EXE where n was the version number, eg: VFP7RUN.EXE. Apparently some standard header code in the compiled user app called this loader to invoke the large support library contained in the other runtime files (DLLs). Since VFP8 this EXE file is no longer part of the runtime files and the compiled app seems to be able to access the runtime library DLLs directly. Besides this minor change, very little is different from the deployment requirements for a compiled VFP app.

While the previously required runtime EXE file was small, the associated DLL support libraries were/are sizable. To illustrate, here are the runtime files and their sizes needed to support a compiled VFP8 .EXE of any size:
VFP8r.DLL (4.2 MB)
VFP8RENU.DLL (1.124 MB)

In my world, when a 100K (or smaller) compiled executable file requires over 5 MB of external support files to run, it can be said to require runtime support and is not a true "native" EXE, unlike small executables produced in the C++ environment.

Interestingly, there are two other "runtime support" files which are required to run a VFP executable which may or may not be already available on the host machine. These include components previously included in earlier Windows installations as part of the Win-32 API:
GDIPLUS.DLL (1.6 MB)
MSVCR70.DLL (336 KB

The GDIPLUS DLL is an enhanced interface to the console and printer and is part of Windows, replacing an earlier version GDI.DLL

MSCVR70.DLL is a runtime component of Visual C++ and if not installed on a system (as with installing Visual Studio .NET) will prevent execution of compiled VFP7 and VFP8 apps. VFP9 runtime support requires the next release of this C++ library: MSVCR71.DLL.

The VFP documentation refers to the "runtime environment" of redistributable files to be included in compiled applications deployed to machines not having the development environment already installed. To me, if it looks like a runtime, acts like a runtime, is called a runtime by its makers, it probably is a runtime. While VFP is very powerful and useful and produces true executable files (.EXEs) unlike Paradox and Access, these require significant runtime support in order to function. In the real world, this is not usually a big problem since the files are readily available and can either be installed via a standard InstallShield installation process along with the app or simply included in the same subdir as the compiled app itself.

Interestingly, much earlier DOS versions of FoxPro allowed either small EXEs to be compiled and distributed along with the runtime files or a single big fat EXE which included the app AND the entire runtime support in a single file. This latter executable would run completely stand-alone.

While I take your point that in truth, both C++ and .NET apps use a similar runtime environment ultimately, the significant difference is that in most cases, this does not require additional (large) files to be distributed and installed along with the app, as the runtime environment is already part of the Windows infrastructure. In situations where a DotNet app installation does require the DotNet framework to be installed first, the situations are indeed quite similar.