Deploying applications

PC Repair Tools

Advanced Registry Cleaner PC Diagnosis and Repair

Get Instant Access

Once your application is up and running, you can deploy it. That is, you can make it available for others to run. A number of steps must be taken to deploy an application to another computer so that the application is completely functional. The steps required by a given application vary, depending on the type of application. The following sections describe these steps when deploying the following applications:

  • Deploying general applications
  • Deploying CLX applications
  • Deploying database applications
  • Deploying Web applications
  • Programming for varying host environments
  • Software license requirements

Note Information included in these sections is for deploying applications on Windows. To deploy a cross-platform applications on Linux, refer to your Kylix documentation.

Deploying general applications

Beyond the executable file, an application may require a number of supporting files, such as DLLs, package files, and helper applications. In addition, the Windows registry may need to contain entries for an application, from specifying the location of supporting files to simple program settings. The process of copying an application's files to a computer and making any needed registry settings can be automated by an installation program, such as InstallShield Express. Nearly all types of applications include the following issues:

  • Using installation programs
  • Identifying application files
  • Helper applications
  • DLL locations

Database and Web applications require additional installation steps. For additional information on installing database applications, see "Deploying database applications" on page 18-6. For more information on installing Web applications, see "Deploying Web applications" on page 18-9. For more information on installing ActiveX controls, see "Deploying an ActiveX control on the Web" on page 45-15.

Using installation programs

Simple applications that consist of only an executable file are easy to install on a target computer. Just copy the executable file onto the computer. However, more complex applications that comprise multiple files require more extensive installation procedures. These applications require dedicated installation programs.

Setup toolkits automate the process of creating installation programs, often without needing to write any code. Installation programs created with Setup toolkits perform various tasks inherent to installing Delphi applications, including: copying the executable and supporting files to the host computer, making Windows registry entries, and installing the Borland Database Engine for BDE database applications.

InstallShield Express is a setup toolkit that is bundled with Delphi. InstallShield Express is certified for use with Delphi and the Borland Database Engine. It is based on Windows Installer (MSI) technology.

InstallShield Express is not automatically installed when Delphi is installed, so it must be manually installed if you want to use it to create installation programs. Run the installation program from the Delphi CD to install InstallShield Express. For more information on using InstallShield Express to create installation programs, see the InstallShield Express online help.

Other setup toolkits are available. However, if deploying BDE database applications, you should only use toolkits based on MSI technology and those which are certified to deploy the Borland Database Engine.

Identifying application files

Besides the executable file, a number of other files may need to be distributed with an application.

  • Application files
  • Package files
  • Merge modules
  • ActiveX controls

Application files

The following types of files may need to be distributed with an application. Table 18.1 Application files


File name extension

  • exe and .dll .bpl and .dcp
  • hlp, .cnt, and .toc (if used) or any other Help files your application supports .ocx (sometimes supported by a DLL)

Program files Package files Help files

ActiveX files

Local table files .dbf, .mdx, .dbt, .ndx, .db, .px, .y*, .x*, .mb, .val, .qbe, .gd*

Package files

If the application uses runtime packages, those package files need to be distributed with the application. InstallShield Express handles the installation of package files the same as DLLs, copying the files and making necessary entries in the Windows registry. You can also use merge modules for deploying runtime packages with MSI-based setup tools including InstallShield Express. See the next section for details.

Borland recommends installing the runtime package files supplied by Borland in the Windows\System directory. This serves as a common location so that multiple applications would have access to a single instance of the files. For packages you created, it is recommended that you install them in the same directory as the application. Only the .bpl files need to be distributed.

Note If deploying packages with CLX applications, you need to include clx70.bpl rather than vcl70.bpl.

If you are distributing packages to other developers, supply the .bpl and .dcp files.

Merge modules

InstallShield Express 3.0 is based on Windows Installer (MSI) technology. With MSI-based setup tools such as InstallShield Express, you can use merge modules for deploying runtime packages. Merge modules provide a standard method that you can use to deliver shared code, files, resources, Registry entries, and setup logic to applications as a single compound file.

The runtime libraries have some interdependencies because of the way they are grouped together. The result of this is that when one package is added to an install project, the install tool automatically adds or reports a dependency on one or more other packages. For example, if you add the VCLInternet merge module to an install project, the install tool should also automatically add or report a dependency on the VCLDatabase and StandardVCL modules.

