General Wine Information

From Wine-Wiki

Jump to: navigation, search

Contents

Introduction

This is for small tips, tricks and general troubleshooting for Wine Users. Often these arise from discussions in the Wine Mailing Lists. Interesting details that don't require a seperate entry in the Wine-wiki, or have yet to be assigned a permanent page in the wiki can be listed here. Wine is now essential to some business as One wrote: We use Wine at work to run a Windows console binary from a dead company (so no prospect of porting or updates). It runs on a Linux box with a zillion other things, rather than a Windows box, where it would have to be pretty much the only thing running and cost us a Windows licence and the PC to run it on - so for us it's not reliability, it's sort-of-virtualisation. It's run flawlessly for years. It's the example I bring up whenever anyone claims Wine will never be ready for real-world use ;-)

General Wine Tips

Official Documentation


Dimi Paun mentioned a change in the documentation arrangements for Wine [May 05]: the SGML docs have moved over to the CVS SourceForge: http://sourceforge.net/cvs/?group_id=6241

I'll be managing that tree for now (unless Alexandre wants to do it :)). Please send your patches as you usually do to wine-patches@winehq.org, but make sure to prefix the subject with '[WINEDOCS]' so I can more easily spot them. Discussions should take place on wine-devel@winehq.org as per normal. The new repository is set up with translations in mind [...]

Finding Wine

Has wine previously been installed on my computer?
You can confirm whether Wine is installed by opening a terminal window and typing 

which wine

Unless the Wine Application Database instructs otherwise, use the latest release. Wine is constantly improving at an impressive rate.

Further Reading


H. Bostick [May 05][Wine Archive link]: [Most distributions of Linux] have some [old] version of Wine in their repositories. So the user just installs it from there. We have to send them to the [www.winehq.org [official wine hq]] site to get a current download. [...] Wine installs silently as H. Bostick points out: 'There is no popup on firstrun' but then said 'if you need more help, or want to help, head over to http://www.winehq.org.' With your version of Wine help is provided with the standard linux man pages though she added a caution: [...] man pages are not the default first search point of this so-called "average (Windows) user"

M. Hearn described the reasoning behind this: The basic idea is you don't need any instructions. We currently associate EXE files with Wine, so you can just click on the EXE file [as you would do with Windows]. [..] We [do] need [...]somebody [...]to draw us some nice win32 file icons and get them merged into the default icon themes (or our CVS). I. Leo Puoti: I just use the wine icon for Mandrake RPMs.

Why does Wine install in a hidden directory?

When Wine is run for the first time, it installs in the users home directory under ~/.wine but a user queried this [July 05]: the C drive [is installed] under ~/.wine [and is] 'hidden' [...] a lot of graphical file browsing tools won't show dot files / directories without reconfiguration.

S. Richie: It's sort of a [Linux] standard to have an application store all of stuff in its own hidden folder. Now, Wine may be a bit of an exception to this, since it's not really one application or even suite of applications - the user has to install everything. However, keeping everything in .wine allows an easy, clean, nuke and reinstall of Wine, or transference of it to another system - one of the reasons this standard came about. Wine Archive

M. Hearn [Jun 06]: [after musing whether this should change asked] How often does [the average user] need to go poking around C:\Program Files in real Windows? wine archive

P. Beutner: system.reg, user.reg and dosdevices/, [...] are "generally uninteresting". And if you [access and edit...] them you want to use regedit/winecfg, than editing them by hand. wine archive

A user asked [aug 08 wine user] Is there any way [...] to change that and make it a normal directory called simply "wine"?

D. Kasak pointed to an easy solution: How about [create a visable link to this from your home folder]: 

ln -s .wine wine

The Wine Version

What version of Wine do I have Installed?
If you already have wine installed, identify the version by typing in a terminal window 

wine --version

A. Mohr explained why there are two dashes: Unix *always* (well, almost;) uses double-dash for long options Wine Archive

64Wine and Wine on 64

