常见问题/知识库

本文档提供有关编译器最近错误的信息。 并回答常见问题以及为 Free Pascal 提供常见问题的解决方案。 这里提供的信息始终取代 Free Pascal 文档中的信息。

有关 pascal 语言和运行时库调用的更多信息,请参阅 Free Pascal 手册。本文档涉及的主题有:

  1. 常规信息
    1. 什么是 Free Pascal(FPC)?
    2. 都有哪些版本,我应该使用哪个版本?
    3. Free Pascal 和 GNU Pascal - 对比
    4. 许可和版权信息
    5. 获取编译器
    6. Free Pascal 安装提示
    7. 为什么我必须提供用户名和密码才能获取 Free Pascal?
    8. 连接到 Free Pascal FTP 站点时提示 Access denied 错误
    9. 我现在需要新版本
    10. 安装快照
    11. 我需要写课外作业程序。你能帮我吗?
    12. 如何使用 Windows 和菜单栏制作真正的 Windows 应用程序?
    13. 如何使用 Free Pascal 制作游戏?我可以制作像 Doom 3 这样的游戏吗?
    14. 应用程序崩溃时获取更多信息
    15. 编译器似乎跳过了 -Fu 指向目录的文件
    16. 为什么生成的二进制文件如此之大?
    17. 运行时错误
    18. 标准单元
    19. 调试智能链接代码不能正常工作
    20. 无法使用二进制版本的单元编译程序
    21. 你会支持 ISO 扩展 Pascal吗?
    22. 那么 .NET 呢?
  2. Pascal 语言相关信息
    1. 移植代码到其他处理器注意事项
    2. 移植代码到其他操作系统注意事项
    3. 使用 Free Pascal 编译 Delphi 代码
    4. 构建单元
    5. 编译系统单元
    6. 函数重载是如何工作的?
    7. 调用 C 函数
    8. 集成汇编语法
    9. 找不到 system、syslinux、sysos2 或 syswin32 单元错误
    10. 有一个新扩展非常好用,你会加入吗?
  3. 运行时库相关信息
    1. 使用 graph 单元时为什么会出现颜色错误?
    2. 文件共享和锁定
    3. 打开文件后 reset 提示 File denied 错误
  4. Windows 相关信息
    1. 发布由 Windows 编译器生成的软件
    2. 调试
    3. 动态库
    4. 分析
    5. Graph 单元引发的键盘、鼠标和“虚拟dos窗口”的问题
    6. Cygwin 程序目录存在于环境变量 PATH 中造成构建失败
    7. 在 Windows 95 下使用 DOS 编译器
    8. 在 Windows 下使用 DOS 生成应用程序
    9. 鼠标光标在 Windows IDE 中不响应
  5. UNIX 相关信息
    1. 发布由 UNIX 编译器生成的软件
    2. 调试
    3. 动态库
    4. 分析
    5. i386 以外的平台上缺少 Libc
    6. 链接器为什么找不到 "vga"?
    7. 编译器指示缺少 as 和 ld
    8. link.res 语法错误,或 "你忘了 -T 吗?"
  6. OS/2 相关信息
    1. 发布由 OS/2 编译器生成的软件
    2. 调试
    3. 动态库
    4. 分析
    5. 在 OS/2 下使用 DOS 生成应用程序
    6. OS/2 下 INSTALL.EXE 1.0.6 或更低版本返回未知错误(-1)

      OS/2 下 1.0.6 或更高版本的 INSTALL.EXE 提示缺少 TZ 变量
    7. 升级到 1.9.6 或更高版本后,OS/2 编译器无法工作
    8. OS/2 下编译失败,并显示错误 "Can't call the assembler"
  7. DOS 相关信息
    1. 发布由 DOS 编译器生成的软件
    2. 调试
    3. 动态库
    4. 分析
    5. 在没有数学协处理器的情况下运行 Free Pascal
    6. 在 80386 系统上使用 Free Pascal 创建应用程序造成崩溃
    7. 鼠标光标在屏幕上看不到
    8. 访问 I/O 端口
    9. 访问 DOS 内存/进行图形编程
    10. 更改默认堆栈大小
  1. 常规信息

    1. 什么是 Free Pascal(FPC)?

      Free Pascal 最初名为 FPK-Pascal,是一个 16、32 和 64 位 Turbo Pascal 和 Delphi 兼容的 Pascal 编译器;适用于 Linux、Windows、OS/2、FreeBSD、Mac OS X、DOS 和其他几个平台(支持目标的数量一直在增长,尽管并非所有目标都与主要目标处于同一水平)。

      Free Pascal 编译器可用于多种架构:x86(16、32 和 64 位)、ARM 、PowerPC(32 和 64 位)、SPARC(v8、v9)、Java 虚拟机(开发中)和 MIPS(小端和大端,开发中)。旧版本(1.0系列)和当前开发版本也支持 m68k。

      编译器以 Pascal 编写,能够编译自己。源文件在 GPLv2+ 下分发并包含在内。

      简史:

      • 1993年6月:项目开始
      • 1993年10月:第一个小程序工作
      • 1995年3月:编译器编译自己
      • 1996年3月:发布到互联网
      • 2000年7月:1.0 发布
      • 2000年12月:1.0.4 发布
      • 2002年4月:1.0.6 发布
      • 2003年7月:1.0.10 发布
      • 2005年5月:2.0.0 发布
      • 2005年12月:2.0.2 发布
      • 2006年8月:2.0.4 发布
      • 2007年9月:2.2.0 发布
      • 2008年8月:2.2.2 发布
      • 2009年4月:2.2.4 发布
      • 2009年12月:2.4.0 发布
      • 2010年11月:2.4.2 发布
      • 2011年5月:2.4.4 发布
      • 2012年1月:2.6.0 发布
      • 2013年2月:2.6.2 发布
      • 2014年3月:2.6.4 发布
      • 2015年11月:3.0.0 发布
      • 2017年2月:3.0.2 发布
      • 2017年11月:3.0.4 发布
      • 2020年6月:3.2.0 发布
      • 2021年5月:3.2.2 发布
    2. 都有哪些版本,我应该使用哪个版本?

      最新的正式版本是 3.2.2,是 3.2.x 系列中的第一个小更新。在 3.3.x 系列中进行开发,最终将根据所实现的进度发布为 3.4.0 或 4.0.0。

      历史版本

      多年来,FPC 的版本编号发生了几次更改。1.0 版之前的版本信息已移至 Wiki 1.0 版本页面。

      目前版本控制

      在 1.0 中,版本编号稍有更改,改为类似于 Linux 内核版本号命名方式。

      • 仅修复 1.0 中错误的版本编号为 1.0.x。
      • 1.0 以后的开发(所谓的快照)的版本号为 1.1.x。
      • 最终,在稳定的 1.1.x 中以 2.0.x 系列发布,其后是标有 1.9.x beta。2.0 的修复程序编号为 2.0.x,2.2 的修复程序编号为 2.2.x,2.4 的修复程序编号为 2.4.x 等。
      • 2.4.0 发行版之后的新开发版本编号为 2.5.x,依此类推。
      • 重新打包并影响原有的,用单个字母表示为后缀(例如 2.0.4a)。对于不属于原始发行的平台,通常是这种情况。
      • 稳定分支(当前为 fixes_3_0,先前为 fixes_2_6)。最后一个数字为奇数(2.6.1、2.6.3 和 3.0.1)。 则此类版本的编译器是快照,例如 2.6.1 的快照可以在 2.6.0 和 2.6.2 之间的任何时间(2013年1月)。 同样,在 2.6.2 发布后,fixes_2_6 分支将其自身标识为版本 2.6.3,直到分支 2.6.4(通常在之前两个月发布)。 在 2.6.4 之后,稳定分支的编号已更新为 2.6.5,在 3.0.2 至 3.0.3 之后等等。

      通常情况下,希望你使用稳定版。发行版被认为是稳定的,并且更容易支持(bug、异常和意想不到的“特性”在一段时间后是众所周知的,并且存在解决方法)

      开发快照(每天生成)反映了编译器的当前状态。开发版可能会修复上一版本的问题或增加新功能,但可能存在一些临时的缺陷(通常在第二天修复)。

      开发快照通常对某些用户来说非常有用。如果你不确定的话,在邮件列表中询问你的情况是否需要。

      稳定分支的快照(fixes_3_2)用于测试发布工程。他们主要在发布前的几个月对创建发布的分支进行广泛测试。

      我们建议所有用户升级到最新版本(最好是稳定的 3.2.x 系列)。

      FPC 项目及其近期的时间线图表:

    3. Free Pascal 和 GNU Pascal - 对比

      目标:
      Free Pascal 尝试在尽可能多的平台上实现与 Borland 兼容的 pascal 编译器。GNU Pascal 尝试实现基于 POSIX 的便携式 pascal 编译器。
      版本:
      目前,Free Pascal 的版本为 3.2.2(2021年5月)。GNU Pascal 停止于 2.1版(从 2002 年开始,它可以用几个不同的 GCC 作为后端构建;Mac OS X 版本是一个例外,因为它遵循 GCC 版本号)。
      跟踪:
      在发行版之间,FPC 的开发版本可通过每日快照获得,而源代码可通过 CVS 获得。GPC 每年都会发布几次最新版本的补丁程序,并且定期由用户制作 OS X 和 Windows 快照。
      操作系统:
      Free Pascal 可在多个平台上运行:包括 DOS(16/32位)、Win32(不需要 Unix 移植层)、Linux、FreeBSD、NetBSD、OS/2、BeOS、Classic Mac OS、Mac OS X ,采用以下架构:x86(32和64位)、Sparc、PowerPC(32/64位)、ARM 和 Java 虚拟机(正在开发中)、MIPS(正在开发中)。GNU Pascal 基本上可以在 GCC 支持的任何操作系统上运行,并且验证了构建过程。
      引导:
      FPC 需要一组合适的 binutils(AS,AR,LD),GNU make 和命令行引导编译器。新架构/操作系统是交叉编译的。GPC 引导通过合适的 GCC 版本,并需要一整套 binutils、flex、bison、gmake、POSIX shell 和 libtool
      源码:
      Free Pascal 完全用 Pascal 编写,而 GNU Pascal 用 C 语言编写(它是 GNU C 编译器的改编版)
      语言:
      Free Pascal 支持 Borland Pascal 方言,实现 Delphi Object Pascal 语言、Objective-Pascal,并对 ISO 7185 Pascal 和 Mac Pascal 扩展提供了一些支持。GNU Pascal 支持 ISO 7185、ISO 10206,Borland Pascal 7.0(大部分)
      扩充:
      Free Pascal 实现方法,函数和运算符重载。(后来 Delphi 版本添加了这些,所以严格来说不再是扩充)GNU Pascal 实现了运算符重载。
      许可:
      两个编译器都属于 GNU GPL。
      作者:
      Free Pascal 由德国的 Florian Klämpfl(florian@freepascal.org)发起,GNU Pascal 由芬兰的 Jukka Virtanen 创建(jtv@hut.fi)。

    4. 许可和版权信息

      由编译器创建的应用程序和使用运行时库以 gnu 公共许可证(LGPL)授权, 它不允许对应用程序的许可类型进行限制。 因此,可以使用 Free Pascal 创建闭源或专有软件。

      向 LGPL 添加例外:
      作为一个特殊的例外,此库的版权所有者允许您将此库与独立模块链接以生成可执行文件, 而不管这些独立模块的许可条款如何,以及根据您选择的条款复制和分发生成的可执行文件,前提是您还满足每个链接的独立模块的许可条款和条件。 独立模块是不是从该库派生或基于该库的模块。如果您修改此库,您可以将此例外扩展到您的库版本,但您没有义务这样做。 如果您不希望这样做,请从您的版本中删除此例外声明。 请注意,你仍必须遵守 LGPL,例如,LGPL 要求你提供运行时库的源代码。如果你想编写专有的闭源软件,请这样做以符合要求:

      • 大多数人都可以从 Free Pascal 网站上下载 rtl 源码:如果你没有修改 rtl,这被认为满足 LGPL 提供源代码的要求。
      • 如果你对运行时库进行了修改,你不能私用,如果需要,你必须公开它们。
      • 与你的产品一起分发 LGPL 许可证。

      另一方面,编译器源码属于 GNU 公共许可证,这意味着编译器源码任何形式的使用只能以相同的方式授权。

    5. 获取编译器

      最新 Free Pascal 官方稳定版可从所有官方镜像下载

    6. Free Pascal 安装提示

      • 编译器安装目录不能包含空格,因为某些编译器工具不喜欢这样
    7. 为什么我必须提供用户名和密码才能获取 Free Pascal?

      登录到 ftp 站点,必须使用登录名:anonymous,密码为你的电子邮件地址。

    8. 连接到 Free Pascal FTP 站点时提示 Access denied 错误

      The Free Pascal main ftp site can only accept a maximum number of simultaneous connections. 如果发生此错误,则表明 FTP 站点达到最大连接数。 解决方法是等待后重试,或者使用 Free Pascal 镜像站点。

    9. 我现在需要新版本

      在发布新的正式版本之前,你可以查看并测试开发人员的版本(称为“快照”)。请注意:这是正在进行的工作,因此除了修复错误和添加的新功能之外,其中还可能包含新的错误。

      快照每天晚上自动从当前源生成。如果你的版本不能使用,这可能由于尚未完全实现的较大更改。请在一两天后重试。

      最新快照可以始终从开发页面下载。

    10. 安装快照

      要安装快照,请将 zip 文件解压缩到 Free Pascal 现有版本的目录中(当然,在备份原始文件之后)。 你还可以文件解压缩到空目录中,然后将文件移动到程序目录中,覆盖现有文件。

      确保解压 ZIP 文件并保持目录结构不变。例如,如果您使用 PKUNZIP,请使用 “pkunzip -d” 而不是 “pkunzip”。 请注意,快照还包含一个新的 RTL,很可能与前一发行版不兼容,因此也要备份旧的 RTL。

    11. 我需要写课外作业程序。你能帮我吗?

      不,请不要发有关作业的邮件给我们,我们不是老师。 开发团队试图为 Free Pascal 编译器提供良好的支持,并尝试回复电子邮件。 如果我们收到这样的电子邮件,这将变得越来越难了。

    12. 如何使用 Windows 和菜单栏制作真正的 Windows 应用程序?

      最简单的方法是下载 Lazarus。 它不仅仅是一个 Windows 应用程序,还可以在 Linux、FreeBSD 和 Mac OS X 下运行。
    13. 如何使用 Free Pascal 制作游戏?我可以制作像 Doom 3 这样的游戏吗?

      是的,你可以使用 Free Pascal 制作游戏,如果你很厉害,就能制作像 Doom 3 一样游戏。 开发游戏很困难,你需要成为经验丰富的程序员才能制作游戏。 www.pascalgamedevelopment.com 网站是一个使用 Free Pascal 和 Delphi 编写游戏的社区。

      如果你想开始,请学习 JEDI-SDLPTCPas。 你也可以尝试研究现有游戏,例如 The Sheep Killer 是一个很简单的游戏,它的代码不难理解。

    14. 应用程序崩溃时获取更多信息

      1. 最简单的方法是使用 -gl 调试选项重新编译程序。通过这种方式,LineInfo 单元会自动链接进来,程序崩溃后除了打印输出崩溃地址外,还包含源行号。 要在 backtrace 中查看运行时库(RTL)的函数名称,还必须使用 -gl 重新编译 RTL。
      2. 要进行更全面的检查,请使用调试信息编译程序(使用 -g 命令行选项)
      3. 在调试器中加载程序
        gdb(pas)(w) --directory=<src dirs> myprog.exe
        注:
        • 在 UNIX 系统(Linux、BSD)下,不要在 myprog 之后添加 “.exe”
        • src dirs” 是一个目录列表,其中包含 myprog 的源代码和单元文件,使用分号(“;”)分隔。当前目录自动包含在内。
      4. 进调试器后,你可以(可选)使用“set args <option1 option2 ...>”命令将参数传递给程序。
      5. 要启动程序,输入 “run”,然后回车。
      6. 程序崩溃后,将显示引起崩溃指令的地址。调试器将尝试显示与此地址对应的源代码行。 请注意,它可能在 RTL 过程内,因此源位置可能并不总是可用,并且很可能 RTL 不是使用调试信息编译的。
      7. 输入“bt” (BackTrace),将显示调用堆栈中的地址(在程序到达当前地址之前调用过程的地址)。 你可以使用该命令查看这些源代码行
        info line *<address>
        如:
        info line *0x05bd8
    15. 编译器似乎跳过了 -Fu 指向目录的文件

      如果复制命令未保留日期,有时会造成会出现安装/编译脚本。 目标文件比 PPU 文件旧,编译器将尝试重新编译它们。通过简单的 touch 就可以解决。

      另外要注意的是,与 Turbo Pascal 相反,FPC 会跟踪引入的文件。修改引入的文件或重复的名称可能会触发重新编译。

    16. 为什么生成的二进制文件如此之大?

      有几个原因和补救方法:
      1. 你可以创建智能链接应用程序。要创建智能链接库,请在编译单元时使用 -Cx 命令行选项。 要开启智能链接单元,请在编译程序时使用 -XX(0.99.12 及更早版本中的 -XS)命令行选项。

      2. 通常,所有符号信息都包含在生成的程序中(以方便调试)。 你可以在编译程序时使用 -Xs 命令行选项删除它们(编译单元时不会执行任何操作)
      3. 你可以使用 UPX 压缩 DOS(GO32v2)和 Windows 可执行文件(就像 pklite 一样)。 查看这里了解更多信息。
      4. 你可以使用 LXLITE 打包 EMX 二进制文件,但是你将不能再在 DOS(带有扩展程序)下运行它们。 这个问题与 1.9.x 及更高版本的编译环境(本地 OS/2 环境,编译目标为 OS2 二进制文件)无关,因为这些文件无论如何都无法在 DOS 下运行。 此外,根据所选的压缩类型,可能无法在较低的 OS/2 版本(如 2.x)上运行压缩过二进制文件。 可以在 Hobbes 上搜索 LXLITE。
      5. 打开优化,无论是对提供的包(RTL、FV、FCL)还是你自己的代码,这都将减少代码大小。
      6. 请记住,在 NT、2000、XP 下,压缩后的二进制文件启动速度相对较慢。 在压缩前,在各种条件下(操作系统、CPU速度、内存)测试该行为是否可以接受。
      通常,Free Pascal 生成的二进制文件比现代编译器生成的文件要小, 但是,它不会隐藏大型动态库中的代码。 相比之下,Free Pascal 生成的二进制文件比早期编译器生成的文件更大。 大型框架库会产生更大的文件。
    17. 运行时错误

      Free Pascal 生成应用程序异常终止时,很可能会产生运行时错误。这些错误的形式如下:

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

      在这种情况下,201 表示运行时错误码。Free Pascal 用户手册附录D 中描述了不同运行时错误码的定义。十六进制数表示发生错误时的调用堆栈。

    18. 标准单元

      要查看 Free Pascal 提供的基本单元列表,以及各平台支持情况,请参阅 Free Pascal 用户手册。在手册同一部分也有对各单元的功能介绍。

    19. 调试智能链接代码不能正常工作

      调试智能链接代码可能无法正常工作。这是因为智能链接代码没有发出类型信息。如果这样做,文件将变得巨大。

      调试时,不建议使用智能链接选项。

    20. 无法使用二进制版本的单元编译程序

      有时,即使存在可用的模块(单元文件和目标文件)的二进制版本,编译器仍会提示编译错误。这可能是由于 PPU 文件格式不兼容(编译器的主要版本之间发生变化), 或者是由于 RTL 的某个单元在两个版本之间发生了更改引起的。

      获取详细信息,请使用 -va(显示所有信息)并重新编译代码,这将显示单元加载状态。 你会发现正在加载的单元需要重新编译,因为它使用的某个单元已经被修改。

      因此,如果计划在没有源代码的情况下分发模块,则应编译二进制文件到所有编译器版本,否则必定会发生编译错误。

      换句话说,单元(PPU)文件格式在次要版本之间没有显著变化(例如:1.0.4 和 1.0.6 ),也就是说它们是二进制兼容的, 但是因为单元接口 RTL 肯定会在版本之间发生变化,因此无论如何都需要重新编译每个版本。

    21. 你会支持 ISO 扩展 Pascal吗?

      我们愿意支持 ISO Extended Pascal,但 Free Pascal 开发团队并不认为扩展的 Pascal 兼容性很重要, 因此不会花时间在上面。原因是 ISO Extended Pascal 必须被认为是一个失败的标准。

      为了解释原因,我们需要回到20世纪70年代。UCSD-Pascal,一个特殊的 Pascal 编译器流行起来, 一个重要原因是:它能让在一个架构上编写的程序在另一个架构上运行。 所有主要的 Pascal 编译器都是从 UCSD-Pascal 编译器中派生出来的,包括众所周知的 Borland 和 Mac-Pascal 方言。

      UCSD-Pascal 采用了我们都非常熟悉的系统单元和字符串变量。 ISO Extended Pascal 语言与这两个功能互斥;ISO Extended Pascal 有一个完全不同的模块化编程系统,因为它的字符串系统与 UCSD 模型完全不同。 简而言之,不可能同时支持两种方言。

      因此,软件行业无法在不破坏与现有源码兼容的情况下切换到 ISO Extended Pascal。 因此,很少有编译器实现 ISO Extended Pascal。这样做的编译器大多不受欢迎。

      目前,用 ISO Extended Pascal 编写的代码很少。 虽然 Free Pascal 可以使用另一种编译器模式来支持它,但是花时间编写一个没有源代码可供编译的编译器是没有意义的。

      GNU-Pascal 是一个可以编译 ISO Extended Pascal 的现代编译器。 如果你需要 ISO Extended Pascal 方言,我们建议您查看此编译器。

    22. 那么 .NET 呢?

      有时候,用户会询问 FPC 是否支持 .NET,或者说我们有计划在这个方面。

      用户感兴趣的主要原因,要么是 .NET 的可移植性(Mono 反复提及),要么是它被认为是 Windows 编程的下一个重要事件。

      而 FPC 核心开发人员则出于学术上的好奇而对其产生了一定兴趣(主要原因是它可以创建试验性字节码), 然而 .NET 与 FPC 结合存在以下几个问题:

      1. FPC 语言使用指针,因此只能非托管。非托管代码在 .NET 下是不可移植的,因此这已经扼杀了所有可能的好处。 这也意味着现有的 FPC 和 Delphi 代码将不能在 .NET 上运行。
      2. FPC 库不基于 .NET 类和数据模型(如果不有效地重写它们,就不能更改为基于 .NET 类和数据模型),而且这些库也只能是非托管的,否则它们将不兼容。
      3. 对于普通 .NET 代码的可移植性目前尚不清楚。 使用 hello world 级代码的小实验没有任何意义,这类代码也适用于普通 C语言。
      4. 依赖操作系统的代码将不再起作用,因为 win32 接口是非托管的。

      因此,意味着为了让 FPC 受益于 .NET,必须大范围调整语言(编译器)和库,并且与现有源码不兼容。 这可不是在 FPC 中添加对 .NET 的支持,而是几乎从头开始在 .NET 上重新实现 FPC,这将破坏向下兼容。 这也意味着必须为 .NET 重写现有程序,因为使用 FPC/.NET 编译器进行重新编译将不仅仅是简单的重新编译。

      这样做没有实际用处,虽然非托管代码有些用途(允许在 Windows 更容易与托管代码集成),但这仍然需要编写代码生成器后端、定义接口和库。 由于 .NET 占用量并不高,非托管 FPC/.NET 很少被使用,这意味着需要做大量的工作,这样做不值得。

      如果 FPC 用户完成了大部分工作(例如,字节码代码生成器,或者一些基本库),并适合在 FPC 中引入(那会是非常大的 if),我们会引入它。

      这些问题与 Java(字节码)非常相似。必须要破坏现有语言,并在目标(Java/.NET)的基础库上重写。这样的尝试与 FPC 项目没有什么协同作用,就像现在一样。

  2. Pascal 语言相关信息

    1. 移植代码到其他处理器注意事项

      因为编译器支持多种处理器体系结构,所以采取一些预防措施很重要,这样你的代码才能在所有处理器上正确执行。

      • 限制 asm 语句的使用,除非它是时间要求严格的代码
      • 在执行依赖于字节顺序的操作时,尽量不要依赖于特定机器的字节序。特别是,从文件读写二进制数据可能需要在不同的字节序机器之间进行字节交换(在本例中,swapendian 是你的朋友)。Freepascal 定义了 FPC_LITTLE_ENDIANFPC_BIG_ENDIAN 来指示目标字节序。
      • 尝试将子例程中的局部变量限制为 32K,因为这是某些处理器的限制。请改用动态分配。
      • 尝试将子例程中的局部变量限制为 32K,因为这是某些处理器的限制。在适当的地方使用 const 或 var 参数。
      • 定义了 CPU16CPU32CPU64指示目标是16、32 位还是 64 位 cpu。这有助于合并 16、32 位和 64 位特定代码。
      • 声明存储指针顺序时,请使用 ptruint 类型,因为根据处理器和操作系统的不同,指针可以是 32位或 64位。 对于 16位,它取决于内存模型。

    2. 移植代码到其他操作系统注意事项

      由于编译器支持多种不同的操作系统,因此采取一些预防措施非常重要,这样才能使你的代码在所有系统上正确执行。

      • 文件共享在不同的操作系统上实现不同,在某些操作系统(如 Windows)上打开已打开的文件可能会失败。 确保具有相同文件共享行为的唯一正确方法是使用 sysutils 中提供的 I/O 例程。
      • 在程序结束时清理,即在退出时关闭所有文件,并释放所有分配的堆内存,因为有些操作系统不喜欢某些东西被分配或打开。
      • 某些操作系统限制了本地堆栈可用空间,因此限制子程序嵌套和局部变量的数量非常重要。限制特定总堆栈空间最多 256 KB,这会使得移植更容易。
      • 不要硬编码文件路径,而是尝试使用相对路径
      • 使用以下常量(在 system 单元中定义)获取有关文件,行结束符和构建路径信息:
        • LineEnding:表示文本行结束符
        • LFNSupport:是否支持长文件名(长度超过 8.3 格式的文件名)
        • DirectorySeparator:目录分隔符
        • DriveSeparator:驱动器分隔符
        • PathSeparator:环境变量中目录分隔符
        • FileNameCaseSensitive:文件名是否区分大小写
        也可以使用 sysutils 中定义的 PathDelimPathSepDriveDelim 常量。

    3. 使用 Free Pascal 编译 Delphi 代码

      编译器支持 Delphi 类。确保使用 -S2 或 -Sd 选项(有关这些选项的含义,请参阅手册)。有关不兼容 Delphi 的列表,请查看手册。

    4. 构建单元

      它的工作方式与 Turbo Pascal 相似。文件中的第一个关键字必须是 UNIT(不区分大小写)。 编译器将生成两个文件:XXX.PPUXXX.O。PPU 文件包含编译器的接口信息,O 文件包含机器代码(目标文件,其准确结构取决于使用的汇编程序)。 要在其他单元或程序中使用该单元,必须在程序 USES 子句中包含其名称。

    5. 编译系统单元

      需要重新编译系统单元,建议安装 GNU make。在 rtl 源目录中输入 'make' 然后将重新编译包括系统单元在内的所有 RTL 单元。 你可以下载到操作系统的目录(例如 rtl/go32v2)并在那里执行 'make'。

      可以手动完成所有操作,但是需要更详细的 RTL 树结构知识。

    6. 函数重载是如何工作的?

      这是一个过程重载的示例:

                          procedure a(i : integer);
                          begin
                          end;
      
                          procedure a(s : string);
                          begin
                          end;
      
                          begin
                              a('asdfdasf');
                              a(1234);
                          end.
                      

      你必须要小心。如果某个重载函数位于单元的 interface 部分中,则所有重载函数都必须位于 interface 部分中。 如果你留遗留了一个,编译器会提示“This overloaded function can't be local”(重载函数不能在本地)的消息。 函数返回类型允许相同,但参数类型必须不同。

    7. 调用 C 函数

      可以调用 C 编写的函数,这些函数是使用 GNU C 编译器(GCC)编译。 已测试的版本为 GCC 2.7.2 到 2.95.2 。对于调用 C 函数 strcmp,声明如下:

      function strcmp(s1 : pchar;s2 : pchar) : integer;cdecl;external;
    8. 集成汇编语法

      默认汇编程序语法(AT&T 风格)与 Borland Pascal(Intel 风格)不同。

      从 0.99.0 开始,编译器支持 Intel 风格汇编语法。有关如何使用不同汇编程序风格的详细信息,请参阅文档。

      从 1.9.2 开始,编译器约定使用注册调用,这意味着编译器可以在不修改的情况下在 Delphi 源代码中汇编程序。

      AT&T 语法介绍可以在 GNU 汇编器文档中找到。

    9. 找不到 system、syslinux、sysos2 或 syswin32 单元错误

      System(syslinux - 不是 bootloader,sysos2 或 syswin32,取决于平台)是 Pascal 的基本单元, 它在所有程序中都被内置引用。该单元定义了几个标准程序和结构,以便 FPC 编译任何 pascal 程序。

      system.ppu 和 syslinux.o 文件位置由 -Fu 开关确定,通常位于 ppc386.cfg 或 fpc.cfg 配置文件中,该开关可以在命令行中使用。

      如果编译器找不到该单元,有三种可能的原因:

      1. ppc386.cfg 或 fpc.cfg 与编译器可执行文件(go32v2、win32 和OS/2)不在同一路径中, 或者找不到“/etc/fpc.cfg”或“.fpc.cfg”在你的主目录里(Linux)。
      2. fpc.cfg 或 ppc386.cfg 不包含 -Fu 或错误的行。 请参阅 build faq (PDF) 有关 fpc.cfg 和目录结构章节。
      3. 找到文件但版本或平台错误。修改 ppc386.cfg 或 fpc.cfg 以指向正确的版本或重新安装正确的版本 (如果你使用的是snapshot快照编译器,而使用的 fpc.cfg 中的 -Fu 语句仍然指向的是旧的 RTL,则会发生这种情况)。

      你可以执行“ppc386 programname -vt”,将显示当前编译器搜寻单元文件的路径信息。 使用 more(Dos,OS/2,Windows)或 less(Linux)来查看它,因为它返回的信息很多:

                          Dos, OS/2, Windows: ppc386 programname -vt |more
      unix, linux: ppc386 programname -vt |less

    10. 有一个新扩展非常好用,你会加入吗?

      偶尔会有人在邮件列表中询问新扩展的问题,随后会相继讨论。 对于 FPC 团队来说扩展是一个重大的事情,有一些标准便于筛选扩展是否“值得”增加。 最重要的预选标准是:
      1. 不得以任何方式破坏兼容性。至少 Pascal 级别的现有代码库必须保持运行。这通常比大多数人想象的要困难。
      2. 扩展必须具有实际价值。除非与现有的 Pascal/Delphi 代码库不兼容,否则任何简化的功能都不适用, 实际上,这意味着它必须做些很棘手的事情,成为一个可相容的项目。
      3. 更改必须与项目符合项目规范,实现一个具有 RAD 和通用 DB 系统的 Pascal 编译器。这不包括内联 SQL 和大型垃圾回收对象框架等功能。
      第二个规则对于特定平台特定的原因(如,与某些语言或操作系统的接口)例外。 第一个规则通常是一个问题,除非以前尝试过扩展,否则问题很难被识别出来。 最好的方法制作一份完整的书面提案,让我们可以通过这些提案进行审核。
      • 功能说明
      • 为什么需要它,它使什么成为可能?
      • 你如何实现它?
      • 大量常规使用示例和问题测试案例
      尽可能详细,尝试从实现者角度来处理问题,并尝试制作跨越多个单元和过程的示例,并检查发生了什么。 至关重要的,尝试在自己的推理中寻找突破,找出可能存在问题的案例,并记录下来。

      除了这些预选规则和文档,另一个重要的问题是谁来完成这项工作。请记住,FPC 开发人员是志愿者,其待办事项列表被预订到下一个十年。 你不能期望他们放下手里的东西来实现这个功能,因为你迫切需要它,或者认为它很好。如果你不愿意自己实现它,提交补丁,那么机会很小。 备注为“这会吸引很多用户,因为”这适用任何新开发,这会让人存疑。

  3. 运行时库相关信息

    1. 使用 graph 单元时为什么会出现颜色错误?

      如果使用 detect 作为图形驱动程序,则最终将支持最高位深度。 由于图形单元当前仅支持高达 16位/像素模式,并且过去 5 年制造的显卡都支持此位深,因此你很有可能获得 16 位模式。

      主要问题是在 16(和 15、24、32……)位模式中,调色板中的索引不再设置颜色(调色方式称为“索引颜色”)。 在这些模式中,颜色编号本身决定了屏幕上获得的颜色,并且你无法更改此颜色。颜色编码如下(至少对于 PC 上大多数显卡):

      • 15 位颜色:低 5 位是蓝色,下来是 5 位绿色,之后是 5 位红色。字的最高位被忽略。
      • 16 位颜色:低 5 位是蓝色,接下来是 *6* 位绿色,然后是 5 位红色。

      这意味着要么重写程序才能使用这种所谓的“direct color”方案,或者使用 D8BIT 作为图形驱动,将 DetectMode 作为图形模式。 这将确保你最终得到 256(索引)颜色模式。如果不支持 256 颜色模式,那么在调用 InitGraph 之后,graphresult 将包含值 GrNotDetected, 你可以使用图形驱动 D4BIT 重试。使用常量名称(D8BIT、D4BIT……)而不是它们的实际数值,因为这些值可能在下一个版本中更改! 这就是为什么存在这种符号常量的原因。

    2. 文件共享和锁定

      标准运行时库 I/O 文件例程以操作系统(system、objects单元)默认的共享模式打开文件。 如果文件被另一个进程或同一进程多次打开,则会出现问题。

      通常,不同操作系统的行为如下:

      • Unix系统:根本没有验证。
      • Windows:将返回拒绝访问错误。
      • Amiga:将返回拒绝访问错误。
      • DOS / OS/2:如果同一进程多次打开文件,不会发生错误,否则将返回拒绝访问错误。

      有两种方法可以解决这个问题:

      • 使用特定的操作系统调用(如 UNIX 和 Amiga 系统上的文件锁定)来获取正确的行为。
      • 使用 sysutils 单元或 Free Component Library TFileStream I/O 例程文件,它们尽可能多的模拟文件共享机制。
    3. 打开文件后 reset 提示 File denied 错误

      尝试使用 reset 打开非文本文件文件可能会导致运行时错误 5(访问被拒绝)。

      在上述系统单元例程中打开的文件,通过 filemode 值确定打开方式。默认情况下,filemode 设置为 2(读/写访问)。

      因此,对非文本文件调用 reset表示文件将以只读方式打开。 在尝试使用 reset 以默认方式打开只读文件会时会失败。在调用 reset 之前,filemode 应该设置为 0(只读访问)来解决这个问题。 下面是解决方法示例:

                    const
                       { filemode 值有 }
                       READ_ONLY = 0;
                       WRITE_ONLY = 1;
                       READ_WRITE = 2;
                    var
                       oldfilemode : byte;
                       f: file;
                    begin
                       assign(f,'myfile.txt');
                       oldfilemode := filemode;
                       { reset 将以只读方式打开 }
                       filemode := READ_ONLY;
                       reset(f,1);
                       { 恢复文件模式 }
                       filemode := oldfilemode;
                       // ...
                       close(f);
                    end.
                  

      有关更多信息,请参见 Free Pascal 参考手册

  4. Windows 相关信息

    1. 发布由 Windows 编译器生成的软件

      发布 Windows 平台软件没有特殊要求,可以直接开箱即用。以下是 Windows 平台的默认设置:

      • 默认堆大小为 256 KB。支持自动增长。 需要注意的是,Windows 95、Windows 98 和 Windows Me 将堆限制为 256 MB(这是操作系统的限制,不是 Free Pascal,请参阅 MSDN 文章 Q198959 以获取更多信息)。
      • 堆栈大小无限制
      • 此平台上不提供堆栈检查选项。

    2. 调试

      GNU 调试器 v4.16 及更高版本已经过测试,通常可以正常工作。因为 GNU 调试器是面向 C 的,所以某些 pascal 类型可能无法表示。 建议使用 gdbpas 或文本模式 IDE 而不是 GDB,它们都可用于 Windows 目标。

    3. 动态库

      编译器完全支持创建和使用共享库(也称为动态链接库)。有关共享库创建和使用的更多信息,请参阅开发手册。

    4. 分析

      从 1.0.7 版本开始,支持 gprof 性能分析。它需要安装 mingw,并且 fpc.cfg 指向正确的库路径。

    5. Graph 单元引发的键盘、鼠标和“虚拟dos窗口”的问题

      问题:

      • 在 Win32 下使用 Graph 单元,将不能使用 API mouse 单元来对鼠标支持或使用 Win32 Crt 单元来获取键盘数据。 原因是弹出的窗口是 GUI 窗口,而非控制台窗口。
      解决方法:
      • 请使用 WinMouse 和 WinCrt 单元代替。

      问题:

      • 当你按照上述建议,运行基于 Graph 的 win32 程序时,将打开一个虚拟 dos 窗口。
      解决方法:
      • 将应用程序类型设置为 GUI:
        {$apptype GUI}
        并将这一行放在程序 InitGraph 语句之前:
        ShowWindow(GetActiveWindow,0);
        这将隐藏 Windows 的 DOS 窗口。

      一些演示(如 fpctris)使用这些技术。

    6. Cygwin 程序目录存在于环境变量 PATH 中造成构建失败

      当 cygwin 二进制目录位于系统环境变量 PATH 中时,mingw make 工具会搜索 sh.exe,并使用它。 搜索路径发生了改变,因此,构建过程也跟着终止。

      解决方法: 暂时不要将 cygwin 目录放到你的系统环境变量 PATH 中。只在需要时添加。我们正在努力解决这个问题。

      未经测试的方法:在系统环境变量 PATH 中,将 mingw sh.exe 目录添加到 cygwin 目录之前。

    7. 在 Windows 95 下使用 DOS 编译器

      在内存少于 16 MB的计算机上, DOS(GO32V2)编译器和 Windows 95 存在问题。 首先在 DOS 框的属性中将 DPMI 内存大小设置为最大值。现在尝试在 DOS 框中启动演示程序,例如 HELLO(开始可能需要一些时间)。 如果这可行,则可以通过使用较小的堆大小(也许为2或4 MB)(选项-Chxxxx)重新编译来使编译器正常工作。

    8. 在 Windows 下使用 DOS 生成应用程序

      在某些版本的 32位 MS Windows(NT/2000/XP)下运行 DOS 软件时,发现了一些问题。 这些似乎是 DOS 仿真层(仿真的 DPMI 服务或 Go32 扩展器)存在的问题。 FPC 生成的所有软件都可能不会出现这些问题。在发布这些应用程序之前,应该在这些系统上对其进行测试,或者应该生成 Windows 版本。 请注意,在 64 位版本的 MS Windows 下不能使用 DOS 应用程序-由于这些 MS Windows 版本未提供 DOS 仿真,因此这是一个普遍限制。 你可能可以在 DosBox 仿真下使用这些应用程序,但是 FPC 团队尚未对其正式支持/测试。

    9. 鼠标光标在 Windows IDE 中不响应

      在窗口模式下,IDE 可能不会响应鼠标的移动和单击。只需更改控制台的属性,然后删除快速编辑模式选项即可。这样可以解决鼠标响应问题。

  5. UNIX 相关信息

    本节也适用于大多数 UNIX 变体,例如 Linux,FreeBSD 和 Mac OSX。

    1. 发布由 UNIX 编译器生成的软件

      • 没有堆栈空间使用限制。
      • 堆栈检查是模拟的。
      • 最低操作系统版本:
        • Linux : Kernel v2.4.x 或以上。
        • FreeBSD:版本 5.x 或以上。 (4.x 可做些小工作)
        • NetBSD: 版本 1.5 或以上。
        • Solaris: SunOS 5.7 或更高版本 (应该与早期版本一起使用,但未经测试)。
        • Mac OS X: 版本 10.4 或更高版本(Intel)或 10.3.9 或更高版本(PowerPC)

    2. 调试

      GNU 调试器 v6.5 和更高版本已经过测试,并工作正常。 由于 GNU 调试器是面向 C 的,所以某些 pascal 类型可能未按应有的方式表示。

    3. 动态库

      支持在类 UNIX 的操作系统下创建动态库。

      从共享库导入代码确实可以按预期工作,因为它不需要使用与位置无关的代码。

    4. 分析

      在 Linux,FreeBSD 和 NetBSD 下使用 gprof 分析,仅从 1.0.8 开始支持后两种。 在其他其他类 UNIX 的操作系统上,当前不支持分析。

    5. Linux/i386 以外平台上缺少 Libc

      Libc 是 Kylix 兼容性单元。因为它包含许多 i386 特定代码和来自遗留内核的特征结构, 它还没有在其他平台上提供。

      要访问 UNIX 功能,请使用诸如 baseunix 和 unix 之类的单元。

    6. 链接器为什么找不到 "vga"?

      这个错误通常是这样的:

                       Free Pascal Compiler version 3.0.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
                  

      此错误不是 FPC 或 FPC 本身的安装错误,是在 UNIX 安装中缺少 Svgalib 库。请使用你喜欢的包管理器工具安装所需的库

    7. 编译器提示缺少 as 和 ld

      通常,UNIX 系统已预先安装了汇编程序(as)和链接程序(ld),并且已经在搜索路径中。这就是为什么编译器未提供这些工具的原因。

      如果编译器找不到这些工具,则说明它们不在搜索路径中,或者未安装。你应该将这些工具所在的路径添加到搜索路径中,和/或应该安装这些工具。

    8. link.res 语法错误,或"你忘了-T吗?"

      GNU LD 2.19 中存在一个错误,导致在处理 FPC 生成的链接器脚本时崩溃。此错误已在 GNU LD 2.19.1 中修复。

      同时,LD 已修改为发出以下形式的警告

                     /usr/bin/ld: warning: link.res contains output sections; did you forget -T?
                  

      默认情况下,FPC 3.1.1 和更高版本会生成另一种不再触发此警告的链接描述文件。遗憾的是,这只能通过使用 GNU LD 2.19 之前不可用的功能来实现。 因此,早期版本提示 link.res 语法错误。但是,新的 -X9 编译器命令行参数可用于生成与 2.19 之前链接器版本兼容的链接器脚本。

      对于早期的 FPC 版本,无法删除 -T 警告,但这不会导致任何问题。

  6. 与 OS/2 相关的信息

    1. 发行由 OS/2 编译器生成的软件

      OS/2 编译器版本 1.0.x 和之前的版本基于 EMX,因此它应该可以在 OS/2 和原始 DOS 系统上运行。在 1.9.x 及更高版本中,此功能在新添加的目标 EMX 中保留,而目标 OS2 的二进制文件只能在真实 OS/2 下运行。以下注意事项适用于 1.0.x 中的 OS2 目标和 1.9.x 及更高版本中的 EMX:

      • 为 OS/2(EMX)目标生成的所有应用程序都需要 EMX 0.9d(或更高版本)运行时文件才能运行。这些文件应随你的软件一并分发。所有重新分发的文件都包含在 emxrt.zip 中。
      • 在 OS/2 下,应修改 LIBPATH 以添加 EMX DLL 路径。否则,程序将无法运行,并且将以错误 'Cannot find EMX.dll' 中止。
      • 默认情况下,堆栈可以增长到 256 KB。用户或开发人员可以使用 emxstackemxbind 实用工具对此进行更改。

    2. 调试

      GNU 调试器 v4.16(EMX 端)已经过测试(包括其 PM 附加组件 pmgdb.exe),并且通常可以正常运行。因为 GNU 调试器是面向 C 的,所以某些 pascal 类型可能无法正确表示。

    3. 动态库

      即使操作系统允许创建和使用共享库(也称为动态链接库),编译器当前仅允许从动态库导入例程(不支持创建动态库)。

    4. 分析

      该平台当前不支持分析。

    5. 在 OS/2 下使用 DOS 生成的应用程序

      据报告,由编译器生成的一些 DOS(GO32V2)应用程序(包括 DOS 编译器本身)在某些 OS/2 安装上失败。这是由于 OS/2 DPMI 服务器中的问题引起的。

      你应该在 OS/2 下使用本地 OS/2 应用程序(包括本地 OS/2 编译器),或尝试安装新的 OS/2 修订包以查看它是否可以解决问题。

    6. OS/2 下 INSTALL.EXE 1.0.6 或更低版本提示未知错误(-1)

      OS/2 下 INSTALL.EXE 1.0.6 或更高版本提示缺少 TZ 变量

      你很可能使用的是较旧版本的 OS/2(如 OS/2 Warp 3.0),并且你的环境中没有 TZ 变量。最简单的解决方案是添加 "SET TZ=..."(例如:"SET TZ=CET-1CEST,3,-1,0,7200,10,-1,0,10800,3600" 适用于大多数西欧和中欧地区)行到 CONFIG.SYS,并重新启动 OS/2。找到适合你的正确设置,可以使用像 TIME868 软件包中的 TZCALC 工具。

    7. 升级到 1.9.6 或更高版本后,OS/2 编译器无法工作

      GNU 汇编程序(as.exe)的更新版本与 1.9.6 版一起打包(必须有较新的版本才能支持现代 CPU 的功能)。此版本的 GNU 工具是使用 GNU C 的 Innotek 端创建的,并且依赖于它的 libc。这将导致对受支持的配置更高的限制,因为此 libc 需要最新版本的 OS/2 Unicode 支持库(LIBUNI.DLL 和 UCONV.DLL),而基础的 OS/2 Warp 3.0 和 OS/2 Warp 4.0 中没有这些库。更新版本由 IBM 以修复包(fixpaks)的形式分发,参见例如 WarpUpdates 站点 提供有关 OS/2 修复包的信息以及用于下载它们的链接。该问题对于 WarpServer for e-Business,MCP 和 eComStation 无效,它们已是正确的版本。

    8. OS/2 下编译失败,显示 "Can't call the assembler" 错误

      除了上述要点外,执行汇编器还有其他至少一个潜在的问题原因,并导致出现错误消息 "Can't call the assembler, error 2 switching to external assembling"。此错误可能是由 OS/2 系统无法找到汇编程序所需的 DLL 导致的。确保已完全安装 FPC(这些 DLL 是 asldos2.zip 文件的一部分),并且已根据 README.TXT 中的说明设置了 LIBPATH(然后重新启动)。如有疑问,直接从命令行运行汇编程序(如,"as --version" 以显示已安装的 as.exe 版本),这有可能便于查看缺少的动态库的名称或有关此问题的其他详细信息。

  7. 与 BeOS 相关的信息

    1. 发布由 BeOS 编译器生成的软件

      为 BeOS 目标生成的软件只能在基于 Intel 的 BeOS 版本上运行。

      • 目标系统必须至少 BeOS v4.0 或更高版本(支持 BeOS 5.1d 'Dano')
      • 堆栈大小设置为 256 KB。这个不能改变

    2. 调试

      调试可与系统提供的 gdb 版本一起使用。

    3. 动态库

      即使操作系统允许创建和使用共享库(也称为动态链接库),编译器当前仅允许从动态库导入例程(不支持创建动态库)。

    4. 分析

      该平台当前不支持分析。

    5. BeOS 链接问题

      据报告,某些版本的 BeOS 附带的某些版本的链接器已损坏。如果链接 fpc 应用程序时出现错误,请尝试从以下站点更新 ld 版本。

  8. DOS 相关信息

    1. 发布由 DOS 编译器生成的软件

      • 如果你的程序使用浮点代码(非常可能),请务必阅读“"在 80386 系统上使用 Free Pascal 创建应用程序造成崩溃”, 了解可能发生的特殊问题。然后需要数学协处理器仿真软件(wmemu387.dxe 应该与你的软件一起重新分发)
      • 目标系统必须是 DPMI 服务器。为避免出现问题,应该将 cwsdpmi.exe 文件与应用程序一起重新分发
      • 目标系统必须 DOS 3.3 或更高版本
      • 默认堆大小为 2MB。支持自动增长
      • 默认堆栈大小为 256KB。参见“更改默认堆栈大小
      • 此平台上提供了堆栈检查选项

    2. 调试

      GNU 调试器 v4.16 及更高版本已经过测试,通常可以正常工作。 因为 GNU 调试器是面向 C 的,所以某些 pascal 类型可能无法表示。 建议使用 gdbpas 或文本模式 IDE 而不是 GDB,它们都可用于 DOS 目标。

    3. 动态库

      此平台不支持创建或使用共享库(也称为动态链接库)。

    4. 分析

      此平台支持使用 gprof 进行性能分析。

    5. 在没有数学协处理器的情况下运行 Free Pascal

      在 Intel 版本上,将以下命令添加到 autoexec.bat,则编译器会自动加载仿真器:

                          SET 387=N
                          SET EMU387=C:\PP\BIN\GO32V2\WEMU387.DXE
                  
      (别忘了将 C:\PP 替换为 FPC 安装目录)
    6. 在 80386 系统上使用 Free Pascal 创建应用程序造成崩溃

      • 试图在没有数学协处理器的情况下运行 386 系统上进行浮点运算的应用程序将会崩溃, 除非使用 emu387 单元,该单元加载了数学协处理器仿真器(称为 wmemu387.dxe)。添加单元如下所示:

                                program myprog;
                                uses emu387, ...
                        

        当应用程序发布时,软件包还应该包含 wmemu387.dxe 文件以避免出现问题……

      • 某些 80386 系统存在硬件错误,如果在 POPAL 指令之后的 MOV 指令中使用它,则会损坏累加器寄存器 EAX。 在 1.0.5 版之前,编译器和运行时库可以生成这样的代码序列。现在已经修复,不会再出现此问题。

    7. 鼠标光标在屏幕上看不到

      很多 DOS 鼠标驱动程序不支持 VESA 模式下的鼠标光标。 据说罗技有一个不错的鼠标驱动程序,可以在这里找到。

    8. 访问 I/O 端口

      对于 0.99.10 之前的版本:如果你在 DOS 下,就可以使用 go32 单元的 outport*inport* 过程。

      从 0.99.8 版开始,只要在程序中使用 ports 单元(在 Win32 下不可用),就像在 TP 中一样使用 Port 数组。

      在 Linux 下可以访问 I/O 端口,但这需要 root 权限。查看 IOPerm、ReadPort 和 WritePort 过程的开发手册。(Linux 单元)

    9. 访问 DOS 内存/进行图形编程

      你也可以像 Turbo Pascal 一样,通过 absolute 或 mem[]。对于较大的内存块,请使用 Go32 单元中 dosmemput/dosmemget 例程。

    10. 更改默认堆栈大小

      在 DOS(GO32V2)目标下,默认堆栈大小为 256 KB。可以用一个特殊的 DJGPP 实用程序 stubedit 来修改。 要注意的是,堆栈也可以通过一些编译器开关来改变,如果堆栈大小大于默认堆栈大小,将使用该值,否则将使用默认值。