1 Qomo Linux 简介
2 新手指南
2.1 前言
2.2 准备
2.3 安装
2.4 适配
2.5 使用
3 安装手册
3.1 安装总览
3.2 获取Qomo
3.3 硬盘安装
3.4 LiveCD/DVD试用
3.5 LiveCD/DVD安装
3.6 U盘安装
3.7 虚拟机安装
3.8 双系统
3.9 网络安装
4 用户手册
4.1 Qomo 1.1用户手册
4.2 使用DOSBox
4.3 桌面应用程序
4.4 Windows应用移植
4.5 文件和资源管理(P22)
4.6 系统和桌面设置(SP2)
4.7 术语表
5 开发手册
5.1 命令行
5.1.1 Shell简介
5.1.2 Shell编程基础
5.1.3 如何进入命令行界面
5.1.4 改变登录方式
5.1.5 Vim
5.1.6 FTP
5.1.7 RPM
5.1.8 Telnet
5.1.9 安装应用软件
5.1.10 常用文件系统管理命令
5.1.11 文件系统
5.1.12 管道
5.1.13 维护文件系统
5.2 KDE
5.2.1 KDE加速
5.3 SSH
5.4 Git
5.4.1 起步
5.4.2 基础
5.4.3 分支
5.4.4 服务器上的 Git
5.4.5 分布式 git(上)
5.4.6 分布式 git(下)
5.4.7 git 工具(上)
5.4.8 git 工具(下)
5.4.9 自定义 git(上)
5.4.10 自定义 git(下)
5.4.11 git 与其它系统
5.4.12 git 内部原理(上)
5.4.13 git 内部原理(下)
5.4.14 Git简易教程
5.5 其他
5.5.1 Bash
6 历史版本
6.1 Qomo Linux 0.7
6.2 Qomo Linux 0.8
6.3 Qomo Linux 1.0
6.4 Qomo Linux 1.1.0
6.5 Qomo Linux 1.2.0
6.6 Qomo Linux 2.0
6.7 Qomo Linux 3.0
6.8 Qomo Linux 3.1
6.9 Qomo Linux 4.0 Beta
6.10 Qomo Linux 4.0
6.11 Qomo Linux 4.1
6.12 Qomo Linux 4.2圣诞版
6.13 Qomo Linux 4.5
6.14 Qomo Linux 4.8七夕版(增加了64位版)

Windows应用移植

2016-11-13 00:16:41
sjchenkan
575
最后编辑:sjchenkan 于 2016-11-13 00:47:36

Window 应用移植

目录

Linux下移植Windows应用参考文档

本文档主要讨论Windows应用程序向Linux下移植的方法和案例,全文分三部分,第一部分主要介绍常见类型的移植需求,对每一类需求给出了移 植方法和建议;第二部分针对各种移植方法所涉及的知识点、实施过程和注意事项进行了收集和汇总;第三部分通过一些实际案例,具体说明了在实际项目中如何针 对Windows下待移植应用进行考察和分析,并根据用户对性能、稳定性、易用性等方面的需求在最少研发成本下选择恰当的移植方法。本文较少涉及整体解决 方案,例如数据中心或者网站的改造和迁移,更多的讨论内容集中在代码和程序本身。

第一部分 常见移植需求和方法介绍

随着Linux自身的日渐成熟和各大IT厂商的持续投入,在服务器端、桌面端以及通讯和消费电子产品上越来越多的基于Linux操作系统的底层解决 方案和上层应用正在被广大用户所接受,尽快将各类Windows应用软件向Linux平台移植正具有越来越迫切的重要性。对于操作系统厂商来说,1. 更多Linux上的成熟应有利于其操作系统的更全面的普及 2.实际项目的实施中,要取代Windows必须解决原系统中已有应用在Linux下的兼容 3. Linux内核和系统级应用已经日臻完善,各领域大量的专业应用的迁移成为工作焦点; 对于ISV开发商来说,1. 随着政府和企业正版化的实施以及Windows下病毒的日益增多,越来越多的客户选择了Linux作为其工作平台 2. 很多应用尤其是网络应用在Linux下性能更加出色3. 自己定制操作系统大大降低了系统的成本,并提高了系统的灵活性和可维护性 4.具有跨平台版本的产品更具市场竞争力。因此移植Windows应用对于Linux操作系统厂商和第三方软件开发商都具有重要意义。
实际在一个较为复杂应用成功移植的过程中,往往需要操作系统厂商和应用软件开发商的共同参与,操作系统厂商提供系统全面的移植方案和Linux平台开发的 支持与培训,而应用程序自身的业务逻辑和测试流程则更适合由应用开发商来承担的。在移植过程中,双方经常需要互相共享彼此的部分核心代码,从而更准确更快 捷的定位移植过程中出现的问题的原因所在。
从移植的角度看Windows下的应用,我们通常更关注其开发所使用的工具和语言,由此将传统的Windows应用大致分为下类别:

  • C/C++(包括使用VC,BCB等IDE开发环境)
  • RAD (包括Delphi,VB,PB等快速开发工具)
  • Java(包括各类J2EE应用)/.NET
  • HTML/Javascript
  • 其他跨平台脚本语言(包括perl, php,python等)


移植方法大致上分三类:代码或二进制文件都无法重用的,只能根据原设计重写全部或大部分代码;借助部分跨平台开发环境或跨平 台设计,只需要重写部分底层相关模块或修改部分代码实现;与系统底层耦合疏松,并且对效率没有苛刻限制的应用可以通过一些虚拟运行环境或模拟技术重用二进 制可执行文件。 下面将对每一类开发工具开发的程序在面临移植时,可能选择的方法和工具进行逐一的介绍。

使用C/C++开发的代码,由于形式多样,移植的方法较为多样。与操作系统底层结合紧密的程序更难以移植,如果涉及的代码运行在ring0 级别,那么几乎只能重写,对于Windows 和 Linux操作系统的重要系统调用的实现的差异和对应API将在第二部分中详细介绍。另外,花费一些时间去熟悉和理解Linux上同一级别类似的开发库有 助于应用能够在较短时间内重新构建,例如MFC与wxWindows;winpcap与libpcap等。如果使用了跨平台的开发库(如Qt,Ace), 而较少直接使用系统调用或API,并且在设计过程中采用了有助于逻辑结构和底层实现分离的设计模式时,需要重新实现的代码将会显著减少。

