Wine Traffic

This is the 124th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

News Apple News

Granted, Win4Lin isn't based on Wine, nor is it free (in either the source code or monetary sense), nor can you use it without a license for Windows. If you're only interested in running a Windows application on Linux and Wine won't work, you may be interested in it. I have no personal experience with it; the last emulator I used was the first release of VMWare. But I found this review of Win4Lin 4.0 interesting. It sounds like Netraverse has done a good job with it.

Some news came out of TransGaming last week (narrowly missing the last issue.) I suspected an announcement was on the horizon when I saw TransGaming was sharing space with Transitive Technologies at E3. The press release from May 22nd says, TransGaming Technologies, in partnership with Transitive Technologies, unveil their game-porting technology that can allow Windows-based x86 games to be simultaneously released onto multiple platforms. These include the Sony PlayStation 2, Apple Mac OS, set-top boxes, PDAs and wireless devices.. Okay, I'm not sure of the relative merits of playing a Direct3D game on a PDA, but I can understand how useful it would be to get PC games running on a PlayStation.

And seen in TransGaming's latest development update from May 17th: In other news, we recently made a breakthrough with support for Civilization 3 - it has just started to work with the current CVS tree. We hope to have it fully functional in the next WineX release. WineX 2.0.1 was also released on May 17th, I'm not sure if the Civ fixes made it in.

Project Management Andreas Mohr

Recently a lot of effort has gone into updating Wine's bug tracking system. Old cruft has been removed, new bugs have been entered, and old bugs have been dissected into smaller pieces. Andriy Palamarchuk posted a list for anyone wanting to get involved - and yes, you can contribute even if you can't code.

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.
confirm and research bugs in Wine Bugzilla http://bugs.winehq.com/
Add a 'Debunking Wine Myths' web page [ #606 ]

Examples of the easiest programming tasks available:

Help Wine hackers - document Wine debugging channels [ #638 ]
Improve RichEdit headers [ #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
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!

Note: some URL's converted to hyperlinks above

Andreas Mohr added a page discussing Wine myths at: http://www.winehq.com/about/index.php?myths. He reclassified bug 606 as Resolved.

Documentation Project Management Andreas Mohr Patrik Stridval

Want to start a flame war? Start a discussion among developers about licensing. Since we've already done that and have the mailing list to prove it, it was time to find a new topic. What better way than to comment on a 2 MB patch and ask for opinions about coding standards. Bill Medland fired the first salvo in response to a legitimate patch from Vincent Beron that stripped trailing whitespace at the end of lines, how about agreeing the size of a tab or removing them altogether or agreeing always to use tabs for progra, indentation or ....;

Dimitrie Paun replied, There no need to agree -- tabs are 8 spaces by definition. It's standard. As for the indentation size, I think it's time to agree on a size. It seems to me that most of the code is indented to 4 spaces. Vincent Beron felt tabs were better than spaces since they resulted in one character versus one for each space. Jeremy White jumped in to mention, Every good developer knows that tabs are evil, and that four space indentation is the way and the truth and the light...<grin> Dimi pointed out that Jeremy was wrong, Tabs are _not_ evil, tabs "defined" at anything else than 8 spaces *are* evil... The rest are good tabs!

Andreas Mohr voted for indents set to 4 spaces. Alexandre's opinion was, Mixing tabs and spaces should be avoided because it makes the diff output unreadable. And of course the one true indentation is 4 spaces, but I'm not going to enforce that.

A few people felt differently and mentioned that if tabs were used then the width of the tab could be set in the editor. Most Wine code is quite readable, so this thread probably didn't change anyone's minds. Vincent Beron went on to mention:

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.

He asked if Alexandre would accept a patch to remove extra characters. Alexandre replied he'd accept a script to do it. Vincent promptly provided a short 10 line shell script to parse all of the .c and .h files. Patrik Stridvall, the resident Perl guru, reduced it to, find . -name '*.[ch]' | xargs perl -i -pe 's/[ \t]+$//; s/;;+$/;/'. When it was all said and done about 25k of garbage was removed.

Internationalization

Leanne Tsang tested some of the new font stuff and found printing didn't work nearly as well as the client side font rendering, We tried to print Chinese on notepad but failed. We found that WINE default only writes western characters to postscript. Is that true?

Ian Pilcher replied first with the following suggestion:

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.

Tell the driver where to find the TrueType font by adding a [TrueType Font Directories] to your Wine configuration file. Something like this:
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.)

Ian described more details, then added, It's a lot harder than it should be.

Huw Davies hinted that a better solution was on the horizon:

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.

Ian liked the idea, but didn't want to lose support for the current method. He also thought there should be a way to turn off font embedding. Huw pointed out that only the glyphs needed were embedded and not the whole font file.

Ports ReactOS

Steven Edwards wrote a draft of a compiling Wine for ReactOS. However, it's generic enough that most of it applies to anyone interested in using the Mingw compiler. Parts of the following have been summarized, please refer to his Mingw_and_ReactOS_wine_porting_and_status_guide_v0.1.txt"> full document for all the details:

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.

Make sure you have the latest cygwin with win32api package.
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 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.

./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"
make depend
make implib
make tools
cd programs && make
make dlls
Build each dll manually.
make tests

Transgaming Transgaming TransGaming

I'll admit to seeing this one on Slashdot first. Coincidentally I had my moderation threshold set pretty high, so I even read some interesting replies. A debate on the debian-devel mailing list came about as the result of a package request for TransGaming's WineX code. Marc Leeman did a good job summarizing the thread. He outlined the history of Wine, it's recent license change, and TransGaming's use of the AFPL license. No real news. He then described the current problem facing the Debian developers:

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:

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.

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
Is the source free?
Well, to some degree, not the 3 RMS criteria, that's for sure
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).
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.
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.
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).

Gavriel State clarified several points concerning TransGaming's stance:

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.