# GNUstep Base

$Revision: 39998 $
$Date: 2016-07-15 13:30:07 +0200 (Fri, 15 Jul 2016) $
2005 Free Software Foundation, Inc.
Base

The GNUstep Base library is a free software package implementing the API of the OpenStep Foundation Kit (tm), including later additions. This documentation package describes the core of the Base library, for documentation on additional classes, see the BaseAdditions documentation package.

Read the Release Notes for the current release.

Compatibility

GNUstep is generally compatible with the OpenStep specification and with recent developments of the MacOS (cocoa) API. Where MacOS deviates from the OpenStep API, GNUstep generally attempts to support both versions. In some cases the newer MacOS APIs are incompatible with OpenStep, and GNUstep usually supports the richer version. See the OpenStep Compliance section for more information on OpenStep Compliance.

In order to deal with compatibility issues, GNUstep uses two mechanisms - it provides conditionally compiled sections of the library header files, so that software can be built that will conform strictly to a particular API, and it provides user default settings to control the behavior of the library at runtime.

Conditional compilation

Adding an option to a makefile to define one of the following preprocessor constants will modify the API visible to software being compiled -

GS_GNUSTEP_V
Specifies the software version of the header being included.
Features in that header which are declared as having been introduced at or before the specified version, and not being removed until or after the specified version are available.
The version consists of five or six digits ... a major number (0-99) followed by a minor number (00-99) and a subminor number (00-99).
Features in the header file are marked as belonging to different version ranges using the GS_API_VERSION macro.
NB. This is the native versioning of the library being used via the header file. You can use this mechanism in your own libraries and frameworks.
GS_OPENSTEP_V
Used only for the software version in sequence of OpenStep specification and the NeXT/Apple implementation of that specification and its extensions.
Features in the header being included which are declared as having been introduced at or before the specified version, and not being removed until or after the specified version are available.
The version consists of five or six digits ... a major number (1-99) followed by a minor number (00-99) and a subminor number (00-99).
A major number of 1 indicates the OpenStep specification ... available as the GS_API_OSSPEC preprocessor constant.
A major number of 4 indicates the OPENSTEP implementation ... available as the GS_API_OPENSTEP preprocessor constant.
A major number of 10 indicates the MacOS-X implementation ... available as the GS_API_MACOSX preprocessor constant.
Features in the header file are marked as belonging to different version ranges using the GS_API_VERSION macro.
For MacOS-X compatibility, if this constant is not defined and MAC_OS_X_VERSION_MAX_ALLOWED is defined, then GS_OPENSTEP_V is defined to be MAC_OS_X_VERSION_MAX_ALLOWED.
Similarly, for MacOS-X we define MAC_OS_X_VERSION_10_2, MAC_OS_X_VERSION_10_3 etc as the appropriate numeric version numbers.

NB These preprocessor constants are used in developer code (ie the code that users of GNUstep write) rather than by the GNUstep software itself. They permit a developer to ensure that he/she does not write code which depends upon API not present on other implementations (in practice, MacOS-X or some old OPENSTEP systems).
The actual GNUstep libraries are always built with the full GNUstep API in place, so that the feature set is as consistent as possible.

The presence of these macros is also used by autogsdoc to generate information about which version of the API a particular feature belongs to.

User defaults
GNU-Debug

An array of strings that lists debug levels to be used within the program. These debug levels are merged with any which were set on the command line or added programmatically to the set given by the [NSProcessInfo-debugSet] method.

GSLogSyslog

Setting the user default `GSLogSyslog` to `YES` will cause log/debug output to be sent to the syslog facility (on systems which support it), rather than to the standard error stream. This is useful in environments where stderr has been re-used strangely for some reason.
On mswindows, where syslog does not exist, this flag instead controls whether log/debug output is sent to the windows event log.

GSLogOffset

Setting the user default `GSLogOffset` to `YES` will cause NSLog and debug output to include the current time zone offset in the timestamp of the logged message.
This is useful when comparing logs from machines in different countries.

GSLogThread

Setting the user default `GSLogThread` to `YES` will cause NSLog and debug output to include the current thread name in the logged message.
This may be useful for debugging multi-threaded applications.

