<<ExOS R138：瀏覽器主導之 NT-style 作業系統執行環境、虛擬檔案系統、安全機制與 XSH 應用平台之研究>>

研究範圍：ExOS R138 開發套件、ExDesk 桌面環境、ExFS/EFS/ExES/ExMD3、NT Core/NT API、XDL、XSH/XSH IDE、ExOS CMD Mode、HTML/CSV/TXT 編輯器、記帳與 Chat 應用，以及 ExOS 2D Game SDK；並以使用者提供之線上 Demo（https://jplop.lionfree.net/exos/）與運行畫面作為系統展示證據。

一、研究主題名稱

中文題名：ExOS R138 瀏覽器主導式 NT-style 作業系統執行環境之架構、虛擬檔案系統、安全模型、Shell 應用平台與 2D 遊戲執行層研究

研究焦點副題：從 ExOS Core、NT Executive、ExFS/EFS、XDL、XSH 到 ExDesk 的跨層整合與可運作性分析

二、英文名稱

Architecture, Virtual Filesystem, Security Model, CMD-Compatible Shell and Application Platform, and 2D Game Runtime of ExOS R138: A Browser-Hosted NT-Style Operating Environment

三、摘要

本研究以 ExOS R138 為研究對象，探討一套以 Chromium/V8 類瀏覽器能力為宿主、以 JavaScript/PHP 與 sandboxed XSH 執行環境構成之 NT-style 作業系統平台。研究涵蓋 ExOS 核心、NT Executive、Process/Thread/Job、Virtual Memory、I/O Manager、Object Manager、ALPC、Security、ExFS filesystem driver、EFS per-account identity 與 per-file key distribution、ExES payload encryption、ExMD3 credential foundation、XDL module ABI、XSH 應用環境、ExDesk 桌面與 XSH IDE，以及 ExOS CMD Mode 與 2D Game SDK。研究方法採系統架構逆向分析、原始碼與文件對照、測試報告驗證、執行畫面觀察及線上 Demo 交叉驗證。研究結果顯示，ExOS 已形成由核心狀態、程序生命週期、檔案系統、身份安全、模組載入、桌面殼層與應用程式所組成的多層 runtime；其中 R138 新增之 kernel/runtime-backed XSH debugger，使 XSH IDE 能透過 ExOS.Debug 進行中斷點、繼續執行與 source-line step，顯示其已由單純模擬介面逐步轉向具有自身執行語意與開發工具鏈之平台。研究同時發現，ExFS/EFS/ExES/ExMD3 的責任分層、XDL 的 ABI 化、USER32 native menu/context-menu 架構，以及 Game2D 的 host-owned graphics/resource model，是本平台最具技術辨識度之設計。另一方面，瀏覽器安全模型與 PHP/HTTP backend 仍構成實體資源與信任邊界，因此本文主張以「platform boundary」而非「原生 kernel 等價」理解 ExOS。

 

 

 

 

四、Keywords

ExOS; browser-hosted operating system; NT-style runtime; ExDesk; ExFS; EFS; ExES; ExMD3; XDL; XSH; XSH IDE; virtual filesystem; process model; security model; 2D game SDK; WebAssembly/JavaScript runtime architecture; CMD Mode; command shell compatibility

五、英文摘要（Abstract）

This study investigates ExOS R138 as a browser-hosted NT-style operating environment implemented across a Chromium/V8-oriented JavaScript runtime and a PHP-backed storage boundary. The study focuses on the architecture and integration of the ExOS core, NT Executive semantics, process/thread/job management, virtual memory, I/O, object management, ALPC, security, ExFS filesystem-driver boundaries, per-account EFS identities, per-file key distribution, ExES payload encryption, ExMD3 credential primitives, XDL module ABI, XSH application runtime, ExDesk desktop environment, XSH IDE, and the ExOS CMD Mode and 2D Game SDK. The methodology combines architectural inspection, source-to-document correlation, regression-test analysis, runtime observation, screenshot-based interface analysis, and cross-validation against the public ExOS demonstration. The results indicate that ExOS has evolved beyond a presentation-only browser mock-up into a working platform prototype with persistent internal state, process-oriented execution semantics, filesystem and security boundaries, reusable module interfaces, desktop services, and application tooling. A particularly significant result in R138 is the introduction of an executive-owned, kernel/runtime-backed XSH debugger, through which the XSH IDE can launch debug profiles, synchronize breakpoints, continue execution, and perform source-line stepping. The study also identifies the separation among ExFS, EFS, ExES, and ExMD3, the XDL module contract, native USER32 menu/context-menu ownership, and host-owned Game2D graphics resources as major architectural strengths. Nevertheless, ExOS must be interpreted within browser and backend platform boundaries: it does not claim access to host Ring 0, physical interrupts, DMA, Hyper-V, VBS, or a real hardware scheduler. The contribution of ExOS is therefore best understood as an executable operating-environment architecture that models and implements OS-level semantics within an explicitly declared host capability boundary.

六、背景

傳統作業系統以硬體特權層、核心態記憶體管理、程序與執行緒排程、I/O 裝置與檔案系統為基礎；應用程式則透過系統呼叫、動態函式庫與桌面殼層使用這些資源。瀏覽器環境原本將網頁程式限制於 sandbox 中，無法直接取得宿主作業系統的核心權限。因此，在瀏覽器中重建 OS-like environment，真正的挑戰不是畫出桌面，而是如何在瀏覽器提供的能力邊界內，建立可驗證且一致的 process、thread、file、security、module、window 與 application 語意。

ExOS R138 的架構選擇是把瀏覽器視為 Host Layer，再由 ExOS Core 建立高階 OS semantics。瀏覽器所真正擁有的 DOM、Canvas、WebCrypto、Web Worker、WebGL/WebGPU 等能力不直接向 XSH 應用開放，而透過 host dispatch、capability broker、XDL、USER32/SHELL32 等邊界提供受控服務。這種設計使 ExOS 得以在沒有宣稱真實 Ring 0 能力的前提下，建立一個具有 OS-like internal state 的執行環境。

