Aros/平台/支持 *nix
mingw32 移植特别有趣。它是在 Windows 上的托管移植，本质上使用操作系统线程系统在内核中实现一个最小的虚拟机。它有一个小的引导加载程序，加载一个 ELF 内核，使其能够在 Windows 上使用 AROS i386 代码，即使 Windows 本身不使用 ELF。它所做的另一件事是将模块整齐地分成主机端和 AROS 端部分。AROS 部分作为正常模块处理，但在初始化时调用 hostlib.resource（现在包含在 kernel.resource 中）加载并链接主机端部分。这些是标准的共享库（即 DLL），它们可以引入任何需要的库依赖项，从而巧妙地避免了 X11 和 SDL 驱动程序中包含的问题，因为在运行时查找需要的库有点痛苦。这种方式，你只需要在链接时找到你需要的库。
Best option is to use one of the virtual machines - see more here
从 这里下载最新的 mingw32-i386-system
已确认在 Windows XP SP2 (2010) 上工作， ?
x86 32 位讨论线程 这里.
实验性的 x86_64 位构建讨论 这里.
目前 Windows 上没有托管网络，我建议使用虚拟机在 Windows 上测试 AROS 网络，直到 hostio.hidd 的工作完成。它是一个与平台无关的 unixio.hidd 重制版，也可以在 Windows 上运行（使用重叠 I/O）。一旦完成，移植 Windows TAP 的任务就变得微不足道。P.S. 甚至可以将 X11 显示驱动程序移植到 Windows :)
如何构建 Win7 托管的 AROS（不想弄乱笔记本电脑的出厂分区安装等，以便从 SVN 运行 AROS）。Mingw32 - 如何？或者如果可能，VS 2010 - 如何？
aros 源代码的 arch/mingw32 目录中有一个自述文件可能会有帮助。
已经开始编译了，但又遇到了一些其他问题（也就是 Netpbm 和类似的东西，这是必需的，而它又需要 zlib、libjpeg、libpng 和一些其他东西...其中除了 zlib 之外，没有一个我能够编译成功，没有大量的错误 - 似乎 Mingw 的 gcc 4.5.x 在某种程度上有点问题）。
你不需要编译 netpbm。MinGW 确实缺少它，但你可以从另一个项目 GNUWin32 下载它。它们完美地配合使用。我使用它。还需要 Windows 版本的 Python，从 python.org 获取。
很容易尝试构建 WinCE 托管版本。MinGW 托管的移植旨在与 CPU 无关。我们只需要
- 针对 WinCE 的 gcc。我想这可以做到：http://sourceforge.net/projects/cegcc/
- 编写 arch/all-mingw32/kernel/cpu-arm.h
完成之后，它应该可以运行！顺便说一下，Win64 托管的移植应该也一样简单。
你是否使用了 --with-kernel-tool-prefix=... 来指定内核工具？
请注意，--disable-crosstools 在 Windows 上不起作用。目前，你需要让 AROS 自己构建它的交叉工具。
如何在 Windows 托管的 AROS 中访问原始硬盘驱动器
- 打开 HDToolBox，在设备列表中按下“添加”，然后添加 hostdisk.device。
- 以与在本地 AROS 上浏览硬盘驱动器相同的方式浏览设备。
- 选择要访问的分区，然后在菜单中选择“分区->创建挂载列表...”。
- 保存挂载列表。默认情况下，它具有物理设备的名称（例如 DH0），并将放置在 SYS:Storage/DOSDrivers 中。
- 编辑保存的挂载列表。你需要添加文件系统名称（例如 devs:sfs.handler 或 devs:afs.handler）
- 在命令行中执行“Mount DH0:”。
挂起我有一个想法，是 GDI 窗口服务线程和主 AROS 线程之间存在某种死锁，当它们同时在某些条件下访问 GDI 上下文时。这很难跟踪。如果我在 GDI 线程中添加任何调试输出，问题就会消失。我试图用 MSVC 中断冻结的 AROS。看到所有 3 个线程都在系统调用中等待。但是从那一点开始的回溯并不是一个微不足道的任务。MSVC 无法理解 AROS 代码。你可以在冻结后使用调试器检查全局变量吗？如果是这样，你可以设置一些变量，而不是调试输出，这些变量在不同的地方被设置为不同的值，这些值稍后可以让你识别线程在冻结之前最后执行的位置。
my_debug_var = 1; dothis(); my_debug_var = 2; dothat(); my_debug_var = 3; donothing(); my_debug_var = 4;
如果冻结发生在代码中的某处，my_debug_var 将提示冻结发生在哪里。
考虑编写一些特殊的扩展模块，该模块创建一个具有单独服务线程的窗口，并在其中转储一些东西，并有可能在该线程中运行 SAD。因此，我将能够在 AROS 冻结后进入 SAD 并检查任务调度程序状态。这可以揭示一些现象。
有一点 - 死锁不会发生在窗口服务线程中。它运行良好。它只在我添加对键盘事件接收的确认之后才开始锁定，这样按键不会丢失或重复。当服务线程将按键发布到主 AROS 线程时，它会等待一个信号（在 Windows 术语中是事件）。预计 AROS 会在中断中拾取按键时触发此事件。由于 AROS 不响应中断，因此它从不发布此事件。因此，可能是中断中存在一些缺陷，导致“所有任务正在等待”状态，并且中断被禁用。需要使用描述的模块来验证此假设。
Windows 托管和本地使用相同的 NewStackSwap()，用汇编语言编写。Linux（除了 ARM）使用 C 中的通用实现，利用 swapcontext()。在 ARM 上，此函数没有在 libc 中实现，因此所有 ARM 移植都使用用汇编语言编写的相同 NewStackSwap()。StackSwap() 始终相同。它是为每个 CPU 用汇编语言编写的。顺便说一下，事实上，Linux 托管的移植可以使用汇编语言实现。只是由于历史原因没有这样做。
你不能使用一些缓冲区来解决这个问题吗？
servicethread:
on keypress/keyrelease:
lock input buffer
add event to buffer
unlock input buffer
main thread: every once in a while
lock input buffer
remove event from buffer
if event != null call kbd hidd callback()
unlock input buffer
据我所知，理论上你甚至可以摆脱输入缓冲区的锁定/解锁，使用一些原子指令技巧。
参见 arch/all-mingw32/host_scheduler.c，任务异常处理。我必须通过寄存器传递参数到异常处理程序，因为我无法修改 Windows 异常中的堆栈，因为 Windows 异常处理程序运行在与主代码相同的堆栈上。另外请注意，我将一些代码移回了 exec.library/Switch() 和 exec.library/Dispatch()。现在 kernel.resource 不需要包含 exec 的私有内容（etask.h）。
存在一些问题...
- 它将调度程序分散在多个模块中。调度的一部分由 kernel.resource 完成，一部分由 exec.library 完成。唯一的优势是摆脱了 etask.h 包含。
但它本身并不是调度，而是某种内部 exec 状态维护，它始终相同。这个想法是在检查了 UNIX 托管的代码之后产生的。我知道它很旧，但它使用 Dispatch() 进行状态更改，我喜欢这个想法。我正在为 UNIX 开发功能齐全的 kernel.resource。我相信这遵循 AmigaOS 的理念，即让这些入口点可修补，以便能够安装某种 CPU 使用情况监视器。Switch() 在某个任务失去 CPU 时被调用，Dispatch() 在另一个任务获得 CPU 时被调用。移动的代码始终相同，它重置 exec 状态。由 kernel.resource 决定何时调用它们（这取决于任务调度）。
- 目前，我们只支持 RR 调度程序。如果我们需要添加更多内容怎么办？将 Switch() 和 Dispatch() 移回 exec 意味着，我们也需要在 exec 中实现不同的调度程序。
- 某些调度程序（ppc efika、sam440，很快还有 x86）访问 etask.h 以在其中存储一些统计信息。目前，任务重新调度时间戳和任务中花费的总 CPU 时间存储在那里。如果
你在这种情况下会怎么做？不同的调度程序是否意味着只有 core_Schedule() 替换？它也可以移到 exec 中。这将使其自动在所有架构上工作。当然，如果我们提供某种对 CPU 时间的访问。顺便说一下，也许它可以基于 timer.device 的 EClock？kernel.resource 然后只需调用 Switch() 和 Dispatch() 以通知 exec 关于任务切换（注意 kernel.resource 仍然执行实际的切换，因此 exec 中没有特定于架构的代码）。然后 exec 将执行状态更新和记账。
如果此文件是特定于 mingw32 的，我认为路径应该是 aros/mingw32/irq.h（或 aros/windows/irq.h）。这将允许你仍然从任何地方交叉编译，最终为所有 CPU 和架构提供一个 SDK。
好吧，我可以做到。但是，这里是我对这个位置的最后一个论点... 实际上，这个位置是 $prefix/i386-mingw32/include/aros/irq.h。如果你正在处理 AROS，并且正在安装 mingw 交叉编译器，交叉编译器的默认路径也将最终位于 $prefix/i386-mingw32/include 和 $prefix/i386-mingw32/lib 中。这样，该文件就会出现在它应该出现的位置。
是的，存在libaroskernel.a，它会进入i386-mingw32/lib目录，但是它需要mingw32编译器进行构建，所以它只会在windows-hosted构建过程中构建。当进行例如Linux-hosted构建时，它就无法构建。
到目前为止，这件事实际上只完成了一半。如果你仍然不喜欢它，我可以将这个包含项仅安装到Windows-hosted构建中。这样，我们只会在“mingw32-sdk”目标中获取它，但会与它的linklib一起。也许这样更好（无论如何，你需要libaroskernel.lib才能使用它）。
所有hosted端口。在非Linux操作系统上，完全无法获取地址4。在遇到入口点问题后，我引入了新的宏AROS_ENTRY来缓解这个问题。
调试
[edit | edit source]之前我们总是使用串口。目前我们没有。这很痛苦。理论上我们可以用其他设备（以太网、USB等）来代替它。这些东西更复杂，需要驱动才能运行。我省略了必要的协议，因为例如对于以太网，我们可以使用一些简单的原始协议，仅仅为了能够读取消息。
所以第一个想法是：我们应该有一些东西可以被称为“调试通道”。每个调试通道都可以通过名称来识别，例如由设备驱动程序提供。
这个设备驱动程序需要：1. 早期初始化（在系统启动时）2. 某种方法将它的输出通道提供给系统。
（1）通过模块化内核解决。现在关于（2）。我们已经在内核中拥有KrnPutChar()和KrnMayGetChar()。为了简单起见，我们目前只讨论KrnPutChar()。我们可以添加一些额外的函数，例如
KrnRegisterDebugChannel(STRPTR name, APTR function)
其中name是通道名称，function是回调函数，例如MyCallback(char c)。
调用它时会发生什么？让我们记住，我们有debug=XXX内核参数，它实际上指定了输出的去向（我们可以运行多个提供调试输出的设备驱动程序，但我们只需要其中一个）。XXX可以是以下形式的字符串
<channel>:<parameters>
例如，对于串口No2，波特率为19200 bps，参数可以是
debug=serial:2@19200
该参数在早期初始化时进行处理，内核会记住它。当某些东西（驱动程序）调用KrnRegisterDebugChannel("serial", SerOutput)时，通道名称会与debug=参数提供的名称进行比较。如果匹配，内核从现在开始将使用提供的函数进行调试输出。参数是什么？只有驱动程序本身知道如何解码它们。显然，在开始使用通道之前，需要先初始化它。为此，驱动程序应该提供另一个回调函数，例如MyInit(char *params)。所以注册采用以下形式
KrnRegisterDebugChannel(STRPTR name, APTR InitCallback, APTR OutputCallback)
但是，在驱动程序接入之前呢？我们有我们的屏幕。唯一不好的地方是我们不知道如何驱动它。但是，如果我们更聪明一些…
通常情况下，要么是文本模式，要么是图形模式帧缓冲。在启动时，我们知道是文本模式还是图形模式VESA帧缓冲。唯一的问题是热重启，此时屏幕被驱动程序留在了某种状态，我们不知道。有一些选择
a) 驱动程序应该安装一个重置回调函数，它应该将显卡重置回文本模式。
b) 驱动程序可以拥有另一个回调函数，它将返回当前状态的VESA类似描述，以便在重启期间可以拾取现有的显示。
顺便说一下，同样的事情也可以让我们显示友好的Guru屏幕，而不是简单的重启。只是显示驱动程序中的这个例程应该防崩溃（它不能依赖于中断、其他库等，甚至不能依赖于exec本身）。同样，我们需要一些方法来注册这个例程。
有人可以提出一些框架吗？我在这里已经筋疲力尽，特别是考虑到
a) 在某些情况下，显示驱动程序可以卸载。
b) 可能存在多个显示器，如何选择正确的显示器（例如，双头卡上未使用的连接器可能没有物理连接）。
现在让我们回顾一下KrnMayGetChar()。目前AROS拥有内置的SAD调试器。我从i386-native版本中获取了它，并稍微适应了新的环境。现在它可以在Windows-hosted上完美运行，我可以使用C:Debug命令运行它。事实上，在其他端口上你也可以运行它，你会在调试输出中看到一个提示符，但无法与它进行交互 - KrnMayGetChar()只在Windows版本中实现。
当前的SAD功能并不多，但它只是需要开发人员的关注。它可以成为一个有用的工具。特别是如果我们发明了一些方法来在发生Guru时运行它（就像经典的Amiga(tm)上的那样）。
所以，回到主题。首先，并非所有设备都是双向的。其次，为什么不使用我们自己的机器键盘呢？然后驱动程序需要以下函数：InitCallback、InputCallback、ReleaseCallback。例如，当你离开SAD时，可以调用Release函数，将设备返回给正常的操作系统使用。
到目前为止，我们已经有了五个函数（假设调试输出从未释放）。如果它以某种方式被释放，那么我们就有六个函数。也许我们不应该有两个注册函数，而应该只有一个基于标签列表的函数？
如何配对输入和输出通道？假设设备不是双向的？或者，也许我们不应该将它们配对，而是允许用户指定第二个参数，例如“debuginput=ps2kbd”？
MacOSX
[edit | edit source]介绍
[edit | edit source]从这里下载
或者
建议在你的MacOSX机器上安装git，并通过git克隆AROS源代码
$ git clone git://repo.or.cz/AROS.git
然后，你可以使用./configure来设置你的交叉编译环境。
$ mkdir AROS.darwin-x86_64 $ cd AROS.darwin-x86_64 $ ../AROS/configure --target=darwin-x86_64 $ make -s # This is a lot less verbose [get a coffee. Or five.]
然后，要运行AROS
$ cd bin/darwin-x86_64/AROS $ boot/AROSBootstrap
一些你可能想做的事情
1) 修改bin/darwin-x86_64/AROS/S/Startup-Sequence，运行“NewCLI”而不是“WANDERER:WANDERER” - 这至少会为你提供一个全屏文本控制台。
2) 使用附带的补丁创建一个“C:RawEcho”命令（使用“make -s workbench-c-quick”构建它），你可以使用它将调试消息发送到运行boot/AROSBootstrap的MacOS文本控制台
- | 你的X服务器似乎禁用了后台存储！
你可以安全地忽略此警告。我已经以这种模式运行了2年。已确认它适用于x86 10.5.8 Leopard 10.6.2和10.6.4 Snow Leopard。不要忘记安装x11 XQuartz)，它在安装光盘上。在/Applications/Utilities中应该有一个X11.app。如果没有，那就是你的问题。
当赏金创建时，Mac仍然只有PPC，从最近的svn日志来看，它应该也能够在Darwin PPC上运行。
你不需要SDL，但你需要一个X服务器来进行图形处理。较新版本的OSX通常已经安装了一个。不知道SDL是否也可能，在iOS上不行。Cocoa SDL需要在程序的main()中进行特殊准备才能工作。
请查看arch/all-darwin/README.txt以获取构建说明。不要尝试构建contrib，某些包会失败，SDL_mixer和gmake IRC。也许你忘记向configure添加—target=darwin-i386？但是，很奇怪，在我的机器上不需要它。
是的，darwin 32位集。我不得不手动将二进制文件移动到包含i386-aros-gcc之类的名称的路径中，以使configure满意。
/usr/local/bin是否已经在你的路径中了？工具链使用—prefix=/usr/local构建。如果你将这两个存档提取到你的/usr/local中，它应该可以正常工作。
目前还没有时间完成GPT分区表处理（它目前是只读的，你可以在GPT分区上安装AROS，但必须使用第三方工具来分区驱动器）。目前已经启用了写入GPT，但不要尝试这样做。它会破坏你的分区表！！！CRC和备份表不会更新！！！
1. 如果你遇到挂起，可能是AROS在后台崩溃了。如果你使用VESA模式，如果你在命令行中添加“vesahack”，则可以看到调试日志。这将设置分屏模式。在上半部分你会看到AROS屏幕，在下半部分 - 调试日志。
2. 如果你在早期启动时遇到崩溃，尝试在命令行中添加“NOACPI”。ACPI内容测试非常糟糕，因为发现功能在Mac上失败（不同的ROM）。
自建
[edit | edit source]需要下载XCode或安装MacPorts。警告：macports与xcode 4.3不兼容。请使用旧版本...
运行“./configure --target=darwin-ppc --disable-crosstools”，如果失败，请发送结果（config.log和终端输出）
如果成功... 那么任何构建错误“make -s”都会生成。
如果*那*成功... 那么任何致命错误“cd bin/darwin-ppc/AROS; boot/AROSBootstrap”都会生成。
如果*那*成功... 它就工作了！
如果“gcc -v”和“make -v”工作，你就完成了90%。
如果你因为缺少libpng和netpnm而出现构建错误，你可以使用Fink解决这个问题。更好的是，使用Homebrew，它有一个PPC分支，在我的旧PowerBook上运行良好：）。
安装完成后，它将允许你获得X-Code没有提供的额外开发包，例如
$ sudo apt-get install libpng3
构建darwin hosted端口，尝试遵循arch/all-darwin/README.txt中的指南。不需要使用—enable-crosstools开关构建交叉工具（它可能根本不起作用），因为你应该安装Sonics预构建的交叉编译器。
事实上，交叉工具的构建过程是错误的。它依赖于已经存在的链接库和启动代码，而这些代码只能通过包装脚本构建。当然，在非 ELF 主机上，包装器将无法工作。它应该以完全不同的方式完成，涉及更多步骤。
- 构建 binutils，它们没有任何先决条件。
- 构建 collect-aros。它的 env.h.cross 文件包含构建说明。
- 解压缩 gcc，配置它并执行 'make all-gcc' 和 'make target-libgcc'。这将生成一个基本的 C 编译器。
- 使用此编译器，构建 AROS 链接库。
- 完成此操作后，使用 'make' 构建 gcc。它也将构建 g++ 及其库。
当然，在构建 gcc 之前也应该创建 AROS 包含文件，但 gcc 本身不需要此步骤。
在 Darwin 上，AROS 使用预安装的交叉工具构建。Jason，你的新配置不再支持它，似乎使用主机编译器和包装器。这在 Darwin 上是不可能的。然后 Darwin 构建需要设置—with-toolchain=... 和—with-kernel-tool-prefix=ppc-aros-
Windows 也是如此。我猜类似的问题影响了 Android（它使用 Android 交叉编译器作为 $KERNEL_CC 和包装器作为 $TARGET_CC。使用 Linux gcc 编译 Android 二进制文件是不可能的，它们的 ABI 有些不同！
指定—with-kernel-toolchain-prefix=i386-aros- make 查询仍然为内核 cc 打印 /usr/bin/gcc。
如果你在 Darwin 上编译为 Darwin 主机，则完全不使用—with-kernel-toolchain-prefix。
或者只使用 '--with-kernel-toolchain-prefix='。
记住，'kernel' 用于编译 AROS 引导程序的 Darwin 部分。
以及所有在构建宏中指定 compiler=kernel 的内容，例如 arch/all-unix/kernel。
AROS 模块不再有 compiler=kernel。在非 ELF 系统（Windows 和 Darwin）上，无法将不同的对象链接在一起。compiler=kernel 用于
- 引导程序
- 主机端 DLL（在 Windows 主机中大量使用）。
- 支持链接库，例如 libarosbootstrap.a
现在，直接与主机操作系统交互的 AROS 模块使用另一种技巧。它仍然是 $TARGET_CC，但带有 -nostdinc -isystem $GENINGDIR。这允许生成仍然符合正确主机端 ABI 的 AROS ELF 对象。如果我们想知道底层主机是什么，我们会明确添加 -DAROS_HOST_$(AROS_HOST_OS) 标志。这是因为 AROS 代码中没有 __linux__（__darwin__，__win32，等等），始终是 __AROS__。
这不能是主机端的 elf 包装器。为了构建在操作系统下运行的程序，你需要该操作系统的 SDK。实际上，elf 包装器与 aros-gcc 相同，但会生成静态链接的（ET_EXEC）二进制文件。这仅适用于构建原生引导程序（在裸机硬件上运行并自包含）。
在 Darwin 上构建 Darwin 主机？配置错误。实际上这些架构是 Darwin、Windows 和 Android。它们的 KERNEL_CC 即使使用包装器也不能用于构建 AROS 代码。因此，这三个架构必须强制使用 AROS 交叉工具，无论是构建的还是预安装的。
如何在笔记本电脑上用键盘代替 rmb？CTRL 不起作用。转到系统偏好设置 -> 触控板。选中“辅助点击”框，然后从下拉菜单中选择“右下角”。然后你就可以按触控板右下角来进行右键点击。
顺便说一下，要从 OS X 访问 AROS 文件结构，只需右键点击并选择“显示包内容”。
对于托管系统，我们有一个驱动程序将 AHI 包装到开放的声音系统，参见 arch/all-unix/libs/oss。可能可以为 Darwin 托管编写类似的东西。
为了解决异步 I/O 问题，想知道为什么 AROS 不能通过 AROS 内部线程处理这个问题。这正是 asyncio.library 的工作方式。线程可以在 68k AROS 内部或外部，例如 Linux 主机线程。
从主机的角度来看，AROS 只是一个线程。因此，如果一些 AROS 进程调用阻塞 I/O，它会阻塞整个 AROS。不会进行任务切换，因为不会传送信号。所以这是相关的。AROS 必须是子线程，这些线程映射到原生线程（顺便说一下，这有时在 JVM 中完成，也包括在 Linux 中）。
至于主机线程，还有一个大问题。在 Android 主机端口中尝试过，但失败了。当 SIGARLM 到达时，你无法知道哪个线程被中断。这完全破坏了 AROS 的任务切换器。也许值得检查一下在常见的 JVM 实现中是如何解决这个问题的。
已经有一个解决方案，以 unixio.hidd 的形式存在。然而，它只对文件描述符起作用。据我所知，eSounD 仅提供基于库的 API，具有阻塞函数。没有某种形式的 UNIX 套接字/管道/等等。你可能想尝试一下 eSound：eSound 存在一个问题。它缺乏异步 I/O 功能，只提供阻塞调用。你不能从 AROS 内部使用阻塞 I/O。这会导致阻塞整个 AROS，包括中断，并将提供非常糟糕的用户体验。
当然，可以实现 oss.library，它可以在 Core Audio 之上运行。但我认为编写一个独立的 AHI 驱动程序会更简洁，无需任何额外的 API 包装器。它会更好地利用 Core Audio 的可能性，不会仅限于 oss.library 所具有的功能。并不是说 oss.library 是一个快速黑客的糟糕的东西。
偏向 PortAudio 而不是 eSound - 我不知道提到的 I/O 问题是否也反映在 PortAudio 上。但总的来说，直接访问 OSS 似乎不是最佳解决方案，因为 eSound - 也可能是 PortAudio - 作为额外的抽象层确实确保了 AROS 不会阻塞主机音频，而是进行了适当的混合。为了解决异步 I/O 问题，想知道为什么 AROS 不能通过 AROS 内部线程处理这个问题。这正是 asyncio.library 的工作方式。线程可以在 68k AROS 内部或外部，例如 Linux 主机线程。
说到套接字……也许一个由 AROS 通过 localhost IP 连接指示的原生 Linux 音频客户端将是一个解决方法。这意味着 asyncio 和 SIGURG 可以在那时工作……
以下是一个例子，说明一些人如何使用 OSS 和 UDP 套接字开发了一个婴儿电话客户端/服务器（即发送方/接收方）。
当然，如果你想要基于连接，具有更高的可靠性和音频设置的预先协商，它会变得更加复杂 - 可能可以使用 TCP 代替，并附带一个合适的报头。
Sashimi
几天前我在 Linux PPC 上运行它（我在那里编写了 emul_dir.c 的初始版本），也工作正常。是新的构建吗？这是一个完整的重建。问题只发生在—enable-debug 中，因为 ASSERT_VALID_PTR 在 AllocateExt 中被调用，而 AllocateExt 在 PrepareExecBase 中被调用。
PrepareExecBase() 非常棘手。如果你想调试它，可以暂时添加静态链接的 KrnBug() 调用（从 kernel_debug.h 复制存根并使用它）。执行调试还没有完成。但是，此例程应该足够简单，不需要任何调试。
恢复了这一点，现在链接到 libgcc.a。缺少符号的问题没有发生在 Rosetta 上，但能够在 10.3 G4 ppc ibook 上测试它现在可以工作了。
现在从 Rosetta 获取一些调试输出，使用我的最新提交，没有它们你只会得到垃圾。如你所见，在 HostLib_Open 之后，klo 的值被破坏了。破坏可能会有所不同，具体取决于你在哪里放置调试输出。
所有托管端口。在非 Linux 操作系统上，根本无法获取地址 4。在遇到入口点问题后，引入了一个新的宏 AROS_ENTRY 来缓解这个问题。
不知道 GNU binutils 是否支持 i386-darwin 目标进行交叉编译，以及设置它有多困难。在编译 Mac OS X 托管的 AROS 时，我不得不进行以下修补，否则编译器将找不到一些包含文件（例如 sys/_types）。这是我的构建环境的问题还是更普遍的问题？你是否从 aros-archives 安装了我的交叉工具链，还是你使用了某些技巧，或者—with-crosstools？我确实安装了你的交叉工具链，并按照你的构建说明进行操作，但我也从 MacPorts（用于构建原生）安装了通用的 i386 交叉编译器。
Index: workbench/libs/mesa/src/mesa/mmakefile.src
===================================================================
--- workbench/libs/mesa/src/mesa/mmakefile.src (revision 35709)
+++ workbench/libs/mesa/src/mesa/mmakefile.src (working copy)
@@ -131,6 +131,7 @@
-I$(SRCDIR)/$(CURDIR)/../talloc \
-I$(SRCDIR)/$(CURDIR)/../gallium/include \
-I$(AROS_DEVELOPMENT)/include/gallium \
+ -I$(AROS_DEVELOPMENT)/include \
USER_CFLAGS := -DUSE_MGL_NAMESPACE -ffast-math $(FFIXED) -DMAPI_GLAPI_CURRENT
顺便说一下，是否不应该使用—with-crosstools？（而且这现在不是大多数其他架构的默认设置吗？）。据我所知，—with-crosstools 工作不正常。大多数架构目前使用主机 gcc 的包装器脚本。交叉工具仅为 MESA 构建，然后仅使用 g++。是的，这确实不正确。
实际上，我正在考虑改变这一点。我认为真正的交叉编译器应该在主机基础上强制执行，而不是在目标基础上强制执行。也就是说，如果我们在非 ELF 主机（例如 Windows 或 Darwin）上编译，则使用 $cpu-aros-gcc。否则使用包装器脚本。这将使在任何构建机器上交叉编译任何端口变得非常容易。
看起来你安装了交叉编译器，但没有将 AROS SDK 安装到它的目录（/usr/local/i386-aros/include 和 /usr/local/i386-aros/lib）。c++ 编译器没有被 AROS 构建系统包装起来，因此它不会向它提供 Development/include。也许将其添加到 mmakefile.src 可以作为一种选择。
已知缺陷
1. Stackswap 测试在 NewStackSwap() 中崩溃，原因正在调查中。但是可执行文件可以完美运行。我认为问题可能是由于 swapcontext() 嵌套造成的。
2. X11 驱动性能比较差。此外还有一些小问题。我认为这些问题是由于缺少后台存储造成的。可以启用后台存储，但这有点棘手。
事实上，X11 驱动需要彻底重写，以便支持屏幕合成并在没有后台存储的情况下工作。此外，其中还存在一些明显的编码错误。不幸的是，我对 X11 编程不太了解，所以暂时不会接手这项任务。
未来
- x86-64 Darwin 构建。
- ppc-Darwin 构建（在某人的帮助下测试）。
- iPhone 托管端口。
在测试 Darwin 托管构建的部分时，我再次遇到了这个问题。目前我们有一个 AROS.boot 文件，用于存放架构名称。真的有必要在那里存放完整的名称吗？
实际上，这会阻止使用相同 CPU 的不同机器使用同一个引导磁盘。例如，ppc-chrp-efika 分区无法在 ppc-sam440 上启动，尽管它们是相同的！我个人在 Darwin 上构建了 aros-base 和 aros-strap 内核模块，然后试图在我的现有 Windows 托管安装（由于还没有 aros-bsp-darwin）上启动它们时遇到了这个问题。
我考虑了两种选择。
1. 恢复到检查 C:Shell 文件。LoadSeg() 不会加载外来 CPU 的二进制文件。因此，我们将能够检测哪些分区可以在哪些 CPU 上启动（我记得这个文件是作为解决 x86-64 和 i386 安装共存问题的方案提供的）。
2. 只用这个文件检查 CPU（例如，“i386” 或 “x86-64”）。这样就可以解决两个问题。此外，将来我们还可以向该文件添加更多数据（如引导优先级）。这就是我们应该保留该文件的原因。
有可能在 x86-64 MacOS 上运行托管的 AROS。存在一个问题。
当前的 AROS 可执行文件使用小代码模型，因此需要将它们加载到地址空间的低 2GB 中。在原生 AROS 中这没有问题，在 Linux 中我们可以使用 MAP_32BIT 标志。但是 BSD 中没有这样的标志，因此在 Darwin 中也没有。此外，Darwin 将整个低地址空间保留用于自身需求。用户空间从 0x1000000000 开始。这意味着无法进入低 2GB。只有更改代码模型才能解决这个问题。对于 x86_64 的小代码模型是这样吗？是否存在“大”代码模型？我也想知道不同代码模型对代码大小、堆栈使用、速度等的影响。当然可以。它没有施加任何限制，但对二进制文件大小有负面影响（所有引用都是 64 位）。小代码模型使用 CPU 指令的特殊形式，其中所有引用仍然是 32 位的。模型参考。
Darwin 本身对可执行文件使用小 PIC 模型（-fpic 选项始终强制开启）。这允许覆盖那里的问题。我建议在 64 位 AROS 上使用相同的模型。但是，这意味着 -fpic 选项需要在 AROS 中普遍生效。为了做到这一点，我们需要稍微改变链接过程。需要向 ld 提供 -q 而不是 -r。这将指示它链接一个最终的可执行文件 (ET_EXEC) 文件，但保留其中的重定位。链接最终可执行文件涉及额外的魔术，例如创建全局偏移表。我认为支持可执行文件中的不同代码模型并无害。我还认为，用于代码的默认代码模型应该能够在所有 AROS 端口上运行。我还认为，默认代码模型可以在不同的 CPU 上有所不同，例如，在 m68k、i386、PPC 上为绝对模型；在 x86-64、PPC64 等上为相对模型。当然可以。在 i386 上，默认模型是小模型，它仍然有一些差异，我不知道哪些差异。我建议在 x86-64 AROS 上将小 PIC 作为默认代码模型。但是，为此，PIC 应该在普遍情况下生效。目前它没有生效（尝试用 -fpic 编译 hello world，看看会发生什么）。
问题是现在应该在主干中实现它，还是最好延迟到 ABI_V1 分支之后，在该分支中，当前的 ABI 将被分支到一个单独的分支中。例如，你现在可以在 branches/ABI_V1/trunk-piccodemodel64 中实现你的功能。
我认为我们应该看看有多少人拥有他们想要运行更新程序的当前 x86_64 安装。此外，升级现有安装需要多大的工作量。这不是一个真正的问题，因为第一组更改完全向后兼容。AROS 仍然会加载现有的可执行文件。我甚至可以向 collect-aros 添加一个 #ifdef，更改只会影响 64 位 AROS。32 位可执行文件仍然保持旧格式。我只是不喜欢代码中充斥着 #ifdef，而且如果我对所有 CPU 实现更改，那么所有 CPU 都将获得生效的 -fpic 选项。这不会更改除 x86-64 之外的任何其他内容的默认代码模型。只是 ELF 将成为真正可执行文件（修改我们的 InternalLoadSeg() 以支持它们非常简单。我认为过去我们已经多次打破了 x86_64 二进制兼容性而没有多想（例如，在系统结构中将 ULONG 更改为 IPTR）。IMO，我们用这个更改做同样的事情无关紧要。
无论如何，我现在在实现 clib 拆分方面已经相当先进，拆分已经完全完成，contrib-gnu 基本上可以编译和运行。顺便问一下，你知道当前的 arosc.library 将其线程局部数据存储在 exec 的 ETask 结构的私有字段中吗？我希望你将其更改为仅使用公共 API 的东西（例如，使用 AVL 树将线程数据与进程相关联）？我只需要在 setenv/getenv 中解决一个 bug，然后基本上就完成了。所以我认为等待 ABI_V1 实现才能开始这项工作不会延迟几个月。我们还需要与 m68k 人员保持一致。这是我在 ABI_V1 分支中完成的一项重要工作。数据存储在 AVL 树中。这是否属于“按调用任务存储的共享模块处理”。如果是，你能在 SVN 中指出代码吗？
它现在就可以实现。只有一个问题：新的可执行文件无法在旧的 AROS 上运行。旧的可执行文件仍然可以在新的 AROS 上运行，我会注意这一点。实现这一点将允许我们继续前进，并实现对 -fPIC 的特殊支持，这将使一些很棒的功能成为可能，例如将全局变量移动到库基址。这个更改可以进行吗？此实现不应该是最终实现，但要保留在 ABI_V1 实现阶段调整 AROS 代码模型的可能性。可以使用 -mcmodel gcc 选项指定代码模型。在没有任何更改的情况下，我们可以在非 PIC 模式下使用所有代码模型。我的更改的目标是使构建 PIC 二进制文件成为可能。PIC 会以这样的方式更改 x86-64 小模型，使其能够使用任何地址范围，只限制代码的大小而不是位置。
在 x86-64-Darwin 托管的 AROS 上的工作仍在继续。它已经启动并进入 Wanderer，但许多组件崩溃。这是因为仍然有很多地方将指针通过转换为 ULONG 进行截断。在 Linux-x86-64 上，你不会注意到这一点，因为 AROS 内存分配在低区域（低于 2GB 限制）。
在 Darwin 上（与其他任何 BSD 一样），你没有这样的可能性。Darwin 将整个低内存保留用于操作系统使用，应用程序的内存从 0x001000000000 开始。这在一定程度上限制了你在 AROS 中可以做的事情。例如，AROS 无法加载位图字体，diskfont.library 会崩溃。这是因为 diskfont.library 在尝试处理加载到高地址的 AmigaDOS hunk 文件时访问了错误的地址。为了防止将这些文件加载到高地址，我引入了 MEMF_31BIT 标志。此标志用于其结束地址不大于 0x7FFFFFFF 的内存区域。此标志仅在 64 位机器上有效。在 32 位架构中，exec.library 会忽略它，因此不需要在其中设置它。如果有人正在开发 x86-64-pc 端口（Alain？），他应该考虑到这一点。内存初始化例程应该使用此标志并用它标记相应的区域。在 x86-64-Linux 托管端口上，设置了此标志，因此该端口可以加载 AmigaDOS hunk 文件（并使用位图字体）。这是因为引导程序向 mmap() 调用提供了 MAP_32BIT 标志。目前只有 InternalLoadSeg_AOS() 例程向 AllocMem() 提供此标志。但是我认为，还有更多地方应该使用它（例如，具有 32 位 PCI DMA 的设备驱动程序）。我在实现 PIC 支持方面遇到了问题，因此目前我使用大代码模型来编译 Darwin 托管的 AROS。我以后会实现 PIC，这最终会导致在 binutils 中实现自己的 BFD 后端。我还没有确定 gcc 应该默认使用什么代码模型，但肯定不是小模型。使用小模型的 ELF 会造成问题，因为代码模型在 ELF 中没有任何地方记录，我也不知道是否可以使用某些启发式方法来猜测它（例如，检测特定重定位类型）。目前，使用小代码模型的程序将在 Darwin 托管的 AROS 上崩溃。用大代码模型（以及将来的 PIC）编译的程序将在任何 x86-64 端口上运行。即使我成功实现了自动检测，也不会让小代码神奇地运行在所有端口上。尝试加载它会导致“文件不可执行”，仅此而已。
我想要的一个额外功能是，你可以决定哪些变量放在 libbase 中，哪些变量对所有 libbases 都是全局的；也许可以用一些 AROS_xxx() 宏来包围变量定义来实现这一点。
此外，我可以使用 ELFOSABI_AROS 定义（为 AROS 保留的 ELF ABI 号）。但是，这将要求使用 AROS 版本的 binutils 进行链接，Linux ld 将不再进行任何操作。我一直想让 AROS 程序成为真正的 ELF 程序（尽管仍然保留重定位信息），但我认为这应该属于 ABI V1。好吧，我会在 collect-aros 中使用 #ifdef。
目前，AROS 构建系统不支持为不同的 arch/cpu 提供不同的 .conf 文件。如果实现了这一点，就可以做到。无论如何，与 PPC 的二进制兼容性是未来的提案。也许它甚至会成为一个单独的 AROS 版本。这可以公开讨论。我们的一些领导人不喜欢 MorphOS ABI，并且不希望将其作为 PPC AROS 的默认 ABI。
无论如何，我认为 LVO 应该尽可能相似。实际上，这个地方应该是唯一发生 LVO 交换的地方。在 AmigaOS3.9 和 MorphOS 之间似乎没有其他冲突的扩展。
ABI V1 的 C 库是否允许在一个任务中分配内存，并在另一个任务中释放它？目前不行，我还没有重新实现此功能，因为我没有找到任何使用它的代码。至少 MPlayer 需要这个功能——我必须在当前的 arosc.library 中添加一个丑陋的 sharecontextwithchild 函数来实现这种行为。所以如果我能拿到源代码，我可以考虑最佳的实现方式。它似乎与线程有关。
如果你指的是 PIC 和 GOT，这是否意味着我们也可以拥有共享对象？也许可以，但请不要这样做。不要从 OS4 中复制糟糕的设计决策。使用共享对象的 OS4 程序启动速度与其他操作系统 (Linux、Windows 等) 相同。事实上，我们现在就可以拥有它们。AROS 中的共享对象不需要是 PIC，因为每个二进制文件都是可重定位的。但是，我同意，加载时链接并不好。
找到 PPC Darwin ABI 文档，并与 Linux ABI 进行比较。如果你仔细检查堆栈帧的布局，你就会注意到差异以及造成垃圾的原因。在 ppc darwin 上，调用函数允许写入调用者堆栈帧的参数区域。我认为可以通过每个主机 OS 调用周围的一些 C 或 Asm 存根来解决这个问题。
所以，我应该寻找图形驱动程序、声音和键盘等。我是否可以假设我应该在 PS3 端口的 Linux 版本中搜索它们？还有一个问题，Linux 曾经有 otheros 选项，但现在这个选项不再存在于 PlayStation 3 3.21 以上版本的固件中。所以，我不能使用自定义的 otheros.bld 文件来启动。
我已经设置了来自 *http://psl1ght.com/ 的 *psl1ght sdk，它使创建在带有自定义固件的 PS3 上运行的 pkg 或 elf 文件成为可能。现在我感兴趣的是使用该 sdk 作为起点，将 AROS 移植到 PS3 gameos。我知道 PS3 上有一个 sdl 移植 gameos。你可以将其用作参考，了解如何执行某些操作，但同时也要注意
http://git.kernel.org/?p=linux/kernel/git/geoff/ps3-linux.git;a=summary
http://repo.or.cz/w/freebsd-src.git/tree/HEAD:/sys/powerpc/ps3
http://www.ki.nu/hardware/ps3/
记住第一个是 GPL，甚至索尼也有版权，不要从那里复制粘贴代码。我似乎记得，即使是最后一个也曾在某一时刻使用过 GPL 代码进行显示。我不确定我链接的项目中的驱动程序是否有帮助，其中一些可能会有帮助。
我不确定如何在当前固件上实现这一点。虽然我们有在 gameos 上运行自制代码的优势。所以，我猜我需要一个 pkg 应用程序文件来充当 AROS 的引导加载程序。也许我应该尝试了解更多关于 petitboot 的信息？它曾经是 PS3 的引导加载程序，尝试将其制作成 pkg 文件？我知道 PS3 上的 Linux 引导加载程序需要 otheros 功能，但由于这是针对越狱机器的，这些机器拥有 geohot 的 lv2 peek 漏洞，我们可以访问 PS3 内存区域的任何部分，因此理论上缺乏 otheros 选项不会阻止其他操作系统的执行 (asbestos 便是如此)。
我正在尝试了解将 AROS 移植到 PS3 gameos 需要什么。我需要什么？我知道 ppc linux 移植，我正在尝试创建一个新的配置文件来使用。
据我所知，sdk 使用交叉编译器，因此有可能在配置中添加类似于 MacOS X 托管端口中的部分，该端口也使用预构建的工具链，或者检查其他通常使用交叉编译的原生端口，例如 sam440 或 ppc-efika 端口。
我假设 sdk 应该提供很多必需的东西，也许现在还没有，但随着时间的推移会提供。总而言之，我们需要一个引导应用程序来初始化图形、声音、USB、键盘、蓝光驱动器并打开屏幕？AROS 在 Linux 上是这样工作的吗？
不完全是，像 Linux 这样的托管端口作为正常的主机程序启动 (arch/all-hosted/main.c)，它充当引导加载程序，然后跳到起始地址 (arch/all-unix/kernel/kernel_startup.c)。原生端口类似，但它需要做更多工作来接管整个机器。这方面的一部分是设备驱动程序，但还有更多。例如，sam440 端口必须在启动的早期阶段初始化一些寄存器、中断控制器和 MMU。你可以通过研究 AROS 源代码来了解所有这些，毕竟设备驱动程序必须以 AROS 的方式完成，sdk 示例和其他 gameos 黑客代码，也许在网络上搜索一些 Cell 芯片文档也是一个好主意。
然后，你需要在 arch 目录中设置一些东西，以便它包含特定于 PS3 的部分。然后让 sdk 生成一个在 PS3 上加载和启动的二进制文件。这通常是引导加载程序，它从引导介质加载所有必要的模块，然后跳到其中一个的起始地址。引导加载程序可能已经必须设置一些硬件才能完成其工作，其余部分可以在以后阶段完成。此外，您将需要用于显示、USB（至少用于键盘和鼠标）、硬盘驱动器和蓝光驱动器的硬件驱动程序。
这是可能的吗？会遇到什么问题？我认为这是可能的，但这不是一项简单的任务，最大的问题可能是不要在某个时刻放弃。
顺便说一下，AROS 不需要 SDL，但我们有一个 SDL 显示驱动程序用于托管端口。
所以，我应该寻找图形驱动程序、声音和键盘等。我是否可以假设我应该在 PS3 端口的 Linux 版本中搜索它们？
还有一个问题，Linux 曾经有 otheros 选项，但现在这个选项不再存在于 PlayStation 3 3.21 以上版本的固件中。所以，我不能使用自定义的 otheros.bld 文件来启动。
我不确定如何在当前固件上实现这一点。虽然我们有在 gameos 上运行自制代码的优势。所以，我猜我需要一个 pkg 应用程序文件来充当 AROS 的引导加载程序。也许我应该尝试了解更多关于 petitboot 的信息？它曾经是 PS3 的引导加载程序，尝试将其制作成 pkg 文件？
我知道 PS3 上的 Linux 引导加载程序需要 otheros 功能，但由于这是针对越狱机器的，这些机器拥有 geohot 的 lv2 peek 漏洞，我们可以访问 PS3 内存区域的任何部分，因此理论上缺乏 otheros 选项不会阻止其他操作系统的执行 (asbestos 便是如此)。
总而言之，我们需要一个引导应用程序来初始化图形、声音、USB、键盘、蓝光驱动器并打开屏幕？AROS 在 Linux 上是这样工作的吗？