                             FAQ / Knowledge base

   This  document  gives  last minute information regarding the compiler.
   Furthermore, it answers frequently asked questions and gives solutions
   to  common  problems found with Free Pascal. The information presented
   herein always supersedes those found in the Free Pascal documentation.

   For  more  comprehensive  information  on the pascal language, and the
   runtime  library  calls, consult the Free Pascal manuals and our Wiki.
   Topics covered in this document:
    1. General information

    1. [1]What is Free Pascal (FPC)?
    2. [2]Which versions exist, and which one should I use?
    3. [3]Free Pascal and GNU Pascal - a comparison
    4. [4]License and copyright information
    5. [5]Getting the compiler
    6. [6]Free Pascal installation hints
    7. [7]Why  do  i  have to supply a user name and password to get Free
       Pascal ?
    8. [8]Access denied error when connecting to the Free Pascal FTP site
    9. [9]Where can I find a text mode IDE?
   10. [10]I want a new version NOW
   11. [11]Installing a snapshot
   12. [12]Known bugs / Reporting bugs
   13. [13]I have to write a program for homework. Can you help?
   14. [14]How do I make a real Windows application with windows and menu
       bars?
   15. [15]How  do I make a game with Free Pascal? Can I make a game like
       Doom 3?
   16. [16]Getting more information when an application crashes
   17. [17]Increasing the heap size
   18. [18]Compiler seems to skip files in directories -Fu points to
   19. [19]Why are the generated binaries so big?
   20. [20]Configuration file problems (fpc.cfg or ppc386.cfg)
   21. [21]Runtime errors
   22. [22]Standard units
   23. [23]How does the compiler work internally?
   24. [24]Debugging smartlinked code does not fully work
   25. [25]Debugging  shared  library  (dynamic linked library) code does
       not fully work
   26. [26]PPU files binary compatibility between versions
   27. [27]Can't compile a program using a binary only version of a unit
   28. [28]What about .NET?

     Pascal language related information
    1. [29]Considerations in porting code to other processors
    2. [30]Considerations in porting code to other operating systems
    3. [31]Compiling Delphi code using Free Pascal
    4. [32]Building a unit
    5. [33]Compiling the system unit
    6. [34]How does function overloading work?
    7. [35]Calling C functions
    8. [36]Integrated Assembler syntax
    9. [37]Unit system, syslinux, sysos2 or syswin32 not found errors
   10. [38]There  is a new extension that will be really useful. Will you
       include it?

     Runtime library related information
    1. [39]Using the graph unit with Free Pascal
    2. [40]Why do I get wrong colors when using the graph unit?
    3. [41]File sharing and file locks
    4. [42]Accessing huge files using standard I/O routines
    5. [43]File denied errors when opening files with reset
    6. [44]Turbo Vision libraries

     DOS related information
    1. [45]Releasing software generated by the DOS compiler
    2. [46]Debugging
    3. [47]Dynamic libraries
    4. [48]Profiling
    5. [49]Running Free Pascal without a math coprocessor
    6. [50]Applications created with Free Pascal crash on 80386 systems
    7. [51]The mouse cursor is not visible in graphics screens
    8. [52]Accessing I/O ports
    9. [53]Accessing DOS memory / Doing graphics programming
   10. [54]Changing the default stack size
   11. [55]Using OS/2 generated applications under DOS

     Windows related information
    1. [56]Releasing software generated by the windows compiler
    2. [57]Debugging
    3. [58]Dynamic libraries
    4. [59]Profiling
    5. [60]Graph  and  problems  with  keyboard,  mouse  and  "dummy  dos
       windows"
    6. [61]Cygwin  binary  directory in your path sometimes causes builds
       to fail
    7. [62]Makefile problems on Win2000 (and NT)
    8. [63]Using the DOS compiler under Windows 95
    9. [64]Using OS/2 generated applications under Windows
   10. [65]Using DOS generated applications under windows
   11. [66]The mouse cursor does not respond in the Windows IDE
   12. [67]INSTALL.EXE of version 1.0.6 returns errors under some version
       of Windows

     UNIX related information
    1. [68]Releasing software generated by the unix compilers
    2. [69]Debugging
    3. [70]Dynamic libraries
    4. [71]Profiling
    5. [72]Why can't the linker find "vga"?
    6. [73]Compiler indicates missing as and ld

     OS/2 related information
    1. [74]Releasing software generated by the OS/2 compiler
    2. [75]Debugging
    3. [76]Dynamic libraries
    4. [77]Profiling
    5. [78]Using DOS generated applications under OS/2
    6. [79]INSTALL.EXE of version 1.0.6 or below returns an unknown error
       (-1) under OS/2
       or
       [80]INSTALL.EXE  of version 1.0.6 or above complains about missing
       TZ variable under OS/2
    7. [81]OS/2 compiler not working after upgrading to 1.9.6 or newer

     BeOS related information
    1. [82]Releasing software generated by the BeOS compiler
    2. [83]Debugging
    3. [84]Dynamic libraries
    4. [85]Profiling
    5. [86]BeOS linking problems

     Amiga related information
    1. [87]Releasing software generated by the Amiga compiler
    2. [88]Debugging
    3. [89]Dynamic libraries
    4. [90]Profiling

     PalmOS related information
    1. [91]Releasing software generated by the PalmOS compiler
    2. [92]Debugging
    3. [93]Dynamic libraries


    1. General information

    1. What is Free Pascal (FPC)?
       Originally  named FPK-Pascal, the Free Pascal compiler is a 32 bit
       Turbo Pascal and Delphi compatible Pascal compiler for DOS, Linux,
       Win32,  OS/2,  FreeBSD, AmigaOS, MacOSX, MacOS classic and several
       other  platforms  (the  number  of supported targets grows all the
       time,  although  not all of them are on the same level as the main
       ones).
       The  Free  Pascal compiler is available for several architectures,
       x86,  Sparc  (v8,v9),  ARM, x86 64 (AMD64/Opteron) and Powerpc. An
       older version (the 1.0 series) also supports m68k.
       The  compiler  is written in Pascal and is able to compile its own
       sources. The source files are under GPL and included.
       Free  Pascal  is  modest regarding its minimal system requirements
       (386-25  Mhz  for  the Intel version and ideally a 68020 processor
       for  the  Motorola  version.  FPU  emulation required). At least 2
       megabytes  of  RAM  are required. To remake the compiler more than
       32-64MB is recommended, less for 1.0.x versions.
       Short history:
          + 06/1993: project start
          + 10/1993: first little programs work
          + 03/1995: the compiler compiles the own sources
          + 03/1996: released to the internet
          + 07/2000: 1.0 version
          + 12/2000: 1.0.4 version
          + 04/2002: 1.0.6 version
          + 07/2003: 1.0.10 version
          + 05/2005: 2.0
    2. Which versions exist, and which one should I use?
       The  latest  official  version  is  2.0.4,  released  as a bug fix
       release  for  2.0.x  series. New development is performed in 2.1.x
       series,  which  eventually gets released as either 2.2.0, or 3.0.0
       (depending  on  amount  of  accumulated  changes  at  the  time of
       release).
       Historic versions
       FPC's  version  numbering  changed  a  few  times  over the years.
       Versions  before  0.99.5 are considered archaic. After the release
       of  0.99.5  a system in version numbering was introduced, and that
       system was changed slightly changed after the 1.0 release.
       Versioning for versions 0.99.5 - 1.0
       Compilers  with  an  even  last  number are release versions (e.g.
       0.99.8, 0.99.10, 0.99.12, 0.99.14 1.0.0)
       Compilers  and  packages  with  an odd last number are development
       versions (e.g. 0.99.9, 0.99.11, 0.99.13, 0.99.15)
       0.99.5  is an exception to this rule, since 0.99.5 IS a release (a
       release prior to the introduction of this odd/even system).
       Letters  behind  the  version  number (0.99.12b, 0.99.5d) indicate
       release  versions  with  some  bugs  and  problems in the original
       release (respectively 0.99.12 and 0.99.5) fixed.
       Versioning after 1.0
       Together  with  the  release  of  1.0  the  version  numbering was
       slightly  changed, and a system in versioning resembling the Linux
       kernel's  has  been  introduced.  The  main difference is that the
       difference  between  a release version is now in the second number
       (1.0.x vs 1.1.x) instead of the third number (0.99.14 vs 0.99.15),
       and  the  third  number now becomes the patch level, replacing the
       postfixed letter in the old system.
          + Releases  that  only  fixed bugs in version 1.0 were numbered
            1.0.x.
          + New  development  (the  so  called  snapshots)  started  with
            version number 1.1.x.
          + Eventually the 1.1.x versions, when stabilized turned to 2.x.
            Fixes on 2.0 release are numbered 2.0.x.
          + The  new  development after the 2.0 release is numbered 2.1.x
            and so on.
       Normally  you would want to use a release. Releases are considered
       stable,  and  easier  to  support (the bugs, quirks and unintended
       "features"  are well known after a period of time, and workarounds
       exist).
       Development  snapshots  (which  are  generated  daily) reflect the
       current status of the compiler. Development versions probably have
       new  features  and  larger  bugs fixed since the last release, but
       might  have  some temporary stability drawbacks (which are usually
       fixed by the next day).
       Development   snapshots   are   often  quite  useful  for  certain
       categories  of  users.  Ask  in  the  maillists if it is worth the
       trouble in your case if you're not sure.
       We  advise  all  users  to upgrade to the newest version for their
       target (Preferably the stable 2.0.x series).
    3. Free Pascal and GNU Pascal - a comparison

        Aim:
                Free  Pascal  tries  to  implement  a  Borland compatible
                pascal  compiler  on  as  many platforms as possible. GNU
                Pascal  tries  to  implement  a  portable pascal compiler
                based on POSIX.

        Version:
                Currently,  Free Pascal is at version 2.0 (may 2005). GNU
                Pascal  is  at version 2.1 (from 2002, which can be built
                with  several  different GCC's as backend; their Mac OS X
                version  is  an  exception  though, as it follows the GCC
                version number).

        Tracking:
                Between   releases,   development  versions  of  FPC  are
                available through daily snapshots and the source via CVS.
                GPC  issues  a  set  of patches to the last version a few
                times a year, and there are regular snapshot for OS X and
                Windows, made by users.

        Operating systems:
                Free  Pascal runs on a large amount of platforms of OSes,
                e.g.  DOS,  Win32  (no Unix porting layer needed), Linux,
                FreeBSD,  NetBSD,  OS/2,  BeOS, Classic Mac OS, Mac OS X,
                and   AmigaOS,   on,   at   the   moment   the  following
                architectures:  x86,  x86 64 (AMD64), Sparc, PowerPC, ARM
                and Motorola (Motorola only in version 1.0.x). GNU Pascal
                runs  basically on any system that can run GNU C, and for
                which the buildprocess was verified.

        Bootstrapping:
                FPC requires a suitable set of binutils (AS,AR,LD), gmake
                and  a  commandline  compiler. New architectures/OSes are
                crosscompiled.  GPC  bootstraps via a suitable version of
                GCC,  and  requires  a full set of binutils, flex, bison,
                gmake, a POSIX shell and libtool

        Sources:
                Free  Pascal is entirely written in Pascal (about 6 MB of
                source  code),  while GNU Pascal is written in C (it's an
                adaptation  of  the GNU C compiler: 2.8 MB code + 8 MB of
                GNU C code)

        Language:
                Free   Pascal   supports   the  Borland  Pascal  dialect,
                implements the Delphi Object Pascal language and has some
                Mac  Pascal extensions. GNU Pascal supports ISO 7185, ISO
                10206, (most of) Borland Pascal 7.0

        Extensions:
                Free  Pascal  implements  method,  function  and operator
                overloading.   (later   Delphi  versions  add  these,  so
                strictly  not an extension anymore) GNU Pascal implements
                operator overloading.

        License:
                Both compilers come under the GNU GPL.

        Author:
                Free  Pascal  was  started  by  Florian Klaempfl, Germany
                (florian@freepascal.org), GNU Pascal was started by Jukka
                Virtanen, Finland (jtv@hut.fi).

    4. License and copyright information
       Applications created by the compiler and using the runtime library
       come  under  a  modified  library gnu public license (LGPL), which
       permit  no restriction on the type of license the application has.
       It  is  therefore  possible to create closed source or proprietary
       software using Free Pascal.
       This extra exception to the LGPL is added:
       As a special exception, the copyright holders of this library give
       you  permission  to  link this library with independent modules to
       produce  an  executable,  regardless of the license terms of these
       independent  modules,  and  to  copy  and distribute the resulting
       executable  under  terms  of  your  choice, provided that you also
       meet, for each linked independent module, the terms and conditions
       of  the  license of that module. An independent module is a module
       which  is not derived from or based on this library. If you modify
       this library, you may extend this exception to your version of the
       library,  but you not obligated to do so. If you do not wish to do
       so, delete this exception statement from your version.
       Please  note that you still have to comply to the LGPL, which, for
       example,  requires  you  to provide the source code of the runtime
       library.  If you want to write proprietary closed source software,
       please do this to comply:
          + Most  people  can  satisfy  the  source  code  requirement by
            mentioning  the rtl source code can be downloaded at the Free
            Pascal  web  site:  if  you  did  not  modify the rtl this is
            considered  adequate  to  satisfy  the  LGPL  requirement  of
            providing source code.
          + If  you made modifications to the runtime library, you cannot
            keep  them  for  yourself,  you  must  make them available if
            requested.
          + Distribute the LGPL license with your product.
       The  compiler  source code, on the other hand, comes under the GNU
       Public  license, which means that any usage of the compiler source
       can only be used in software projects which have the same license.
    5. Getting the compiler
       The  latest  official  stable Free Pascal release is available for
       download from one of our [94]official mirrors
    6. Free Pascal installation hints
          + Do  not  install  the  compiler in a directory which contains
            spaces  in  its name, since some of the compiler tools do not
            like these
    7. Why  do  i  have  to  supply  a user name and password to get Free
       Pascal ?
       You  are trying to login in to an ftp site. You must use the login
       name:  anonymous  and as your password, you should put your e-mail
       address.
    8. Access denied error when connecting to the Free Pascal FTP site
       The  Free Pascal main ftp site can only accept a maximum number of
       simultaneous connections. If this error occurs, it is because this
       limit  has  been reached. The solution is either to wait and retry
       later, or better still use one of the Free Pascal mirror sites.
    9. Where can I find a text mode IDE?
       The development of the IDE (integrated development environment) is
       not  yet  finished.  However  a working test version of the IDE is
       included  with  version  1.0.x  and  higher of the compiler. There
       might be problems running the DOS IDE under Windows NT and Windows
       2000  (especially  the  debugger), in that case it is suggested to
       use the native Windows version.
       The  textmode  IDE  on *nix targets has several terminal problems.
       Try to use a real xterm as possible, and choose a font which has a
       Dos character set
   10. I want a new version NOW
       In  the time between the release of new official versions, you can
       have   a   look   at   and   test  developer  versions  (so-called
       "snapshots"). Be warned though: this is work under progress, so in
       addition  to  old bugs fixed and new features added, this may also
       contain new bugs.
       Snapshots  are generated automatically each night from the current
       source  at  that  moment.  Sometimes  this  may fail due to bigger
       changes  not  yet fully implemented. If your version doesn't work,
       try  again  one  or two days later. You're advised not to download
       the GO32v1 version for Dos, since it's not supported any more.
       The   latest   snapshot   can   always   be  downloaded  from  the
       [95]development web page.
   11. Installing a snapshot
       To  install  a snapshot, extract the zip archive into the existing
       program  directory  of  the  last  official version of Free Pascal
       (after  making  a  backup of the original of course). You can also
       extract  it into an empty directory and then move the files to the
       program directory, overwriting existing files.
       Make  sure that you extract the ZIP archive such that the included
       directory  structure  remains  intact.  For  example  if  you  use
       PKUNZIP,  use  "pkunzip  -d"  instead of just "pkunzip". Note that
       snapshots  also  contain a new RTL which most likely can't be used
       with the previous release version, so backup your old RTL as well.
   12. Known bugs / Reporting bugs
       Go to the [96]bugs page.
       If  you  wish to know the bugs for a specific Free Pascal version,
       go  to  the bugs page, display the bug database. At the end of the
       page  you  should see an option to view only specific bugs. Choose
       "With  Version" with the version you want to get information about
       and  "With  Status" choose "Unfixed". This should display all bugs
       which  are  present  in  the  specific version of the compiler you
       requested.
   13. I have to write a program for homework. Can you help?
       No. Please, don't send us mail about homework, we are no teachers.
       The  Free  Pascal  development team tries to give good support for
       the Free Pascal compiler and are trying to always reply to emails.
       If we get emails like this, this becomes harder and harder.
   14. How  do  I  make  a real Windows application with windows and menu
       bars? The easiest way is to [97]download Lazarus. It won't be just
       a  Windows application, it will also work under Linux, FreeBSD and
       MacOS X.
   15. How do I make a game with Free Pascal? Can I make a game like Doom
       3?  Yes, you can make games with Free Pascal and if you are really
       good  you  can make a game like Doom 3. Making games is difficult,
       you  need  to  be  an experienced programmer to make them. The web
       site  [98]www.pascalgamedevelopment.com  is  a community of people
       who program games in Free Pascal and Delphi.
       If  you  want  a  start,  please  start  to  study [99]JEDI-SDL or
       [100]PTCPas.  Also  you  can  try  to  study an existing game, for
       example  [101]The Sheep Killer is a very simple game and it should
       not be very hard to understand its code.
   16. Getting more information when an application crashes
         1. The easiest possibility is to recompile your program with -gl
            debugging  option.  This  way  unit LineInfo is automatically
            linked  in,  and  the  printout  after  a  program crash then
            contains  source line numbers in addition to addresses of the
            crash.   To  see  runtime  library  (RTL)  functions  in  the
            backtrace with their real name, you have to recompile the RTL
            with -gl too.
         2. For  more  comprehensive  checking,  compile the program with
            debugging information (use the -g command line option)
         3. Load the program in the debugger