R138 的研究版本沿襲多個前置架構決策，包括 V8-only client policy、現代 ExFS 路徑、XSH bundle 分離、ExDesk user-data namespace、NT Executive 對照模型與 native USER32 menu architecture；因此本研究並非只評估單一版本的 UI，而是分析持續 hotfix 與 architecture contracts 所形成的累積系統。

七、研究動機

第一，瀏覽器內的 OS-like project 容易停留在視覺模擬層，缺乏可觀測的內部 OS 狀態。本研究希望確認 ExOS 是否真正建立了程序、執行緒、I/O、filesystem 與 security 的一致狀態模型。

第二，檔案加密、憑證、身份與 filesystem 若混合實作，往往造成責任不清。ExOS 將 ExMD3、ExES、EFS 與 ExFS 分層，因此值得以研究方法驗證此分層是否能支持清楚的 trust boundary 與 key-management semantics。

第三，XSH 不只是 command shell；它同時承擔系統工具、文件編輯器、Chat、記帳與遊戲等應用。因此需要確認 XSH 是否具備類似 application ABI 的穩定層，並觀察 XDL 是否形成可重用的 module contract。

第四，R138 的 XSH IDE debugger 使 developer tooling 直接進入 ExOS Executive，是平台成熟度的重要指標。研究需釐清這項功能究竟是 IDE UI 假象，還是核心持有 breakpoint/step/continue state 的真正 runtime path。

八、研究目的

• 建立 ExOS R138 的完整分層模型，描述 Browser Host、ExOS Core、NT-style API、XDL、XSH、ExDesk、ExFS 與 Application/Game SDK 的責任關係。

• 分析 ExFS、EFS、ExES、ExMD3 四者之間的安全與儲存分工，並說明為何 ACL、EFS recipient、FEK 與 payload encryption 不應視為同一機制。

• 評估 NT Core/NT API 是否形成真實可查詢的內部狀態，而非單純以固定資料模擬 API 回傳。

• 分析 XDL 與 XSH 是否可構成穩定 application ABI，並以 XSH IDE、HTML/CSV/TXT Editor、Finance、Chat 與 Game2D 作為應用層案例。

• 檢驗 R138 debugger、USER32 native menu、ExFS driver gate、ExCrypt native companion 等功能對平台成熟度的影響。

• 建立平台限制與研究結果的界線，避免將 browser-hosted semantics 誤認為宿主硬體核心能力。

九、研究方法

9.1 系統架構分析

依據 R138 套件中的核心程式、架構文件、版本歷史與測試報告，建立 subsystem map，並將每個 subsystem 置於下列觀察維度：狀態持有位置、呼叫邊界、資料結構、錯誤語意、權限條件、持久化路徑與回歸測試。

Browser/V8 Host
    │
    ├── ExOS Core / Executive
    │     ├── Process / Thread / Job
    │     ├── VMM
    │     ├── I/O / Object / ALPC
    │     └── Security / Trace / Boot
    │
    ├── XDL Module ABI
    │
    ├── XSH Runtime
    │     ├── SystemApps
    │     └── Programs
    │
    ├── ExDesk
    │     ├── Desktop / Taskbar / Explorer
    │     └── User Data Namespace
    │
    └── Game2D Host Runtime

ExFS path:
XSH/Shell/API → I/O Manager → exfs.sys → ExesFlt.sys
→ ExFSVdo.sys → PhpExfsBridge.sys → exos.php → /_exfs/

9.2 原始碼與文件交叉驗證

以核心程式檔與文件的 interface name、object name、status code、路徑、build information 及測試檔名進行對照。例如 EXOS_EXFS_SYS_V1 與 exos_exfs_sys.js 的 DriverEntry/MountVolume/DispatchRequest；EXOS_XSH_DEBUGGER_V1 與 R138 debugger test；以及 Game2D v14 README 與 SDK 內容。

9.3 測試報告分析

研究特別採用 package 中之 R138、R137、R102、R101、R100、R84 等驗證紀錄，區分「程式碼檢查通過」、「V8 編譯通過」、「回歸測試通過」、「實際 runtime 驗證」與「平台能力聲明」。此區分可避免將 static scan 或 mock test 過度推論為真正的 kernel capability。

9.4 Runtime與畫面觀察

使用者提供之運行畫面顯示命令提示字元、工作管理員、資源回收筒及檔案總管同時運行；工作管理員顯示 PID、CPU、記憶體、優先順序、Affinity、執行緒、Session 與命令列等欄位；Explorer 顯示 ExFS(C:)、Desktop、Documents、Downloads 與操作工具列。此畫面用於驗證 UI、process model 與 filesystem namespace 是否在同一 runtime 中匯合。

9.5 Public Demo 交叉驗證

以使用者提供的 ExOS Demo 入口 https://jplop.lionfree.net/exos/ 作為外部 runtime 觀察點，檢查其是否呈現 Session、Window Station、SYSTEM/administrator、LogonUI、Secure Desktop 與 XSH 暫停等概念。此部分屬系統展示證據，不替代原始碼審查。

9.7 CMD Mode 命令語意驗證

CMD Mode 的研究採取「parser → standard handles → ExFS I/O → command execution → result/exit code」之端到端驗證。原始碼顯示命令提示字元由 C:\ExOS\SystemApps\cmd.xsh 作為獨立 XSH process 執行，而 exos.js 僅保留通用 ExFS path helper 與 shell launch adapter。研究進一步檢查標準輸入、標準輸出、標準錯誤、pipe、檔案重導向、環境變數、命令歷史、completion、batch/XBA 相容語法，以及 SUBST 與 CMD Mode device mapping 是否真正經由 ExOS API 發生。

