Wine 中文用户指南 （五）

第五章 问题捕捉报告 bug

内容标签：

5.1 如果有些程序仍不能运行怎么办？

5.2 如何报告一个bug

5.1 如果有些程序仍然不能运行怎么办

有些时候您已经尝试了所有的方法, 您甚至费了九牛二虎之力吃尽了苦头绞尽了脑汁，做了这令人恶心的事情，但仍然无助于使一些他妈的该死的程序在一些版本的 Wine 上工作。别泄气，我们在这里要帮助您……（换句话说，您想付出多少银子？）

5.1.1 验证您的wine配置

使用 $ wine --version 并观察其输出，确保您正在运行一个新近版本的 Wine。启动 winecfg 并检查各个设定以确保设定看上去比较正常。检查 ~/.wine/dosdevices 确保您的 c: 指向了您认为它应该指向的地方。

5.1.2 使用不同的 Windows 版本设定

在许多情况下使用不同的 Windows 版本设定 是有所助益的。

5.1.3 使用不同的启动路径

这个方法有时能有助益。请 wine prg.exe和wine x://full//path//to//prg.exe都试一试。

（译者注：请替换为您自己机器上的正确路径）

5.1.4 乱动 DLL 配置

在运行时使用 WINEDEBUG=+loaddll 来配置要载入哪些 DLL，以及载入 native的还是 built-in 版本。然后请确保您有正确的 native的DLL文件在您配置的 C:/windows/system 目录并在命令行或配置文件乱动 DLL 载入顺序设定。

5.1.5 检查您的系统环境！

仅仅一个想法：会不会是您的 Wine 创建/执行环境出错了？请确保 Wine 所依赖的包没有任何问题（gcc, glibc，X 库，OpenGL(!)，……）例如当使用“错误的”头文件给“正确的”库时，有些人会遇到奇怪的不能找到东西的失败！！！（这导致数日的 debug ，不顾一切地尝试找出为什么那个低级的功能[函数]会以那种超乎想象的方式失败……ARGH!）

5.1.6 使用不同的GUI(窗口管理器)模式

通过配置文件来命令 Wine 使用 桌面模式 ，托管模式 或朴素的或者说丑陋的 “普通”模式 三者其一。也将可能使问题有所改善。

5.1.7 检查您的应用程序！

可能您的应用程序在使用某种防拷贝措施？许多防拷贝措施当前并不能在 Wine 上工作。不过，有些可能在将来可以工作。（ CD-ROM 层并不真的是特性完全的。）

 

到 游戏拷贝世界 并尝试给您的游戏找一个象样的破解来破除该丑陋的防拷贝措施。不过,我还是希望您确实有一份该程序的合法拷贝…… :-)

5.1.8 检查您的 Wine 环境！

是否使用 Windows 分区运行会有戏剧性的影响。 配置 Wine 去做与过去所做相反的事。另外，安装 DCOM98 或 DCOM95 。这将非常有益。

5.1.9 重新配置 wine

有时候 wine 安装进程发生了改变，新版本的 Wine 依赖于这些改变。尤其是如果您的配置是很就以前创建的。重命名您原有的 ~/.wine 目录作为备份。使用适合您的 Wine 发行版的配置进程来创建新的配置。使用原有的 ~/.wine 目录里的信息作为参考。如果是源代码的 Wine 发行版，您可以您想用来配置 Wine 的用户身份来运行 tools/wineinstall 脚本。这是一个很安全的操作。以后，您可以删除新创建的 ~/.wine 目录，并把旧的那个重命名回去。（译者注：意味著您觉得新的配置不如旧配置好，想改回去。）

5.1.10 查看更多信息

很有可能有其他人已经尝试了做您要做的事，您会发现下列资源很有用：

 

•搜索 WineHQ的应用程序数据库 来查找与该程序有关的窍门、技巧。如果您的该程序的特定版本未被列于其中，您可以找一个不同版本的信息来帮助您解决问题。

 

•Frank's Corner 包含一个应用程序列表以及详细的安装、配置它们的指导。更多的帮助可以从其用户论坛得到。

 

•Google 其用处大小取决于您如何使用之。您可能会发现搜寻 Google组群 是很有用的。特别是 comp.emulators.ms-windows.wine组群。

 

•Freenode.net有一个关于 Wine 的 IRC 频道。您可以在这里聊关于 Wine 的内容，使用任何的 IRC 客户端，比如Xchat,(译者注：推荐使用mozilla或者firefox的那个插件，支持多国语文[一个对话框只限一种文字]，稳定性也不错)。您需要如下设定方可登录：server = irc.freenode.net，port = 6667，channel = #winehq

 

•如果您的程序需要 Visual Basic 运行时间环境，您可以从 此微软页面 下载之。

 

•如果您知道您缺失某个 DLL ，例如 mfc42，您可能会在 www.dll-files.com找到它。

 

•Wine的 邮件列表 也可能有所助益。特别是 wine-users 列表。Wine-devel 列表可能也是合适的。视乎您所遇到的问题的类型。如果您要张贴问题到 wine-devel 您应该准备好做一些有助于诊断该问题的工作。参阅下一节来找出如何debug，找出您的问题之源。

 

•如果所有其他的努力都失败了，也许您希望调查商业化的 wine 版本来检视您的应用程序是否被其支持。

5.1.11 Debug之！

下一步所要做的就是找到您的问题之源。可能的问题范围广泛到从只是配置的问题到 Wine 中完全没有实现的功能的问题。下一小节将描述如何 file 一个 bug 报告以及怎么开始 debug 一个崩溃。要获取更多关于使用 Wine 的 debug 设施的信息。请参阅《 Wine 开发者指南》。

