Requirements

Windows version

The FreeBASIC compiler (fbc.exe) and the executables generated by it, need at least Windows 98 to run.
The msvcrt.dll (the Microsoft's C runtime library) must be present (note: it wasn't shipped with Windows 95, but it's installed by many applications and can be also downloaded at: Microsoft).
The gfx routines will use DirectX 5.0 or later if found on the host system, otherwise they'll fall back on standard Win32 GDI which will work on any Windows system.
Unicode wide strings (WSTRING's) only work in Windows NT/2000/XP/2003/Vista or above. Applications that depend on wide-strings will run in Windows 98/Me, but no input/output will work if the character set isn't Latin-based, because those platforms don't support Unicode strings. Windows 95 has most Unicode API functions missing; applications using wide strings won't even be loaded by this specific OS.

Linux version

The FreeBASIC compiler (fbc) and the executable generated by it depend on libc, libm, libpthread, libdl and libncurses. These are all standard Linux libraries and should be available by default on all modern distros.
When using the gfx routines, the dependencies will increase. FreeBASIC gfx programs will also need libX11, libXext, libXpm, libXrender and libXrandr to be installed on the host system to be executed. This is usually not a problem as long as there's a recent X11 server installed in the system (at least XFree86 4.3.0 or any X.org version).
If having a working X11 installation is enough to run FreeBASIC gfx programs, it may be not enough to compile them; you may need to install the X11 development libraries from your Linux packages repository.
Unicode wide-strings (WSTRING's) with non-ASCII character sets can only be displayed in console if the locale is set to an UTF-8 version - most modern distros come with support that and char sets other than latin may work only in xterm.

DOS version

Official requirement: A DPMI (DOS Protected-Mode Interface) server must be present to run fbc.exe and any executable generated by it. This is not as bad as it looks. It simply means, that the "CWSDPMI.EXE" file (cca 20 KiB) must be present in the same directory or a place where the PATH environment variable points to. CWSDPMI package: homer.rice.edu...cwsdpmi (note: FreeDOS comes with it already installed). Further, there is a possibility to bypass this problem, and to use alternatively HDPMI, for details see DOS related FAQ .
You need a 80386 or newer CPU and cca 4 MiB of RAM. For compiling of large programs or libraries, you will need more. Similar applies to executables generated by FBC, those using FB's graphics library however will need a better/faster CPU (200 MHz (?), work in progress, code not yet fully optimized, and exact minimum not known by now). FBC and executables generated by it need an FPU (80387, 80487, always built-in since Pentium). This requirement can by bypassed using "EMU387" (auto-loaded if needed, but not included in FB packages, see delorie.com/djgpp/... ), or by avoiding floats and (non-trivial) removing float-related startup code.
The DOS version should run in any DOS, like FreeDOS, [Enhanced-]DR-DOS (do not use the DR-EMM386's included DPMI, use CWSDPMI or HDPMI), or MS-DOS. It also works properly under a number of "DOS box" environments that emulate a DOS system, such as the Windows NTVDM; however, some of these environments are not implemented faithfully and contain bugs, so caution should be exercised.
Long filenames are supported under systems that supply the long filename API defined by Windows 95, including DOS with an LFN TSR (for example DOSLFN (1) (2)). Long filename support is not required to use the compiler; however, care must be taken in unpacking the distribution, for example, with a Windows program which creates short names with numeric tails (FREEBA~1) instead of truncating to 8 characters (FREEBASI). The filenames of all files in the distribution should be truncated to 8.3 if the compiler is to be used without long filename support.
There are a few limitations, see DOS related FAQ .