Share via

VFP9R.DLL Run-Time Library

  • Article

The Visual FoxPro run-time library VFP9R.dll is the main run-time library used by most Visual FoxPro applications and provides services for the following Visual FoxPro application types:

  • Distributed application (.exe) files

  • Out-of-process Automation server (.exe) files

  • In-process Automation server (.dll) files

This run-time library is located in the ..\Program Files\Common Files\Microsoft Shared\VFP directory.

The main Visual FoxPro run-time library is not shared by all the multiple in-process Automation servers (.dll). Instead, each in-process Automation server uses a separate instance of the main Visual FoxPro run-time library. The following rules determine how in-process Automation servers use the main Visual FoxPro run-time library:

  • The in-process .dll file that is called first has exclusive use of the main Visual FoxPro run-time library.

    If an in-process .dll file already has exclusive use of the main Visual FoxPro run-time library, a renamed copy of the main Visual FoxPro run-time library is created on disk and loaded into memory for each in-process .dll called. The main Visual FoxPro run-time library is assigned a name based on the name of the in-process .dll.

    For example, suppose you call an in-process .dll named MyServer.dll. A copy of the Visual FoxPro run-time library is renamed to MyServerR.dll and is loaded into memory to service the in-process .dll. This can also occur with a Visual FoxPro .exe server creating an instance of a .dll server, a situation where both share the same run-time library from the same process.

  • Visual FoxPro run-time libraries are renamed only for in-process .dlls that run within the same process.

    This means that two separate clients, each running in their own process, can load two different Visual FoxPro in-process .dll files without the run time being renamed. In this case, both Visual FoxPro in-process .dll files use the main Visual FoxPro run-time library because the clients load in separate processes.

  • Multiple Automation servers, created with OLEPUBLIC clause in the DEFINE CLASS command, in a single in-process .dll share the same main Visual FoxPro run-time library.

    In this case, it's possible that the Automation servers can affect each other by sharing PUBLIC memory variables, setting the same SET commands, and so on if they reside on a common thread. Be careful that multiple Automation servers in a single in-process .dll don't interfere with each other. The new Session class can help eliminate some of these conflicts. Using the Visual FoxPro multithreaded run-time library, VFP9T.dll, avoids these conflicts because objects created on separate threads will use their own separate memory space (thread-local storage).

You can use the main Visual FoxPro run-time library with in-process .dll servers. Because there are limitations in using the main Visual FoxPro run-time library, you should consider using the multithreaded Visual FoxPro run-time library, VFPVersionNumberT.dll instead. The main Visual FoxPro run-time library does not fully protect instance data and global values; therefore the library blocks multiple objects from executing code concurrently. If one of the objects is executing code, all other instances must queue up to execute code. When the object executing code finishes, another object can enter the run time to begin its execution, whether it is a property assignment or method invocation. While this might not be ideal in many application scenarios, there are certain types of server applications where this may be the optimal approach.

If in-process .dll servers are deployed in a Component Services (or Microsoft Transaction Server) package, creating an instance of the server will load the .dll into the memory space of a Component Services process rather than the calling process. Moreover, multiple-process .exe files can instantiate Visual FoxPro .dll servers that will be loaded into a single Component Services process. Component Services generates or reuses a thread for each client requesting an instance (OLEPUBLIC) from a Visual FoxPro server. Since such applications often require enterprise scalability, there is the potential for many concurrent instances to access your Visual FoxPro server simultaneously. If only one client (instance) is allowed to execute code at a time, all others must wait. With a single processor machine, this may be fine, depending on the nature and execution times of methods in your server. Remember, a single processor can only run one line of code at a time.

Tip

You should always consider using the multithreaded Visual FoxPro runtime library for multiple processor machines since each processor can simultaneously execute code for different objects. Since the main Visual FoxPro run-time library blocking behavior prevents simultaneous code execution, you should use the multithreaded Visual FoxPro run-time library for most situations.

See Also

Reference

Visual FoxPro Run-Time Libraries
Scalability and Multithreading

Other Resources

Interoperability and the Internet
Server Design Considerations and Limitations