Wine currently can run on many 64 bit systems with the compatibility libraries for 32bit. Now for wine running the 64bit Windows software, that is another matter all together. Work has been on going and as of dec 08 with multiple patches yet to be included in Wine, it can apparently run some minor things but this will need on going work before it is ready.

Identifying the Latest Version of Wine

There is a small catch that may trip you up with the version numbers when you are looking to download the very latest version. A. Talbot [Feb 07 Wine devel] The problem arises when version control programs sort the release "tags" alphanumerically, [...]. as one long time wine user noted: [The] actual system is [...] a numbering one - so [...] the difference between 0.9.3. and 0.9.30 is the difference between 3 and 30. [...] so [..] 0.9.3. < 0.9.30. ; 03.9.3.1 < 0.9.30.1 ...etc .

Ed. Perhaps another example will suffice. After version x.x.99, the next version would likely be increased by 1 which gives you x.x.100. However your software tools may list the older version first.

Further Reading



How will Wine be developed since version 1.0

A. Julliard gave a few notes on future development [Jun 08 wine devel]:

  • [...] Development will continue as usual in the git "master" branch. The 1.1.x development releases will be made from that branch every other Friday.
  • There is now a git "stable" branch, where only important bug fixes will be committed. The 1.0.x maintenance releases will be made from that branch whenever enough changes have accumulated to justify a release. The process I suggest for the 1.0.1 release is as follows:
    • all bugs should be fixed in the master branch first - once a bug fix has been committed to master, the corresponding bug report should be marked fixed, with the sha1 of the commit fixing it
    • the bug report should then be put into the 1.0.1 milestone.

This will allow me to periodically query for 1.0.1 bugs that are fixed in master and cherry-pick the corresponding commits into the stable branch.[...]It's easy enough to extract a list of translation patches if we decide to merge them, so I don't think there's a need to maintain a list in bugzilla. [...]If a patch can't be made to apply then I'll ask the author to merge it, but for 1.0.1 that shouldn't happen, we won't be diverging that fast. And once backporting starts to become too painful then it will be time to make a new stable release. [... For the 1.0.1 branch] If a bug fix comes with a test then the test can be merged too, but otherwise I don't think it's necessary to add tests.


One person [jun 07] asked tongue in cheek: don't a 1.0-Version mean that every Windows app works on Wine?

J. Hawkins: There will never be a point where all Windows apps work in Wine. As it stands, we have a bigger compatibility goal than current versions of Windows, as we support apps all the way back to Win 3.1. Unfortunately, it's just not possible to support all known apps.

anon: repeat after me... Wine, more compatible with Windows than er, Windows!


Preparations

