If you ship an application to a site where other applications are already installed, your application might conflict with the existing ones if your application uses a different version of the run-time system from the existing ones. For example, your application uses version 4 of the run-time system and the existing applications use version 3. Normally, you would need to ship the version 4 run-time system. You would also need to set the paths on your user's system so that each application used its own version of the run-time system: the version 4 application used the version 4 run-time system and the version 3 application used the version 3 run-time system.
Similarly, if you create a system that can be used by two applications, one multi-threaded and one single-threaded, you would normally have to create two dynamic link libraries, one linked to the multi-threaded run-time system, one to the single-threaded run-time system.
To solve these problems, you can dynamically bind a run-time system to your programs. Dynamic run-time system binding enables you to:
Dynamic run-time system binding is enabled using a glue library, called cblrtsg.lib. When you choose to dynamically bind an application, your system executable is linked to the glue library rather than directly to a run-time system. If your executable is a .dll file, it can then run in a process that has loaded the single-threaded or multi-threaded run-time system. If your executable is an .exe file, it dynamically binds to either the required version of the run-time system, or the system default run-time system. As long as the system to which you are shipping your system executable file already has a run-time system installed, you need to ship only the executable file. How your system executable interacts with the installed run-time system depends on how you linked your program to the glue library.
You can create a dynamically bound executable in the Link page of the Build Settings, or by using the Cbllink utility.