System unit structure

│ English (en) │ español (es) │ français (fr) │

(work in progress - incomplete!)

This page is supposed to document functions and procedures serving as "interfaces" between common and platform specific parts of unit System as well as commonly used subroutines for particular tasks performed during unit System initialization and specify their behaviour. This should then serve as specification for maintainers of existing and new platforms to ensure fully compatible behaviour (as far as possible considering limitations of the individual platforms).

Usually, all listed routines are mandatory (at least as stub) unless specifically mentioned otherwise - see section Features below for exceptions. If name of the usual source file containing implemenation of the particular routine is not mentioned, it's supposed to be system.pas for platform specific parts and system.inc for the shared routines.

Source file structure

Similarly to other parts of FPC RTL (and also units included in packages), the general pattern is that units requiring at least some platform / target specific parts have the main source file (system.pas in case of unit System) in the specific subdirectory specific for the particular target, but this file refers an include file containing the common interface (systemh.inc) and another include file containing implementation of platform independent stuff (system.inc) - obviously, we try to share as much as possible rather than duplicating the same code on several places. The parts shared for all targets (like the two include files mentioned above) are stored in /rtl/inc.

In the particular case of unit System (and partly also some other more complex units), there are quite a few more include files involved, though. In addition to parts which are shared among all targets, there are also parts which may be shared for all targets on a particular CPU / platform stored in a subdirectory named after the CPU / platform (e.g. in /rtl/i386/, /rtl/x86_64/, /rtl/aarch64/, /rtl/jvm/, etc.). Moreover, there may be parts which are shared by several targets having certain similar aspects - e.g. various BSD based targets have shared parts in /rtl/bsd/, all *NIX targets have shared parts in /rtl/unix/ and various MS Windows targets may use shared parts in /rtl/win/.

Finally, the complexity of the System unit led to the situation that the common implementation part expects certain parts of the target-specific implementation in specifically named include files which need to be made available in the subdirectory for the particular target, or possibly in a subdirectory shared among several targets as mentioned above. As an example, target specific implementation of file handling needs to be provided in file sysfile.inc.

You might wonder how the compiler knows where to find the different include files - this is handled in the Makefile (generated from Makefile.fpc rules using our fpcmake tool - see /utils/fpcm/).

Features

Certain targets are not capable to provide certain functionality due to their limited nature (typically certain embedded systems, etc.). In order to provide this level of flexibility without sacrificing the aim of sharing as much code as possible, there are conditional defines set for individual targets specifying features available for that targets. The list of features enabled for all targets by default is specified at the beginning of systemh.inc. Targets which need to limit the set of supported features need to include {$DEFINE FPC_HAS_FEATURE_SUPPORT} at the beginning of their System unit (before {$I systemh.inc}). As of time of writing this, the following features are included in the default (full) set using conditional defines:

• {$define FPC_HAS_FEATURE_HEAP} - dynamic memory management using heap
• {$define FPC_HAS_FEATURE_INITFINAL} - initialization and finalization
• {$define FPC_HAS_FEATURE_RTTI} - Runt-Time Type Information
• {$define FPC_HAS_FEATURE_CLASSES} - classes
• {$define FPC_HAS_FEATURE_EXCEPTIONS} - exceptions
• {$define FPC_HAS_FEATURE_EXITCODE} - returning of exit code when finishing the program
• {$define FPC_HAS_FEATURE_ANSISTRINGS} - AnsiString type (variable length strings)
• {$define FPC_HAS_FEATURE_WIDESTRINGS} - WideString type
• {$define FPC_HAS_FEATURE_TEXTIO} - text file input/output
• {$define FPC_HAS_FEATURE_CONSOLEIO} - input/output using console
• {$define FPC_HAS_FEATURE_FILEIO} - general file input/output
• {$define FPC_HAS_FEATURE_RANDOM} - random number generator
• {$define FPC_HAS_FEATURE_VARIANTS} - variants
• {$define FPC_HAS_FEATURE_OBJECTS} - objects
• {$define FPC_HAS_FEATURE_DYNARRAYS} - dynamic arrays
• {$define FPC_HAS_FEATURE_THREADING} - multithreading (note that this just specifies that the RTL structures for multithreading support are included; it doesn't necessarily mean, that the target must allow creating multiple threads (e.g. MS-DOS based targets don't allow that at the moment due to missing support from the operating system, although it might be technically possible to provide implementation at the RTL or user code level)
• {$define FPC_HAS_FEATURE_COMMANDARGS} - command-line arguments
• {$define FPC_HAS_FEATURE_PROCESSES} - running of other processes
• {$define FPC_HAS_FEATURE_STACKCHECK} - stack checking
• {$define FPC_HAS_FEATURE_DYNLIBS} - dynamic libraries
• {$define FPC_HAS_FEATURE_OBJECTIVEC1} - ObjectiveC classes
• {$define FPC_HAS_FEATURE_UNICODESTRINGS} - UnicodeString type

Types

The following types are assumed to be defined in platform specific part of System unit interface.

• THandle
• TThreadID
• TRTLCriticalSection
• PRTLCriticalSection

Constants and variables

The following list includes mandatory constants and variables that have to be declared (and usually initialized to reasonable values for the particular platform) for all platforms:

• LineEnding
• DirectorySeparator
• DriveSeparator
• PathSeparator
• MaxExitCode
• MaxPathLen
• UnusedHandle
• StdInputHandle
• StdOutputHandle
• StdErrorHandle
• LFNSupport
• FileNameCaseSensitive
• CtrlZMarksEof
• sLineBreak
• DefaultTextLineBreakStyle
• ArgC
• ArgV
• EnvC
• EnvP

