In many cases, the embedding layer will be transparent to the application developer. It provides a full set of default functions for interaction between Prolog and the host operating system. Frequently all you will need to do is use the extended FLI and let the defaults provided by Quintus Prolog take care of the operating system requirements concerning memory management and I/O. However, Prolog no longer insists on controlling memory management and input/output operations, should this be impossible or undesirable in your application. These default interfaces are fully user redefinable.
Memory management: Quintus Prolog release 3 does not have any restrictions on the underlying memory. This is a crucial aspect of embeddability. Any good Prolog implementation will start up with the minimum amount of memory necessary and expand and shrink depending on the memory needed to execute each goal. In previous releases of Quintus Prolog (as well as most other Prolog implementations) all the memory that Prolog used had to be contiguous. So it was possible that if some foreign component of the application allocated memory from the top, it would disable Prolog from growing any further. With release 3, Quintus Prolog runs on discontiguous memory. Therefore Prolog can share the process's address space with memory allocated to Prolog interspersed with memory allocated by other components of the application.
The user can replace Quintus Prolog's low level memory management functions. This is essential if the user has an application that would like to take care of all memory management and does not want Prolog to directly make system calls to the OS to allocate memory. This makes it easy to link Prolog with other components that have more rigid restrictions about its memory allocation. (Discussed further in fli-emb-how-mem).
Input/Output: The user can create, access and manipulate Prolog I/O streams from foreign code. This provides a unified way of performing I/O from Prolog as well as foreign code. It also gives the user the ability to have I/O streams to sockets, pipes or even windows. Graphical user interfaces have become a natural Prolog component of an application.
The low level I/O functions can also be replaced. This is essential if the user has a large application and wants to take care of all I/O without any direct calls from Prolog to the OS to perform I/O. This is elaborated in fli-emb-how-iou.
Windows caveat: Redefining functions in the Embedding Layer only works in executables built with
-S; see sap-rge-sos.