CMD Mode architecture
cmd.xsh
  │
  ├── STDIN / STDOUT / STDERR handles
  ├── command parser
  ├── history / completion / line editing
  ├── environment and current directory
  ├── redirection: > >> < 2> 2>> 2>&1 1>&2
  ├── anonymous pipe: command | command
  └── batch/XBA chain execution
          │
          ▼
     kernel32 / ExOS API
          │
          ├── GetCurrentDirectory / Environment
          ├── ReadConsole / WriteConsole
          ├── ReadFile / WriteFile
          ├── CreateProcess
          ├── DefineCmdModeDevice / QueryCmdModeDevice
          └── ExFS path and file operations
          │
          ▼
        ExFS (C:)

代表性命令集合包括 DIR、CD、COPY、XCOPY、DEL、RD、SET、FIND、FINDSTR、FC、WHERE、PUSHD、POPD、CHCP、DOSKEY、CLIP、START、ATTRIB、CHKDSK、CHOICE、ECHO、MD、MKLINK、MORE、SORT、ROBOCOPY、VERIFY、MOVE、PATH、PAUSE、PROMPT、REN、SUBST、TIME、TITLE、TREE、TYPE、VER、VOL、XBA，以及 ExOS 專用的 CALC、EXPLORER、NOTEPAD、CSVEDIT、MSPAINT、DEVMGMT、WINMINE、TASKMGR、REGEDIT、DISKMGMT、EXCONFIG、WHOAMI、MEM、PEB、PE、CONSOLE、TASKLIST、VDO 與 IRP。

9.6 研究限制控制

研究中將 capability 分成 Implemented、Modeled by platform boundary、Unavailable by platform 三類。尤其 physical CPU scheduler、Ring 0、DMA、host interrupt controller、Hyper-V、VBS、Secure Kernel 等不被瀏覽器直接提供的能力，不因 API 名稱存在而判定為實際硬體實作。

十、系統架構與元件分析

10.1 ExOS Core 與 NT Executive

ExOS Core 是整體平台的 authoritative runtime。R38 文件描述 EXOS_NT_EXECUTIVE_V1，並將 Object Manager、Dispatcher、I/O Manager、Cache Manager、Kernel Trace、Boot Phase 與 HAL 組成一致的 Executive 查詢面。Process 與 Thread lifecycle 並非只存在於 XSH sandbox：host Executive 會建立 Thread Object、維持 PID/TID、state、priority、wait reason、start/exit time 等欄位，並在 process termination 時同步完成 cleanup。

元件	主要責任	研究判定
Process/Job	PID/PPID、PEB、handle、membership、resource limit	核心狀態由 ExOS 持有，屬 implemented semantics
Thread	TID、state、priority、wait reason、worker-backed flag	Thread object/state 為 implemented；physical CPU scheduling 由 host 控制
VMM	4 KiB page、VAS/VAD、reserve/commit/protect、page fault/accounting	ExOS VMM semantics 為 implemented；宿主 heap 不是假稱的 Ring-0 pool
I/O Manager	IRP、driver/device registry、PnP、power state、IOCP	形成可觀測的 driver-shaped I/O subsystem
Object Manager	unified namespace、typed object、owner-PID handles	建立 runtime object identity 與 capability checks
ALPC	port、queue、waiter、message id、disconnect semantics	提供 process-to-process runtime IPC semantics
Kernel Trace	bounded events、sequence、timestamp、provider、payload	可作為 runtime diagnostic evidence

10.2 ExFS：檔案系統驅動邊界

ExFS 的特色是「driver-shaped boundary」。瀏覽器端 carrier 為 exos_exfs_sys.js，但 NT identity 為 exfs.sys；其 volume device 與 VDO 為 \Device\ExFSVolume0 / \Device\ExFSVdo0，CMD symbolic link 為 \??\C:。R84 明確規定正常 I/O 路徑必須經 I/O Manager → exfs.sys → ExesFlt.sys → ExFSVdo.sys → PhpExfsBridge.sys → exos.php → /_exfs/。同時，server-side gate 可拒絕未經 driver dispatch 標記的 ExFS volume I/O。這種設計的研究價值在於「禁止 architecture shortcut」，而不是宣稱 HTTP header 本身構成 Ring-0 security boundary。

10.3 EFS：每帳號身份與每檔案 FEK 分配

R47 的 EFS 模型將 authorization、account identity、file FEK distribution 分開。每個啟用帳號擁有獨立 RSA-OAEP/SHA-256 2048-bit EFS identity；每個檔案則取得新的 512-bit FEK，檔案內容以 FEK 加密，而 FEK 本身透過 DDF/DRF 等 recipient-specific wrapper 保存。此架構使「能讀檔案」與「擁有管理員權限」不再是同一判斷。R48 進一步納入 DRA/DRF 與 transaction recovery 測試。

10.4 ExES 與 ExMD3

ExES 負責 encrypted payload 的 cryptographic layer；ExMD3 則作為 credential/KDF foundation。兩者與 EFS、ExFS 形成不同責任面：ExMD3 處理 credential-derived key；EFS 決定哪些 identity 可以取得檔案 FEK；ExES 保護內容；ExFS 儲存 metadata 與加密內容。此分層降低 subsystem coupling，並使 password change、file encryption 與 recipient sharing 可以分開演進。

10.5 ExCrypt：Native companion

ExCrypt v3.8.0-r48-nt-efs-transaction-recovery 包含 ExCrypt.exe、ExCryptMount.exe 與 ExCryptFTP.exe，並以 WinFsp、native C crypto 與 ExFS/MFT/SAM6 等元件支援 Windows x64 build。測試報告記錄 core selftest、User RSA DDF decrypt、Public multi-DDF decrypt、DRA recovery、wrong-password rejection、mirror rollback、primary roll-forward 與 release build 等通過結果。此 native companion 使 ExOS 的檔案與加密模型具備跨 browser/native 工具鏈的延伸可能。