对于使用Visual C++ IDE环境的开发者可以尝试使用Kdevelop和QDevelop。类似Visual Studio,提供了代码编辑、UI设计、编译调试、项目管理、代码模板等功能。功能完善角度上,Kdevelop更为强大,稳定性和简洁性上 QDevelop更加实用。二者都是免费开源软件,分别可以在:
http://www.kdevelop.org/
http://biord-software.org/index.php
获得安装程序和源代码。
使用Borland C++ Builder的开发人员可以在Linux下找到BCB的Linux版本kylix。类似Delphi和BCB,kylix也提供了Object Pascal和C++两种开发语言及其对应的两套开发环境。由于同出自Borland公司之手,kylix的界面与使用习惯和Windows版本的 delphi/BCB基本一致,与Windows版本的最大的差异来自于kylix只提供一套CLX控件,而的VCL以及ActiveX控件在Linux 下不再可用。因此对于大量使用VCL控件的应用,移植过程中的主要工作可能集中在工程改造和替换控件上。Kylix的安装及使用过程在本文第二部分将有更 加详细的介绍。
对于大多数C/C++生成的PE格式的Windows本地应用程序,还有一个较为便捷的移植方式,通过一个名为wine的模拟器来运行。尽管Wine自称 是Wine Is Not an Emulator的缩写,其的功能及实现原理与一般的模拟器并没有本质的差别。由于Windows的执行文件格式并不能被Linux识别,并且与 linux实质上放弃了x86的分段特性不同,Windows完全利用了x86的分段功能,此外大量的windows dll提供了成百上千的API让应用程序使用,因此要在Linux下运行Windows可执行程序是很困难的,而wine基本实现了这一目标。由于都使用 相同的x86硬件架构,二进制机器代码本身是一致的,因此并不需要类似全虚拟化的代码指令翻译工作,Wine通过解析PE文件后加载Windows应用程 序、借助内核提供的LDT支持提供分段功能、使用linux系统调用模拟几乎所有Windows API行为来实现Windows应用程序在Linux环境中的正确运行,通常使用wine appname.exe来运行一个windows可执行程序,而通过注册可执行文件格式,甚至可以将.exe程序赋予可执行权限后直接运行。使用wine 来运行windows程序不是万能的,首先运行在ring0级别的驱动性质的程序和动态库无法使用,wine并不能模拟windows内核的API和数据 结构,尽管wine参照官方SDK文档重新实现了ntdll,kernl32,user32,gdi32等windows核心动态库,但是并未实现 windows ddk中的API。其次,由于wine的实现基本参照ms的官方文档,只关注输入、输出参数、返回值以及功能,并不能保证和微软的实现在逻辑上一致,因此 运行过程中表现出和在windows环境中界面、行为、逻辑的差异,甚至产生崩溃、异常的情况也并不少见。这种情况下,多数时候需要结合应用程序代码本身 和wine代码去调试、解决。最后,由于经过了一层转换,大多数情况下使用wine来运行Windows可执行程序,在相同硬件上,要比直接在 Windows环境中运行慢,对于效率要求较为严格的程序来说,是否能、以及如何优化到可以接受的程度是移植工作前的需求分析和可行性研究过程中要考虑和 验证的重点。另外,对于使用wine移植的应用程序,在软件的Windows版本更新时,会受到需要重新测试、开发、调试的困扰。本文在第二部分会详细讲 解wine的大部分子系统的实现,第三部分会结合一些案例说明使用wine移植windows应用程序的调试过程。
wine还提供了一个叫winelib的库,用来直接编译windows源代码,生成本地可执行程序,一般是appname.exe.so,需要注意的是,即使生成的是本地可执行程序,仍然需要wine的大多数动态库和wineserver的支持。

对于使用RAD开发的应用程序,主要的解决思路是在Linux下使用类似的开发工具进行开发,这类开发工具通常屏蔽了操作系统底层细节的差异。和 C/C++开发人员不同,RAD开发人员多数时候并不关心操作系统底层API和相关架构,而更专注于程序逻辑实现本身,因此,使用Linux下的RAD开 发工具可以缩短开发人员由于更换操作系统平台而需要的学习时间,减少开发过程中由于不熟悉系统带来的潜在问题,从而加快移植进度,节约成本。此外,对于类 似PowerBuilder等开发工具开发的数据库应用来说,使用wine是非常值得尝试的选择,这种情况下的决定性因素往往在于需要找到对应数据库的 unixODBC驱动,从而可以在wine环境中配置使用。如果不能找到,那么可能需要考虑修改windows源代码,并使用某种有unixODBC驱动 的数据库,从而在wine环境中能正确运行。
Java应用程序大多数时候是可以做到一次编写到处运行的,但是使用了JNI的程序例外,需要重写本地接口的动态库,具体方法和Windows下非常类 似,将在下一部分详细介绍。另外,Java的IDE在Linux下也有不少,目前最常用的是eclipse, 较早版本的还有JBuilder等。
.Net可执行程序虽然通常扩展名也是.exe或.dll,但是和windows本地应用程序完全不同,是无法直接通过wine来运行的。.Net程序更 类似java,编译后是中间代码,第一次运行时才会生成本地可执行二进制。运行.Net应用程序是通过一个(或者叫一组)叫mono的工具。和wine类 似Mono提供了运行环境和编译环境,运行环境用于直接解释运行.Net的可执行程序,而编译环境则提供了一整套流程用于C#源代码的编译。目前Mono 项目已经成熟了许多,效率也有大幅提升,mono还提供了例如xsp,mod_mono apache模块等内容,对于类似ASP.NET的服务器端应用的移植来说,已经几乎完全可以胜任。
B/S架构的应用程序的移植根据开发时是否作了跨浏览器准备以及开发过程中测试浏览器的类型选择不同,有很大的差别。几年前firefox、webkit 还很少有人使用的时候,大多数的b/s程序只基于 ie开发和测试,而6.0以及之前版本的IE浏览器dom模型实现与w3c的符合性并不好,加上过多纵容了非标准的html以及css代码,导致多数 B/S应用在非IE浏览器中都会存在问题。而本质上是windows本地可执行代码的ActiveX控件更使许多关键功能无法支持。因此,移植B/S应用 (这里主要针对ie向Linux下的firefox的移植)的主要工作有三处,1. 修改页面排版相关代码,使得firefox下的界面与原始设计一致。2. javascript代码的修改与调试,firefox下javascript无论在语法上、内建函数上、还是重要功能和事件模型实现方式上都和IE的 jscript有着不少的差异。3. 使用firefox提供的插件机制开发本地插件代替ActiveX控件。这些差异以及修改方法、包括插件开发方式在第二部分有较为详细的描述。
Perl,Php,Python等解释性跨平台语言很好的封装了操作系统平台的差异,这类应用的移植更多的时间集中在环境搭建以及测试上。当然这类语言也 提供了直接或间接的接口调用操作系统API或本地动态库,这种情况下,只需要对代码稍作修改,或类似JNI的移植重新实现一个Linux系统下的动态库并 加以封装。