The dependencies for each merge module are listed in the table below. The various install tools may react to these dependencies differently. The InstallShield for Windows Installer automatically adds the required modules if it can find them. Other tools may simply report a dependency or may generate a build failure if all required modules are not included in the project.

Table 18.2 Merge modules and their dependencies

Merge module

BPLs included




DatabaseRTL, BaseRTL



DatabaseRTL, BaseRTL, DataSnap,




No dependencies


vcl70.bpl, vclx70.bpl




BaseClientDataSet, DataBaseRTL, BaseRTL,

DataSnap, dbExpress, BDERTL



Internet, DatabaseRTL, BaseRTL, BDERTL



DatabaseRTL, BaseRTL






BaseVCL, DatabaseRTL, BaseRTL



DatabaseRTL, BaseRTL



DataSnap, DatabaseRTL, BaseRTL



DataSnapConnection, DataSnap,

DatabaseRTL, BaseRTL, BaseVCL



DataSnap, DatabaseRTL, BaseRTL,




DatabaseVCL, BaseVCL, BaseRTL,




DatabaseRTL, BaseRTL



BaseClientDataSet, DataBaseRTL, BaseRTL,

DataSnap, dbExpress



Internet, DatabaseRTL, BaseRTL,

dbExpress, DatabaseVCL, BaseVCL



TeeChart, BaseVCL, BaseRTL,

DatabaseVCL, DatabaseRTL, BDERTL



BaseClientDataSet, BaseRTL, BaseVCL,

DatabaseRTL, DatabaseVCL, DataSnap,



inet70.bpl, inetdb70.bpl

DatabaseRTL, BaseRTL



BaseVCL, BaseRTL



DatabaseVCL, BaseVCL, DatabaseRTL,




DatabaseVCL, BaseVCL, DatabaseRTL,




BaseVCL, BaseRTL, BDERTL, DatabaseRTL



BaseVCL, BaseRTL

Deploying general applications Table 18.2 Merge modules and their dependencies (continued)

Merge module


BPLs included soaprtl70.bpl


BaseRTL, XMLRTL, DatabaseRTL, DataSnap, Internet

BaseVCL, BaseRTL

TeeChart tee70.bpl, teedb70.bpl, teeqr70.bpl, teeui70.bpl vclactnband70.bpl vclie70.bpl visualclx70.bpl visualdbclx70.bpl webdsnap70.bpl






BaseVCL, BaseRTL BaseVCL, BaseRTL BaseRTL

BaseRTL, DatabaseRTL, VisualCLX XMLRTL, Internet, DataSnapConnection,



websnap71.bpl, vcljpg70.bpl xmlrtl70.bpl

DataSnap, DatabaseRTL, BaseRTL

WebDataSnap, XMLRTL, Internet, DataSnapConnection, DataSnap, DatabaseRTL, BaseRTL, BaseVCL

Internet, DatabaseRTL, BaseRTL

ActiveX controls

Certain components bundled with Delphi are ActiveX controls. The component wrapper is linked into the application's executable file (or a runtime package), but the .ocx file for the component also needs to be deployed with the application. These components include:

  • Chart FX, copyright SoftwareFX Inc.
  • VisualSpeller Control, copyright Visual Components, Inc.
  • Formula One (spreadsheet), copyright Visual Components, Inc.
  • First Impression (VtChart), copyright Visual Components, Inc.
  • Graph Custom Control, copyright Bits Per Second Ltd.

ActiveX controls that you create need to be registered on the deployment computer before use. Installation programs such as InstallShield Express automate this registration process. To manually register an ActiveX control, choose Run I ActiveX Server in the IDE, use the TRegSvr demo application in \Demos\ActiveX or use the Microsoft utility REGSRV32.EXE (not included with Windows 9x versions).

DLLs that support an ActiveX control also need to be distributed with an application.

Helper applications

Helper applications are separate programs without which your application would be partially or completely unable to function. Helper applications may be those supplied with the operating system, by Borland, or by third-party products. An example of a helper application is the InterBase utility program Server Manager, which administers InterBase databases, users, and security.

If an application depends on a helper program, be sure to deploy it with your application, where possible. Distribution of helper programs may be governed by redistribution license agreements. Consult the helper program documentation for specific information.

DLL locations

You can install DLL files used only by a single application in the same directory as the application. DLLs that will be used by a number of applications should be installed in a location accessible to all of those applications. A common convention for locating such community DLLs is to place them either in the Windows or the Windows\System directory. A better way is to create a dedicated directory for the common .DLL files, similar to the way the Borland Database Engine is installed.

