2
2
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
3
3
"http://www.w3.org/TR/REC-html40/loose.dtd">
5
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
5
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
6
6
<META NAME="Author" CONTENT="Free Pascal Web Team">
7
<META name="description" content="Free Pascal: free 32-bit Pascal compiler for DOS, Linux, Win32 and OS/2">
8
<META NAME="keywords" content="32 bit, protected mode, compiler, pascal, FPC, FPC Pascal, Free Pascal">
9
<TITLE>Free Pascal - FAQ</TITLE>
7
<META name="description" content="Free Pascal: free 32-bit and 64-bit Pascal compiler supporting many platforms on several architectures">
8
<META NAME="keywords" content="32 bit, 64 bit, protected mode, compiler, pascal, FPC, FPC Pascal, Free Pascal">
9
<title>Free Pascal - FAQ</title>
11
11
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#FF8080">
14
<LI><A HREF="#WhatIsFP">What is Free Pascal (FPC)?</A></LI>
15
<LI><A HREF="#versions">Which versions exist, and which one should I use?</A></LI>
16
<LI><A HREF="#FPandGNUPascal">Free Pascal and GNU Pascal - a comparison</A></LI>
17
<LI><A HREF="#WhereToGetFP">Where can I get the compiler ?</A></LI>
18
<LI><A HREF="#PortabilityTips">What are the considerations in porting</A></LI>
19
<LI><A HREF="#OOP">I tried to compile my Delphi code with the Free Pascal</A></LI>
20
<LI><A HREF="#HOMEWORK">I have to write a program for homework. Can you help?</A></LI>
21
<LI><A HREF="#HowcanIbuildaunit">How can I build a unit?</A></LI>
22
<LI><A HREF="#TurboVision">Will Free Pascal support TV (Turbo Vision) in the future?</A></LI>
23
<LI><A HREF="#CompileSystemUnit">How can I compile the system unit?</A></LI>
24
<LI><A HREF="#Internalerror9999">I get an internal error 9999 or 10?</A></LI>
25
<LI><A HREF="#Howdoesfunctionoverloadingwork">How does function overloading work?</A></LI>
26
<LI><A HREF="#HowToCallCFuncuntions">How can I call C functions?</A></LI>
27
<LI><A HREF="#HowToUseGraph">How can I use the graph unit with Free Pascal?</A></LI>
28
<LI><A HREF="#WrongColors">Why do I get wrong colors when using the graph unit?</A></LI>
29
<LI><A HREF="#IntegratedAssemblerSyntax">Integrated Assembler syntax</A></LI>
30
<LI><A HREF="#HowToAccessDosMemory">How can I access DOS memory / How can I do graphics programming?</A></LI>
31
<LI><A HREF="#FPwithoutfpu">How can I run Free Pascal without a math coprocessor?</A></LI>
32
<LI><A HREF="#AccessingMoreThan4MB">How do I reserve more than 2 megabytes of RAM?</A></LI>
33
<LI><A HREF="#accessioports">How can I access I/O ports?</A></LI>
34
<LI><A HREF="#ImusingWin95">I'm using the Dos compiler under Windows 95</A></LI>
35
<LI><A HREF="#ImusingOS2">I'm using OS/2</A></LI>
36
<LI><A HREF="#dpmi">INSTALL.EXE of Dos version 0.99.10 reports "Load error: no DPMI"</A></LI>
37
<LI><A HREF="#instal10NT">INSTALL.EXE of version 1.0 for Dos returns an error (-2) in Windows NT 4.0</A></LI>
38
<LI><A HREF="#instal106os2">INSTALL.EXE of version 1.0.6 or below returns an unknown error (-1) under OS/2</A>
40
<A HREF="#instal106os2">INSTALL.EXE of version 1.0.6 or above complains about missing TZ variable under OS/2</A></LI>
41
<LI><A HREF="#snapshot">I want a new version NOW</A></LI>
42
<LI><A HREF="#ideinst">Where can I find a text mode IDE?</A></LI>
43
<LI><A HREF="#ideconfig">How do I configure the Dos IDE?</A></LI>
44
<LI><A HREF="#binariesbig">Why are the generated binaries so big?</A></LI>
45
<LI><A HREF="#systemnotfound">Unit system, syslinux, sysos2 or syswin32 not found errors</A></LI>
46
<LI><A HREF="#KnownBugs">Known bugs</A></LI>
47
<LI><A HREF="#ErrorPos">How can I find where an error occurred using the addresses a crashed program prints?</A></LI>
51
<LI><A NAME="WhatIsFP"></A><H3>What is Free Pascal (FPC)?</H3>
53
Originally named FPK-Pascal, the Free Pascal compiler is a 32 bit Turbo
54
Pascal compatible Pascal compiler for DOS, Linux, Win32, OS/2 and (based on
55
an older version) the AmigaOS. More operating systems (BeOS and FreeBSD/ELF are in
56
advanced stages of development) are in the works.
59
The compiler is written in Pascal and is able to compile its own sources.
60
The source files are included.
63
Free Pascal is modest regarding its minimal system requirements (386-25 Mhz for
64
the Intel version and ideally a 68020 processor for the Motorola
65
version). At least 2 megabytes of RAM are required. To remake the compiler
66
more than 16MB is recommended.
71
<LI>6/1993: project start
72
<LI>10/1993: first little programs work
73
<LI>3/1995: the compiler compiles the own sources
74
<LI>3/1996: released to the internet
75
<LI>7/2000: 1.0 version
78
<LI><A NAME="versions"></A><H3>Which versions exist, and which one should I use?</H3>
80
FPC's version numbering changed a few times over the years. Versions before 0.99.5 are considered archaic.
81
After the release of 0.99.5 a system in version numbering was introduced, and that system was changed slightly changed after the
84
<b>Versioning for versions 0.99.5 - 1.0</b>
86
Compilers with an <b>even</b> last number are <b>release</b> versions(e.g. 0.99.8, 0.99.10, 0.99.12, 0.99.14 1.0.0)<br>
87
Compilers and packages with an <b>odd</b> last number are <b>development</b> versions (e.g. 0.99.9, 0.99.11, 0.99.13, 0.99.15)
90
0.99.5 is an exception to this rule, since <b>0.99.5 IS a release</b> (a release prior to the introduction of this odd/even system).
93
Letters behind the version number (0.99.12b, 0.99.5d) indicate release versions with some bugs and problems in the original release
94
(respectively 0.99.12 and 0.99.5) fixed.
97
<b>Versioning after 1.0</b>
100
Together with the release of 1.0 the version numbering has been slightly changed,
101
and a system in versioning resembling the Linux kernel's has been introduced.
102
The main difference is that the difference between a release version is now in the
103
second number (1.0.x vs 1.1.x) instead of the third number (0.99.14 vs 0.99.15), and
104
the third number now becomes the patch level, replacing the postfixed letter in the old system.
108
<li>Releases that only fix bugs in version 1.0 will be numbered 1.0.x</li>
109
<li>New development (the so called snapshots) have version number 1.1.x. The meaning
110
of the third version number x in the new development branch is not defined yet, it could be used for test releases or to signal major changes. </li>
111
<li>Eventually the 1.1.x versions, when stabilized will be released as version 1.2. Fixes on the 1.2 release will be numbered 1.2.x</lI>
112
<li>The new development after the 1.2 release will be numbered 1.3.x and so on</li>
113
<li>When really big changes are implemented, the version will be updated in the major number. This could be case with
114
e.g. a codegenerator rewrite with support for other processors</li>
118
Normally you would want to use a release. Releases are considered stable, and
119
easier to support (the bugs, quirks and unintended "features" are well
120
known after a period of time, and workarounds exist).
123
Development snapshots (which are generated daily) reflect the current status of the compiler.
124
Development versions probably have new features and larger bugs fixed since the last release,
125
but might have some temporary stability drawbacks (which are usually fixed by the next day).
128
Most support for development snapshots are basically the advise to
129
upgrade to newer snapshot in which the bugs are hopefully fixed.
130
Since version 0.99.8 the stability of the compiler steadily increased
131
and development snapshots are often quite useful for certain categories of users. Ask in the maillists if it
132
is worth the trouble in your case if you're not sure.
135
<b>The current release version is 1.00</b> for the OS/2, Linux, Windows and Dos (Go32V2) targets and 0.99.5d for the 680x0 based systems (Amiga and Atari ST).
136
The development versions (snapshots) are numbered 1.1.x at the moment</b>
139
We advise all users to upgrade to the newest version for their target. (1.0 for intel processors, and 0.99.5d for Motorola)
141
<LI><A NAME="FPandGNUPascal"></A><H3>Free Pascal and GNU Pascal - a comparison</H3>
12
<h1>FAQ / Knowledge base</h1>
14
<p>This document gives last minute information regarding the compiler. Furthermore,
15
it answers frequently asked questions and gives solutions to common problems
16
found with Free Pascal. The information presented herein always supersedes those
17
found in the Free Pascal documentation. </p>
18
<p> For more comprehensive information on the pascal language, and the runtime library
19
calls, consult the Free Pascal manuals and our Wiki. Topics covered in this document: </p>
21
<li> General information </li>
23
<li><a href="#WhatIsFP">What is Free Pascal (FPC)?</a></li>
24
<li><a href="#versions">Which versions exist, and which one should I use?</a></li>
25
<li><a href="#FPandGNUPascal">Free Pascal and GNU Pascal - a comparison</a></li>
26
<li><a href="#general-license">License and copyright information</a></li>
27
<li><a href="#WhereToGetFP">Getting the compiler</a></li>
28
<li><a href="#general-install">Free Pascal installation hints</a></li>
29
<li><a href="#ftpproblems"> Why do i have to supply a user name and password to get Free Pascal ?</a></li>
30
<li><a href="#general-connectftp"> Access denied error when connecting to the Free Pascal FTP site</a></li>
31
<li><a href="#ideinst">Where can I find a text mode IDE?</a></li>
32
<li><a href="#snapshot">I want a new version NOW</a></li>
33
<li><a href="#installsnap"> Installing a snapshot</a></li>
34
<li><a href="#KnownBugs">Known bugs / Reporting bugs</a></li>
35
<li><a href="#HOMEWORK">I have to write a program for homework. Can you help?</a></li>
36
<li><a href="#windowsapp">How do I make a real Windows application with windows and menu bars?</a></li>
37
<li><a href="#game">How do I make a game with Free Pascal? Can I make a game like Doom 3?</a></li>
38
<li><a href="#ErrorPos">Getting more information when an application crashes</a></li>
39
<li><a href="#general-heap">Increasing the heap size</a></li>
40
<li><a href="#general-doesntfindfiles">Compiler seems to skip files in directories -Fu points to</a></li>
41
<li><a href="#binariesbig">Why are the generated binaries so big?</a></li>
42
<li><a href="#cfgfiles">Configuration file problems (fpc.cfg or ppc386.cfg)</a></li>
43
<li><a href="#runerror">Runtime errors</a></li>
44
<li><a href="#stdunits">Standard units</a></li>
45
<li><a href="#internaldocs">How does the compiler work internally?</a></li>
46
<li><a href="#debugsmart">Debugging smartlinked code does not fully work</a></li>
47
<li><a href="#debugshared">Debugging shared library (dynamic linked library) code does not fully work</a></li>
48
<li><a href="#cantfindunit">PPU files binary compatibility between versions</a></li>
49
<li><a href="#cantfindunit">Can't compile a program using a binary only version of a unit</a></li>
50
<li><a href="#dotnet">What about .NET?</a></li>
52
<li> Pascal language related information </li>
54
<li><a href="#PortingCPU">Considerations in porting code to other processors</a></li>
55
<li><a href="#PortingOS">Considerations in porting code to other operating systems</a></li>
56
<li><a href="#OOP">Compiling Delphi code using Free Pascal</a></li>
57
<li><a href="#HowcanIbuildaunit">Building a unit</a></li>
58
<li><a href="#CompileSystemUnit">Compiling the system unit</a></li>
59
<li><a href="#Howdoesfunctionoverloadingwork">How does function overloading work?</a></li>
60
<li><a href="#HowToCallCFuncuntions">Calling C functions</a></li>
61
<li><a href="#IntegratedAssemblerSyntax">Integrated Assembler syntax</a></li>
62
<li><a href="#systemnotfound">Unit system, syslinux, sysos2 or syswin32 not found errors</a></li>
63
<li><a href="#extensionselect">There is a new extension that will be really useful. Will you include it?</a></li>
65
<li> Runtime library related information </li>
67
<li><a href="#HowToUseGraph">Using the graph unit with Free Pascal</a></li>
68
<li><a href="#WrongColors">Why do I get wrong colors when using the graph unit?</a></li>
69
<li><a href="#fileshare"> File sharing and file locks </a></li>
70
<li><a href="#filebig"> Accessing huge files using standard I/O routines </a></li>
71
<li><a href="#filemode">File denied errors when opening files with reset </a></li>
72
<li><a href="#TurboVision">Turbo Vision libraries</a></li>
74
<li> DOS related information </li>
76
<li><a href="#dos-release">Releasing software generated by the DOS compiler</a></li>
77
<li><a href="#dos-debugging">Debugging</a></li>
78
<li><a href="#dos-dll">Dynamic libraries</a></li>
79
<li><a href="#dos-profile">Profiling</a></li>
80
<li><a href="#FPwithoutfpu">Running Free Pascal without a math coprocessor</a></li>
81
<li><a href="#fp386">Applications created with Free Pascal crash on 80386 systems</a></li>
82
<li><a href="#nomousegraph">The mouse cursor is not visible in graphics screens</a></li>
83
<li><a href="#accessioports">Accessing I/O ports</a></li>
84
<li><a href="#HowToAccessDosMemory">Accessing DOS memory / Doing graphics programming</a></li>
85
<li><a href="#dos-stack">Changing the default stack size</a></li>
86
<li><a href="#dos-os2">Using OS/2 generated applications under DOS</a></li>
88
<li> Windows related information </li>
90
<li><a href="#win-release">Releasing software generated by the windows compiler</a></li>
91
<li><a href="#win-debugging">Debugging</a></li>
92
<li><a href="#win-dll">Dynamic libraries</a></li>
93
<li><a href="#win-profile">Profiling</a></li>
94
<li><a href="#win-graph">Graph and problems with keyboard, mouse and "dummy dos windows"</a></li>
95
<li><a href="#win-cygwin">Cygwin binary directory in your path sometimes causes builds to fail</a></li>
96
<li><a href="#win-makefile">Makefile problems on Win2000 (and NT)</a></li>
97
<li><a href="#win95-fpc">Using the DOS compiler under Windows 95</a></li>
98
<li><a href="#win-os2">Using OS/2 generated applications under Windows</a></li>
99
<li><a href="#win-dos">Using DOS generated applications under windows</a></li>
100
<li><a href="#win-ide-mouse">The mouse cursor does not respond in the Windows IDE</a></li>
101
<li><a href="#instal106win32">INSTALL.EXE of version 1.0.6 returns errors under some version of Windows</a>
103
<li> UNIX related information </li>
105
<li><a href="#unix-release">Releasing software generated by the unix compilers</a></li>
106
<li><a href="#unix-debugging">Debugging</a></li>
107
<li><a href="#unix-dll">Dynamic libraries</a></li>
108
<li><a href="#unix-profile">Profiling</a></li>
109
<li><a href="#vgamissing">Why can't the linker find "vga"?</a></li>
110
<li><a href="#unix-asldmissing">Compiler indicates missing as and ld</a></li>
112
<li> OS/2 related information </li>
114
<li><a href="#os2-release">Releasing software generated by the OS/2 compiler</a></li>
115
<li><a href="#os2-debugging">Debugging</a></li>
116
<li><a href="#os2-dll">Dynamic libraries</a></li>
117
<li><a href="#os2-profile">Profiling</a></li>
118
<li><a href="#os2-dos">Using DOS generated applications under OS/2</a></li>
119
<li><a href="#instal106os2">INSTALL.EXE of version 1.0.6 or below returns an unknown error (-1) under OS/2</a>
121
<a href="#instal106os2">INSTALL.EXE of version 1.0.6 or above complains about missing TZ variable under OS/2</a></li>
122
<li><a href="#os2-fp">OS/2 compiler not working after upgrading to 1.9.6 or newer</a></li>
124
<li> BeOS related information </li>
126
<li><a href="#beos-release">Releasing software generated by the BeOS compiler</a></li>
127
<li><a href="#beos-debugging">Debugging</a></li>
128
<li><a href="#beos-dll">Dynamic libraries</a></li>
129
<li><a href="#beos-profile">Profiling</a></li>
130
<li><a href="#beos-linking">BeOS linking problems</a></li>
132
<li> Amiga related information </li>
134
<li><a href="#amiga-release">Releasing software generated by the Amiga compiler</a></li>
135
<li><a href="#amiga-debugging">Debugging</a></li>
136
<li><a href="#amiga-dll">Dynamic libraries</a></li>
137
<li><a href="#amiga-profile">Profiling</a></li>
139
<li> PalmOS related information </li>
141
<li><a href="#palmos-release">Releasing software generated by the PalmOS compiler</a></li>
142
<li><a href="#palmos-debugging">Debugging</a></li>
143
<li><a href="#palmos-dll">Dynamic libraries</a></li>
148
<h2><li> General information </li></h2>
150
<li><a name=WhatIsFP></a>
151
<h3>What is Free Pascal (FPC)?</h3>
152
<p>Originally named FPK-Pascal, the Free Pascal compiler is a 32
153
bit Turbo Pascal and Delphi compatible Pascal compiler for DOS,
154
Linux, Win32, OS/2, FreeBSD, AmigaOS, MacOSX, MacOS classic and
155
several other platforms (the number of supported targets grows
156
all the time, although not all of them are on the same level as
159
<p>The Free Pascal compiler is available for several
160
architectures, x86, Sparc (v8,v9), ARM, x86 64 (AMD64/Opteron)
161
and Powerpc. An older version (the 1.0 series) also supports
164
<p>The compiler is written in Pascal and is able to compile its
165
own sources. The source files are under GPL and included.</p>
166
<p> Free Pascal is modest regarding its minimal system
167
requirements (386-25 Mhz for the Intel version and ideally a
168
68020 processor for the Motorola version. FPU emulation required).
169
At least 2 megabytes of RAM are required. To remake the compiler
170
more than 32-64MB is recommended, less for 1.0.x versions. </p>
173
<li>06/1993: project start</li>
174
<li>10/1993: first little programs work</li>
175
<li>03/1995: the compiler compiles the own sources</li>
176
<li>03/1996: released to the internet</li>
177
<li>07/2000: 1.0 version</li>
178
<li>12/2000: 1.0.4 version</li>
179
<li>04/2002: 1.0.6 version</li>
180
<li>07/2003: 1.0.10 version</li>
181
<li>05/2005: 2.0 </li>
184
<li><a name=versions></a>
185
<h3>Which versions exist, and which one should I use?</h3>
186
<p>The latest official version is 2.0.4, released as a bug fix release for
187
2.0.x series. New development is performed in 2.1.x series, which eventually
188
gets released as either 2.2.0, or 3.0.0 (depending on amount of accumulated
189
changes at the time of release).</p>
190
<h4>Historic versions</h4>
191
<p>FPC's version numbering changed a few times over the years. Versions
192
before 0.99.5 are considered archaic. After the release of 0.99.5 a
193
system in version numbering was introduced, and that system was changed
194
slightly changed after the 1.0 release. </p>
195
<p><b>Versioning for versions 0.99.5 - 1.0</b></p>
196
<p>Compilers with an <b>even</b> last number are <b>release</b>
197
versions (e.g. 0.99.8, 0.99.10, 0.99.12, 0.99.14 1.0.0)<br>Compilers and
198
packages with an <b>odd</b> last number are <b>development</b> versions
199
(e.g. 0.99.9, 0.99.11, 0.99.13, 0.99.15) </p>
200
<p>0.99.5 is an exception to this rule, since <b>0.99.5 IS a release</b>
201
(a release prior to the introduction of this odd/even system).</p>
202
<p>Letters behind the version number (0.99.12b, 0.99.5d) indicate
203
release versions with some bugs and problems in the original release
204
(respectively 0.99.12 and 0.99.5) fixed.</p>
205
<p><b>Versioning after 1.0</b></p>
206
<p>Together with the release of 1.0 the version numbering was
207
slightly changed, and a system in versioning resembling the Linux
208
kernel's has been introduced. The main difference is that the difference
209
between a release version is now in the second number (1.0.x vs 1.1.x)
210
instead of the third number (0.99.14 vs 0.99.15), and the third number
211
now becomes the patch level, replacing the postfixed letter in the old
215
<li>Releases that only fixed bugs in version 1.0 were numbered 1.0.x.</li>
216
<li>New development (the so called snapshots) started with version number
218
<li>Eventually the 1.1.x versions, when stabilized turned to 2.x. Fixes on
219
2.0 release are numbered 2.0.x.</li>
220
<li>The new development after the 2.0 release is numbered 2.1.x
224
<p>Normally you would want to use a release. Releases are considered
225
stable, and easier to support (the bugs, quirks and unintended
226
"features" are well known after a period of time, and workarounds
228
<p>Development snapshots (which are generated daily) reflect the current
229
status of the compiler. Development versions probably have new features
230
and larger bugs fixed since the last release, but might have some
231
temporary stability drawbacks (which are usually fixed by the next day).</p>
232
<p>Development snapshots are often quite useful for certain categories of
233
users. Ask in the maillists if it is worth the trouble in your case if
235
<p>We advise all users to upgrade to the newest version for their
236
target (Preferably the stable 2.0.x series).</p>
238
<li><a name=FPandGNUPascal></a>
239
<h3>Free Pascal and GNU Pascal - a comparison</h3>
144
<DD>Free Pascal tries to implement a Borland compatible pascal compiler
145
on as many platforms as possible. GNU Pascal tries to implement a portable
146
pascal compiler based on POSIX.</DD>
147
<DT><B>Version:</B></DT>
148
<DD>Currently, Free Pascal is at version 1.00 for the Intel version
149
and version 0.99.5d for the Motorola/Intel version. Version 0.99.5d differs
150
from version 0.99.5 in that all run time library fixes have been
151
applied, as well as all known code generation bugs. Version 1.00
152
differs from version 0.99.5d in that all parser bugfixes have also
153
been applied and also a lot of Delphi 2 and Delphi 3 extensions have
154
been implemented. GNU Pascal is at version 2.8.1 (but this numbering is
155
not really an indication, it follows the GNU
156
C numbering, since it is a derivation of it)</DD>
157
<DT><B>Operating systems:</B></DT>
158
<DD>Free pascal runs on a limited number of systems : DOS, Win32, Linux,
159
OS/2 and AmigaOS and is for the moment limited to the Intel and Motorola
160
architectures. GNU Pascal runs basically on any system that can run GNU C.
162
<DT><B>Sources:</B></DT>
163
<DD>Free Pascal is entirely written in Pascal (about 6 Mb of source code),
164
while GNU Pascal is written in C (it's an adaptation of the GNU C compiler:
165
2.8 Mb code + 8 MB of GNU C code)</DD>
166
<DT><B>Language:</B></DT>
167
<DD>Free Pascal supports the Borland Pascal dialect Borland, and implements
168
the Delphi Object Pascal language. GNU Pascal supports ISO 7185, ISO 10206,
169
(most of) Borland Pascal 7.0</DD>
170
<DT><B>Extensions:</B></DT>
171
<DD>Free Pascal implements method, function and operator overloading.
172
GNU Pascal implements operator overloading.</DD>
173
<DT><B>License:</B></DT>
174
<DD>Both compilers come under the GNU GPL.</DD>
175
<DT><B>Author:</B></DT>
176
<DD>Free Pascal was started by Florian Klaempfl, Germany (Florian.Klaempfl@gmx.de),
177
GNU Pascal was started by Jukka Virtanen, Finland (jtv@hut.fi).</DD>
180
<LI><A NAME="WhereToGetFP"></A><H3>Where can I get the compiler ?</H3>
182
Free Pascal is available for download from all <A HREF="download.html"> official mirrors</A>
184
<LI><A NAME="PortabilityTips"></A><H3>What are the considerations in porting
185
code to other processors?</H3>
187
Because the compiler now supports processors other than the Intel, it is
188
important to take a few precautions so that your code will execute
189
correctly on all processors.
192
<LI>Limit your use of asm statements unless it is time critical code</LI>
193
<LI>Don't use the packed directive unless you know exactly what you are
194
doing. Most processors require alignment of data, and using packed on
195
objects,classes and records may break this requirement. If this is the
196
case your code will simply crash on the target processors.</LI>
197
<LI>Clean up at the end of your program, i.e. close all files on exit,
198
as some operating systems don't like it when some files are left opened. </LI>
199
<LI>Try not to rely on the endian of the specific machines when doing
242
<DD>Free Pascal tries to implement a Borland compatible pascal
243
compiler on as many platforms as possible. GNU Pascal tries to
244
implement a portable pascal compiler based on POSIX.
246
<DD>Currently, Free Pascal is at version 2.0 (may 2005). GNU Pascal is at
247
version 2.1 (from 2002, which can be built with several different GCC's as backend;
248
their Mac OS X version is an exception though, as it follows the GCC version number).
250
<DD>Between releases, development versions of FPC are available through daily snapshots
251
and the source via CVS. GPC issues a set of patches to the last version a few times
252
a year, and there are regular snapshot for OS X and Windows, made by users.
253
<DT><b>Operating systems:</b>
254
<DD>Free Pascal runs on a large amount of platforms of OSes,
255
e.g. DOS, Win32 (no Unix porting layer needed), Linux, FreeBSD,
256
NetBSD, OS/2, BeOS, Classic Mac OS, Mac OS X, and AmigaOS, on, at
257
the moment the following architectures: x86,
258
x86 64 (AMD64), Sparc, PowerPC, ARM and Motorola (Motorola only in version 1.0.x).
259
GNU Pascal runs basically on any system that can run GNU C, and for which the buildprocess was verified.
260
<DT><b>Bootstrapping:</b>
261
<DD>FPC requires a suitable set of binutils (AS,AR,LD), gmake and a commandline compiler. New architectures/OSes are crosscompiled.
262
GPC bootstraps via a suitable version of GCC, and requires a full set of binutils, flex, bison, gmake, a POSIX shell and libtool
264
<DD>Free Pascal is entirely written in Pascal (about 6 MB of source
265
code), while GNU Pascal is written in C (it's an adaptation of the GNU
266
C compiler: 2.8 MB code + 8 MB of GNU C code)
268
<DD>Free Pascal supports the Borland Pascal dialect,
269
implements the Delphi Object Pascal language and has some Mac Pascal extensions.
270
GNU Pascal supports ISO 7185, ISO 10206, (most of) Borland Pascal 7.0
271
<DT><b>Extensions:</b>
272
<DD>Free Pascal implements method, function and operator overloading. (later Delphi versions add these, so strictly not an extension anymore)
273
GNU Pascal implements operator overloading.
275
<DD>Both compilers come under the GNU GPL.
277
<DD>Free Pascal was started by Florian Klaempfl, Germany
278
(florian@freepascal.org), GNU Pascal was started by Jukka Virtanen,
279
Finland (jtv@hut.fi). </DD></DL><br>
280
<li><a name=general-license></a>
281
<h3>License and copyright information</h3>
282
<p> Applications created by the compiler and using the runtime
283
library come under a modified library gnu public license (LGPL),
284
which permit no restriction on the type of license the application
285
has. It is therefore possible to create closed source
286
or proprietary software using Free Pascal.
288
<p>This extra exception to the LGPL is added:<br><I> As a special
289
exception, the copyright holders of this library give you
290
permission to link this library with independent modules to
291
produce an executable, regardless of the license terms of
292
these independent modules, and to copy and distribute the
293
resulting executable under terms of your choice, provided
294
that you also meet, for each linked independent module, the
295
terms and conditions of the license of that module. An
296
independent module is a module which is not derived from or
297
based on this library. If you modify this library, you may
298
extend this exception to your version of the library, but
299
you not obligated to do so. If you do not wish to do so,
300
delete this exception statement from your version.</I></p>
301
Please note that you still have to comply to the LGPL, which, for example,
302
requires you to provide the source code of the runtime library. If you want
303
to write proprietary closed source software, please do this to comply:
305
<li>Most people can satisfy the source code requirement by mentioning
306
the rtl source code can be downloaded at the Free Pascal
307
web site: if you did not modify the rtl this is considered adequate to
308
satisfy the LGPL requirement of providing source code.
309
<li>If you made modifications to the runtime library, you cannot keep them
310
for yourself, you must make them available if requested.
311
<li>Distribute the LGPL license with your product.
313
<p> The compiler source code, on the other hand, comes under
314
the GNU Public license, which means that any usage of the compiler
315
source can only be used in software projects which have the same
319
<li><a name=WhereToGetFP></a>
320
<h3>Getting the compiler</h3>
321
<p>The latest official stable Free Pascal release is available for download
322
from one of our <a href="http://www.freepascal.org/download.html">official mirrors
324
<li><a name=general-install></a>
325
<h3>Free Pascal installation hints</h3>
327
<li> Do not install the compiler in a directory which contains spaces
328
in its name, since some of the compiler tools do not like these </li>
332
<li><a name=ftpproblems></a>
333
<h3> Why do i have to supply a user name and password to get Free Pascal ? </h3>
334
<p> You are trying to login in to an ftp site. You must use the login name:
335
anonymous and as your password, you should put your e-mail address.
338
<li><a name=general-connectftp></a>
339
<h3>Access denied error when connecting to the Free Pascal FTP site</h3>
340
<p>The Free Pascal main ftp site can only accept a maximum number of
341
simultaneous connections. If this error occurs, it is because
342
this limit has been reached. The solution is either to wait and
343
retry later, or better still use one of the Free Pascal mirror sites.</p>
345
<li><a name=ideinst></a>
346
<h3>Where can I find a text mode IDE?</h3>
347
<p>The development of the IDE (integrated development environment) is
348
not yet finished. However a working test version of the IDE is included
349
with version 1.0.x and higher of the compiler. There might be problems
350
running the DOS IDE under Windows NT and Windows 2000 (especially
351
the debugger), in that case it is suggested to use the native Windows
353
<p> The textmode IDE on *nix targets has several terminal problems. Try
354
to use a real xterm as possible, and choose a font which has a Dos
358
<li><a name=snapshot></a>
359
<h3>I want a new version NOW</h3>
360
<p>In the time between the release of new official versions, you can
361
have a look at and test developer versions (so-called "snapshots"). Be
362
warned though: this is work under progress, so in addition to old bugs
363
fixed and new features added, this may also contain new bugs. </p>
364
<p>Snapshots are generated automatically each night from the current
365
source at that moment. Sometimes this may fail due to bigger changes not
366
yet fully implemented. If your version doesn't work, try again one or
367
two days later. You're advised not to download the GO32v1 version for
368
Dos, since it's not supported any more. </p>
369
<p>The latest snapshot can always be downloaded from the <A
370
href="http://www.freepascal.org/develop.html#snapshot">development</a>
373
<li><a name=installsnap></a>
374
<h3>Installing a snapshot</h3>
375
<p>To install a snapshot, extract the zip archive into the existing
376
program directory of the last official version of Free Pascal (after
377
making a backup of the original of course). You can also extract it into
378
an empty directory and then move the files to the program directory,
379
overwriting existing files. </p>
380
<p> Make sure that you extract the ZIP archive such that the included
381
directory structure remains intact. For example if you use PKUNZIP,
382
use "pkunzip -d" instead of just "pkunzip". Note that snapshots also
383
contain a new RTL which most likely can't be used with the previous
384
release version, so backup your old RTL as well. </p>
386
<li><a name=KnownBugs></a>
387
<h3>Known bugs / Reporting bugs</h3>
388
<p>Go to the <a href="http://www.freepascal.org/bugs.html">bugs page</a>. </p>
389
<p>If you wish to know the bugs for a specific Free Pascal version, go to the bugs
390
page, display the bug database. At the end of the page you should
391
see an option to view only specific bugs. Choose "With Version"
392
with the version you want to get information about and
393
"With Status" choose "Unfixed". This should display all bugs
394
which are present in the specific version of the compiler
398
<li><a name=HOMEWORK></a>
399
<h3>I have to write a program for homework. Can you help?</h3>
400
<p>No. Please, don't send us mail about homework, we are no teachers.
401
The Free Pascal development team tries to give good support for the Free
402
Pascal compiler and are trying to always reply to emails. If we get
403
emails like this, this becomes harder and harder. </p>
405
<li><a name="windowsapp"></a>
406
<h3>How do I make a real Windows application with windows and menu bars?</h3>
407
The easiest way is to <a href='http://www.lazarus.freepascal.org'>download Lazarus</a>.
408
It won't be just a Windows application, it will also work under Linux, FreeBSD and
411
<li><a name="game"></a>
412
<h3>How do I make a game with Free Pascal? Can I make a game like Doom 3?</h3>
413
Yes, you can make games with Free Pascal and if you are really good you can make
414
a game like Doom 3. Making games is difficult, you need to be an experienced
415
programmer to make them. The web site <a href='http://www.pascalgamedevelopment.com'>
416
www.pascalgamedevelopment.com</a> is a community of people who program games in Free
419
If you want a start, please start to study <a href='http://www.delphi-jedi.org/Jedi:TEAM SDL HOME'>JEDI-SDL</a>
420
or <a href='http://ptcpas.sourceforge.net'>PTCPas</a>. Also you can try to study an existing game, for example
421
<a href='http://thesheepkiller.sourceforge.net'>The Sheep Killer</a> is a very simple game and it should not be
422
very hard to understand its code.
424
<li><a name=ErrorPos></a>
425
<h3>Getting more information when an application crashes</h3>
427
<li>The easiest possibility is to recompile your program with -gl
428
debugging option. This way unit LineInfo is automatically linked in,
429
and the printout after a program crash then contains source line
430
numbers in addition to addresses of the crash. To see runtime library (RTL)
431
functions in the backtrace with their real name, you have to recompile
432
the RTL with -gl too.</li>
433
<li>For more comprehensive checking, compile the
434
program with debugging information (use the -g command line option) </li>
435
<li>Load the program in the debugger <PRE>gdb(pas)(w) --directory=<src dirs> myprog.exe</PRE>Notes:
437
<li>Under UNIX systems (Linux, the BSD's), don't add the ".exe" after myprog
438
<li>"<TT>src dirs</TT>" is a list of directories containing the
439
source code files of myprog and the units it uses seperated by
440
semi-colons (";"). The current directory is automatically included.</li>
442
<li>Once inside the debugger, you can (optionally) set the command
443
line options that will be passed to your program using the command
444
"<TT>set args <option1 option2 ...></TT>"
445
<li>To start the program, type "<TT>run</TT>" and press enter
446
<li>After the program has crashed, the address of the instruction
447
where the crash occurred will be shown. The debugger will try to
448
display the source code line corresponding with this address. Note
449
that this can be inside a procedure of the RTL, so the source may not
450
always be available and most likely the RTL wasn't compiled with
451
debugging information.
452
<li>If you then type "<TT>bt</TT>" (BackTrace), the addreses in the
453
call stack will be shown (the addresses of the procedures which were
454
called before the program got to the current address). You can see
455
which source code lines these present using the command
456
<PRE>info line *<address></PRE>For example:<PRE>info line *0x05bd8</PRE></li>
458
<li><a name=general-heap></a>
459
<h3>Increasing the heap size</h3>
460
<p>By default Free Pascal allocates a small part of RAM for your
461
application as heap memory. If it just allocated all it could get,
462
people running Windows would have problems as Windows would increase
463
the swap file size to give the program more memory on and on, until
464
the swap file drive would be full. </p>
465
<p>You can specify the size of the heap with -Chxxxx. </p>
466
<p>However, the heap size doesn't really matter, since the Heap
467
is able to grow: if you've used all the available heap space, the
468
program will try to get more memory from the Operating system (OS),
469
so the heap is limited to the maximum amount of free memory provided by
471
<p>It is only handy if you know you will need at least a certain amount
472
of memory. You can then specify this value using the -Ch parameter, so
473
your program will allocate it at once on startup. This is slightly
474
faster than growing the heap a number of times. </p>
476
<li><a name=general-doesntfindfiles></a>
477
<h3>Compiler seems to skip files in directories that -Fu points to</h3>
478
<p>This sometimes happens with installation/compilation scripts if the
479
copying command doesn't preserve dates. The object files get older than
480
the PPU file, and the compiler tries to recompile them. A simple <TT>touch</TT>
483
Also note that FPC, contrary to Turbo Pascal keeps track of includefiles. Modified
484
includefiles or duplicate names might trigger an attempt at recompiling</p>
486
<li><a name=binariesbig></a>
487
<h3>Why are the generated binaries so big?</h3>
488
<p>There are several reasons and remedies for this: </p>
492
<p>You can create smartlinked applications. To turn on
493
the generation of smartlinkable units, use the -Cx command
494
line option when compiling your units. To turn on
495
the linking of previously generated smarlinkable units, use the -XX
496
(-XS in 0.99.12 and earlier) command line option when compiling a
498
<li>Normally, all symbol information is included in the resulting
499
program (for easier debugging). You can remove this by using the -Xs
500
command line option when compiling your program (it won't do anything
501
when compiling units)
502
<li>You can use UPX to pack the .EXEs (just like e.g. pklite) for Dos
503
(GO32v2) and Windows targets. Look <A
504
href="http://upx.sourceforge.net/">here</a> for
506
<li>You can use LXLITE for packing EMX binaries, but you won't be able
507
to run them under DOS (with extender) any more then. This issues is
508
not relevant for native OS/2 binaries compiled for target OS2 with
509
version 1.9.x and above, because these don't run under DOS anyway.
510
In addition, it might not be possible to use compressed binaries
511
on lower OS/2 versions (like 2.x) depending on chosen type of
512
compression. LXLITE can be found e.g. on
513
<a href="http://hobbes.nmsu.edu/">Hobbes</a>, search for LXLITE.
514
<li>Turn on optimalisations, both for supplied packages (RTL, FV, FCL)
515
and for your own code, this will also decrease the code size. </li>
516
<li>Keep in mind that under NT,2000,XP, compressed binaries startup
517
relatively slow. Test under various conditions (OS, CPU speed, memory)
518
if the behaviour is acceptable before compressing</li>
522
<li><a name=cfgfiles></a>
523
<h3>Configuration file problems (fpc.cfg or ppc386.cfg)</h3>
524
<p> Starting from version 1.0.6 of Free Pascal, the configuration
525
file is now called <TT>fpc.cfg</TT> instead of <TT>ppc386.cfg</TT>.
526
For backward compatibility , <TT>ppc386.cfg</TT> is still searched first
527
and, if found, is used instead of <TT>fpc.cfg</TT></p>
528
<p> Versions prior to Free Pascal 1.0.6 do not recognize <TT>fpc.cfg</TT>,
529
so if you wish to use an earlier version of the compiler using the
530
same configuration file used with FPC version 1.0.6 (or later),
531
the configuration file should be renamed to <TT>ppc386.cfg</TT></p>.
533
<li><a name=runerror></a>
534
<h3>Runtime errors</h3>
535
<p> When there is abnormal termination of an application generated
536
by Free Pascal, it is very probable that a runtime error will be
537
generated. These errors have the form : </p>
539
Runtime error 201 at 0x00010F86
540
0x00010F86 main, line 7 of testr.pas
543
<p> The 201 in this case indicates the runtime error
544
number. The definition of the different runtime error numbers is
545
described in the Free Pascal user's manual, Appendix D. The
546
hexadecimal numbers represent the call stack when the error occured.
549
<li><a name=stdunits></a>
550
<h3>Standard units</h3>
551
<p> To see the list of base units supplied with Free Pascal, and
552
on which platform they are supported, consult the Free Pascal user's manual.
553
There is also a short description of what each unit does in the same section
557
<li><a name=internaldocs></a>
558
<h3>How does the compiler work internally?</h3>
560
<p>A draft document describing the internals of the Free Pascal compiler is
561
available <a href="ftp://ftp.freepascal.org/pub/fpc/docs/fpc-int10.zip">here</a>.
565
<li><a name=debugsmart></a>
566
<h3>Debugging smartlinked code does not fully work</h3>
567
<p>Debugging smart linked code might not work correctly. This is
568
due to the fact that no type information is emitted for
569
smartlinked code. If this would not be done, the files
570
would become enormous.
572
<p> While debugging, it is not recommended to use the
573
smartlinking option.</p>
575
<li><a name=debugshared></a>
576
<h3>Debugging shared library (dynamic linked library) code does not fully work</h3>
577
<p>Debugging shared libraries (or dynamic linked libraries) produced
578
by the Free Pascal compiler is not officially supported.
581
<li><a name=cantfindunit></a>
582
<h3>PPU files binary compatibility between versions</h3>
583
<h3>Can't compile a program using a binary only version of a unit</h3>
585
Sometimes, even though there is a binary version of a module (unit file and object file)
586
available, the compiler still gives compilation errors. This can be caused either by an
587
incompatibility in the PPU file format (which should change only between
588
major versions of the compiler), or by a change in one of the units of the RTL
589
which has changed in between releases.
592
To get more information, compile the code using the -va (show all information)
593
compiler switch, and the unit loading phase will be displayed. You might
594
discover that the unit being loaded requires to be recompiled because one
595
of the unit it uses has changed.
597
<p>So if you plan on distributing a module without the source code, the binaries
598
should be compiled and made available for all versions of the compiler you
599
wish to support, otherwise compilation errors are bound to occur.
601
<p>In other words, the unit (PPU) file format does not change significantly
602
in between minor releases of the compiler (for exemple : from 1.0.4 and 1.0.6)
603
which means they are binary compatible, but because the interface of the units
604
of the RTL certainly changes between versions, recompilation will be required
605
for each version anyways.
608
<li><a name=filemode></a>
609
<h3>File denied errors when opening files with reset </h3>
610
<p> Trying to open files using <CODE>reset</CODE> on non-text files
611
might cause a Runtime Error 5 (Access denied). </p>
612
<p> All files opened using the above system unit routine use the current
613
<CODE>filemode</CODE> value to determine how the file is opened. By
614
default, <CODE>filemode</CODE> is set to 2 (Read/Write access).
616
<p>So, a call to <CODE>reset</CODE> on non-text files does <EM>not</EM>
617
indicate that the file will be opened read-only. So, trying to open a file
618
using <CODE>reset</CODE> with the defaults will fail on read-only files.
619
<CODE>filemode</CODE> should be set to 0 (Real-only access) before
620
calling <CODE>reset</CODE> to solve this problem. A sample solution
625
{ possible values for filemode }
633
assign(f,'myfile.txt');
634
oldfilemode := filemode;
635
{ reset will open read-only }
636
filemode := READ_ONLY;
638
{ restore file mode value }
639
filemode := oldfilemode;
644
<p> For more information, consult the Free Pascal reference manual</p>
646
<li><a name=dotnet></a>
647
<h3>What about .NET? </h3>
648
Occasionally, users ask about a FPC that supports .NET, or our
649
plans in that direction. <p>
650
Mainly the users are either interested because of .NET's
651
portability aspects (Mono is quoted over and over again), or
652
because it is supposed to be the next big thing in Windows
654
While the FPC core developpers are somewhat interested out of
655
academic curiousity (mainly because it could be a pilot for
656
creating bytecode) there are however several problems with .NET
657
in combination with FPC:
660
<li>FPC's language uses pointers, and so can only be
661
unmanaged. Unmanaged code is not portable under .NET, so that
662
already kills all possible benefits. This also means that
663
existing FPC and Delphi code won't run on .NET.</li>
664
<li>FPC's libraries don't base on .NET classes and datamodels (and
665
can't be changed to do so without effectively rewriting them),
666
moreover the libraries could only be unmanaged too, or they
667
would be incompatible</li>
668
<li>There is nothing <emph>practical</emph> known yet about how
669
portable an average .NET code will be. Little experiments with
670
hello world level code mean nothing, that kind of code works
671
with plain C too. </li>
672
<li>Operating System dependant code wouldn't work anymore, since
673
the win32 interface is unmanaged.</li>
676
So effectively this means that for FPC to benefit from .NET you
677
would have to significantly adapt the language (thus compiler) and
678
libraries, and be incompatible with the existing native sourcecode.
679
This is not adding support for .NET in FPC, but reimplementing FPC
680
on .NET from near scratch without backwards compability. Moreover
681
that also means that existing apps would have to be rewritten for
682
.NET, since it would take more than a simple recompile with a
683
FPC/.NET compiler.<p>
684
While unmanaged code has some uses (allows to integrate with managed
685
code inside windows easier), this still needs a codegenerator
686
backend to be written, interfaces and libraries defined, for little
687
practical use. This means a <b>lot of work</b> and since .NET take
688
up is not really high, this might not be worth it, since an
689
unmanaged FPC/.NET would only be minimally used. <p>
690
However if a FPC user does the bulk of the work (e.g. a bytecode
691
codegenerator, and maybe some base libraries) and if the work is
692
suitable for inclusion in FPC (a very big if), we will of course
694
These problems are pretty much similar for the Java (bytecode) too.
695
One has to mutilate the language, and rewrite the libraries from
696
scratch on the base libraries of the target (Java/.NET). Such an
697
attempt would have little synergy with the FPC project as it is
701
<h2><li>Pascal language related information</li></h2>
703
<li><a name=PortingCPU></a>
704
<h3>Considerations in porting to other processors</h3>
705
<p>Because the compiler now supports processors other than the Intel, it
706
is important to take a few precautions so that your code will execute
707
correctly on all processors. </p>
709
<li>Limit your use of asm statements unless it is time critical code</li>
710
<li>Try not to rely on the endian of the specific machines when doing
200
711
arithmetic operations. Furthermore, reading and writing of binary data
201
712
to/from files will probably require byte swaps across different endian
202
machines (swap is your friend in this case). This is even more important
203
if you write binary data to files. </LI>
204
<LI>Try limiting your local variables in subroutines to 32K, as this
205
is the limit of some processors, use dynamic allocation instead. </LI>
206
<LI>Try limiting the size of parameters passed to subroutines to 32K,
713
machines (swap is your friend in this case). This is even more
714
important if you write binary data to files. Freepascal defines
715
<CODE>ENDIAN_LITTLE</CODE> or <CODE>ENDIAN_BIG</CODE> to indicate the
717
<li>Try limiting your local variables in subroutines to 32K, as this
718
is the limit of some processors, use dynamic allocation instead.
719
<li>Try limiting the size of parameters passed to subroutines to 32K,
207
720
as this is the limit of some processors, use const or var parameters
210
<LI><A NAME="OOP"></A><H3>I tried to compile my Delphi code with the Free Pascal
211
Compiler, but it seems that it doesn't recognize Delphi style OOP.</H3>
213
The compiler supports the Delphi OOP. Make sure you use
214
the -S2 or -Sd switches (see the manuals for the meaning of these switches).
215
For a list of Delphi incompabilities also check the manual.
217
<LI><A NAME="HOMEWORK"></A><H3>I have to write a program for homework. Can you help?</H3>
219
No. Please, don't send us mail about homework, we are no teachers.
220
The Free Pascal development team tries to give good support for the Free
221
Pascal compiler and are trying to always reply to emails. If we get
222
emails like this, this becomes harder and harder.
224
<LI><A NAME="HowcanIbuildaunit"></A><H3>How can I build a unit?</H3>
226
It works like in Turbo Pascal. The first keyword in the file must be
227
UNIT (not case sensitive). The compiler will generate two files: <TT>XXX.PPU</TT>
228
and <TT>XXX.O</TT>. The PPU file contains the interface information for
229
the compiler and the O-file the machine code (an object file, whose precise
230
structure depends on the assembler you used). To use this unit in another
231
unit or program, you must include its name in the USES clause of your program.
233
<LI><A NAME="TurboVision"></A><H3>Will Free Pascal support TV (Turbo Vision) in the future?</H3>
235
A Turbo Vision port, called Free Vision, has progressed nicely lately. It's
236
already very usable, we are even writing an IDE in it. Due to copyrights
237
problem the FreeVision source code is not available at the moment. You can
238
download the IDE from the <A HREF="develop.html#snapshot">development</A> page. and get an idea of the look and feel though.
240
<LI><A NAME="CompileSystemUnit"></A><H3>How can I compile the system unit?</H3>
242
To recompile the system unit, it is recommended to have GNU make installed.
243
typing 'make' in the rtl source directory will then recompile all RTL units
244
including the system unit.
245
You may choose to descend into the directory of your OS (e.g. rtl/go32v2)
246
and do a 'make' there.
249
It is possible to do all this manually, but you need more detailed knowledge
250
of the RTL tree structure for that.
252
<LI><A NAME="Internalerror9999"></A><H3>I get an internal error 9999 or 10?</H3>
254
The latest versions of the Free Pascal Compiler come with an error handling
255
routine which catches the segmentation fault and lets the compiler to exit
256
gracefully. This is reported as an internal error 9999.
257
Please try to reproduce the error and send <A HREF="bugs.html">us</A>
261
(For the curious, IE 9999 is not a specific bug. It is a safety measure which
262
terminates if during compiling a certain condition is not met, which can be
263
caused by several bugs. So if you report the bug, and get IE 9999 later in
264
a different piece or part of sourcecode, it could be a completely different
265
bug. <b>IE 10</b> is something similar. It is a safety measure that is triggered
266
when the estimated number of registers needed to evaluate an expression proves
267
wrong. Just like IE 9999, two IE 10 problems are often independant of eachother.)
269
<LI><A NAME="Howdoesfunctionoverloadingwork"></A><H3>How does function overloading work?</H3>
271
function overloading is implemented, like in C++:
722
<li>The <TT>integer</TT> and <TT>cardinal</TT> types might have different
723
sizes and ranges on each processor, as well as depending on the compiler
726
<li>The <TT>CPU32</TT> or <TT>CPU64</TT> (defined by FPC starting
727
from version 1.9.3) are defined indicating if the target is a 32-bit or
728
64-bit cpu; This can help you separate 32-bit and 64-bit specific code.
730
<li>Use the <TT>ptrint</TT> type (defined by FPC starting
731
from version 1.9.3) when declaring an ordinal that will store
732
a pointer, since pointers can be either 32-bit or 64-bit depending on
733
the processor and operating system.
738
<li><a name=PortingOS></a>
739
<h3>Considerations in porting code to other operating systems</h3>
740
<p>Because the compiler supports several different operating systems,
741
is important to take a few precautions so that your code will execute
742
correctly on all systems. </p>
744
<li>File sharing is implemented differently on different operating
745
systems, so opening already opened files may fail on some operating
746
systems (such as Windows). The only correct way to make sure to
747
have the same file sharing behavior is to use the I/O routines
748
furnished in <TT>sysutils</TT>. </li>
749
<li>Clean up at the end of your program, i.e. close all files on exit, and
750
release all allocated heap memory, as some operating systems don't like it
751
when some things are left allocated or opened.</li>
752
<li> Some operating systems limit the local stack space which can be allocated,
753
therefore it is important to limit subroutine nesting, and the amount of
754
local variables. Limiting total stack space usage at a given moment to
755
at most 256 KBytes while make porting easier.</li>
756
<li> Do not hard code paths to files, try to use relative paths
758
<li> Use the following constants (defined in the system unit)
759
to get information on files, line endings, and to build paths:
761
<li> <TT>LineEnding</TT> : Indicates the characters which end a text line</li>
762
<li> <TT>LFNSupport</TT> : Indicates if long filenames are supported (more then 8.3 characters)</li>
763
<li> <TT>DirectorySeparator</TT> : The character or characters which separate path components </li>
764
<li> <TT>DriveSeparator</TT> : The character which separate the drive specification from the rest
766
<li> <TT>PathSeparator</TT> : The character which separates directories in the search path environment</li>
767
<li> <TT>FileNameCaseSensitive</TT> : Boolean indicating if the filenames for this system are case-sensitive or not</li>
769
It is also possible to use the <TT>PathDelim</TT>, <TT>PathSep</TT> and <TT>DriveDelim</TT> constants
770
defined in <TT>sysutils</TT>.
776
<h3>Compiling Delphi code using Free Pascal</h3>
777
<p>The compiler supports the Delphi classes. Make sure you use the -S2 or
778
-Sd switches (see the manuals for the meaning of these switches). For a
779
list of Delphi incompabilities also check the manual. </p>
781
<li><a name=HowcanIbuildaunit></a>
782
<h3>Building a unit</h3>
783
<p>It works like in Turbo Pascal. The first keyword in the file must be
784
UNIT (not case sensitive). The compiler will generate two files:
785
<TT>XXX.PPU</TT> and <TT>XXX.O</TT>. The PPU file contains the interface
786
information for the compiler and the O-file the machine code (an object
787
file, whose precise structure depends on the assembler you used). To use
788
this unit in another unit or program, you must include its name in the
789
USES clause of your program. </p>
791
<li><a name=CompileSystemUnit></a>
792
<h3>Compiling the system unit</h3>
793
<p>To recompile the system unit, it is recommended to have GNU make
794
installed. typing 'make' in the rtl source directory will then recompile
795
all RTL units including the system unit. You may choose to descend into
796
the directory of your OS (e.g. rtl/go32v2) and do a 'make' there. </p>
797
<p>It is possible to do all this manually, but you need more detailed
798
knowledge of the RTL tree structure for that. </p>
800
<li><a name=Howdoesfunctionoverloadingwork></a>
801
<h3>How does function overloading work?</h3>
802
<p>function overloading is implemented, like in C++:
274
804
procedure a(i : integer);
286
You must be careful. If one of your overloaded functions is in the interface
287
part of your unit, then all overloaded functions must be in the interface
288
part. If you leave one out, the compiler will complain with a 'This overloaded
289
function can't be local' message. Overloaded functions must differ in their
290
parameters, it's not enough if their return types are different.
292
<LI><A NAME="HowToCallCFuncuntions"></A><H3>How can I call C functions?</H3>
294
C calling convention is implemented as follows: The compiler pushes
295
the parameters from right to left, but the procedure has to clear the stack.
296
For calling the C function strcmp declare the following:
815
<p>You must be careful. If one of your overloaded functions is in the
816
interface part of your unit, then all overloaded functions must be in
817
the interface part. If you leave one out, the compiler will complain
818
with a 'This overloaded function can't be local' message. Overloaded
819
functions must differ in their parameters, it's not enough if their
820
return types are different. </p>
822
<li><a name=HowToCallCFuncuntions></a>
823
<h3>Calling C functions</h3>
825
It is possible to call functions coded in C, which were compiled
826
with the GNU C compiler (<TT>GCC</TT>). Versions which have been
827
tested are version 2.7.2 through 2.95.2 of GCC. For calling the
828
C function strcmp declare the following:
830
<PRE>function strcmp(s1 : pchar;s2 : pchar) : integer;cdecl;external;</PRE>
832
<li><a name=IntegratedAssemblerSyntax></a>
833
<h3>Integrated Assembler syntax</h3>
834
<p>The default assembler syntax (AT&T style) is different from the
835
one in Borland Pascal (Intel style). </p>
836
<p>However, as of version 0.99.0, the compiler supports Intel style
837
assembly syntax. See the documentation for more info on how to use
838
different assembler styles. </p>
839
<p>A description of the AT&T syntax can be found in the GNU
840
Assembler documentation. </p>
842
<li><a name=systemnotfound></a>
843
<h3>Unit system, syslinux, sysos2 or syswin32 not found errors</h3>
844
<p>System (syslinux - not the bootloader, sysos2 or syswin32, depending
845
on platform) is Pascal's base unit which is implicitely used in all programs.
846
This unit defines several standard procedures and structures, and must be found to
847
be able to compile any pascal program by FPC. </p>
848
<p>The location of the system.ppu and syslinux.o files are determined by
849
the -Fu switch which can be specified commandline, but is usually in the
850
ppc386.cfg or fpc.cfg configuration file. </p>
851
<p>If the compiler can't find this unit there are three possible causes:</p>
853
<li>The ppc386.cfg or fpc.cfg isn't in the same path as the compiler
854
executable (go32v2, win32 and OS/2) or can't be found as
855
"/etc/fpc.cfg" or ".fpc.cfg" in your homedirectory (Linux).
856
<li>The fpc.cfg or ppc386.cfg doesn't contain the -Fu line, or a wrong one.
857
See the <a href="http://www.stack.nl/~marcov/buildfaq.pdf">build faq (PDF)</a>, especially the chapters
858
about the fpc.cfg and the directory structure.
859
<li>The files ARE found but the wrong version or platform. Correct
860
ppc386.cfg or fpc.cfg to point to the right versions or reinstall the right
861
versions (this can happen if you try to use a <A
862
href="#snapshot">snapshot</a>
863
compiler while the -Fu statement in the used fpc.cfg still points to
864
the RTL that came with the official release compiler). </li>
866
<p>A handy trick can be executing "ppc386 programname -vt", this shows
867
where the compiler is currently looking for the system unit's files. You
868
might want to pipe this through more (Dos, OS/2, Windows) or less
869
(Linux), since it can generate more than one screen information: </p>
299
function strcmp(s1 : pchar;s2 : pchar) : integer;cdecl;external;
300
Since 0.99.5, the older [C]; won't work!
872
Dos, OS/2, Windows: ppc386 programname -vt |more<br>
873
unix, linux: ppc386 programname -vt |less<br>
302
<LI><A NAME="HowToUseGraph"></A><H3>How can I use the graph unit with Free Pascal?</H3>
304
Since 0.99.12, the graph unit is available both for Dos and Linux. Under Dos,
305
it only supported VESA modes though. Since version 0.99.14, a new more system
306
independant graph unit is included (although the only extra supported OS is
307
Win32 and this is only rudimentary support) which also supports standard VGA.
310
Since version 1.0, we also have a completely platform independent way of selecting
311
resolutions and bitdepths. You are strongly encouraged to use it, because other ways
312
will probably fail on one or other platform. See the documentation of the graph unit
313
for more information.
314
<LI><A NAME="WrongColors"></A><H3>Why do I get wrong colors when using the graph unit?</H3>
316
If you use <TT>detect</TT> as graphdriver, you will end up with the highest supported
317
bitdepth. Since the graph unit currently only supports up to 16 bits per pixel modes and
318
since this bitdepth is supported by all graphics cards made in at least the last 5 years, you
319
will most likely get a 16 bit mode.
322
The main problem is that in 16 (and 15, 24, 32, ...) bit modes, the colors aren't set anymore
323
using an index in a palette (the palettized way is called "indexed color"). In these modes, the
324
color number itself determines what color you get on screen and you can't change this color. The
325
color is encoded as follows (for most graphics cards on PC's at least):
328
<LI>15 bit color: lower 5 bits are blue intensity, next come 5 bits of green and then 5 bits of red. The
329
highest bit of the word is ignored.
330
<LI>16 bit color: lower 5 bits are blue intensite, next come *6* bits of green and then 5 bits of red.
333
This means that either you have to rewrite your program so it can work with this so-called "direct color"
334
scheme, or that you have to use <TT>D8BIT</TT> as graphdriver and <TT>DetectMode</TT> as graphmode. This will ensure that
335
you end up with a 256 (indexed) color mode. If there are no 256 color modes supported, then graphresult
336
will contain the value <TT>GrNotDetected</TT> after you called InitGraph and you can retry with graphdriver <TT>D4BIT</TT>. Make sure you use
337
the constant names (D8BIT, D4BIT, ...) and not their actual numeric values, because those values can
338
change with the next release! That the very reason why such symbolic constants exist.
340
<LI><A NAME="IntegratedAssemblerSyntax"></A><H3>Integrated Assembler syntax</H3>
342
The default assembler syntax (AT&T style) is different from the
343
one in Borland Pascal (Intel style).
346
However, as of version 0.99.0, the
347
compiler supports Intel style assembly syntax.
348
See the documentation for more info on how to use different assembler styles.
351
A description of the AT&T syntax can be found in the DJGPP FAQ <A HREF="http://www.delorie.com/djgpp/v2faq/faq102.html#Syntax">http://www.delorie.com/djgpp/v2faq/faq102.html#Syntax</A>
352
or in Brennan's Guide to Inline Assembly <A HREF="http://www.rt66.com/%7Ebrennan/djgpp/djgpp asm.html">http://www.rt66.com/%7Ebrennan/djgpp/djgpp asm.html</A>.
353
The documentation also contains a chapter where the difference between
354
the Intel and AT&T style assembly is explained.
357
Or you can use the convertor program at <A HREF="http://rcs.urz.tu-dresden.de/schoenfu/zip/asmtrans.zip">http://rcs.urz.tu-dresden.de/schoenfu/zip/asmtrans.zip
360
<LI><A NAME="HowToAccessDosMemory"></A><H3>How can I access DOS memory / How can I do graphics programming?</H3>
362
You can do like in TP, via absolute or mem[]. For larger memory blocks use the
363
dosmemput/dosmemget routines in Go32 unit.
365
<LI><A NAME="FPwithoutfpu"></A><H3>How can I run Free Pascal without a math coprocessor?</H3>
367
On the Intel version the emulator is automatically loaded by the compiler
368
if you add the following commands to your autoexec.bat:
877
<li><a name=extensionselect></a>
878
<h3>There is a new extension that will be really useful. Will you include it?</h3>
880
Occasionally somebody asks for a new extension on the maillist,
881
and the discussions that follow have a recurring pattern. An
882
extension is quite a big deal for the FPC team, and there are
883
some criteria that are used to select if an extension is
884
"worth" the trouble. The most important pre-selection criteria are:
886
<li>Compability must not be compromised in any way. Existing
887
codebases on at least the Pascal level must keep
888
running. This is often more difficult than most people
890
<li>The extension must have real value. Anything that is only
891
a shorter notation does not apply, unless it is
892
out of compatibility with an existing Pascal/Delphi
893
codebase. Practically it means it must make something
894
possible that can't be done otherwise or be a compability
896
<li>The change must fit in with the scope of the project,
897
implementing a Pascal compiler which can have a RAD
898
and generic DB system. This excludes features like
899
inline SQL, and large garbage collected objectframeworks.
902
Exceptions to the second rule are sometimes made for platform
903
specific reasons (e.g. interfacing to some other language or
904
OS). The first rule is often a problem, because issues aren't
905
easily recognizable unless one has tried to make extensions
906
before. Best is to make a thoroughly written proposal that the
907
devels can review with
908
<ul><li> Explanation of the feature</li>
909
<li> Why it is needed, what does it make possible?</li>
910
<li> How you would implement it?</li>
911
<li> Lots of examples of typical use, and tests for possible problem
914
Try to be verbose and really try to view this from the viewpoint
915
of somebody who has to implement it, and try to make examples
916
that span multiple units and procedures, and review what happens.
917
Be critical, try to punch holes in your
918
own reasoning and find possible problematic cases, and document
922
Besides these pre-selection rules and documentation, the other
923
important question is who is going to do the work. Keep in mind
924
that the FPC devels are volunteers with to-do lists that are
925
booked till the next decade. You can't simply expect they'll
926
drop everything from their hands and implement the feature
927
because you need it urgently, or think it is nice. If you are
928
not willing to implement it yourself, and submit patches,
929
chances are slim. Remarks as "this will attract a lot of
930
users because" are considered with a lot of scepsis, since
931
that applies to any new development.
934
<li><h2> Runtime library related information </h2></li>
936
<li><a name=HowToUseGraph></a>
937
<h3>Using the graph unit with Free Pascal</h3>
938
<p>Since version 1.0, we have a completely platform independent way
939
of selecting resolutions and bitdepths. You are strongly encouraged to
940
use it, because other ways will probably fail on one or other platform.
941
See the documentation of the graph unit for more information. </p>
943
<li><a name=WrongColors></a>
944
<h3>Why do I get wrong colors when using the graph unit?</h3>
945
<p>If you use <TT>detect</TT> as graphdriver, you will end up with the
946
highest supported bitdepth. Since the graph unit currently only supports
947
up to 16 bits per pixel modes and since this bitdepth is supported by
948
all graphics cards made in at least the last 5 years, you will most
949
likely get a 16 bit mode. </p>
950
<p>The main problem is that in 16 (and 15, 24, 32, ...) bit modes, the
951
colors aren't set anymore using an index in a palette (the palettized
952
way is called "indexed color"). In these modes, the color number itself
953
determines what color you get on screen and you can't change this color.
954
The color is encoded as follows (for most graphics cards on PC's at
957
<li>15 bit color: lower 5 bits are blue intensity, next come 5 bits of
958
green and then 5 bits of red. The highest bit of the word is ignored.</li>
959
<li>16 bit color: lower 5 bits are blue intensite, next come *6* bits
960
of green and then 5 bits of red. </li>
962
<p>This means that either you have to rewrite your program so it can
963
work with this so-called "direct color" scheme, or that you have to use
964
<TT>D8BIT</TT> as graphdriver and <TT>DetectMode</TT> as graphmode. This
965
will ensure that you end up with a 256 (indexed) color mode. If there
966
are no 256 color modes supported, then graphresult will contain the
967
value <TT>GrNotDetected</TT> after you called InitGraph and you can
968
retry with graphdriver <TT>D4BIT</TT>. Make sure you use the constant
969
names (D8BIT, D4BIT, ...) and not their actual numeric values, because
970
those values can change with the next release! That is the very reason why
971
such symbolic constants exist. </p>
973
<li><a name=fileshare></a>
974
<h3> File sharing and file locks </h3>
975
<p> The standard runtime library file I/O routines open
976
files in the default sharing mode of the operating system
977
(<TT>system, objects</TT> units). Because of this, you
978
might get problems if the file is opened more than once either
979
by another process or the same process. </p>
980
<p> Generally the behaviors for the different operating
981
systems are as follows : </p>
983
<li> UNIX systems : There is no verification at all. </li>
984
<li> Windows : An access denied error will be reported. </li>
985
<li> Amiga : An access denied error will be reported. </li>
986
<li> DOS / OS/2 : If the file is opened more than once by
987
the same process, no errors will occur, otherwise an
988
access denied error will be reported. </li>
990
<p>There are two ways to solve this problem:</p>
992
<li> Use specific operating system calls (such as file locking
993
on UNIX and Amiga systems) to get the correct behavior. </li>
994
<li> Use the <TT>sysutils</TT> unit or the Free Component Library
995
<TT>TFileStream</TT> File I/O routines, which try
996
to simulate, as much as possible, file sharing mechanisms. </li>
1000
<li><a name=filebig></a>
1001
<h3> Accessing huge files using standard I/O routines </h3>
1002
<p>The runtime library currently limits access to files which have
1003
file sizes which fit into a 32-bit signed integer (<TT>longint</TT>).</p>
1004
<p> Therefore accessing files which have file sizes greater than
1005
2 Gigabytes will produce unpredictable behavior. Application
1006
accessing such files will have to use direct operating systems
1007
calls (if the OS supports such files) to workaround the problem.
1010
<li><a name=TurboVision></a>
1011
<h3>Turbo vision libraries</h3>
1012
<p>A Turbo Vision port, called Free Vision, has progressed nicely
1013
lately. It's already very usable, we are even writing an IDE in it.
1014
When it will be in a more stable state it will be included in the
1015
standard runtime library. </p>
1018
<h2><li>DOS related information</li></h2>
1020
<li><a name=dos-release></a>
1021
<h3>Releasing software generated by the DOS compiler</h3>
1023
<li> If your program uses floating point code (which is
1024
very probable), make sure to read "<a href="#fp386">Applications created
1025
with Free Pascal crash on 80386 systems</a>" regarding special issues
1026
which might occur. Math coprocessor emulation software is then
1027
required (<TT>wmemu387.dxe</TT> should be redistributed with your software) </li>
1028
<li> The target system must have a DPMI server. To avoid problems,
1029
the file <TT>cwsdpmi.exe</TT> should always be redistributed with your
1031
<li> The target system must have DOS 3.3 or later </li>
1032
<li> The default heap size is 2 Megabytes. Automatic growing of the heap is supported </li>
1033
<li> The default stack size is 256 Kbytes. See also "<a href="#dos-stack">Changing
1034
the default stack size</a>" </li>
1035
<li> The stack checking option is available on this platform. </li>
1039
<li><a name=dos-debugging></a>
1041
<p>The GNU debugger v4.16 and later have been tested, and generally work as
1042
they should. Because the GNU debugger is C oriented, some pascal types might not be
1043
represented as they should. It is suggested to use gdbpas or the text mode
1044
IDE instead of GDB, which are both available for the DOS target.</p>
1047
<li><a name=dos-dll></a>
1048
<h3>Dynamic Libraries</h3>
1049
<p>Creation or use of shared libraries (also called dynamic link libraries) is not
1050
supported under this platform.
1054
<li><a name=dos-profile></a>
1057
<p>Profiling with <TT>gprof</TT> is supported for this platform. </p>
1060
<li><a name=FPwithoutfpu></a>
1061
<h3>Running Free Pascal without a math coprocessor?</h3>
1062
<p>On the Intel version the emulator is automatically loaded by the
1063
compiler if you add the following commands to your autoexec.bat: </p>
373
SET EMU386=C:\PP\BIN\GO32V2\WEMU387.DXE
375
(don't forget to replace the <TT>C:\PP</TT> with the directory where you installed FPC)
377
<LI><A NAME="AccessingMoreThan4MB"></A><H3>How do I reserve more than 2 megabytes of RAM?</H3>
379
By default Free Pascal allocates only 2MB of RAM for your application. If it just allocated all
380
it could get, people running Windows would have problems as Windows would
381
increase the swap file size to give the program more memory on and on,
382
until the swap file drive would be full.
385
You can specify the size of the heap with -Chxxxx. The default value
386
is -Ch4000000. Try -Ch10000000, provided you got enough swap space.
389
However, the heap size doesn't really matter anymore, since the Heap
390
is able to grow: if you've used all the available heap space, the
391
program will try to get more memory from the OS, so the heap is limited
392
to the maximum amount of free memory provided by the OS.
395
It is only handy if you know you will need at least a certain amount of memory.
396
You can then specify this value using the -Ch parameter, so your program will
397
allocate it at once on startup. This is slightly faster than growing the heap
400
<LI><A NAME="accessioports"></A><H3>How can I access I/O ports?</H3>
402
With versions before 0.99.10: if you're under DOS you can use the <TT>outport*</TT> and <TT>inport*</TT>
403
procedures of the go32 unit.
406
Since version 0.99.8, the Port array is supported like in TP, as long as you
407
use the ports unit in your program (not available under Win32).
410
I/O port access is possible under Linux, but that requires root privileges. Check
411
the manuals for the IOPerm, ReadPort and WritePort procedures. (Unit Linux)
413
<LI><A NAME="ImusingWin95"></A><H3>I'm using the Dos compiler under Windows 95</H3>
415
There is a problem with the Dos compiler and Win 95 on computers with less
416
than 16 MB. First set in the properties of the DOS box the DPMI memory
417
size to max value. Now try to start a demo program in the DOS box, e.g.
418
HELLO (starting takes some time). If this works you will be able to get
419
the compiler to work by recompiling it with a smaller heap size, perhaps
420
2 or 4 MB (option -Chxxxx).
422
<LI><A NAME="ImusingOS2"></A><H3>I'm using OS/2</H3>
424
Problems have been reported that the GO32v2 compiler does not run on
425
some OS/2 installations. You can use the native OS/2 compiler (strongly
426
preferred solution) or maybe compile a GO32v1 compiler yourself. However,
427
the GO32v2 version should generally work under OS/2 as well.
429
<LI><A NAME="dpmi"></A><H3>INSTALL.EXE of Dos version 0.99.10 reports "Load error: no DPMI"</H3>
431
The file cwsdpmi.exe is missing in the main directory of the zip archive.
432
The above message pops up if no other DPMI services are available.
433
Such services are for example available in a Dos window of Windows.
434
You can either extract that file from basego32.zip or download it from
435
<a href="http://www.brain.uni-freiburg.de/%7Eklaus/cwsdpmi.exe">
436
http://www.brain.uni-freiburg.de/%7Eklaus/cwsdpmi.exe</a>.
437
Put it into the same directory as install.exe and run install again.
439
<LI><A NAME="instal10NT"></A><H3>INSTALL.EXE of version 1.0 for Dos returns an error (-2) in Windows NT 4.0</H3>
441
This is caused by long file names in some of the .ZIPs of the dosversion. A new installer
442
will be generated that ignores the packages with long file names in it. Currently it is still being tested.
443
Alternatively, one could use the installer from the Win32 1.0 version under NT. This has the additional benefit
444
that the archives with long filenames can be selected and installed too.
447
The exact cause of this problem is that a NT 4.0 dosbox doesn't support long file names for dos programs.
448
Windows 95,98 and 2000 don't exhibit this problem.
452
<li>The current ZIPs on ftp have been updated with the new installer.</lI>
453
<lI>Dosw32100.zip, has now default the win32 installer, and the go32v2
454
installer packaged as installd.exe.
455
<li>If you already downloaded one of the large Dos zips, repeated downloading
456
is not necessary, just download a new installer:<ul>
457
<li><a href="ftp://ftp.freepascal.org/pub/fpc/dist/dos-1.00/separate/install.exe">Plain dos installer. For dos without a 32-bit windows loaded or OS/2</a></lI>
458
<li><a href="ftp://ftp.freepascal.org/pub/fpc/dist/win32-1.00/separate/install.exe">Win32 installer, for all win32 targets (win 95,98,NT en 2000) including their dosboxes</a></li>
460
<li>If you downloaded an OS/2 version, and experience problems, you can try to download the new dos installer</lI>
463
<LI><A NAME="instal106os2"></A><H3>INSTALL.EXE of version 1.0.6 or below fails with an unknown error (-1) under OS/2</H3>
1066
SET EMU387=C:\PP\BIN\GO32V2\WEMU387.DXE
1067
</PRE>(don't forget to replace the <TT>C:\PP</TT> with the directory
1068
where you installed FPC)
1071
<li><a name=fp386></a>
1072
<h3>Applications created with Free Pascal crash on 80386 systems</h3>
1075
<p>Trying to run an application which does floating point operations
1076
on a 386 system without a math co-processor will crash unless
1077
the <TT>emu387</TT> unit is used, as this unit loads the math co-processor
1078
emulator (called <TT>wmemu387.dxe</TT>). You can add the unit as follows:</p>
1084
<p>When the application is released, the software package should also
1085
include the wmemu387.dxe redistributable file to avoid problems. </p>.
1087
<p>Some 80386 systems have a hardware bug which corrupt the accumulator
1088
register <TT>EAX</TT> if it is used in a <TT>MOV</TT> instruction just
1089
after a <TT>POPAL</TT> instruction. Prior to version 1.0.5, the compiler
1090
and runtime library could generate such code sequences. This is now
1091
fixed and should no longer cause problems</p>
1096
<li><a name=nomousegraph></a>
1097
<h3>The mouse cursor is not visible in graphics screens</h3>
1098
<p>A lot of DOS mouse drivers don't support mouse cursors in VESA modes
1099
properly. Logitech is said to have a decent mouse driver, which can be
1101
href="ftp://ftp.logitech.com/pub/techsupport/mouse/m643 w31.exe">here</a></p>
1103
<li><a name=accessioports></a>
1104
<h3>Accessing I/O ports</h3>
1105
<p>With versions before 0.99.10: if you're under DOS you can use the
1106
<TT>outport*</TT> and <TT>inport*</TT> procedures of the go32 unit. </p>
1107
<p>Since version 0.99.8, the Port array is supported like in TP, as long
1108
as you use the ports unit in your program (not available under Win32).</p>
1109
<p>I/O port access is possible under Linux, but that requires root
1110
privileges. Check the manuals for the IOPerm, ReadPort and WritePort
1111
procedures. (Unit Linux) </p>
1113
<li><a name=HowToAccessDosMemory></a>
1114
<h3>Accessing DOS memory / Doing graphics programming</h3>
1115
<p>You can do like in Turbo Pascal, via absolute or mem[]. For larger memory
1116
blocks use the dosmemput/dosmemget routines in the <TT>Go32</TT> unit. </p>
1118
<li><a name=dos-stack></a>
1119
<h3>Changing the default stack size</h3>
1120
<p>Under the DOS (GO32V2) target, the default stack size to 256 bKbytes. This can
1121
be modified with a special DJGPP utility called <TT>stubedit</TT>. It is to note
1122
that the stack may also be changed with some compiler switches, this stack size,
1123
if greater then the default stack size will be used instead, otherwise the default
1124
stack size is used.</p>
1127
<li><a name=dos-os2></a>
1128
<h3>Using OS/2 generated applications under DOS</h3>
1129
<p>OS/2 applications (including the compiler) created with version 1.0.x
1130
and before should work correctly under vanilla DOS, since they are based
1131
on EMX (versions prior to 1.0.5 had big problems with EMX under DOS, this
1132
is now fixed). It is important to note that the compiled applications
1133
require the EMX runtime files (<TT>emx.exe</TT>) to execute properly. It may be
1134
necessary to distribute these files with the generated application.</p>
1135
<p>Binaries created for target OS2 with version 1.9.x and above cannot
1136
run under DOS any more, because they directly use OS/2 API functions not
1137
available when running under extender - you need to compile for a newly added
1138
EMX target which provides this capability of running on both platforms.</p>
1141
<h2><li>Windows related information </li></h2>
1143
<li><a name=win-release></a>
1144
<h3>Releasing software generated by the windows compiler</h3>
1145
<p> There is no special requirements for releasing software
1146
for the windows platform, it will work directly out of the box. The following
1147
are default for the Windows platform: </p>
1149
<li> The default heap size is 256 Kbytes. Automatic growing
1150
of the heap is supported. It is to note that Windows 95,
1151
Windows 98 and Windows Me limit the heap to 256 Mbytes
1152
(this is a limitation of those Operating systems, not of Free Pascal,
1153
consult MSDN article Q198959 for more information).
1155
<li> Stack size is unlimited </li>
1156
<li> The stack checking option is not available on this platform. </li>
1160
<li><a name=win-debugging></a>
1162
<p>The GNU debugger v4.16 and later have been tested, and generally work as
1163
they should. Because the GNU debugger is C oriented, some pascal types might not be
1164
represented as they should. It is suggested to use gdbpas or the text mode
1165
IDE instead of GDB, which are both available for windows targets.</p>
1168
<li><a name=win-dll></a>
1169
<h3> Dynamic libraries </h3>
1170
<p>Creation and use of shared libraries (also called dynamic link libraries) is
1171
fully supported by the compiler. Refer to the Programmer's Reference Manual for
1172
more information on shared library creation and use.
1176
<li><a name=win-profile></a>
1179
<p>Profiling is supported using <TT>gprof</TT>, starting with version 1.0.7.
1180
It requires mingw to be installed, and that <TT>fpc.cfg</TT> point to the
1181
correct library paths. </p>
1184
<li><a name=win-graph></a>
1185
<h3> Graph and problems with keyboard, mouse and "dummy dos windows" </h3>
1188
<li>If you use the Graph unit under Win32, you can't use the API mouse
1189
unit for mouse support or use the win32 Crt unit to get keyboard data.
1190
The reason for this is that the window popped up is a GUI window, and
1191
not a console one.</li>
1195
<li>Use units WinMouse and WinCrt instead.</li>
1200
<li>When you follow the above advice, and you run your purely Graph
1201
based win32 program from the RUN menu in windows, a dummy dos window
1206
<li>Set the application type to GUI: <PRE>{$apptype GUI}</PRE>
1207
and put this line before your programs InitGraph statement:
1208
<PRE>ShowWindow(GetActiveWindow,0);
1209
</PRE>This will hide the dos window window. </li>
1212
<p>Some of the demos (like fpctris) use these techniques </p>
1213
<li><a name=win-cygwin></a>
1214
<h3>Cygwin binary directory in your path sometimes causes strange problems</h3>
1215
<p>The mingw make tool seems to look for a "sh.exe", which it
1216
finds when the cygwin binary directory is in the path. The
1217
way directories are searched changes, and the build process dies.
1219
<p>Solution: don't put cygwin in your global path for now, only
1220
add it when needed. Efforts are made to work around this.
1222
<p>Possible untested workaround: add mingw sh.exe to a directory before
1223
the cygwin binary directory in the path
1225
<li><a name=win-makefile></a>
1226
<h3>Makefile problems on Win2000 (and NT)</h3>
1227
<p>After the 1.0.4 release, some problems with the mingw win32 build
1228
tools (make.exe and friends) were discovered. A patched version of these tools
1229
has been released. Automatically building large parts of the sources under
1230
Windows 2000 and Windows NT is now a lot easier. </p>
1233
<li>Download makew32.zip from the <A
1234
href="ftp://ftp.freepascal.org/pub/fpc/olddist/1.0.10/win32-1.0.10/separate/makew32.zip">ftp
1235
site</a> or a mirror.<br>
1236
<li>Unzip it to your pp directory. (the archive already contains the
1237
bin/win32/ directories)
1238
<li>Properties of "My Computer", (system properties), tab "advanced",
1239
"Environment Variables".
1240
<li>In the bottom box, select the "Path" entry, and then "Edit"
1241
<li>In the top field of this dialog, change "Path" to "PATH", and
1243
<li>Close and Reopen dosboxes to apply changes. </li>
1246
<p>Alternatively, if changing the case of the "Path" variable leads to
1247
problems, you could run the following batchfile in each dosbox prior to
1256
<p>A lot, if not all, makefile trouble is now probably gone. If you still
1257
have problems try getting the makent.zip utilities from the <A
1258
href="ftp://ftp.freepascal.org/pub/fpc/contrib/utils/win32/makent.zip">ftp
1259
site</a> or a mirror. It should be installed just like makew32.zip.</p>
1260
<p><b>Note:</b> The win32 version of make is case sensitive with respect to
1261
filenames (paths?) and environment variables</p>
1263
<li><a name=win95-fpc></a>
1264
<h3>Using the DOS compiler under Windows 95</h3>
1265
<p>There is a problem with the DOS (GO32V2) compiler and Windows 95 on
1266
computers with less than 16 Megabytes of RAM. First set in the
1267
properties of the DOS box the DPMI memory size to max value. Now try
1268
to start a demo program in the DOS box, e.g. HELLO (starting may take
1269
some time). If this works you will be able to get the compiler to work
1270
by recompiling it with a smaller heap size, perhaps 2 or 4 MB
1271
(option -Chxxxx). </p>
1273
<li><a name=win-os2></a>
1274
<h3>Using OS/2 generated applications under Windows</h3>
1275
<p>Normally OS/2 applications (including the compiler) created with version 1.0.x
1276
and before should work under Windows, since they are based on EMX - see
1277
<a href="#dos-os2">note about running OS/2 applications under DOS</a> for
1278
more detailed information. You need the RSX extender (rsx.exe) to do this.
1279
There have been problems reported while trying to run EMX applications under
1280
NT / 2000 / XP systems though. This seems to be a problem with EMX (RSX) itself.
1281
It is not recommended to use Free Pascal OS/2 compiled programs under NT / 2000
1282
and XP, as it might produce unexpected results.</p>
1284
<li><a name=win-dos></a>
1285
<h3>Using DOS generated applications under windows</h3>
1286
<p>Several problems have been found running DOS software
1287
under certain versions of Windows (NT / 2000 / XP). These
1288
seem to be problems with the DOS emulation layers (emulated
1289
DPMI services). These problems may not occur with all software
1290
generated by FPC. Either applications should be tested on these systems
1291
before being released, or Windows versions should be generated instead.</p>
1293
<li><a name=win-ide-mouse></a>
1294
<h3>The mouse cursor does not respond in the Windows IDE</h3>
1295
<p>In windowed mode, the mouse cursor might not respond to
1296
mouse moves and clicks. Just change the properties of the console,
1297
and remove the quick edit mode option. This should solve the mouse
1301
<li><a name=instal106win32></a>
1302
<h3>INSTALL.EXE of version 1.0.6 returns errors under some version
1304
<p>The original 1.0.6 installer gave errors under Win95/98/Me in some circumstances.
1305
A new installer (INSTALL.EXE) is included as of this date (10th July 2002)
1306
with version 1.0.6. If you downloaded Free Pascal for Windows before this date, you
1307
should upgrade to the latest version of Free Pascal.
1311
<h2><li>UNIX related information </li></h2>
1312
<p>This section also applies to most unix variants, such as
1313
linux, freebsd and netbsd. </p>
1315
<li><a name=unix-release></a>
1316
<h3>Releasing software generated by the unix compilers</h3>
1318
<li> The default heap size is 256 Kbytes for the intel version,
1319
and 128 Kb for the m68k versions. Automatic growing of the
1320
heap is supported. </li>
1321
<li> There is no stack space usage limit. </li>
1322
<li> Under Solaris and QNX, stack checking is simulated. </li>
1323
<li> Minimal operating system versions :
1325
<li> Linux : Kernel v1.1.x or later. </li>
1326
<li> FreeBSD : version 4.x or later. </li>
1327
<li> NetBSD : version 1.5 or later. </li>
1328
<li> Solaris : version 5.7 of SunOS or later
1329
(should work with earlier versions, but untested). </li>
1330
<li> Qnx : version 6.1.0 or later
1331
(should work with earlier versions, but untested). </li>
1337
<li><a name=unix-debugging></a>
1339
<p>The GNU debugger v4.16 and later have been tested, and generally work as
1340
they should. Because the GNU debugger is C oriented, some pascal types might not be
1341
represented as they should. For FreeBSD a recent GDB (v5) CVS snapshot is
1342
recommended for Pascal support and ease of building</p>
1345
<li><a name=unix-dll></a>
1346
<h3> Dynamic libraries </h3>
1347
<p>These operating systems do support shared libraries (also called
1348
dynamic link libraries), Free Pascal currently does not emit position
1349
independant code (PIC), as required for the creation of shared libraries.
1352
Therefore, even though the linux compiler target permits creating shared
1353
libraries, the usage of that shared library may result in undefined
1354
behavior, especially if accessing global variables in the library. Creation
1355
of shared libraries is not recommended with the current version of the
1359
Importing code from shared libraries does work as expected though, since
1360
it does not require usage of position independant code.
1364
<li><a name=unix-profile></a>
1367
<p>Profiling is supported using <TT>gprof</TT> under linux,
1368
FreeBSD and NetBSD, the latter two only since 1.0.8. On other
1369
other unix-like operating systems, profiling is currently not
1374
<li><a name=vgamissing></a>
1375
<h3>Why can't the linker find "vga"?</h3>
1376
<p>This error typically looks like this:<PRE>
1377
Free Pascal Compiler version 1.0.x [xxxx/yy/zz] for i386
1378
Copyright (c) 1993-2000 by Florian Klaempfl
1379
Target OS: Linux for i386
1383
/usr/bin/ld: cannot find -lvga
1384
test.pp(6,4) Warning: Error while linking Closing script ppas.sh 5 Lines
1388
<p>This error is not an error in the installation of FPC or FPC itself,
1389
but a missing Svgalib library in your unix install. Please install the
1390
required library using your favourite package manager tool </p>
1392
<li><a name=unix-asldmissing></a>
1393
<h3>Compiler indicates missing as and ld</h3>
1394
<p> Normally unix systems have the assembler (<TT>as</TT>) and linker
1395
(<TT>ld</TT>) pre-installed and already in the search path. That is
1396
the reason why these tools are not supplied with the compiler. </p>
1397
<p>If the compiler cannot find these tools, either they are not in
1398
your search path, or they are not installed. You should either add the
1399
path where the tools are located to your search path, and / or you
1400
should install these tools. </p>
1401
<p> It is to note that the Solaris version of FPC contains these tools. </p>
1404
<h2><li>OS/2 related information </li></h2>
1406
<li><a name=os2-release></a>
1407
<h3>Releasing software generated by the OS/2 compiler</h3>
1408
<p> The OS/2 compiler version 1.0.x and before is based on EMX, therefore
1409
it should work both on OS/2 and on vanilla DOS systems. In version 1.9.x and
1410
above this functionality is preserved in newly added target EMX, whereas binaries
1411
for target OS2 can only run under real OS/2. The following notes apply to OS2
1412
target in 1.0.x and EMX in 1.9.x and above:</p>
1414
<li> All applications generated for the OS/2 (EMX) target require
1415
the EMX 0.9d (or later) runtime files to run. These files
1416
should be redistributed with your software. All the files
1417
which should be redistributed are included in <TT>emxrt.zip</TT></li>
1418
<li> Under OS/2, <TT>LIBPATH</TT> should be modified to add the EMX
1419
DLL paths. Otherwise, programs will not run and will abort
1420
with an error 'Cannot find EMX.dll'.</li>
1421
<li> The default heap size is 256 Kbytes.
1422
Automatic growing of the heap is supported.</li>
1423
<li> Stack can grow up to 256 Kbytes by default. This can be changed by
1424
the user or developper using the <TT>emxstack</TT> or <TT>emxbind</TT>
1429
<li><a name=os2-debugging></a>
1431
<p>The GNU debugger v4.16 (EMX port) has been tested (including
1432
its PM add-on, pmgdb.exe) and generally works as it should.
1433
Because the GNU debugger is C oriented, some pascal types
1434
might not be represented correctly.</p>
1437
<li><a name=os2-dll></a>
1438
<h3> Dynamic libraries </h3>
1440
Even though this operating system permits the creation and usage of
1441
shared libraries (also called dynamic link libraries), the compiler
1442
currently only permits importing routines from dynamic libraries (creation of
1443
dynamic libraries is unsupported).
1447
<li><a name=os2-profile></a>
1450
<p>Profiling is currently not supported for this platform. </p>
1452
<li><a name=os2-dos></a>
1453
<h3>Using DOS generated applications under OS/2</h3>
1454
<p>It has been reported that some DOS (GO32V2) applications
1455
(including the DOS compiler itself) generated by the compiler fail on
1456
some OS/2 installations. This is due to problems in the OS/2 DPMI server.
1458
<p>You should use native OS/2 applications under OS/2 (including the native OS/2
1459
compiler) or try installing a new OS/2 fixpack to see if it solves the
1462
<li><a name="instal106os2"></a><h3>INSTALL.EXE of version 1.0.6 or below fails with an unknown error (-1) under OS/2</h3>
467
<H3>INSTALL.EXE of version 1.0.6 or above complains about missing TZ variable under OS/2</H3>
1466
<h3>INSTALL.EXE of version 1.0.6 or above complains about missing TZ variable under OS/2</h3>
469
1468
You are most probably using an older version of OS/2 (like OS/2 Warp 3.0)
470
1469
and don't have TZ variable in your environment. The easiest solution is to add
471
1470
"SET TZ=..." (e.g. "SET TZ=CET-1CEST,3,-1,0,7200,10,-1,0,10800,3600" for most
472
1471
of western and central Europe) line to your CONFIG.SYS, and restart OS/2.
473
1472
The proper setting for you can be found e.g. using the TZCALC tool from
474
<A HREF="http://hobbes.nmsu.edu/pub/os2/apps/internet/time/time868f.zip">TIME868</A>
1473
<a href="http://hobbes.nmsu.edu/pub/os2/apps/internet/time/time868f.zip">TIME868</a>
478
<LI><A NAME="snapshot"></A><H3>I want a new version NOW</H3>
480
In the time between the release of new official versions, you
481
can have a look at and test developer versions (so-called "snapshots").
482
Be warned though: this is work under progress, so in addition to
483
old bugs fixed and new features added, this may also contain new bugs.
486
Snapshots are generated automatically each night from the current
487
source at that moment. Sometimes this may fail due to bigger changes
488
not yet fully implemented. If your version doesn't work, try again one
489
or two days later. You're advised not to download the GO32v1 version for Dos,
490
since it's not supported any more.
492
<p>The latest snapshot can always be downloaded from the
493
<a href="develop.html#snapshot">development</a> web page.
496
To install a snapshot, extract the zip archive into the existing
497
program directory of the last official version of Free Pascal (after
498
making a backup of the original of course). You can also extract it into an
499
empty directory and then move the files to the program directory,
500
overwriting existing files. Make sure that you extract the ZIP archive
501
such that the included directory structure remains intact. For example
502
if you use PKUNZIP, use "pkunzip -d" instead of just "pkunzip".
503
Note that snpashots also contain a new RTL which most likely can't be
504
used with the previous release version, so backup your old RTL as well.
506
<LI><A NAME="ideinst"></A><H3>Where can I find a text mode IDE?</H3>
508
The development of the IDE (integrated development environment)
509
is not yet finished. However a working test version of the IDE is available
510
as snapshot. It requires the latest compiler snapshot be installed on
511
top of the current official version for your particular platform (1.00
512
for GO32v2 or Win32). So if you have not already done that, first install the latest official
513
version (e.g. file dos100.zip or dos100full.zip, you find these in
514
the <a href="download.html">download</a> section).
517
Then get and extract the latest snapshot for your platform (e.g. snapshot.zip)
518
into the directory containing the official version.
519
Next, do the same with one of the IDE snapshots.
520
For more details on where to find and how to install a snapshot,
521
please see the previous FAQ item. For additional instructions
522
for required IDE configuration please also read the next FAQ item.
524
<LI><A NAME="ideconfig"></A><H3>How do I configure the Dos IDE?</H3>
526
Once you have installed the IDE (see the previous FAQ item),
527
it requires two configuration changes before it can compile.
528
This is due to the fact that the IDE includes its own compiler;
529
it does not use ppc386.exe and thus it also does not use the
530
configuration in the file ppc386.cfg.
533
Start fp.exe, select Target from the Compile menu and then check GO32v2.
534
Next, choose Directories in the Otions menu and in the line "Unit directories"
535
enter the path to your copy of the rtl directory, usually c:\pp\rtl\go32v2.
536
If you have done everything correct and it still doesn't work,
537
you may have grabbed a snapshot that has a bug; in this case
538
try again one or two days later or ask for help on one of the
539
<A HREF="maillist.html">mailing lists</A>.
541
<LI><A NAME="binariesbig"></A><H3>Why are the generated binaries so big?</H3>
543
There are several reasons and remedies for this:
548
<p>If you are using 0.99.12: Due to some problems with the binary writer, 0.99.12 wasn't
549
released with smartlinkable RTLs. Smartlinking causes only actually used procedures,
550
functions and constants to be linked in.</p>
552
You can remedy this by using a development version and creating a smartlinking
553
RTL. See the <a href="makecyc.html">make cycle faq</a> or use a later release if available (0.99.14 and later do include a smartlinkable RTL). To turn on the generation of smartlinkable units, use the -Cx command line option when compiling
554
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.
556
<li>Normally, all symbol information is included in the resulting program (for
557
easier debugging). You can remove this by using the -Xs command line
558
option when compiling your program (it won't do anything when compiling
560
<lI>You can use UPX to pack the .EXEs (just like e.g. pklite) for Dos (GO32v2)
561
and Windows targets. Look <A HREF="http://wildsau.idv.uni-linz.ac.at/mfx/upx.html">here</A> for
563
<lI>You can use LXLITE for packing EMX binaries, but you won't be able to run
564
them under DOS (with extender) any more then. It might even not be possible
565
to use them on lower OS/2 versions (like 2.x) depending on chosen type
566
of compression. LXLITE can be found e.g. on <A HREF="http://hobbes.nmsu.edu">Hobbes</A>, search
567
for LXLITE.</li></li>
568
<li>Turn on optimalisations, both for supplied packages (RTL, API, FV, FCL) and for
569
your own code, this will also decrease the code size.
572
<LI><A NAME="systemnotfound"></A><H3>Unit system, syslinux, sysos2 or syswin32 not found errors</H3>
574
System (syslinux, sysos2 or syswin32, depending on platform) is Pascal's base unit which is implicitely used
575
in all programs. This unit defines several standard procedures and structures, and must
576
be found to be able to compile any pascal program by FPC.
579
The location of the system.ppu and syslinux.o files are determined by the -Fu
580
switch which can be specified commandline, but is usually in the ppc386.cfg
584
If the compiler can't find this unit there are three possible causes:
587
<lI>The ppc386.cfg isn't in the same path as the compiler executable (go32v2, win32 and OS/2)
588
or can't be found as "/etc/ppc386.cfg" or ".ppc386.cfg" in your homedirectory (Linux).
589
<li>The ppc386.cfg doesn't contain the -Fu line, or a wrong one.
590
See the <a href="makecyc.html">make cycle faq</a>, especially the chapters
591
about the ppc386.cfg and the directory structure.
592
<li>The files ARE found but the wrong version or platform. Correct ppc386.cfg to
593
point to the right versions or reinstall the right versions (this can happen
594
if you try to use a <A HREF="#snapshot">snapshot</A> compiler while the -Fu
595
statemnt in the used ppc386.cfg still points to the RTL that came with the
596
official release compiler).
599
A handy trick can be executing "ppc386 programname -vt", this shows
600
where the compiler is currently looking for
601
the system unit's files. You might
602
want to pipe this through more (Dos, OS/2, Windows) or less (Linux), since it can generate more than one screen information:
607
ppc386 programname -vt |more<br>
609
ppc386 programname -vt |less<br>
612
<LI><A NAME="KnownBugs"></A><H3>Known bugs</H3>
614
Go to the <A HREF="bugs.html">bugs page</A>
616
<LI><A NAME="ErrorPos"></A><H3>How can I find where an error occurred using the addresses a crashed program prints?</H3>
618
<LI>Starting with version 1.00, the easiest possibility is to recompile
619
your program with -gl debugging option. This way unit LineInfo is
620
automatically linked in, and the printout after a program crash then
621
contains source line numbers in addition to addresses. To see RTL functions in the backtrace
622
with their real name, you have to recompile the RTL with -gl too.</LI>
623
<LI>For older versions, or more comprehensive checking, compile the program
624
with debugging information (use the -g command line option)</LI>
625
<LI>Load the program in the debugger (gdb(w) for 0.99.12b and earlier, gdbpas(w)
626
for 0.99.14 and later) using
627
<pre>gdb(pas)(w) --directory=<src dirs> myprog.exe</pre>
630
<LI>Under Linux/Unix, don't add the ".exe" after myprog</LI>
631
<LI>"<TT>src dirs</TT>" is a list of directories containing the source code
632
files of myprog and the units it uses seperated by semi-colons (";").
633
The current directory is automatically included.</LI>
635
<LI>Once inside the debugger, you can (optionally) set the command line options
636
that will be passed to your program using the command "<TT>set args <option1
637
option2 ...></TT>"</LI>
638
<LI>To start the program, type "<TT>run</TT>" and press enter</LI>
639
<LI>After the program has crashed, the address of the instruction where the crash
640
occurred will be shown.
641
The debugger will try to display the source code line corresponding with this
642
address. Note that this can be inside a procedure of the RTL, so the source
643
may not always be available and most likely the RTL wasn't compiled with
644
debugging information.</LI>
645
<LI>If you then type "<TT>bt</TT>" (BackTrace), the addreses in the call stack will
646
be shown (the addresses of the procedures which were called before the program
647
got to the current address). You can see which source code lines these present
648
using the command <pre>info line *<address></pre>For example:<pre>info line *0x05bd8</pre> </LI>
1477
<li><a name="os2-fp"></a><h3>OS/2 compiler not working after upgrading to 1.9.6 or newer</h3>
1478
<p>An updated version of GNU assembler (as.exe) is packaged with release 1.9.6 (newer version
1479
was necessary to get support for features of modern CPUs). This version of the GNU tool
1480
was created with Innotek port of GNU C and relies on its libc. This results in higher
1481
limitations regarding supported configurations, because this libc needs recent version
1482
of OS/2 Unicode support libraries (LIBUNI.DLL and UCONV.DLL) not available in base OS/2 Warp 3.0
1483
and OS/2 Warp 4.0. The updated versions were distributed by IBM in corrective packages (fixpaks)
1484
- see e.g. <a href="http://www.warpupdates.mynetcologne.de/english/basesystem.html">WarpUpdates site</a>
1485
for information about OS/2 fixpaks and links for downloading them.
1486
This issue isn't valid for WarpServer for e-Business, MCP and eComStation - these already have
1487
the correct version.
1491
<h2><li> BeOS related information </li></h2>
1492
<b>The BeOS port is current no longer maintained</b>
1494
<li><a name=beos-release></a>
1495
<h3>Releasing software generated by the BeOS compiler</h3>
1496
<p> Software generated for the BeOS target will only work
1497
on the intel based version of BeOS. </p>
1499
<li> The target system must have at least BeOS v4.0 or later
1500
(BeOS 5.1d 'Dano' is <em>not</em> supported) </li>
1501
<li> The default heap size is 256 Kbytes.
1502
Automatic growing of the heap is supported</li>
1503
<li> Stack size is set to 256 Kbytes. This cannot be changed </li>
1507
<li><a name=beos-debugging></a>
1510
This operating system uses DWARF debugging information, and Free Pascal
1511
does not support emitting DWARF debugging information. It is currently
1512
impossible to debug applications under BeOS
1516
<li><a name=beos-dll></a>
1517
<h3> Dynamic libraries </h3>
1519
Even though this operating system permits the creation and usage of
1520
shared libraries (also called dynamic link libraries), the compiler
1521
currently only permits importing routines from dynamic libraries (creation of
1522
dynamic libraries is unsupported).
1526
<li><a name=beos-profile></a>
1529
<p>Profiling is currently not supported for this platform. </p>
1533
<li><a name=beos-linking></a>
1534
<h3>BeOS Linking problems</h3>
1535
<p>It has been reported that certain versions of the linker
1536
that shipped with some versions of BeOS are broken. If you get
1537
an error when linking fpc applications, try updating your version
1538
of ld from the following
1539
<a href="http://open-beos.sourceforge.net/dev.php">site.</a>
1546
<h2><li> Amiga related information </li></h2>
1548
<li><a name=amiga-release></a>
1549
<h3>Releasing software generated by the Amiga compiler</h3>
1551
<li> The target system must have AmigaOS v2.04 or higher </li>
1552
<li> The default heap size is 128 Kbytes.
1553
Automatic growing of the heap is supported. </li>
1554
<li> Stack size is not set by the compiler, but by the <TT>stack</TT>
1555
command on the CLI. Because of this, and because default
1556
stack sizes for this target are small, it is recommended
1557
to always compile software with stack checking enabled.</li>
1558
<li> By default, the compiler generates code for the 68020+
1559
processor. The code generated will not work on 68000
1560
and 68010 systems unless the <TT>-O0</TT> compiler switch
1561
is used, and there is no runtime checking. It is up
1562
to you to implement CPU verification at program startup. The
1563
standard runtime libraries have been compiled for the
1564
68000 target, and should not cause any problems. </li>
1565
<li> All floating point operations are simulated,
1566
and use the <TT>single</TT> floating point type.
1567
You will need to recompile all standard runtime
1568
libraries and your application, with the software floating point
1569
option off, if you wish to use hardware floating point.</li>
1573
<li><a name=amiga-debugging></a>
1575
<p> Source level debugging is not supported for the Amiga target. Assembler
1576
target debugging is possible though, using the excellent <TT>Barfly</TT>
1580
<li><a name=amiga-dll></a>
1581
<h3> Dynamic libraries </h3>
1583
Even though this operating system permits the creation and usage of
1584
shared libraries (also called dynamic link libraries), the compiler
1585
does not support either the importing or creation of shared libraries.
1586
Importing must be done manually in assembler.
1590
<li><a name=amiga-profile></a>
1593
<p>Profiling is currently not supported for this platform. </p>
1597
<h2><li> PalmOS related information </li></h2>
1599
<li><a name=palmos-release></a>
1600
<h3>Releasing software generated by the PalmOS compiler</h3>
1605
<li><a name=palmos-debugging></a>
1607
<li><a name=palmos-dll></a>
1608
<h3> Dynamic libraries </h3>
added
removed
doc/faq.htm