第二部分 移植知识汇总

Wine的使用

1.1. Windows 和 Linux 不同的程序是为不同的操作系统设计的,大多数情况下不能在其他系统上运行。
例如,Windows程序,不能在Linux上运行,因为它们包含有Linux 系统不能理解的指令,除非它们在Windows环境下被翻译。同理,Linux程序,也不能在Windows操作系统下运行,因为Windows不能解释其所有的指令。
这 个情况呈现出一个基础的问题,在那些想要同时想要在Windows和Linux下运行软件的人面前。通常的解决方法是在同一台计算机上同时安装这两套系 统,这被称为“双(重)启动”。当需要Windows程序时,使用者重启并进入Windows来执行之。当需要Linux程序时,使用者重启并进入 Linux。这个方法呈现出巨大的困难:不仅是使用者必须经受经常重启的折磨,而且两个平台的程序不能同时运行。
在系统上安装Windows也增加了额外的负担:该软件昂贵,需要独立的磁盘分区,并不能阅读多数的文件系统,使得在各个系统间共享数据变得困难。
1.2 wine的版本
1.2.1 从WineHQ来的Wine
Wine是一个开源项目,有许多不同版本的Wine,因此,您可以从中选择。
标准的Wine版本来自于断断续续的发布(大概一月一次),可以从互联网上
下载预先打包好的二进制形式和现成的用来编译的源代码形式。
作为一个选择,通过使用在CVS服务器上的最近的可用的源代码,您可以
安装Wine的开发版。

