來(lái)自:https://reactos.org/blogs/newsletter-102/

你好ReactOS的追隨者和愛(ài)好者！自從我們發(fā)布第101份時(shí)事通訊以來(lái)已經(jīng)有很長(zhǎng)一段時(shí)間了，到目前為止，還沒(méi)有發(fā)布進(jìn)一步的更新。雖然ReactOS Twitter帳戶確實(shí)不時(shí)提供公告，有關(guān)工作應(yīng)用程序的帖子等，但整個(gè)項(xiàng)目正在發(fā)生的事情并沒(méi)有被提及。我們將要討論的大部分內(nèi)容是發(fā)布和整體 ReactOS 開(kāi)發(fā)的當(dāng)前情況。

為什么發(fā)布新版本的 ReactOS 需要這么長(zhǎng)時(shí)間？你們死了嗎？

最新版本是ReactOS的0.4.14，發(fā)布于2021年12月16日。僅該版本就花了一年時(shí)間進(jìn)行設(shè)計(jì)。當(dāng)時(shí)，ReactOS 遵循 3 個(gè)月的節(jié)奏，每3個(gè)月發(fā)布一次新版本。但自2021年以來(lái)，ReactOS仍處于0.4.14。你們死了嗎？
答案當(dāng)然是否定的，我們處理發(fā)布的方式已經(jīng)改變。過(guò)去，ReactOS的發(fā)布是為了數(shù)量而不是質(zhì)量。3個(gè)月后的每個(gè)新版本都與上一個(gè)版本相似，除了少量添加的功能和錯(cuò)誤修復(fù)。但總的來(lái)說(shuō)，版本之間的凈差距并沒(méi)有那么大。一段時(shí)間以來(lái)，我們已經(jīng)制定了一條規(guī)則，即要使新版本達(dá)到“發(fā)布”狀態(tài)，它需要具有相當(dāng)?shù)偷幕貧w量（不超過(guò) 20），并且穩(wěn)定性不得受到引入新功能或在開(kāi)發(fā)過(guò)程中完成的代碼更改的嚴(yán)重影響。
換句話說(shuō)，ReactOS 項(xiàng)目現(xiàn)在專注于提供高質(zhì)量的版本，這排除了3個(gè)月的發(fā)布節(jié)奏。無(wú)論如何，以前的方法對(duì)于像我們這樣規(guī)模的開(kāi)發(fā)團(tuán)隊(duì)來(lái)說(shuō)是不可行的。
預(yù)計(jì)發(fā)布新版本需要更長(zhǎng)的時(shí)間，盡管這些版本現(xiàn)在將更加充實(shí)，并具有更多的改進(jìn)。如果您迫不及待地想要測(cè)試最新的更改和功能，您可以隨時(shí)嘗試夜間構(gòu)建（也稱為實(shí)驗(yàn)性構(gòu)建）。

發(fā)展現(xiàn)狀

在去年和 2023 年初，ReactOS開(kāi)發(fā)人員和貢獻(xiàn)者都在研究項(xiàng)目的許多部分，最關(guān)注的領(lǐng)域是內(nèi)核。其他與內(nèi)核無(wú)關(guān)的領(lǐng)域是應(yīng)用程序，特別是我們的畫(huà)圖和記事本程序，輸入法編輯器（IME）以及其他內(nèi)容，例如ReactOS測(cè)試基礎(chǔ)架構(gòu)。

ReactOS x64端口狀態(tài)

ReactOS的x64端口雖然仍處于起步階段，但在穩(wěn)定性方面已經(jīng)穩(wěn)步變得更好。當(dāng)時(shí)，ReactOS幾乎無(wú)法啟動(dòng)，即使啟動(dòng)，通常只需執(zhí)行簡(jiǎn)單的任務(wù)即可立即崩潰或BSoD。在Timo Kreuzer （tkreuzer）的幫助下，x64端口已經(jīng)達(dá)到了可以容忍的狀態(tài)，ReactOS現(xiàn)在可以毫無(wú)問(wèn)題地運(yùn)行。

盡管問(wèn)題仍然存在，并且兼容性不如x86版本，但更多的應(yīng)用程序甚至硬件驅(qū)動(dòng)程序已經(jīng)開(kāi)始工作。請(qǐng)注意，由于缺少 WoW64，x64 端口目前不會(huì)運(yùn)行任何 x86 應(yīng)用程序。

