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 上是這樣工作的嗎？