This file is indexed.

/usr/share/doc/fp-compiler/2.4.4/faq.html is in fp-compiler-2.4.4 2.4.4-3.1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Free Pascal - Knowledge base</title>
</head>

<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF8080">
<h1>FAQ / Knowledge base</h1>







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



  <p> For more comprehensive information on the pascal language, and the runtime library
  calls, consult the Free Pascal manuals. Topics covered in this document : 


<OL>
    <li>General information
   <OL>
    <li><a href="#WhatIsFP">What is Free Pascal (FPC)?</a>
    <li><a href="#versions">Which versions exist, and which one should I use?</a>
    <li><a href="#FPandGNUPascal">Free Pascal and GNU Pascal - a comparison</a>
    <li><a href="#general-license">License and copyright information</a>
    <li><a href="#WhereToGetFP">Getting the compiler</a>
    <li><a href="#general-install">Free Pascal installation hints</a>
    <li><a href="#ftpproblems">Why do i have to supply a user name and password to get Free Pascal ?</a>
    <li><a href="#general-connectftp">Access denied error when connecting to the Free Pascal FTP site</a>
    <li><a href="#snapshot">I want a new version NOW</a>
    <li><a href="#installsnap">Installing a snapshot</a>
    <li><a href="#HOMEWORK">I have to write a program for homework. Can you help?</a>
    <li><a href="#windowsapp">How do I make a real Windows application with windows and menu bars?</a>
    <li><a href="#game">How do I make a game with Free Pascal? Can I make a game like Doom 3?</a>
    <li><a href="#ErrorPos">Getting more information when an application crashes</a>
    <li><a href="#general-heap">Increasing the heap size</a>
    <li><a href="#general-doesntfindfiles">Compiler seems to skip files in directories -Fu points to</a>
    <li><a href="#binariesbig">Why are the generated binaries so big?</a>
    <li><a href="#cfgfiles">Configuration file problems (fpc.cfg or ppc386.cfg)</a>
    <li><a href="#runerror">Runtime errors</a>
    <li><a href="#stdunits">Standard units</a>
    <li><a href="#debugsmart">Debugging smartlinked code does not fully work</a>
    <li><a href="#debugshared">Debugging shared library (dynamic linked library) code does not fully work</a>
    <li><a href="#cantfindunit">PPU files binary compatibility between versions</a>
    <li><a href="#cantfindunit">Can't compile a program using a binary only version of a unit</a>
    <li><a href='#isoxpascal'>Will you support ISO Extended Pascal?</a>
    <li><a href="#dotnet">What about .NET?</a>
   </OL>
   <li>Pascal language related information
   <OL>
    <li><a href="#PortingCPU">Considerations in porting code to other processors</a>
    <li><a href="#PortingOS">Considerations in porting code to other operating systems</a>
    <li><a href="#OOP">Compiling Delphi code using Free Pascal</a>
    <li><a href="#HowcanIbuildaunit">Building a unit</a>
    <li><a href="#CompileSystemUnit">Compiling the system unit</a>
    <li><a href="#Howdoesprocedureoverloadingwork">How does function overloading work?</a>
    <li><a href="#HowToCallCFuncuntions">Calling C functions</a>
    <li><a href="#IntegratedAssemblerSyntax">Integrated Assembler syntax</a>
    <li><a href="#systemnotfound">Unit system not found errors</a>
    <li><a href="#extensionselect">There is a new extension that will be really useful. Will you include it?</a> 
    </OL>
   <li>Runtime library related information
   <OL>
    <li><a href="#HowToUseGraph">Using the graph unit with Free Pascal</a>
    <li><a href="#WrongColors">Why do I get wrong colors when using the graph unit?</a>
    <li><a href="#fileshare">File sharing and file locks</a>
    <li><a href="#filemode">File denied errors when opening files with reset</a>
   </OL>
   <li>DOS related information
   <OL>
    <li><a href="#dos-release">Releasing software generated by the DOS compiler</a>
    <li><a href="#dos-debugging">Debugging</a>
    <li><a href="#dos-dll">Dynamic libraries</a>
    <li><a href="#dos-profile">Profiling</a>
    <li><a href="#FPwithoutfpu">Running Free Pascal without a math coprocessor</a>
    <li><a href="#fp386">Applications created with Free Pascal crash on 80386 systems</a>
    <li><a href="#nomousegraph">The mouse cursor is not visible in graphics screens</a>
    <li><a href="#accessioports">Accessing I/O ports</a>
    <li><a href="#HowToAccessDosMemory">Accessing DOS memory / Doing graphics programming</a>
    <li><a href="#dos-stack">Changing the default stack size</a>
    <li><a href="#dos-os2">Using OS/2 generated applications under DOS</a>
   </OL>
   <li>Windows related information
   <OL>
    <li><a href="#win-release">Releasing software generated by the windows compiler</a>
    <li><a href="#win-debugging">Debugging</a>
    <li><a href="#win-dll">Dynamic libraries</a>
    <li><a href="#win-profile">Profiling</a>
    <li><a href="#win-graph">Graph and problems with keyboard, mouse and "dummy dos windows"</a>
    <li><a href="#win-cygwin">Cygwin binary directory in your path sometimes causes builds to fail</a>
    <li><a href="#win95-fpc">Using the DOS compiler under Windows 95</a>
    <li><a href="#win-os2">Using OS/2 generated applications under Windows</a>
    <li><a href="#win-dos">Using DOS generated applications under windows</a>
    <li><a href="#win-ide-mouse">The mouse cursor does not respond in the Windows IDE</a>
  </OL>
   <li>UNIX related information
   <OL>
    <li><a href="#unix-release">Releasing software generated by the unix compilers</a>
    <li><a href="#unix-debugging">Debugging</a>
    <li><a href="#unix-dll">Dynamic libraries</a>
    <li><a href="#unix-profile">Profiling</a>
    <li><a href="#libci386">Libc is missing on platforms other than i386</a>
    <li><a href="#vgamissing">Why can't the linker find "vga"?</a>
    <li><a href="#unix-asldmissing">Compiler indicates missing as and ld</a>
    <li><a href="#unix-ld219">An error occurred while linking, or &quot;did you forget -T?&quot;</a>
   </OL>
   <li>OS/2 related information
   <OL>
    <li><a href="#os2-release">Releasing software generated by the OS/2 compiler</a>
    <li><a href="#os2-debugging">Debugging</a>
    <li><a href="#os2-dll">Dynamic libraries</a>
    <li><a href="#os2-profile">Profiling</a>
    <li><a href="#os2-dos">Using DOS generated applications under OS/2</a>
    <li><a href="#instal106os2">INSTALL.EXE of version 1.0.6 or below returns an unknown error (-1) under OS/2</a>
    <br>or<br>
    <a href="#instal106os2">INSTALL.EXE of version 1.0.6 or above complains about missing TZ variable under OS/2</a>
    <li><a href="#os2-fp">OS/2 compiler not working after upgrading to 1.9.6 or newer</a>
    <li><a href="#os2-as-failing">Compilation under OS/2 fails with error "Can't call the assembler"</a>
   </OL>
   <li>BeOS related information
   <OL>
    <li><a href="#beos-release">Releasing software generated by the BeOS compiler</a>
    <li><a href="#beos-debugging">Debugging</a>
    <li><a href="#beos-dll">Dynamic libraries</a>
    <li><a href="#beos-profile">Profiling</a>
    <li><a href="#beos-linking">BeOS linking problems</a>
   </OL>
   <li>Amiga related information
   <OL>
    <li><a href="#amiga-release">Releasing software generated by the Amiga compiler</a>
    <li><a href="#amiga-debugging">Debugging</a>
    <li><a href="#amiga-dll">Dynamic libraries</a>
    <li><a href="#amiga-profile">Profiling</a>
   </OL>
   <li>PalmOS related information
   <OL>
    <li><a href="#palmos-release">Releasing software generated by the PalmOS compiler</a>
    <li><a href="#palmos-debugging">Debugging</a>
    <li><a href="#palmos-dll">Dynamic libraries</a>
   </OL>
   