10.6 XDL：Module ABI

XDL 是 ExOS 的可重用 module contract。典型模組包括 kernel32.xdl、ntdll.xdl、user32.xdl、shell32.xdl、game2d.xdl、exes.xdl、ppc.xdl、webview2.xdl、ws2_32.xdl 等。XSH 透過 ExOS.LoadLibrary(...) 取得這些能力，並由 XDL registry 與 host export table 管理。這種設計將 app code 與 host service 解耦，使相同的 USER32、COMDLG32、Game2D 等服務可以被多個 XSH application 重用。

10.7 XSH：從 Shell 到 Application Runtime

XSH 的重要性在於其涵蓋範圍已超越命令解析器。系統 bundle 與 programs bundle 分離後，XSH 可承載 CMD、Control、Explorer、Task Manager、Registry/Device utilities，也可承載 Text++、CSV、HTML editor、Finance、Chat、Paint、game 與其他應用。R137 測試顯示 55/55 packaged current XSH 可經 V8 AsyncFunction 編譯，65/65 non-legacy XSH source 可編譯；R138 又加入 55 個 debug-instrumented XSH template 編譯驗證。

10.8 XSH IDE：Developer Platform

R100 先將高頻設計器 pointer interaction 移至 USER32 DESIGNSURFACE，以避免每個 pointermove 都經 XSH RPC 往返；R101 將 IDE menu 改為真正的 USER32 HMENU；R138 再將 debugger 狀態提升至 EXOS_XSH_DEBUGGER_V1。F5 以 debug profile 啟動 .xsh；F9 同步 breakpoint line；F5 在 paused 狀態繼續；F8 進行 source-line step。editor 透過 USER32 CODEEDIT markedLines 顯示停止行。此架構顯示 IDE 不再只是 app-private UI，而是開始使用 ExOS 的 process/debug semantics。

10.9 ExDesk 與 Desktop Environment

ExDesk 提供 user-facing desktop OS environment。實際運行畫面可見 Desktop、Taskbar、Start、Command Prompt、Task Manager、Recycle Bin、File Explorer 等元件並行存在。ExDesk namespace 同時定義 C:\ExDesk、C:\ExDesk\System32、C:\ExDesk\SystemApps、C:\Apps 與 user profile 等路徑，使系統應用、使用者資料與 system binaries 有明確位置。

10.10 USER32 native menu 與 Shell integration

R101/R102 顯示平台已逐步排除由 BUTTON 或 private DOM dropdown 模擬的 menu。USER32 現在擁有 HMENU、SetMenu、DrawMenuBar、TrackPopupMenu、WM_COMMAND routing；Shell32 則負責 semantic verbs 與 context-menu model。CSV 與 HTML editor、Text++、XSH IDE 都可共用此 infrastructure。這種設計提高 UI consistency，也證明 UI controls 並不是各應用各自重造。

10.11 HTML/CSV/TXT/記帳/Chat 應用

應用	平台價值	觀察
TXT Editor / Text++	基礎 document workflow	驗證 window、document、save、menu、CodeEdit 等基礎能力
CSV Editor	structured document integration	驗證 grid、menu、search、formula/data/view 等跨 API workflow
HTML Editor	rich document / source / preview	同時運用 USER32、RichEdit、Shell 與 document broker
Finance / 記帳	productivity application	將檔案、視窗與使用者資料模型帶入 end-user workflow
Chat	identity + UI + directory integration	可作為 security、account、directory、UI 與 message flow 的整合案例

10.12 ExOS 2D Game SDK

Game2D v14 將 browser host 能力與 sandbox XSH 分隔：Host 持有 DOM、Canvas、AudioContext、WebGL/WebGPU 與 decoded assets；XSH 僅取得 process-owned handles 與 serializable state/commands。核心圖為 Game → Scene → GameObject2D/Node2D → Components。SDK 同時涵蓋 Sprite、Animator、Physics、Hitbox、AudioSource、EventBus、Tween、Scheduler、RenderPass、Material、Shader、Tilemap、Projectile、Combat、Dialogue、Localization、Replay、RenderGraph、GPU instancing 與 WebGL/WebGPU backend。資產路徑遵守 ExFS → XSH permission/integrity → read → decode → cache → Game2D handle。

10.13 ExOS CMD Mode：命令相容性與 I/O 語意層

ExOS CMD Mode 是本研究新增的重要系統層。其核心設計不是把所有命令解析寫在核心檔案中，而是採取 XSH-first 架構：命令提示字元是一個真正的 SystemApps/cmd.xsh process，由 xshhost.exe 承載；核心 exos.js 不再負責主要 command parser、history、completion 與 console UI。此切分使 CMD Mode 成為 XSH application runtime 的第一級使用者介面，同時保留 kernel32 / ExOS API 對檔案、程序、環境及虛擬磁碟的權威性。

CMD Mode 能力	ExOS 實作對應	研究意義
命令提示與 line editing	cmd.xsh；↑/↓ history、TAB/Shift+TAB completion、F3/F8、Ctrl+C	證明 console UX 屬於 XSH application，而非假 UI
標準串流	GetStdHandle、ReadConsole、WriteConsole、ReadFile、WriteFile	建立 process-level I/O 語意
重導向與 pipe	>、>>、<、2>、2>>、2>&1、1>&2 及 anonymous pipe	把 shell command composition 連接到 ExFS/I/O subsystem
Filesystem commands	DIR、CD、COPY、MOVE、DEL、RD、REN、MD、TYPE、TREE、ATTRIB 等	驗證 CMD 語意是否真正落到 ExFS
環境與流程控制	SET、SETLOCAL、ENDLOCAL、PATH、START、EXIT、error level	形成可組合的 user-mode shell process model
CMD Mode virtual drives	SUBST → DefineCmdModeDevice / QueryCmdModeDevice；ExFS C: 為主要 volume	證明 drive-letter semantics 屬於 ExOS shell/filesystem contract