GSMacOSXCompatible

Setting the user default `GSMacOSXCompatible` to `YES` will cause MacOS compatible behavior to be the default at runtime. This default may however be overridden to provide more fine grained control of system behavior.

GSOldStyleGeometry

Specifies whether the functions for producing strings describing geometric structures (NSStringFromPoint(), NSStringFromSize(), and NSStringFromRect()) should produce strings conforming to the OpenStep specification or to MacOS-X behavior. The functions for parsing those strings should cope with both cases anyway.

GSSOCKS

May be used to specify a default SOCKS5 server (and optionally a port separated from the server by a colon) to which tcp/ip connections made using the NSFileHandle extension methods should be directed.
This default overrides the SOCKS5_SERVER and SOCKS_SERVER environment variables.

GSSortAlgorithm

May be used to specify the sort algorithm used for sorting arrays etc. The current options are QuickSort, ShellSort, and TimSort, with TimSort being the default.
NB. The QuickSort and ShellSort are 'unstable' algorithms, which means that the order of equal objects may be changed by a sort. Selecting these may break code which assumes that sorting is stable.

Local Time Zone

Used to specify the name of the timezone to be used by the NSTimeZone class.

NSWriteOldStylePropertyLists

Specifies whether text property-list output should be in the default MacOS-X format (XML), or in the more human readable (but less powerful) original OpenStep format.

Reading of property lists is supported in either format, but only if GNUstep is built with the libxml library (which is needed to handle XML parsing).

NB. MacOS-X generates illegal XML for some strings - those which contain characters not legal in XML. GNUstep always generates legal XML, at the cost of a certain degree of compatibility. GNUstep XML property lists use a backslash to escape illegal characters, and consequently any string containing either a backslash or an illegal character will be written differently to the same string on MacOS-X.

NSLanguages

An array of strings that lists the users preferred languages, in order or preference. If not found the default is just English.

Environment variables

There are some environment variables used by GNUstep base, where there would be problems obtaining data from the defaults system.

CRASH_ON_ABORT

The default exception handler will either cause the program to simply terminate, or to crash - leaving a core dump. The standard behavior is to leave a core dump if the library was built for debugging, and to simply exit if it was not.

The CRASH_ON_ABORT environment variable can be used to override this behavior. If this is defined to NO, FALSE, or 0 then the program will simply exit when an exception occurs. Any other value of the variable will cause the program to generate a core dump.

CRASH_ON_ZOMBIE

When the a message is sent to a zombie object (see the `NSZombieEnabled` environment variable) the base library allows you to specify whether the program should continue after logging the message, or have the program abort.
By default, the program will attempt to continue.

The `CRASH_ON_ZOMBIE` variable can be used to override this behavior. If this is defined to YES, TRUE, or 1 then the program will log the message sent to the zombie and then abort, producing a core dump on systems where that is possible.

GNUSTEP_SHOULD_CLEAN_UP

When this is set to YES, the GNUstep extension method +setShouldCleanUp: is called when the NSObject class is initialised, this turns on recording of some intentionally leaked memory (data structures intended to persist for the whole life of the process), and activates cleanup of that memory on process exit so that external tools such as valgrind will not report the memory as possibly lost.

Use of this facility is a work in progress ... many classes do not yet clean up after themselves when this is enabled.

GNUSTEP_STACK_TRACE

When this is set to YES a human readable stack trace (with function names and line numbers) is added to the output of the description method of a raised exception object.
This only works if gnustep was built with support for it using libbfd, so it may not be available on all systems.

When this is set to NO the raw stack trace provided by [NSException-callStackReturnAddresses] is disabled.
The possible reasons for disabling this are:
1. that the feature is implemented using a function of the gcc compiler to provide stack addresses, and the function is buggy on some systems/compiler versions, and will cause a signal to be sent which would crash your program if not caught. The GNUstep code catches the signal and recovers using a signal handler, but there have been two reports of this not working with no known cause.
2. that you have code which uses exceptions in a way in which they were not designed to be used ... so that they are routinely and frequently called rather than being called only occasionally when exceptional conditions occur. In this case you may want to disable the stack frame generation implicit in each raised exception, in order to improve performance.

