STDLIB provides a POSIX-like abstraction of file descriptors which unifies the different types of resource and permits a single API to be used across all of them. This is a significantly different approach from Win32 and the Symbian platform, both of which have separate APIs for each distinct type of resource.
STDLIB supports files stored in the file system, sockets, a console, and
a /dev/null device. The first time STDLIB initialises its
internal file descriptor table it creates an emulated console device and attaches
it to descriptors 0, 1 and 2. The emulated console device will appear as a
window when it is first used (i.e. when the program writes to or reads from
the console).
The open() function recognises the following names:
CON: is
taken to mean a newly-created console. This will never be the same console
as the one automatically associated with 0, 1 and 2.
NUL: is
taken to mean a /dev/null device.
TMP: is
taken to mean a temporary file, which will use the underlying Symbian platform
file system facilities to create a uniquely-named temporary file, and will
cause the file to be deleted after it has been closed cleanly.
COMx: is
the serial port where x is a number from 1 to 9. COM1: corresponds
to serial port zero and so on.
IRCOMx: is
the serial port where x is a number from 1 to 9.
The number of open files in the file has no explicit limit.
The Symbian platform resources such as RFile and RSocket are
derived from class RSubSessionBase, so are thread specific.
This means they cannot be used by any thread other than the one which opened
them. In STDLIB however, the CPosixServer, if running, controls
the master file descriptor table. In this case, all STDLIB threads in a process
may share their resources, because the STDLIB implementation forwards all
I/o requests to the resources owned by that process's CPosixServer thread.
If no CPosixServer is running, each thread has a separate
file descriptor table and the resources are not shareable.