D. Kegel reported after the 2007 wine hackers conference (wineconf) that he had been tasked to go through and identify (with Alexandre's approval) what bugs are 1.0 bugs and what aren't. [He has adready] started adjusting the "Target Release" fields on a few bugs in Bugzilla.

Developing Software for Windows and Wine

One developer reported: I did several changes to my application to be compatible with wine, but if every time a new snapshot is released something is broken I can't support wine.

M. Stefanuic: That's the wrong approach. You shouldn't need to make your application compatible to Wine. If your up runs into Wine bugs please fix Wine itself or at least open bug reports. Wine will make the efforts to be bug compatible to Windows _if_ real life applications depend on that behavior. But Wine won't be compatible to its own bugs.


Wine and Windows Partitions

A user queried about mixing wine and Windows. While this appears to be a common misconception about wine, J. Chapman explained it this way [Aug 07 wine user]: Wine Is Not (an) Emulator.

This means that it cannot run windows - it 'is' windows as far as your end-user applications are concerned.[...] This means that you should [...] install applications properly [under wine] and use them. It does not require, nor does it work with, an existing windows installation.

NEVER, EVER run wine as root!

V. Margolen wine developer Warned : don't run programs directly from your [real] windows drive. [as a general rule] Never point your c: drive to the real windows drive - that won't help wine at all but it might break your windows beyond repair. [because]. Wine, [can] (and will) create/write/change/delete files under C:\Windows. This is dangerous on a working windows drive. wine archive [Oct 07 wine devel he added] : It's the same as [attempting] to run an application on windows via the network from another [windows] PC [No, dont try this at home, this is a bad idea. Doing this even in Windows will likely cause you grief].

Starting Wine

Running Wine with user privileges

T. Cavin: Yes, this is a "security precaution", but [...] It isn't just Wine that you shouldn't run as root or superuser, it's any program. On any Unix or Linux computer system, a process running with root (uid=0), (or in MS-Windows a process running with administrator privileges) has unquestioned authority to change the system. Execution privileges directly affect program functionality, and giving a program too many privileges means you may be giving it more than it was designed for.

The operating system doesn't care if the command to format the system disk came from a command line of a logged in sys-admin who is wiping the disk before disposal, or from an email virus automatically executed by Outlook Express. If the process issuing the format command has sufficient privileges to wipe the disk ... it's history.

That's an extreme example, but there are many lesser issues that can cause more subtle damage. Programs that are designed to be run by non-privileged users may normally probe parts of the file system in order to find a place to store temporary files. This probe can be as simple as checking for read permissions, and a failed check causes the program to look elsewhere for temporary file space. A user program may try to store information in the current directory, and if it can't write there it will switch to a user's home directory. If you run such a program as superuser, the permissions check always succeeds, so you may end up writing files anywhere on your system. in the case of Wine, this is a particularly serious issue. Wine is designed to run programs that were written for a different OS. Regardless of anyone's opinion of the innate reliability of such code, running _any_program in Wine is running it in a foreign environment that has different rules than the program expects.

[...] If you do this on your own machine you are only likely to hurt yourself. It might be interesting to see what happens, and it could even be a good learning experience. But please don't do this on any system you (or anyone else) depends on. Wine Archive

It is true there are a few programs where wine needs to run as root, wine will tell you if it needs root permissions. Unless wine tells you, do not run as root. J. Lang Oct 07 wine devel: we strongly recommend against running Wine as root. But you sometimes need to run Wine as root in order to do certain things on Linux, e.g. open raw sockets. The solution: don't run applications that want to do those things, or take it up with the Linux kernel developers.

Setting up the Fake Windows environment

You can obtain installation files and the source code from the Official Wine website. Users have added to The Wine-Wiki instructions to install Wine for most distributions, and the Official Wine Application Database has important information on how to install and run an extensive list of programs with Wine.

You can then run Windows software under wine by either clicking on a Windows executable, from the command line, or you can make a shortcut. If you run a installation program that puts installs a shortcut on the desktop, Wine can often create a shortcut on your linux desktop for you.

Since the June 2005 release of Wine, type in a terminal window Winecfg. This will create a fake Windows Drive and all the directories in your home user directory, and is where Wine's configuration settings can be altered. (Previous versions of Wine made use of the (now obsolete) Wine Config File) With winecfg, you can set overrides for each application, sound, and many other aspects of wine. If you are new to Wine, or have not used Wine for a long period, the need to first read the documentation with Wine probably cannot be understated.

A. Browaeys: See windows programs as plugins for wine . They are installed in the home directory of the user used to install them[...](c: is a directory in your user home, so your are already "root" in the windows meaning in your wine environment). Security wise using wine as root is giving your windows program the capabilities to break your system [...].

W. Olgburn: the general recommendation is to install applications separately under wine.

If you have a windows executable, say "setup.exe," you could:

  • open up a terminal window, cd to the right directory, and type
    wine setup.exe
  • open a file browser like Konqueror, click on setup.exe, and in the "Open with..." dialog type "wine."


At this stage in Wine's development, sometimes dll overrides are required, which means that a Native Microsft Dll is needed to make it run. Several methods are available. See winecfg,Using the Command Line#WINEDLLOVERRIDES and see Man Page:WINEDLLOVERRIDES for running Wine InstallShield or Wine MSI installers and also while running some programs. Because of the rapid pace of Wine development, check the Wine application database for the latest tips to installing and using your favourite software (if your software is not listed, please make sure you submit it to be added.


W. Ogburn: As you install programs under Wine, you should automatically get a "Wine" entry in your applications menu. This works like the MS Windows Start menu, if you're used to that. Wine Archives.


N. Law [Nov 2006]: for those that rely upon wine to run their favorite application, then install your stable version of wine that runs your application somewhere other than the default installation directory and use that while still downloading and testing the latest release. Then when the latest wine breaks you application it doesn't stop you using your favorite [application ]


Windows File Locations

V. Margolen: [Wine is a] "Windows replacement". So all the cases [where] someone has an access to a partition with functioning windows means nothing to Wine. "~/.wine/dosdevices/c: points to what windows programs will see as a "c:" drive." [but] don't run programs directly from your [real] windows drive. [as a general rule] Never point your c: drive to the real windows drive - that won't help wine at all but it might break your windows beyond repair. [because]. Wine, [can] (and will) create/write/change/delete files under C:\Windows. This is dangerous on a working windows drive. While at any time you can remove ~/.wine dir [created by wine] and [restart] with a clean [fake] "windows" environment, you [will] have to reinstall Microsoft Windows if [you] break [your real windows installation]. [whttp://www.winehq.org/pipermail/wine-devel/2005-November/042319.html wine archive]

J.Hawkins:In [the folder] .wine/dosdevices there are symbolic links that point to virtual "devices" for wine. Z:\ usually maps to the root directory.., so if you want to access anything outside of C:\ you can use Z:\. Generally you should use .wine/drive_c with windows programs though so you don't have to look through the unix file system for a file.


Does wine need to set virtual memory in like windows?
J. vonThaddon: 'No. Wine is not Windows. Everything on the OS-Level like memory management, network access and so on, is done by Linux'

Setting the Version of Windows

Some programs need to run on a specific version of Windows. The version of Windows can be set using winecfg (Older Wine versions use the Wine Config File). Setting the version on the command line and through the obsolete config file, has been deprecated and will no longer work. Dimi Paun maintains a list of where you can now set advanced options for Wine, and the scope they have here http://winehq.org/site/status_options .

Since June 05 P. Oberndorfer: wine now defaults to behave like Win 2000 [though if this does give trouble,] you could try to set windows version to 98 with winecfg. Wine Archives.

Further Reading

Wine and Fake Windows Dlls

Wine refers to dlls as builtin and native. You may recognize the name because if you look in Windows there are quite a few files that end in the letters .dll. What you need to know is that builtin means that this file has already been implemented with wine whereas a native dll is a dll that is copied over from Windows installation. With wine you can sometimes use a native dll, but check in the official application database to see what will work with your software.

Wine has even got fake dlls. This was noticed by one programmer [Oct 07 wine devel] ddhelp.exe is on the list of fake dlls even if I couldn't find any reference to building such a file in Wine sources. [...] I've found that dsound.vxd also isn't [..] built in Wine. These two files are on the list by mistake?

A. Julliard: No, they are here because an app needs them. It's not always necessary to have a corresponding builtin, if the app doesn't try to actually load the dll a fake is enough.

A user asked sept 08: what is in the drive_C/windows/system32 folder? are these the Builtin dlls? or are they just stubs needed to fool the programs into thinking that the dll exists?

Vitamin :[They are] Stubs or what we call them "fake dlls". They contain only resources but not the actual code.

A user then asked: If [..] I want to use a Native dll for just one program, then do I copy it to the system32 folder and overwrite the dll file there [..]

Vitamin: No, you should copy it to the program's directory and override it for that only program in winecfg. Unless you force Wine to use native dll, Wine will always prefer to use it's own [builtin] dlls [separate files, but somewhere in /usr/lib/wine ...] (except when Wine's dll is a complete stub (has no code at all) and configured to prefer native, if exists).

Speed Tweaks

Wine outputs many debugging messages, but if you are not trying to debug or add to Wine's functionality, you can redirect these messages. Often this will make programs (such as games) run faster. J von Thadden: 

$@		all command line parameters
&>/dev/null	all output into hell
&		go to background

Put together, this works as: 

wine  program_name.exe ($@ &>/dev/null &)

[ed ] Your favorite program may run well, but you can hide some of the terminal messages so Grandma doesnt worry...

D. Clark and TimeFX: 

WINEDEBUG=fixme-all wine program.exe


D. Clark [May 05] highlighted another somewhat more advanced trick to consider: try setting msvcrt to native. Often with programs that are processor intensive [...] using a native msvcrt can have a dramatic impact on performance. [ed] to try this, you would need to copy msvcrt into your wine's system directroy and then run your application with the following: 

WINEDLLOVERRIDE="msvcrt=native" wine foo.exe

However for those trying this, U. Bonnes asked: If you have downloadable applications that work fine with native MSVCRT and not with builtin msvcrt, please let wine-devel know.Wine Archives

Running Command Line Applications

WineConsole

C.Curley: you can run some. I've already found out you cannot run programs that access the video hardware directly. Use wineconsole.

D.Clark: If it is a purely command line application, that is, it only outputs plain text, then plain old Wine is fine. I have been running Xilinx command line tools under Wine for years that way.


J.Vinod suggested: Use the full path. You may pass arguments to the program being executed by adding them to the end of the command line invoking wine eg: 

wine notepad C:\\TEMP\\README.TXT

Note that you need to '\' escape special characters (and spaces) when invoking Wine via a shell. If wine should run the program myapp.exe with the arguments --(2 gyphons)display 3d somefile, then you could use the following command line to invoke wine: 

wine --dll riched32=n -- myapp.exe --display 3d somefile

Check the man pages for more details.....


C.Curley: Here is how to set up a shell script running on Linux invoke the console/command line application 

$ cat $(which rf)
#!/bin/sh

# Time-stamp: <2005-01-24 07:57:01 ccurley rf>

# Shell script to launch real-Forth from wine.

# set the geometry once and for all. wineconsole seems to prefer 80x25
geo=3D80x25-15+20

xterm -fn 10x20 -geometry $geo -e 'cd ~/.wine/drive_c/crc/rf ; /usr/bin/wineconsole c:\\crc\\rf\\rff.com 3 load'


However S.Petreolle pointed out: You can use wcmd Wine Archive Link

WCMD

M. Stefaniuc: If you want wcmd [...] both [of of these] methods work: 

wcmd foo.exe

and 

wineconsole --backend=user wcmd

The later one runs a console which is fully compatible to that on Windows and some programs rely on that. Wineconsole is only the "terminal emulation window". [..] It also has the advantage that the wine debugging output (FIXME/ERR) don't clutter the output.Wine Archive Link

Stopping Wine

Stopping a program
M. Hearn: You can't interrupt all Windows programs using ctrl-c. It is preferable to use "kill" instead. Pressing Ctrl-C on the console of a Wine process will cause it to deadlock or crash, and you may see a lot of "Expect deadlock!" statements.

Wine Archive Link If you want to kill Wine, [dont use] Ctrl-C. [type in a terminal window]: 

killall -9 wine-preloader

Desktop Shortcuts

Creating a Shortcut
Is it possible to create a shorcut of our program on our desktop so that a end user will just click the icon on the desktop to run the program.exe without needing to type the text command "wine program.exe".

M.Hearn: Yes it's possible, just create a link that runs 

wine "c:\wherever\myprogram.exe"

Wine Archive Link


Odds and Ends

You can list information that is of interest but were not sure where to put it here... Another wiki user may know where it goes.

How do programmers develop Wine

Simply by testing the behavior of Windows. R. Dunn explained [Aug 07 wine devel]: [An analogy] would be that you have a light switch and a light bulb. The light switch is your input and the light bulb is the output. Everything else is unknown (a black box). You don't know how it works.


You could open the box up and look inside (the equivalent of looking at the Windows source), but Wine can't do that. Also, if you modify the Wine code to improve it, you may break something. This would be like making a short circuit in your example above: the light no longer works in your replica (i.e. Wine), so any tests will fail on that.


What you can do instead is say that when the light switch is on the 'up' position, the light bulb is on and when the switch is on the 'down' position, the light bulb is off. Now say you have two rows of 4 switches and a row of 4 lights, aligned with each other. What is the behavior of this system? The only way to find out (without looking inside) is to devise a set of tests. This way, you can find out what logic the system is using. For example, if the system is behaving like a binary adder, you can deduce that from the tests. The tests in Wine are designed to pass on Windows (and should, in theory, pass cleanly on that platform). The implementation of Wine is then written to pass those tests, therefore matching the behavior of Windows. [emphasis added]

Ed. Anyone who looks at the source code to Windows is banned from working on Wine.

Wine vs Codeweavers

A user asked [Sept 06]: Is your group affiliated with "CodeWeavers"? They claim to have a "wine" product called Crossover Mac that will have a final release soon.

T. Schmidt: CodeWeavers is a company that sells a proprietary version of Wine called CrossOver Office, for running Windows applications on Linux. The company was founded in 1996 as a consultancy, eventually moving entirely over to Wine support. Crossover is regularly rebased to new Wine snapshots, and patches that the company's employees write are sent back to the project almost immediately

And this page:

D. Kegel: It should also be said that Wine is the "clean" tree (Alexandre doesn't let any [poor] code in), while Crossover uses an "expedient" tree (with a fair amount of code that really isn't right, but happens to make a few key apps like MS Office work). It's a good division, actually, with lots of cross-pollination. The two trees are kept well in sync. wine archive


Wine vs TransGaming

J. Green [Aug 07 wine devel] All of the LGPL Cedega/Cider source code is available on TransGaming's public CVS server at http://www.cedega.com/cvs/. Any substantial patches to LGPL'd components are typically submitted back to WineHQ. There haven't been many recently since most of those components aren't heavily used by games. One of my roles at TransGaming is to make sure that patches to our LGPL'd folders make their way back here [to wine].

Wine doesnt assist working around game protection

A user asked wouldn't WINE [...] make a great cracking tool for [exeCypter]? [...] It supposedly detects and resists attempts to debug encrypted applications to break the code, but can it do so with WINE's virtualized environment?

M. Hearn [May 05]: They generally work pretty well (assuming they run correctly). It's quite hard to figure out what they're doing even when run within Wine.Wine Archive

May 07. Progress has continued apace. When Wine 0.9.37 was released it noted an improvement: Support for a few more exe protection schemes.

Can Wine Run Windows64 Applications

Ed. Work is ongoing.

Ge van Geldorp [Jun 06]: With the Win64 patches I just submitted to wine-patches, I'm able to successfully build Win64-enabled Wine and execute the following 64-bit winelib (winelib64? wine64lib?) application.

K. Ober: I'm currently hacking on gcc for an embedded target (Z8 Encore), but I wouldn't mind giving it a try while I'm digging in the gcc tree.

A. Julliard described the problem: Wine can't use a global option since we have to call Unix functions. The only way is to have an explicit attribute on Windows APIs.

F. Navara: I've had GCC patched to use the MSVC x64 calling convention (without a switch though) for about a year now, but it doesn't solve the problem. There is much more ABI differences including the exception handling (and yes, I mean exception handling in C, not only C++) where MSVC generates special unwinding information for the functions.

H. Verbeet: MSDN AMD64 has some info. wine archive

F. Navara: the documentation I can recommend

Can Wine Run on a Mac

With Apple moving to intel processors, normal windows applications have the potential to run using Wine and Codeweavers now offer a version of wine for the Apple with intel processors. But with the PowerPC processors it is not so clear.

Jurgen: Short answer: nope. Wine doesn't emulate the Intel processor, [...] Since Macs use PowerPC CPUs, not Intel or AMD CPUs, it won't work for you. [..]

M. Mebane: As I understand it, the long-term goal of the Darwine project is to integrate Wine and QEMU to get x86 binaries running on PPCs. http://darwine.opendarwin.org/

E. Charpentier: You might be interested by one of a few emulators projects running under MacOSX : the older is bochs, but I have to say I have been very impressed by QEMU. Even in "full emulation" mode, it is able to run a complete installation of Windows NT quite decently (feels like a PIII/1G while running on a monoprocessor PIV/3.2G). According to the mailing lists, a MacOS version is good enough to do the same. Wine Archives


Further Reading

What about Windows Viruses

As long as you are running wine as a normal user and NOT as root, there is some protection. It is still a concern, but considering that you will most likely be using native Linux software for transferring software, perhaps it is unlikely you will be easily infected.

W. Ogburn [Nov 05] : I think there are two different answers:In principle, an executable that you run as a user under Wine can do anything that a malicious Linux executable could do. So it could potentially mess up your user's account. There's no special protection from malicious programs that comes from running under Wine. However, a Windows virus or other malicious program that doesn't know anything about Wine or Linux isn't very likely to do that. Any harmful effects will probably be limited to your fake Windows directory, and a lot of things that a virus might try to do won't work at all.


S. Petreolle: [read acces] Files are still at risk since the virus has _read_ access on them. As an example viruses replicate by reading mail adresses into files.

J. LaBarre pointed to another concern. I have a data partition formatted as FAT32 to be shared between Linux and Windows 2000. This partition is mounted under a "windisk" group which has R/W permissions (umask 0007)

M. Knecht: If he executed some exe file that had a virus in it, and the virus found some data file to infect, then the virus is there. It may not matter on his system, but should he send that file on to someone else then he would be transmitting a virus to others.

J. Ernst provided a voice of reason: If you are worried you can have your own wine user that you'll use for running wine.[and lock that down]

Further Reading

Viewing Windows Help Files

Truiken [ Apr 06] suggested using the command: wine hh filename.chm H. Arnesen pointed out there are native linux help file views: chm-viewer - xchm. kchmviewer, probably others.

Following The Wine Mailing Lists

A comment on the winedevel list noted a handy tip for sorting mail from the mailing lists: One Developer reported: Due to the rather large amount of spam sent to the *winehq.com email addresses (as opposed to *winehq.org), I would like to phase them out. I will state up front that this proposal benefits only me or any future moderator. Since I have been doing that for about 6 years now, hopefully I'll get a bit of sympathy

S. Dossinger: OK with me. The dual address thing is also confusing for everyone who sets up his own filters in the mailer, mostly to sort out mails into different folders.

R. Shearman: You should sort on the List-Id header instead.

The Wine License

T Wickline wrote [Jul 07 wine devel]: I was wondering if there are any plans in place for Wine to move to the newly revised LGPL 3 licence before the release of 1.0? http://www.gnu.org/licenses/lgpl.html

D. Jovanovic: LGPL3 = GPL3 + additional permissions: "This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below." The GPL3 has no track record so far,[...] Let's wait a while before making the decision.

K. Blin: This means that, as the GPLv3, the LGPLv3 is more compatible with international laws, as opposed to being US-centric like the (L)GPLv2 was. Also, all the other reasons to move to the GPLv3 apply. [...] At Samba, we have decided to switch to GPLv3 for the coming releases, releasing the libraries that were under the LGPLv2 under the LGPLv3. As for other projects, see http://gpl3.palamida.com:8080/index.jsp. [He then referred to the previous comment about waiting..] What specifically are we waiting for? [...]


T. Kuliavas :[...] there is no difference between GPLv2 and GPLv3 for BSD people. [...] Last time I've checked programmers could use code licensed under BSD license in GPL software, but they couldn't use code licensed under GPL in BSD licensed software. BSD is compatible with GPL, but GPL is not compatible with BSD. [...] The only people worried about GPLv3 and not worried about GPLv2, are the ones that use GPL software and restrict end user rights with hardware or patents.

Victor noted: Wine isn't just a library. (LGPL) though T. Schmidt said: Nor is the LGPL a license exclusively for libraries.

I. MacFarlane: [...] The version 3 of the (L)GPL license has numerous benefits:

  • It's much more legally sound in the rest of the world (IMO one of the most important factors about the new license) - numerous reasons for this e.g. referencing WIPO rather than US laws.
  • It has an explicit patent agreement (really an extension of the above -(L)GPLv2 has an implicit patent agreement, but this is only valid in the US) - this means that people who contribute to and/or distribute WINE cannot sue WINE (or WINE users) for patent infringement.
  • It is compatible with the Apache 2.0 license, meaning that there is an even bigger pool of source code to draw from.
  • It helps ensure that companies cannot prevent people from modifying the source code by providing them explicit legal rights to change the code in these circumstances, and requiring information to allow users to change it.
  • For LGPL only, It makes 100% sure that GPL+linking exception and LGPL can be combined legally in all jurisdictions by merging them (which is essentially the only real difference, barring slightly different wording in the v2.1 of LGPL vs v2. of GPL)
  • It prevents patent agreements where only some people are protected.
  • It provides a mechanism for first-time accidental violations to be 'cured' more easily
  • ... and lots of other minor changes to improve the validity of the legal status of the license.

[...]

  • Solaris may go GPLv3, another potentially useful repository of code to

draw from that would not be possible under GPLv2. So as you can see, (L)GPL version 3 has a lot of benefits. It also has broad support (excluding Linus of course, who I must point out objects only to a single clause in the license that can be resolved by adding an extra permission, as GPLv3 permits), including strong corporate backing (e.g. IBM, Red Hat, MySQL, Sun, even Novell). As one of the projects that Microsoft would most like to destroy, the added protections in this updated version of the license would seem even more valuable.

ps: As a last note to Damjan - all GPL versions have been considered both radical and political when they were released. In retrospect, the protections that they provided have been considered invaluable.

S. Edwards liked (l)GLPv3): The termination clause is clarified and a grace period added for compliance. As it stands right now, if someone was to inadvertently not adhere to the terms of a (L)GPLv2 program an over zealous major contributor could revoke distribution rights downstream to the offender even if the offender was in the process of trying to remedy the situation. It may only be a technicality but this bothers me. When corporate powers, with their own motives of profit outweigh commitment to FreeSoftware, are major contributors all the loopholes have to be closed. Imagine a world where SCO had contributed a lot of (L)GPL code and then they had gotten lucky to find a technicality in the license to revoke it for everyone.

M. Stefanuic pointed out that other projects using GPLv3 still automatically can not share code with wine: Samba is GPL and Wine is LGPL. I don't see v3 having changed something in regard to that. If Wine wants to use Samba code it has to ask the people that own the copyright to relicense their work.

Alexandre Julliard was silent on the matter, so we will have to wait and see.

The Software Freedom Conservancy and Wine

J. White Nov 08 [with formatting added]: several years ago, we decided to work with the Software Freedom Conservancy to ask them to manage aspects of Wine that merited the shield of a formal organization. They have been great, and a great improvement over our former process. [...]

What they do for [Wine], and how [it] is governed

First, there are essentially 2 major assets they manage for us.

  • They manage all funds donated to Wine - the donate button goes into a bank account they manage.
  • They also hold trademarks to the Wine logo that they filed on our behalf.

For decisions on how to spend funds, we've adopted a loose set of guidelines. That is, Dan Kegel, Alexandre, and myself are in contact with them. The goal is that all 3 of us agree on every decision, but 2 of the 3 of us must concur with any decision before it is effective. We three can appoint anyone else we choose to replace or augment the decision group. All decisions are CC'd to the WWN author (currently Zach Goldberg) for monitoring.

The SFC will recognize a 'revolt' by the Wine project. That is, Dan, Alexandre and I can be overthrown, once you figure out our evil plans, if the SFC is persuaded that the majority of Wine contributors agree on that point. Patch count in the Wine tree will be the primary mechanism to recognize a contributor.

Finally, all spending by the SFC on Wine's behalf for the last few years has been related to Wineconf. That has either been to pay for conference expenses directly (as in Reading, 2 years ago), or to help defray travel costs for Wine contributors to come to Wineconf (as happened this year).

General Wine Troubleshooting

For General Troubleshooting see another page called General Wine Troubleshooting

Retrieved from "http://wiki.jswindle.com/index.php/General_Wine_Information"
Personal tools