如何得知需用winetricks安装哪些组件

[duyanning]

一般安装一个windows程序之前都得先通过winetricks安装若干windows组件。
如果我现在手里有一个windows程序，我怎么才能知道我得先用winetricks装些什么东西呢？
求教。

[sgsdxzy]

用wine运行一遍，缺少什么会提示的。

[fracting]

duyanning, 如果某个程序在wine下无法开箱即用, 那么第一反应应该是给wine报一个bug, winetricks只是workaround的方式.
如果你愿意给wine报bug, 可以帮助以后的用户使用wine的时候减少一些痛苦

当不得不使用winetricks的时候, 得根据具体的终端信息进行分析, 请说一下你具体要运行什么程序.

使用wine的一个大误区,就是认为用winetricks装越多dll越好. 其实是相反的.

[sgsdxzy]

也得看的，如果缺少VCruntime，就winetricks吧……这是wine开发者知道但解决不了的问题。

[fracting]

也得看的，如果缺少VCruntime，就winetricks吧……这是wine开发者知道但解决不了的问题。

目前vcruntime部分已经在开发了
msvcr60, msvcp60, msvcr71, msvcp71, msvcr80, msvcp80, msvcr90, msvcp90, msvcr100, msvcp100, 这些都是wine实现的目标, 目前已经有很大一部分函数被实现了.

有一定折腾能力的老用户, 可以下载 mscodescan : http://winezeug.googlecode.com/svn/trunk/mscodescan.pl
通过这个脚本, 可以分析出一个应用程序依赖了哪些wine未实现的函数, 分析的结果可以作为报bug的有用信息

除了以上提到的一些dll, 还有很多dll都是wine实现的目标, 基本的原则是, 只要是 win98, win2k, winxp, win7, win server 2000, win server 2003, win server 2008等版本的操作系统默认自带的用户空间dll, 并且有用户报告说这个dll被某个程序使用到, 那么就都是wine实现的目标.

这里必须强调报bug的重要性, 就是如果一个dll或一个函数没有被已知的应用程序调用到, 那么wine开发者是不会去开发的.
一个例子是, 工行网银客户端的安装包依赖了 scarddlg.dll, 过去wine没有这个dll, 也没有人报过这个bug, 后来我报了这个bug之后wine开发者就修复了:
Bug 26026 - Installation of ICBC online bank Active Control needs scarddlg.dll
http://bugs.winehq.org/show_bug.cgi?id=26026

但是, 有少数几个目前还没有开工的, 比如mfc42和其他几个mfc dll, 还有 msvbvm60.dll等, 这几个函数虽然未实现, 但也是bug, 不过它们是known bug:
http://bugs.winehq.org/show_bug.cgi?id=657
http://bugs.winehq.org/show_bug.cgi?id=19816

这两个bug曾经被关了, 后来又reopen了, 对其中的来龙去脉感兴趣的朋友可以看看上游bugzilla中的讨论.

至于楼主关心的, 如何知道需要用winetricks安装哪些组件, 其实多给wine报bug就有经验了.
报bug的过程也是向开发者学习的过程, 当你报了一个bug之后, 开发者可能会初步诊断问题出现在哪个组件上, 然后问你如果使用winetricks安装某个dll,是不是可以workaround,
这个时候如果你尝试成功了并告诉开发者, 开发者就可以进一步确定诊断是正确的, 然后去修复问题, 同时你也可以积累到解决问题的方法.

如果脱离具体的问题具体的bug, 硬要总结出一份 "如何使用winetricks"的教程, 那就几乎是无意义的, 因为使用 winetricks 本来就是 *错的*, 只是对一些bug的workaround,
当这些bug被修复了, 使用winetricks安装相应的组件就失去意义了, 甚至还可能带来不好的后果. 而wine上游的开发是非常迅速的, 旧的workaround可能很快就过时了,
为了避免无止境的折腾, 唯一的方式就是第一时间给wine上游报bug, 从而一劳永逸地解决问题.

