4.5. wine 的驱动器标签和系列号
编写：Petr Tomasek <tomasek@etf.cuni.cz>; Nov 14 1999
修改：Andreas Mohr <amohr@codeweavers.com>; 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 卷标如何? ....
HonestQiao 回复于：2005-09-13 14:19:33
4.6. Dll 加载
编写：Ove Ken <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。
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 版本不存在。[/color]
4.7. 键盘
编写：Ove Ken <ovek@winehq.com>;
(提取自 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!","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",",<",".>;","/?",
"<>;" /* 幽灵键 */
};
接着，把印在按键上的字符赋予每个扫描码。这为 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 < , . -
Ctrl Alt Spacebar AltGr Ctrl
注意第 102 个键，它是 <>; 键，在 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 提交到 <wine-patches@winehq.com>; 并加上关于它是什么的一个简要的说明。
如果你不使用 CVS，你需要做
diff -u the_backup_file_you_made windows/x11drv/keyboard.c >; layout.diff
并按上面解说的那样提交。
如果你做的正确，它将被包括到下一次 Wine 发行中，而所有使用扫描码的有问题的应用程序(尤其是远程控制应用程序)和游戏将荣幸的使用你键盘布局，并且你将不再得到这些闹心的 fixme 消息了。
祝你好运。
4.8. 处理字体
4.8.1. 字体
编写：Alex Korobka <alex@aikea.ams.sunysb.edu>;
(提取自 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 字体] <, 可选的 "屏蔽 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 可获得的字体。
Alias.. = System, ...bold font without serifs
还有，一些 Windows 应用程序要求字体而不指定这个字体的字型名字。在多数 Windows 安装中字体表以 Arial 为开始，但是 X 字体表以在 fonts.dir 中的第一行的字体为开始。所以 WINE 使用下列条目来确定首先检查哪个字体。
例子:
Default = -adobe-times-
注释:
最好使可缩放的字体家族(包括粗体和斜体)成为缺省的选择，原因是映射器检查所有可获得的字体，直到完美的匹配了要求的高度和其他属性或者到达了字体表的结束。典型的 X 安装在 ../fonts/Type1 和 ../fonts/Speedo 目录中有可缩放的字体。
4.8.1.3. 如何管理一个缓存的字体矩阵
WINE 在 ~/.wine/.cachedmetrics 文件中存储可获得的字体的详情。你可以把它复制到其他地方并向 ~/.wine/config 中的 [fonts] 段添加这个条目:
FontMetrics = <file with metrics>;
如果 WINE 检测到在 X 字体配置中的变动，它将从头重建字体矩阵并用新信息重写 ~/.wine/.cachedmetrics 。这个过程要持续一会。
4.8.1.4. 太小或太大的字体
Windows 程序可以要求 WINE 呈现有用点指定的高度的一个字体。但是，点-到-象素的比率依赖于你的显示器的真实的物理大小 (15"、17"、等...)。X 尝试着提供一个估计的比率，而可能与你的实际大小有很到不同，你可以通过向 [fonts] 段添加下列条目来选择这个比率:
Resolution = <integer value>;
一般的，更高的数给你更大的字体。尝试实验 60 - 120 范围的值。96 是好的起点。
4.8.1.5. 启动时的 "FONT_Init: failed to load ..." 消息
最常见的情况是在你的字体目录之一当中有一个破碎的 fonts.dir 文件。你需要重新运行 mkfontdir 来重建这个文件。详情参见它的手册页。如果你因为不是 root 而不能在机器上运行 mkfontdir，使用 xset -fp xxx 来删除破碎的字体路径。
4.8.2. 设置一个 TrueType 字体服务器
编写：???
(提取自 wine/documentation/ttfserver)
依从下列指示来在你的系统上设置一个 TrueType 字体服务器。
获得 freetype-1.0.full.tar.gz
阅读文档，解包，配置和安装
测试库，比如 ftview 20 /dosc/win95/fonts/times
获得 xfsft-beta1e.linux-i586
安装它并在启动时开始它，比如在一个 rc 脚本中。参见 xfs 的手册页。
依从 <williamc@dai.ed.ac.uk>; 给出的提示
我是从 http://www.dcs.ed.ac.uk/home/jec/progindex.html 得到 xfsft。我总是运行它。下面是我的 /usr/X11R6/lib/X11/fs/config:
clone-self = on
use-syslog = off
catalogue = /c/windows/fonts
error-file = /usr/X11R6/lib/X11/fs/fs-errors
default-point-size = 120
default-resolutions = 75,75,100,100
明显的，/c/windows/fonts 是我的 Win95 C: 驱动器上 Windows 字体所在的地方；对于 Win31 是 /mnt/dosC/windows/system。在 /c/windows/fonts/fonts.scale 中我有
14
arial.ttf -monotype-arial-medium-r-normal--0-0-0-0-p-0-iso8859-1
arialbd.ttf -monotype-arial-bold-r-normal--0-0-0-0-p-0-iso8859-1
arialbi.ttf -monotype-arial-bold-o-normal--0-0-0-0-p-0-iso8859-1
ariali.ttf -monotype-arial-medium-o-normal--0-0-0-0-p-0-iso8859-1
cour.ttf -monotype-courier-medium-r-normal--0-0-0-0-p-0-iso8859-1
courbd.ttf -monotype-courier-bold-r-normal--0-0-0-0-p-0-iso8859-1
courbi.ttf -monotype-courier-bold-o-normal--0-0-0-0-p-0-iso8859-1
couri.ttf -monotype-courier-medium-o-normal--0-0-0-0-p-0-iso8859-1
times.ttf -monotype-times-medium-r-normal--0-0-0-0-p-0-iso8859-1
timesbd.ttf -monotype-times-bold-r-normal--0-0-0-0-p-0-iso8859-1
timesbi.ttf -monotype-times-bold-i-normal--0-0-0-0-p-0-iso8859-1
timesi.ttf -monotype-times-medium-i-normal--0-0-0-0-p-0-iso8859-1
symbol.ttf -monotype-symbol-medium-r-normal--0-0-0-0-p-0-microsoft-symbol
wingding.ttf -microsoft-wingdings-medium-r-normal--0-0-0-0-p-0-microsoft-symbol
在 /c/windows/fonts/fonts.dir 中我有完全相同的字体。
在 /usr/X11R6/lib/X11/XF86Config 中我有
FontPath "tcp/localhost:7100"
在其他 FontPath 行的前面。就是它了! 作为一个有趣的阶段性的意外收获(by-product of course)，所有指定 Arial 的 web 页在 Netscape 中以 Arial 出现 ...
关闭 X 并重新启动(并调试你在设置这些事时做出的错误)。
测试，比如 xlsfont | grep arial
希望这有所帮助...[/color]
4.9. 在 Wine 中打印
在 Wine 中如何打印文档...
4.9.1. 打印
编写：Huw D M Davies <h.davies1@physics.ox.ac.uk>;
(提取自 wine/documentation/printing)
在 Wine 中打印可以通过两种方式。它们二者都在 alpha 阶段。
使用一个外部的 windows 3.1 打印机驱动程序。
使用内置的 Wine Postscript 驱动程序(+ ghostscript 为非 postscript 打印机生成输出)。
注意现在 WinPrinter(廉价，要求宿主计算机显式的控制打印头的哑巴打印机) 不能与它们的 Windows 打印机驱动程序一起工作。不清楚它们以后是否会。
4.9.1.1. 外部打印机驱动程序
现在只有 16 bit 驱动程序可以工作(注意这包括 win9x 驱动程序)。要使用它们，添加
printer=on
到 wine.conf (or ~/.wine/config) 的 [wine] 段。如果 CreateDC 的驱动程序参数是一个 16 bit 驱动程序，这个选项让它继续进行(proceed)。你可能还需要添加
"TTEnable" = "0" "TTOnly" = "0"
到 ~/.wine/config 的 [TrueType] 段。给驱动程序接口的这个代码在 graphics/win16drv 中。
4.9.1.2. 内置 Wine PostScript 驱动程序
通过把一个驱动程序内置到 Wine 中启用 PostScript 文件打印。参见下面的安装指导。给 PostScript 驱动程序的代码在 graphics/psdrv 中。
4.9.1.3. 缓冲池
缓冲池(Spooling)是非常原始的。wine.conf 的 [spooler] 段把一个端口 (比如，LPT1:) 映射到一个文件上或通过一个管道映射一个命令上。例如下面的一行
"LPT1:" = "foo.ps" "LPT2:" = "|lpr"
把 LPT1: 映射到文件 foo.ps 而把 LPT2: 映射到 lpr 命令。如果一个作业被发送到一个未列出的端口，则建立以这个端口为名字的文件，比如为 LPT3: 建立一个叫 LPT3: 的文件。
4.9.2. Wine PostScript 驱动程序
编写：Huw D M Davies <h.davies1@physics.ox.ac.uk>;
(提取自 wine/documentation/psdriver)
当完成了这些的过程时候就允许 Wine 生成 PostScript 文件而不需要一个外部的打印机驱动程序。应该可以通过 ghostscript 过滤输出来打印到一个非 PostScript 打印机。
4.9.2.1. 介绍
驱动程序在被建造在 Wine 当中的时候表现的如同它就是一个叫做 wineps.drv 的 DRV 文件。尽管它模仿一个 16 bit 驱动程序，但如同 win9x 驱动程序那样，它可以与 16 和 32 bit 应用程序二者一起工作。
要安装它则添加
"Wine PostScript Driver" = "WINEPS,LPT1:"
到 win.ini 的 [devices] 段和
"Wine PostScript Driver" = "WINEPS,LPT1:,15,45"
到 [PrinterPorts] 段来设置它为缺省的打印机，还要添加
"device" = "Wine PostScript Driver,WINEPS,LPT1:"
到 ~/.wine/config 的 [windows] 段和 ??? [sic]
你还需要向注册表添加特定的条目。最简单的方式是定制 documentation/psdrv.reg 的内容(见后)并使用 Winelib 程序 programs/regapi/regapi。例如，如果你把 Wine 源代码树安装在 /usr/src/wine 中，你可以使用下列命令系列:
cp /usr/src/wine/documentation/psdrv.reg ~
vi ~/psdrv.reg
编辑 psdrv.reg 的复件来适合你的要求。作为一个最小化，你必须为每个打印机指定一个 PPD 文件。
regapi setValue < ~/psdrv.reg
你需要给你想使用的(type 1 PostScript)字体的 Adobe Font Metric (AFM) 文件。你可以从 ftp: //ftp.adobe.com/pub/adobe/type/win/all/afmfiles 得到它们。目录 base17 或 base35 是开始的好地方。 注意它们只是字体矩阵而不是字体本身。现在这个驱动程序不下载额外的字体，所以你只能使用载这个打印机上存在的字体。(实际上，驱动程序可以使用在 PPD 文件中列出的任何字体，对于每个字体它都有一个 AFM 文件。如果你使用的字体未在你的打印机中或在 Ghostscript 中安装，你需要使用一些方式来把字体嵌入到打印作业中或把字体下载到打印机中。还要注意仍不能在它的 DSC 注释中正确的列出要求的字体，所以依赖于这些注释来下载正确的字体到打印机的一个打印管理器可能不能正确的工作。)
接着在你的 wine.conf (或 ~/.wine/config) 中建立 [afmdirs] 段并为每个包含你要使用的 AFM 文件的目录添加下列形式的一行:
"dir<n>;" = "/unix/path/name/"
你还需要给你的打印机的一个 PPD 文件。它描述这个打印机的特定特征。比如安装了那些字体，如何手动进纸(feed)等。Adobe 在它自己的 web 站点上有许多这种文件，看一下 ftp: //ftp.adobe.com/pub/adobe/printerdrivers/win/all/。 参见上面的信息来配置驱动程序使用这个文件。
要启用彩色打印机你需要把在 PPD 中的 *ColorDevice 条目设置为 true，否则驱动程序将生成灰度的输出。
注意你不需要在 wine.conf 的 [wine] 段中设置 printer=on，它启用通过外部打印机驱动程序的打印，而不影响内置的 PostScript 驱动驱动程序。
如果你走运的话现在就可以从 Wine 生成 PS 文件了!
我测试它使用了 win3.1 notepad/write、Winword6 、Origin4.0，和 32 bit 应用程序如 win98 wordpad、Winword97、Powerpoint2000，有着一定程度的成功 - 你应当可以弄出点什么东西，它可能不在适当的位置。
4.9.2.2. 要做/缺陷
驱动程序读 PPD 文件，但忽略所有约束并不让你指定你是否有额外的东西比如信封进纸器(feeder)。 你将在打印设置对话框中发现输入箱(bin)比一般选择更大。我只真正测试了在 hp4m6_v1.ppd 文件上的 ppd 分析。
没有 TrueType 下载。
StretchDIBits 使用 level 2 PostScript。
高级设置对话框。
许多功能的部分实现。
ps.c 正在变得混乱(messy)。
Notepad 开始文本经常比边距(margin)设置要左许多。但是 win3.1 pscript.drv (在 wine 下)也是这样。
可能更多...
如果你想得到帮助请与我联系这样我们可以避免重复。
Huw D M Davies <h.davies1@physics.ox.ac.uk>;
第 5 章. 运行 Wine
目录
5.1. 如何运行 Wine
5.2. 命令行选项
编写：John R. Sheets <jsheets@codeweavers.com>;
5.1. 如何运行 Wine
Wine 是一个非常复杂的软件，有多种方式调整如何运行它。除了非常少的例外，你可以通过配置文件激活与命令行参数相同的设置特征。本章中，我们将简要的讨论这些参数，并把它们与相应的配置变量相匹配。你可以调用 wine --help 命令来得到所有 Wine 的命令行参数的一个列表:
用法: ./wine [选项] 程序名字 [参数]
选项:
--debugmsg 名字 开启和或关闭调试消息
--desktop 几何 使用给定几何的一个桌面窗口
--display 名字 使用指定的显示器
--dll 名字 启用或停用内置的 DLL
--dosver x.xx 模仿的 DOS 版本(例如，6.22)
只在与 --winver win31 一起时有效
--help,-h 显示这个帮助信息
--language xx 设置语言(Br,Ca,Cs,Cy,Da,De,En,Eo,Es,Fi,Fr,Ga,Gd,Gv,
Hr,Hu,It,Ja,Ko,Kw,Nl,No,Pl,Pt,Sk,Sv,Ru,Wa 之一)
--managed 允许窗口管理器来管理建立的窗口
--synchronous 开启同步显示模式
--version,-v 显示 Wine 版本
--winver xxxx 模仿的版本 (win95,nt40,win31,nt2k,win98,nt351,win30,win20)
你可以按需要指定任何参数。典型的，你想使你的配置文件成为一个合理的缺省设置；在这种情况下，你可以运行 wine 而不用显式的列出任何选项。在少见的情况下，你可能想屏弃命令行上的特定参数。
在选项之后，你应该加上你希望 wine 去执行的文件的名字。如果可执行文件在配置文件的 Path 参数中的目录里，你可以简单的给出可执行文件的名字。但是，如果文件不在 Path 中，则你必须给出到可执行文件的完整路径(用 Windows 格式，而不是 UNIX 格式!)。例如，给出下列的一个 Path:
[wine]
"Path"="c:\windows;c:\windows\system;e:\;e:\test;f:\"
要运行 c:\windows\system\foo.exe 你可以用:
$ wine foo.exe
但是，你必须使用下面的命令运行文件 c:\myapps\foo.exe:
$ wine c:\myapps\foo.exe
最后，如果你想向你的 windows 应用程序传递任何参数，你可以把它们列在尾部，在可执行文件名之后。这样，要运行虚构的 foo.exe Windows 应用程序并加上它的 /advanced 模式参数，在--managed 模式下调用 Wine，你的命令将如下:
$ wine --managed foo.exe /advanced
换句话说，影响 Wine 的选项应当在 Windows 程序名字之前，而影响 Windows 程序的选项在它的后面。[/color]
5.2. 命令行选项
5.2.1. --debugmsg [通道]
Wine 仍不完善，并且许多 Windows 应用程序仍然不能在 Wine 下运行而没有 bug(但它们中的许多程序在本地 Windows 下运行也不能没有 bug!)。为了易于人们找出(track down)导致每个 bug 的原因。Wine 提供了许多用于窃听的调试通道。
每个调试通道在活跃的时候，将触发把日记消息显示到你调用 wine 的控制台上。你可以把消息从它重定向到一个文件中并在你有空时检查它。但是要事先警告你! 一些调试通道可以生成难以置信的大量日记消息。最多产的犯罪分子(offender)有 relay，它在每次调用一个 win32 函数的时候吐出(spits out)一个日记消息，win ，它跟踪 windows 消息传递，当然还有 all ，它是所有现存的调试单一通道的一个别名。对于一个复杂的应用程序，你的调试日志文件可能很容易的就达到 1 MB 和更多。依赖于你运行程序多长时间，一个 relay 经常可以生成多于 10 MB 日志消息。记录日志使 Wine 减慢许多。所以除非你真的想要日记文件，否则不要使用 --debugmsg。
在每个调试通道中，你可以进一步指定一个 message class，来过滤出不同严重程度的错误。四个消息类是: trace、fixme、warn、err。
要开启一个调试通道，使用形式 class+channel。要关闭它，使用 class-channel。要在同一个 --debugmsg 选项中列出多于一个通道，用逗号分隔它们。例如，要求在 heap 通道中的 warn 类消息，你可以项下面这样调用 wine:
$ wine --debugmsg warn+heap program_name
如果你去掉了消息类，wine 将显示这个通道的所有四类消息:
$ wine --debugmsg +heap program_name
如果你想查看除了 relay 通道的所有日志消息，你可以象下面这样去做:
$ wine --debugmsg +all,-relay program_name
下面是在 Wine 中所有调试通道和类的一个主列表。在以后的版本中可能增添(或减去)更多的通道。
all accel advapi animate aspi atom avifile bitblt
bitmap caret cdrom class clipboard clipping combo comboex
comm commctrl commdlg console crtdll cursor datetime dc
ddeml ddraw debug debugstr delayhlp dialog dinput dll
dosfs dosmem dplay driver dsound edit elfdll enhmetafile
event exec file fixup font gdi global graphics
header heap hook hotkey icmp icon imagehlp imagelist
imm int int10 int16 int17 int19 int21 int31
io ipaddress joystick key keyboard ldt listbox listview
local mci mcianim mciavi mcicda mcimidi mciwave mdi
menu message metafile midi mmaux mmio mmsys mmtime
module monthcal mpr msacm msg msvideo nativefont nonclient
ntdll odbc ole opengl pager palette pidl print
process profile progress prop propsheet psapi psdrv ras
rebar reg region relay resource richedit scroll segment
seh selector sendmsg server setupapi setupx shell snoop
sound static statusbar storage stress string syscolor system
tab tape tapi task text thread thunk timer
toolbar toolhelp tooltips trackbar treeview ttydrv tweak typelib
updown ver virtual vxd wave win win16drv win32
wing wininet winsock winspool wnet x11 x11drv
关于调试通道的详情，请查看 Wine 开发者指南。
5.2.2. --desktop [几何]
缺省的，wine 在你的正规桌面上运行应用程序。Wine 应用程序与本地 X11 应用程序混合在一起。窗口相互交叠，并且你可以在相互关系中调整它们的大小。通常，当你最小化 Wine 窗口的时候，它们缩小(collapse)成在你的桌面左下角的一个小图标，躲避你的其他非 Wine 窗口的行为。但是，如果你运行在 --managed 模式中，你的 Wine 应用程序将象其他程序那样最小化。
有时，你可能要把 Wine 窗口限制于你的桌面中小一些的一个区域中。这由 --desktop 选项来控制。 当你把这个选项传递给 wine 的时候，它将建立这么大的一个窗口并作为 Wine 桌面而不再借用正规的桌面空间。Wine 将接着把应用程序窗口放置到这个新桌面窗口中。如果你最小化这个应用程序，它将在它自己的桌面窗口的左下角图标化(iconize)。
--desktop 选项的几何信息使用标准的 X11 几何格式，例如，"640x480" 是 640 象素宽和 480 象素高的一个桌面窗口。你还可以在几何中指定桌面窗口的左上角的坐标，但你的窗口管理器可能选择屏弃你的要求。下列调用将在坐标(10, 25)打开一个新的 640 x 480 桌面窗口: $ wine --desktop 640x480+10+25 foo.exe
更常见的是，你去掉起点坐标，而只使用高度和宽度: $ wine --desktop 640x480 foo.exe
5.2.3. --display
缺省的，wine 在 $DISPLAY 环境变量中的那个 X 显示器上显示它的窗口。通常，$DISPLAY 被设置为 :0，它把所有窗口发送到你的当前宿主主机上的主视频监视器上。
要包窗口发送到在同一个系统上的一个不同的监视器上，你需要把 :0 变更为一个不同的数，例如，设置为 :1 来发送到第二监视器上。你还可以指定其他系统。如果你登录到一个系统 alpha，但想让 wine 在网络上的一个其他系统上运行，比如 beta，你可以使 $DISPLAY 的值为 beta:0。
你还可以在你的 wine 命令行使用 --display 选项声明你的显示器的值。上面的例子的命令行如下:
$ wine --display="beta:0" foo.exe
5.2.4. --dll
5.2.5. --dosver
5.2.6. --help
5.2.7. --language
5.2.8. --managed
5.2.9. --synchronous
5.2.10. --version
5.2.11. --winver
第6章. 找出和报告缺陷
6.1. 如何报告一个缺陷
编写：Gerard Patel
(提取自 wine/documentation/bugreports)
有两种方式来报告一个缺陷。其一是使用一个简单的 perl 脚本，如果你不想花很长时间来生成报告则建议你使用这种方式。它被设计来供所有人使用，从新手到高级开发者。你也可以通过困难的方式制作一个缺陷报告 -- 高级开发者可能有此偏好。
6.1.1. 简单的方式
要使这种方法工作你的计算机上必须有 perl。要找出你是否有 perl，可运行 which perl。如果它返回象 /usr/bin/perl 这样的东西，则你有可运行的 Perl。否则跳到(skip on down to)"困难方式"。如果你不确信，继续进行好了。当你运行这个脚本时，如果你没有 perl，状况是会是显而易见的。
把目录改变为 <dirs to wine>;/tools
键入 ./bug_report.pl 并给随着这个目录。
向 comp.emulators.ms-windows.wine newsgroup 发送一个消息并加上 "Nice Formatted Report" 附件。如果可能的话，上载完整的调试输出到一个 web/ftp 服务器并在你的消息中提供地址。
6.1.2. 困难的方式
一些简单的建议可以使你的缺陷报告更有用(这样更容易得到回答和修理):
尽可能多的传送信息。
这意味着我们更多的信息而不是一个简单的 "我运行 MS Word 的时候它崩溃了。你知道为什么吗?" 至少包括下列信息:
你使用的 Wine 版本(运行 wine -v)
你使用的操作系统，什么发布(如果是的话)，和什么版本
编译器和版本(运行 gcc -v)
Windows 版本，如果你安装了的话
你正在尝试运行的程序，它的版本号，和从中获取这个程序的一个 URL(如果可获取的话)
你启动 wine 的命令行
你认为有关的或有帮助的任何其他信息，如在 X 问题的情况下 X 服务器版本，libc 版本等。
加上 --debugmsg +relay 选项重新运行程序(比如，wine --debugmsg +relay sol.exe)。
如果在运行你的程序时 Wine 崩溃了，这些信息对于对我们找出导致崩溃的原因很重要。这可能输出大量(好多 MB)信息，所以最好输出到一个文件中。在 Wine-dbg>; 提示符出现的时候，键入 quit。
你可能想要尝试 +relay,+snoop 而不是 +relay，但是请注意 +snoop 是非常不稳定的并且经常比一个简单的 +relay 更早崩溃! 如果在这种情况下，则请只使用 +relay!! 在多数情况下加上 +snoop 时的缺陷报告是没用的!
要跟踪输出请使用下列命令:
所有 shell:
$ echo quit | wine -debugmsg +relay [other_options] program_name >;& filename.out;
$ tail -n 100 filename.out >; report_file
(这将把 wine 的调试信息只打印到文件接着自动退出。使用这个命令可能是个好主意，因为 wine 打印输出太多的调试信息，它们会溢出终端，吞噬 CPU。)
tcsh 和其他 csh 式样的 shell:
$ wine -debugmsg +relay [other_options] program_name |& tee filename.out;
$ tail -100 filename.out >; report_file
bash 和其他 sh 式样的 shell:
$ wine -debugmsg +relay [other_options] program_name 2>;&1 | tee filename.out;
$ tail -100 filename.out >; report_file
report_file 将包含最后一百行调试输出，包括寄存器复制和回溯(backtrace)，这是信息中最重要的部分。即使你不理解它们的意思，也请不要删除它们。
传送你的报告到新闻组 comp.emulators.ms-windows.wine
在你的帖子中，包括第1部分的所有信息，并插入在第二部分中的输出文件中的文本。如果你这样作了，你收到一些有帮助的响应的机会就会很大。
6.1.3. 问题和注释
如果读了本文档之后还有一些东西搞不明白，或者认为可以解释的更好，或者是应该包括的，请向 comp.emulators.ms-windows.wine 发帖子来让我们知道如何改进这个文档。
Wine: 目前只支持 PCs >;= i386。Winelib: 可支持其他平台，但有点困难。