WHS 測(cè)試修復(fù)

WHS測(cè)試機(jī)器人（代表Windows Home Server的首字母縮略詞）是運(yùn)行Windows Server 2003的機(jī)器人，它執(zhí)行整個(gè)ReactOS測(cè)試套件基礎(chǔ)結(jié)構(gòu)，確保每個(gè)測(cè)試用例在Windows環(huán)境中通過(guò)測(cè)試結(jié)果。這有助于了解Windows在向它提供某些測(cè)試輸入時(shí)的行為方式。眾所周知，由于測(cè)試未通過(guò)甚至崩潰，WHS 測(cè)試用例基礎(chǔ)設(shè)施會(huì)失敗很多。在 2023 年 1 月的黑客節(jié)期間，Timo Kreuzer （tkreuzer）、Mark Jansen （learn_more） 和 Thomas Faber （ThFabba） 共同修復(fù)了一些測(cè)試用例。由于他們的努力，WHS現(xiàn)在可以通過(guò)所有測(cè)試。

畫(huà)圖和記事本改進(jìn)

多虧了Katayama Hirofumi MZ，油漆和記事本都得到了生活質(zhì)量的改善，雜項(xiàng)修復(fù)等等。值得注意的是，他在調(diào)整應(yīng)用程序窗口大小時(shí)修復(fù)了 Paint 上的一些閃爍問(wèn)題，并實(shí)現(xiàn)了“文本工具”功能。此外，他還改進(jìn)了記事本的性能，實(shí)現(xiàn)了“正在打印”對(duì)話框，并提供了一些雜項(xiàng)修復(fù)。

安全子系統(tǒng)改進(jìn)

George Bi?oc（GeoB99）通過(guò)新東西和錯(cuò)誤修復(fù)逐步改進(jìn)了內(nèi)核的安全子系統(tǒng)（Se），主要是顯著改進(jìn)了安全訪問(wèn)檢查和訪問(wèn)令牌。
訪問(wèn)檢查是內(nèi)核執(zhí)行的操作，用于驗(yàn)證請(qǐng)求者是否可以訪問(wèn)對(duì)象。如果請(qǐng)求者沒(méi)有訪問(wèn)對(duì)象的正確權(quán)限，或者對(duì)象本身阻止其他人執(zhí)行訪問(wèn)控制列表 （ACL） 強(qiáng)加的某些操作，則訪問(wèn)將被拒絕。SepAccessCheck中發(fā)生了一次黑客攻擊，無(wú)論安全描述符施加的安全限制如何，都可以向任何人授予訪問(wèn)權(quán)限。這可能會(huì)導(dǎo)致不良行為者篡改和玩弄物體。
多虧了他的工作，SepAccessCheck中的hack已被刪除，安全訪問(wèn)檢查現(xiàn)在可以運(yùn)行，內(nèi)核可以防止任何試圖以不當(dāng)訪問(wèn)權(quán)限訪問(wèn)對(duì)象的人進(jìn)行任何未經(jīng)授權(quán)的訪問(wèn)。他對(duì)安全子系統(tǒng)的未來(lái)計(jì)劃是對(duì)所有對(duì)象實(shí)施安全審核，并在需要時(shí)進(jìn)行其他改進(jìn)。

注冊(cè)表改進(jìn)