2.1 wine安装方法
一旦您已经决定 Wine 正合适您的需求,下一步是决定您想怎样安装之。有3种方法安装来自 WineHQ 的 Wine ,每一种都有其优点和缺点。
2.1.1 从一个包安装
迄今为止最为容易的安装 Wine 的方法是使用预先打包好的 Wine 的版本。这个包包含可以运行的二进制文件,它们特别地为您的发行版而编译。通常它们的功能性和完整性已被打包者测试过。
包是推荐的安装 Wine 的方法。在www.winehq.org和其他地方在官方发行版仓库都能发现 Wine 包。然而它们可能有时是过时的,取决于您的发行版。
包也易于升级,有些发行版可以无缝地升级 Wine ,只需几次点击。从源代码包创建您自己的可安装的二进制包也是可能的。
2.1.2 从一个源归档安装
有时 Wine 包并不完全符合您的需求。可能它们在您的架构或发行版上不可用,或者您需要使用您自己的编译器优化选项来创建 Wine ,并关闭一些设置。或者可能您需要在编译之前修改源代码特定的部分。
作为一个开源项目,您可以对 Wine源代码自由地做上述之事,它将随每个 Wine版本发布。这个安装方法可以通过下载一个 Wine源归档并从命令行编译来完成。
2.2 从一个包安装wine
2.2.1 安装一个全新的包
在一个全新的系统上安装一个包是非常直截了当的。简单地下载并安装包使用任何您的发行版提供的工具。通常在安装之前不需要明确地移除旧版本,因为现代的 Linux 发行版应该能自动地升级并替换之。
如果你从源代码安装了 Wine, 但是, 在安装一个 Wine 包之前,您应该移除它。
2.2.2 不同的发行版
Wine 在巨大数量的不同的 Linux 发行版上工作,也能在其他 类Unix 系统,比如 Solaris 和 FreeBSD, 每一种都有其特定的安装和管理包的方法。但是,幸运地,相同的基本思想对所有它们的都起作用,而安装 Wine 应该不比安装任何其他软件更难,不管您用的是什么发行版。卸载 Wine 包也很简单,并且在现代的 Linux 发布里通常是通过与安装包相同的易用界面来完成。
2.3 从源代码安装wine
2.3.1 获取创建依赖关系
在 Wine 运行时,使用许多开源的库。虽然 Wine 并不严格地依赖于这些库而且能够在没有
它们中的大多数时编译,但是在编译时拥有这些库,Wine的功能性将得到提升。
在过去,许多用户问题是由于人们在从源创建 Wine 时,没有必要的开发库所致;由于这个
以及其他的原因,我们高度推荐通过二进制包安装,或者通过创建能够自动满足其依赖关系
的源代码包安装。
如果您希望手动安装创建依赖关系,有许多种方法可以检视您是否缺少一些有用的开发库。
最为直接的方法是在您编译 Wine 之前,查看 configure 程序的输出,以确定任何重要的东西是否缺少。如果是那样,简单地安装缺少的东西,然后在编译之前重新运行 configure。
2.3.2 编译wine
一旦您已经安装了您需要的创建依赖关系,您已经做好了编译包的准备。在终端窗口,在导航到 Wine 源代码树后,运行下面的命令:
$ ./configure
# make depend
# make
# make install
末尾的命令要求 root 权限。尽管您决不应该以 root 运行 Wine ,您将需要以这样的方式安装 Wine。
2.3.3 卸载从源代码安装的 Wine
要卸载从源代码安装的 Wine, 您需要再一次在终端里导航到您用来安装 Wine 的同一个目录。然后运行下面的命令:
# make uninstall
这个命令将需要 root 权限,并且应该从您系统上移除所有的 Wine 二进制文件。但是,它将不移除您的 Wine配置 以及位于您用户的 home目录 (主目录)里的应用程序,所以您可以自由地安装另一版本的 Wine 或者手动地删除该配置。
配置wine
最 最通常的配置变更可以通过使用 Winecfg 工具来达成。我们将经历一个简单的,一步一步的介绍,这个介绍是对 Winecfg 的介绍。并概要的给出可用的设置选项。在下一节我们将看到您可以通过使用 regedit 做出更高级的变更,也提供一个完全的参考给所有的 Wine 配置设定。最后,一些您可能想要配置的东西超出了 Winecfg 和 regedit 的范围,我们将看看它们。
3.1 使用winecfg
在 过去,Wine 使用一个特殊的配置文件,它能在 ~/.wine/config 中找到。如果您仍然使用一个提及这个文件的 Wine 的版本 (即2005年六月以前的版本)。您应该在您要做任何其他事情之前进行升级。所有的设定现在都直接地存储于注册表中并且在 Wine 启动时被 Wine 存取。
Winecfg 应该已经与 Wine 程序的其他部分被一齐安装到了您的计算机上。如果您不能指出如何启动它,尝试运行命令:
$ /usr/local/bin/winecfg
或者可能仅仅是:$ winecfg
当该程序启动了,您将注意到在窗口的上方有如下的一排标签:
•Applications
•Libraries
•Graphics
•Appearance
•Drives
•Audio
•About
在 Applications (意为:应用程序) 和 Libraries (意为:库) 标签里更改设定将最能对运行一个程序产生影响。其他的设定偏重于使 Wine 本身以您希望的方式运转。
3.1.1 应用程序设定
Wine 有能力模仿不同版本的 Windows 的运转。一般地,最大的区别是 Wine 以 Win9x版本 或 NT版本 方式运转。一些应用程序要求特定的运转模式以运行,而更改此设置可能使一个运行有错误的应用程序工作。最近,Wine的默认 Windows 版本变成了 Windows 2000。人所共知,如果您选择 Windows 98 ,许多应用程序将工作得好些。
在该标签内您将注意到有一个 Default Settings (默认设定)入口。如果您选择之,您将看见给所有应用程序的当前默认 Windows 版本。一个问题多多的应用程序最好在默认设定之外单独地配置。要这么做:
1 点击 Add application (添加应用程序)按钮。
2 浏览直到您定位了该 .exe 文件。
3 当它被添加后您可以选择特定的 Windows 版本,Wine 将为该程序模拟之。
3.1.2 库设定
同样,一些应用程序需要特定的库,以便运行。Wine重新制造了 Windows 系统库--即所谓的 本地(原生)DLL 和完全地定制版本设计来以完全相同的方式作用而不需要来自微软的许可证。
Wine 的内建版本有许多广为人知的不足,但是许多情况下其功能性是足够的。仅使用 内建的 DLL 确保您的系统是 非微软的。
但是,Wine有能力载入 本地(原生) Windows DLL。
3.1.2.1 DLL Overrides
不是总能使用 内建DLL 运行一个应用程序的。有时 本地(原生)DLL 简单地工作得更好。
在 你已定位了一个在一个 Windows 系统上的 本地(原生)DLL 后,您将需要把它放在一个合适的地方以便 Wine 找到它,而后配置使它被使用。一般说来您需要把它放在一个您已经配置为 c:\windows\system 的目录 (获取更多信息在 驱动 节)。有四个 DLL 您应该决不/从不尝试使用 本地(原生)版本:kernel32.dll, gdi32.dll, user32.dll, 和 ntdll.dll。
这些库要求低级的 Windows 内核存取而其不存在于 Wine 中。
保持它在您脑海中,一旦您已经拷贝了 DLL 您需要告诉 Wine 尝试使用之。您可以配置 Wine 来在 本地(原生)DLL 和 内建的DLL 之间选择在两个不同的级别。如果您有 Default Settings 选择在 Applications 标签,您所做的改变将影响所有的应用程序。或者,您可以通过在Applications 标签里改写全局设定在“每一个应用程序” 级别。
要添加 并override FOO.DLL,键入“FOO”在标有 New override for library标签的盒子里:并点击 Add按钮。要改变 DLL 如何运转,选择它在 Existing overrides:盒子和选择 Edit。您也可以选择 native only,builtin only,或全部关闭。
3.1.2.2 关于系统 DLL 的助记
Wine 团队已经决定要创建 假的 DLL 文件来欺骗许多程序,这些程序要检查文件是否存在以决定某功能是否可用(比如 Wincosk 和 TCP/IP 网络)。如果这对你来说是一个问题,您可以创建空文件于配置的 c:\windows\system目录来使得程序 认为它在那里,而 Wine 的 内建DLL 将被载入当程序真的需要它时。(很不幸,tools/wininstall自己并不创建这些空文件。)
应用程序有时也从物理文件检查版本资源(例如,决定 DirectX 的版本)。空文件在这种情况下不起作用,有必要安装完全本的资源的文件。这个问题正在解决中。与此同时,您仍然需要抓一些真的 DLL 文件来愚弄这些应用程序。
当 然有 Wine 当前没有很好(或根本没有)实现的 DLL。如果您没有真的 Windows 可以从中拷贝必要的 DLL,您总是可以从一个 Windows DLL 归档站点得到一些,这些站点可以从 Internet 搜索引擎搜索得到。请确保遵守任何您抓到的 DLL 的许可证;有些是可再分发的,而有些不是。
3.1.2.3 缺失的 DLL
万一 Wine 抱怨缺失一个 DLL,您应该检查是否该文件为一个 公共可用DLL 或一个属于您的程序的 客户DLL(通过在 Internet 上搜索其名字)。在您已定位该 DLL 后,您需要确保 Wine 能够使用之。DLL 通常在下述位置被载入,并依从下述顺序:
1、程序被启动的目录。
2、当前目录。
3、Windows system 目录。
4、Windows 目录。 (即 Windows 根目录)
5、PATH 变量目录。
简 单地说:要不把要求的 DLL 放到您的程序目录,要不就放到 Windows system 目录。另外,如果可能,您可能不应该使用 基于NT 的 本地(原生)DLL,因为 Wine 的 NT API 支持比它的 Win9x API 支持弱(可能导致比没有 Windows 配置更差的与 NT DLL 的兼容性)。
3.1.3 图形设定
有基本地五个不同的图形设定您可以配置。对大多数人来说默认值就很好。第一个是 “screen colour depth”,它代表著能够被显示在屏幕上的颜色的数目。老一点的图形卡曾经难以显示一系列完整色深,对其使用一特定的“8-bit”显示是能有用的。现 代的视频卡,不论什么名字,只要有超过 8MB 显存,使用完全的 24-bit或 32-bit色深是没问题的。
下面一些设定主要影响游戏,并 有些明显。您能够阻止鼠标从一个 DirectX 程序(例如,一个游戏)的窗口中离开,其默认值是那个 box 被勾选。有许多的原因使得您可能想那样做,至少包括:如果把鼠标配置为局限在一个更小的区域,玩游戏会更加容易;另一个打开此选项的另一个原因,是为了更 精确的控制鼠标。Wine偏移鼠标的位置,来模拟 Windows 鼠标的运作方式 。相似地,“desktop double buffering”它允许更平滑的屏幕刷新,游戏可以从中获益,默认值是打开之。作为交换,内存使用量将增加。
您可能会发现Emulate a virtual desktop(模拟一个虚拟桌面)非常有用。在这个情况下,所有程序将在一个独立的窗口中运行。您可能会发现这个非常有用,特别是在测试有错误的游戏 (可能不成功地)改变屏幕分辨率时。限制他们在一个窗口中能允许对他们的更多控制以减少实际可能的费用。您可能想要尝试的分辨率大小是 640x480 (默认值) 或 800x600。
最后,您可以配置一些 Direct3D 设定。在大多部分这些设定是自动探测的,但是您可以强制它们以一个特定的方式运行。有些游戏探测潜在的系统来检视它是否支持特殊的某些特性。通过关闭这些 Wine 将不会报告能力用一个某一方式呈报游戏。这将导致游戏运行得更快以图形的质量的费用或者图形或游戏根本不能运行。
3.1.4 驱动器设定
Windows 要求一个相当严格的启动器配置,Wine 模拟之。大多数人熟悉该标准的符号:“A:”驱动器代表软盘,“C:”驱动器代表主系统盘,等等。Wine 使用相同的概念并将这些驱动器映射到当前的本地文件系统上。
Wine 的驱动器配置相对地简单。在 Winecfg 的 Drives 标签您将看见用来添加和移除可用的驱动器的按钮。一个新的 entry 将会被制作并且一个默认的驱动器 mapping 将会出现。您可以在 Path: 框里改变这些驱动器指向哪里。如果您不确定具体的路径,您可以选择“Browse”并寻找之。移除一个驱动器就简单得只需要选择之并点击 “Remove”。
Winecfg 能自动地探测您系统上可用的驱动器。推荐您在尝试手动配置驱动器前使用之。简单地点击“Autodetect”按钮来使 Wine 寻找您系统上的驱动器。
也许您有兴趣在 Winecfg 之外配置您的驱动器设定。幸运地,这种情况也很简单。所有的驱动器设定居于一个特殊的目录~/.wine/dosdevices。每个“驱动器”简单地是一个到其真实所在的连接。Wine 自动地建立2个驱动其在您首次运行它的时候:
$ ls -la ~/.wine/dosdevices/ lrwxrwxrwx 1 wineuser wineuser 10 Jul 23 15:12 c: -> ../drive_c
lrwxrwxrwx 1 wineuser wineuser 1 Jul 23 15:12 z: -> /
要 添加其他驱动器,例如您的 CD-ROM, 创建如下连接即可: $ ln -s /mnt/cdrom ~/.wine/dosdevices/d: 请注意给连接使用的 DOS-风格 命名习惯——其格式是一个字母后接一个冒号,诸如“a:”。所以如果您连接您的 C: 驱动器指向 ~/.wine/drive_c,您可以认为说 c:\windows\system 即是说 ~/.wine/drive_c/windows/system 的意思。
3.1.5 音频设定
Wine 可以使用几种不同的音频子系统工作,您可以在“Audio”标签下选择他们。“Autodetect”按钮能为你把它全部配置出来,或者您可以手动地选择 一个驱动。老一点的Linux 发行版使用 2.4 内核或更早的版本典型地使用“OSS”。新一点的 2.6 内核已经转换到了“ALSA”。如果您正在使用KDE,不管使用何种内核,您或许也可以使用“aRts”,如果您正在使用GNOME您或许也可以使用 “EsounD”。OSS 和 ALSA 声音驱动得到了最充分的测试,所以如果可能的话,推荐您坚持使用它们。如果您需要使用“Jack”或“NAS”您可能已经知道为什么了。
DirectSound 设定主要被游戏使用。您可以选择什么级别的硬件加速您想要,但是对大多数人来说“Full”不错。
3.1.6 外观
Wine 能够载入 Windows 的主题,如果您有可用的主题。
当 然,这肯定不是使用 Wine 或者应用程序所必须的,它确实能允许您定制一个程序的外观和感观。Wine 支持新一点的 MSStyles 型主题。不像老一点的 Windows Plus!型主题,uxthem引擎支持特殊格式的 .msstyles 文件,这种 .msstyles 文件能改变所有的 Windows控件 的主题。
3.2 使用注册表和Regedit
您在 Winecfg 里做的所有设定变更,除了驱动器设定,基本上都存储在注册表里。在 Windows 里,这是一个应用程序和操作系统配置的中央存储仓库。同样地,Wine 实现一个注册表,而一些在 Winecfg 里找不到的设定能在注册表里变更。
现 在,Wine 本身使用注册表来存储设定的事实已引起争议。有的人争辩道这样它就太像 Windows 了。相反地,有很多事物需要考虑。首先,不可能避免实现一个注册表,很简单,因为应用程序期望能存储其设定于那里。以便 Wine 存储和读取在一个单独配置文件里的设定将会要求一套独立的代码来基本上做 Win32 API 所做的,而这些 Wine 已经实现。最后,不像 Windows, Wine 的注册表是用纯文本写成的,并且能使用您喜爱的文本编辑器进行修改。
3.2.1 注册表结构
Windows 的注册表是一个精心制作的树形结构,连大多数 Windows 程序员也不完全明白它是怎样展开的,它有著不同的“ hives”和大量的连接在其中;要完全覆盖它的内容超出了本文档的范畴。但是您现在就可能需要了解如下的注册表键:
HKEY_LOCAL_MACHINE
这个基本的根键(在 Win9x 里它被存储于隐藏文件 system.dat 里)包含所有与当前 Windows 安装有关系的东西。它通常被简写为 HKLM 。
HKEY_USERS
这个基本的根键(在 Win9x 里它被存储于隐藏文件 user.dat 里)包含该安装的每一个用户的配置信息。
HKEY_CLASSES_ROOT
它是一个到 HKEY_LOCAL_MACHINE\Software\Classes 的连接。它包含一些数据,它们描述一些事物,诸如文件关联,OLE 文档处理器,以及 COM 类。
HKEY_CURRENT_USER
它是一个到 HKEY_USERS\your_username 的连接。例如,您的个人配置。
3.2.2 注册表文件
现在,您可能想知道的是如何翻译成 Wine 的结构。在上面描述的注册表布局事实上存在于三个不同的文件,这些文件存在于每个用户的 ~/.wine 目录中。
system.reg
这个文件包含 HKEY_LOCAL_MACHINE 。
user.reg
这个文件包含 HKEY_CURRENT_USER 。
userdef.reg
这个文件包含 HKEY_USERS\.Default (例如,默认用户的设定)
这 些文件在您首次使用 Wine 时被 wineprefixcreate 自动地创建。一系列的全局设定被存储于 c:\windows\inf\wine.inf 并且被 rundll32.exe 程序处理。当您首次运行 Wine 时 wine.inf 被处理来组装初始的注册表。要获取更详细的信息,您可以查看wineprefixcreate 脚本来检视这一切是如何完成的。在升级 Wine 后,wineprefixcreate 也可以用来升级默认的注册表键。
正如我们所提到的,您可以编辑那些 .reg 文件,使用任意您想要的文本编辑器。请确保您这么做的时候 Wine 不在运行,否则所有的变更将丢失。
3.2.3 使用Regedit
要 读取并变更注册表,一个简单一点的方法是使用工具——regedit。类似于它所代替的 Windows 程序,regedit 用来提供一个系统级别的注册表视图,包含所有的键。简单地运行 regedit 它就应该弹出来。您将会立即注意到在文本文件中显示得像密码般的键被组织得井井有条,层次分明。
在注册表中导航,点击左边的键名,并深入下一层。 要删除一个键,点击之并从 Edit目录选择“Delete”。要添加一个键或值,定位您想要放它的地方并从Edit目录选择选择“New”。同样地,您修改一个存在的键或值,在右 手边的窗格里高亮之,并从Edit目录选择选择“Modify”。
另一个达到同样效果的方法是右键单击键或值。
可能对 Wine 使用者来说,比较感兴趣的是存储于 HKEY_CURRENT_USER\Software\Wine 里的设定。大多数您在 Winecfg 里变更的设定存储于此目录的此区域。
3.3
3.3.1 串口和并口