<TODO>

Initialization

Shared

InitHeap

Implemented in heap.inc.

Initialization of internal structures used by the default heap memory manager. No heap may be used before calling InitHeap.

SysInitExceptions

Initialization of internal structures used by the exception support.

<TODO>

OpenStdIO

Common part of initialization for standard file variables. It's similar to Assign and Reset/Rewrite calls for normal text files, but the files are associated with empty file names and no attempt is made to open the files (they're assumed to be already open).

<TODO>

InitSystemThreads

<TODO>

SetThreadManager

<TODO>

InitHeapMutexes

<TODO>

InitVariantManager

<TODO>

InitWideStringManager

<TODO>

Sysinit unit and indirect entry information

(note: This is currently at very initial stage and applies only to i386-win32 target)

Supporting runtime packages requires possibility to link the system unit and the main program into different executable modules. Therefore, global information generated by compiler, such as unit initialization table, cannot be directly referenced from the system unit. Instead, it is referenced from a separate small unit ('sysinit') and passed to routines in system unit via function arguments. The module entry point is placed in sysinit unit, too. A copy of sysinit unit is statically linked into every executable module, so every module ends up containing the initialization table only for the units it actually contains.

This global information is not limited to unit initialization table, see TEntryInformation record for complete list.

A target may have more than one sysinit unit, each solving specific initialization tasks. A particular unit to use is determined by compiler, see InitSysInitUnitName method in descendants of TLinker class. For example, while normally using sysinitpas.pp, complier will use sysinitcyg.pp instead if it detects linking with cygwin libraries.

Platform specific

unit initialization

The following tasks are performed:

• IsLibrary variable initialization (true if running in a shared library, false otherwise)
• ProcessID and ThreadID variables initialization
• IsConsole variable initialization (true if running in a text console, false if running in windowed GUI application)
• ExitProc variable initialization <TODO>
• Heap initialization (calling shared InitHeap)
• Initialization of potential procedural variables and/or parameters needed to support System unit routines requiring different implementation depending on detected version of operating system (possibly including dynamic loading of procedures or functions from shared libraries where appropriate) - see OS aware RTL
• InOutRes variable initialization (set to 0)
• Environment variables initialization (EnvC and EnvP), usually by calling InitEnvironment - only needed for platforms not providing access to these variables natively
• Internal thread manager is initialized by calling InitSystemThreads
• Internal variant manager is initialized by calling InitVariantManager
• Internal widestring manager is initialized by calling InitWideStringManager

InitEnvironment

Only needed for platforms not providing access to EnvC and EnvP variables natively.

Procedure checks amount of environment variables and stores it in EnvC. Then memory for EnvP^ is allocated from heap (array of EnvC + 1 items of type PChar - the list pointer will point to nil). Finally the individual items in the array are initialized with PChars pointing to null terminated strings containing the environment variable name, equal sign and the environment variable value. Memory for the individual null terminated strings may be allocated from heap for these strings and they may be copied there if needed (i.e. if the particular platform doesn't provide pointer to a fixed location for these strings in required format).

InitArguments

Only needed for platforms not providing access to ArgC, ArgV and/or CmdLine variables natively.

<TODO>

SysInitStdIO

Initialization of standard file variables (Input, Output, ErrOutput, StdOut and StdErr).

<TODO>

SysSetCtrlBreakHandler

Unlike some other target specific functions, this function is optional (controlled using {$DEFINE FPC_HAS_SETCTRLBREAKHANDLER} before {$I system.inc}). It allows the target to provide its own implementation of a function for setting up own a handler for the Ctrl-Break handler. This may be necessary e.g. if the handler needs to be somehow initialized before it could be used (e.g. by specifically allowing triggering Ctrl-Break event as an exception at the operating system level). The default implementation is the following:

function SysSetCtrlBreakHandler (Handler: TCtrlBreakHandler): TCtrlBreakHandler;
begin
  (* Return either nil or previous handler *)
  SysSetCtrlBreakHandler := CtrlBreakHandler;
  CtrlBreakHandler := Handler;
end;

Setting up CtrlBreakHandler allows specific handling of Ctrl-Break key combination rather than having this combination interpreted at the operating system level (translating it to an attempt to terminate the running program). As an example, this functionality may be used in units Crt and/or Keyboard in package rtl-console (/packages/rtl-console/). TCtrlBreakHandler is defined as follows:

type
  TCtrlBreakHandler = function (CtrlBreak: boolean): boolean;

When CtrlBreakHandler is called, the CtrlBreak parameter set to true signalizes a Ctrl-Break signal, otherwise it means that the call was triggered by Ctrl-C keyboard combination. The handler is supposed to return true if the signal has been processed, false means that default exception handling should be used.

General tasks

Platform specific

File handling

Usually implemented in file sysfile.inc.

Public routines

The following routines are part of System unit interface and are supposed to be implemented fully in platform specific way. Their specification is available in FPC documentation, so they're listed here mostly for completeness sake to provide complete list for porting purposes.

Directory handling

Usually implemented in sysdir.inc.

• MkDir
• RmDir
• ChDir
• GetDir

Other

• Randomize
• ParamCount, ParamStr (possibly to be moved to common - <TODO>)

Finalization

Shared

InternalExit

<TODO>

FinalizeHeap

<TODO>

Platform specific

FinalDeallocation

<TODO>

An editor has declared this article to be a stub, meaning that it needs more information. Can you help out and add some? If you have some useful information, you can help the Free Pascal Wiki by clicking on the edit box on the left and expanding this page.