                             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. 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]I want a new version NOW
        10. [10]Installing a snapshot
        11. [11]I have to write a program for homework. Can you help?
        12. [12]How do I make a real Windows application with windows and
            menu bars?
        13. [13]How  do I make a game with Free Pascal? Can I make a game
            like Doom 3?
        14. [14]Getting more information when an application crashes
        15. [15]Increasing the heap size
        16. [16]Compiler seems to skip files in directories -Fu points to
        17. [17]Why are the generated binaries so big?
        18. [18]Configuration file problems (fpc.cfg or ppc386.cfg)
        19. [19]Runtime errors
        20. [20]Standard units
        21. [21]How does the compiler work internally?
        22. [22]Debugging smartlinked code does not fully work
        23. [23]Debugging  shared  library  (dynamic linked library) code
            does not fully work
        24. [24]PPU files binary compatibility between versions
        25. [25]Can't  compile a program using a binary only version of a
            unit
        26. [26]Will you support ISO Extended Pascal?
        27. [27]What about .NET?
    2. Pascal language related information
         1. [28]Considerations in porting code to other processors
         2. [29]Considerations in porting code to other operating systems
         3. [30]Compiling Delphi code using Free Pascal
         4. [31]Building a unit
         5. [32]Compiling the system unit
         6. [33]How does function overloading work?
         7. [34]Calling C functions
         8. [35]Integrated Assembler syntax
         9. [36]Unit system not found errors
        10. [37]There is a new extension that will be really useful. Will
            you include it?
    3. Runtime library related information
         1. [38]Using the graph unit with Free Pascal
         2. [39]Why do I get wrong colors when using the graph unit?
         3. [40]File sharing and file locks
         4. [41]File denied errors when opening files with reset
    4. DOS related information
         1. [42]Releasing software generated by the DOS compiler
         2. [43]Debugging
         3. [44]Dynamic libraries
         4. [45]Profiling
         5. [46]Running Free Pascal without a math coprocessor
         6. [47]Applications  created  with  Free  Pascal  crash on 80386
            systems
         7. [48]The mouse cursor is not visible in graphics screens
         8. [49]Accessing I/O ports
         9. [50]Accessing DOS memory / Doing graphics programming
        10. [51]Changing the default stack size
        11. [52]Using OS/2 generated applications under DOS
    5. Windows related information
         1. [53]Releasing software generated by the windows compiler
         2. [54]Debugging
         3. [55]Dynamic libraries
         4. [56]Profiling
         5. [57]Graph  and  problems  with keyboard, mouse and "dummy dos
            windows"
         6. [58]Cygwin  binary  directory  in  your path sometimes causes
            builds to fail
         7. [59]Using the DOS compiler under Windows 95
         8. [60]Using OS/2 generated applications under Windows
         9. [61]Using DOS generated applications under windows
        10. [62]The mouse cursor does not respond in the Windows IDE
    6. UNIX related information
         1. [63]Releasing software generated by the unix compilers
         2. [64]Debugging
         3. [65]Dynamic libraries
         4. [66]Profiling
         5. [67]Libc is missing on platforms other than i386
         6. [68]Why can't the linker find "vga"?
         7. [69]Compiler indicates missing as and ld
    7. OS/2 related information
         1. [70]Releasing software generated by the OS/2 compiler
         2. [71]Debugging
         3. [72]Dynamic libraries
         4. [73]Profiling
         5. [74]Using DOS generated applications under OS/2
         6. [75]INSTALL.EXE  of version 1.0.6 or below returns an unknown
            error (-1) under OS/2
            or
            [76]INSTALL.EXE  of  version  1.0.6  or above complains about
            missing TZ variable under OS/2
         7. [77]OS/2  compiler  not  working  after upgrading to 1.9.6 or
            newer
         8. [78]Compilation  under  OS/2 fails with error "Can't call the
            assembler"
    8. BeOS related information
         1. [79]Releasing software generated by the BeOS compiler
         2. [80]Debugging
         3. [81]Dynamic libraries
         4. [82]Profiling
         5. [83]BeOS linking problems
    9. Amiga related information
         1. [84]Releasing software generated by the Amiga compiler
         2. [85]Debugging
         3. [86]Dynamic libraries
         4. [87]Profiling
   10. PalmOS related information
         1. [88]Releasing software generated by the PalmOS compiler
         2. [89]Debugging
         3. [90]Dynamic libraries

    1. General information
         1. What is Free Pascal (FPC)?
            Originally named FPK-Pascal, the Free Pascal compiler is a 32
            and 64 bit Turbo Pascal and Delphi compatible Pascal compiler
            for  DOS, Linux, Win32, OS/2, FreeBSD, AmigaOS, Mac OS X, Mac
            OS  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.
            Short history:
               o 06/1993: project start
               o 10/1993: first little programs work
               o 03/1995: the compiler compiles the own sources
               o 03/1996: released to the internet
               o 07/2000: 1.0 version
               o 12/2000: 1.0.4 version
               o 04/2002: 1.0.6 version
               o 07/2003: 1.0.10 version
               o 05/2005: 2.0.0 version
               o 12/2005: 2.0.2 version
               o 08/2006: 2.0.4 version
               o 09/2007: 2.2.0 version
               o 08/2008: 2.2.2 version
         2. Which versions exist, and which one should I use?
            The  latest  official  version  is  2.2.2, bugfix release for
            2.2.0.  New  development  is performed in 2.3.x series, which
            eventually gets released as either 2.4.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.
            Pre  1.0  versioning  moved  to  the  [91]Wiki 1.0 versioning
            article.
            Modern versioning
            Together  with  the  release of 1.0 the version numbering was
            slightly  changed,  and a system in versioning resembling the
            Linux kernels has been introduced.
               o Releases  that only fix bugs in version 1.0 are numbered
                 1.0.x.
               o Post  1.0  development  (the  so  called snapshots) have
                 version number 1.1.x.
               o Eventually  the  1.1.x  versions,  when  stabilized were
                 released  as  the 2.0.x series, preceded by betas marked
                 as  1.9.x.  Fixes  on  2.0  release were numbered 2.0.x,
                 fixes on 2.2 release 2.2.x.
               o The  new development after the 2.2.0 release is numbered
                 2.3.x and so on.
               o Repackagings  that  affect  sources are indicated with a
                 single  letter  as suffix (e.g. 2.0.4a), this is usually
                 the case for platforms that weren't part of the original
                 release round.
            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 new stable 2.2.x series).
            A  graphical timeline of the FPC project plus its near future
            would be: [timeline.png]
         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.2.2 (August
                      2008).  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  SVN.  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)
                      on   some   platforms,   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 Klmpfl, 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:
               o 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.
               o If  you  made  modifications to the runtime library, you
                 cannot  keep  them  for  yourself,  you  must  make them
                 available if requested.
               o 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 all [92]official mirrors
         6. Free Pascal installation hints
               o 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. I want a new version NOW 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.
            The  latest  snapshot  can  always  be  downloaded  from  the
            [93]development web page.
        10. 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"
            (InfoZIP  unzip doesn't require any special parameters). 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.
        11. 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.
        12. How  do  I  make  a real Windows application with windows and
            menu  bars?  The  easiest  way is to [94]download Lazarus. It
            won't  be just a Windows application, it will also work under
            Linux, FreeBSD and Mac OS X.
        13. 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 [95]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 [96]JEDI-SDL or
            [97]PTCPas.  Also  you can try to study an existing game, for
            example  [98]The  Sheep  Killer  is a very simple game and it
            should not be very hard to understand its code.
        14. 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:
                    # Under  UNIX  systems  (Linux, the BSD's), don't add
                      the ".exe" after myprog
                    # "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
        15. 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.
        16. 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
        17. 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
                 [99]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  issue 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
                 [100]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  Windows  NT/2k/XP/Vista,
                 compressed  binaries startup relatively slow. Test under
                 various  conditions  (OS,  CPU  speed,  memory)  if  the
                 behaviour is acceptable before compressing
            Generally  Free Pascal generates smaller binaries than modern
            competing  compilers,  however, it doesn't hide code in large
            dynamic libraries. Free Pascal generates larger binaries than
            compilers  from long ago do. Large framework libraries result
            in  larger  executables.  See also the [101]Size Matters wiki
            entry.
        18. Configuration file problems (fpc.cfg or ppc386.cfg)
            Starting from version 1.0.6 of Free Pascal, the configuration
            file  is  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.
            Since  1.0.6  is now over 5 years old, the ppc386.cfg support
            will be phased out. 2.2.2 will warn, and 2.4.0 will no longer
            search ppc386.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.
        19. 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 $00010F86
              $00010F86  main,  line 7 of testr.pas
              $0000206D

            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.
        20. 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.
        21. 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.
        22. 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.
        23. 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.
        24. Will you support ISO Extended Pascal? We are open for support
            for ISO Extended Pascal, but the Free Pascal development team
            does  not  consider  extended Pascal compatibility important,
            and  therefore  will not spend time on it. The reason is that
            the ISO Extended Pascal must be considered a failed standard.
            To  explain  the  reasons for this, we need to go back to the
            1970's.  At that time a specific Pascal compiler got popular,
            UCSD-Pascal,  its  ability  to  allow programs written on one
            architecture  to run on another played an important factor in
            this.  All  major Pascal compilers derive their language from
            the  UCSD-Pascal  compiler,  including the well known Borland
            and Mac-Pascal dialects.
            UCSD-Pascal   introduced  the  unit  system  and  the  string
            variables  we  all  know  very  well. The ISO Extended Pascal
            language  is  mutually exclusive with both of these features;
            ISO  Extended  Pascal  both has a completely different system
            for modular programming, as that its string system is totally
            different from the UCSD model. In short it is not possible to
            support both dialects at the same time.
            Because  of  this,  the software industry could not switch to
            ISO  Extended  Pascal without breaking compatibility with all
            source   code.  Because  of  this,  very  few  compilers  did
            implement ISO Extended Pascal. Compilers that did were mostly
            unpopular.
            Nowadays,  there  exists  very  little  code  written  in ISO
            Extended  Pascal.  While  Free  Pascal could support it using
            another  compiler  mode,  there is little point spending time
            making  a  compiler  for  which  no source exists that it can
            compile.
            GNU-Pascal is a modern compiler that can compile ISO Extended
            Pascal.  If  you  have  any  need for the ISO Extended Pascal
            dialect, we recommend to take a look at this compiler.
        25. 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,  and  they  think  windows  programming won't be
            possible in the future.
            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. Pascal  is  a  language that uses pointers, and existing
                 codebases  can  only be unmanaged. Unmanaged code is not
                 portable under .NET, so that already kills most possible
                 benefits.  This  also means that existing FPC and Delphi
                 code  won't  run  on  .NET.  There  are more such little
                 language problems.
              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 program will be. Little experiments with
                 hello  world  level code mean nothing, that kind of code
                 works  with  plain  C  too.  A good test would be to see
                 existing  non  trivial  codebases  run  unmodified under
                 mono. Just like we try to do for Delphi
              4. The  fact  that on Windows 80% of the .NET code seems to
                 be  ASP.NET  doesn't  help  either.  This  makes porting
                 existing  code  less  useful  (since  ASP.NET is tied to
                 IIS),  and  new codebases of portable code can be set in
                 nearly every language
              5. 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  compatibility.  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.
    2. 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.
               o Limit  your  use  of  asm  statements  unless it is time
                 critical code
               o 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.
               o Try limiting your local variables in subroutines to 32K,
                 as  this  is  the  limit of some processors, use dynamic
                 allocation instead.
               o 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.
               o 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.
               o Use  the  ptruint  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.
               o 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.
               o 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.
               o 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.
               o Do  not  hard  code  paths to files, try to use relative
                 paths instead
               o Use the following constants (defined in the system unit)
                 to  get information on files, line endings, and to build
                 paths:
                    # LineEnding  :  Indicates the characters which end a
                      text line
                    # LFNSupport   :  Indicates  if  long  filenames  are
                      supported (more then 8.3 characters)
                    # DirectorySeparator  :  The  character or characters
                      which separate path components
                    # DriveSeparator  :  The character which separate the
                      drive specification from the rest of the path
                    # PathSeparator   :  The  character  which  separates
                      directories in the search path environment
                    # FileNameCaseSensitive  :  Boolean indicating if the
                      filenames for this system are case-sensitive or not
                    # AllFilesMask   :   String   containing  a  wildcard
                      expression for all files
                 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 incompatibilities 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 procedure overloading work?
            Here is a procedure overloading example:
                    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.
            Since  version  1.9.2,  the  compiler  also uses the register
            calling  convention,  which  means  the compiler can assemble
            assembler    routines   in   Delphi   source   code   without
            modification.
            A  description  of  the  AT&T  syntax can be found in the GNU
            Assembler documentation.
         9. Unit system 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 [102]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 [103]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. Compatibility  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
                 compatibility 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
               o Explanation of the feature
               o Why it is needed, what does it make possible?
               o How you would implement it?
               o 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.
    3. 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 colours 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):
               o 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.
               o 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 :
               o UNIX systems : There is no verification at all.
               o Windows : An access denied error will be reported.
               o Amiga : An access denied error will be reported.
               o 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:
               o Use  specific  operating  system  calls  (such  as  file
                 locking  on  UNIX  and Amiga systems) to get the correct
                 behavior.
               o 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. 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
    4. DOS related information
         1. Releasing software generated by the DOS compiler
               o If  your program uses floating point code (which is very
                 probable),  make sure to read "[104]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)
               o The  target  system  must  have  a DPMI server. To avoid
                 problems,   the   file   cwsdpmi.exe  should  always  be
                 redistributed with your application
               o The target system must have DOS 3.3 or later
               o The  default heap size is 2 Megabytes. Automatic growing
                 of the heap is supported
               o The   default   stack  size  is  256  Kbytes.  See  also
                 "[105]Changing the default stack size"
               o 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 the text mode IDE instead of
            GDB, which is 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
               o 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. .
               o 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 [106]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.
    5. 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:
               o 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).
               o Stack size is unlimited
               o 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 the text mode IDE instead of
            GDB, which is 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:
               o 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:
               o Use units WinMouse and WinCrt instead.
            Problem:
               o 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:
               o 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. 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).
         8. 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 [107]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.
         9. 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  or the Go32 extender). 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.
        10. 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.
    6. 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
               o 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.
               o There is no stack space usage limit.
               o Under Solaris and QNX, stack checking is simulated.
               o Minimal operating system versions :
                    # Linux : Kernel v2.4.x or later.
                    # FreeBSD : version 5.x or later. (4.x can be made to
                      work with minor work)
                    # NetBSD : version 1.5 or later.
                    # Solaris  :  version  5.7  of SunOS or later (should
                      work with earlier versions, but untested).
                    # Qnx  :  version  6.1.0  or  later (should work with
                      earlier versions, but untested).
                    # Mac OS X : version 10.3.9 or later
         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)  SVN  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. Libc is missing on platforms other than Linux/i386
            Libc  is a Kylix compatibility unit. Because it contains many
            i386  specific  code  and  features  structures  from  legacy
            kernels, it has not been made available on other platforms.
            To  access Unix functionality, please use units like baseunix
            and unix.
         6. Why can't the linker find "vga"?
            This error typically looks like this:
                 Free Pascal Compiler version 2.2.x [xxxx/yy/zz] for i386
                 Copyright (c) 1993-2008 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
         7. 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.
    7. 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:
               o 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
               o 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'.
               o The  default  heap size is 256 Kbytes. Automatic growing
                 of the heap is supported.
               o 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 [108]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.  [109]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.
         8. Compilation  under  OS/2  fails  with  error  "Can't call the
            assembler"
            Apart  from the point mentioned [110]above, there is at least
            one  more  potential  reason  for  issues  with executing the
            assembler  and  resulting  in  error  message "Can't call the
            assembler,  error  2  switching to external assembling". This
            error may be result of the OS/2 system not being able to find
            DLLs required for the assembler. Make sure that you installed
            FPC  completely (these DLLs are part of file asldos2.zip) and
            that  you  have  set  LIBPATH  according  to  instructions in
            README.TXT (and restarted afterwards).
    8. 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.
               o The  target system must have at least BeOS v4.0 or later
                 (BeOS 5.1d 'Dano' is not supported)
               o The  default  heap size is 256 Kbytes. Automatic growing
                 of the heap is supported
               o 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 [111]site.
    9. Amiga related information
         1. Releasing software generated by the Amiga compiler
               o The target system must have AmigaOS v2.04 or higher
               o The  default  heap size is 128 Kbytes. Automatic growing
                 of the heap is supported.
               o 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.
               o 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.
               o 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.
   10. PalmOS related information
         1. Releasing software generated by the PalmOS compiler
         2. Debugging
         3. Dynamic libraries

References

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