5.2 如何报告一个bug

请报告所有的 bug 以及相关的信息到 Wine Bugzilla。请搜索 Bugzilla 数据库来确定您的问题是否已经被报告过。如果该 bug 已被报告过，请添加任何与已有的 bug报告 相关的信息。

5.2.1 所有bug报告

下面是一些关于如何使您的 bug报告更有价值的建议（这样您的问题更有可能被回复并被修复）：

1、尽可能多地张贴相关信息

   这以为著我们需要比“MicroSoft Office word 在任何我运行它的时候崩溃。您知道为什么吗？”更多的信息：

•您在使用 Wine 的哪一个版本（运行wine --version）

 

•您所使用的操作系统的名称，什么发行版（如果是发行版的话），以及什么版本。（例如，Linux Red Hat 7.2）。

 

•编译器及其版本（Linux 下请运行 gcc -v）。如果您并未编译 Wine，那么请告诉我们您使用的 Wine 的包的名称以及您从何处获得之。

 

•Windows版本，如果您通过 Wine 使用之。如果您没有使用 Windows，也请您告诉我们。

 

•您尝试运行的程序名，以及版本号，以及一个可以获取该程序的 URL（如果有的话）。

 

•您用来启动 Wine的确切命令行。（例如，wine "C:/Program Files/Test/program.exe"）

 

•能够重现该 bug 所需的确切操作步骤。

 

•任何其他您认为可能相关或有用的信息，比如 X 服务器版本如果有 X 问题，libc 版本，等等。

 

2、再次运行该程序，并使用 WINEDEBUG 环境变量 WINEDEBUG=+relay 选项。（例如， WINEDEBUG=+relay wine sol.exe）

 

这将输出一些可能对 debug 该程序有用的额外信息到控制台。它也会减慢程序执行速度。有些情况下，在使用了 +relay 后，bug 消失了。如果这种情况发生了，请告诉我们。

5.2.2 崩溃

如果在运行您的程序时 wine 崩溃了，拥有这一信息对我们来说相当重要；有了这些信息，我们才有机会指出是什么导致了崩溃。当然啦，这将会输出相当多（若干 MB）的信息。所以最佳的方法是将其输出到一个文件。当 Wine-dbg> 提示符出现时，键入 quit。

 

您可能想试试用 +relay,+snoop 来代替 +relay ，但是请注意，+snoop 非常不稳定而经常比只有 +relay 更早崩溃！ 如果是这样，请只使用 +relay ！！一个使用 +snoop 代码里的一个崩溃的 bug 报告在大多数情况下是没用的！您也可以启用其他参数，取决于您所研究的程序的性质和类型。参阅 wine man page获取全部参数的列表。

 

要获取回溯跟踪输出，请使用下列方法之一。

5.2.2.1简单的方法

1、此方法可使得一个完全是新手的人也能在一个崩溃事件中提交一份有关的回溯跟踪日志。

 

为了让这种方法工作，您的计算机上必须 有 Perl。要证实您是否有 perl，请运行 which perl。如果返回如 /usr/bin/perl 的信息，说明您已经装了 perl。否则，请跳到下一小节“困难的方法”。如果你不确定，就继续，当你试着运行perl脚本，它将明显的表现出来（译者注：表现出来你是否安装perl）。

 

2、切换目录到 /tools

 

3、键入 ./bug_report.pl ，然后请按其说明操作。

 

4、张贴该 bug 到 Wine Bugzilla。在张贴一个 bug 报告前，请搜索 Bugzilla数据库 来检查您的问题是否已被找到。包括您自己的关于问题的详细描述以及相关信息。粘贴“很好格式化了的报告”到提交的 bug。不要剪切、复制 bug 描述里的报告 —— 它相当的大。请保存完整的 debug 输出，以防万一啥时候 Wine 开发者需要。

5.2.2.2复杂的方法

似乎只有最后的 100 行左右的回溯跟踪对于找出程序在什么地方崩溃是必要的。为了获得那最后 100 行，我们需要干如下的事：

 

1、重定向所有 WINEDEBUG 输出到一个文件。

2、使用 tail 命令把最后 100 行分离到另一个文件。

 

这可以使用下列方法之一来完成

所有shells：

 

$ echo quit | WINEDEBUG=+relay wine [other_options] program_name >& filename.out;

$ tail -n 100 filename.out > report_file

（这将打印 wine 的 debug 信息只到文件然后自己退出，使用此命令是个不错的主意，因为 wine 打印如此之多的 debug 信息以至于如洪水泛滥般淹没了终端，如猛兽般吃掉 CPU 时间片。）

 

tch和其他类csh shells：

 

$ WINEDEBUG=+relay wine [other_options] program_name |& tee filename.out;

$ tail -n 100 filename.out > report_file

 

bash和其他类sh shells：

 

$ WINEDEBUG=+relay wine [other_options] program_name 2>&1 | tee filename.out;

$ tail -n 100 filename.out > report_file

 

report_file 现在将包含最后一百行的 debug 输出，包括注册表备份和回溯追踪，这些是最为重要的信息。请不要删除这一部分，即使您不知道它是什么意思。

 

张贴 bug 到 Wine Bugzilla。您需要粘贴第(2)部分输出的 report_file 文件，以及相关的信息来创建 bug 报告。请不要剪切、复制 bug 描述里的报告 —— 它相当的大，并将造成大量的 bug 报告。如果您这样做，您收到某种有用的回复的机率将会非常小。

 

请搜索 Bugzilla数据库 来检查是否您的问题已经被报告过。如果已经被报告过，请粘贴输出的 report_file 文件到原来的 bug 报告并添加任何其他相关的信息。