| |
| Wine 用户指南（四） |
|
| 来源:
ChinaUnix博客 日期：
2005.02.03 15:17 (共有条评论) 我要评论 |
| |
Wine 用户指南（四）
翻译：寒蝉退士
译者声明：译者对译文不做任何形式的担保，译者对译文不拥有任何权利并且不负担任何义务。
原文：
http://www.winehq.com/Docs/wine-user/
第 4 章. 配置 Wine
目录
4.1. 一般配置
4.2. Win95/98 外观
4.3. 配置 x11drv 驱动器
4.4. 注册表
4.5. Wine 的驱动器标签和系列号
4.6. Dll 加载
4.7. 键盘
4.8. 处理字体
4.9. 在 Wine 中打印
设置 config 文件等。
4.1. 一般配置
Copyright 1999 Adam Sacarny
(提取自 wine/documentation/config)
4.1.1. Wine 配置文件
Wine config 文件存储各种 Wine 的设置。包括:
★ 驱动器和关于它们的信息
★ 目录设置
★ 端口设置
★ Wine 外观和感觉
★ Wine 的 DLL 用法
4.1.2. 我如何做一个?
本节将带领你经过制作一个 config 文件的(全部)过程。看一下文件 /documentation/samples/config。它是由段组织起来的。
段名 需要 用途
[Drive X] 是 设置 wine 识别的驱动器
[wine] 是 设置 wine 目录
[DllDefaults] 推荐 缺省装载的 DLL
[DllPairs] 推荐 对 DLL 的健全检查
[DllOverrides] 推荐 屏弃缺省的 DLL 装载
[options] 否 好象没人知道
[fonts] 是 字体外观和识别
[serialports] 否 wine 见到的 COM 端口
[parallelports] 否 wine 见到的 LPT 端口
[spooler] 否 打印缓冲池
[ports] 否 直接访问端口
[spy] 否 怎样处理特定的调试信息
[Registry] 否 指定 windows 注册表文件的位置
[tweak.layout] 推荐 wine 的外观
[programs] 否 自动运行的程序
[Console] 否 控制台设置
4.1.2.1. [Drive X] 段
这是自明的，下面是深入的指导。对于 Wine 中的每个驱动器最多有 6 行。
[Drive X]
上面的行开始了一个给字母是 X 的那个驱动器的段落。
Path=/dir/to/path
这个路径是这个驱动器开始的地方。当 Wine 在驱动器 X 中浏览的时候，它将见到目录 /dir/to/path 中的文件。不要忘记去掉尾随的斜杠!
"Type" = "floppy|hd|cdrom|network" "
设置 Wine 将见到的驱动器类型。类型必须等于下列四者之一 floppy、hd、cdrom、或 network。它们是自明的。
"Label" = "blah"
定义驱动器标签。一般只有查找一个特定的 CD-ROM 的应用程序需要它。关于查找标签的信息请参见 /documentation/cdrom-labels。标签最多是 11 个字符。
"Serial" = "deadbeef"
告诉 Wine 这个驱动器的系列号。一些意图防止剽窃的应用程序可能需要它，否则不要使用它。最多 8 个字符和十六进制数。
"Filesystem" = "msdos|win95|unix"
设置 Wine 查看这个驱动器上的文件的方式。
msdos 大小写不敏感文件系统。类似于 DOS 和 Windows 3.x。 8.3 是文件名的最大长度(eightdot.123) - 更长的部分将被截掉。(注意: 如果你想运行使用长文件名的程序，这将是非常糟的选择。win95 可以很好的与设计在 msdos 系统下运行的应用程序一起工作。换句话来说，你可能不需要使用它。)
win95 大小写不敏感。类似于 Windows 9x/NT4。这可能是你用来工作的长文件名文件系统。是给 wine 下运行的多数应用程序选择的文件系统。可能正是你需要的!
unix 大小写敏感。这个文件系统基本不用(Windows 应用程序需要大小写不敏感文件名)。如果你敢就试一下，win95 是更好的选择。
"Device" = "/dev/xx"
只用于软盘和光盘设备。在 Extended2 分区上使用它将有灾难性的结果(在一个 windows 应用程序尝试做一次低层写的时候，他们以在 FAT 下的方式去做 -- FAT 不能与 Extended2 混同使用)。
注意: 这个设置不是十分重要；如果保持未指定，几乎所有的应用程序都没有问题。对于 CD-ROM 你可能希望添加它来获得自动的标签检测。如果你不能确定指定的设备名字，只须为你的设备空缺这个设置。
下面是 Drive X 的一个设置，它是一个通用的硬盘驱动器: [Drive X]
"Path" = "/dos-a"
"Type" = "hd"
"Label" = "Hard Drive"
"Filesystem" = "win95"
下面是 Drive X 的一个设置，它是一个通用的 CD-ROM 驱动器:
[Drive X]
"Path" = "/dos-d"
"Type" = "cdrom"
"Label" = "Total Annihilation"
"Filesystem" = "win95"
"Device" = "/dev/hdc"
下面是 Drive X 的一个设置，它是一个通用的软盘驱动器:
[Drive X]
"Type" = "floppy"
"Path" = "/mnt/floppy"
"Label" = "Floppy Drive"
"Serial" = "87654321"
"Filesystem" = "win95"
"Device" = "/dev/fd0"
4.1.2.2. [wine] 段
配置文件的 [wine] 段包含 wine 使用的目录的信息。在给这些设置指定目录的时候，按它们在 wine 中出现的那样设置它们。如果你的驱动器 C 有一个路径 /dos，并且你的 windows 目录位于 /dos/windows，则使用: "Windows" = "c:windows"
它设置 windows 目录。如果你未曾有这个目录则建一个。没有尾随的斜杠(不能是 C:windows)!
"System" = "c:windowssystem"
它设置 windows 系统文件所在的地方。这个目录应当驻留在用于 Windows 设置的目录中。如果你没有 windows 则它应是系统文件所在的地方。再次强调，没有尾随的斜杠!
"Temp" = "c:temp"
这应该是你打算把临时文件存储到其中的目录。你必须有到它的写访问权限。
"Path" = "c:windows;c:windowssystem;c:blanco"
行为好象是 UNIX 的 PATH 环境变量设置。在 wine 运行如 wine sol.exe，如果 sol.exe 驻留在 Path 设置中指定的一个目录中，wine 将会运行它(当然，如果 sol.exe 驻留在当前目录中，wine 也可以运行它)。确保它总包含你的 windows 目录和系统目录(对于这个设置，它必须包含 "c:windows;c:windowssystem")。
"SymbolTableFile" = "wine.sym"
为 wine 调试器设置符号表。你可能不需要摆弄它。如果你的 wine 出了问题(stripped)可能用到它。
"printer" = "off|on"
告诉 wine 是否允许打印机驱动程序和打印工作。这些东西仍处在 alpha 阶段，所以使用它你要当心。但一些人可能发现它很有用。如果你不打算进行打印工作，则不要把它添加到你的 ~/.wine/config 中(它可能不在其中)。还要检查 [spooler] 和 [parallelports] 段。
4.1.2.3. 介绍 DLL 段
在 wine 配置文件中设置 DLL 段之前，你需要知道一些事情。
4.1.2.3.1. Windows DLL 对
多数 windows DLL 有 win16 (Windows 3.x) 和 win32 (Windows 9x/NT) 两种形式。win16 和 win32 DLL 版本的组合叫做"DLL 对"。下面是最常见的 DLL 对:
Win16 Win32 固有 [a]
KERNEL KERNEL32 否!
USER USER32 否!
SHELL SHELL32 是
GDI GDI32 否!
COMMDLG COMDLG32 是
VER VERSION 否
注释:a. 是 wine 可以使用固有的 dll?(参见下节)
4.1.2.3.2. DLL 的不同形式
wine 可以装载的 DLL 有多种形式:
native(本地，固有)
DLL 包含在 windows 中。许多 windows DLL 可以用它们固有的形式来装载。许多时候这些固有版本比它们的非 Microsoft 替代品要好一些，但不总是。
elfdll
用 ELF 封装的 windows DLL。当前还是实验性的(仍不能工作)。
so
本地 ELF 库。仍不能工作。
builtin(内置)
DLL 装载的最通常形式。如果 DLL 用固有形式装载是错误的(error-prone)(例如，KERNEL)，你没有固有的 DLL，或你想自由于 Microsoft，则可以使用它们。
4.1.2.4. [DllDefaults] 段
这些设置提供了 wine 的缺省 DLL 装载处理。
"DefaultLoadOrder" =" native, so, builtin"
这个设施是一个逗号分界的列表，按它的次序尝试装载 DLL。如果第一种选项失败了，它将尝试第二种，以次类推。上面的次序在多数情况下是最好的。
4.1.2.5. [DllPairs] 段
有时，在缺省配置文件中有一个叫做 [DllPairs] 的段，它已经被废弃了，原因是组对信息已经被嵌入到 Wine 自身中。(本段的目的只不过是如果用户尝试组对(pair codependent)不同类型的16-bit/32-bit DLL 则发起警告。) 如果你的 wine.conf 或 ~/.wine/config 中仍然有它，你删除它是安全的。
4.1.2.6. [DllOverrides] 段
本段的格式对于每行都是相同的: {,,...} = {,,...}
例如，要装载内置的 KERNEL 对(这里大小写都行): "kernel,kernel32" = "builtin"
要装载固有 COMMDLG 对，但如果它们不工作则尝试内置的: "commdlg,comdlg32" = "native,builtin"
要装载 COMCTL32: "comctl32" = "native"
下面是一个很好的通用设置(在你 wine 包中的 config 文件中定义的): [DllOverrides]
"commdlg" = "builtin, native"
"comdlg32" = "builtin, native"
"ver" = "builtin, native"
"version" = "builtin, native"
"shell" = "builtin, native"
"shell32" = "builtin, native"
"lzexpand" = "builtin, native"
"lz32" = "builtin, native"
"comctl32" = "builtin, native"
"commctrl" = "builtin, native"
"wsock32" = "builtin"
"winsock" = "builtin"
"advapi32" = "builtin, native"
"crtdll" = "builtin, native"
"mpr" = "builtin, native"
"winspool.drv" = "builtin, native"
"ddraw" = "builtin, native"
"dinput" = "builtin, native"
"dsound" = "builtin, native"
"mmsystem" = "builtin"
"winmm" = "builtin"
"msvcrt" = "native, builtin"
"msvideo" = "builtin, native"
"msvfw32" = "builtin, native"
"mcicda.drv" = "builtin, native"
"mciseq.drv" = "builtin, native"
"mciwave.drv" = "builtin, native"
"mciavi.drv" = "native, builtin"
"mcianim.drv" = "native, builtin"
"msacm.drv" = "builtin, native"
"msacm" = "builtin, native"
"msacm32" = "builtin, native"
"midimap.drv" = "builtin, native"
"wnaspi32" = "builtin"
"icmp" = "builtin"
注意: 你见到此中的一些 dll 的第一选项是 elfdll 或 so。对于你这个尝试将是失败的，但你不用管它，它会使用第二个或第三个选项。
4.1.2.7. [options] 段
好象没人知道这段是干什么用的...
"AllocSystemColors" = "100"
分配的系统颜色? 保持它为 100。
4.1.2.8. [fonts] 段
本段设置 wine 的字体处理。
"Resolution" = "96"
因为 X 处理字体的方式与 Windows 的方式不同，wine 使用一个特殊的机制来处理它们。它必须使用在"Resolution"设置中的数来缩放字体。60-120 是合理的值，96 是此间的一个很好的值。如果你能获得真实的 windows 字体(参见 /documentation/
ttfserver 和 fonts)，这个选项就不重要了。当然，总是可以使你的 X 字体在 wine 中工作的很好。
"Default" = "-adobe-times-"
wine 使用的缺省字体。随你的喜好去设置(fool around with)它。
可选的:
Alias 设置允许你把一个 X 字体映射成在 wine 中使用的一个字体。如果应用程序需要使用你没有的特定字体，而存在一个很好的替代字体，可使用这个设置。语法如下: "AliasX" = "[伪装的 windows 名字],[真实的 X 名字]"
非常直接，把 "AliasX" 替换为 "Alias0", 接着 "Alias1" 并以此类推。伪装的 windows 名字是在 wine 中的 windows 应用程序将见到的字体名字。而真实的 X 名字是 X 见到的字体名字(运行 "xfontsel"可以查看)。可选的"屏蔽" 段允许你利用你定义的伪装 windows 名字。如果不使用它，则 wine 将只是尝试提取伪装 windows 名字自身而不使用你输入的值。
下面是没有屏蔽的别名的例子。字体在 windows 应用程序中将表现为"Google"。在一个 config 文件中定义一个别名的时候，请忘记我的注释文本("/documentation/fonts
4.1.2.9. [serialports]、[parallelports]、[spooler]、和 [ports] 段
尽管看起来好象是很多段，它们是紧密关联的。它们都是关于通信和并行端口的。
[serialports] 段告诉 wine 那些串行端口是允许使用的。 "ComX" = "/dev/cuaY"
把 X 替换为 Windows 中 COM 端口号(1-8) 而 Y 是它在 X 的编号(通常是在 Windows 中端口号减 1)。 ComX 实际上可以是任何设备(/dev/modem 是可接受的)。不总是需要定义任何 COM 端口(一个可选的设置)。下面是一个例子: "Com1" = "/dev/cua0"
你想设置多少就设置多少。定义你需要的所有 COM 端口。
[parallelports] 段设置在 wine 下可以访问的任何并行端口。 "LptX" = "/dev/lpY"
很熟悉? 语法很象 COM 端口设置。把 X 替代为 1-4 的一个值如同在 Windows 中那样，把 Y 替代为 0-3 的一个值(同 COM 端口一样，Y 通常是在 windows 中的值减 1)。你不总是需要定义一个并行端口(AKA，它是可选的)。象其他段一样，LptX 可以等于任何设备(可能是 /dev/printer)。下面是一个例子: "Lpt1" = "/dev/lp0"
[spooler] 段将通知 wine 在那里缓冲(spool)打印作业。如果你想打印的话就要使用它。Wine docs 声称现在的缓冲池是 "非常原始的"，所以它不能很好的工作。这是可选的。在本段中你唯一的设置工作是把一个端口(例如，LPT1)映射到一个文件或一个命令上。下面是一个例子，把 LPT1 映射到一个文件 out.ps 上: "LPT1:" = "out.ps"
下列命令把到 LPT1 的打印作业映射到命令 lpr。注意这个 |: "LPT1:" = "|lpr"
[ports] 段只在需要直接端口访问的时候是有用的，例如用户的程序需要 dongle(加密/解密器)或扫描仪。如果不需要，就不要用它!
"read" = "0x779,0x379,0x280-0x2a0"
给予到这些 IO 的直接读访问。
"write" = "0x779,0x379,0x280-0x2a0"
给予到这些 IO 的直接写访问。这是保持 read 和 write 的设置相同可能是个好主意。只有你以 root 运行的时候这些材料才能工作。
4.1.2.10. [spy]、[Registry]、[tweak.layout]、和 [programs] 段
使用 [spy] 来包含或排除调试信息，并把它们输出到一个文件中。后者是很少使用的。这些都是可选的，你可能不需要向你的 config 中的这个段增加或删除任何东西。
"File" = "/blanco"
为 wine 设置日志文件。设置为 CON 来记录到标准输出。这很少使用。
"Exclude" = "WM_SIZE;WM_TIMER;"
在日志文件中排除关于 WM_SIZE 和 WM_TIMER 的调试信息。
"Include" = "WM_SIZE;WM_TIMER;"
在日志文件中包含关于 WM_SIZE 和 WM_TIMER 的调试信息。
使用 [Registry] 来告诉 wine 你的旧有的 windows 注册表文件存在于什么地方。这个段是完全可选的，而且对没有现存 windows 安装的人是没用的。
"UserFileName" = "/dirs/to/user.reg"
你旧有的 user.reg 文件的位置。
[tweak.layout] 决定 wine 的外观。它只有一个设置。
"WineLook" = "win31|win95|win98"
可以把 wine 的外观改变为 Windows 3.1 和 Windows 95。win98 设置的行为在多数情况下类似于 win95。
使用 [programs] 来说明在特定条件下运行什么程序。
"Default" = "/program/to/execute.exe"
设置启动 wine 而未指定一个程序的时候运行的程序。
"Startup" = "/program/to/execute.exe"
设置在每次启动的时候自动运行的程序。
4.1.3. 我把它放在哪里?
wine config 文件可以放到两个地方。
/usr/local/etc/wine.conf
系统范围的 config 文件，用于没有自己的配置文件的任何人。注意: 这个文件当前未使用，原因是一个新的全局配置机制现在仍未准备好。
$HOME/.wine/config
你自己的 config 文件，只用于你的用户。
把你的 wine.conf 版本文件复制到 /usr/local/etc/wine.conf 或 $HOME/.wine/config 来让 wine 识别它。
4.1.4. 如果它不工作怎么办?
事情总是可能出错。如果不可想象的事情发生了，尝试一下新闻组，comp.emulators.ms-windows.wine，或者在 irc.stealth.net:6668 或连接的服务器上找寻 IRCnet 频道 #WineHQ。确保你完全的查阅了本文档，并且还读了:
README
http://www.la-sorciere.de/wine/index.html
(可选的，推荐的)
如果看起来你真的已经作了研究，等着收到有帮助的建议好了。如果你没有，作好受到指责的准备。
4.2. Win95/98 外观
编写：David A. Cuthbert
(提取自 wine/documentation/win95look)
介绍 Win95/Win98 界面设置。
不再使用 #define 开关为 Win3.1 和 Win95 外观来编译 Wine，现在在 ~/.wine/config 中一个特殊的 [Tweak.Layout] 段中编码，其中有 "WineLook" = "Win95" 或 "WineLook" = "Win98" 条目。
已经向 ~/.wine/config 文件增加了一些新的段和一些条目 -- 它们只是用来调试 Win95 tweak 并且可能在将来的发行中删除掉! 这些条目/段是:
[Tweak.Fonts]
"System.Height" = "" # 设置系统字型的高度
"System.Bold" = "[true|false]" # 系统字体是否应该是粗体
"System.Italic" = "[true|false]" # 系统字体是否应该是斜体
"System.Underline" = "[true|false]" # 系统字体是否应该有下划线
"System.StrikeOut" = "[true|false]" # 系统字体是否应该有删除线
"OEMFixed.xxx" # 给 OEM fixed 字型的一些参数
"AnsiFixed.xxx" # 给 Ansi fixed 字型的一些参数
"AnsiVar.xxx" # 给 Ansi variable 字型的一些参数
"SystemFixed.xxx" # 给系统 fixed 字型的一些参数
[Tweak.Layout]
"WineLook" = "[Win31|Win95|Win98]" # 改变 Wine 的感观
4.3. 配置 x11drv 驱动器
编写：Ove K鍁en
(提取自 wine/documentation/cdrom-labels)
多数 Wine 用户在一个叫做 X11 的窗口系统下运行 Wine。在 Wine 历史上的多数时期，这是唯一的可获得的显示驱动器，但是在近几年，已经重新组织了部分 Wine 来允许其他显示驱动器(当前只能获得一个可替代的显示驱动器是 Patrik Stridvall 的基于 ncurses 的 ttydrv，他声称用它来显示 calc.exe)。在~/.wine/config 的 [wine] 段中用 GraphicsDriver 选项来选择显示驱动器，但在本文中我只覆盖 x11drv 驱动器。
4.3.1. x11drv 操作模式
x11drv 驱动器由两个概念上的不同部分组成，图形驱动器(GDI 部分)，和窗口驱动器(USER 部分)。但它们二者都被连接到 libx11drv.so 模块中(你用 GraphicsDriver 选项装载它)。在 Wine 中，运行在 X11 上，图形驱动器必须在窗口驱动器提供的 drawable (window interior)上绘图。这与 Windows 模型有一点区别， 在 X11 中，窗口系统建立和配置由图形驱动器控制的设备上下文，而允许应用程序在它们喜欢的任何地方用挂钩连接起(hook into)这个联系。所以，为了要在兼容性和可用性之间提供有道理的任何折中，x11drv 有三种不同的操作模式。
Unmanaged/Normal
缺省的。窗口管理器无关(完全忽略任何运行的窗口管理器)。 窗口装饰(decoration)(标题条，边界，等)由 Wine 绘制来使感观如同真实的 Windows。这兼容于依靠可以计算出这些装饰的精确大小的应用程序，或想自己画它们的程序。
Managed
使用 --managed 命令行选项或 Managed wine.conf 选项(见后)指定。普通的顶层框架窗口，有粗边界，标题条，和由你的窗口管理器管理的系统菜单。这允许这些应用可以与你的桌面的其余部分更好的集成，但可能不总是工作的很好。(非常需要一个重写的这种操作模式，使它更加健壮和更少瑕疵(patchy)，并计划在 Wine 1.0 发行之前完成。)
Desktop-in-a-Box
使用 --desktop 命令行选项(加上一个几何，比如给一个 800x600 这么大的桌面 --desktop 800x600， 或者在显示器的左上角自动的定位桌面 --desktop 800x600+0+0 )。这是与 Windows 模型最兼容的模式。所有应用程序窗口都是在提供给 Wine 的桌面窗口内的 Wine 绘制的窗口(桌面窗口自身由你的窗口管理器来管理)，而 Windows 应用可以随心所欲的在这个虚拟工作空间操作并认为完全拥有它，不受你的其他 X 应用程序的打扰。
4.3.2. [x11drv] 段
AllocSystemColors
只在你拥有一个基于调色板(palette)的显示器时使用，例如，如果你的 X 服务器被设置为 8bpp 的色深，并且你没有想要的一个私有颜色映射。它指定 Wine 所占有的共享颜色映射(colormap)单元(palette entries)的最大数目。这个值越高，其他应用程序可获得的颜色就越少。
PrivateColorMap
在你拥有一个基于调色板的显示器时使用，例如，如果你的 X 服务器被设置为 8bpp 的色深。它指定你不想使用共享的颜色映射，而是使用一个私有的颜色映射，这这里可以获得全部的 256 种颜色。不足是这个 Wine 的私有颜色映射只在鼠标指针在这个 Wine 窗口期间可以见到，所以如果你频繁使用鼠标就会经常见到迷幻的闪烁和滑稽的颜色。
PerfectGraphics
它确定在 blit 操作中对于特定的 ROP 代码使用快速 X11 例程还是严格的 Wine 例程。多数用户不能找出任何区别。
ScreenDepth
只在多色深显示器上使用。它指定 Wine 应当使用(并告诉 Windows 应用程序)那种可获得的色深。
Display
它指定使用那个 X11 显示器，并且如果被指定了，它将屏弃 DISPLAY 环境变量和 --display 命令行选项二者。
Managed
Wine 可以让框架窗口由你的窗口管理器来管理。这个选项指定你是否想使之成为缺省的。
UseDGA
它指定你是否想让 DirectDraw 使用 XFree86 的直接图形体系(Direct Graphics Architecture -- DGA)，这可以接管整个显示器并在全屏幕下以最大速度运行游戏。(使用 DGA1 (XFree86 3.x)，你仍需要首先把 X 服务器配置成游戏所需的 bpp，而使用 DGA2 (XFree86 4.x)，依赖于你的驱动器的能力，有可能使用运行时颜色选择。) 但要当心如果 Wine 在 DGA 模式下崩溃，要想收复对你的计算机的控制就只能重启动了。DGA 通常要求要么特权要么对 /dev/mem 的读/写访问权限。
UseXShm
如果你不希望 DirectX 使用 DGA，你至少可以使用 X 共享内存扩展(X Shared Memory extensions -- XShm)。它比 DGA 慢很多，原因是应用程序不直接访问物理的桢缓冲区，但是使用共享内存来绘制桢至少比使用标准 X11 套接口要快，即使通过 Wine 的 XShm 支持有时仍会崩溃。
DXGrab
如果你不使用 DGA，你可能想要一种替代的方式来确保鼠标光标滞留在游戏窗口中。这个选项就是干这个的。当然，象使用 DGA 一样，如果你的 Wine 崩溃了，你就有麻烦了(但不象 DGA 情况下那么糟，因为你仍然可以使用键盘来退出 X)。
DesktopDoubleBuffered
只在你使用了 --desktop 命令行选项来在一个桌面窗口中运行时使用。指定建立的桌面窗口是否有双缓冲区的 visual，是多数 OpenGL 游戏正确运行所需的东西。
4.4. 注册表
编写：Ove K鍁en
(提取自 wine/documentation/registry)
在 Win3.x 之后，注册表成为 Windows 的一个基本部分。Windows 自身，和所有遵循 Win95/98/NT/2000/whatever 的应用程序，在其中存贮配置和状态数据。尽管多数有理智的系统管理员(和 Wine 开发者)恶毒的诅咒 Windows 注册表的扭曲天性(twisted nature)。Wine 以某种方式支持它仍是必须的。
4.4.1. 注册表结构
Windows 注册表是一个复杂的树结构，而且多数 Windows 程序员不完全知道注册表是怎样布置的，加上它的不同的 "蜂窝"和它们之间的大量连接；一个完整个论述(coverage)超出了本文档的范围。下面是你需要知道的基本的注册键。
HKEY_LOCAL_MACHINE
这个基本根键(在 win9x 中，存储在隐藏文件 system.dat 中)包含与当前 Windows 有关的所有东西。
HKEY_USERS
这个基本根键(在 win9x 中，存储在隐藏文件 user.dat 中)包含这个安装的每个用户的配置数据。
HKEY_CLASSES_ROOT
这是到 HKEY_LOCAL_MACHINESoftwareClasses 的一个连接。它包含描述文件关联、OLE 文档处理器、和 COM 类的数据。
HKEY_CURRENT_USER
这是到 HKEY_USERSyour_username 的一个连接，比如，你的个人配置。
4.4.2. 使用 Windows 注册表
如果你把 Wine 指向一个现存的 MS 安装(通过在 ~/.wine/config 中设置适当的目录，则 Wine 能从中装载注册表数据。但是，Wine 不会把任何东西保存到真实的 Windows 注册表中，而是保存到它自己的注册表文件中(见后)。当然，如果在 Windows 注册表和 Wine 注册表二者中都存在一个特定的注册值，则 Wine 将使用后者。
偶尔的，Wine 装载 Windows 注册表可能有麻烦。通常，这是因为注册表是不一致或以某种方式被破坏的。如果出现了这个问题，你可以从 MS 的网站下载 regclean.exe 并使用它来清理注册表。作为替代，你总是可以使用 regedit.exe 来把你需要的数据导出到一个文本文件中，并接着导入到 Wine 中。
4.4.3. Wine 注册表数据文件
在用户的主目录中，有一个叫 .wine 的子目录，Wine 缺省的将尝试在这里保存它的注册表。它保存到四个文件中，它们是:
system.reg
这个文件包含 HKEY_LOCAL_MACHINE。
user.reg
这个文件包含 HKEY_CURRENT_USER。
userdef.reg
这个文件包含 HKEY_USERS.Default (比如，缺省用户设置)。
wine.userreg
Wine 把 HKEY_USERS 保存到这个文件中(当前和缺省二者)，但不从中装载，除非 userdef.reg 丢失的。
所有这些文件是常人可读的文本文件，所以不象 Windows，如果需要的话，你实际上可以用一个普通的文本编辑器来编辑它。
除了这些文件之外，Wine 还可以有选择的从全局注册表文件中装载，它驻留在与全局 wine.conf 相同的目录中(比如，如果你从源代码编译的话则是 /usr/local/etc)。它们是:
wine.systemreg
包含 HKEY_LOCAL_MACHINE。
wine.userreg
包含 HKEY_USERS。
4.4.4. 系统管理
一个系统管理员可以使用上面的文件结构配置系统，这样一个系统 Wine 安装(和应用程序)可以被所有用户共享，而仍旧让用户拥有它自己的个人化配置。一个管理员可以，在安装了 Wine 和用户需要访问的所有 Windows 应用软件之后，把结果的 system.reg 和 wine.userreg 复制成全局注册表文件(我们假定它驻留在 /usr/local/etc)，使用:
cd ~/.wine
cp system.reg /usr/local/etc/wine.systemreg
cp wine.userreg /usr/local/etc/wine.userreg
并且甚至可以把它们符号连接回管理员的帐户上，以便易于以后安装系统范围的应用程序:
ln -sf /usr/local/etc/wine.systemreg system.reg
ln -sf /usr/local/etc/wine.userreg wine.userreg
注意如果你以 root 安装 Wine，tools/wineinstall 脚本已经为你作好了这一切。如果你接着在 root 登录期间安装 Windows 应用程序，你的所有用户就自动的可以使用它们了。应用程序的设置将接受全局注册表，而用户的个人化配置将保存在他们自己的主目录中。
但是要注意对管理员帐户的操作 - 如果你把管理员的注册表复制或连接成全局注册表，任何用户就都可以读到管理员的偏好，如果在其中存储了敏感信息(口令、个人信息，等)这就不好了。只使用管理员帐户安装软件，而不是进行日常工作；平时使用一个普通用户帐户。
4.4.5. 缺省的注册表
一个 Windows 注册表缺省的包含许多键，而其中的一些对于安装程序进行正确的操作是必须的。在叫 winedefault.reg 的文件中包含了 Wine 开发者找到的对安装应用程序是必须的键。如果你使用 tools/wineinstall 脚本则已经为你自动安装了它，如果你想手动安装它，你可以使用 regapi 工具做这件事。你可在 Wine 发布中的 documentation/no-windows 文档中找到更多的信息。
4.4.6. [registry] 段
有了以上信息，下面查看一下 wine.conf/~/.wine/config 中处理注册表的选项。
LoadGlobalRegistryFiles
控制是否尝试装载全局注册表，如果它存在的话。
LoadHomeRegistryFiles
控制是否尝试装载用户的注册表文件(在用户的主目录中的 .wine 子目录中)。
LoadWindowsRegistryFiles
控制 Wine 是否尝试从在现存的 MS Windows 安装中的真实的 Windows 注册表中装载注册信息。
WritetoHomeRegistryFiles
控制是否把注册信息写到用户的注册表文件中(目前，这是没有选择的，就是说如果你把它关闭了， Wine 根本就不能把注册表保存到磁盘上；你退出 Wine 之后，你的变动就消失了。)
UseNewFormat
这个选项被废弃了。Wine 现在总是使用新格式；前些时候去除了对旧格式的支持。
PeriodicSave
如果设置这个选项为一个非零的值，它指定你想以一个给定的时间间隔把注册表保存到磁盘上。如果你未设置它，则只在 wineserver 终止的时候把注册表保存到磁盘上。
4.5. wine 的驱动器标签和系列号
编写：Petr Tomasek Nov 14 1999
修改：Andreas Mohr Jan 25 2000
(提取自 wine/documentation/cdrom-labels)
直到不久前，你只可能在 wine config 文件中通过手动设置来指定驱动器卷标和系列号。现在，wine 也可以直接从驱动器读取它们。对在 CD-ROM 上发布的许多 Win 9x 游戏和安装程序这是很有用的，它们检查卷标。
4.5.1. 支持什么?
文件系统 类型 注释
FAT 系统 硬盘、软盘 读取标签和系列号
ISO9660 光盘 只读取标签
4.5.2. 如何设置?
如果你在 ~/.wine/config 文件的[Drive X]段中指定了一个 Device= 行，则自动的读取标签和系列号。注意如果你这样设置它，则这个设备必须存在和可以访问。
如果你不这样做，则你应该在 ~./wine/config 中给出固定的 "Label" = 或 "Serial" = 条目，如果没有给出设备则 Wine 返回这些条目。如果它们不存在，则 Wine 将返回缺省值(标签 Drive X 和系列号 12345678)。
如果你给出一个 "Device" = 条目只是为了原始扇区访问，而不从这个设备读取卷信息(例如，你希望有一个固定的，预先配置的标签)，则你需要指定 "ReadVolInfo" = "0" 来告诉 Wine 跳过卷读取。
4.5.3. 例子
这里是光盘和软盘一个例子；从光盘和软盘二者的设备上读取标签；只从软盘上读取系列号:
[Drive A]
"Path" = "/mnt/floppy"
"Type" = "floppy"
"Device" = "/dev/fd0"
"Filesystem" = "msdos"
[Drive R]
"Path" = "/mnt/cdrom"
"Type" = "cdrom"
"Device" = "/dev/hda1"
"Filesystem" = "win95"
下面是屏弃 CD-ROM 标签的一个例子:
[Drive J]
"Path" = "/mnt/cdrom"
"Type" = "cdrom"
"Label" = "X234GCDSE"
; 注意这里的这个设备不是真的需要有一个固定的标签
"Device" = "/dev/cdrom"
"Filesystem" = "msdos"
4.5.4. 要做/开放要点
只有光盘是 iso9660 和光盘标签驻留在第一轨道上时才可以读取它。
最好检查 FAT 超级块(现在只检查一个字节)。
支持标签/系列号写。
标签可以长于 11 个字符? (iso9660 有 32 个字符)。
读取 ext2 卷标如何? ....
SaveOnlyUpdatedKeys
控制是把整个注册表保存到用户的注册表文件中，还是只保存用户实际上变更了的子键。考虑到用户的注册表将屏弃任何全局注册表文件和 Windows 注册表文件，通常应该只保存用户修改了的子键； 这种方式下，对全局或 Windows 注册表其余部分的变动仍可以影响这个用户。
4.6. Dll 加载
编写：Ove K鍁en
(提取自 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。
icmp
给 wsock32 的 ICMP 例程。如同 wsock32，保留为 builtin。
mpr
由于 thunking 要点，它的 native 版本可能不工作。保留为 builtin。
lzexpand, lz32
Lempel-Ziv 压缩。 Wine 的 builtin 版本应当工作的很好。
winaspi, wnaspi32
高级 SCSI 外设接口。它的 native 版本可能不工作。保留为 builtin。
crtdll
C 运行时库。它的 native 版本很容易的比 Wine 的版本工作的好。
winspool.drv
打印机缓冲池。你好象没有那么走运使用它的 native 版本。
ddraw
DirectDraw/Direct3D(直接绘制/直接三维)。因为 Wine 没有实现 DirectX HAL，现在它的 native 版本不能工作。
dinput
DirectInput(直接输入)。它的 native 版本是否工作是两可的。
dsound
DirectSound(直接声音)。可能运行它的 native 版本，但不要依仗它。
dplay/dplayx
DirectPlay(直接播放)。它的 native 版本应该工作的非常好，如果是完全的话。
mmsystem, winmm
多媒体系统。它的 native 版本好象不能工作。保留为 builtin。
msacm, msacm32
音频压缩管理器。如果你把 msacm.drv 设置为相同的，它的 builtin 版本工作的非常好。
msvideo, msvfw32
Windows 视频。 可以安全的(和推荐)尝试 native 版本。
mcicda.drv
CD 音频 MCI 驱动程序。
mciseq.drv
MIDI Sequencer MCI 驱动程序(.MID 回放)。
mciwave.drv
Wave 音频 MCI 驱动程序(.WAV 回放)。
mciavi.drv
AVI MCI 驱动程序(.AVI 视频回放)。最好使用 native 版本。
mcianim.drv
Animation MCI 驱动程序。
msacm.drv
音频压缩管理器。设置为与 msacm32 相同。
midimap.drv
MIDI Mapper。
wprocs
这是 Wine 用于 thunking 目的的一个伪装 DLL。它的 native 版本不存在。
4.7. 键盘
编写：Ove K鍁en
(提取自 wine/documentation/keyboard)
现在 Wine 需要知道你的键盘布局(layout)。这个要求来自一些应用程序的需求，它们需要获得正确的键盘扫描码，原因是它们直接读取这些扫描码，而不是接受从 X 服务器返回的字符。这意味着 Wine 现在需要有一个从 X 键到这些程序所需要的扫描码的映射。
在启动的时候，Wine 尝试着识别活跃的 X 布局，方法是查看它是否匹配任何定义的表。如果是，所有的事情都正常。如果不是，你需要定义它。
要想定义它，打开文件 windows/x11drv/keyboard.c 并查看现存的表。复制它做为一个备份，特别是在你不是使用 CVS 的时候。
你实际上需要做的是找出每个键需要生成的那个扫描码。在 main_key_scan 表中查看，它看起来如下:
static const int main_key_scan[MAIN_LEN] =
{
/* 这是我的 (102-键) 键盘布局，如果不匹配你的键盘是很遗憾的 */
0x29,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,
0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,
0x1E,0x1F,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x2B,
0x2C,0x2D,0x2E,0x2F,0x30,0x31,0x32,0x33,0x34,0x35,
0x56
/* 第 102 个键(实际上在 l-shift 的右边) */
};
static const char main_key_US_phantom[MAIN_LEN][4] =
{
"`~","1!","
[email=2@]2@","3#","4$","5%","6^","7&","8*","9(","0[/email]
)","-_","=+",
"qQ","wW","eE","rR","tT","yY","uU","iI","oO","pP","[{","]}",
"aA","sS","dD","fF","gG","hH","jJ","kK","lL",";:","'"","|",
"zZ","xX","cC","vV","bB","nN","mM",",","/?",
"" /* 幽灵键 */
};
接着，把印在按键上的字符赋予每个扫描码。这为 US 101 键键盘(的次序)做的。它可以在 keyboard.c 的顶部找到。它还显示了如果没有第 102 键，你可以跳过它。
但是，对于多数国际化的 102 键键盘，我们使它易于你的使用。这些键盘的扫描码布局已经非常匹配在 main_key_scan 中的物理键盘布局了，所以你要做的所有事情就是完成在你主键盘上生成字符的所有的键(除了空格键之外)，并把它们组织到一个适当的表中。只有第 102 个键是个例外，它通常在最后一行的第一个字符的左边(通常是 Z)，它必须放到在最后一行之后的单独一行中。
例如，我的挪威(Norwegian)键盘看起来如下
? ! " # ? % & / ( ) = ? ` Back-
| 1 2@ 3?4$ 5 6 7{ 8[ 9] 0} + ?space
Tab Q W E R T Y U I O P ? ^
▇
Enter
Caps A S D F G H J K L ? ? *
Lock '
Sh- > Z X C V B N M ; : _ Shift
ift 键，在 Z 的左边。在主字符右侧的那个字符是由 AltGr 键生成的字符。
定义这个键盘如下:
static const char main_key_NO[MAIN_LEN][4] =
{
"|?,"1!","2"@","3#?,"4?","5%","6&","7/{","8([","9)]","0=}","+?","?,
"qQ","wW","eE","rR","tT","yY","uU","iI","oO","pP","迮","╚~",
"aA","sS","dD","fF","gG","hH","jJ","kK","lL","","嫫","'*",
"zZ","xX","cC","vV","bB","nN","mM",",;",".:","-_",
""
};
除了 " 和 需要用反斜杠引用起来，和第 102 个键在单独的一行之外，它是非常直接的。
你写完了一个这样的表之后，你需要把它添加到 main_key_tab[] 布局索引表中。这看起来如下:
static struct
{
WORD lang, ansi_codepage, oem_codepage;
const char (*key)[MAIN_LEN][4];
} main_key_tab[]={
...
...
{MAKELANGID(LANG_NORWEGIAN,SUBLANG_DEFAULT), 1252, 865, &main_key_NO},
...
在你增加了这个表之后，重新编译 Wine 并测试它的工作。如果检测你的表失败，尝试运行
wine --debugmsg +key,+keyboard >& key.log
并查看结果的 key.log 文件来找到关于你的布局的错误消息。
注意 LANG_* 和 SUBLANG_* 定义在 include/winnls.h 中，你可能需要用它找出给你的语言分配的编号，并在调试消息输出中找到它。这个编号是(SUBLANG * 0x400 + LANG)，所以，例如 LANG_NORWEGIAN (0x14) 和 SUBLANG_DEFAULT (0x1) 的组合将是 (十六进制的) 14 + 1*400 = 414，因为我是挪威人，我将在调试消息输出中查找 0414 以便找出为什么不能检测到我的键盘。
一旦它工作了，请提交到 Wine 计划。如果你使用 CVS，你需要在你的主 Wine 目录中做
cvs -z3 diff -u windows/x11drv/keyboard.c > layout.diff
，接着把 layout.diff 提交到 并加上关于它是什么的一个简要的说明。
如果你不使用 CVS，你需要做
diff -u the_backup_file_you_made windows/x11drv/keyboard.c > layout.diff
并按上面解说的那样提交。
如果你做的正确，它将被包括到下一次 Wine 发行中，而所有使用扫描码的有问题的应用程序(尤其是远程控制应用程序)和游戏将荣幸的使用你键盘布局，并且你将不再得到这些闹心的 fixme 消息了。
祝你好运。
4.8. 处理字体
4.8.1. 字体
编写：Alex Korobka
(提取自 wine/documentation/fonts)
Note: Wine 包含了 fnt2bdf 实用工具。可以在 tools 目录中找到它。可以在 wine headquarters:
http://www.winehq.com/tools.html
找到到本文档中提及的工具的链接。
4.8.1.1.如何转换 Windows 字体
如果你要访问一个 Windows 安装，你应该使用 fnt2bdf 实用工具(可在 tools 目录中找到) 来把位图字体(VGASYS.FON、SSERIFE.FON、和 SERIFE.FON)转换成 X 窗口系统可以识别的格式。
用 fnt2bdf 提取位图字体。
使用 bdftopcf 把第一步生成的 .bdf 文件转换成 .pcf 文件。
把 .pcf 文件复制到字体服务器目录中，它的目录通常是 /usr/lib/X11/fonts/misc (你可能要有超级用户的特权)。如果你想建立一个新字体目录，则你必须把它添加到字体路径上。
为把字体复制到其中的那个目录运行 mkfontdir。如果你已经在 X 中了，你应该运行 xset fp rehash 来使 X 服务器使用这个新字体。
编辑 ~/.wine/config 文件来删除给你刚安装的字体的别名。
WINE 运行可以不需要这些字体，但感观可能非常不同。还有，一些应用程序尝试装载它们定制的字体(? on the fly)(WinWord 6.0)，并且因为 WINE 仍未实现这个，它转而输出象下面这样的一些东西；
STUB: AddFontResource( SOMEFILE.FON )
你也可以转换这个文件。注意这个 .FON 文件可能不持有任何位图字体，而 fnt2bdf 在这种情况下会失败。还要注意尽管上述消息不会消失，WINE 通过使用你从 SOMEFILE.FON 提取的字体绕过(work around)问题。fnt2bdf 将只适用于 Windows 3.1 字体。它不适用于 TrueType 字体。
怎样处理 TrueType 字体? 有很多商业字体工具可以把它们转换成 Type1 格式但结果的字体是远离主流的 (stellar)。使用它们的其他方式是使用有呈现(render) TrueType 能力的字体服务器(Caldera 有一个，在 sunsite 和它的镜像的 Linux/X11/fonts 中有自由的 xfstt，如果你在 FreeBSD 上你可以使用 /usr/ports/x11-servers/Xfstt 中的 port。还有一个 xfsft，它使用 freetype 库，参见 documentation/ttfserver)。
但是，将来有可能通过 FreeType 呈现器支持固有 TrueType(hint, hint :-)
4.8.1.2. 如何向 ~/.wine/config 添加字体别名
许多 Windows 应用程序假定总是存在最初的 Windows 3.1 发布中包含的字体。缺省的 Wine 建立许多把它们映射成现存的 X 字体的别名:
Windows 字体 ...被映射成... X 字体
"MS Sans Serif" -> "-adobe-helvetica-"
"MS Serif" -> "-bitstream-charter-"
"Times New Roman" -> "-adobe-times-"
"Arial" -> "-adobe-helvetica-"
没有给 "System" 字体的别名。还有，对应用程序在运行时安装的字体不建立别名。建议的处理这个问题的方式是转换缺少的字体(参见前面)。如果证明这是不可能的，如在 TrueType 字体的情况下，你可以通过向 [fonts] 添加一个别名强迫字体映射器选择一个接近的相关 X 字体。确保 X 字体实际上存在(使用 xfontsel 工具)。
AliasN = [Windows 字体], [X 字体]
例子:
Alias0 = System, --international-, subst
Alias1 = ...
...
注释:
在序列 {0, ..., N} 中不能有间隙(gap)，否则不读在第一个间隙之后的所有别名。
通常字体映射器以下列方式把 X 字体名转换成 Windows 程序可见的字体名字:
X 字体 ...被展示为... 提取的名字
--international-... -> "International"
-adobe-helvetica-... -> "Helvetica"
-adobe-utopia-... -> "Utopia"
-misc-fixed-... -> "Fixed"
-... ->
-sony-fixed-... -> "Sony Fixed"
-... ->
注意因为 -misc-fixed- 和 -sony-fixed- 是不同的字体，Wine 修改第二个提取的名字来确保 Windows 程序可以区分它们，原因是在字体选择对话框中只出现提取的名字。
"屏蔽" 别名替换最初的提取的名字，所以在这个例子的情况下我们将有下列映射:
X 字体 ...被映射成... 提取的名字
--international-... -> "System"
"非屏蔽"别名对用户是透明的，他们不替代提取的名字。
当对一个别名可获得一个固有 X 字体的时候，Wine 丢弃这个别名。
如果你不访问在第一段落中提及的 Windows 字体，你应该尝试用非屏蔽别名替换"System"字体。 xfontsel 应用程序可向你展示 X 可获得的字体。
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/60/showart_11472.html
|
| 发表评论
查看评论(共有条评论)
我要提问
|
| |
|
|
|