在研究定位上，CMD Mode 不應被視為另一個獨立 kernel，而應視為「ExOS 的 command compatibility surface」。它向使用者提供熟悉的 DOS/Windows command-line 操作模型，但命令背後的資源仍由 ExOS process、handle、ExFS、XDL 與 XSH runtime 管理。因此 CMD Mode 是連接「傳統命令列心智模型」與「現代 browser-hosted OS architecture」的重要相容層。

十一、研究結果

11.1 架構結果

層級	主要產物	研究結果
Host	V8/Chromium + Web APIs	形成明確平台能力邊界
Core	ExOS / NT Executive	持有 process、thread、object、I/O、trace 等狀態
Filesystem	ExFS / VDO / filter / bridge	以 driver-shaped path 統一 volume I/O
Security	SAM / Token / ACL / EFS / ExES / ExMD3	建立 credential、authorization、FEK 與 payload 的分層
Module	XDL	形成可重用 host export / library contract
Shell/App	XSH / XSH IDE	形成 user-mode application runtime 與 developer tooling
Desktop	ExDesk / USER32 / SHELL32	形成多視窗 desktop environment
Game	2D Game SDK	提供隔離式 graphics/audio/game runtime

11.2 R138 Debugger 結果

R138 的核心成果是 EXOS_XSH_DEBUGGER_V1。其 executive 持有 breakpoint authorization、line sets、break state、event sequence、continue、step 與 terminate wakeup；XSH 只透過 ExOS.Debug syscall/RPC wrapper 使用 Break、SetBreakpoints、QueryProcess、Continue。這表示 breakpoint 不再只是 editor state，而是 process runtime state。R138 test report 同時記錄 core JavaScript syntax checks、XSH bundle checks、55 active template 與 55 debug-instrumented template 的 V8 編譯，以及 integrity manifest validation。

11.3 ExCrypt 結果

ExCrypt 測試報告記錄 native core selftest、R48 SAM6 fixture、user DDF decrypt、public multi-DDF decrypt、non-recipient rejection、DRA recovery、chunked file/ADS/reparse/MFT regressions、wrong-password rejection，以及 primary roll-forward / mirror rollback 等 transaction recovery 測試均通過。研究上可解讀為：ExOS 的加密/文件格式不只是概念模型，而已經開始具有 native validation toolchain。

11.4 Runtime/UI 結果

使用者提供之運行畫面顯示多個 system/application windows 同時存在於單一 desktop：命令提示字元、工作管理員、資源回收桶及檔案總管。工作管理員顯示 PID 0 System Idle Process 與 PID 4 System 等 NT-style entries，並提供 CPU、memory、priority、affinity、thread、session、command line 等欄位；Explorer 則掛載 ExFS(C:) 並提供文件、CSV、HTML、上傳與檔案操作。此結果支持「ExDesk、NT-style process model 與 ExFS 在同一 runtime integration」的判斷。

11.5 Public Demo 結果

線上 Demo 進一步顯示 Session、WinSta0\Winlogon、NT AUTHORITY\SYSTEM、LogonUI、Secure Desktop、XSH 暫停等概念。此結果與 package 中的 session/logon/security architecture 相互吻合，形成 source、test、runtime UI 與 public demo 的多證據鏈。

11.6 CMD Mode 結果

研究結果確認 CMD Mode 已具備獨立 process 形式、標準 I/O handle、命令解析、line editing、環境變數、current directory、pipe、stream redirection、batch/XBA chain、ExFS filesystem commands 與 CMD Mode device alias 等能力。更重要的是，R138 架構明確將主要 CMD parser 與 console UI 從 exos.js 移至 cmd.xsh，形成 XSH-first shell model；此設計降低核心與 shell presentation 的耦合，也使 CMD Mode 與 Explorer、XSH IDE、其他 XSH application 共用同一批 kernel32/ExOS service surface。

典型重導向／pipe 驗證情境
DIR > listing.txt
SORT < names.txt > sorted.txt
DIR /B | FIND ".txt"
TYPE missing.txt 2> error.log

對應語意：
command parser
    → redirection parser
    → ExFS file handle / anonymous pipe handle
    → process standard handle replacement
    → command execution
    → handle restore / completion

此模型表示 CMD Mode 的輸入輸出並非單純字串模擬，而是以 handle-oriented abstraction 串接至 ExOS I/O semantics。

十二、研究發現

主要發現一：ExOS 的真正創新點在於「語意整合」，而非單一 API 數量。 Process、filesystem、security、desktop、XSH 與 Game2D 都被放在同一 runtime contract 下，因此平台價值來自 cross-layer consistency。

主要發現二：ExFS/EFS/ExES/ExMD3 的 separation 是安全架構的關鍵。 File storage、recipient authorization、content encryption 與 credential derivation 被分離後，可以各自測試與演進，也避免將 administrator privilege 誤認為 cryptographic recovery right。

主要發現三：XDL 與 XSH 已開始形成 application platform。 多個 system/app program 可以依賴共同 module services，降低 private DOM/JS implementation 的重複程度。

主要發現四：R138 debugger 是平台成熟度的分水嶺。 從 IDE-only breakpoint 視覺狀態轉移到 Executive-owned runtime state，使 ExOS 開始具備自己的 developer platform，而非只提供終端與桌面工具。

主要發現五：browser boundary 既是限制，也是架構強項。 ExOS 不宣稱 host Ring 0/DMA/physical interrupts/Hyper-V/VBS；反而透過明確的 unavailable reporting，使研究結果較不容易陷入「名稱等於能力」的錯誤。