我看到论坛上有的朋友折腾了好多年wine却从来没有报过一个bug, 真是很痛心, 如果几年前就开始报bug了, 那现在不知有多少问题都解决了?
根据我过去的经验, 一年里给wine报100个bug的话, 会有50个被修复.

另一个统计数字是, wine的bugzilla从2000年到2008年, 增长了15000个bug, 从2008年到2012年初, 又增长了15000个bug, 可见有报bug意识的朋友是越来越多的.
不过中文Linux社区的用户报bug意识仍不强, 还需我们共同努力

[sgsdxzy]

VCrun居然在开发了？向wine工作者致敬。话说能原生支持DX就好了……
不过现实问题是，我们有时需要立刻使用wine。这时候，还是先用workaround解决问题，再提BUG汇报。winetricks是一个跳板，该用就用，事实上wine本身也是个跳板，一旦程序都支持linux了，wine不也失去了意义？我自己报过很多bug，也在wine论坛上解决过别人的一些问题，但是我觉得不能期望每个人都主动去报BUG，尤其是还有不懂英语的新手。
fracting，你觉得如果我们写一个可以自动化报告BUG的脚本，bug汇报问题会不会有改观？
另外，寻找缺失dll，还可以使用一个windows原生程序depends。

[fracting]

VCrun居然在开发了？向wine工作者致敬。话说能原生支持DX就好了……
不过现实问题是，我们有时需要立刻使用wine。这时候，还是先用workaround解决问题，再提BUG汇报。winetricks是一个跳板，该用就用，事实上wine本身也是个跳板，一旦程序都支持linux了，wine不也失去了意义？我自己报过很多bug，也在wine论坛上解决过别人的一些问题，但是我觉得不能期望每个人都主动去报BUG，尤其是还有不懂英语的新手。
fracting，你觉得如果我们写一个可以自动化报告BUG的脚本，bug汇报问题会不会有改观？
另外，寻找缺失dll，还可以使用一个windows原生程序depends。

你说的原生支持DX是指什么? wined3d是不是你说的原生支持?

我自己很少有需要用wine的时候, 我报的bug都是别人用的软件, 所以对我来说不存在 "需要立刻使用wine"的问题

你说的自动化报告BUG的脚本很有意义, wine上游有人讨论, 建议你到wine-devel邮件列表搜索过去的存档, 然后到上游跟开发者讨论

[sgsdxzy]

我在幻想微软开放DirectX……wineD3D已经很努力了，但是翻译dx指令到OpenGL只能承受性能损失。
其实我也没有要用wine的地方，我就是装了个wine，每次升级测试一下各种程序运行的怎么样，发现能运行了或者BUG修改了就很高兴，为wine的进步高兴。然后wine就束之高阁了……

[fracting]

我在幻想微软开放DirectX……wineD3D已经很努力了，但是翻译dx指令到OpenGL只能承受性能损失。
其实我也没有要用wine的地方，我就是装了个wine，每次升级测试一下各种程序运行的怎么样，发现能运行了或者BUG修改了就很高兴，为wine的进步高兴。然后wine就束之高阁了……

很高兴看到sgsdxzy兄弟也在为Wine做贡献, 希望以后可以多多交流
如果这里有其他愿意为Wine做贡献的朋友, 我的建议是多向上游报bug, 并且, 非常重要的一点, 报bug之后要主动跟进. 例如, 一个bug如果长时间没有人处理, 那么可以每一到三个月升级到最新的Wine开发版本,
重新测试一下, 把新的测试结果简单地跟开发者说一下, 比如说 "这个bug在某某版本中仍然存在", 或者, 如果bug修复了, 就提醒开发者可以把bug关闭了.

如果时间许可, 也可以主动到Wine上游的bugzilla中寻找超过三个月没人回应的新bug, 然后帮忙测试一下看看能不能重现. 如果你坚持这样做一年, 那么我可以肯定你自己报的或你关注的bug中, 只要是有效的bug, 一年内100个 bug会有50个被修复.

对于折腾能力強的用户, 还可以帮忙跑一下regression测试等等.