"Device" = "/dev/cdrom"
"Filesystem" = "msdos"
4.5.4. 要做/开放要点
只有光盘是 iso9660 和光盘标签驻留在第一轨道上时才能够读取他。
最好检查 FAT 终极块(现在只检查一个字节)。
支持标签/系列号写。
标签能够长于 11 个字符? (iso9660 有 32 个字符)。
读取 ext2 卷标如何? ....
SaveOnlyUpdatedKeys
控制是把整个注册表保存到用户的注册表文档中，还是只保存用户实际上变更了的子键。考虑到用户的注册表将屏弃任何全局注册表文档和 Windows 注册表文档，通常应该只保存用户修改了的子键； 这种方式下，对全局或 Windows 注册表其余部分的变动仍能够影响这个用户。
4.6. Dll 加载
编写：Ove K鍁en <ovek@winehq.com>
(提取自 wine/documentation/dll-overrides)
wine.conf 指令(directive) [DllDefaults] 和 [DllOverrides] 是有些混乱的主题。这些指令的最终目的是足够清楚的，通过 - 给出一个选择，Wine 应该使用自己的内置 DLL，或应该使用在现存的 Windows 安装中找到的 .DLL 文档? 本文档将解释这些特征是如何工作的。
4.6.1. DLL 类型
native
一个“固有的”DLL 是为真实的 Microsoft Windows 写的一个 .DLL 文档。
builtin
一个“内置的”DLL 是个 Wine DLL。他们能够要么是 libwine.so 的一部分, 要么是在新近的版本中，在 Wine 在需要的时候能够装载的一个特别的 .so 文档。
elfdll
一个“elfdll”是有着一个特别的 Windows 式样的文档结构的一个 Wine .so 文档，他尽可能的和 Windows 相接近，并且通过使用特别的 ELF 装载器和连接器技巧，能够无缝的和“固有的” DLL 进行动态连接。Bertho Stultiens 正在做这项工作，但这个特征还没有合并到 Wine 中(因为政治上的原因和缺乏时间)，所以这个 DLL 类型此时在官方的 Wine 中不存在，“内置的” DLL 类型获取了 elfdll 的一些特征(比如动态装载)，所以“elfdll”的功能可能即将融入“内置”类型中。
so
一个固有的 Unix .so 文档，加上在装载库时生成的(? on the fly )调用惯例转换 thunk。(with calling convention conversion thunks generated on the fly as the library is loaded) 对于“glide”这样的在 Windows 和 Unix 二者上使用相同的 API 的库，这是很有用的。
译注：历史上，在实现 Algol 60 传名调用(call by name)的时候，把实际参数做为一个无参数的子程式来对待，传统上把这个无参数的子程式叫做 thunk。
4.6.2. [DllDefaults] 段
DefaultLoadOrder
假如正在处理的 DLL 未在 [DllOverrides] 段中找到，这个选项指定 Wine 应当以什么次序查找可获得的 DLL 类型。
4.6.3. [DllPairs] 段
有的时候，在缺省的配置文档中有一个叫 [DllPairs] 的段，他已被废弃了，因为组对信息已被嵌入到 Wine 自身中了。(本段的目的只但是是假如用户尝试组对(pair codependent)不同类型的16-bit/32-bit DLL 则发起警告。) 假如您的 wine.conf 或 ~/.wine/config 中仍然有他，您删除他是安全的。
4.6.4. [DllOverrides] 段
本段指定如何处理特定的 DLL，特别是，假如您从一个真实的 Windows 配置中得到一些“固有的”DLL，那么就要在这里指定是否使用他们。因为内置的 DLL 仍不能和固有的 DLL 无缝的混合，特定的 DLL 依赖可能有问题，但在 Wine中对许多流行的 DLL 配置存在着工作项目(workaround)。参见 WWN 的 [16] 状态页来找出您要用的 DLL 是否在 Wine 中被实现了。
当然也能够通过显式的使用 Wine 的 --dll 命令行选项来屏弃这些配置(详情参见手册页)。下面是对选择您的最优的配置的提示(列出 16/32-bit DLL 对):
krnl386, kernel32
他们的固有版本永远不能工作，所以不用尝试了。保持为 builtin。
gdi, gdi32
图像设备接口。尝试运行固有的 GDI 没什么作用。保持为 builtin。
user, user32
窗口管理和标准控件。有时可能要使用 Win95 的 native 版本(假如依赖于他的任何其他 DLL，比如 comctl32 和 comdlg32，也运行 native 版本的话)。但是，在地址空间单独(Address Space Separation)之后就不可能了，所以保持为 builtin。
ntdll
NT 内核 API。尽管没有很好的编制文档，他的 native 版本是永远不能工作的。保留为 builtin。
w32skrnl
Win32s (在 Win3.x 中)。他的 native 版本可能是永远不能工作的。保留为 builtin。
wow32
NT 的 Win16 支持库。他的 native 版本可能是永远不能工作的。保留为 builtin。
system
Win16 内核材料。他的 native 版本是永远不能工作的。保留为 builtin。
display
显示器驱动程式。明确的保留为 builtin。
toolhelp
工具帮助器例程。这很少出问题。保留为 builtin。
ver, version
版本。很少有用和处理他(mess with)。
advapi32
注册表和安全特征。他的 native 版本是否工作是两可的。
commdlg, comdlg32
通用对话框，比如颜色选择器、字体对话框、打印对话框、打开/保存对话框，等等。尝试 native 版本是安全的。
commctrl, comctl32
通用控件。他们是工具条、状态条、列表控件、等。尝试 native 版本是安全的。
shell, shell32
Shell 接口(桌面、文档系统、等)。他是 Windows 中未编制文档最严重的部分之一，您可能走运的能使用他的 native 版本，假如您需要的话。
winsock, wsock32
Windows 套接口。他的 native 版本不能在 Wine 下工作，所以保留为 builtin。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