12.1 研究成熟度綜合評估

面向	評估	說明
架構一致性	高	Subsystem 之間已形成明確責任與資料流
Runtime 可觀測性	高	Process/Thread/I/O/Object/Trace 等狀態可被查詢
安全模型	高	Credential、EFS、payload encryption、ACL 分層清楚；仍須持續做威脅模型與實際攻擊驗證
Desktop 整合	高	多窗口、Taskbar、Explorer、Task Manager、Recycle Bin 可同時運作
Developer tooling	中高	R138 已有 runtime-backed debugger，但 IDE/diagnostic ecosystem 尚可擴張
Native interoperability	中高	ExCrypt 等 companion 已存在，但仍是 ExOS 自有格式與生態系
瀏覽器普適性	中	目前以 V8/Chromium 為明確目標，並不追求舊式 browser compatibility
生產級成熟度	未定	目前更適合稱為 advanced platform prototype，仍需長期可靠性、安全性與相容性證據

十三、未來可延伸研究

• 建立正式 ExOS ABI/Protocol Specification：為 XDL、XSH syscall/RPC、ExFS driver dispatch、debugger、window/message routing 建立 versioned contract、error compatibility 與 backward/forward compatibility matrix。

• 建立形式化 threat model：以 STRIDE、capability-security、confused-deputy、replay、message spoofing、session fixation、cross-origin attack 等角度驗證 XSH sandbox、ALPC、ExFS backend、ExCrypt 與 EFS sharing。

• 建立 deterministic execution/replay：將 Process、Thread、XSH event queue、Game2D frame、scheduler state 與 debugger event sequence 做 deterministic record/replay，以利 regression 與研究 reproducibility。

• 研究 WebAssembly backend：比較 JavaScript/V8、WebAssembly 與 Web Worker 在 ExOS Core、crypto primitives、Game2D physics 與 XSH execution 的效能與隔離成本。

• 研究 PWA/Service Worker/OPFS storage adapter：將目前 PHP-backed ExFS 與 browser-local storage model 做可插拔 adapter，以評估 offline-first 與 server-less ExOS deployment。

• 研究 multi-user / multi-session：擴充 Session、Window Station、Secure Desktop、token 與 service isolation，建立更完整的 interactive session model。

• 研究 native storage interoperability：將 ExCrypt/ExFS format 發展成有公開 specification、fixture、conformance suite 與 version negotiation 的 file format。

• 研究 XSH package manager：為 XDL/XSH app 建立 signing、dependency resolution、capability manifest、version pinning、sandbox permission 與 update rollback。

• 研究 Game2D 對 ExOS scheduling/I/O 的壓力模型：分析 asset loading、render graph、GPU instance buffer、physics、audio 與 XSH message traffic 的 backpressure 與 frame-time stability。

• 建立學術可重現實驗平台：固定瀏覽器版本、V8 build、PHP backend、fixture volume、seed、test vectors、screenshot baseline 與 performance benchmark，使 Rxxx hotfix 線具有實驗科學上的可重現性。

十四、參考文獻

[1] ExOS Project. ExOS R138 package, including exos.js, exos_xsh_system.js, exos_xsh_programs.js, exos_exfs_sys.js, exos_2dgame_sdk.js, ex_md3.js, exes.js and related test tools. 2026.

[2] ExOS Project. NT Executive R38: ExOS 核心機制對照與實作狀態. Related Documents/NT_EXECUTIVE_R38.md. 2026.

[3] ExOS Project. EXFS_SYS_R84: exfs.sys filesystem driver. Core Architecture/EXFS_SYS_R84.md. 2026.

[4] ExOS Project. NT_EFS_DDF_R47: NT-style EFS DDF Architecture. Related Documents/NT_EFS_DDF_R47.md. 2026.

[5] ExOS Project. NT_EFS_TRANSACTION_RECOVERY_R48 and NT_EFS_SESSION_RESUME_R49. 2026.

[6] ExOS Project. HOTFIX76 R138: XSH IDE core breakpoints. Testing Tool/HOTFIX76_R138_REPORT.txt. 2026.

[7] ExOS Project. HOTFIX76 R100: XSH IDE USER32 DESIGNSURFACE Stability. Version History/HOTFIX76_R100_XSH_IDE_DESIGNSURFACE_STABILITY_REPORT.md. 2026.

[8] ExOS Project. HOTFIX76 R101: USER32 Native Menu Bar / HMENU Completion. Version History/HOTFIX76_R101_USER32_NATIVE_MENUBAR_REPORT.md. 2026.

[9] ExOS Project. HOTFIX76 R102: USER32 Shell Context Menu + CSV/HTML Native Menu Report. Version History/HOTFIX76_R102_SHELL_NATIVE_CONTEXT_EDITOR_MENUS_REPORT.md. 2026.

[10] ExOS Project. ExOS Native Environment Namespace R88. Core Architecture/EXOS_NATIVE_ENVIRONMENT_R88.md. 2026.

[11] ExOS Project. ExOS 2D Game SDK v14 README and Game2D v13 capability coverage reports. Version History/. 2026.

[12] Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts. 10th ed., Wiley, 2018.

[13] Tanenbaum, A. S., & Bos, H. Modern Operating Systems. 4th ed., Pearson, 2014.

[14] Russinovich, M. E., Solomon, D. A., & Ionescu, A. Windows Internals, Part 1: System Architecture, Processes, Threads, Memory Management, and More. 7th ed., Microsoft Press, 2017.

[15] RFC 8017. PKCS #1: RSA Cryptography Specifications Version 2.2. Internet Engineering Task Force, 2016.

[16] NIST. SP 800-57 Part 1 Rev. 5: Recommendation for Key Management: Part 1 — General. National Institute of Standards and Technology, 2020.

[17] WHATWG. HTML Living Standard. Web Hypertext Application Technology Working Group.