Deploying CLX applications

If you are writing cross-platform applications that will be deployed on both Windows and Linux, you need to compile and deploy the applications on both platforms. To deploy a CLX application on Windows, follow the same steps as those for general applications. You need to include qtintf.dll with the application to include the runtime library. To deploy packages with CLX applications, you need to include clx70.bpl rather than vcl70.bpl.

See Chapter 15, "Developing cross-platform applications" for information on writing CLX applications.

Deploying database applications

Applications that access databases involve special installation considerations beyond copying the application's executable file onto the host computer. Database access is most often handled by a separate database engine, the files of which cannot be linked into the application's executable file. The data files, when not created beforehand, must be made available to the application. Multi-tier database applications require additional handling on installation, because the files that make up the application are typically located on multiple computers.

Since several different database technologies (ADO, BDE, dbExpress, and InterBase Express) are supported, deployment requirements differ for each. Regardless of which you are using, you need to make sure that the client-side software is installed on the system where you plan to run the database application. ADO, BDE, dbExpress, and InterBase Express also require drivers to interact with the client-side software of the database.

Specific information on how to deploy dbExpress, BDE, and multi-tiered database applications is described in the following sections:

  • Deploying dbExpress database applications.
  • Deploying BDE applications.
  • Deploying multi-tiered database applications (DataSnap).

Database applications that use client datasets such as TClientDataSet or dataset providers require you to include midaslib.dcu and crtl.dcu (for static linking when providing a stand-alone executable); if you are packaging your application (with the executable and any needed DLLs), you need to include Midas.dll.

If deploying database applications that use ADO, you need to be sure that MDAC version 2.1 or later is installed on the system where you plan to run the application. MDAC is automatically installed with software such as Windows 2000 and Internet Explorer version 5 or later. You also need to be sure the drivers for the database server you want to connect to are installed on the client. No other deployment steps are required.

If deploying database applications that use InterBase Express, you need to be sure that the InterBase client is installed on the system where you plan to run the application. InterBase requires gd32.dll and interbase.msg to be located in an accessible directory. No other deployment steps are required. InterBase Express components communicate directly with the InterBase Client API and do not require additional drivers. For more information, refer to the Embedded Installation Guide posted on the Borland Web site.

In addition to the technologies described here, you can also use third-party database engines to provide database access. Consult the documentation or vendor for the database engine regarding redistribution rights, installation, and configuration.

Deploying dbExpress database applications dbExpress is a set of thin, native drivers that provide fast access to database information. dbExpress support cross-platform development because they are also available on Linux.

You can deploy dbExpress applications either as a stand-alone executable file or as an executable file that includes associated dbExpress driver DLLs.

To deploy dbExpress applications as stand-alone executable files, the dbExpress object files must be statically linked into your executable. You do this by including the following DCUs, located in the lib directory:

Table 18.3 dbExpress deployment as stand-alone executable

Database unit When to include dbExpINT Applications connecting to InterBase databases dbExpORA Applications connecting to Oracle databases dbExpDB2 Applications connecting to DB2 databases dbExpMYS Applications connecting to MySQL 3.22.x databases dbExpMYSQL Applications connecting to MySQL 3.23.x databases crtl Required by all executables that use dbExpress

MidasLib Required by dbExpress executables that use client datasets such as TClientDataSet

Note For database applications using Informix or MSSQL, you cannot deploy a standalone executable. Instead, deploy an executable file with the driver DLL (listed in the table following).

If you are not deploying a stand-alone executable, you can deploy associated dbExpress drivers and DataSnap DLLs with your executable. The following table lists the appropriate DLLs and when to include them:

Table 18.4 dbExpress deployment with driver DLLs

Database DLL When to deploy dbexpinf.dll Applications connecting to Informix databases dbexpint.dll Applications connecting to InterBase databases dbexpora.dll Applications connecting to Oracle databases dbexpdb2.dll. Applications connecting to DB2 databases dbexpmss.dll Applications connecting to MSSQL databases dbexpmys.dll Applications connecting to MySQL 3.22.xdatabases dbexpmysql.dll Applications connecting to MySQL 3.23.x databases

Midas.dll Required by database applications that use client datasets

See Chapter 28, "Using unidirectional datasets" for more information about using the dbExpress components.

Deploying BDE applications