串口和并口配置非常类似于驱动器配置 —— 简单地创建一个符号连接在 ~/.wine/dosdevices 使用设备的名字。

Windows 串口按照这么一个习惯命名:一个词“com”后面接一个数字。比如 com1,com2, 等等。
类似地,并口使用“lpt”后接数字。比如 lpt1。

您应该直接地连接它们到相应的 Unix 设备,诸如 /dev/ttyS0 和 /dev/lp0 。要配置一个串口和一个并口,运行下列命令:
ln -s /dev/ttyS0 com1
ln -s /dev/lp0 lpt1

3.3.2 网络共享
Windows 共享能被映射到 unc/ 目录里以便任何尝试存取 \\myserver\some\file
的东西将在 ~/.wine/dosdevices/unc/myserver/some/file/ 里查找。例如,如果您
使用 Samba 来挂载 \\myserver\some 于(到)/mnt/smb/myserver/some,那么您可以做:
ln -s /mnt/smb/myserver/some unc/myserver/some
来使之在 Wine 中可用(如果它不存在,请先创建该 unc 目录!)
3.3.3 字体
如果有一系列的 TrueType 字体在 Windows 里,您可以简单地拷贝 .ttf 文件们到 c:\windows\fonts 中。
3.3.4 打印机
Wine 能直接地与 CUPS打印系统 (CUPS, Common UNIX Printing System 通用 Unix 打印系统)互动,来查找您系统上可用的打印机。配置 Wine 的打印机就简单到确保您的 CUPS 配置工作。
3.3.5 扫描仪
在 Windows 里,扫描仪使用 TWAIN API 来存取当前的硬件。Wine 的内建的 TWAIN DLL 简单地将那些请求发送给 Linux 的 SANE 库。所以,要在 Wine 下利用您的扫描仪您首先需要确保您能够使用 SANE 存取之。在此之后您需要确保您有 xscanimage 可用。当前 xscanimage 是和 “sane-frontends 包”一起发行的,但它可能不能安装到您的发行版上。现在已知扫描仪存取有一些问题存在。如果您发现它能够工作,请考虑升级本指南的这一节,并提供详细的关 于在 Wine 下使用 SANE 的细节。
3.3.6. ODBC 数据库
在 Wine 里的 ODBC 数据库 系统,类似于打印系统,被设计钩对 Unix 系统于一高水平。不是去确保所有的Windows 代码在 Wine 下工作,而是使用一个合适的 Unix ODBC 供应商,比如 UnixODBC。
因此,如果您配置 Wine 去使用 内建的 odbc32.dll ,此 Wine DLL 将接入到您的 Unix ODBC 包,并让其做该工作。
但是,如果您配置 Wine 去使用 本地的 odbc32.dll , 它将尝试使用 本地的ODBC32 等驱动程序。
3.3.6.1 配置Unix上的ODBC数据库
要 在 Wine 下使用 Unix ODBC 数据库的第一步当然就是要使 Unix ODBC 系统自己能工作起来啦。这个方法包括下载 源代码 或 RPM包 等。有多种 Unix ODBC系统 可用;笔者曾经使用过的一种叫UnixODBC (with the IBM DB2 驱动). 也有 ODBC-ODBC 桥 ,它可以用来存取一个 微软 Access 数据库。
一般地,这类系统将包含一个工具,例如 isql,它将允许您从命令行存取数据以便您能检查该系统是否工作。
下一步就是要使 Unix ODBC 库 和 内建的odbc32 DLL 相勾结。内建的odbc32 DLL 检查环境变量 LIB_ODBC_DRIVER_MANAGER 来寻找ODBC 库 的名字。例如在笔者的 .bashrc 文件里有如下的行:
export LIB_ODBC_DRIVER_MANAGER=/usr/lib/libodbc.so.1.0.0
如果该环境变量没有设置,那么它寻找一个库名曰“libodbc.so”,这样您可以添加一个符号连接到您系统上与之等价的库文件。例如,以 root 身份您可以运行如下命令:
$ ln -s libodbc.so.1.0.0 /usr/lib/libodbc.so
$ /sbin/ldconfig
配置这个的最后一步是确保 Wine 被设定为运行 内建的odbc32.dll版本。通过修改 DLL 配置 可以达此目的。这个 内建DLL 仅仅作为调用的代码和 Unix ODBC 库 之间的残余部分。
如果您遇见了任何问题,您可以在运行 Wine 之前,使用 WINEDEBUG=+odbc32 命令,就可以跟踪(调试)发生了什么。
3.3.6.2 使用Windows上的ODBC数据库
本 地(原生)的 ODBC 驱动已经被报告可以为多种数据库(包括 MSSQL 和 Oracle)工作。事实上,有些如 MSSQL 只能通过一个 Winelib 应用程序被存取。不是仅仅拷贝 DLL 文件,多数 ODBC 驱动 要求一个 基于Windows的 安装向导被运行来配置诸如注册表键之类的东西。
为了安装 MSSQL 支持,您将首先需要到
microsoft.com
下载并运 行 mdac_typ.exe 安装向导。为了配置您的ODBC连接 您必须接下来在 Wine 下运行 CLICONFG.EXE 和 ODBCAD32.EXE 。(CLICONFG.EXE 疑为CLICONFIG.EXE或CLCONFIG.EXE 误)您可以在 windows\system 目录里找到他们,在运行 mdac_typ 后。
比较这些程序的输出和在 Windows 机器上有何不同。有些东西,比如协议,可能会缺失 —— 因为他们需要和操作系统一齐安装。如果是这样,您可能可以从一个 存在的 Windows 安装 拷贝缺失的功能和任何需要的注册表键值。一个本地的 Windows安装配置在 Wine 上应该与在 Windows 本地以同样的方式工作。
已经在 Wine 下成功地测试的 类型:
数据类型 有用性
微软 MS SQL 100%
3.3.6.3 使用Windows上的ODBC数据库成功报告
请报告任何其他的成功事例到 wine-devel 邮件列表。
4 运行Wine
本章将描述运行 Wine 的所有方面,例如,基本的 Wine 启(调)用,各种 Wine 支持程序的命令行参数,等等。
4.1 基础使用:应用程序和控制面板小程序
假 定您正在使用假的 Windows 安装,您使用与您在 Windows 里相同的方法来安装应用程序到 Wine 中:通过运行安装向导。您可以只接受默认安装路径,大多数安装向导会默认安装到 “C:\Program Files”,这不错。如果应用程序安装向导要求创建快捷方式图标,您可能会发现 Wine 在您的桌面和您的应用程序目录里创建图标。如果这事发生了,您可以通过点击(译者注:有的桌面管理器单击有的桌面管理器双击)启动应用程序。
标准 的卸载东西的方法是对这种应用程序提供一个 unistaller,通常注册到 “添加/删除应用程序”控制面板小程序。要使用 Wine 上的等价物(替代品),运行 uninstaller 程序(它位于在 Wine 源代码目录里的programs/uninstaller/ 目录)于一个终端:
$ uninstaller
有些程序安装关联的控制面板小程序,典型的这类例子是 IE 和 QuickTime,您可以在终端中使用下列命令 Wine 来使用控制面板:
$ wine control
它将打开一个窗口,窗口中有已安装的控制面板小程序,就类似于在 Windows 里。
如果应用程序不安装任何目录或桌面项目,您将需要从命令行运用该应用程序。请记住您把它安装在哪里了,然后使用类似下面的命令:
$ wine "c:\program files\appname\appname.exe"
将可能工作。目录并不区分大小写,但请记住一定带上双引号(半角英文)。有些程序并不总是使用显而易见的名字来命名其目录和 EXE 文件,故您也许需要进入程序文件目录去看看哪里放了些什么。
4.2 如何来运行Wine
您可以简单地调用 wine 命令行来获取简单的帮助信息:
Usage: wine PROGRAM [ARGUMENTS...] 运行特定的程序
wine --help 显示本帮助并退出
wine --version 输出版本信息并退出
第一个参数应该是您想要 Wine 执行的文件的名字。如果可执行文件在 Path 环境变量里,您可以简单地给出可执行文件名。
但是,如果可执行文件不在 Path 里,您必须给出可执行文件的全路径(以 Windows 格式,而非 UNIX 格式!)。 例如,给一个下列的 Path:
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