[18] W3C. Web Cryptography API. World Wide Web Consortium.

[19] MDN Web Docs. Web Workers API; WebGL API; WebGPU API; Window Management and related web platform references.

十五、相關附件：完整步驟、教學與方法

附件 A：研究重現流程

以下流程用於研究者、開發者或審查者重現本研究觀察；因 ExOS R138 為持續演進之 development branch，實際畫面與 build string 可能隨 hotfix 變更。

步驟 1：取得 ExOS R138 壓縮套件，解壓並保留原始目錄層級。

步驟 2：先閱讀 exos/readme.txt、Core Architecture 文件、NT Executive、EFS、ExFS、Version History 與 Testing Tool 之 R138/R137/R102/R101/R100 報告。

步驟 3：建立 component inventory：exos core、ExFS、EFS/ExES/ExMD3、XDL、XSH system/program bundles、ExDesk、ExCrypt、Game2D。

步驟 4：檢查 exos.js、exos_exfs_sys.js、exos_ntoskrnl.js、exos_shell32.js、exos_advapi32.js、exos_comctl32.js、exos_2dgame_sdk.js 等核心 library 的入口與 export surface。

步驟 5：依照 ExFS driver chain 驗證 filesystem path：XSH/Shell/API → I/O Manager → exfs.sys → filter/VDO/bridge → PHP backend。

步驟 6：檢查 XDL catalog 與 LoadLibrary() 呼叫，確認 applications 透過 module contract 取得 USER32、SHELL32、Game2D 等服務。

步驟 7：檢查 R137/R138 XSH compile tests，區分 packaged current、non-legacy 與 debug-instrumented sources。

步驟 8：檢查 R138 debugger：debug profile → process creation → ExOS.Debug → Break/SetBreakpoints/Continue/step → editor markedLines。

步驟 9：檢查 R100/R101/R102 UI architecture：DESIGNSURFACE、HMENU、WM_COMMAND、Shell context menu broker。

步驟 10：運行 ExOS Demo，觀察 boot/logon/session/secure-desktop 行為，並記錄瀏覽器版本、時間、螢幕解析度與登入流程。

步驟 11：在 ExDesk 中依序開啟 Command Prompt、Task Manager、Recycle Bin、File Explorer，檢查 process list、ExFS(C:) namespace、taskbar 與 window state。

步驟 12：以 TXT/CSV/HTML editor 作為 application-level integration tests；再測 Finance、Chat 與 Game2D 以驗證不同 subsystem 的組合。

步驟 13：最後對照測試報告與 runtime 結果，將結論分成 implemented、modeled by platform boundary、unavailable by platform 三類。

附件 B：ExOS 分層閱讀法

第一層：Host

  看瀏覽器真正提供什麼；不要把 Web API 等同硬體核心能力。

第二層：Core / Executive
  看誰真正持有 Process / Thread / Object / I/O / VMM / Security state。

第三層：XDL
  看 capability 是如何被 export、load、version 與驗證。

第四層：XSH
  看 application 是否只做 DOM 操作，還是經過 host dispatcher 使用 OS service。

第五層：ExDesk
  看 desktop、taskbar、Explorer、user profile 與 system apps 是否共同使用同一 runtime。

第六層：Application / Game2D
  看 editor/chat/finance/game 是否能從底層 subsystem 拿到一致能力。

附件 C：EFS/加密研究方法

問題	應觀察項目	避免的誤判
身份從哪裡來？	SAM、SID、EFS account identity、credential key	不要把 username string 當成 cryptographic identity
內容怎麼加密？	per-file FEK、ExES payload encryption	不要把 FEK bits 數直接等同 security strength
誰可取得 FEK？	DDF/DRF、recipient SID、DRA	不要把 Administrator role 直接當 recovery key
密碼改變會怎樣？	credential key re-derivation、key wrapping update	不要假設所有檔案都要重新 encrypt
儲存怎麼走？	ExFS driver path、MFT、journal、bridge	不要把 backend HTTP endpoint 視為 ring-0 guarantee

附件 D：XSH IDE Debugger 驗證方法

• 建立一個最小 XSH 測試程式，讓其執行到兩個可預期的 source line。

• 在 IDE 設定第一個 breakpoint，使用 F5 以 debug profile 啟動。

• 使用 F9 將 breakpoint line set 傳入 ExOS.Debug，確認 executive state 有對應 sequence/event。

• 確認停下時 editor 的 markedLines 與實際 stopped source line 一致。

• 按 F8 執行單一 source-line step，再驗證 process state 與 event sequence 改變。

• 按 F5 continue，確認 breakpoint 可以再次觸發，且非 debug profile 的一般 .xsh 不會自動注入 debug instrumentation。

附件 E：ExFS 驅動路徑驗證方法

1. 檢查 exfs.sys DriverEntry 是否完成註冊。
2. 檢查 C: mount state 與 VDO state。
3. 送出 filesystem request。
4. 確認 request 經 I/O Manager → exfs.sys → ExesFlt.sys → ExFSVdo.sys。
5. 確認 PhpExfsBridge.sys / exos.php 是 backing transport，而不是 XSH bypass。
6. 將 driver not-ready、unmounted、missing action、invalid transport 等列為 negative tests。
7. 驗證 dispatch/completed/failed/bytesSubmitted counters。
8. 將「driver gate」與 authentication/session/CSRF/permission 分開評估。

附件 F：Desktop 運行畫面檢查表

檢查面	通過判準
Desktop shell	Start、Taskbar、desktop icons 能同時呈現
Window management	多個 application window 可同時存在並維持 activation/z-order semantics
Task Manager	可看到 PID/PPID 或相當 process state、CPU、memory、thread、session 等欄位
Explorer	可瀏覽 ExFS(C:)、user folders 與 shell namespace
Recycle Bin	可保留刪除 metadata 並支援 restore/permanent delete semantics
Application integration	TXT/CSV/HTML/Finance/Chat 可共用 USER32/SHELL32/document/storage infrastructure
System identity	Session、user、security context 等資訊與 core state 一致