The Borland Database Engine (BDE) defines a large API for interacting with databases. Of all the data access mechanisms, the BDE supports the broadest range of functions and comes with the most supporting utilities. It is the best way to work with data in Paradox or dBASE tables.

Database access for an application is provided by various database engines. An application can use the BDE or a third-party database engine. The following section describes installation of the database access elements of an application.

Borland Database Engine

You can use the Borland Database Engine (BDE) to provide database access for standard Delphi data components. See the BDEDEPLOY document for specific rights and limitations on redistributing the BDE.

You should use InstallShield Express (or other certified installation program) for installing the BDE. InstallShield Express creates the necessary registry entries and defines any aliases the application may require. Using a certified installation program to deploy the BDE files and subsets is important because:

  • Improper installation of the BDE or BDE subsets can cause other applications using the BDE to fail. Such applications include not only Borland products, but many third-party programs that use the BDE.
  • Under 32-bit Windows 95/NT and later, BDE configuration information is stored in the Windows registry instead of .ini files, as was the case under 16-bit Windows. Making the correct entries and deletions for install and uninstall is a complex task.

It is possible to install only as much of the BDE as an application actually needs. For instance, if an application only uses Paradox tables, it is only necessary to install that portion of the BDE required to access Paradox tables. This reduces the disk space needed for an application. Certified installation programs, like InstallShield Express, are capable of performing partial BDE installations. Be sure to leave BDE system files that are not used by the deployed application, but that are needed by other programs.

Deploying multi-tiered database applications (DataSnap)

DataSnap provides multi-tier database capability to Delphi applications by allowing client applications to connect to providers in an application server.

Install DataSnap along with a multi-tier application using InstallShield Express (or other Borland-certified installation scripting utility). See the DEPLOY document (found in the main Delphi directory) for details on the files that need to be redistributed with an application. Also see the REMOTE document for related information on what DataSnap files can be redistributed and how.

Deploying Web applications

Some Delphi applications are designed to be run over the World Wide Web, such as those in the form of Server-side Extension DLLs (ISAPI and Apache), CGI applications, and ActiveForms.

The steps for deploying Web applications are the same as those for general applications, except the application's files are deployed on the Web server.

Here are some special considerations for deploying Web applications:

  • For BDE database applications, the Borland Database Engine (or alternate database engine) is installed with the application files on the Web server.
  • For dbExpress applications, the dbExpress DLLs must be included in the path. If included, the dbExpress driver is installed with the application files on the Web server.
  • Security for the directories should be set so that the application can access all needed database files.
  • The directory containing an application must have read and execute attributes.
  • The application should not use hard-coded paths for accessing database or other files.
  • The location of an ActiveX control is indicated by the CODEBASE parameter of the <OBJECT> HTML tag.

For information on deploying database Web applications, see "Deploying database applications" on page 18-6.

Deploying on Apache servers

WebBroker supports Apache version 1.3.9 and later for DLLs and CGI applications.

Modules and applications are enabled and configured by modifying Apache's httpd.conf file (normally located in your Apache installation's \conf directory).

Enabling modules

Your DLLs should be physically located in the Apache Modules subdirectory. Two modifications to httpd.conf are required to enable a module.

1 Add a LoadModule entry to let Apache locate and load your DLL. For example:

LoadModule MyApache_module modules/Projectl.dll

Replace MyApache_module with the exported module name from your DLL. To find the module name, in your project source, look for the exports line. For example:

exports apache_module name 'MyApache_module';

2 Add a resource locator entry (may be added anywhere in httpd.conf after the LoadModule entry). For example:

# Sample location specification for a project named projectl. <Location /project1>

SetHandler projectl-handler </Location>

This allows all requests to to be passed on to the Apache module.

The SetHandler directive specifies the Web server application that handles the request. The SetHandler argument should be set to the value of the ContentType global variable.

CGI applications

When creating CGI applications, the physical directory (specified in the Directory directive of the httpd.conf file) must have the ExecCGI option and the SetHandler clause set to allow execution of programs so the CGI script can be executed. To ensure that permissions are set up properly, use the Alias directive with both Options ExecCGI and SetHandler enabled.

Note An alternative approach is to use the ScriptAlias directive (without Options

ExecCGI), but using this approach can prevent your CGI application from reading any files in the ScriptAlias directory.

The following httpd.conf line is an example of using the Alias directive to create a virtual directory on your server and mark the exact location of your CGI script:


