ReactOS 开发 > 开发者常见问题

开发者常见问题

开发者常见问题关于 ReactOS。如果您有更常见的问题，请阅读用户常见问题。

• 常规
• 图形子系统
• 文件子系统
• 调试

 

常规

在 ReactOS 里你要如何避免无可避免的 "Microsoft"（微软）文字？

我们相信，这是属于合理使用。并且除了注册表之外，它是不需要的。

那些为 Windows 设计的驱动程序能不能在 ReactOS 里运作？

我们已经知道有些驱动程序能够运作，但是在这个时刻并没有确定的答案，这是因为内核的某些功能仍然还未实现。

我需要什么才能从源码编译 ReactOS？

请参见我们的 构建环境页面（英文） 以便获取如何从源码编译 ReactOS 的信息。

你为什么不要去协助 Wine 工程呢？

其实我们与 Wine 工程紧密联系。Wine 很可能与 ReactOS 有更多的共同点过 Linux。Wine 工程有个目标实现整个 Windows API（应用程序编程界面）于 WineServer 之上。那里只有几个 WINE 动态链接库是不能在 ReactOS 里使用。它们是 NTDLL, USER32, KERNEL32, GDI32, 和 ADVAPI。剩余 WINE 的动态链接库可以与 ReactOS 共享。我们也有数位开发者在 WINE 和 ReactOS 工程里处理这两个工程之间的跨兼容性问题。在我们的观点，Linux + Wine 永远不能作为微软(R) Windows(R) 的完全替代品。ReactOS 有潜能达到更高的兼容性程度 – 尤其是微软(R) Windows(R) 驱动程序 – 这是 WINE 不会解决的部分。

我应该使用什么 IDE（集成开发环境）开发 ReactOS？

参见使用集成开发环境（英文）以获取已支持代码编辑器的信息。

那么关于所谓的 SEH 问题？

Structured exception handling（缩写：SEH，结构化异常处理）是用在编程 ReactOS，这是因为它也是用于编程 OS/2 或微软(R) Windows(R) NT。SEH 是由操作系统和编译器玩的一场游戏（关键词：__try, __except, __finally）。ReactOS 本身是能够了解 SEH 并且提供这个基础设施。可是直到现在，我们所使用的 GNU 编译器却无法生成了解 SEH 的代码。所以各位就不能通过 GNU 编译器编译那些使用 SEH 的驱动程序或程序。

图形子系统

为什么图形子系统是建立在 Ring 0 而非 Ring 3？

简短答案是因为微软选择这么做，并且我们为了目标驱动程序的兼容性，我们也不得已必须如此实现。

微软为什么将图形界面放在 Ring 0？

因为这样做会有助于速度上的优点。比起一个图形界面的服务器，它会以各自的进程运行，在执行图形界面操作的时候却无需做出内容背景的更改。当然这样做会使得架构比较不干净，并且当图形界面崩溃时也会导致整个系统崩溃。当图形界面已经引进到微软 (R) Windows(R) NT 4.0 的内核，这相同的讨论也曾在微软提起过。他们当时的结论是图形界面已经成熟了，如此一来就不出现任何问题除非出现一个损坏的驱动程序，并且它与在用户模式出错的后果是相似的。

ReactOS 是否也有微软(R) Windows(R) 相同的安全问题？

微软(R) Windows(R) NT 和其继承人并不是天性不安全的系统。我们相信是微软由于做出错误的决定导致一个安全系统变得不安全的。比如，Windows XP 在默认上给每个人管理员权限。一些服务却实现的很差并且时常简易使用优于安全课题。我们却可以，在ReactOS 重新编排这些优先权。到时比较麻烦的问题是微软并没有施压软件创建者能够在一般用户权限里运行。

我可以使用什么图形界面？