附件 G：學術寫作與證據等級建議

研究報告在引用 ExOS 功能時，建議使用「source/document evidence → automated test evidence → runtime evidence → public demo evidence」四級證據鏈。凡只有 static scan 的結果，不應寫成「執行成功」；凡只有畫面，不應寫成「kernel implementation verified」。對於 browser-host capability，應以「modeled by platform boundary」描述；對明確不存在的 host feature，應以「unavailable by platform」描述。

附件 H：ExOS CMD Mode 完整重現教學與驗證步驟

以下步驟可作為研究者的重現性檢查表。研究重點不是只確認黑色命令視窗能出現，而是逐層確認「cmd.xsh process → standard handles → command parser → ExOS API → ExFS → result」整條鏈。

1. 啟動 ExOS 並確認 V8 browser host 成功載入 ExOS Core、XDL 與 XSH runtime。
2. 由桌面或 Start/Shell 開啟「命令提示字元」，確認其對應為 SystemApps/cmd.xsh，而不是直接由 exos.js 內嵌一個假 console。
3. 輸入 VER，確認輸出包含 ExOS 版本資訊；輸入 WHOAMI，確認 security/session context 能被查詢。
4. 輸入 CD、DIR、TYPE，確認 current directory 與 ExFS namespace 正常工作。
5. 建立測試檔案後執行 COPY、MOVE、REN 與 DEL，並用 Explorer 交叉觀察檔案狀態。
6. 輸入 DIR > listing.txt，再執行 TYPE listing.txt，驗證 STDOUT→ExFS file handle 的輸出重導向。
7. 建立排序測試檔，執行 SORT < names.txt > sorted.txt，驗證 STDIN 與 STDOUT 同時重導向。
8. 執行 DIR /B | FIND ".txt"，驗證 anonymous pipe 將前一命令的 STDOUT 交給後一命令的 STDIN。
9. 執行 TYPE missing.txt 2> error.log，確認 STDERR 可獨立重導向。
10. 執行 SET TEST=123、SET TEST、SETLOCAL 與 ENDLOCAL，確認環境變數 scope。
11. 測試 PUSHD／POPD 與 current directory stack。
12. 測試 SUBST，確認 DefineCmdModeDevice／QueryCmdModeDevice 產生虛擬 drive-letter mapping，而不暴露 host physical disk。
13. 若研究目的包含 batch compatibility，使用 XBA 範例執行串接命令、&&、||、環境變數展開與 redirect；並記錄 exit code/error level。
14. 最後開啟工作管理員，交叉確認 cmd.xsh process 與其他 XSH/desktop application 同時存在，藉以驗證 CMD Mode 屬於整體 process model，而非獨立頁面元件。

學術驗證判準：只有在命令結果、ExFS 狀態、process state 與 source/test evidence 彼此一致時，才能將 CMD Mode 描述為「implemented command/runtime semantics」；單純看到黑色命令視窗本身不足以證明其具有真正的 process/I/O 整合。

十六、研究結論

綜合 R138 原始碼、架構文件、回歸測試、ExCrypt 測試、XSH IDE debugger、ExFS driver contract、Game2D SDK 與實際運行畫面，本研究認為 ExOS 已形成一套具有自身內部狀態、跨層 API、filesystem、安全模型、desktop 與 application tooling 的 browser-hosted operating environment。其最重要的技術貢獻，不是單純複製 Windows 外觀，而是在瀏覽器限制內建立 NT-style semantic architecture，並透過 XDL/XSH 使底層能力能夠被系統工具、編輯器、Chat、Finance 與 Game2D 等多種類型應用共用。

R138 的 XSH IDE debugger 與 CMD Mode 是成熟度上的兩個互補里程碑；前者驗證 developer tooling 可進入 Executive，後者驗證 user-mode command interface 可透過 handle/I/O/ExFS 語意落到同一 runtime。前者使 breakpoint、continue、step 與 stopped-source-line 由 IDE state 上升為 Executive-owned runtime state，後者則使 command parser、standard handles、pipe、redirection、environment 與 ExFS operations 由同一 user-mode process/runtime path 統一管理。ExFS/EFS/ExES/ExMD3 的責任分層則構成資料與安全面的核心設計。另一方面，ExOS 仍受 browser/PHP host boundary 限制，因此在學術分類上較適合描述為「advanced, executable platform prototype」，而非宣稱等同於原生 Windows/Linux kernel。

十七、版本與研究資料註記

本研究以提供的 exos_r138.zip 為主要技術資料來源；套件共有 1,163 個 archive entries、1,134 個檔案，解壓後檔案總大小約 17.86 MB。R138 測試報告記錄 active SYSTEM bundle 34 個、PROGRAMS bundle 21 個；55 個 packaged current XSH templates 與 55 個 debug-instrumented templates 均進行 V8 compilation validation。這些數值屬於本次研究樣本版本的觀測值，不應視為 ExOS 永久固定的產品規格。

研究觀察日期以本次分析所使用之 R138 套件與使用者提供的 Demo/運行畫面為準。Public Demo 之實際內容可能隨伺服器部署變更；因此 source package 與 test reports 應視為主要可重現資料來源。

本次修訂另納入 ExOS CMD Mode 專題分析。依 R138 套件之 cmd.xsh 與相關 architecture/readme 資料，CMD Mode 被界定為 ExOS 的 command compatibility surface，而非另一個 kernel；其命令執行、標準串流、重導向、pipe、環境變數、batch/XBA 與 SUBST/virtual drive 行為均置於既有 XSH、kernel32、ExOS 與 ExFS contract 之上。