This would allow requests such as /MyWeb/mycgi.exe to be satisfied by running the script c:\httpd\docs\MyWeb\mycgi.exe.

You can also set Options to All or to ExecCGI using the Directory directive in httpd.conf. The Options directive controls which server features are available in a particular directory.

Directory directives are used to enclose a set of directives that apply to the named directory and its subdirectories. An example of the Directory directive is shown below:

<Directory "c:/httpd/docs/MyWeb"> AllowOverride None Options ExecCGI Order allow,deny Allow from all

AddHandler cgi-script exe cgi </Directory>

In this example, Options is set to ExecCGI permitting execution of CGI scripts in the directory MyWeb. The AddHandler clause lets Apache know that files with extensions such as exe and cgi are CGI scripts (executables).

Note Apache executes locally on the server within the account specified in the User directive in the httpd.conf file. Make sure that the user has the appropriate rights to access the resources needed by the application.

See the Apache LICENSE file, included with your Apache distribution, for additional deployment information. For additional Apache configuration information, see

Programming for varying host environments

Programming for varying host environments

Due to the nature of various operating system environments, there are a number of factors that vary with user preference or configuration. The following factors can affect an application deployed to another computer:

  • Screen resolutions and color depths
  • Fonts
  • Operating system versions
  • Helper applications
  • DLL locations

Screen resolutions and color depths

The size of the desktop and number of available colors on a computer is configurable and dependent on the hardware installed. These attributes are also likely to differ on the deployment computer compared to those on the development computer.

An application's appearance (window, object, and font sizes) on computers configured for different screen resolutions can be handled in various ways:

  • Design the application for the lowest resolution users will have (typically, 640x480). Take no special actions to dynamically resize objects to make them proportional to the host computer's screen display. Visually, objects will appear smaller the higher the resolution is set.
  • Design using any screen resolution on the development computer and, at runtime, dynamically resize all forms and objects proportional to the difference between the screen resolutions for the development and deployment computers (a screen resolution difference ratio).
  • Design using any screen resolution on the development computer and, at runtime, dynamically resize only the application's forms. Depending on the location of visual controls on the forms, this may require the forms be scrollable for the user to be able to access all controls on the forms.

Considerations when not dynamically resizing

If the forms and visual controls that make up an application are not dynamically resized at runtime, design the application's elements for the lowest resolution. Otherwise, the forms of an application run on a computer configured for a lower screen resolution than the development computer may overlap the boundaries of the screen.

For example, if the development computer is set up for a screen resolution of 1024x768 and a form is designed with a width of 700 pixels, not all of that form will be visible within the desktop on a computer configured for a 640x480 screen resolution.

Considerations when dynamically resizing forms and controls

If the forms and visual controls for an application are dynamically resized, accommodate all aspects of the resizing process to ensure optimal appearance of the application under all possible screen resolutions. Here are some factors to consider when dynamically resizing the visual elements of an application:

  • The resizing of forms and visual controls is done at a ratio calculated by comparing the screen resolution of the development computer to that of the computer onto which the application installed. Use a constant to represent one dimension of the screen resolution on the development computer: either the height or the width, in pixels. Retrieve the same dimension for the user's computer at runtime using the TScreen.Height or the TScreen.Width property. Divide the value for the development computer by the value for the user's computer to derive the difference ratio between the two computers' screen resolutions.
  • Resize the visual elements of the application (forms and controls) by reducing or increasing the size of the elements and their positions on forms. This resizing is proportional to the difference between the screen resolutions on the development and user computers. Resize and reposition visual controls on forms automatically by setting the CustomForm.Scaled property to True and calling the TWinControl.ScaleBy method (TWidgetControl.ScaleBy for cross-platform applications). The ScaleBy method does not change the form's height and width, though. Do this manually by multiplying the current values for the Height and Width properties by the screen resolution difference ratio.
  • The controls on a form can be resized manually, instead of automatically with the TWinControl.ScaleBy method (TWidgetControl.ScaleBy for cross-platform applications), by referencing each visual control in a loop and setting its dimensions and position. The Height and Width property values for visual controls are multiplied by the screen resolution difference ratio. Reposition visual controls proportional to screen resolution differences by multiplying the Top and Left property values by the same ratio.
  • If an application is designed on a computer configured for a higher screen resolution than that on the user's computer, font sizes will be reduced in the process of proportionally resizing visual controls. If the size of the font at design time is too small, the font as resized at runtime may be unreadable. For example, the default font size for a form is 8. If the development computer has a screen resolution of 1024x768 and the user's computer 640x480, visual control dimensions will be reduced by a factor of 0.625 (640 / 1024 = 0.625). The original font size of 8 is reduced to 5 (8 * 0.625 = 5). Text in the application appears jagged and unreadable as it is displayed in the reduced font size.
  • Some visual controls, such as TLabel and TEdit, dynamically resize when the size of the font for the control changes. This can affect deployed applications when forms and controls are dynamically resized. The resizing of the control due to font size changes are in addition to size changes due to proportional resizing for screen resolutions. This effect is offset by setting the AutoSize property of these controls to False.
  • Avoid making use of explicit pixel coordinates, such as when drawing directly to a canvas. Instead, modify the coordinates by a ratio proportionate to the screen resolution difference ratio between the development and user computers. For example, if the application draws a rectangle to a canvas ten pixels high by twenty wide, instead multiply the ten and twenty by the screen resolution difference ratio. This ensures that the rectangle visually appears the same size under different screen resolutions.