若要回答这个问题，各位必须了解在 ReactOS、微软®Windows® 的图形界面是如何运作：
- DIB 引擎（于图形子系统），连同您的显示卡驱动程序，提供渲染原始东西，比如长方形，线，和 BitBlit 操作。
- 然后，那里有 Win32 子系统 (CSRSS)，它提供窗口化功能，包括控制台窗口。
- USER32.DLL 库则提供稍微比较复杂的窗口，比如按钮和复选框。
- 然后 COMCTL32 库就提供更加复杂的窗口，比如打开文件对话框。
- 壳（比如资源管理器）只是一个在启动时开始的普通程序。它在其图标创建桌面和开始菜单。就是这个最后一个组件是可以用别的壳来取代。外边有许多出名开源的“资源管理器替代品”比如 LiteStep 和 BlackBox ，就是我们也打算支持的产品。

 

文件系统

ReactOS 使用与微软(R) Windows(R) NT 的文件系统驱动程序一样。就是因为这个原因，它实现了 IFS 界面（Installable File System，又成为可安装文件系统）。因此 ReactOS 将能够载入并使用 IFS 驱动程序。截稿为止 ReactOS 仍然无法载入微软(R) Windows(R) NT 原生的 IFS 驱动程序。但到了某些时候，ReactOS 将能够载入原生的 NTFS 驱动程序。

我们能否实现 FreeDOS 版的 FAT32 文件系统？

ReactOS 老早就支持 FAT32。因此没有必要再去实现另一个。

ReactOS 是否支持 VFAT 和长文件名称？

ReactOS 原生上支持长和 Unicode（万国码）的文件名称。这是取决于文件系统的驱动程序要如何应对他/她。ReactOS 所运来的 FAT 驱动程序支持 VFAT（相等于 FAT 的长文件名称）。

为什么你不要直接实现 Ext2/3 而却集中在 NTFS？

因为 NTFS 是个重大功能必须在某个阶段后支持。Ext2/3 当然对我们而言是个课题，可是外边也有一些工程的目标是在 NT 实现 Ext2/3。我们会在它们足够成熟后动用这些驱动程序。

我要在哪里寻找 Ext2/3 的 IFS？

您可以在以下的链接找到（英文）
http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm
http://sys.xiloo.com/projects/projects.htm#ext2fsd
http://ashedel.chat.ru/ext2fsnt/.

我能否前来协助编程可安装文件系统 (IFS) 驱动程序？

是的，在 IFS 驱动程序那里有很多东西要做。可是这方面却是非常难以编程。您可以说编程驱动程序本来就是难度较高可是要编程文件系统驱动程序更是难上加难的王道。如果您是真的一位内核破解者，欢迎前来我们的邮件列表并对大家宣布自己。

我们能否先研究 Ext2/3 而非在 NTFS？

可以，这将取决于您要使用什么文件系统。可是目前为止，Ext2/3-IFS 和我们的 NTFS-IFS 还未准备能够作为读取和写入的用途。所以这方面还需要更多付出并且唯一的选项是 FAT-IFS。

为什么你不要直接使用 Linux-NTFS 工程的代源码？

这些来源都很有用，但是就如所有的 NTFS 实现（除了微软本身的）都缺乏写入的支持。并且 NTFS 里还有许多未知、未记载的部分。我们正在与他们合作，或者目前为止，只是借用他们的代码。目前为止，NTFS 并没有优先权，所以这方面活跃的贡献是微乎其微。

究竟 ReactOS 的 NTFS 支持是多重要才能够成功？

ReactOS 工程逐步会看到 NTFS 支持为一个优先权，可是目前为止却没有什么严重的原因一定要有它。NTFS 主要是个硬盘的文件系统，所以唯一的原因非要有 NTFS 支持是当用户需要在使用 ReactOS 里访问一个 NTFS 格式的物理分区。如果严格 NTFS 兼容性不是个要求的话，其他文件系统也能够提供那些 NTFS 的高级功能（日志， ACL –访问控制列表，压缩，硬链接，等。）。所有来自于光盘媒介 (ISO-9660 or UDFS) 的软件，或可能是软盘以及外接媒介（闪存，记忆棒，等）通常是以 FAT 格式化。

JFS 源码（也用于 OS/2）能够自由下载。为什么不要在 ReactOS 将 JFS 作为标准的文件系统？

是的，但至少已经计划一个 IFS。既然 JFS 还是在日志，大型文件以及分区大小，访问控制列表，和扩展属性和硬链接里应用最先进的方法，它将会完全适合 ReactOS。我们还在处理它不过还是会欢迎您前来协助。