要获取运行文本模式(CUI,文本界面)可执行文件的详细信息,请参阅下面相关章节。

4.3 类似 Explorer 的图形化Wine环境
如果您喜欢使用一个图形化的界面来管理您的文件,您可能想考虑使 Winefile 。这个 Winelib 应用程序是来自 Wine 的并且能从其他 Wine 程序找到。它是来检视您驱动器配置和定位文件的有用方法。另外您能够直接从Winefile执行程序。请注意,很多功能没有被实现。

4.4 wine命令行选项 : 4.4.1 --help 和 4.4.2 --version
--help
显示简单的命令行帮助页。
--version
显示 Wine 版本字符串。对验证您的安装有用。

4.5 环境变量
4.5.1. WINEDEBUG=[channels]
Wine 并不是完美的, 并且许多Windows程序还是不能在没有bugs的情况下运行于wine下(但那么,很多程序也不能完美运行在wine下)。为了使人比较容易追踪找到在每个bug后面的成因,wine提供你一些侦错频道能让你轻易的进入每个除错频道。
每 个除错频道, 当被激活, 将会引起登录信息被显示到你调用的wine控制台。在那里,你能在你的空闲时后重新传入给一个文件的讯息而且调查它。 但是你首先要注意, 一些侦错频道能产生难以置信那么多数量的记录信息。 在很多丰富的主要罪犯中都是接替每一次发出一个记录信息当wine 32功能被调用, 追踪窗户信息传递的win, 和 一定全部存在每个单独得侦错频道的一个别名。对于一个复杂的应用程序,你的侦错记录能容易地大于1MB 或者更大。 接替痕迹能时常产生记录信息超过 10 MB,视乎你运行程序多久。 (你将会想检查 RelayExclude 注册修正的关键传播痕迹报告). Logging会一点点的相当的降低wine的速度, 因此不要使用 WINEDEBUG ,除非你真的做需要记录文件。 在每个侦错频道里面,你能更进一步叙述一个信息类别, 过滤出不同的严重的错误。 四个信息类别是: trace, fixme, warn, err。
为了要打开一个侦错频道, 使用形式类别+频道。 为了把它关掉,使用类别-频道。 为了要列出相同的超过一个频道的 WINEDEBUG 选,用逗点隔开他们。 例如, 去请求大量除错频道的警告类别信息, 你可以像这样调用wine:
$ WINEDEBUG=warn+heap wine program_name