為了使ReactOS達(dá)到測(cè)試階段，它必須解決兩個(gè)主要的里程碑 - 穩(wěn)定性和損壞。通常，ReactOS 中的損壞可能以文件系統(tǒng)和注冊(cè)表?yè)p壞的形式表現(xiàn)出來(lái)。雖然可以通過(guò)選擇我們目前支持的更現(xiàn)代的文件系統(tǒng)（例如 BtrFS）來(lái)防止文件系統(tǒng)損壞，但注冊(cè)表?yè)p壞本身就是死刑，因?yàn)?ReactOS 目前沒(méi)有實(shí)施任何自我修復(fù)機(jī)制來(lái)從損壞的注冊(cè)表配置單元中恢復(fù)系統(tǒng)。因此，用戶被迫對(duì)系統(tǒng)進(jìn)行干凈的重新安裝。最壞的情況是，系統(tǒng)仍然可以啟動(dòng)，但由于用戶配置文件已損壞或丟失，因此卡在登錄提示對(duì)話框（也稱為“Ctrl + Alt + Del”對(duì)話框）上。后者通常發(fā)生在 ReactOS 在全新安裝后強(qiáng)制關(guān)閉之后。
George Bi?oc 目前正在通過(guò)實(shí)施必要的注冊(cè)表自我修復(fù)機(jī)制和 CmCheckRegistry 來(lái)改進(jìn)注冊(cè)表，CmCheckRegistry 是一項(xiàng)基本功能，可驗(yàn)證注冊(cè)表中是否存在注冊(cè)表的任何損壞部分，并采取適當(dāng)?shù)拇胧拇祟悡p壞部分恢復(fù)注冊(cè)表配置單元。雖然他的工作目前正在進(jìn)行中（#4571），但到目前為止，他已經(jīng)從測(cè)試人員那里收到了一些積極的結(jié)果。他的一小部分工作已被合并，這修復(fù)了近十年來(lái)無(wú)法工作的 ReactOS 注冊(cè)表刷新器！此修復(fù)程序還解決了由于強(qiáng)制關(guān)閉系統(tǒng)而導(dǎo)致用戶配置文件丟失的問(wèn)題，因此您不應(yīng)再期望像以前那樣經(jīng)常看到臭名昭著的“Ctrl+Alt+Del”對(duì)話框提示。
此外，他正在研究注冊(cè)表緩存實(shí)現(xiàn)（#5088），因?yàn)?ReactOS 沒(méi)有正確同步緩存的信息，從而導(dǎo)致結(jié)果不一致。
目前，大部分工作仍在堅(jiān)持，因?yàn)樗刮覀兊囊龑?dǎo)加載程序大小大于應(yīng)有的大小，從而阻止了 ReactOS的AMD64版本啟動(dòng)。

輸入法項(xiàng)目

輸入法編輯器（或 IME）是一個(gè)組件，它有助于通過(guò)使用字符序列鍵入輸入設(shè)備上最初不存在的字符。ReactOS中的IME在很大程度上是一個(gè)存根，但值得慶幸的是，Katayama Hirofumi MZ已經(jīng)對(duì)此進(jìn)行了廣泛的研究。這極大地有助于CJK支持，并允許為不同的區(qū)域設(shè)置安裝自定義 IME。片山寫(xiě)了一篇關(guān)于他的工作的文章，其中的日語(yǔ)部分是在ReactOS中使用MZ-IME 編寫(xiě)的，這是它的英文部分：
距離我上次報(bào)告已經(jīng)過(guò)去了七個(gè)月，我想解釋一下日本在 ReactOS 中輸入的現(xiàn)狀。我們已經(jīng)確認(rèn)日語(yǔ)ReactOS識(shí)別并實(shí)際可以使用MZ-IME日語(yǔ)輸入，這是一種自制的測(cè)試IME。
在 IMM32 實(shí)現(xiàn)幾乎完成之后，剩下的問(wèn)題是 USER32 端的實(shí)現(xiàn)，其中默認(rèn)過(guò)程以及默認(rèn) IME 窗口和 EDIT 控件的處理尚未編寫(xiě)。默認(rèn)過(guò)程需要處理多個(gè) IME 消息。默認(rèn) IME 窗口是不可見(jiàn)的窗口，在 IME 消息傳遞中是必不可少的;EDIT 控件是一個(gè)所謂的文本框，需要正確處理某些 IME 消息。實(shí)現(xiàn) IME 消息處理時(shí)，IME 組合字符串窗口和候選窗口正確顯示。

視頻： https://www.youtube.com/watch?v=Dv58IV_vUxY

請(qǐng)注意，命令提示符和豐富編輯控件的日語(yǔ)輸入尚不可用。仍然存在一些故障和不穩(wěn)定。請(qǐng)注意，ReactOS IMM目前是為較舊的系統(tǒng)開(kāi)發(fā)的，不支持較新的TSF兼容 IME。缺陷和問(wèn)題可以在 https://github.com/katahiromz/ImeStudy/issues 報(bào)告。

其他亮點(diǎn)