你是如何应对区分大小写的问题（比如 ext2）？

区分大小写的问题不是在文件系统本身的范围。这是相应驱动程序方面的问题。对象管理器提供整个命名空间能够原生支持区分大小写。所以当 IFS 驱动程序必须相应地处理时将会会得到一个特殊的大小写标记。一个被移植的文件系统驱动程序因此必须能够处理这两者（区分）大小写。

一个 64 位文件系统能否在 一台 32 位机器里运行？

是的。这个 64 位的部分只是访问到磁盘。这与可执行文件包含该驱动程序无关。那个可执行文件的比特数量与整个操作系统的数量是一样的。

现在 ReactOS 支持什么文件系统？

FAT(12/16/32) 外加 VFAT，ISO-9660 – 唯读光盘，NPFS - named pipe file system（命名管道文件系统 – 内部文件系统），MSFS – mail-slot file system（邮件槽文件系统-内部文件系统）

ReactOS 将会支持什么文件系统？

我们的目标是尽可能支持越多文件系统。IFS 驱动程序可以被开发，至少是那些在 Linux 中可用的磁盘文件系统。可是，要编程一个符合、能够运作的文件系统驱动程序却是非常困难的。所以这需要一些时间。那里至少会有：FAT(12/16/32) 外加 VFAT，ISO-9660 – 唯读光盘，以及一个较高的文件系统如 ext3，NTFS 或 JFS, ，NPFS - named pipe file system（命名管道文件系统 – 内部文件系统），MSFS – mail-slot file system（邮件槽文件系统-内部文件系统）

我有个点子：为什么不要直接丢掉这些古怪的驱动字符？

这是个古怪的点子。微软本身或许很可能也有这样的想法，但是他们仍然还未实现它。在 ReactOS 团队在这个课题也有些想法。可是截至为止在这个课题并没有足够的结论。那里也有一些点子就包括基于所挂载文件系统的内存或者掀开对象管理器的命名空间到 Win32 应用程序或驱动字符，可是每一个做法都各有各自的优缺点。注意： ReactOS/ 微软(R) Windows(R) NT 内核并不处理驱动字符。这些都是DOS 的遗迹（或者我应该说是 CP/M） 于 Win32。

什么是重定向器？

这是一种特殊 IFS 驱动程序的形式。它并不实现磁盘上的文件系统。而它却依赖内核的网络堆栈并多数提供一个远程文件系统（比如 SMB 共享）。

什么是文件系统识别器？

它是真正重量级的文件系统驱动程序。载入它而却发现没有可以挂载的分区只是浪费时间。为此 Dave Cutler 就发明了所谓的识别器驱动程序。它们或多或少是驱动程序架构的组成部分。这个驱动程序将会被载入并搜索分区其 IFS 能够读取的文件系统。如果找到这样的分区，它就会载入其 IFS 并挂载这个分区。

SEH 问题

Structured exception handling（缩写：SEH，结构化异常处理）是用在编程 ReactOS，这是因为它也是用于编程 OS/2 或微软(R) Windows(R) NT。SEH 是由操作系统和编译器玩的一场游戏（关键词：__try, __except, __finally）。ReactOS 本身是能够了解 SEH 并且提供这个基础设施。可是直到现在，我们所使用的 GNU 编译器却无法生成了解 SEH 的代码。所以各位就不能通过 GNU 编译器编译那些使用 SEH 的驱动程序或程序。

 

调试

我要如何在用户模式里追踪未处理的异常？

追踪的样貌很像以下的范例：
(KERNEL32:process/create.c:328) Process terminated abnormally due to unhandled exception （由于未处理的异常进程不正常的终止）
(KERNEL32:process/create.c:329) Address: 761a13e0 （地址：761a13e0）
(KERNEL32:process/create.c:334) Frames: （帧：）
(KERNEL32:process/create.c:338) 761a2be9
请阅读 reactos/baseaddress.cfg，寻找与您尝试追踪地址所匹配的最接近的较低地址。请在相对的动态链接库里使用阅读器打开 .map 文件然后再搜寻其偏移量。