When this is not set, or is set to a non-boolean value, the stack trace handling on exceptions is MacOS-X compatible ... stack return addresses are available but a human readable trace back is not logged.

GNUSTEP_STRING_ENCODING

This is used to specify the default encoding for 8-bit strings (those used by 'cstring' methods of NSString).
It may be any of the 8-bit encodings supported by your system.

If this environment variable is not set, GNUstep attempts to use the characterset specified by your operating systems, locale information (using the standard nl_langinfo function) if possible.

If there is no usable operating system defined characterset, GNUstep defaults to NSISOLatin1StringEncoding.

GNUSTEP_HOST_CPU

Used in place of GNUSTEP_TARGET_CPU if the other is missing. Please do not use this to locate resources; for architecture dependent resources use GNUSTEP_TARGET_DIR.

GNUSTEP_HOST_DIR

Used in place of GNUSTEP_TARGET_DIR if the other is missing.

GNUSTEP_HOST_OS

Used in place of GNUSTEP_TARGET_OS if the other is missing. Please do not use this to locate resources; for architecture dependent resources use GNUSTEP_TARGET_DIR.

GNUSTEP_TARGET_CPU

Overrides the default value of the machine (hardware) name used on this system. Please do not use this to locate resources; for architecture dependent resources use GNUSTEP_TARGET_DIR.

GNUSTEP_TARGET_DIR

Overrides the default path used to locate subdirectories for GNUstep binaries within bundles and applications. This is normally equivalent to a path made up of the GNUSTEP_TARGET_CPU and GNUSTEP_TARGET_OS

GNUSTEP_TARGET_OS

Overrides the default value of the operating system name used on this system. Please do not use this to locate resources; for architecture dependent resources use GNUSTEP_TARGET_DIR.

GNUSTEP_TZ

Used to specify the timezone to be used if there is no timezone specified in the user defaults system. The preferred mechanism is to use the 'Local Time Zone' value from the user defaults system.

GNUSTEP_CONFIG_FILE

