pascal
/
freepascal.compiler
mirror of https://gitlab.com/freepascal.org/fpc/source.git


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637
							<HTML>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Author" CONTENT="Free Pascal Web Team">
<META name="description" content="Free Pascal: free 32-bit Pascal compiler for DOS, Linux, Win32 and OS/2">
<META NAME="keywords" content="32 bit, protected mode, compiler, pascal, FPC, FPC Pascal, Free Pascal">
<TITLE>Free Pascal - FAQ</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#FF8080">
<OL>
<!-- IDXSTART -->
<LI><A HREF="#WhatIsFP">What is Free Pascal (FPC)?</A></LI>
<LI><A HREF="#versions">Which versions exist, and which one should I use?</A></LI>
<LI><A HREF="#FPandGNUPascal">Free Pascal and GNU Pascal - a comparison</A></LI>
<LI><A HREF="#WhereToGetFP">Where can I get the compiler ?</A></LI>
<LI><A HREF="#PortabilityTips">What are the considerations in porting</A></LI>
<LI><A HREF="#OOP">I tried to compile my Delphi code with the Free Pascal</A></LI>
<LI><A HREF="#HOMEWORK">I have to write a program for homework. Can you help?</A></LI>
<LI><A HREF="#HowcanIbuildaunit">How can I build a unit?</A></LI>
<LI><A HREF="#TurboVision">Will Free Pascal support TV (Turbo Vision) in the future?</A></LI>
<LI><A HREF="#CompileSystemUnit">How can I compile the system unit?</A></LI>
<LI><A HREF="#Internalerror9999">I get an internal error 9999 or 10?</A></LI>
<LI><A HREF="#Howdoesfunctionoverloadingwork">How does function overloading work?</A></LI>
<LI><A HREF="#HowToCallCFuncuntions">How can I call C functions?</A></LI>
<LI><A HREF="#HowToUseGraph">How can I use the graph unit with Free Pascal?</A></LI>
<LI><A HREF="#WrongColors">Why do I get wrong colors when using the graph unit?</A></LI>
<LI><A HREF="#IntegratedAssemblerSyntax">Integrated Assembler syntax</A></LI>
<LI><A HREF="#HowToAccessDosMemory">How can I access DOS memory / How can I do graphics programming?</A></LI>
<LI><A HREF="#FPwithoutfpu">How can I run Free Pascal without a math coprocessor?</A></LI>
<LI><A HREF="#AccessingMoreThan4MB">How do I reserve more than 2 megabytes of RAM?</A></LI>
<LI><A HREF="#accessioports">How can I access I/O ports?</A></LI>
<LI><A HREF="#ImusingWin95">I'm using the Dos compiler under Windows 95</A></LI>
<LI><A HREF="#ImusingOS2">I'm using OS/2</A></LI>
<LI><A HREF="#dpmi">INSTALL.EXE of Dos version 0.99.10 reports "Load error: no DPMI"</A></LI>
<LI><A HREF="#instal10NT">INSTALL.EXE of version 1.0 for Dos returns an error (-2) in Windows NT 4.0</A></LI>
<LI><A HREF="#snapshot">I want a new version NOW</A></LI>
<LI><A HREF="#ideinst">Where can I find a text mode IDE?</A></LI>
<LI><A HREF="#ideconfig">How do I configure the Dos IDE?</A></LI>
<LI><A HREF="#binariesbig">Why are the generated binaries so big?</A></LI>
<LI><A HREF="#systemnotfound">Unit system, syslinux, sysos2 or syswin32 not found errors</A></LI>
<LI><A HREF="#KnownBugs">Known bugs</A></LI>
<LI><A HREF="#ErrorPos">How can I find where an error occurred using the addresses a crashed program prints?</A></LI>
<!-- IDXEND -->
</OL>
<OL>
<LI><A NAME="WhatIsFP"></A><H3>What is Free Pascal (FPC)?</H3>
<P>
Originally named FPK-Pascal, the Free Pascal compiler is a 32 bit Turbo
Pascal compatible Pascal compiler for DOS, Linux, Win32, OS/2 and (based on
an older version) the AmigaOS. More operating systems (BeOS and FreeBSD/ELF are in
advanced stages of development) are in the works.
</P>
<P>
The compiler is written in Pascal and is able to compile its own sources.
The source files are included.
</P>
<P>
Free Pascal is modest regarding its minimal system requirements (386-25 Mhz for
the Intel version and ideally a 68020 processor for the Motorola
version). At least 2 megabytes of RAM are required. To remake the compiler
more than 16MB is recommended.
</P>
<p>
Short history:
<UL>
<LI>6/1993: project start
<LI>10/1993: first little programs work
<LI>3/1995: the compiler compiles the own sources
<LI>3/1996: released to the internet
<LI>7/2000: 1.0 version
</UL> 
</p>
<LI><A NAME="versions"></A><H3>Which versions exist, and which one should I use?</H3>
<p>
FPC's version numbering changed a few times over the years. Versions before 0.99.5 are considered archaic.
After the release of 0.99.5 a system in version numbering was introduced, and that system was changed slightly changed after the
1.0 release.
</p>
<b>Versioning for versions 0.99.5 - 1.0</b>
<P>
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>
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)
</P>
<P>
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).
</P>
<P>
Letters behind the version number (0.99.12b, 0.99.5d) indicate release versions with some bugs and problems in the original release 
(respectively 0.99.12 and 0.99.5) fixed.
</P>
<p>
<b>Versioning after 1.0</b>
</p>
<P>
Together with the release of 1.0 the version numbering has been slightly changed, 
and a system in versioning resembling the Linux kernel's has been introduced.
The main difference is that the difference between a release version is now in the 
second number (1.0.x vs 1.1.x) instead of the third number (0.99.14 vs 0.99.15), and
the third number now becomes the patch level, replacing the postfixed letter in the old system.
</p>
<p>
<ul>
<li>Releases that only fix bugs in version 1.0 will be numbered 1.0.x</li>
<li>New development (the so called snapshots) have version number 1.1.x. The meaning
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>
<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>
<li>The new development after the 1.2 release will be numbered 1.3.x and so on</li>
<li>When really big changes are implemented, the version will be updated in the major number. This could be case with
e.g. a codegenerator rewrite with support for other processors</li>
</ul>
</P
<P>
Normally you would want to use a release. Releases are considered stable, and
easier to support (the bugs, quirks and unintended &quot;features&quot; are well
known after a period of time, and workarounds exist). 
</P>
<P>
Development snapshots (which are generated daily) reflect the current status of the compiler.
Development versions probably have new features and larger bugs fixed since the last release,
but might have some temporary stability drawbacks (which are usually fixed by the next day). 
</P>
<P>
Most support for development snapshots are basically the advise to
upgrade to newer snapshot in which the bugs are hopefully fixed.
Since version 0.99.8 the stability of the compiler steadily increased
and development snapshots are often quite useful for certain categories of users. Ask in the maillists if it  
is worth the trouble in your case if you're not sure.
</P>
<P>
<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).
The development versions (snapshots) are numbered 1.1.x at the moment</b>
</p>
<p>
We advise all users to upgrade to the newest version for their target. (1.0 for intel processors, and 0.99.5d for Motorola)
</P>
<LI><A NAME="FPandGNUPascal"></A><H3>Free Pascal and GNU Pascal - a comparison</H3>
<DL>
<DT><B>Aim:</B></DT>
<DD>Free Pascal tries to implement a Borland compatible pascal compiler
on as many platforms as possible. GNU Pascal tries to implement a portable
pascal compiler based on POSIX.</DD>
<DT><B>Version:</B></DT>
<DD>Currently, Free Pascal is at version 1.00 for the Intel version
and version 0.99.5d for the Motorola/Intel version. Version 0.99.5d differs
from version 0.99.5 in that all run time library fixes have been
applied, as well as all known code generation bugs. Version 1.00
differs from version 0.99.5d in that all parser bugfixes have also
been applied and also a lot of Delphi 2 and Delphi 3 extensions have
been implemented. GNU Pascal is at version 2.8.1 (but this numbering is
not really an indication, it follows the GNU
C numbering, since it is a derivation of it)</DD>
<DT><B>Operating systems:</B></DT>
<DD>Free pascal runs on a limited number of systems : DOS, Win32, Linux,
OS/2 and AmigaOS and is for the moment limited to the Intel and Motorola
architectures. GNU Pascal runs basically on any system that can run GNU C.
</DD>
<DT><B>Sources:</B></DT>
<DD>Free Pascal is entirely written in Pascal (about 6 Mb of source code),
while GNU Pascal is written in C (it's an adaptation of the GNU C compiler:
2.8 Mb code + 8 MB of GNU C code)</DD>
<DT><B>Language:</B></DT>
<DD>Free Pascal supports the Borland Pascal dialect Borland, and implements
the Delphi Object Pascal language. GNU Pascal supports ISO 7185, ISO 10206,
(most of) Borland Pascal 7.0</DD>
<DT><B>Extensions:</B></DT>
<DD>Free Pascal implements method, function and operator overloading.
GNU Pascal implements operator overloading.</DD>
<DT><B>License:</B></DT>
<DD>Both compilers come under the GNU GPL.</DD>
<DT><B>Author:</B></DT>
<DD>Free Pascal was started by Florian Klaempfl, Germany ([email protected]),
GNU Pascal was started by Jukka Virtanen, Finland ([email protected]).</DD>
</DL>
<BR>
<LI><A NAME="WhereToGetFP"></A><H3>Where can I get the compiler ?</H3>
<P>
Free Pascal is available for download from all <A HREF="download.html"> official mirrors</A>
</P>
<LI><A NAME="PortabilityTips"></A><H3>What are the considerations in porting
code to other processors?</H3>
<P>
Because the compiler now supports processors other than the Intel, it is
important to take a few precautions so that your code will execute
correctly on all processors.
</P>
<UL>
<LI>Limit your use of asm statements unless it is time critical code</LI>
<LI>Don't use the packed directive unless you know exactly what you are
doing. Most processors require alignment of data, and using packed on
objects,classes and records may break this requirement. If this is the
case your code will simply crash on the target processors.</LI>
<LI>Clean up at the end of your program, i.e. close all files on exit,
as some operating systems don't like it when some files are left opened. </LI>
<LI>Try not to rely on the endian of the specific machines when doing
arithmetic operations. Furthermore, reading and writing of binary data
to/from files will probably require byte swaps across different endian
machines (swap is your friend in this case). This is even more important
if you write binary data to files. </LI>
<LI>Try limiting your local variables in subroutines to 32K, as this
is the limit of some processors, use dynamic allocation instead. </LI>
<LI>Try limiting the size of parameters passed to subroutines to 32K,
as this is the limit of some processors, use const or var parameters
instead. </LI>
</UL><BR>
<LI><A NAME="OOP"></A><H3>I tried to compile my Delphi code with the Free Pascal
Compiler, but it seems that it doesn't recognize Delphi style OOP.</H3>
<P>
The compiler supports the Delphi OOP. Make sure you use
the -S2 or -Sd switches (see the manuals for the meaning of these switches).
For a list of Delphi incompabilities also check the manual.
</P>
<LI><A NAME="HOMEWORK"></A><H3>I have to write a program for homework. Can you help?</H3>
<P>
No. Please, don't send us mail about homework, we are no teachers.
The Free Pascal development team tries to give good support for the Free
Pascal compiler and are trying to always reply to emails. If we get
emails like this, this becomes harder and harder.
</P>
<LI><A NAME="HowcanIbuildaunit"></A><H3>How can I build a unit?</H3>
<P>
It works like in Turbo Pascal. The first keyword in the file must be
UNIT (not case sensitive). The compiler will generate two files: <TT>XXX.PPU</TT>
and <TT>XXX.O</TT>. The PPU file contains the interface information for
the compiler and the O-file the machine code (an object file, whose precise
structure depends on the assembler you used). To use this unit in another
unit or program, you must include its name in the USES clause of your program.
</P>
<LI><A NAME="TurboVision"></A><H3>Will Free Pascal support TV (Turbo Vision) in the future?</H3>
<P>
A Turbo Vision port, called Free Vision, has progressed nicely lately. It's
already very usable, we are even writing an IDE in it. Due to copyrights
problem the FreeVision source code is not available at the moment. You can
download the IDE from the <A HREF="develop.html#snapshot">development</A> page. and get an idea of the look and feel though.
</P>
<LI><A NAME="CompileSystemUnit"></A><H3>How can I compile the system unit?</H3>
<P>
To recompile the system unit, it is recommended to have GNU make installed.
typing 'make' in the rtl source directory will then recompile all RTL units
including the system unit.
You may choose to descend into the directory of your OS (e.g. rtl/go32v2)
and do a 'make' there.
</P>
<P>
It is possible to do all this manually, but you need more detailed knowledge
of the RTL tree structure for that.
</P>
<LI><A NAME="Internalerror9999"></A><H3>I get an internal error 9999 or 10?</H3>
<P>
The latest versions of the Free Pascal Compiler come with an error handling
routine which catches the segmentation fault and lets the compiler to exit
gracefully. This is reported as an internal error 9999.
Please try to reproduce the error and send <A HREF="bugs.html">us</A>
a bug report.
</P>
<P>
(For the curious, IE 9999 is not a specific bug. It is a safety measure which
terminates if during compiling a certain condition is not met, which can be
caused by several bugs. So if you report the bug, and get IE 9999 later in
a different piece or part of sourcecode, it could be a completely different
bug. <b>IE 10</b> is something similar. It is a safety measure that is triggered
when the estimated number of registers needed to evaluate an expression proves 
wrong. Just like IE 9999, two IE 10 problems are often independant of eachother.)
</P>
<LI><A NAME="Howdoesfunctionoverloadingwork"></A><H3>How does function overloading work?</H3>
<P>
function overloading is implemented, like in C++:
</P>
<PRE>
procedure a(i : integer);
begin
end;
procedure a(s : string);
begin
end;
begin
a('asdfdasf');
a(1234);
end.
</PRE>
<P>
You must be careful. If one of your overloaded functions is in the interface
part of your unit, then all overloaded functions must be in the interface
part. If you leave one out, the compiler will complain with a 'This overloaded
function can't be local' message. Overloaded functions must differ in their
parameters, it's not enough if their return types are different.
</P>
<LI><A NAME="HowToCallCFuncuntions"></A><H3>How can I call C functions?</H3>
<P>
C calling convention is implemented as follows: The compiler pushes
the parameters from right to left, but the procedure has to clear the stack.
For calling the C function strcmp declare the following:
</P>
<PRE>
function strcmp(s1 : pchar;s2 : pchar) : integer;cdecl;external;
Since 0.99.5, the older [C]; won't work!
</PRE>
<LI><A NAME="HowToUseGraph"></A><H3>How can I use the graph unit with Free Pascal?</H3>
<P>
Since 0.99.12, the graph unit is available both for Dos and Linux. Under Dos,
it only supported VESA modes though. Since version 0.99.14, a new more system
independant graph unit is included (although the only extra supported OS is
Win32 and this is only rudimentary support) which also supports standard VGA.
</P>
<P>
Since version 1.0, we also have a completely platform independent way of selecting
resolutions and bitdepths. You are strongly encouraged to use it, because other ways
will probably fail on one or other platform. See the documentation of the graph unit
for more information.
<LI><A NAME="WrongColors"></A><H3>Why do I get wrong colors when using the graph unit?</H3>
<P>
If you use <TT>detect</TT> as graphdriver, you will end up with the highest supported
bitdepth. Since the graph unit currently only supports up to 16 bits per pixel modes and
since this bitdepth is supported by all graphics cards made in at least the last 5 years, you
will most likely get a 16 bit mode.
</P>
<P>
The main problem is that in 16 (and 15, 24, 32, ...) bit modes, the colors aren't set anymore
using an index in a palette (the palettized way is called "indexed color"). In these modes, the
color number itself determines what color you get on screen and you can't change this color. The
color is encoded as follows (for most graphics cards on PC's at least):
</P>
<UL>
<LI>15 bit color: lower 5 bits are blue intensity, next come 5 bits of green and then 5 bits of red. The
highest bit of the word is ignored.
<LI>16 bit color: lower 5 bits are blue intensite, next come *6* bits of green and then 5 bits of red.
</UL>
<P>
This means that either you have to rewrite your program so it can work with this so-called "direct color"
scheme, or that you have to use <TT>D8BIT</TT> as graphdriver and <TT>DetectMode</TT> as graphmode. This will ensure that
you end up with a 256 (indexed) color mode. If there are no 256 color modes supported, then graphresult
will contain the value <TT>GrNotDetected</TT> after you called InitGraph and you can retry with graphdriver <TT>D4BIT</TT>. Make sure you use
the constant names (D8BIT, D4BIT, ...) and not their actual numeric values, because those values can
change with the next release! That the very reason why such symbolic constants exist.
</P>
<LI><A NAME="IntegratedAssemblerSyntax"></A><H3>Integrated Assembler syntax</H3>
<P>
The default assembler syntax (AT&amp;T style) is different from the
one in Borland Pascal (Intel style).
</P>
<P>
However, as of version 0.99.0, the
compiler supports Intel style assembly syntax.
See the documentation for more info on how to use different assembler styles.
</P>
<P>
A description of the AT&amp;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>
or in Brennan's Guide to Inline Assembly <A HREF="http://www.rt66.com/%7Ebrennan/djgpp/djgpp&nbsp;asm.html">http://www.rt66.com/%7Ebrennan/djgpp/djgpp&nbsp;asm.html</A>.
The documentation also contains a chapter where the difference between
the Intel and AT&amp;T style assembly is explained.
</P>
<P>
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
</A>.
</P>
<LI><A NAME="HowToAccessDosMemory"></A><H3>How can I access DOS memory / How can I do graphics programming?</H3>
<P>
You can do like in TP, via absolute or mem[]. For larger memory blocks use the
dosmemput/dosmemget routines in Go32 unit.
</P>
<LI><A NAME="FPwithoutfpu"></A><H3>How can I run Free Pascal without a math coprocessor?</H3>
<P>
On the Intel version the emulator is automatically loaded by the compiler
if you add the following commands to your autoexec.bat:
</P>
<P>
<PRE>
SET 387=N
SET EMU386=C:\PP\BIN\GO32V2\WEMU387.DXE
</PRE>
(don't forget to replace the <TT>C:\PP</TT> with the directory where you installed FPC)
</P>
<LI><A NAME="AccessingMoreThan4MB"></A><H3>How do I reserve more than 2 megabytes of RAM?</H3>
<P>
By default Free Pascal allocates only 2MB of RAM for your application. If it just allocated all
it could get, people running Windows would have problems as Windows would
increase the swap file size to give the program more memory on and on,
until the swap file drive would be full.
</P>
<P>
You can specify the size of the heap with -Chxxxx. The default value
is -Ch4000000. Try -Ch10000000, provided you got enough swap space.
</P>
<P>
However, the heap size doesn't really matter anymore, since the Heap
is able to grow: if you've used all the available heap space, the
program will try to get more memory from the OS, so the heap is limited
to the maximum amount of free memory provided by the OS.
</P>
<P>
It is only handy if you know you will need at least a certain amount of memory.
You can then specify this value using the -Ch parameter, so your program will
allocate it at once on startup. This is slightly faster than growing the heap
a number of times.
</P>
<LI><A NAME="accessioports"></A><H3>How can I access I/O ports?</H3>
<P>
With versions before 0.99.10: if you're under DOS you can use the <TT>outport*</TT> and <TT>inport*</TT>
procedures of the go32 unit.
</P>
<P>
Since version 0.99.8, the Port array is supported like in TP, as long as you
use the ports unit in your program (not available under Win32).
</P>
<P>
I/O port access is possible under Linux, but that requires root privileges. Check
the manuals for the IOPerm, ReadPort and WritePort procedures. (Unit Linux)
</P>  
<LI><A NAME="ImusingWin95"></A><H3>I'm using the Dos compiler under Windows 95</H3>
<P>
There is a problem with the Dos compiler and Win 95 on computers with less
than 16 MB. First set in the properties of the DOS box the DPMI memory
size to max value. Now try to start a demo program in the DOS box, e.g.
HELLO (starting takes some time). If this works you will be able to get
the compiler to work by recompiling it with a smaller heap size, perhaps
2 or 4 MB (option -Chxxxx).
</P>
<LI><A NAME="ImusingOS2"></A><H3>I'm using OS/2</H3>
<P>
Problems have been reported that the GO32v2 compiler does not run on
some OS/2 installations. You can use the native OS/2 compiler (strongly
preferred solution) or maybe compile a GO32v1 compiler yourself. However,
the GO32v2 version should generally work under OS/2 as well.
</P>
<LI><A NAME="dpmi"></A><H3>INSTALL.EXE of Dos version 0.99.10 reports "Load error: no DPMI"</H3>
<p>
The file cwsdpmi.exe is missing in the main directory of the zip archive.
The above message pops up if no other DPMI services are available.
Such services are for example available in a Dos window of Windows.
You can either extract that file from basego32.zip or download it from
<a href="http://www.brain.uni-freiburg.de/%7Eklaus/cwsdpmi.exe">
http://www.brain.uni-freiburg.de/%7Eklaus/cwsdpmi.exe</a>.
Put it into the same directory as install.exe and run install again.
</p>
<LI><A NAME="instal10NT"></A><H3>INSTALL.EXE of version 1.0 for Dos returns an error (-2) in Windows NT 4.0</H3>
<P>
This is caused by long file names in some of the .ZIPs of the dosversion. A new installer 
will be generated that ignores the packages with long file names in it. Currently it is still being tested.
Alternatively, one could use the installer from the Win32 1.0 version under NT. This has the additional benefit 
that the archives with long filenames can be selected and installed too.
</P>  
<P>
The exact cause of this problem is that a NT 4.0 dosbox doesn't support long file names for dos programs.
Windows 95,98 and 2000 don't exhibit this problem.
</P>  
<P>
<ul>
<li>The current ZIPs on ftp have been updated with the new installer.</lI>
<lI>Dosw32100.zip, has now default the win32 installer, and the go32v2
installer packaged as installd.exe.
<li>If you already downloaded one of the large Dos zips, repeated downloading 
is not necessary, just download a new installer:<ul>
<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>
<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>
</ul></lI>
<li>If you downloaded an OS/2 version, and experience problems, you can try to download the new dos installer</lI>
</ul>
</P>
<LI><A NAME="snapshot"></A><H3>I want a new version NOW</H3>
<P>
In the time between the release of new official versions, you
can have a look at and test developer versions (so-called "snapshots").
Be warned though: this is work under progress, so in addition to
old bugs fixed and new features added, this may also contain new bugs.
</P>
<P>
Snapshots are generated automatically each night from the current
source at that moment. Sometimes this may fail due to bigger changes
not yet fully implemented. If your version doesn't work, try again one
or two days later. You're advised not to download the GO32v1 version for Dos,
since it's not supported any more.
</p>
<p>The latest snapshot can always be downloaded from the
<a href="develop.html#snapshot">development</a> web page.
</p>
<p>
To install a snapshot, extract the zip archive into the existing
program directory of the last official version of Free Pascal (after
making a backup of the original of course). You can also extract it into an
empty directory and then move the files to the program directory,
overwriting existing files. Make sure that you extract the ZIP archive
such that the included directory structure remains intact. For example
if you use PKUNZIP, use "pkunzip -d" instead of just "pkunzip".
Note that snpashots also contain a new RTL which most likely can't be
used with the previous release version, so backup your old RTL as well.
</p>
<LI><A NAME="ideinst"></A><H3>Where can I find a text mode IDE?</H3>
<p>
The development of the IDE (integrated development environment)
is not yet finished. However a working test version of the IDE is available
as snapshot. It requires the latest compiler snapshot be installed on
top of the current official version for your particular platform (1.00
for GO32v2 or Win32). So if you have not already done that, first install the latest official
version (e.g. file dos100.zip or dos100full.zip, you find these in
the <a href="download.html">download</a> section).
</p>
<p>
Then get and extract the latest snapshot for your platform (e.g. snapshot.zip)
into the directory containing the official version.
Next, do the same with one of the IDE snapshots.
For more details on where to find and how to install a snapshot,
please see the previous FAQ item. For additional instructions
for required IDE configuration please also read the next FAQ item.
</p>
<LI><A NAME="ideconfig"></A><H3>How do I configure the Dos IDE?</H3>
<p>
Once you have installed the IDE (see the previous FAQ item),
it requires two configuration changes before it can compile.
This is due to the fact that the IDE includes its own compiler;
it does not use ppc386.exe and thus it also does not use the
configuration in the file ppc386.cfg.
</p>
<p>
Start fp.exe, select Target from the Compile menu and then check GO32v2.
Next, choose Directories in the Otions menu and in the line "Unit directories"
enter the path to your copy of the rtl directory, usually c:\pp\rtl\go32v2.
If you have done everything correct and it still doesn't work,
you may have grabbed a snapshot that has a bug; in this case
try again one or two days later or ask for help on one of the
<A HREF="maillist.html">mailing lists</A>.
</p>
<LI><A NAME="binariesbig"></A><H3>Why are the generated binaries so big?</H3>
<p>
There are several reasons and remedies for this:
</p>
<p>
<ol>
<li>
<p>If you are using 0.99.12: Due to some problems with the binary writer, 0.99.12 wasn't
released with smartlinkable RTLs. Smartlinking causes only actually used procedures,
functions and constants to be linked in.</p>
<p>
You can remedy this by using a development version and creating a smartlinking
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
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.
</p></li>
<li>Normally, all symbol information is included in the resulting program (for
easier debugging). You can remove this by using the -Xs command line
option when compiling your program (it won't do anything when compiling
units)</li>
<lI>You can use UPX to pack the .EXEs (just like e.g. pklite) for Dos (GO32v2)
and Windows targets. Look <A HREF="http://wildsau.idv.uni-linz.ac.at/mfx/upx.html">here</A> for
more info.</lI>
<lI>You can use LXLITE for packing EMX binaries, but you won't be able to run
them under DOS (with extender) any more then. It might even not be possible
to use them on lower OS/2 versions (like 2.x) depending on chosen type
of compression. LXLITE can be found e.g. on <A HREF="http://hobbes.nmsu.edu">Hobbes</A>, search
for LXLITE.</li></li>
<li>Turn on optimalisations, both for supplied packages (RTL, API, FV, FCL) and for
your own code, this will also decrease the code size. 
</ol>
</p>
<LI><A NAME="systemnotfound"></A><H3>Unit system, syslinux, sysos2 or syswin32 not found errors</H3>
<p>
System (syslinux, sysos2 or syswin32, depending on platform) is Pascal's base unit which is implicitely used
in all programs. This unit defines several standard procedures and structures, and must
be found to be able to compile any pascal program by FPC.
</p>
<p>
The location of the system.ppu and syslinux.o files are determined by the -Fu
switch which can be specified commandline, but is usually in the ppc386.cfg
configuration file.
</p>
<p>
If the compiler can't find this unit there are three possible causes:
</p>
<ol>
<lI>The ppc386.cfg isn't in the same path as the compiler executable (go32v2, win32 and OS/2)
or can't be found as "/etc/ppc386.cfg" or ".ppc386.cfg" in your homedirectory (Linux). 
<li>The ppc386.cfg doesn't contain the -Fu line, or a wrong one.
See the <a href="makecyc.html">make cycle faq</a>, especially the chapters
about the ppc386.cfg and the directory structure.
<li>The files ARE found but the wrong version or platform. Correct ppc386.cfg to
point to the right versions or reinstall the right versions (this can happen
if you try to use a <A HREF="#snapshot">snapshot</A> compiler while the -Fu
statemnt in the used ppc386.cfg still points to the RTL that came with the
official release compiler).
</ol>
<p>
A handy trick can be executing &quot;ppc386 programname -vt&quot;, this shows
where the compiler is currently looking for
the system unit's files. You might
want to pipe this through more (Dos, OS/2, Windows) or less (Linux), since it can generate more than one screen information:
</p>
<P>
<pre>
Dos, OS/2, Windows:
ppc386 programname -vt |more<br>
Linux:
ppc386 programname -vt |less<br>
</pre>
</P>
<LI><A NAME="KnownBugs"></A><H3>Known bugs</H3>
<P>
Go to the <A HREF="bugs.html">bugs page</A>
</P>
<LI><A NAME="ErrorPos"></A><H3>How can I find where an error occurred using the addresses a crashed program prints?</H3>
<OL>
<LI>Starting with version 1.00, the easiest possibility is to recompile
your program with -gl debugging option. This way unit LineInfo is
automatically linked in, and the printout after a program crash then
contains source line numbers in addition to addresses. To see RTL functions in the backtrace
with their real name, you have to recompile the RTL with -gl too.</LI>
<LI>For older versions, or more comprehensive checking, compile the program
with debugging information (use the -g command line option)</LI>
<LI>Load the program in the debugger (gdb(w) for 0.99.12b and earlier, gdbpas(w)
for 0.99.14 and later) using
<pre>gdb(pas)(w) --directory=&LT;src dirs&GT; myprog.exe</pre>
Notes:
<UL>
<LI>Under Linux, don't add the ".exe" after myprog</LI>
<LI>"<TT>src dirs</TT>" is a list of directories containing the source code
files of myprog and the units it uses seperated by semi-colons (";").
The current directory is automatically included.</LI>
</UL>
<LI>Once inside the debugger, you can (optionally) set the command line options
that will be passed to your program using the command "<TT>set args &LT;option1
option2 ...&GT;</TT>"</LI>
<LI>To start the program, type "<TT>run</TT>" and press enter</LI>
<LI>After the program has crashed, the address of the instruction where the crash
occurred will be shown.
The debugger will try to display the source code line corresponding with this
address. Note that this can be inside a procedure of the RTL, so the source
may not always be available and most likely the RTL wasn't compiled with
debugging information.</LI>
<LI>If you then type "<TT>bt</TT>" (BackTrace), the addreses in the call stack will
be shown (the addresses of the procedures which were called before the program
got to the current address). You can see which source code lines these present
using the command <pre>info line *&LT;address&GT;</pre>For example:<pre>info line *0x05bd8</pre> </LI>
</OL>
</ol>
<BR></TD>
</TR>
</TABLE>
</BODY>
</HTML>