Table Of Contents
|1.||21 May 2002 - 29 May 2002||(4 posts)||News: Win4Lin Review, TransGaming News|
|2.||21 May 2002||(1 post)||How *You* Can Help Wine|
|3.||28 May 2002 - 29 May 2002||(25 posts)||Code Practices|
|4.||20 May 2002 - 26 May 2002||(7 posts)||Printing Multi-byte Characters|
|5.||25 May 2002||(1 post)||Compiling Wine with Mingw|
|6.||22 May 2002 - 27 May 2002||(73 posts)||WineX and Debian|
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).
Mailing List Stats For This Week
We looked at 274 posts in 951K.
There were 68 different contributors. 42 posted more than once. 47 posted last week too.
The top posters of the week were:
1. News: Win4Lin Review, TransGaming News
21 May 2002 - 29 May 2002 (4 posts) Archive Link: "News"
People: TransGaming, , Apple, News
Granted, Win4Lin (http://www.netraverse.com) 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 (http://www.osnews.com/story.php?news_id=1112) 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 (http://www.transgaming.com/news.php?newsid=37) 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 (http://www.transgaming.com/news.php?newsid=36) 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.
2. How *You* Can Help Wine
21 May 2002 (1 post) Archive Link: "Want to help Wine project?"
Topics: Project Management
People: Andriy Palamarchuk, 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:
Examples of the easiest programming tasks available:
Easy, aren't they?
Do you need more choice?
If you want to know more - just ask.
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 (http://www.winehq.com/about/index.php?myths) . He reclassified bug 606 as Resolved.
3. Code Practices
28 May 2002 - 29 May 2002 (25 posts) Archive Link: "RE: Stripping of whitespaces at the end of lines"
Topics: Documentation, Project Management
People: Bill Medland, Dimitrie Paun, Jeremy White, Alexandre Julliard, Vincent Beron, Patrik Stridvall, 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 '#topofpage'
. When it was all said and done about 25k of garbage was
4. Printing Multi-byte Characters
20 May 2002 - 26 May 2002 (7 posts) Archive Link: "Asian characters printing - not supported"
People: Leanne Tsang, Ian Pilcher, Huw Davies,
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.
[TrueType Font Directories]to your Wine configuration file. Something like this:
[TrueType Font Directories]
"dir0" = "/usr/X11R6/lib/X11/fonts/TrueType/index.html"
"dir1" = "/usr/share/fonts/default/TrueType/index.html"
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.
5. Compiling Wine with Mingw
25 May 2002 (1 post) Archive Link: "V0.1 WINE Mingw and ReactOS porting and status guide."
People: Steven Edwards, , 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 (http://www.winehq.com/hypermail/wine-devel/2002/05/att-0707/01-Mingw_and_ReactOS_wine_porting_and_status_guide_v0.1.txt) 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.
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"
cd programs && make
6. WineX and Debian
22 May 2002 - 27 May 2002 (73 posts) Archive Link: "Re: Bug#147303: ITP: winex -- A DESCRIPTION"
People: Marc Leeman, Gavriel State, , 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.
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.
Sharon And Joy