This functionality may have been disabled if the base library was configured/built with the `--disable-environment-config-file` option.
If it is operational (ie unless you've deliberately disabled it), the environment variable overrides the normal path to the gnustep config file used to determine the locations of paths for the gnustep system (see later).
This is provided to support situations such as when you install into a sandbox during packaging, or where you may want to simultaneously run applications using different sets of resources but linked to a single copy of the base library, or you want to use an alternative config file for some reason.

GNUSTEP_BEHAVIOR_DEBUG
A boolean (YES or NO) which can be used to turn on debug logging (to stderr) of the GSObjCRuntime functions to add/override methods in a class using a list of methods from another class.
HOMEDRIVE

Used on ms-windows to locate the home directory if the HOMEPATH environment variable is also used.

HOMEPATH

Used on ms-windows to locate the home directoryb in conjunction with HOMEDRIVE. If this is just a backslash then the USERPROFILE variable is used if possible.

LANGUAGES

If there is no NSLanguages user default set, and there is no language information available in the native system locale mechanism, then this environment variable is used to provide a list of the languages that the user prefers to use. languages listed in this variable must be separated by semicolons.

LOGNAME

This is used as the default value for the current user (as returned by the NSUserName() functions). If it is not specified, or contains an illegal value, other methods are used to get the user name.

LIBRARY_COMBO

Used to override the default value of the combination of standard libraries used to build binaries. This value locates the final subdirectory used to locate binaries.

NSDeallocateZombies

This may be used in conjunction with NSZombieEnabled to specify whether the objects should really be deallocated. If you set this to YES, the zombie logging will only work until the deallocated memory is re-used.

NSZombieEnabled

If this is set to YES, then deallocation of an object causes the object to be morphed into a Zombie ... a special object which will call the GNUstep specific GSLogZombie() function to log the method call.
If GNUstep-base was built for debugging (make debug=yes), you can set a breakpoint in this function and examine the process memory when you are running under a debugger.
As this overrides actual object deallocation, all memory allocated for objects will be leaked unless the NSDeallocateZombies environment variable is also set.
You can use the `CRASH_ON_ZOMBIE` environment variable to force an abort after the message is logged.

SOCKS5_SERVER

Specifies the default socks server to be used when making outgoing tcp/ip connections using NSFileHandle. This may also specify a port after the host name (and separated from it by a colon).
This environment variable is used only if the GSSOCKS user default is not set.

SOCKS_SERVER

Equivalent to SOCKS5_SERVER, but used only if that is not defined.

TZ

Used to specify the timezone to be used if there is no timezone specified by any other mechanism. The preferred mechanism is to use the 'Local Time Zone' value from the user defaults system.

USERPROFILE

Used on windows to identify the home directory of the current used (unless HOMEPATH and HOMEDRIVE are set to point to an individual user's home).

GNUstep Configuration File

This file is the master configuration file for GNUstep. It can be used to set the base location of all the standard paths that GNUstep programs use or know about. The location of this file depends on how the Base library was configured and/or what operating system it was configured on. On a GNU/Linux system, the default would be /etc/GNUstep/GNUstep.conf for instance, while on mswindows it would be ./GNUstep.conf (the leading './' here indicates that the file is located relative to the base library, on windows this is the location of the base library DLL, which is normally the same location as command line tools).

If setting up GNUstep in a sandbox for packaging it as part of an operating system distribution, you may well want a special configuration for use within the sandbox. The normal way to do that would be to create a GNUstep.conf file in /tmp and set the GNUSTEP_CONFIG_FILE environment variable to point to that while doing the packaging setup.

NB. The gnustep-make package sets up a configuration file to be used when building GNUstep software, and gnustep-base normally uses that same file, but it is important to be aware that the two configuration files are not necessarily the same since one is required to provide environment variables used while building and installing software, but the other is used when gnustep tools and applications are run (ie in a target/deployment environment).
In particular it is normal for the two files to differ on mswindows (where the build environment is an UNIX-like MSYS shell, using the its own paths, but the deployment environment is native-windows using real windows paths).

The location of the GNUstep configuration file can be specified when the base library is configured, using the `--with-config-file=` option of the `configure` script.
This configuration file is not actually required to exist, and if it does not exist, then default values will be used for the standard path locations (these default values may be specified using the `--with-default-config=` option of the `configure` script.
If you want to force the internal defaults to be used, you can use `--with-config-file=` to specify a path with a trailing '/' (ie with no filename) as the base library will refrain from trying to load configuration from a file of no name.
System paths are defined by the following:

GNUSTEP_SYSTEM_APPS
This is where System GUI Applications get installed.
Traditionally it is /usr/GNUstep/System/Applications.
GNUSTEP_SYSTEM_ADMIN_APPS
This is where System GUI Applications that only the Administrator can use get installed.
Traditionally it is /usr/GNUstep/System/Applications/Admin.
GNUSTEP_SYSTEM_WEB_APPS
This is where System Web Applications (GSWeb, SOPE) get installed.
Traditionally it is /usr/GNUstep/System/Library/WebApplications.
GNUSTEP_SYSTEM_TOOLS
This is where System Command-Line Tools get installed.
Traditionally it is /usr/GNUstep/System/Tools.
GNUSTEP_SYSTEM_ADMIN_TOOLS
This is where System Command-Line Tools that only the Administrator can use get installed. Important: this should not be in the PATH of normal users.
Traditionally it is /usr/GNUstep/System/Tools/Admin.
GNUSTEP_SYSTEM_LIBRARY
This is where System resources get installed. This directory will contain a lot of executable code since *step traditionally likes to bundle executables and resources together.
Traditionally it is /usr/GNUstep/System/Library.
GNUSTEP_SYSTEM_HEADERS
This is where System headers get installed. They are the library .h headers.
Traditionally it is /usr/GNUstep/System/Library/Headers.
GNUSTEP_SYSTEM_LIBRARIES
This is where System libraries get installed. By libraries we mean the shared/static object files that you can link into programs.
Traditionally it is /usr/GNUstep/System/Library/Libraries.
GNUSTEP_SYSTEM_DOC
This is where System documentation get installed. This is known not to contain any executable, so we keep it separate.
Traditionally it is /usr/GNUstep/System/Library/Documentation.
GNUSTEP_SYSTEM_DOC_MAN
This is where System man pages get installed.
Traditionally it is /usr/GNUstep/System/Library/Documentation/man.
GNUSTEP_SYSTEM_DOC_INFO
This is where System info pages get installed.
Traditionally it is /usr/GNUstep/System/Library/Documentation/info.

In addition to the above SYSTEM domain paths, there are corresponding LOCAL, NETWORK, and USER domain paths (with the same names except for replacing 'SYSTEM' with 'LOCAL', 'NETWORK', or 'USER'.
All these paths must be absolute, except for the USER domain paths which, if not absolute, are considered to be with the user's home directory.
NB. as a special case a path may begin with './' or '../' when it is to be resolved to an absolute path relative to the location of the GNUstep configuration file. So while such paths appear to be relative, they actually produce absolute locations at runtime since the location of the configuration file is known.
Finally, for paths in the USER domain only, a limited substitution into the path is performed at runtime as follows:
'%u' is replaced by the user name
'%i' is replaced by the user ID
'%%' is replaced by a single '%'

The GNUSTEP_DEVELOPER_DIR path may be used to specify where the development system is located. On most systems this should be the default value of '/', but on windows it should be the location of the msys/mingw filesystem (so that msys development tools can be found).

Other paths for each user are defined by the following:

GNUSTEP_USER_CONFIG_FILE
Name of user configuration file (eg. '.GNUstep.conf') relative to the user's home directory.
Can be specified as an empty string to ensure that no user specific config file is loaded.
GNUSTEP_USER_DEFAULTS_DIR
Name of directory for user defaults files. Always relative to the user's home directory except:
On mswindows this may be set to be ':REGISTRY:' to have defaults stored in the windows registry rather than in the standard file format.
On any system this may be set to ':INTERNAL:' to use only internal defaults domains (NSArgumentDomain, NSRegistrationDomain, and GSConfigDomain).

The user's home directory is taken to be the standard home directory for that user on the system
On unix, that is the user's home directory from the password file, while on windows it's the value given by the HOMEDRIVE and HOMEPATH environment variables (or the USERPROFILE environment variable if the others can't be used).

NB. The presence of a path in the configuration (and therefore its inclusion in the paths provided by the API at runtime) does not guarantee that the directory at that path actually exists in the local filesystem.
However the GNUSTEP_CREATE_LIBRARY_PATH configuration value may be set to YES to tell the library to create the most commonly used per-user directory (GNUSTEP_USER_LIBRARY) on startup if it does not already exist.

All the above values from the configuration file are made available in the NSUserDefaults system at runtime, in the GSConfigDomain (along with any defaults provided in property lists in the GlobalDefaults subdirectory or in the GlobalDefaults.plist file in the same directory as the config file).
The `.plist` files in the GlobalDefaults subdirectory are merged into the defaults system in an unpredictable order, but the values from the GlobalDefaults.plist are merged in after the other values and will take precedence.
The global defaults files allow packagers and system administrators to provide defaults settings for all users of a particular GNUstep installation.
It is recommended that each software package provides its own defaults in the GlobalDefaults subdirectory, while the GlobalDefaults.plist file should be reserved for other system-wide settings.

The exact format of the configuration file is expected to be that of a basic unix "conf" style file, with one key = value per line (the format a unix shell can 'source' in order to define shell variables).
This configuration file uses the escape sequence and quoting conventions of the standard bourne shell.
The only Keys permitted are those listed above, and all consist of uppercase letters, digits, and underscores, and must not begin with a digit.
A value may be any quoted string (or an unquoted string containing no white space).
Lines beginning with a hash '#' are deemed comment lines and ignored.
The backslash character may be used as an escape character anywhere in the file except within a singly quoted string (where it is taken literally).
A backslash followed immediately by a newline (except in a singly quoted string) is removed completely along with the newline ... it thus serves to join lines so that they are treated as a single line.
NB. Since ms-windows uses backslash characters in paths, it is a good idea to specify path values in the config file as singly quoted strings to avoid having to double all occurrences of the backslash.

Relocatable packages

The configuration files system has two features which make it possible to build standalone packages containing the entire GNUstep system in a form which can be moved anywhere and just run.

Firstly, variables in the configuration file which define paths, are expected to by full path specifications, except for the special case in which they begin with dot-slash (./) or dot-dot-slash (../).
In this case the path from the variable is appended to the path of the directory containing the configuration file (or the path specified to contain the configuration file if no configuration file exists) to form the value used.
So, if you configure other paths relative to the configuration file, you can relocate everything when you move the configuration file.

Secondly, If the value of the path built in to the base library as the location of the config file (or specified by the GNUSTEP_CONFIG_FILE environment variable unless that option was disabled when the base library was configured) begins with a dot-slash (./) or dot-dot-slash (../) then the path used for that file is made relative to the base library.
The base library contains code to determine its own location, so this allows it to locate the configuration file, and by reading the configuration file it determines where all other resources are located.

So you can bundle the whole lot together in one directory, and configure various relative paths in that directory, then move the directory around wherever you like.
However, if your operating system needs to know where to find the libraries it will load, you will have to tell it where they are ... typically you do this by setting an environment variable such as LD_LIBRARY_PATH to contain the full path to the directory you put the libraries in.

Standalone packages

While the recommended setup for GNUstep is to install the core packages in a standard location on your system, and then install applications which make use of those core libraries, it is sometimes desirable to have standalone applications which don't need the core to be installed.
This is a special case of the relocatable packages described above, in which all your application's dependencies are built as relocatable packages using a filesystem layout which lets them all be stored within your application directory.

As an aide to easy creation of such standalone packages we provide two template gnustep configuration files for a common setup where things are stored in a 'standalone' subdirectory of your application wrapper.
You configure/install gnustep-make with the 'standalone' filesystem layout, then you configure/build/install gnustep-base with the 'standalone.conf' default configuration file, and build/install the other libraries/packages your app depends upon.
This leaves you with a 'standalone' directory containing all the relocatable code, which you can then copy into your app wrapper to provide a complete standalone system.

To set up the relocatable standalone resources: cd make ./configure --with-layout=standalone make install . ~/standalone/Makefile/GNUstep.sh cd ../base ./configure --with-config-file=./GNUstep.conf --with-default-config=standalone.conf make install cd ../gui make install cd ../back make install To copy them to your application and run it using them: (cd ~; tar -cf - standalone) | (cd MyApp.app; tar -xpf -) export LD_LIBRARY_PATH=`pwd`/MyApp.app/standalone MyApp.app/MyApp
Lock-Down

If you wish to lock down a production system for distribution so that users can't change the config file and mess up paths, you can specify the config file name as a path with a trailing slash so that the base library will not read it, and will use the built in default values.
To do this, you would configure using options like `--disable-environment-config-file` with `--with-config-file=/not-used/` and `--with-default-config=myConfig` where myConfig is a file containing the paths you want to use in the locked down system.
The paths from that file will be built in to the base library as defaults, and library will use them rather than attempting to read a config file at runtime.
You can lock down a relocatable system by using this procedure with './' as the config file path and relative paths in myConfig... a user could then move the entire package around, but would not be able to edit a configuration file to alter the paths within the package.

.GNUstep.conf files

The user specific configuration file is read after the system configuration file and may generally override values from the main file. To prevent the use specific file from being read, the system manager may define GNUSTEP_USER_CONFIG_FILE in the main file to be an empty string.
In any case, the user specific file is not read if a program is running setuid.

Unless disabled (as specified above) the presence of a `.GNUstep.conf` file in a users home directory permits the user to customize file locations using all the same commands as the system directory, though any attempt to redefine GNUSTEP_USER_CONFIG_FILE is of course ignored.
Attempts to redefine the users home directory at this level are also ignored.

The defaults database for a user is stored in the location given by GNUSTEP_USER_DEFAULTS_DIR in the config file. This is usually a relative path (default, the `GNUstep/Defaults` subdirectory) taken to specify a subdirectory of the user's home directory.
On mswindows this may be set to be ':REGISTRY:' to have defaults stored in the windows registry rather than in the standard file format.
On any system this may be set to ':INTERNAL:' to use only internal defaults domains (NSArgumentDomain, NSRegistrationDomain, and GSConfigDomain).

API Documentation
Functions
Types and Constants