Wine Traffic #124 For 29 May 2002

This message is for those who wants to help Wine project but do not know where to start.

We need contributors of a wide range of skills. The minimal requirements are: access to a computer with Linux (or other Unix-like system) where you can use Wine.

We have a lot of tasks which are relatively easy to do. The fact that these tasks are easy does not mean they are not important.

Examples of the easiest non-programming tasks available:

• we *badly* need application owners. An application owner is a person who often uses some application and will help to make it work perfectly under Wine.
Does anybody use Lotus Notes regulary under Wine?
• confirm and research bugs in Wine Bugzilla http://bugs.winehq.com/ (http://bugs.winehq.com/)
• Add a 'Debunking Wine Myths' web page [ #606 (http://bugs.winehq.com/show_bug.cgi?id=606) ]

Examples of the easiest programming tasks available:

• Help Wine hackers - document Wine debugging channels [ #638 (http://bugs.winehq.com/show_bug.cgi?id=638) ]
• Improve RichEdit headers [ #330 (http://bugs.winehq.com/show_bug.cgi?id=330) ]

Easy, aren't they?

Do you need more choice?

• file BUGS in the Wine source tree gives more information how you can help the project
• bug 406 contains list of issues which is easy to fix. Don't be afraid to fix all the easy issues, so nothing will be left to others. We'll gladly add more! :-) http://bugs.winehq.com/showdependencytree.cgi?id=406 (http://bugs.winehq.com/showdependencytree.cgi?id=406)
• suggest your help on wine-devel mailing list. Don't forget to mention your skills, experience and what you want to work on.

If you want to know more - just ask.

Have fun!

there are a lot (>20000) of lines which have either some spaces/tabs or combination of both after the final ";" (or "," in the case of function arguments splitted on a couple of lines.) IMHO, it'd be better to remove them (although I admit it's mostly for esthetics reasons).

On the same vein, there are also a couple of instances where the final semi-colon is doubled, eg: "return S_OK;;". I removed the second one when grep encountered them.

The PostScript driver itself has rudimentary support for the Unicode BMP (U+0000 - U+FFFF). It does not support multi-byte characters or wide characters.

You will need a TrueType font with the characters that you want to print (the driver can't handle non-Latin PostScript fonts), and you will have to configure the driver to use the font.

1. Tell the driver where to find the TrueType font by adding a [TrueType Font Directories] to your Wine configuration file. Something like this:
   [TrueType Font Directories]
"dir0" = "/usr/X11R6/lib/X11/fonts/TrueType"
"dir1" = "/usr/share/fonts/default/TrueType"
2. Edit the PPD that you're using and add the TrueType font to the list of printer fonts. (You will need to know the Post- Script "FontName". You may need to run the font through a TrueType-to-PostScript converter to get this.)

We've been working quite hard on making improvements to the PostScript driver and now have code that should print any character that can be displayed on the screen (assuming you're using client side font rendering anyway). The code downloads the TT font to the printer as either Type 42 (TT wrapped in PostScript) or for older printers the font gets converted to a Type 1 outline.

It needs a little more work before we submit it to winehq so please bear with us for a bit.

This document should contain all of the information needed for you to start developing wine on the Mingw platform. Almost all information in this guide applys to both the Mingw on Cygwin and Mingw for ReactOS ports.

This document assumes you are using cygwin to configure and build WINE for a Mingw Target. Cygwin is enviroment used due to a set of bugs within the Mingw Unix Enviroment MSYS. Msys may work however it, the ReactOS build system and and any other configurations are not supported by the WINE project.

1. Make sure you have the latest cygwin with win32api package.
2. Be sure you are using mingw-extra-2.95.3.tar.gz with cygwin. (Fix for some libiberty.a issues) Read http://www.colomsat.net.co/freehost/ngiraldo/cppcygwin.html (http://www.colomsat.net.co/freehost/ngiraldo/cppcygwin.html) for the directions on building mingw C++ applications on cygwin.

DIRECTIONS:
To start hacking on Wine for Mingw, follow the directions at www.winehq.com to download the most current WINE sources.

1. ./configure --host=mingw32 --target=mingw32 --build=mingw32 CFLAGS="-D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK" CC="gcc -mno-cygwin -fnative-struct" CXX="gcc -mno-cygwin -fnative-struct"
2. make depend
3. make implib
4. make tools
5. cd programs && make
6. make dlls
   Build each dll manually.
7. make tests

Recently, a RFP (Request For Package) was put up on the Debian site, and a "developer" agreed on maintaining this package. The license as it is, allows to include it in the non-free archive.

Within hours after posting the ITP (Intent to Package) on the Debian bug database and on the debian-devel mailing list, a mail from Trans- Gaming's CEO/CTE Gavriel State was received, which indicates 1. "We noticed that you intend to package our AFPLed WineX package for release in debian (presumably non-free). We would really prefer that this not happen, for a number of reasons." 2. " We would prefer not to have to change our license to explicitly prevent the distribution of binary packages, but if we have to we will do so."

There are two things in this mail:

There are claims on the rights on the code, which are valid to some degree. The reasons they state are commercial (development => money => development) and possible confusion since the release of debian binaries based on their public AFP'ed CVS does not provide the full functionality of the binaries they redistribute (amongst others, they are not allowed to redistribute proprietary copy protection code used by games).

If you do distribute binaries, we will change the license to explicitly prohibit you from doing this.

The reaction of TransGaming concerning the binary debian release of WineX raises a couple of questions, that should be addressed before pursueing the packaging any further.

1. Does the license allow packaging?
   Yes, I read through it and you can distribute binaries as long as you put the source available in some common format
2. Is the source free?
   Well, to some degree, not the 3 RMS criteria, that's for sure
3. Who is the target audience?
   I would think people interested in 3D and 3D games and development. I think it is pretty obvious that you are not going to satisfy a hard-core gamer, since there is no support for copyright protection and most of the tweaking is manual (downloading dll's for example). I see such a package for enthusiasts that want to check the state-of-the-art in gaming without having to install windows (I recently checked the SoF2 demo with this, even though the game was only for about 30' in my HD). I imagine it is also useful for people working with 3D graphics and programming on it (e.g. students develop in win32 and you do not want to let them show the demo on your GNU/Linux workstation).. In both cases, it is handy, but most likely not enough to go for the commercial thing (one could do without it).
4. Should it be packaged?
   Carefully reading the mail from Gavriel State, I did not see any specific objections to packaging it, but to the inclusion of the package in Debian. I guess it has to do with the possible target audience... Part of the objections he made, are now addressed by changing the name to winex-light. Even then, I do not think this will be sufficient for them not to change the license to prohibit binary redistribution when included in debian.
5. Can TransGaming change the license?
   Legally I guess there within their rights to do so. Morally (I never thought I would use this word) no. I have worked on some projects where I added functionality to code and I cannot imagine me restricting the distribution of the code from which I did not write the bulk of it.
6. Will it be in debian?
   As things are now, no... Distributing it would only be temporary (most likely, it would be cut off before it even reaches unstable).

After having read a few of the comments on our request not to have WineX added to Debian, I thought that I should clarify a few things.

First of all, we have made, and hope to continue to make, substantial contributions to free software projects such as Wine and now ReWind. I think our record on this front speaks for itself to anyone who cares to browse the wine-patches archives, or look at some of my recent posts on wine-devel.

As for the ITP, we have no intention of forcibly stopping Debian from packaging the current version of WineX. Our license allows you to do so, provided that none of the servers that serve the non-free archive are supported by advertising, or other commercial activity.

We have merely asked (politely, I think) that you not do so, out of concern for our ability to continue financing our ongoing development efforts, as well as to avoid confusion with our full download release which includes support for copy protection, and binary DLLs which we have the right to redistribute, but not to sublicense.

If Debian goes ahead and packages WineX despite our request, we will have to evaluate how that is affecting our financial situation, and determine whether we should change our license to restrict any future binary-packaged redistribution, regardless of commercial or non-commercial intent. It would certainly be our preference not to have to do so.