Runtime library Related

If you use detect as graphdriver, you will end up with the highest supported bitdepth. Since the graph unit currently only supports up to 16 bits per pixel modes and since this bitdepth is supported by virtually all graphics cards, you will most likely get a 16 bit mode.

The main problem is that in 16 (and 15, 24, 32, …) bit modes, the colors are not set anymore using an index in a palette (the palettized way is called “indexed color”). In these modes, the color number itself determines what color you get on screen and you can not change this color. The color is encoded as follows (for most graphics cards on PC’s at least):

• 15 bit color: lower 5 bits are blue intensity, next come 5 bits of green and then 5 bits of red. The highest bit of the word is ignored.
• 16 bit color: lower 5 bits are blue intensity, next come 6 bits of green and then 5 bits of red.

This means that either you have to rewrite your program so it can work with this so-called “direct color” scheme, or that you have to use D8BIT as graphdriver and DetectMode as graphmode. This will ensure that you end up with a 256 (indexed) color mode. If there are no 256 color modes supported, then graphresult will contain the value GrNotDetected after you called InitGraph and you can retry with graphdriver D4BIT.

The standard runtime library file I/O routines open files in the default sharing mode of the operating system (system, objects units). Because of this, you might get problems if the file is opened more than once either by another process or the same process.

Generally the behaviors for the different operating systems are as follows :

There are two ways to solve this problem:

• Use specific operating system calls (such as file locking on UNIX systems) to get the correct behavior.
• Use the sysutils unit or the Free Component Library TFileStream File I/O routines, which try to simulate, as much as possible, file sharing mechanisms.

Trying to open files using reset on non-text files might cause a Runtime Error 5 (Access denied).

All files opened using the above system unit routine use the current filemode value to determine how the file is opened. By default, filemode is set to 2 (Read/Write access).

So, a call to reset on non-text files does not indicate that the file will be opened read-only. So, trying to open a file using reset with the defaults will fail on read-only files. filemode should be set to 0 (Real-only access) before calling reset to solve this problem. A sample solution is shown below.

const
    { possible values for filemode }
    READ_ONLY = 0;
    WRITE_ONLY = 1;
    READ_WRITE = 2;
var
    oldfilemode : byte;
    f: file;
begin
    assign(f,'myfile.txt');
    oldfilemode := filemode;
    { reset will open read-only }
    filemode := READ_ONLY;
    reset(f,1);
    { restore file mode value }
    filemode := oldfilemode;
    // ...
    close(f);
end.

For more information, consult the Free Pascal reference manual.