如果你停止所要的信息类别, wine将会为那一个频道显示来自所有的四个类别的信息:
$ WINEDEBUG=heap wine program_name

如果你想看到除接替频道的所有记录信息, 你可以像这样做:
$ WINEDEBUG=+all,-relay wine program_name

4.5.2 WINEDLLOVERRIDES=[DLL Overrides]

不是总能使用 内建DLL 运行应用程序。有时候 本地(原生)DLL 运行得更好。虽然这些 DLL overrides 可以通过使用 winecfg 来设置,但是您可能希望使用 WINEDLLOVERRIDES 环境变量来设置他们。

例如,如果您想要 Wine 来使用本地ole32.dll, oleaut32.dll 和 rpcrt4 您可以像这么运行 Wine :
$ WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n" wine program_name

4.6 wineserver 命令行选项

Wineserver 通常自动地被 Wine 启动,不论第一个 wine 进程是什么时候启动的。但是,wineserver有一些有用的命令行选项,如果您手动启动 wineserver,您就可以添加它们。例如,通过一个用户登录脚本或其他的什么。

4.6.1 -d
为启动wineserver的终端里的debug输出设置debug级别。换句话说:任何高于 0 的值都将启动 wineserver特殊debugging输出。

4.6.2 -h
显示 wineserver 命令行选项帮助信息。

4.6.3 -k[n]
杀死当前的 wineserver ,使用任意的/选择性的信号 n。