Accommodating varying color depths

To account for all deployment computers not being configured with the same color availability, the safest way is to use graphics with the least possible number of colors. This is especially true for control glyphs, which should typically use 16-color graphics. For displaying pictures, either provide multiple copies of the images in different resolutions and color depths or explain in the application the minimum resolution and color requirements for the application.


Windows comes with a standard set of TrueType and raster fonts. Linux comes with a standard set of fonts, depending on the distribution. When designing an application to be deployed on other computers, realize that not all computers have fonts outside the standard sets.

Text components used in the application should all use fonts that are likely to be available on all deployment computers.

When use of a nonstandard font is absolutely necessary in an application, you need to distribute that font with the application. Either the installation program or the application itself must install the font on the deployment computer. Distribution of third-party fonts may be subject to limitations imposed by the font creator.

Windows has a safety measure to account for attempts to use a font that does not exist on the computer. It substitutes another, existing font that it considers the closest match. While this may circumvent errors concerning missing fonts, the end result may be a degradation of the visual appearance of the application. It is better to prepare for this eventuality at design time.

To make a nonstandard font available to a Windows application, use the Windows API functions AddFontResource and DeleteFontResource. Deploy the .fot file for the nonstandard font with the application.

Operating systems versions

When using operating system APIs or accessing areas of the operating system from an application, there is the possibility that the function, operation, or area may not be available on computers with different operating system versions.

To account for this possibility, you have a few options:

  • Specify in the application's system requirements the versions of the operating system on which the application can run. It is the user's responsibility to install and use the application only under compatible operating system versions.
  • Check the version of the operating system as the application is installed. If an incompatible version of the operating system is present, either halt the installation process or at least warn the installer of the problem.
  • Check the operating system version at runtime, just prior to executing an operation not applicable to all versions. If an incompatible version of the operating system is present, abort the process and alert the user. Alternately, provide different code to run dependent on different operating system versions.

Note Some operations are performed differently on Windows 95/98 than on Windows NT/2000/XP. Use the Windows API function GetVersionEx to determine the Windows version.

Software license requirements

The distribution of some files associated with Delphi applications is subject to limitations or cannot be redistributed at all. The following documents describe the legal stipulations regarding the distribution of these files:


The DEPLOY document covers the some of the legal aspects of distributing of various components and utilities, and other product areas that can be part of or associated with a Delphi application. The DEPLOY document is installed in the main Delphi directory. The topics covered include:

  • exe, .dll, and .bpl files
  • Components and design-time packages
  • Borland Database Engine (BDE)
  • ActiveX controls
  • Sample images


The README document contains last minute information about Delphi, possibly including information that could affect the redistribution rights for components, or utilities, or other product areas. The README document is installed in the main Delphi directory.

No-nonsense license agreement

The Delphi no-nonsense license agreement, a printed document, covers other legal rights and obligations concerning Delphi.

Third-party product documentation

Redistribution rights for third-party components, utilities, helper applications, database engines, and other products are governed by the vendor supplying the product. Consult the documentation for the product or the vendor for information regarding the redistribution of the product with Delphi applications prior to distribution.

Was this article helpful?

+1 0


  • beatrice
    How to install applications executable using "installshield express"?
    9 years ago
  • Cotman
    How to deploy application of delphi?
    2 years ago

Post a comment