A graphical user interface (GUI) application is designed using graphical components such as windows, menus, dialog boxes, and other features that make the application easy to use. When you compile a GUI application, an executable file with start-up code is created from your source files. The executable usually provides the basic functionality of your program. Simple programs often consist of only an executable file. You can extend the application by calling DLLs, packages, and other support files from the executable. 

The RAD Studio IDE offers two application UI models:

• Single Document Interface (SDI)
• Multiple Document Interface (MDI)

A SDI application normally contains a single document view.

In an MDI application, more than one document or child window can be opened within a single parent window. This is common in applications such as spreadsheets or word processors. 

MDI applications require more planning and are more complex to design than SDI applications. MDI applications spawn child windows that reside within the client window; the main form contains child forms. For instance, you need to set the FormStyle property of the TForm object to specify whether a form is a child (fsMDIChild) or main form (fsMDIForm). It is a best practice to define a base class for your child forms and derive each child form from this class. Otherwise, you will have to reset the form properties of the child. MDI applications often include a Window pop-up on the main menu that has items such as Cascade and Tile for viewing multiple windows in various styles. When a child window is minimized, its icon is located in the MDI parent form.

Console applications are 32-bit programs that run in a console window without a graphical interface. These applications typically do not require much user input and perform a limited set of functions. Any application that contains {$APPTYPE CONSOLE} in the code opens a console window of its own.

Service applications take requests from client applications, process those requests, and return the information to the client applications. Service applications typically run in the background without much user input. A Web, FTP, or an email server is an example of a service application.

Dynamic link libraries (DLLs) are modules of compiled code that work in conjunction with an executable to provide functionality to an application. You can create DLLs in cross-platform programs.  

Packages are special DLLs used by Delphi applications, the IDE, or both. The two types of packages are runtime and designtime. Runtime packages provide functionality to a program while that program is running. Designtime packages extend the functionality of the IDE. 

For most applications, packages provide greater flexibility and are easier to create than DLLs. However,here are a few situations where DLLs would work better than packages:

• Your code module will be called from non-Delphi applications.
• You are extending the functionality of a Web server.
• You are creating a code module to be used by third-party developers.
• Your project is an OLE container.

You cannot pass Delphi runtime type information (RTTI) across DLLs or from a DLL to an executable. If you pass an object from one DLL to another DLL or to an executable, you will not be able to use the is or as operators with the passed object. This is because the is and as operators need to compare RTTI. If you need to pass objects from a library, use packages instead of DLLs, because packages can share RTTI. Similarly, you should use packages instead of DLLs in Web Services because they rely on Delphi RTTI.

Building a Windows Application 

Building a Windows “Hello World” Console Application 

Building a VCL Forms “Hello World” Application