gdb(pas)(w) --directory=<src dirs> myprog.exe
            Notes:
               o Under  UNIX  systems  (Linux,  the BSD's), don't add the
                 ".exe" after myprog
               o "src  dirs"  is  a  list  of  directories containing the
                 source  code  files  of  myprog  and  the  units it uses
                 seperated by semi-colons (";"). The current directory is
                 automatically included.
         4. Once  inside  the  debugger,  you  can  (optionally)  set the
            command  line  options  that  will  be passed to your program
            using the command "set args <option1 option2 ...>"
         5. To start the program, type "run" and press enter
         6. After the program has crashed, the address of the instruction
            where the crash occurred will be shown. The debugger will try
            to  display  the  source  code  line  corresponding with this
            address. Note that this can be inside a procedure of the RTL,
            so the source may not always be available and most likely the
            RTL wasn't compiled with debugging information.
         7. If  you  then type "bt" (BackTrace), the addreses in the call
            stack  will  be  shown (the addresses of the procedures which
            were  called  before the program got to the current address).
            You  can  see which source code lines these present using the
            command
info line *<address>
            For example:
info line *0x05bd8
   17. Increasing the heap size
       By  default  Free  Pascal  allocates  a small part of RAM for your
       application as heap memory. If it just allocated all it could get,
       people  running  Windows  would  have  problems  as  Windows would
       increase the swap file size to give the program more memory on and
       on, until the swap file drive would be full.
       You can specify the size of the heap with -Chxxxx.
       However,  the  heap  size doesn't really matter, since the Heap is
       able  to  grow:  if  you've used all the available heap space, the
       program  will  try  to  get  more memory from the Operating system
       (OS),  so the heap is limited to the maximum amount of free memory
       provided by the OS.
       It  is  only  handy  if  you know you will need at least a certain
       amount  of  memory.  You can then specify this value using the -Ch
       parameter,  so  your  program will allocate it at once on startup.
       This is slightly faster than growing the heap a number of times.
   18. Compiler seems to skip files in directories that -Fu points to
       This  sometimes  happens  with installation/compilation scripts if
       the  copying  command doesn't preserve dates. The object files get
       older than the PPU file, and the compiler tries to recompile them.
       A simple touch will solve it.
       Also  note  that  FPC,  contrary  to  Turbo  Pascal keeps track of
       includefiles.  Modified  includefiles  or  duplicate  names  might
       trigger an attempt at recompiling
   19. Why are the generated binaries so big?
       There are several reasons and remedies for this:
         1. You  can  create  smartlinked  applications.  To  turn on the
            generation  of  smartlinkable units, use the -Cx command line
            option  when  compiling your units. To turn on the linking of
            previously  generated smarlinkable units, use the -XX (-XS in
            0.99.12  and  earlier)  command  line option when compiling a
            program.
         2. Normally, all symbol information is included in the resulting
            program  (for easier debugging). You can remove this by using
            the  -Xs  command line option when compiling your program (it
            won't do anything when compiling units)
         3. You can use UPX to pack the .EXEs (just like e.g. pklite) for
            Dos  (GO32v2)  and  Windows  targets. Look [102]here for more
            info.
         4. You can use LXLITE for packing EMX binaries, but you won't be
            able  to  run  them  under DOS (with extender) any more then.
            This issues is not relevant for native OS/2 binaries compiled
            for  target  OS2  with version 1.9.x and above, because these
            don't  run  under  DOS  anyway.  In addition, it might not be
            possible  to  use  compressed binaries on lower OS/2 versions
            (like  2.x)  depending  on chosen type of compression. LXLITE
            can be found e.g. on [103]Hobbes, search for LXLITE.
         5. Turn on optimalisations, both for supplied packages (RTL, FV,
            FCL)  and for your own code, this will also decrease the code
            size.
         6. Keep  in  mind  that  under  NT,2000,XP,  compressed binaries
            startup  relatively  slow. Test under various conditions (OS,
            CPU  speed,  memory)  if  the  behaviour is acceptable before
            compressing
   20. Configuration file problems (fpc.cfg or ppc386.cfg)
       Starting from version 1.0.6 of Free Pascal, the configuration file
       is   now  called  fpc.cfg  instead  of  ppc386.cfg.  For  backward
       compatibility  , ppc386.cfg is still searched first and, if found,
       is used instead of fpc.cfg
       Versions  prior  to Free Pascal 1.0.6 do not recognize fpc.cfg, so
       if  you  wish  to use an earlier version of the compiler using the
       same  configuration  file  used with FPC version 1.0.6 (or later),
       the configuration file should be renamed to ppc386.cfg
       .
   21. Runtime errors
       When  there is abnormal termination of an application generated by
       Free  Pascal,  it  is  very  probable that a runtime error will be
       generated. These errors have the form :
Runtime error 201 at 0x00010F86
0x00010F86  main,  line 7 of testr.pas
0x0000206D
       The  201  in  this  case  indicates  the runtime error number. The
       definition  of the different runtime error numbers is described in
       the Free Pascal user's manual, Appendix D. The hexadecimal numbers
       represent the call stack when the error occured.
   22. Standard units
       To  see  the  list of base units supplied with Free Pascal, and on
       which  platform they are supported, consult the Free Pascal user's
       manual.  There  is also a short description of what each unit does
       in the same section of the manual.
   23. How does the compiler work internally?
   24. Debugging smartlinked code does not fully work
       Debugging  smart linked code might not work correctly. This is due
       to  the  fact  that no type information is emitted for smartlinked
       code. If this would not be done, the files would become enormous.
       While  debugging,  it  is  not recommended to use the smartlinking
       option.
   25. Debugging  shared  library  (dynamic linked library) code does not
       fully work
       Debugging  shared libraries (or dynamic linked libraries) produced
       by the Free Pascal compiler is not officially supported.
   26. PPU files binary compatibility between versions
    Can't compile a program using a binary only version of a unit
       Sometimes, even though there is a binary version of a module (unit
       file   and  object  file)  available,  the  compiler  still  gives
       compilation   errors.   This   can   be   caused   either   by  an
       incompatibility  in  the PPU file format (which should change only
       between  major versions of the compiler), or by a change in one of
       the units of the RTL which has changed in between releases.
       To  get more information, compile the code using the -va (show all
       information)  compiler  switch, and the unit loading phase will be
       displayed.  You might discover that the unit being loaded requires
       to be recompiled because one of the unit it uses has changed.
       So  if  you plan on distributing a module without the source code,
       the  binaries  should  be  compiled  and  made  available  for all
       versions   of   the   compiler  you  wish  to  support,  otherwise
       compilation errors are bound to occur.
       In  other  words,  the  unit  (PPU)  file  format  does not change
       significantly  in  between  minor  releases  of  the compiler (for
       exemple  :  from  1.0.4  and  1.0.6)  which  means they are binary
       compatible,  but  because  the  interface  of the units of the RTL
       certainly changes between versions, recompilation will be required
       for each version anyways.
   27. File denied errors when opening files with reset
       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
   28. What about .NET? Occasionally, users ask about a FPC that supports
       .NET, or our plans in that direction.
       Mainly   the   users  are  either  interested  because  of  .NET's
       portability  aspects  (Mono  is  quoted  over  and over again), or
       because  it  is  supposed  to  be  the  next  big thing in Windows
       programming.
       While  the  FPC  core  developpers  are somewhat interested out of
       academic  curiousity  (mainly  because  it  could  be  a pilot for
       creating bytecode) there are however several problems with .NET in
       combination with FPC:
         1. FPC's  language  uses pointers, and so can only be unmanaged.
            Unmanaged  code  is  not portable under .NET, so that already
            kills  all  possible  benefits. This also means that existing
            FPC and Delphi code won't run on .NET.
         2. FPC's  libraries  don't  base  on .NET classes and datamodels
            (and  can't be changed to do so without effectively rewriting
            them), moreover the libraries could only be unmanaged too, or
            they would be incompatible
         3. There  is  nothing  practical known yet about how portable an
            average  .NET  code  will  be.  Little experiments with hello
            world  level  code mean nothing, that kind of code works with
            plain C too.
         4. Operating  System dependant code wouldn't work anymore, since
            the win32 interface is unmanaged.
       So  effectively  this  means that for FPC to benefit from .NET you
       would have to significantly adapt the language (thus compiler) and
       libraries,   and   be   incompatible   with  the  existing  native
       sourcecode.  This  is  not  adding  support  for  .NET in FPC, but
       reimplementing  FPC  on  .NET  from near scratch without backwards
       compability.  Moreover  that  also  means that existing apps would
       have  to  be  rewritten  for .NET, since it would take more than a
       simple recompile with a FPC/.NET compiler.
       While  unmanaged  code  has  some  uses  (allows to integrate with
       managed   code   inside   windows  easier),  this  still  needs  a
       codegenerator  backend  to  be  written,  interfaces and libraries
       defined,  for  little  practical use. This means a lot of work and
       since .NET take up is not really high, this might not be worth it,
       since an unmanaged FPC/.NET would only be minimally used.
       However  if  a FPC user does the bulk of the work (e.g. a bytecode
       codegenerator,  and  maybe some base libraries) and if the work is
       suitable  for  inclusion in FPC (a very big if), we will of course
       include it.
       These  problems  are  pretty  much similar for the Java (bytecode)
       too.  One  has to mutilate the language, and rewrite the libraries
       from scratch on the base libraries of the target (Java/.NET). Such
       an attempt would have little synergy with the FPC project as it is
       today.

     Pascal language related information
    1. Considerations in porting to other processors
       Because the compiler now supports processors other than the Intel,
       it  is  important to take a few precautions so that your code will
       execute correctly on all processors.
          + Limit  your  use of asm statements unless it is time critical
            code
          + Try  not  to rely on the endian of the specific machines when
            doing arithmetic operations. Furthermore, reading and writing
            of binary data to/from files will probably require byte swaps
            across different endian machines (swap is your friend in this
            case).  This  is even more important if you write binary data
            to  files.  Freepascal defines ENDIAN_LITTLE or ENDIAN_BIG to
            indicate the target endian.
          + Try  limiting  your local variables in subroutines to 32K, as
            this  is the limit of some processors, use dynamic allocation
            instead.
          + Try  limiting the size of parameters passed to subroutines to
            32K,  as  this  is the limit of some processors, use const or
            var parameters instead.
          + The integer and cardinal types might have different sizes and
            ranges  on  each  processor,  as  well  as  depending  on the
            compiler mode.
          + The  CPU32  or  CPU64  (defined  by FPC starting from version
            1.9.3)  are  defined  indicating if the target is a 32-bit or
            64-bit  cpu;  This  can  help  you separate 32-bit and 64-bit
            specific code.
          + Use  the  ptrint  type  (defined by FPC starting from version
            1.9.3)  when  declaring an ordinal that will store a pointer,
            since  pointers  can  be either 32-bit or 64-bit depending on
            the processor and operating system.
    2. Considerations in porting code to other operating systems
       Because the compiler supports several different operating systems,
       is  important  to  take  a  few precautions so that your code will
       execute correctly on all systems.
          + File   sharing   is   implemented  differently  on  different
            operating  systems,  so opening already opened files may fail
            on some operating systems (such as Windows). The only correct
            way to make sure to have the same file sharing behavior is to
            use the I/O routines furnished in sysutils.
          + Clean  up at the end of your program, i.e. close all files on
            exit,   and  release  all  allocated  heap  memory,  as  some
            operating  systems  don't  like  it when some things are left
            allocated or opened.
          + Some  operating systems limit the local stack space which can
            be  allocated,  therefore it is important to limit subroutine
            nesting,  and  the  amount of local variables. Limiting total
            stack  space  usage  at  a given moment to at most 256 KBytes
            while make porting easier.
          + Do  not  hard  code paths to files, try to use relative paths
            instead
          + Use  the  following constants (defined in the system unit) to
            get information on files, line endings, and to build paths:
               o LineEnding  :  Indicates the characters which end a text
                 line
               o LFNSupport  :  Indicates if long filenames are supported
                 (more then 8.3 characters)
               o DirectorySeparator  :  The character or characters which
                 separate path components
               o DriveSeparator  : The character which separate the drive
                 specification from the rest of the path
               o PathSeparator    :   The   character   which   separates
                 directories in the search path environment
               o FileNameCaseSensitive   :   Boolean  indicating  if  the
                 filenames for this system are case-sensitive or not
            It  is  also  possible  to  use  the  PathDelim,  PathSep and
            DriveDelim constants defined in sysutils.
    3. Compiling Delphi code using Free Pascal
       The  compiler  supports  the Delphi classes. Make sure you use the
       -S2  or  -Sd  switches  (see  the manuals for the meaning of these
       switches).  For  a  list  of Delphi incompabilities also check the
       manual.
    4. Building a unit
       It  works like in Turbo Pascal. The first keyword in the file must
       be  UNIT  (not  case  sensitive).  The  compiler will generate two
       files:  XXX.PPU  and  XXX.O.  The  PPU file contains the interface
       information  for  the compiler and the O-file the machine code (an
       object  file, whose precise structure depends on the assembler you
       used).  To  use  this  unit  in  another unit or program, you must
       include its name in the USES clause of your program.
    5. Compiling the system unit
       To  recompile  the system unit, it is recommended to have GNU make
       installed.  typing  'make'  in  the rtl source directory will then
       recompile  all RTL units including the system unit. You may choose
       to  descend into the directory of your OS (e.g. rtl/go32v2) and do
       a 'make' there.
       It is possible to do all this manually, but you need more detailed
       knowledge of the RTL tree structure for that.
    6. How does function overloading work?
       function overloading is implemented, like in C++:
procedure a(i : integer);
begin
end;
procedure a(s : string);
begin
end;
begin
a('asdfdasf');
a(1234);
end.
       You must be careful. If one of your overloaded functions is in the
       interface part of your unit, then all overloaded functions must be
       in  the  interface  part.  If you leave one out, the compiler will
       complain with a 'This overloaded function can't be local' message.
       Overloaded  functions  must  differ  in their parameters, it's not
       enough if their return types are different.
    7. Calling C functions
       It  is  possible to call functions coded in C, which were compiled
       with the GNU C compiler (GCC). Versions which have been tested are
       version  2.7.2  through  2.95.2 of GCC. For calling the C function
       strcmp declare the following:
function strcmp(s1 : pchar;s2 : pchar) : integer;cdecl;external;
    8. Integrated Assembler syntax
       The  default  assembler  syntax (AT&T style) is different from the
       one in Borland Pascal (Intel style).
       However,  as  of version 0.99.0, the compiler supports Intel style
       assembly syntax. See the documentation for more info on how to use
       different assembler styles.
       A description of the AT&T syntax can be found in the GNU Assembler
       documentation.
    9. Unit system, syslinux, sysos2 or syswin32 not found errors
       System  (syslinux  -  not  the  bootloader,  sysos2  or  syswin32,
       depending  on platform) is Pascal's base unit which is implicitely
       used   in   all  programs.  This  unit  defines  several  standard
       procedures and structures, and must be found to be able to compile
       any pascal program by FPC.
       The location of the system.ppu and syslinux.o files are determined
       by  the  -Fu  switch  which  can  be specified commandline, but is
       usually in the ppc386.cfg or fpc.cfg configuration file.
       If  the  compiler  can't  find  this unit there are three possible
       causes:
         1. The  ppc386.cfg  or  fpc.cfg  isn't  in  the same path as the
            compiler  executable  (go32v2,  win32  and  OS/2) or can't be
            found  as  "/etc/fpc.cfg" or ".fpc.cfg" in your homedirectory
            (Linux).
         2. The  fpc.cfg or ppc386.cfg doesn't contain the -Fu line, or a
            wrong  one.  See  the  [104]build  faq  (PDF), especially the
            chapters about the fpc.cfg and the directory structure.
         3. The  files  ARE  found  but  the  wrong  version or platform.
            Correct  ppc386.cfg or fpc.cfg to point to the right versions
            or  reinstall  the right versions (this can happen if you try
            to  use  a  [105]snapshot compiler while the -Fu statement in
            the  used  fpc.cfg still points to the RTL that came with the
            official release compiler).
       A  handy  trick  can  be  executing "ppc386 programname -vt", this
       shows  where  the  compiler  is  currently  looking for the system
       unit's files. You might want to pipe this through more (Dos, OS/2,
       Windows)  or  less  (Linux),  since  it can generate more than one
       screen information:
Dos, OS/2, Windows: ppc386 programname -vt |more

unix, linux: ppc386 programname -vt |less

   10. There  is  a  new  extension  that will be really useful. Will you
       include it?
       Occasionally  somebody  asks  for a new extension on the maillist,
       and  the  discussions  that  follow  have  a recurring pattern. An
       extension is quite a big deal for the FPC team, and there are some
       criteria  that  are  used to select if an extension is "worth" the
       trouble. The most important pre-selection criteria are:
         1. Compability  must  not  be  compromised  in any way. Existing
            codebases  on  at  least  the Pascal level must keep running.
            This is often more difficult than most people think.
         2. The  extension  must have real value. Anything that is only a
            shorter  notation  does  not  apply,  unless  it  is  out  of
            compatibility   with   an  existing  Pascal/Delphi  codebase.
            Practically  it  means  it  must make something possible that
            can't be done otherwise or be a compability item
         3. The  change  must  fit  in  with  the  scope  of the project,
            implementing  a  Pascal  compiler  which  can  have a RAD and
            generic  DB  system.  This excludes features like inline SQL,
            and large garbage collected objectframeworks.
       Exceptions  to  the  second  rule  are sometimes made for platform
       specific  reasons (e.g. interfacing to some other language or OS).
       The  first  rule  is often a problem, because issues aren't easily
       recognizable  unless one has tried to make extensions before. Best
       is  to  make  a  thoroughly  written  proposal that the devels can
       review with
          + Explanation of the feature
          + Why it is needed, what does it make possible?
          + How you would implement it?
          + Lots  of  examples  of  typical  use,  and tests for possible
            problem cases
       Try  to  be verbose and really try to view this from the viewpoint
       of somebody who has to implement it, and try to make examples that
       span  multiple  units  and procedures, and review what happens. Be
       critical,  try  to  punch  holes  in  your  own reasoning and find
       possible problematic cases, and document them.
       Besides  these  pre-selection  rules  and documentation, the other
       important  question  is  who is going to do the work. Keep in mind
       that  the  FPC  devels  are  volunteers  with to-do lists that are
       booked  till the next decade. You can't simply expect they'll drop
       everything  from their hands and implement the feature because you
       need  it  urgently, or think it is nice. If you are not willing to
       implement  it  yourself,  and  submit  patches,  chances are slim.
       Remarks  as  "this  will  attract  a  lot  of  users  because" are
       considered  with  a  lot of scepsis, since that applies to any new
       development.



Runtime library related information

    1. Using the graph unit with Free Pascal
       Since  version  1.0, we have a completely platform independent way
       of   selecting   resolutions   and  bitdepths.  You  are  strongly
       encouraged to use it, because other ways will probably fail on one
       or  other  platform.  See  the documentation of the graph unit for
       more information.
    2. Why do I get wrong colors when using the graph unit?
       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  all graphics cards made in at least the last 5 years, you will
       most likely get a 16 bit mode.
       The  main  problem  is that in 16 (and 15, 24, 32, ...) bit modes,
       the  colors  aren't  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't 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 intensite, 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. Make sure you use the constant names
       (D8BIT,  D4BIT,  ...) and not their actual numeric values, because
       those  values  can  change with the next release! That is the very
       reason why such symbolic constants exist.
    3. File sharing and file locks
       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 :
          + UNIX systems : There is no verification at all.
          + Windows : An access denied error will be reported.
          + Amiga : An access denied error will be reported.
          + DOS / OS/2 : If the file is opened more than once by the same
            process,  no  errors  will  occur, otherwise an access denied
            error will be reported.
       There are two ways to solve this problem:
          + Use  specific operating system calls (such as file locking on
            UNIX and Amiga 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.
    4. Accessing huge files using standard I/O routines
       The  runtime  library  currently limits access to files which have
       file sizes which fit into a 32-bit signed integer (longint).
       Therefore  accessing  files  which  have file sizes greater than 2
       Gigabytes   will   produce   unpredictable  behavior.  Application
       accessing  such  files  will  have to use direct operating systems
       calls (if the OS supports such files) to workaround the problem.
    5. Turbo vision libraries
       A  Turbo  Vision  port,  called Free Vision, has progressed nicely
       lately.  It's  already  very usable, we are even writing an IDE in
       it.  When it will be in a more stable state it will be included in
       the standard runtime library.

     DOS related information
    1. Releasing software generated by the DOS compiler
          + If  your  program  uses  floating  point  code (which is very
            probable),  make sure to read "[106]Applications created with
            Free  Pascal crash on 80386 systems" regarding special issues
            which  might  occur.  Math  coprocessor emulation software is
            then required (wmemu387.dxe should be redistributed with your
            software)
          + The target system must have a DPMI server. To avoid problems,
            the file cwsdpmi.exe should always be redistributed with your
            application
          + The target system must have DOS 3.3 or later
          + The  default  heap  size is 2 Megabytes. Automatic growing of
            the heap is supported
          + The default stack size is 256 Kbytes. See also "[107]Changing
            the default stack size"
          + The stack checking option is available on this platform.
    2. Debugging
       The  GNU  debugger v4.16 and later have been tested, and generally
       work  as they should. Because the GNU debugger is C oriented, some
       pascal  types  might  not  be  represented  as  they should. It is
       suggested to use gdbpas or the text mode IDE instead of GDB, which
       are both available for the DOS target.
    3. Dynamic Libraries
       Creation  or  use  of  shared  libraries (also called dynamic link
       libraries) is not supported under this platform.
    4. Profiling
       Profiling with gprof is supported for this platform.
    5. Running Free Pascal without a math coprocessor?
       On  the  Intel version the emulator is automatically loaded by the
       compiler if you add the following commands to your autoexec.bat:
SET 387=N
SET EMU387=C:\PP\BIN\GO32V2\WEMU387.DXE
       (don't  forget  to  replace the C:\PP with the directory where you
       installed FPC)
    6. Applications created with Free Pascal crash on 80386 systems
          + Trying  to  run  an  application  which  does  floating point
            operations  on  a 386 system without a math co-processor will
            crash  unless the emu387 unit is used, as this unit loads the
            math co-processor emulator (called wmemu387.dxe). You can add
            the unit as follows:
program myprog;
uses emu387, ...
            When the application is released, the software package should
            also  include  the wmemu387.dxe redistributable file to avoid
            problems.
            .
          + Some  80386  systems  have  a  hardware bug which corrupt the
            accumulator  register  EAX if it is used in a MOV instruction
            just  after  a POPAL instruction. Prior to version 1.0.5, the
            compiler   and  runtime  library  could  generate  such  code
            sequences.  This  is  now  fixed  and  should no longer cause
            problems
    7. The mouse cursor is not visible in graphics screens
       A  lot  of  DOS  mouse drivers don't support mouse cursors in VESA
       modes  properly.  Logitech  is said to have a decent mouse driver,
       which can be found [108]here
    8. Accessing I/O ports
       With  versions before 0.99.10: if you're under DOS you can use the
       outport* and inport* procedures of the go32 unit.
       Since  version  0.99.8, the Port array is supported like in TP, as
       long  as  you  use  the  ports unit in your program (not available
       under Win32).
       I/O  port  access  is possible under Linux, but that requires root
       privileges.  Check  the  manuals  for  the  IOPerm,  ReadPort  and
       WritePort procedures. (Unit Linux)
    9. Accessing DOS memory / Doing graphics programming
       You can do like in Turbo Pascal, via absolute or mem[]. For larger
       memory  blocks  use  the  dosmemput/dosmemget routines in the Go32
       unit.
   10. Changing the default stack size
       Under  the  DOS  (GO32V2)  target,  the  default stack size to 256
       bKbytes.  This can be modified with a special DJGPP utility called
       stubedit.  It  is  to note that the stack may also be changed with
       some  compiler  switches,  this  stack  size,  if greater then the
       default  stack  size  will  be used instead, otherwise the default
       stack size is used.
   11. Using OS/2 generated applications under DOS
       OS/2  applications  (including  the compiler) created with version
       1.0.x  and  before  should work correctly under vanilla DOS, since
       they  are  based  on EMX (versions prior to 1.0.5 had big problems
       with  EMX  under  DOS, this is now fixed). It is important to note
       that  the  compiled  applications  require  the  EMX runtime files
       (emx.exe)  to  execute properly. It may be necessary to distribute
       these files with the generated application.
       Binaries  created  for  target  OS2  with  version 1.9.x and above
       cannot  run under DOS any more, because they directly use OS/2 API
       functions  not available when running under extender - you need to
       compile   for  a  newly  added  EMX  target  which  provides  this
       capability of running on both platforms.

     Windows related information
    1. Releasing software generated by the windows compiler
       There  is  no  special requirements for releasing software for the
       windows  platform,  it  will  work  directly  out  of the box. The
       following are default for the Windows platform:
          + The default heap size is 256 Kbytes. Automatic growing of the
            heap  is supported. It is to note that Windows 95, Windows 98
            and  Windows  Me  limit  the  heap  to  256 Mbytes (this is a
            limitation  of  those  Operating systems, not of Free Pascal,
            consult MSDN article Q198959 for more information).
          + Stack size is unlimited
          + The stack checking option is not available on this platform.
    2. Debugging
       The  GNU  debugger v4.16 and later have been tested, and generally
       work  as they should. Because the GNU debugger is C oriented, some
       pascal  types  might  not  be  represented  as  they should. It is
       suggested to use gdbpas or the text mode IDE instead of GDB, which
       are both available for windows targets.
    3. Dynamic libraries
       Creation  and  use  of  shared libraries (also called dynamic link
       libraries)  is  fully  supported  by  the  compiler.  Refer to the
       Programmer's  Reference  Manual  for  more  information  on shared
       library creation and use.
    4. Profiling
       Profiling  is  supported using gprof, starting with version 1.0.7.
       It  requires  mingw to be installed, and that fpc.cfg point to the
       correct library paths.
    5. Graph and problems with keyboard, mouse and "dummy dos windows"
       Problem:
          + If  you use the Graph unit under Win32, you can't use the API
            mouse unit for mouse support or use the win32 Crt unit to get
            keyboard  data. The reason for this is that the window popped
            up is a GUI window, and not a console one.
       Solution:
          + Use units WinMouse and WinCrt instead.
       Problem:
          + When  you  follow  the  above advice, and you run your purely
            Graph  based  win32  program  from the RUN menu in windows, a
            dummy dos window is opened.
       Solution:
          + Set the application type to GUI:
{$apptype GUI}
            and put this line before your programs InitGraph statement:
ShowWindow(GetActiveWindow,0);
            This will hide the dos window window.
       Some of the demos (like fpctris) use these techniques
    6. Cygwin  binary  directory  in  your  path sometimes causes strange
       problems
       The  mingw  make tool seems to look for a "sh.exe", which it finds
       when  the  cygwin  binary  directory  is  in  the  path.  The  way
       directories are searched changes, and the build process dies.
       Solution:  don't  put cygwin in your global path for now, only add
       it when needed. Efforts are made to work around this.
       Possible  untested  workaround:  add  mingw  sh.exe to a directory
       before the cygwin binary directory in the path
    7. Makefile problems on Win2000 (and NT)
       After  the 1.0.4 release, some problems with the mingw win32 build
       tools (make.exe and friends) were discovered. A patched version of
       these  tools has been released. Automatically building large parts
       of  the  sources  under  Windows  2000 and Windows NT is now a lot
       easier.
         1. Download makew32.zip from the [109]ftp site or a mirror.
         2. Unzip  it to your pp directory. (the archive already contains
            the bin/win32/ directories)
         3. Properties   of   "My  Computer",  (system  properties),  tab
            "advanced", "Environment Variables".
         4. In the bottom box, select the "Path" entry, and then "Edit"
         5. In the top field of this dialog, change "Path" to "PATH", and
            click OK.
         6. Close and Reopen dosboxes to apply changes.
       Alternatively,  if  changing the case of the "Path" variable leads
       to  problems, you could run the following batchfile in each dosbox
       prior to working with FPC:
set a=%PATH%
set Path=
set PATH=%A%
set a=
       A  lot,  if not all, makefile trouble is now probably gone. If you
       still  have problems try getting the makent.zip utilities from the
       [110]ftp  site  or  a  mirror.  It  should  be installed just like
       makew32.zip.
       Note:  The win32 version of make is case sensitive with respect to
       filenames (paths?) and environment variables
    8. Using the DOS compiler under Windows 95
       There  is  a problem with the DOS (GO32V2) compiler and Windows 95
       on  computers with less than 16 Megabytes of RAM. First set in the
       properties  of  the DOS box the DPMI memory size to max value. Now
       try  to  start a demo program in the DOS box, e.g. HELLO (starting
       may  take  some  time).  If this works you will be able to get the
       compiler  to  work  by  recompiling  it  with a smaller heap size,
       perhaps 2 or 4 MB (option -Chxxxx).
    9. Using OS/2 generated applications under Windows
       Normally  OS/2  applications (including the compiler) created with
       version 1.0.x and before should work under Windows, since they are
       based on EMX - see [111]note about running OS/2 applications under
       DOS  for  more  detailed  information.  You  need the RSX extender
       (rsx.exe)  to  do  this.  There  have been problems reported while
       trying  to  run  EMX  applications  under  NT  / 2000 / XP systems
       though.  This  seems  to be a problem with EMX (RSX) itself. It is
       not recommended to use Free Pascal OS/2 compiled programs under NT
       / 2000 and XP, as it might produce unexpected results.
   10. Using DOS generated applications under windows
       Several  problems  have  been  found  running  DOS  software under
       certain  versions  of  Windows  (NT / 2000 / XP). These seem to be
       problems  with  the DOS emulation layers (emulated DPMI services).
       These  problems  may not occur with all software generated by FPC.
       Either applications should be tested on these systems before being
       released, or Windows versions should be generated instead.
   11. The mouse cursor does not respond in the Windows IDE
       In  windowed  mode,  the  mouse  cursor might not respond to mouse
       moves  and  clicks. Just change the properties of the console, and
       remove  the  quick  edit  mode option. This should solve the mouse
       response problems.
   12. INSTALL.EXE  of version 1.0.6 returns errors under some version of
       Windows
       The original 1.0.6 installer gave errors under Win95/98/Me in some
       circumstances.  A  new  installer  (INSTALL.EXE) is included as of
       this  date  (10th July 2002) with version 1.0.6. If you downloaded
       Free  Pascal  for  Windows before this date, you should upgrade to
       the latest version of Free Pascal.

     UNIX related information

   This  section  also  applies  to  most  unix  variants, such as linux,
   freebsd and netbsd.
    1. Releasing software generated by the unix compilers
          + The  default  heap  size is 256 Kbytes for the intel version,
            and  128  Kb  for the m68k versions. Automatic growing of the
            heap is supported.
          + There is no stack space usage limit.
          + Under Solaris and QNX, stack checking is simulated.
          + Minimal operating system versions :
               o Linux : Kernel v1.1.x or later.
               o FreeBSD : version 4.x or later.
               o NetBSD : version 1.5 or later.
               o Solaris  :  version  5.7  of SunOS or later (should work
                 with earlier versions, but untested).
               o Qnx  :  version 6.1.0 or later (should work with earlier
                 versions, but untested).
    2. Debugging
       The  GNU  debugger v4.16 and later have been tested, and generally
       work  as they should. Because the GNU debugger is C oriented, some
       pascal  types might not be represented as they should. For FreeBSD
       a  recent  GDB (v5) CVS snapshot is recommended for Pascal support
       and ease of building
    3. Dynamic libraries
       These  operating  systems do support shared libraries (also called
       dynamic  link  libraries),  Free  Pascal  currently  does not emit
       position  independant  code (PIC), as required for the creation of
       shared libraries.
       Therefore,  even though the linux compiler target permits creating
       shared  libraries,  the usage of that shared library may result in
       undefined  behavior,  especially  if accessing global variables in
       the  library. Creation of shared libraries is not recommended with
       the current version of the compiler.
       Importing code from shared libraries does work as expected though,
       since it does not require usage of position independant code.
    4. Profiling
       Profiling  is  supported  using  gprof  under  linux,  FreeBSD and
       NetBSD,  the latter two only since 1.0.8. On other other unix-like
       operating systems, profiling is currently not supported.
    5. Why can't the linker find "vga"?
       This error typically looks like this:
Free Pascal Compiler version 1.0.x [xxxx/yy/zz] for i386
Copyright (c) 1993-2000 by Florian Klaempfl
Target OS: Linux for i386
Compiling test.pp
Assembling test
Linking test
/usr/bin/ld: cannot find -lvga
test.pp(6,4) Warning: Error while linking Closing script ppas.sh 5 Lines
compiled, 0.2 sec
       This  error  is  not  an  error  in the installation of FPC or FPC
       itself, but a missing Svgalib library in your unix install. Please
       install  the required library using your favourite package manager
       tool
    6. Compiler indicates missing as and ld
       Normally  unix  systems  have  the  assembler (as) and linker (ld)
       pre-installed  and  already in the search path. That is the reason
       why these tools are not supplied with the compiler.
       If  the  compiler  cannot find these tools, either they are not in
       your search path, or they are not installed. You should either add
       the path where the tools are located to your search path, and / or
       you should install these tools.
       It  is  to  note  that  the  Solaris version of FPC contains these
       tools.

     OS/2 related information
    1. Releasing software generated by the OS/2 compiler
       The  OS/2  compiler  version  1.0.x  and  before  is based on EMX,
       therefore  it should work both on OS/2 and on vanilla DOS systems.
       In  version  1.9.x  and  above  this functionality is preserved in
       newly  added  target EMX, whereas binaries for target OS2 can only
       run  under  real  OS/2. The following notes apply to OS2 target in
       1.0.x and EMX in 1.9.x and above:
          + All  applications generated for the OS/2 (EMX) target require
            the  EMX  0.9d  (or  later) runtime files to run. These files
            should  be  redistributed  with  your software. All the files
            which should be redistributed are included in emxrt.zip
          + Under  OS/2,  LIBPATH  should  be modified to add the EMX DLL
            paths.  Otherwise,  programs will not run and will abort with
            an error 'Cannot find EMX.dll'.
          + The default heap size is 256 Kbytes. Automatic growing of the
            heap is supported.
          + Stack  can  grow  up  to  256  Kbytes by default. This can be
            changed  by  the  user  or  developper  using the emxstack or
            emxbind utilities.
    2. Debugging
       The  GNU  debugger v4.16 (EMX port) has been tested (including its
       PM  add-on,  pmgdb.exe)  and generally works as it should. Because
       the  GNU  debugger  is  C oriented, some pascal types might not be
       represented correctly.
    3. Dynamic libraries
       Even  though  this operating system permits the creation and usage
       of  shared  libraries  (also  called  dynamic link libraries), the
       compiler  currently  only  permits importing routines from dynamic
       libraries (creation of dynamic libraries is unsupported).
    4. Profiling
       Profiling is currently not supported for this platform.
    5. Using DOS generated applications under OS/2
       It   has   been  reported  that  some  DOS  (GO32V2)  applications
       (including the DOS compiler itself) generated by the compiler fail
       on  some  OS/2  installations. This is due to problems in the OS/2
       DPMI server.
       You  should use native OS/2 applications under OS/2 (including the
       native  OS/2 compiler) or try installing a new OS/2 fixpack to see
       if it solves the problem.
    6. INSTALL.EXE  of version 1.0.6 or below fails with an unknown error
       (-1) under OS/2
       or
       INSTALL.EXE  of  version 1.0.6 or above complains about missing TZ
       variable under OS/2
       You  are  most  probably using an older version of OS/2 (like OS/2
       Warp  3.0)  and  don't  have  TZ variable in your environment. The
       easiest   solution   is   to   add   "SET   TZ=..."   (e.g.   "SET
       TZ=CET-1CEST,3,-1,0,7200,10,-1,0,10800,3600"  for  most of western
       and central Europe) line to your CONFIG.SYS, and restart OS/2. The
       proper  setting  for  you  can be found e.g. using the TZCALC tool
       from [112]TIME868 package.
    7. OS/2 compiler not working after upgrading to 1.9.6 or newer
       An  updated  version  of  GNU  assembler (as.exe) is packaged with
       release  1.9.6  (newer  version  was  necessary to get support for
       features of modern CPUs). This version of the GNU tool was created
       with Innotek port of GNU C and relies on its libc. This results in
       higher  limitations  regarding  supported  configurations, because
       this  libc  needs recent version of OS/2 Unicode support libraries
       (LIBUNI.DLL and UCONV.DLL) not available in base OS/2 Warp 3.0 and
       OS/2  Warp  4.0.  The  updated versions were distributed by IBM in
       corrective packages (fixpaks) - see e.g. [113]WarpUpdates site for
       information  about  OS/2  fixpaks  and links for downloading them.
       This  issue  isn't  valid  for  WarpServer for e-Business, MCP and
       eComStation - these already have the correct version.

     BeOS  related  information  The  BeOS  port  is  current  no  longer
   maintained
    1. Releasing software generated by the BeOS compiler
       Software generated for the BeOS target will only work on the intel
       based version of BeOS.
          + The target system must have at least BeOS v4.0 or later (BeOS
            5.1d 'Dano' is not supported)
          + The default heap size is 256 Kbytes. Automatic growing of the
            heap is supported
          + Stack size is set to 256 Kbytes. This cannot be changed
    2. Debugging
       This  operating  system uses DWARF debugging information, and Free
       Pascal  does  not support emitting DWARF debugging information. It
       is currently impossible to debug applications under BeOS
    3. Dynamic libraries
       Even  though  this operating system permits the creation and usage
       of  shared  libraries  (also  called  dynamic link libraries), the
       compiler  currently  only  permits importing routines from dynamic
       libraries (creation of dynamic libraries is unsupported).
    4. Profiling
       Profiling is currently not supported for this platform.
    5. BeOS Linking problems
       It  has  been  reported  that  certain versions of the linker that
       shipped with some versions of BeOS are broken. If you get an error
       when  linking  fpc  applications,  try updating your version of ld
       from the following [114]site.

     Amiga related information
    1. Releasing software generated by the Amiga compiler
          + The target system must have AmigaOS v2.04 or higher
          + The default heap size is 128 Kbytes. Automatic growing of the
            heap is supported.
          + Stack  size  is  not  set  by  the compiler, but by the stack
            command  on  the  CLI.  Because  of this, and because default
            stack  sizes  for this target are small, it is recommended to
            always compile software with stack checking enabled.
          + By  default,  the  compiler  generates  code  for  the 68020+
            processor.  The  code  generated  will  not work on 68000 and
            68010  systems  unless  the  -O0 compiler switch is used, and
            there  is  no  runtime checking. It is up to you to implement
            CPU  verification  at  program  startup. The standard runtime
            libraries have been compiled for the 68000 target, and should
            not cause any problems.
          + All  floating  point  operations  are  simulated, and use the
            single  floating  point  type. You will need to recompile all
            standard  runtime  libraries  and  your application, with the
            software  floating  point  option  off,  if  you  wish to use
            hardware floating point.
    2. Debugging
       Source  level  debugging  is  not  supported for the Amiga target.
       Assembler target debugging is possible though, using the excellent
       Barfly debugger.
    3. Dynamic libraries
       Even  though  this operating system permits the creation and usage
       of  shared  libraries  (also  called  dynamic link libraries), the
       compiler  does  not  support  either  the importing or creation of
       shared libraries. Importing must be done manually in assembler.
    4. Profiling
       Profiling is currently not supported for this platform.

     PalmOS related information
    1. Releasing software generated by the PalmOS compiler
    2. Debugging
    3. Dynamic libraries

References

   1. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#WhatIsFP
   2. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#versions
   3. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#FPandGNUPascal
   4. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#general-license
   5. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#WhereToGetFP
   6. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#general-install
   7. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#ftpproblems
   8. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#general-connectftp
   9. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#ideinst
  10. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#snapshot
  11. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#installsnap
  12. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#KnownBugs
  13. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#HOMEWORK
  14. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#windowsapp
  15. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#game
  16. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#ErrorPos
  17. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#general-heap
  18. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#general-doesntfindfiles
  19. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#binariesbig
  20. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#cfgfiles
  21. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#runerror
  22. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#stdunits
  23. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#internaldocs
  24. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#debugsmart
  25. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#debugshared
  26. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#cantfindunit
  27. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#cantfindunit
  28. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#dotnet
  29. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#PortingCPU
  30. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#PortingOS
  31. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#OOP
  32. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#HowcanIbuildaunit
  33. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#CompileSystemUnit
  34. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#Howdoesfunctionoverloadingwork
  35. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#HowToCallCFuncuntions
  36. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#IntegratedAssemblerSyntax
  37. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#systemnotfound
  38. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#extensionselect
  39. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#HowToUseGraph
  40. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#WrongColors
  41. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#fileshare
  42. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#filebig
  43. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#filemode
  44. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#TurboVision
  45. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#dos-release
  46. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#dos-debugging
  47. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#dos-dll
  48. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#dos-profile
  49. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#FPwithoutfpu
  50. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#fp386
  51. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#nomousegraph
  52. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#accessioports
  53. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#HowToAccessDosMemory
  54. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#dos-stack
  55. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#dos-os2
  56. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#win-release
  57. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#win-debugging
  58. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#win-dll
  59. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#win-profile
  60. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#win-graph
  61. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#win-cygwin
  62. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#win-makefile
  63. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#win95-fpc
  64. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#win-os2
  65. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#win-dos
  66. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#win-ide-mouse
  67. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#instal106win32
  68. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#unix-release
  69. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#unix-debugging
  70. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#unix-dll
  71. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#unix-profile
  72. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#vgamissing
  73. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#unix-asldmissing
  74. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#os2-release
  75. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#os2-debugging
  76. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#os2-dll
  77. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#os2-profile
  78. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#os2-dos
  79. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#instal106os2
  80. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#instal106os2
  81. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#os2-fp
  82. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#beos-release
  83. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#beos-debugging
  84. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#beos-dll
  85. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#beos-profile
  86. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#beos-linking
  87. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#amiga-release
  88. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#amiga-debugging
  89. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#amiga-dll
  90. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#amiga-profile
  91. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#palmos-release
  92. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#palmos-debugging
  93. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#palmos-dll
  94. http://www.freepascal.org/download.html
  95. http://www.freepascal.org/develop.html#snapshot
  96. http://www.freepascal.org/bugs.html
  97. http://www.lazarus.freepascal.org/
  98. http://www.pascalgamedevelopment.com/
  99. http://www.delphi-jedi.org/Jedi:TEAM%C2%A0SDL%C2%A0HOME
 100. http://ptcpas.sourceforge.net/
 101. http://thesheepkiller.sourceforge.net/
 102. http://upx.sourceforge.net/
 103. http://hobbes.nmsu.edu/
 104. http://www.stack.nl/~marcov/buildfaq.pdf
 105. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#snapshot
 106. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#fp386
 107. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#dos-stack
 108. ftp://ftp.logitech.com/pub/techsupport/mouse/m643%C2%A0w31.exe
 109. ftp://ftp.freepascal.org/pub/fpc/olddist/1.0.10/win32-1.0.10/separate/makew32.zip
 110. ftp://ftp.freepascal.org/pub/fpc/contrib/utils/win32/makent.zip
 111. file://localhost/I:/DEV/SNAPSHOT/SVN/FPC/INSTALL/DOC/faq.htm#dos-os2
 112. http://hobbes.nmsu.edu/pub/os2/apps/internet/time/time868f.zip
 113. http://www.warpupdates.mynetcologne.de/english/basesystem.html
 114. http://open-beos.sourceforge.net/dev.php