</OL>

 <OL>
   <li><h2>General information</h2>
   <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
            and 64 bit Turbo Pascal and Delphi compatible Pascal compiler for
            DOS, Linux, Win32, OS/2, FreeBSD, AmigaOS, Mac OS X, Mac OS classic and
            several other platforms (the number of supported targets grows
            all the time, although not all of them are on the same level as
            the main ones).
	
            <p>The Free Pascal compiler is available for several
            architectures, x86, Sparc (v8,v9), ARM, x86_64 (AMD64/Opteron)
            and Powerpc. An older version (the 1.0 series) also supports
            m68k.
  	  	
            <p>The compiler is written in Pascal and is able to compile its
            own sources. The source files are under GPL and included.

            <p>Short history:
            <ul>
              <li>06/1993: project start
              <li>10/1993: first little programs work
              <li>03/1995: the compiler compiles the own sources
              <li>03/1996: released to the internet
              <li>07/2000: 1.0 version
              <li>12/2000: 1.0.4 version
              <li>04/2002: 1.0.6 version
              <li>07/2003: 1.0.10 version
              <li>05/2005: 2.0.0 version
              <li>12/2005: 2.0.2 version
              <li>08/2006: 2.0.4 version
              <li>09/2007: 2.2.0 version
              <li>08/2008: 2.2.2 version
              <li>04/2009: 2.2.4 version
	      <li>12/2009: 2.4.0 version
              <li>11/2010: 2.4.2 version  
              <li>04/2011: 2.4.4 version  (expected)
            </ul>
            

        <li><a name='versions'></a>
          <h3>Which versions exist, and which one should I use?</h3>
          
            <p>The latest official version is 2.4.4, the second bugfix release of the 2.4.x series
            New development is performed in 2.5.x series, which eventually
            gets released as 2.6.0 or 3.0.0, depending on milestones achieved.

            <h4>Historic versions</h4>

            <p>FPC's version numbering changed a few times over the years. Pre 1.0 versioning
			moved to the <a href="http://wiki.freepascal.org/1.0_versioning">Wiki 1.0 versioning article.</a>

            <h4>Modern versioning</h4>

            <p>Together with the release of 1.0 the version numbering was
            slightly changed, and a system in versioning resembling the Linux
            kernels has been introduced. 

            <p>
            <ul>
             <li>Releases that only fix bugs in version 1.0 are numbered 1.0.x.
             <li>Post 1.0 development (the so called snapshots) have version number
              1.1.x.
             <li>Eventually the 1.1.x versions, when stabilized were released
              as the 2.0.x series, preceded by betas marked as 1.9.x. Fixes on
              2.0 release were numbered 2.0.x, fixes on 2.2 release 2.2.x.</li>
             <li>The new development after the 2.2.0 release is numbered 2.3.x
              and so on.
			  <li>Repackagings that affect sources are indicated with a single letter as 
			      suffix (e.g. 2.0.4a), this is usually the case for platforms that weren't part of the original release round.
            </ul>
            <p>

            <p>Normally you would want to use a release. Releases are considered
            stable, and easier to support (the bugs, quirks and unintended
            "features" are well known after a period of time, and workarounds
            exist).

            <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>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>We advise all users to upgrade to the newest version for their
            target (Preferably the new stable 2.2.x series).

            <p> A graphical timeline of the FPC project plus its near future would
            be:
            <img src="pic/timeline.png">
          

        <li><a name='FPandGNUPascal'></a>
          <h3>Free Pascal and GNU Pascal - a comparison</h3>
          
            <DL>
            <DT><b>Aim:</b>
            <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.
            <DT><b>Version:</b>
            <DD>Currently, Free Pascal is at version 2.4.4 (April 2011). GNU Pascal is at
            version 2.1 (from 2002, which can be built with several different GCC's as backend; 
            their Mac OS X version is an exception though, as it follows the GCC version number).
            <DT><b>Tracking:</b>
            <DD>Between releases, development versions of FPC are available through daily snapshots
	        and the source via SVN. GPC issues a set of patches to the last version a few times 
            a year, and there are regular snapshot for OS X and Windows, made by users.
            <DT><b>Operating systems:</b>
            <DD>Free Pascal runs on a large amount of platforms of OSes,
            e.g. DOS, Win32 (no Unix porting layer needed), Linux, FreeBSD,
            NetBSD, OS/2, BeOS, Classic Mac OS, Mac OS X, and AmigaOS, on,  at
            the moment the following architectures: x86,
            x86_64 (AMD64), Sparc, PowerPC, ARM and Motorola (Motorola only in version 1.0.x).

            GNU Pascal runs basically on any system that can run GNU C, and for which the buildprocess was verified.
            <DT><b>Bootstrapping:</b>
            <DD>FPC requires a suitable set of binutils (AS,AR,LD) on some platforms, gmake and a commandline compiler. New architectures/OSes are crosscompiled.
	        GPC bootstraps via a suitable version of GCC, and requires a full set of binutils, flex, bison, gmake, a POSIX shell and libtool 
            <DT><b>Sources:</b>
            <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)
            <DT><b>Language:</b>
            <DD>Free Pascal supports the Borland Pascal dialect, 
            implements the Delphi Object Pascal language and has some Mac Pascal extensions.
            GNU Pascal supports ISO 7185, ISO 10206, (most of) Borland Pascal 7.0
            <DT><b>Extensions:</b>
            <DD>Free Pascal implements method, function and operator overloading. (later Delphi versions add these, so strictly not an extension anymore)
            GNU Pascal implements operator overloading.
            <DT><b>License:</b>
            <DD>Both compilers come under the GNU GPL.
            <DT><b>Author:</b>
            <DD>Free Pascal was started by Florian Kl&auml;mpfl, Germany
            (florian&#x040;freepascal.org), GNU Pascal was started by Jukka Virtanen,
            Finland (jtv&#x040;hut.fi). </DD></DL><br>
          


        <li><a name='general-license'></a>
          <h3>License and copyright information</h3>
          
            <p> Applications created by the compiler and using the runtime
            library come under a modified library gnu public license (LGPL),
            which permit no restriction on the type of license the application
            has. It is therefore possible to create closed source
            or proprietary software using Free Pascal.
            

            <p>This extra exception to the LGPL is added:<br><I> As a special
            exception, the copyright holders of this library give you
            permission to link this library with independent modules to
            produce an executable, regardless of the license terms of
            these independent modules, and to copy and distribute the
            resulting executable under terms of your choice, provided
            that you also meet, for each linked independent module, the
            terms and conditions of the license of that module. An
            independent module is a module which is not derived from or
            based on this library. If you modify this library, you may
            extend this exception to your version of the library, but
            you not obligated to do so. If you do not wish to do so,
            delete this exception statement from your version.</I>

            Please note that you still have to comply to the LGPL, which, for example,
            requires you to provide the source code of the runtime library. If you want
            to write proprietary closed source software, please do this to comply:
            <ul>
              <li>Most people can satisfy the source code requirement by mentioning
              the rtl source code can be downloaded at the Free Pascal
              web site: if you did not modify the rtl this is considered adequate to
              satisfy the LGPL requirement of providing source code.
              <li>If you made modifications to the runtime library, you cannot keep them
              for yourself, you must make them available if requested.
              <li>Distribute the LGPL license with your product.
            </ul>

            <p> The compiler source code, on the other hand, comes under
            the GNU Public license, which means that any usage of the compiler
            source can only be used in software projects which have the same
            license. 
          

        <li><a name='WhereToGetFP'></a>
          <h3>Getting the compiler</h3>
          
            <p>The latest official stable Free Pascal release is available for download
            from all <a href="http://www.freepascal.org/download.var">official mirrors</a>
          

        <li><a name='general-install'></a>
           <h3>Free Pascal installation hints</h3>
           
             <ul>
               <li> Do not install the compiler in a directory which contains spaces
                    in its name, since some of the compiler tools do not like these 
             </ul>
           


        <li><a name='ftpproblems'></a>
          <h3>Why do i have to supply a user name and password to get Free Pascal ?</h3>

          
            <p> You are trying to login in to an ftp site. You must use the login name:
            anonymous and as your password, you should put your e-mail address.
          
        

        <li><a name='general-connectftp'></a>
          <h3>Access denied error when connecting to the Free Pascal FTP site</h3>

          
            <p>The Free Pascal main ftp site can only accept a maximum number of
            simultaneous connections. If this error occurs, it is because
            this limit has been reached. The solution is either to wait and
            retry later, or better still use one of the Free Pascal mirror sites.
          
        

        <li><a name='snapshot'></a>
          <h3>I want a new version NOW</h3>

          I want a new version NOW
            <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>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. 

            <p>The latest snapshot can always be downloaded from the <A
            href="http://www.freepascal.org/develop.var#snapshot">development</a>
            web page. 
          
        

        <li><a name='installsnap'></a>
          <h3>Installing a snapshot</h3>

          
            <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. 

            <p> Make sure that you extract the ZIP archive such that the included
            directory structure remains intact. For example if you use PKUNZIP,
            use "pkunzip -d" instead of just "pkunzip" (InfoZIP unzip doesn't
            require any special parameters). Note that snapshots also
            contain a new RTL which most likely can't be used with the previous
            release version, so backup your old RTL as well. 
          
        

        <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. 
          

        <li><a name="windowsapp"></a>
          <h3>How do I make a real Windows application with windows and menu bars?</h3>

          
            The easiest way is to <a href='http://www.lazarus.freepascal.org'>download Lazarus</a>.
            It won't be just a Windows application, it will also work under Linux, FreeBSD and
            Mac OS X.
          
        
        <li><a name="game"></a>
          <h3>How do I make a game with Free Pascal? Can I make a game like Doom 3?</h3>
          
            Yes, you can make games with Free Pascal and if you are really good you can make
            a game like Doom 3. Making games is difficult, you need to be an experienced
            programmer to make them. The web site <a href='http://www.pascalgamedevelopment.com'>
            www.pascalgamedevelopment.com</a> is a community of people who program games in Free
            Pascal and Delphi.
            <p>
            If you want a start, please start to study <a href='http://www.delphi-jedi.org/Jedi:TEAM_SDL_HOME'>JEDI-SDL</a>
            or <a href='http://ptcpas.sourceforge.net'>PTCPas</a>. Also you can try to study an existing game, for example
            <a href='http://thesheepkiller.sourceforge.net'>The Sheep Killer</a> is a very simple game and it should not be
            very hard to understand its code.
          
        
        <li><a name='ErrorPos'></a>
          <h3>Getting more information when an application crashes</h3>
          
            <OL>
                <li>The easiest possibility is to recompile your program with -gl
                debugging option. This way unit LineInfo is automatically linked in,
                and the printout after a program crash then contains source line
                numbers in addition to addresses of the crash. To see runtime library (RTL)
                functions in the backtrace with their real name, you have to recompile
                the RTL with -gl too.
                <li>For more comprehensive checking, compile the
                program with debugging information (use the -g command line option) 
                <li>Load the program in the debugger <PRE>gdb(pas)(w) --directory=&lt;src dirs&gt; myprog.exe</PRE>Notes:
                <ul>
                    <li>Under UNIX systems (Linux, the BSD's), don't add the ".exe" after myprog
                    <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.
                </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>To start the program, type "<TT>run</TT>" and press enter
                <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>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>
            </OL>
          


        <li><a name='general-heap'></a>
          <h3>Increasing the heap size</h3>
          
            <p>By default Free Pascal allocates a small part of RAM for your
            application as heap memory. If it just allocated all it could get,
            people running Windows would have problems as Windows would increase
            the swap file size to give the program more memory on and on, until
            the swap file drive would be full. 

            <p>You can specify the size of the heap with -Chxxxx. 

            <p>However, the heap size doesn't really matter, since the Heap
            is able to grow: if you've used all the available heap space, the
            program will try to get more memory from the Operating system (OS),
            so the heap is limited to the maximum amount of free memory provided by
            the OS. 

            <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.
          
         


        <li><a name='general-doesntfindfiles'></a>
          <h3>Compiler seems to skip files in directories that -Fu points to</h3>
          
            <p>This sometimes happens with installation/compilation scripts if the
            copying command doesn't preserve dates. The object files get older than
            the PPU file, and the compiler tries to recompile them. A simple <TT>touch</TT>
            will solve it. 
            <p>
	        Also note that FPC, contrary to Turbo Pascal keeps track of includefiles. Modified
            includefiles or duplicate names might trigger an attempt at recompiling
          
        

        <li><a name='binariesbig'></a>
          <h3>Why are the generated binaries so big?</h3>
          
            There are several reasons and remedies for this: 

            <OL>
                <li>
                    You can create smartlinked applications. To turn on
                    the generation of smartlinkable units, use the -Cx command
                    line option when compiling your units. To turn on
                    the linking of previously generated smarlinkable units, use the -XX
                    (-XS in 0.99.12 and earlier) command line option when compiling a
                    program. 
                <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>You can use UPX to pack the .EXEs (just like e.g. pklite) for Dos
                    (GO32v2) and Windows targets. Look <A
                        href="http://upx.sourceforge.net/">here</a> for
                    more info.
                <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. This issue is
                    not relevant for native OS/2 binaries compiled for target OS2 with
                    version 1.9.x and above, because these don't run under DOS anyway.
                    In addition, it might not be possible to use compressed binaries
                    on lower OS/2 versions (like 2.x) depending on chosen type of
                    compression. LXLITE can be found e.g. on
                    <a href="http://hobbes.nmsu.edu/">Hobbes</a>, search for LXLITE.
                <li>Turn on optimalisations, both for supplied packages (RTL, FV, FCL)
                    and for your own code, this will also decrease the code size. 
                <li>Keep in mind that under Windows NT/2k/XP/Vista, compressed binaries startup	
		            relatively slow. Test under various conditions (OS, CPU speed, memory)
                    if the behaviour is acceptable before compressing			   
           </OL>

            Generally Free Pascal generates smaller binaries than modern competing compilers,
            however, it doesn't hide code in large dynamic libraries. Free Pascal generates
            larger binaries than compilers from long ago do. Large framework libraries result
            in larger executables.
			
			See also the <a href="http://wiki.freepascal.org/Size_Matters">Size Matters wiki entry</a>.
          
        


        <li><a name=cfgfiles></a>
          <h3>Configuration file problems (fpc.cfg or ppc386.cfg)</h3>
          
            <p> Starting from version 1.0.6 of Free Pascal, the configuration
            file is called <TT>fpc.cfg</TT> instead of <TT>ppc386.cfg</TT>.
            For backward compatibility , <TT>ppc386.cfg</TT> is still searched first
            and, if found, is used instead of <TT>fpc.cfg</TT>. 
			
			<p> Since 1.0.6 is now over 5 years old, 
			the <TT>ppc386.cfg</TT> support will be phased out. 2.2.2 will warn, and 2.4.0 will no longer search <TT>ppc386.cfg</TT>

            <p> Versions prior to Free Pascal 1.0.6 do not recognize <TT>fpc.cfg</TT>,
            so if you wish to use an earlier version of the compiler using the
            same configuration file used with FPC version 1.0.6 (or later),
            the configuration file should be renamed to <TT>ppc386.cfg</TT>.
          
        


        <li><a name='runerror'></a>
          <h3>Runtime errors</h3>
          
            <p> When there is abnormal termination of an application generated
            by Free Pascal, it is very probable that a runtime error will be
            generated. These errors have the form : 

            <PRE>
            Runtime error 201 at $00010F86
              $00010F86  main,  line 7 of testr.pas
              $0000206D
            </PRE>

            <p> The 201 in this case indicates the runtime error
            number. The definition of the different runtime error numbers is
            described in the Free Pascal user's manual, Appendix D. The
            hexadecimal numbers represent the call stack when the error occured.
          
            

        <li><a name='stdunits'></a>
          <h3>Standard units</h3>
          
            <p> To see the list of base units supplied with Free Pascal, and
            on which platform they are supported, consult the Free Pascal user's manual.
            There is also a short description of what each unit does in the same section
            of the manual.
          

<!--
        <li><a name=internaldocs></a>
           <h3>How does the compiler work internally?</h3>
           <p>A draft document describing the internals of the Free Pascal compiler is
           available <a href="ftp://ftp.freepascal.org/pub/fpc/docs/fpc-int10.zip">here</a>.
           
-->
        

        <li><a name=debugsmart></a>
          <h3>Debugging smartlinked code does not fully work</h3>
          
            <p>Debugging smart linked code might not work correctly. This is
            due to the fact that no type information is emitted for
            smartlinked code. If this would not be done, the files
            would become enormous.
           
            <p> While debugging, it is not recommended to use the
            smartlinking option.
          

        

        <li><a name=debugshared></a>
          <h3>Debugging shared library (dynamic linked library) code does not fully work</h3>

          
            <p>Debugging shared libraries (or dynamic linked libraries) produced
              by the Free Pascal compiler is not officially supported.
          
           

        


        <li><a name='cantfindunit'></a>
          <h3>PPU files binary compatibility between versions</h3>
          <h3>Can't compile a program using a binary only version of a unit</h3>

          
            <p>
            Sometimes, even though there is a binary version of a module (unit file and object file)
            available, the compiler still gives compilation errors. This can be caused either by an
            incompatibility in the PPU file format (which should change only between
            major versions of the compiler), or by a change in one of the units of the RTL
            which has changed in between releases.
            

            <p>
            To get more information, compile the code using the -va (show all information)
            compiler switch, and the unit loading phase will be displayed. You might
            discover that the unit being loaded requires to be recompiled because one
            of the unit it uses has changed.
            

            <p>So if you plan on distributing a module without the source code, the binaries
               should be compiled and made available for all versions of the compiler you
               wish to support, otherwise compilation errors are bound to occur.
            

            <p>In other words, the unit (PPU) file format does not change significantly
               in between minor releases of the compiler (for exemple : from 1.0.4 and 1.0.6)
               which means they are binary compatible, but because the interface of the units
               of the RTL certainly changes between versions, recompilation will be required
               for each version anyways.
          

        
         
        <li><a name='isoxpascal'></a>
          <h3>Will you support ISO Extended Pascal?</h3>
          
       FPC's primary goal is to be a Turbo Pascal and Delphi-compatible compiler, and it also
       supports a subset of the Mac-Pascal dialect.  All of these are incompatible to some extent
       with the ISO Standard and Extended Pascal languages.  While in theory it would be possible
       to add a separate ISO Standard or Extended Pascal mode, until now no people interested in
       such functionality have stepped up to work on such features.
       <p>
       <a href="http://www.gnu-pascal.de/">GNU-Pascal</a> is however a modern compiler that can
       compile ISO Extended Pascal. If you have any need for the ISO Extended Pascal dialect, we
       recommend you to take a look at this compiler.
         


        <li><a name='dotnet'></a>
          <h3>What about .NET?</h3>
          
	   Occasionally, users ask about a FPC that supports .NET, or our
	   plans in that direction. <p>

	   Mainly the users are either interested because of .NET's
	   portability aspects (Mono is quoted over and over again), or
	   because it is supposed to be the next big thing in Windows
	   programming, and they think windows programming won't be possible
	   in the future.<p>

           While the FPC core developpers are somewhat interested out of
	   academic curiousity (mainly because it could be a pilot for a
	   generalized backend creating bytecode) there are however several
	   problems with .NET in combination with FPC:
	   	
        <OL> 
        <li>
           Pascal is a language that uses pointers, and existing codebases
	   can only be unmanaged. Unmanaged code is not portable under .NET,
	   so that already kills most possible benefits. This also means that
	   existing FPC and Delphi code won't run on .NET. There are more
	   such little language problems.</li>

	<li>FPC's libraries don't base on .NET classes and datamodels (and
 	   can't be changed to do so without effectively rewriting them),
 	   moreover the libraries could only be unmanaged too, or they
	   would be incompatible</li>

 	<li>There is nothing <em>practical</em> known yet about how portable
	    an average .NET program will be. Little experiments with hello
	    world level code mean nothing, that kind of code works with
	    nearly any language. A good test would be to see existing non trivial
	    codebases run unmodified under mono, that were not designed with mono
            in mind. Just like we try to do for
	    Delphi</li>

        <li> The fact that on Windows 80% of the .NET code seems to be
 	    ASP.NET doesn't help either. This makes porting existing code
 	    less useful (since ASP.NET is tied to IIS), and new codebases of
 	    portable code can be set in nearly every language </li>
	   
 	<li>Operating System dependant code wouldn't work anymore, since
	     the win32 interface is unmanaged. 
	</OL> <p>
        
    So effectively this means that for FPC to benefit from .NET you
    would have to significantly adapt the language (thus compiler) and
    libraries, and be incompatible with the existing native sourcecode.
    This is not adding support for .NET in FPC, but reimplementing FPC
    on .NET from near scratch without backwards compatibility. Moreover
    that also means that existing apps would have to be rewritten for
    .NET, since it would take more than a simple recompile with a
    FPC/.NET compiler.<p>

    While unmanaged code has some uses (allows to integrate with managed
    code inside windows easier), this still needs a codegenerator
    backend to be written, interfaces and libraries defined, for little
    practical use. This means a <b>lot of work</b> and since .NET take
    up is not really high, this might not be worth it, since an
    unmanaged FPC/.NET would only be minimally used. <p>

    However if a FPC user does the bulk of the work (e.g. a bytecode
    codegenerator, and maybe some base libraries) and if the work is
    suitable for inclusion in FPC (a very big if), we will of course
    include it.<p>

    These problems are pretty much similar for the Java (bytecode) too. 
    One has to mutilate the language, and rewrite the libraries from
    scratch on the base libraries of the target (Java/.NET). Such an
    attempt would have little synergy with the FPC project as it is
    today.<p>
                 

   </OL>
   <li><h2>Pascal language related information</h2>
   <OL>

        <li><a name='PortingCPU'></a>
          <h3>Considerations in porting 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. 
            <ul>
              <li>Limit your use of asm statements unless it is time critical code
              <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. Freepascal defines 
              <CODE>ENDIAN&#x5F;LITTLE</CODE> or <CODE>ENDIAN&#x5F;BIG</CODE> to indicate the
              target endian. 
              <li>Try limiting your local variables in subroutines to 32K, as this
              is the limit of some processors, use dynamic allocation instead.
              <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>The <TT>CPU32</TT> or <TT>CPU64</TT> (defined by FPC starting 
              from version 1.9.3) are defined indicating if the target is a 32-bit or 
              64-bit cpu; This can help you separate 32-bit and 64-bit specific code. 
              
              <li>Use the <TT>ptruint</TT> type (defined by FPC starting 
              from version 1.9.3) when declaring an ordinal that will store
              a pointer, since pointers can be either 32-bit or 64-bit depending on
              the processor and operating system. 
            </ul>
          
        
        <p>

        <li><a name='PortingOS'></a>
          <h3>Considerations in porting code to other operating systems</h3>

          
            <p>Because the compiler supports several different operating systems,
            is important to take a few precautions so that your code will execute
            correctly on all systems. 
            <ul>
              <li>File sharing is implemented differently on different operating
              systems, so opening already opened files may fail on some operating
              systems (such as Windows). The only correct way to make sure to
              have the same file sharing behavior is to use the I/O routines
              furnished in <TT>sysutils</TT>. 
              <li>Clean up at the end of your program, i.e. close all files on exit, and
              release all allocated heap memory, as some operating systems don't like it
              when some things are left allocated or opened.
              <li> Some operating systems limit the local stack space which can be allocated,
              therefore it is important to limit subroutine nesting, and the amount of
              local variables. Limiting total stack space usage at a given moment to
              at most 256 KBytes while make porting easier.
              <li> Do not hard code paths to files, try to use relative paths
              instead 
              <li> Use the following constants (defined in the system unit)
              to get information on files, line endings, and to build paths:
                  <ul>
                    <li> <TT>LineEnding</TT> : Indicates the characters which end a text line
                    <li> <TT>LFNSupport</TT> : Indicates if long filenames are supported (more then 8.3 characters)
                    <li> <TT>DirectorySeparator</TT> : The character or characters which separate path components 
                    <li> <TT>DriveSeparator</TT> : The character which separate the drive specification from the rest
                           of the path
                    <li> <TT>PathSeparator</TT> : The character which separates directories in the search path environment
                    <li> <TT>FileNameCaseSensitive</TT> : Boolean indicating if the filenames for this system are case-sensitive or not
                    <li> <TT>AllFilesMask</TT> : String containing a wildcard expression for all files
                  </ul>
               It is also possible to use the <TT>PathDelim</TT>, <TT>PathSep</TT> and <TT>DriveDelim</TT> constants
               defined in <TT>sysutils</TT>.
              
            </ul>
          
        
        <p>

        <li><a name='OOP'></a>
          <h3>Compiling Delphi code using Free Pascal</h3>
          

            <p>The compiler supports the Delphi classes. Make sure you use the -S2 or
            -Sd switches (see the manuals for the meaning of these switches). For a
            list of Delphi incompatibilities also check the manual. 
                  

        <li><a name='HowcanIbuildaunit'></a>
          <h3>Building 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.
           
        

        <li><a name='CompileSystemUnit'></a>
          <h3>Compiling 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>It is possible to do all this manually, but you need more detailed
            knowledge of the RTL tree structure for that. 
                  


        <li><a name='Howdoesprocedureoverloadingwork'></a>
          <h3>How does procedure overloading work?</h3>

          
            <p>Here is a procedure overloading example:
            <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. 
          

        <li><a name='HowToCallCFuncuntions'></a>
          <h3>Calling C functions</h3>
          
            <p>
            It is possible to call functions coded in C, which were compiled
            with the GNU C compiler (<TT>GCC</TT>). For calling the
            C function strcmp declare the following:
            
            <PRE>function strcmp(s1 : pchar;s2 : pchar) : integer;cdecl;external;</PRE>
          
        


        <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>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>Since version 1.9.2, the compiler also uses the register calling
            convention, which means the compiler can assemble assembler routines
            in Delphi source code without modification.

            <p>Since version 1.9.8, the register calling convention is default
	    for Delphi mode.

            <p>A description of the AT&amp;T syntax can be found in the GNU
            Assembler documentation. 
          


        <li><a name='systemnotfound'></a>
          <h3>Unit system not found errors</h3>
          
            <p>System (syslinux - not the bootloader, sysos2 or syswin32, depending
            on platform) is Pascal's base unit which is implicitely used in all programs.
            This unit defines several standard procedures and structures, and must be found to
            be able to compile any pascal program by FPC. 

            <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 or fpc.cfg configuration file. 

            <p>If the compiler can't find this unit there are three possible causes:
            <OL>
                <li>The ppc386.cfg or fpc.cfg isn't in the same path as the compiler
                executable (go32v2, win32 and OS/2) or can't be found as
                "/etc/fpc.cfg" or ".fpc.cfg" in your homedirectory (Linux).
                <li>The fpc.cfg or ppc386.cfg doesn't contain the -Fu line, or a wrong one.
                See the <a href="http://www.stack.nl/~marcov/buildfaq.pdf">build faq (PDF)</a>, especially the chapters
                about the fpc.cfg and the directory structure.
                <li>The files ARE found but the wrong version or platform. Correct
                ppc386.cfg or fpc.cfg to point to the right versions or reinstall the right
                versions (this can happen if you try to use a <A
                href="#snapshot">snapshot</a>
                compiler while the -Fu statement in the used fpc.cfg still points to
                the RTL that came with the official release compiler). 
            </OL>

            <p>A handy trick can be executing "ppc386 programname -vt", this shows
            where the compiler is currently looking for the system unit's files. You
            might want to pipe this through more (Dos, OS/2, Windows) or less
            (Linux), since it can generate more than one screen information: 

            <p>
            <PRE>
                    Dos, OS/2, Windows: ppc386 programname -vt |more<br>
                    unix, linux: ppc386 programname -vt |less<br>
            </PRE>
            <p>
          
        
        <li><a name='extensionselect'></a>
          <h3>There is a new extension that will be really useful. Will you include it?</h3>
          
            Occasionally somebody asks for a new extension on the maillist,
	    and the discussions that follow have a recurring pattern. An
	    extension is quite a big deal for the FPC team, and there are
	    some criteria that are used to select if an extension is
	    &quot;worth&quot; the trouble. The most important pre-selection criteria are:
 	    <OL>
		<li>Compatibility must not be compromised in any way. Existing
			codebases on at least the Pascal level must keep 
			running. This is often more difficult than most people
		        think.
		<li>The extension must have real value.  Anything that is only
			a shorter notation does not apply, unless it is 
			out of compatibility with an existing Pascal/Delphi
			codebase. Practically it means it must make something
			possible that can't be done otherwise or be a compatibility
			item 
		<li>The change must fit in with the scope of the project, 
			implementing a Pascal compiler which can have a RAD
			and generic DB system. This excludes features like
			inline SQL, and large garbage collected objectframeworks.
		
	    </OL>	

            Exceptions to the second rule are sometimes made for platform
	    specific reasons (e.g. interfacing to some other language or
	    OS). The first rule is often a problem, because issues aren't
	    easily recognizable unless one has tried to make extensions
	    before. Best is to make a thoroughly written proposal that the
	    devels can review with
	    <ul><li> Explanation of the feature
		<li> Why it is needed, what does it make possible?
		<li> How you would implement it?
		<li> Lots of examples of typical use, and tests for possible problem
			cases
	    </ul>	
	    Try to be verbose and really try to view this from the viewpoint
	    of somebody who has to implement it, and try to make examples
	    that span multiple units and procedures, and review what happens.
	    Be critical, try to punch holes in your
	    own reasoning and find possible problematic cases, and document
	    them.	
         
        <p>
  	    Besides these pre-selection rules and documentation, the other
	    important question is who is going to do the work. Keep in mind
	    that the FPC devels are volunteers with to-do lists that are
	    booked till the next decade. You can't simply expect they'll
	    drop everything from their hands and implement the feature
	    because you need it urgently, or think it is nice. If you are
	    not willing to implement it yourself, and submit patches,
	    chances are slim.  Remarks as &quot;this will attract a lot of
	    users because&quot; are considered with a lot of scepsis, since
	    that applies to any new development.
	  
   </OL>

   <li><h2>Runtime library related information</h2>
   <OL>


        <li><a name='HowToUseGraph'></a>
          <h3>Using the graph unit with Free Pascal</h3>
          
            <p>Since version 1.0, we  have a completely platform independent way
            of selecting resolutions and bitdepths. You are strongly encouraged to
            use it, because other ways will probably fail on one or other platform.
            See the documentation of the graph unit for more information. 
          
        

        <li><a name=WrongColors></a>
          <h3>Why do I get wrong colours 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>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): 

            <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 is the very reason why
            such symbolic constants exist. 
          
        

        <li><a name='fileshare'></a>
           <h3>File sharing and file locks</h3>
           
             <p> The standard runtime library file I/O routines open
             files in the default sharing mode of the operating system
             (<TT>system, objects</TT> units). Because of this, you
             might get problems if the file is opened more than once either
             by another process or the same process. 

             <p> Generally the behaviors for the different operating
                 systems are as follows : 
             <ul>
                <li> UNIX systems : There is no verification at all. 
                <li> Windows : An access denied error will be reported. 
                <li> Amiga : An access denied error will be reported. 
                <li> DOS / OS/2 : If the file is opened more than once by
                     the same process, no errors will occur, otherwise an
                     access denied error will be reported. 
             </ul>

             <p>There are two ways to solve this problem:
             <ul>
               <li> Use specific operating system calls (such as file locking
                    on UNIX and Amiga systems) to get the correct behavior. 
               <li> Use the <TT>sysutils</TT> unit or the Free Component Library
                    <TT>TFileStream</TT> File I/O routines, which try
                    to simulate, as much as possible, file sharing mechanisms. 
             </ul>
           
        
        <li><a name='filemode'></a>
          <h3>File denied errors when opening files with reset</h3>
          

           <p> Trying to open files using <CODE>reset</CODE> on non-text files
               might cause a Runtime Error 5 (Access denied). 

           <p> All files opened using the above system unit routine use the current
               <CODE>filemode</CODE> value to determine how the file is opened. By
               default, <CODE>filemode</CODE> is set to 2 (Read/Write access).
            

            <p>So, a call to <CODE>reset</CODE> on non-text files does <EM>not</EM>
               indicate that the file will be opened read-only. So, trying to open a file
               using <CODE>reset</CODE> with the defaults will fail on read-only files.
               <CODE>filemode</CODE> should be set to 0 (Real-only access) before
               calling <CODE>reset</CODE> to solve this problem. A sample solution
               is shown below.
            

            <PRE>
              const
                 { possible values for filemode }
                 READ&#95;ONLY = 0;
                 WRITE&#95;ONLY = 1;
                 READ&#95;WRITE = 2;
              var
                 oldfilemode : byte;
                 f: file;
              begin
                 assign(f,'myfile.txt');
                 oldfilemode := filemode;
                 { reset will open read-only }
                 filemode := READ&#95;ONLY;
                 reset(f,1);
                 { restore file mode value }
                 filemode := oldfilemode;
                 // ...
                 close(f);
              end.
            </PRE>

            <p> For more information, consult the Free Pascal reference manual
          

   </OL>

   <LI><h2>DOS related information</h2>
   <OL>

        <li><a name=dos-release></a>
          <h3>Releasing software generated by the DOS compiler</h3>
          
            <ul>
                <li> If your program uses floating point code (which is
                very probable), make sure to read "<a href="#fp386">Applications created
                with Free Pascal crash on 80386 systems</a>" regarding special issues
                which might occur. Math coprocessor emulation software is then
                required (<TT>wmemu387.dxe</TT> should be redistributed with your software) 
                <li> The target system must have a DPMI server. To avoid problems,
                     the file <TT>cwsdpmi.exe</TT> should always be redistributed with your
                     application
                <li> The target system must have DOS 3.3 or later 
                <li> The default heap size is 2 Megabytes. Automatic growing of the heap is supported 
                <li> The default stack size is 256 Kbytes. See also "<a href="#dos-stack">Changing
                      the default stack size</a>" 
                <li> The stack checking option is available on this platform. 
            </ul>
          

        
        <p>

        <li><a name=dos-debugging></a>
          <h3>Debugging</h3>
          
            <p>The GNU debugger v4.16 and later have been tested, and generally work as
            they should. Because the GNU debugger is C oriented, some pascal types might not be
            represented as they should. It is suggested to use the text mode IDE instead of GDB,
            which is available for the DOS target.
          
        
        <p>

        <li><a name=dos-dll></a>
          <h3>Dynamic Libraries</h3>
          
            <p>Creation or use of shared libraries (also called dynamic link libraries) is not
               supported under this platform.
            

        
        
        <li><a name=dos-profile></a>
          <h3>Profiling</h3>
            
            <p>Profiling with <TT>gprof</TT> is supported for this platform. 
          
        


        <li><a name=FPwithoutfpu></a>
          <h3>Running 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><PRE>
                    SET 387=N
                    SET EMU387=C:\PP\BIN\GO32V2\WEMU387.DXE
            </PRE>(don't forget to replace the <TT>C:\PP</TT> with the directory
            where you installed FPC)
          
        

        <li><a name=fp386></a>
          <h3>Applications created with Free Pascal crash on 80386 systems</h3>
          
            <ul>
                <li>
                 <p>Trying to run an application which does floating point operations
                 on a 386 system without a math co-processor will crash unless
                 the <TT>emu387</TT> unit is used, as this unit loads the math co-processor
                 emulator (called <TT>wmemu387.dxe</TT>). You can add the unit as follows:

                <p><PRE>
                        program myprog;
                        uses emu387, ...
                </PRE>
                


                <p>When the application is released, the software package should also
                include the wmemu387.dxe redistributable file to avoid problems. .


                <li>
                <p>Some 80386 systems have a hardware bug which corrupt the accumulator
                register <TT>EAX</TT> if it is used in a <TT>MOV</TT> instruction just
                after a <TT>POPAL</TT> instruction. Prior to version 1.0.5, the compiler
                and runtime library could generate such code sequences. This is now
                fixed and should no longer cause problems
            </ul>
          
        <p>
        


        <li><a name=nomousegraph></a>
          <h3>The mouse cursor is not visible in graphics screens</h3>
          

            <p>A lot of DOS mouse drivers don't support mouse cursors in VESA modes
            properly. Logitech is said to have a decent mouse driver, which can be
            found <A
            href="ftp://ftp.logitech.com/pub/techsupport/mouse/m643&nbsp;w31.exe">here</a>
         

        <li><a name=accessioports></a>
          <h3>Accessing 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>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>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) 
          
        

        <li><a name=HowToAccessDosMemory></a>
          <h3>Accessing DOS memory / Doing graphics programming</h3>
          
            <p>You can do like in Turbo Pascal, via absolute or mem[]. For larger memory
            blocks use the dosmemput/dosmemget routines in the <TT>Go32</TT> unit. 
                  

        <li><a name=dos-stack></a>
          <h3>Changing the default stack size</h3>
          
            <p>Under the DOS (GO32V2) target, the default stack size to 256 bKbytes. This can
            be modified with a special DJGPP utility called <TT>stubedit</TT>. It is to note
            that the stack may also be changed with some compiler switches, this stack size,
            if greater then the default stack size will be used instead, otherwise the default
            stack size is used.
          
        <p>

        <li><a name=dos-os2></a>
          <h3>Using OS/2 generated applications under DOS</h3>
          
            <p>OS/2 applications (including the compiler) created with version 1.0.x
            and before should work correctly under vanilla DOS, since they are based
            on EMX (versions prior to 1.0.5 had big problems with EMX under DOS, this
            is now fixed). It is important to note that the compiled applications
            require the EMX runtime files (<TT>emx.exe</TT>) to execute properly. It may be
            necessary to distribute these files with the generated application.
            <p>Binaries created for target OS2 with version 1.9.x and above cannot
            run under DOS any more, because they directly use OS/2 API functions not
            available when running under extender - you need to compile for a newly added
            EMX target which provides this capability of running on both platforms.
          


   </OL>
   <LI><h2>Windows related information</h2>
   <OL>

        <li><a name=win-release></a>
          <h3>Releasing software generated by the windows compiler</h3>
          
            <p> There is no special requirements for releasing software
            for the windows platform, it will work directly out of the box. The following
            are default for the Windows platform: 

            <ul>
                <li> The default heap size is 256 Kbytes. Automatic growing
                of the heap is supported. It is to note that Windows 95,
                Windows 98 and Windows Me limit the heap to 256 Mbytes
                (this is a limitation of those Operating systems, not of Free Pascal,
                 consult MSDN article Q198959 for more information).
                
                <li> Stack size is unlimited 
                <li> The stack checking option is not available on this platform. 
            </ul>
          
        
        <p>

        <li><a name=win-debugging></a>
          <h3>Debugging</h3>
          
            <p>The GNU debugger v4.16 and later have been tested, and generally work as
            they should. Because the GNU debugger is C oriented, some pascal types might not be
            represented as they should. It is suggested to use the text mode IDE instead of GDB,
            which is available for windows targets.
          
        
        <p>


        <li><a name=win-dll></a>
          <h3>Dynamic libraries</h3>
          
            <p>Creation and use of shared libraries (also called dynamic link libraries) is
            fully supported by the compiler. Refer to the Programmer's Reference Manual for
            more information on shared library creation and use.
          

        
        
        <li><a name=win-profile></a>
          <h3>Profiling</h3>
          
            <p>Profiling is supported using <TT>gprof</TT>, starting with version 1.0.7. 
               It requires mingw to be installed, and that <TT>fpc.cfg</TT> point to the 
               correct library paths. 
           
        


        <li><a name=win-graph></a>
          <h3>Graph and problems with keyboard, mouse and "dummy dos windows"</h3>
          
            <p>Problem:
            <ul>
                <li>If you use the Graph unit under Win32, you can't use the API mouse
                unit for mouse support or use the win32 Crt unit to get keyboard data.
                The reason for this is that the window popped up is a GUI window, and
                not a console one.
            </ul>
            Solution:
            <ul>
            <li>Use units WinMouse and WinCrt instead.
            </ul>
            <p>
            <p>Problem:
            <ul>
                <li>When you follow the above advice, and you run your purely Graph
                based win32 program from the RUN menu in windows, a dummy dos window
                is opened.
            </ul>
            Solution:
            <ul>
                <li>Set the application type to GUI: <PRE>{$apptype GUI}</PRE>
                and put this line before your programs InitGraph statement:
                <PRE>ShowWindow(GetActiveWindow,0);
                </PRE>This will hide the dos window window. 
            </ul>
            <p>

            <p>Some of the demos (like fpctris) use these techniques 
          

        <li><a name=win-cygwin></a>
          <h3>Cygwin binary directory in your path sometimes causes strange problems</h3>
          
            <p>The mingw make tool seems to look for a "sh.exe", which it
		finds when the cygwin binary directory is in the path. The
		way directories are searched changes, and the build process dies.
            

	    <p>Solution: don't put cygwin in your global path for now, only
               add it when needed. Efforts are made to work around this.
	    

            <p>Possible untested workaround: add mingw sh.exe to a directory before 
               the cygwin binary directory in the path
          

               

        <li><a name=win95-fpc></a>
          <h3>Using the DOS compiler under Windows 95</h3>
          
            <p>There is a problem with the DOS (GO32V2) compiler and Windows 95 on
            computers with less than 16 Megabytes of RAM. First set in the
            properties of the DOS box the DPMI memory size to max value. Now try
            to start a demo program in the DOS box, e.g. HELLO (starting may take
            some time). If this works you will be able to get the compiler to work
            by recompiling it with a smaller heap size, perhaps 2 or 4 MB
            (option -Chxxxx).
           
        

        <li><a name=win-os2></a>
          <h3>Using OS/2 generated applications under Windows</h3>
          
            <p>Normally OS/2 applications (including the compiler) created with version 1.0.x
            and before should work under Windows, since they are based on EMX - see
            <a href="#dos-os2">note about running OS/2 applications under DOS</a> for
            more detailed information. You need the RSX extender (rsx.exe) to do this.
            There have been problems reported while trying to run EMX applications under
            NT / 2000 / XP systems though. This seems to be a problem with EMX (RSX) itself.
            It is not recommended to use Free Pascal OS/2 compiled programs under NT / 2000
            and XP, as it might produce unexpected results.
                  

        <li><a name=win-dos></a>
          <h3>Using DOS generated applications under windows</h3>
          
            <p>Several problems have been found running DOS software
            under certain versions of Windows (NT / 2000 / XP). These
            seem to be problems with the DOS emulation layers (emulated
            DPMI services or the Go32 extender). These problems may not occur with all software
            generated by FPC. Either applications should be tested on these systems
            before being released, or Windows versions should be generated instead.
          


    <li><a name=win-ide-mouse></a>
         <h3>The mouse cursor does not respond in the Windows IDE</h3>
         
		   <p>In windowed mode, the mouse cursor might not respond to
		   mouse moves and clicks. Just change the properties of the console,
		   and remove the quick edit mode option. This should solve the mouse
		   response problems.
         

    


   </OL>
   <LI><h2>UNIX related information </h2>

        <p>This section also applies to most unix variants, such as
        linux, freebsd and netbsd. 

   <OL>
        <li><a name=unix-release></a>
            <h3>Releasing software generated by the unix compilers</h3>

            <ul>
                <li> The default heap size is 256 Kbytes for the intel version,
                     and 128 Kb for the m68k versions. Automatic growing of the
                     heap is supported. 
                <li> There is no stack space usage limit. 
                <li> Under Solaris and QNX, stack checking is simulated. 
                <li> Minimal operating system versions :
                  <ul>
                    <li> Linux : Kernel v2.4.x or later. 
                    <li> FreeBSD : version 5.x or later.   (4.x can be made to work with minor work)
                    <li> NetBSD : version 1.5 or later. 
                    <li> Solaris : version 5.7 of SunOS or later
                         (should work with earlier versions, but untested). 
                    <li> Qnx : version 6.1.0 or later
			(should work with earlier versions, but untested).
                    <li> Mac OS X : version 10.3.9 or later    
                  </ul>
                
            </ul>

        
        <p>

        <li><a name=unix-debugging></a>
            <h3>Debugging</h3>

            <p>The GNU debugger v4.16 and later have been tested, and generally work as
            they should. Because the GNU debugger is C oriented, some pascal types might not be
            represented as they should. For FreeBSD a recent GDB (v5) SVN snapshot is
                recommended for Pascal support and ease of building
        
        <p>


        <li><a name=unix-dll></a>
            <h3> Dynamic libraries </h3>

            <p>These operating systems do support shared libraries (also called
               dynamic link libraries), Free Pascal currently does not emit position
               independant code (PIC), as required for the creation of shared libraries.
            
            <p>
			   Therefore, even though the linux compiler target permits creating shared
			   libraries, the usage of that shared library may result in undefined
			   behavior, especially if accessing global variables in the library. Creation
			   of shared libraries is not recommended with the current version of the
			   compiler.
            

            <p>
               Importing code from shared libraries does work as expected though, since
               it does not require usage of position independant code.
            

        
        
        <li><a name=unix-profile></a>
            <h3>Profiling</h3>
            
            <p>Profiling is supported using <TT>gprof</TT> under linux,
               FreeBSD and NetBSD, the latter two only since 1.0.8. On other
               other unix-like operating systems, profiling is currently not
               supported.
            
        
        <li><a name=libci386></a>
            <h3>Libc is missing on platforms other than Linux/i386</h3>
            <P>Libc is a Kylix compatibility unit. Because it contains many
            i386 specific code and features structures from legacy kernels, 
			it has not been made available on other platforms.

            <P>To access Unix functionality, please use units like baseunix
            and unix.

        <li><a name=vgamissing></a>
            <h3>Why can't the linker find "vga"?</h3>

            <p>This error typically looks like this:<PRE>
                 Free Pascal Compiler version 2.2.x [xxxx/yy/zz] for i386
                 Copyright (c) 1993-2008 by Florian Klaempfl
                 Target OS: Linux for i386
                 Compiling test.pp
                 Assembling test
                 Linking test
                 /usr/bin/ld: cannot find -lvga
                 test.pp(6,4) Warning: Error while linking Closing script ppas.sh 5 Lines
                 compiled, 0.2 sec
            </PRE>
            <p>

            <p>This error is not an error in the installation of FPC or FPC itself,
            but a missing Svgalib library in your unix install. Please install the
            required library using your favourite package manager tool 
        


        <li><a name=unix-asldmissing></a>
            <h3>Compiler indicates missing as and ld</h3>

            <p> Normally unix systems have the assembler (<TT>as</TT>) and linker
            (<TT>ld</TT>) pre-installed and already in the search path. That is
            the reason why these tools are not supplied with the compiler. 

            <p>If the compiler cannot find these tools, either they are not in
            your search path, or they are not installed. You should either add the
            path where the tools are located to your search path, and / or you
            should install these tools. 

            <p> It is to note that the Solaris version of FPC contains these tools. 
        
        <li><a name=unix-ld219></a>
            <h3>An error occurred while linking, or &quot;did you forget -T?&quot;</h3>

            <p>There is a bug in GNU LD 2.19 and 2.19.1 that causes it to crash
            when processing FPC-generated linker scripts. This bug has been fixed
            in the mean time.</p>

            <p>At the same time, LD has been modified to emit a warning of the form 
            <pre>
               /usr/bin/ld: warning: link.res contains output sections; did you forget -T?
            </pre></p>

            <p>This warning is benign, and FPC intentionally does not pass -T to LD. The reason
            is that if -T is used, LD's internal linker script is ignored and only
            FPC's linker script is used. Such linker scripts also contain paths to
            libraries however, and if we would ignore the internal linker script then
            LD would no longer find libraries in distribution-specific directories.</p>

   </OL>
   <LI><h2>OS/2 related information </h2>
   <OL>

       <li><a name=os2-release></a>
            <h3>Releasing software generated by the OS/2 compiler</h3>

             <p> The OS/2 compiler version 1.0.x and before is based on EMX, therefore
             it should work both on OS/2 and on vanilla DOS systems. In version 1.9.x and
             above this functionality is preserved in newly added target EMX, whereas binaries
             for target OS2 can only run under real OS/2. The following notes apply to OS2
             target in 1.0.x and EMX in 1.9.x and above:

             <ul>
                <li> All applications generated for the OS/2 (EMX) target require
                     the EMX 0.9d (or later) runtime files to run. These files
                     should be redistributed with your software. All the files
                     which should be redistributed are included in <TT>emxrt.zip</TT>
                <li> Under OS/2, <TT>LIBPATH</TT> should be modified to add the EMX
                     DLL paths. Otherwise, programs will not run and will abort
                     with an error 'Cannot find EMX.dll'.
                <li> The default heap size is 256 Kbytes.
                     Automatic growing of the heap is supported.
                <li> Stack can grow up to 256 Kbytes by default. This can be changed by
                     the user or developper using the <TT>emxstack</TT> or <TT>emxbind</TT>
                     utilities. 
            </ul>
        
        <p>


        <li><a name=os2-debugging></a>
            <h3>Debugging</h3>

            <p>The GNU debugger v4.16 (EMX port) has been tested (including
            its PM add-on, pmgdb.exe) and generally works as it should.
            Because the GNU debugger is C oriented, some pascal types
            might not be represented correctly.
        
        <p>

        <li><a name=os2-dll></a>
            <h3> Dynamic libraries </h3>

            <p>
            Even though this operating system permits the creation and usage of
            shared libraries (also called dynamic link libraries), the compiler
            currently only permits importing routines from dynamic libraries (creation of
            dynamic libraries is unsupported).
            

        
        
        <li><a name=os2-profile></a>
            <h3>Profiling</h3>
            
            <p>Profiling is currently not supported for this platform. 
        


        <li><a name=os2-dos></a>
            <h3>Using DOS generated applications under OS/2</h3>

            <p>It has been reported that some DOS (GO32V2) applications
            (including the DOS compiler itself) generated by the compiler fail on
            some OS/2 installations. This is due to problems in the OS/2 DPMI server.
            

            <p>You should use native OS/2 applications under OS/2 (including the native OS/2
            compiler) or try installing a new OS/2 fixpack to see if it solves the
            problem. 
        

        <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>
            <p>
            or
            
            <h3>INSTALL.EXE of version 1.0.6 or above complains about missing TZ variable under OS/2</h3>

            <p>
            You are most probably using an older version of OS/2 (like OS/2 Warp 3.0)
            and don't have TZ variable in your environment. The easiest solution is to add
            "SET TZ=..." (e.g. "SET TZ=CET-1CEST,3,-1,0,7200,10,-1,0,10800,3600" for most
            of western and central Europe) line to your CONFIG.SYS, and restart OS/2.
            The proper setting for you can be found e.g. using the TZCALC tool from
            <a href="http://hobbes.nmsu.edu/pub/os2/apps/internet/time/time868f.zip">TIME868</a>
            package.
            
        
        <li><a name="os2-fp"></a><h3>OS/2 compiler not working after upgrading to 1.9.6 or newer</h3>
            <p>An updated version of GNU assembler (as.exe) is packaged with release 1.9.6 (newer version
            was necessary to get support for features of modern CPUs). This version of the GNU tool
            was created with Innotek port of GNU C and relies on its libc. This results in higher
            limitations regarding supported configurations, because this libc needs recent version
            of OS/2 Unicode support libraries (LIBUNI.DLL and UCONV.DLL) not available in base OS/2 Warp 3.0
            and OS/2 Warp 4.0. The updated versions were distributed by IBM in corrective packages (fixpaks)
            - see e.g. <a href="http://www.warpupdates.mynetcologne.de/english/basesystem.html">WarpUpdates site</a>
            for information about OS/2 fixpaks and links for downloading them.
            This issue isn't valid for WarpServer for e-Business, MCP and eComStation - these already have
            the correct version.
            
        <li><a name="os2-as-failing"></a><h3>Compilation under OS/2 fails with error "Can't call the assembler"</h3>
            <p>Apart from the point mentioned <a href="#os2-fp">above</a>,
            there is at least one more potential reason for issues with
            executing the assembler and resulting in error message "Can't call
            the assembler, error 2 switching to external assembling". This
            error may be result of the OS/2 system not being able to find DLLs
            required for the assembler. Make sure that you installed FPC
            completely (these DLLs are part of file asldos2.zip) and that you
            have set LIBPATH according to instructions in README.TXT (and
            restarted afterwards). If in doubts, running the assembler directly
            from the command line (e.g. "as --version" to show the installed
            as.exe version) may be helpful to see name of the missing dynamic
            library or other details about the problem.
            
        
   </OL>

   <LI><h2>BeOS related information </h2>
	<b>The BeOS port is current no longer maintained</b>
   <OL>


          <li><a name=beos-release></a>
               <h3>Releasing software generated by the BeOS compiler</h3>

                <p> Software generated for the BeOS target will only work
                on the intel based version of BeOS. 

                <ul>
                    <li> The target system must have at least BeOS v4.0 or later
                       (BeOS 5.1d 'Dano' is <em>not</em> supported) 
                    <li> The default heap size is 256 Kbytes.
                         Automatic growing of the heap is supported
                    <li> Stack size is set to 256 Kbytes. This cannot be changed 
               </ul>
           
           <p>


        <li><a name=beos-debugging></a>
            <h3>Debugging</h3>

            <p>
            This operating system uses DWARF debugging information, and Free Pascal
            does not support emitting DWARF debugging information. It is currently
            impossible to debug applications under BeOS
            

        
        <p>

        <li><a name=beos-dll></a>
            <h3> Dynamic libraries </h3>

            <p>
            Even though this operating system permits the creation and usage of
            shared libraries (also called dynamic link libraries), the compiler
            currently only permits importing routines from dynamic libraries (creation of
            dynamic libraries is unsupported).
            

        
        
        <li><a name=beos-profile></a>
            <h3>Profiling</h3>
            
            <p>Profiling is currently not supported for this platform. 
        
        
        
          <li><a name=beos-linking></a>
               <h3>BeOS Linking problems</h3>

                <p>It has been reported that certain versions of the linker
                that shipped with some versions of BeOS are broken. If you get 
                an error when linking fpc applications, try updating your version 
                of ld from the following
                <a href="http://open-beos.sourceforge.net/dev.php">site.</a>
                

           
           <p>
        
        


   </OL>

   <LI><h2>Amiga related information </h2>
   <OL>
         <li><a name=amiga-release></a>
               <h3>Releasing software generated by the Amiga compiler</h3>

                <ul>
                    <li> The target system must have AmigaOS v2.04 or higher 
                    <li> The default heap size is 128 Kbytes.
                         Automatic growing of the heap is supported. 
                    <li> Stack size is not set by the compiler, but by the <TT>stack</TT>
                         command on the CLI. Because of this, and because default
                         stack sizes for this target are small, it is recommended
                         to always compile software with stack checking enabled.
                    <li> By default, the compiler generates code for the 68020+
                         processor. The code generated will not work on 68000
                         and 68010 systems unless the <TT>-O0</TT> compiler switch
                         is used, and there is no runtime checking. It is up
                         to you to implement CPU verification at program startup. The
                         standard runtime libraries have been compiled for the
                         68000 target, and should not cause any problems. 
                    <li> All floating point operations are simulated,
                         and use the <TT>single</TT> floating point type.
                         You will need to recompile all standard runtime
                         libraries and your application, with the software floating point
                         option off, if you wish to use hardware floating point.
               </ul>
         
         <p>

        <li><a name=amiga-debugging></a>
            <h3>Debugging</h3>

            <p> Source level debugging is not supported for the Amiga target. Assembler
            target debugging is possible though, using the excellent <TT>Barfly</TT>
            debugger.

        
        <p>

        <li><a name=amiga-dll></a>
            <h3> Dynamic libraries </h3>

            <p>
            Even though this operating system permits the creation and usage of
            shared libraries (also called dynamic link libraries), the compiler
            does not support either the importing or creation of shared libraries.
            Importing must be done manually in assembler.
            

        
        
        <li><a name=amiga-profile></a>
            <h3>Profiling</h3>
            
            <p>Profiling is currently not supported for this platform. 
        
        

   </OL>

   <LI><h2>PalmOS related information </h2>
   <OL>

          <li><a name=palmos-release></a>
            <h3>Releasing software generated by the PalmOS compiler</h3>

            <ul>
            </ul>

          
          <p>

        <li><a name=palmos-debugging></a>
            <h3>Debugging</h3>

        <li><a name=palmos-dll></a>
            <h3> Dynamic libraries </h3>

            <p>
        <p>
   </OL>



</OL>



</body></html>