Dmitry Borisov（disean）修復(fù)了由于Windows Server 2003中的IDE驅(qū)動(dòng)程序堆棧關(guān)閉而導(dǎo)致的BSoD。
??? Win32后端內(nèi)核模式子系統(tǒng)組件（win32k.sys）正在穩(wěn)步改進(jìn)，許多人進(jìn)行了改進(jìn)和錯(cuò)誤修復(fù)，特別是Timo Kreuzer，James Tabor（jimtabor），Jerome Gardou（zefklop），Thamatip Chitpong（TAN-Gaming）和Katayama Hirofumi MZ。
??? 會(huì)話管理器子系統(tǒng) （SMSS） 的某些部分已由 Hermès Bélusca-Ma?to （#4821） 清理和改進(jìn)。這包括清理 SM 客戶端庫(kù) （SMLIB） 中的舊代碼和已棄用的代碼。此外，已經(jīng)實(shí)現(xiàn)了一個(gè)API，以允許ReactOS使用Win32以外的其他子系統(tǒng)。此外，客戶端/服務(wù)器運(yùn)行時(shí)子系統(tǒng) （CSRSS） 已針對(duì)此目的進(jìn)行了略微調(diào)整 （#4802）。

有關(guān)更多更新和最新消息，請(qǐng)查看ReactOS推特。

主分支之外

ReactOS一直不僅僅是一個(gè)操作系統(tǒng)。我們是一個(gè)專注于 Windows 生態(tài)系統(tǒng)的人員社區(qū) — 通過(guò)各種項(xiàng)目來(lái)研究和記錄 Windows 內(nèi)部，改進(jìn)應(yīng)用程序中的 Windows 支持，或以其他方式使更廣泛的 Windows 開(kāi)發(fā)人員社區(qū)的生活更輕松。事實(shí)上，大多數(shù)開(kāi)發(fā)人員第一次接觸 ReactOS 可能不是通過(guò)下載操作系統(tǒng)，而是在 Web 上查找未記錄的 API 并最終進(jìn)入我們的 Doxygen 生成的文檔時(shí)。

因此，過(guò)去兩年中的許多工作也發(fā)生在我們的主源樹(shù)之外，值得一看：

Joachim Henze 繼續(xù)將所有舊版本從0.4.7改進(jìn)到0.4.14，方法是移植回回歸和一些優(yōu)化的安全修復(fù)程序，您可以在 sourceforge 上找到所有這些版本的更新 iso。有關(guān)已應(yīng)用修復(fù)的完整列表，您可以查看 0.4.7、0.4.8、0.4.9、0.4.10、0.4.11、0.4.12、0.4.13、0.4.14。

Colin Finck 一直在嘗試使用Rust編程語(yǔ)言進(jìn)行Windows開(kāi)發(fā)，并且發(fā)布了多個(gè)相關(guān)的庫(kù)。第一個(gè)是nt-hive，最初于2021年2月發(fā)布，它為Windows注冊(cè)表配置單元文件的內(nèi)部結(jié)構(gòu)實(shí)現(xiàn)了解析器。緊隨其后的是2022年1月的ntfs，這是一個(gè)更雄心勃勃的項(xiàng)目，旨在提供NTFS文件系統(tǒng)讀取器作為各種場(chǎng)景的可重用構(gòu)建塊。該庫(kù)已在虛擬FOSDEM 2022上發(fā)布，并附有關(guān)于 NTFS內(nèi)部的演示。幻燈片中有關(guān)NTFS內(nèi)部的演示也在這里。最新添加的是當(dāng)年晚些時(shí)候的 nt-list，它是圍繞 Windows 鏈表（也稱為L(zhǎng)IST_ENTRY和SINGLE_LIST_ENTRY）的類型安全和慣用的Rust包裝器。它已在 2022 年歐洲Rust大會(huì)上展出。用于分析apiset DLL的庫(kù)目前正在籌備中。

最終，這些庫(kù)都應(yīng)該在Rust驅(qū)動(dòng)的引導(dǎo)加載程序中使用。但是它們中的每一個(gè)現(xiàn)在都可以在各種上下文中使用，從低級(jí)系統(tǒng)開(kāi)發(fā)到用戶模式應(yīng)用程序。這已經(jīng)在發(fā)生。