4.6.4. -p[n]
这个参数使 wineserver 保持您想要的时间,n 即为该时间,单位为“秒”。它可以防止 wineserver 马上关闭。
通 常,wineserver 会在最后一个使用 wineserver 的 wine 进程终止后立即退出。但是,由于 wineserver 在启动时载入了许多东西(诸如整个 Windows 注册表数据),其启动可能是相当慢的,所以有时候通过使之保持从而保持其在所有 Wine 会话结束后持续存在。

4.6.5 -w
此参数使一个新启动的 wineserver 等待,直到当前活动的 wineserver 实例终止。


4.7 设定 Windows/Dos 环境变量
您的程序可能要求正确地设置一些环境变量以便其成功地运行。在这种情况 下,您需要在 Linux shell 中设置这些环境变量,因为 Wine 将把全部的 shell 环境变量设定传递给 Windows 环境变量空间。例如,在 bash shell 中(其他 shell 可能有不同的语法 !):
export MYENVIRONMENTVAR=myenvironmentvarsetting
这 将确保一旦您使用 Wine 启动您的程序,该 Windows 程序能存取 MYENVIRONMENTVAR 环境变量。如果您想要 MYENVIRONMENTVAR 设置能保持,那么您可以把该设定放入 /etc/profile,或者也可以放在 ~/.bashrc 里,如果您使用 bash 的话。

请注意,但是该规则也有例外:如果您想要更改 PATH, SYSTEM 或 TEMP 变量,那么您肯定不能那么做,因为那将改变 Unix 环境设定。所以,您应该把他们设置在注册表中。要设置他们,您需要启动 wine regedit 然后进入
HKEY_CURRENT_USER/Environment
键。现在您可以创建或修改您需要的变量的值
"System" = "c:\\windows\\system"
此 设置指出了 windows system 文件们在何处。Windows system 目录应该居于被用来作为 Windows 设定的目录之下。这样,如果使用 /usr/local/wine_c_windows 作为 Windows 目录的话,那么 system 目录应该是 /usr/local/wine_c/windows/system 。此设置务必不要在末尾上写上斜线,并且请确保您有写入权限。
"Temp" = "c:\\temp"
这应该是您想存放您的临时文件的目录, /usr/local/wine_c/temp 在我们前面的例子里。再次提醒,不要有末尾的斜线,要有写入权限!!
"Path" = "c:\\windows;c:\\windows\\system;c:\\blanco"
类 似于 Unix boxes 上的 PATH 设定。当 Wine 是运行像 wine sol.exe ,如果 sol.exe 存在于 Path 设定里指定的目录中,wine 将执行之(当然啦,如果 sol.exe 存在于当前目录中,wine 将执行当前目录中的那一个 sol.exe)。请确保此变量始终有您的 windows目录 和 system目录 (比如,在此例子中的设置,它必须有 "c:\\windows;c:\\windows\\system" )

4.8 文本型程序(CUI: 控制台用户界面)

文本模式程序是只使用文本作为输出的程序。用 Windows 术语来说,它们被称为 CUI(Console User Interface,控制台用户界面)可执行文件,与 GUI(Graphical User Interface,图形用户界面)相对。Win32 API 提供了一套完整的 API 来处理这种情况,涵盖了从基本的特征(如文本打印)到高级的功能性(如全屏幕编辑,色彩支持,光标支持,鼠标支持等),中间的特性如:行编辑,或 原始的/加工过的 输入流 支持。

鉴于上述的宽广范围,以及当前在 Un*x 世界里的应用,Wine 提供三种不同的方法来运行控制台程序(亦称 CUI 可执行文件):

•bare streams

•wineconsole with user backend

•wineconsole with curses backend

这里的名称有点灰色而略显费解。“bare streams”意味著不提供 Wine 的额外支持,这些支持用来影射 Unix 控制台存取。另外两种方法要求使用特定的 Wine 程序 (wineconsole),它提供扩展的环境。


4.8.1 CUI 可执行文件配置

当使用 wineconsole 时,有若干配置选项可用。Wine 以每个应用程序为基础,存储若干配置选项在注册表中。例如,这使得用户可以为一个给定的应用程序定义他想要给它的默认屏幕缓冲大小。

从今以后,只有 USER backend 允许您编辑那些选项(我们不推荐手动编辑注册表内容)。当您右键在控制台中单击时,将弹出一个菜单,您可以从下述选项中选择:

•Default(默认):这将编辑所有尚未被单独配置的应用程序共享的设定。所以,当首次运行一个应用程序时(在您的机器上,在您的帐号 下)Wineconsole 将把从默认设定继承而来的设定作为应用程序的设定。以后,该应用程序将拥有它自己的设定,您可以按照您的意愿来修改之。

•Properties(值):这将编辑应用程序的设定。当您已经完成了编辑,将提示您是否想:

1.Keep these modified settings only for this session (next time you run the application, you will not see the modification you've just made).

仅为此会话保持这些修改后的设定(下一次您运行该应用程序时,修改将消失)


2.Use the settings for this session and save them as well, so that next you run your application, you'll use these new settings again.

为此会话使用这些设定,并存储之,以便您下次运行您的应用程序,您将再一次使用这些新的设定。

下面的列表列出了您可以配置的项目,以及其意义:

问题捕捉报告 bug


5.1 如果有些程序仍然不能运行怎么办?
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 ,以及载入 本地(原生)的 还是 内建的 版本。然后请确保您有正确的 本地(原生)的DLL 文件在您配置的 C:\windows\system 目录并在命令行或配置文件乱动 DLL 载入顺序设定。


5.1.5 检查您的系统环境!

仅仅一个想法:会不会是您的 Wine 创建/执行环境坏了?请确保 Wine 所依赖的包没有任何问题(gcc, glibc,X 库,OpenGL(!),……)例如当使用“错误的”头文件给“正确的”库时,有些人会遇到奇怪的不能找到东西的失败!!!

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
组群。

5.1.11 Debug之!

下一步所要做的就是找到您的问题之源。可能的问题范围广泛到从只是配置的问题到 Wine 中完全没有实现的功能(性)的问题。下一小节将描述如何 file 一个 bug 报告以及怎么开始 debug 一个崩溃。


5.2 如何报告一个bug

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


5.2.1 所有bug报告

下面是一些关于如何使您的 bug报告更有价值的建议(这样您的问题更有可能被回复并被修复):
1、尽可能多地张贴相关信息
这以为著我们需要比“微软办公室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。否则,请跳到下一小节“困难的方法”。

2、切换目录到 /tools

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

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


5.2.2.2困难的方法

貌似只有最后的 100 行左右的

发表评论
评论通过审核后显示。