This is the 171st release of the Wine's kernel cousin publication. It's main goal is to remind me to not write this stuff at the last minute, especially with a hang over. It also serves inform you of what's going on around Wine (the Un*x windows emulator).
Lots of news from TransGaming. Looks like these guys have been pretty busy lately. First off, they released Marble Blast Gold for Linux:
Marble Blast Gold comes with 100 whimsical and challenging levels, as well as the ability for advanced players to craft and share their own levels. Each level has "gold standard" set for the high score, so you can test your skills against the record `gold' times. Marble Blast Gold is sure to provide many hours of fun for the whole family.
Development is rolling along on the WineX branch. May's voting report discusses the items they're focusing on. Battlefield 1942 is receiving some special attention. Nvidia vertex extensions are being replaced with standard OpenGL ARB. Also worth noting is support for hardware acceleration on ATI FireGL drivers. TransGaming noted the following results from April's voting:
Here are April's top-ranked technology poll items:
- Support new features in XFree86 4.3
- DirectX 8 Support: Direct3D
- Windows Installer Support
- Improve 3D performance
- Improve support for copy protected games
- Better Support for InstallShield
And some of the top-ranked and top-voted games included:
- Command and Conquer: Generals
- Battlefield 1942
- Elder Scrolls III: Morrowind
- Get a racing game working
Support for Grand Theft Auto: Vice City looks promising for the next release.
Also in the news this week was a comparison of CrossOver Office with Win4Lin in LinuxWorld. Nicholas Petreley's conclusion:
CrossOver Office has matured to the point where I consider it equal to Win4Lin in desirability. Not equal in capability or ease of use, mind you, but equal in value considering the tradeoffs. If you don't want to own a Windows license, you can twiddle some settings when necessary, and get Microsoft Office running quite well. If your needs don't go beyond the applications CrossOver Office supports, then it's an unbeatable deal.
A thread started last week about holding an IRC meeting to discuss Wine development. Various people wrote in with their schedules and it appeared a few people (including Alexandre) were headed off on vacation. On Tuesday a decision was quickly proposed to hold it the next day. I was slightly surprised so many people were able to make it - about 45 developers showed up. An agenda was posted a few hours before the meeting:
- 0.9 TODO
- Is it complete
- Status update
- Dynamic mount of FS in wine
- Package dependency ( detect available packages at runtime)
- Use it to build Wine
- What we need to implement -shared
- Unicode resources
- dsp2make utility
- Remove wrapper
- Remove startup script
- Other support in tools
- What do we need to build everything as ELF?
- What else are we missing?
- Winecfg (right direction?)
- Can we get it in for 0.9?
- Cleanup (ole/, if1632/, etc.)
- Use script to fix "" -> <> in #includes
- Debug API (I hate the wine_ prefix)
- Move std controls to comctrl32
- Codeweavers merge status
- csgrep useful?
- Win32 / Win16 separation
- DLL separation
- Phase 1: only ntdll & kernel left?
- Phase 2: left for 1.0
- Close bug in Bugzilla?
- x11drv design
- 3rd party tools
- Support in ld for PE (what do we need?)
- Support in gcc for SEH
- What else?
Mike Hearn logged the meeting and made it available in real time on the web. He also kept a summary of it on his web page. Here's my own summary, in part based on Mike's notes. If you're interested in any of the issues listed above, I encourage you to look at the log. It's not too large and most the agenda was covered.
The to-do list for Wine 0.9 has remained mostly the same for several months now. The good news is things are gradually getting done. However, it was unknown whether that to-do list could actually be considered prerequisites for release. Alexandre felt a 0.9 needed to be architecturally complete - the tree cleaned up, a method for configuring Wine needed to be in place, etc. It also needs to get to the point where users can make useful bug reports.
Winecfg to configure Wine needs a lot of work and it's not clear how much work is being done. Someone named Mark (Mark Westcott, perhaps? mentioned he had done some work on it recently but hadn't submitted it. A few people encouraged him to submit whatever he had. Jaco Greef's original work was lost in a hard drive crash and no one wanted to see that repeated. Alexandre liked the idea of Winecfg and moving configuration into the registry, but he felt at some point the program should be made more modular. He didn't think that was necessarily something to worry about at this point though
The focus right now in the DLL separation area concerns NTDll and Kernel32. Eric Pouech and Alexandre are tackling it, but it's slow going. Eric mentioned one of the advantages that would come out of this would be adding support for dynamic configuration of drives, such as mounting, etc. Eric wasn't sure of exactly what needed to be done but knew the time to do it was during the file management rewrite. Mike McCormack had some test programs for the NT file API's he said he would send to Eric. DLL separation is also a blocker for Wineserver protocol stability. Alexandre didn't feel it was a showstopped for a 0.9 release.
One issue on the to-do list that remained undecided concerned using installers without desktop mode. On the to-do list it's called "window management rewrite". Alexandre seems the only one capable of doing the work, but he's unsure if it's high enough priority for a 0.9 release.
Detecting packages available at run-time is an issue being worked on. Right now OpenGL and ncurses have a "hard" dependency. Mike McCormack is working on the ncurses one. OpenGL is toggleable currently, but future plans include writing a common Direct3D core and making OpenGL a soft dependency. Shachar Shemesh wished there was a list of what packages were required by someone building Wine. He also mentioned some of his bidi work would require another library and asked for some advice on that (see part of the thread below.)
A lot of CVS activity has been going on lately and a few questions popped up concerning that. Right now a big merge is going on with CodeWeavers, Alexandre took a quick look at what's been done. Before the merge there were 21513 line insertions and 8388 deletions affecting 485 files. What remains are 10777 insertions and 4502 deletions on 182 files. However, not all of that is fit to be merged.
Integration with other projects was also a hot topic of discussion.
Miguel de Icaza showed up to represent Mono and discuss some of their recent Winforms
work (see the related thread in this issue for more info). Miguel was very
happy with their current patch because it didn't require much work for them.
Alexandre thought the real solution to Mono integration involved a deeper issue
and hacking Wine DLL's to turn them into ELF libraries wasn't the way to do it.
He went on to mention the need for a way to
turn a normal unix app into a winelib
app on the fly, basically by dlopening libwine. Jeremy White felt
the Mono project might be best off maintaining the patch outside of the Wine
So the status quo is that mono has a working Wine interface that is done with a hack.
The upside is that mono is productive; the downside is that it will be a maintenance drag.
Steven Edwards showed up to represent the ReactOS project. Currently Steven's
work involves splitting up 16/32 bit DLL's. He mentioned that the ReactOS project
was primarily concerned with a handful of DLL's:
ole* shlwapi, winmm, comctl32, comdlg32 and shell32.
At one point Dimi thought a dsp2make utility would be a useful addition and Steven
mentioned ReactOS had one. He went on to discuss some future plans,
My goal if the ReactOS guys can get more then winhello working is to have WINEs
shell32 and comctl32 running for Linux world.
All in all the meeting was quite successful and a lot of people were glad to be able to converse in real time about a lot of issues. Often times agreement in the Wine community comes in the form of no disagreement. Based on that, few people seemed to take issue with Wine's direction. Work is moving in parallel in a lot of different directions. As usual, you can most likely expect a Wine release some time in the next decade.
Jeremy Newman dropped a note to let everyone know he upgraded the Bugzilla database:
I have upgraded our installation of Bugzilla from 2.14 to 2.17.4. This solves some issues we were having.
- My Bugs link was not working
- Queries where busted.
From the looks of it, quite a bit has changed in this new version. So poke around and let me know an issues that crop up.
Yes, I plan to convert the bugs site over to the new design soon. Today I mainly wanted just to get it up and running.
A couple people complained they couldn't search for bugs without being logged in. Dimi thought it made a hard system to use even harder. Dan Kegel pointed out the reason for it was to prevent robots from harvesting email addresses. In the end, Jeremy removed the restriction so bugs could be linked from other pages.
There appears to be a bigger problem though. Apparently some bugs have lost a lot of the information associated with them. Jeremy thought the info still resided in the database but Bugzilla wasn't pulling it out. Random discussion in the tech meeting brought forth the suggestion of just dumping the current Bugzilla DB and starting over. Stay tuned, this thread will likely continue.
Mike Hearn posted a note about some work that OpenLink did for the Mono project:
OpenLink Software just announced their patches to Wine to allow mono to Wine directly, rather than by building a winelib wrapper. You can find some info and the patch here:
Warning - the patch is large (~75k) and has lots of #ifdef MONOs and such, but interesting nonetheless, regardless of how big a hack it is. It'd be interesting for Alexandre to review this sometime and evaluate how much would be required to make this mergable (assuming it is).
This goes back to our discussion earlier about what would be required for Wine to be dlopen()able for other projects to use it.
Vladimir Kaluzhny did a lot of the work. Miguel de Icaza mentioned he was happy with the outcome because it just solved the problem. Alexandre didn't feel the patch was ready for inclusion in the main Wine branch though. The decision for the Mono folks to maintain the patch separately.
Shachar Shemesh took up internationalization support for Wine
to provide bi-di support. We covered this last fall, and at the
time Shachar wanted to use the FriBiDi library. He took some time
off, but now he's back at it again. This time around he's considering
using a different library - International
Components for Unicode. Shachar also had questions about linking
in the library and where to call it from. Alexandre just wanted to
see something working and felt the rest could be worked out later,
As I said, I want to see working code first. And frankly, this ICU
library sounds pretty broken, I'm not sure you want to use that.
Shachar wrote back to describe the direction he's taking:
The static link question seems simple enough. I know that Mozilla uses ICU, and I think OpenOffice does too. Both of them don't have a runtime dependancy on it (or else it would be available for redhat, right?). This means they either static link it or imported the sources into their app.
As for the library itself, it boils down to this. It's a horrible library packaging wise, but it's the only one that has what I need, or even likely to have what I need in the foreseeable future. I have been holding off linking with FriBiDi hoping that Behdad, or anyone else, will put in the new interface (that will also let me implement some of GetCharacterProperties more obscure features). That is not likely to happen. I suspect FriBidi has fallen off the end of the earth. It does not implement mirroring, nor does it implement Arabic Shaping (wierd, considering that the maintainer is from Iran). It only supports UCS-4.
Also - like I told Mike H on IRC, static linking ICU will mean that we don't have to remove a dependancy from the Wine binary if FriBiDi ever catches up.
ICU implements both mirroring and shaping. It supports UTF-16, including not reordering the surrogates inside RTL runs (a tough one). It has already been updated for Unicode 4.0 (not the Debian version, of course, but the version you downloaded is). This is meaningless for BiDi (there was no change), but does indicate that the library is alive.
The compile time dependancy is nothing new. It will be there whether I static link or dynamic, and for whichever library I use. The fact that this is an uncommon library, coupled with the fact that I'm going to make it an optional compile time dependancy, means that there is a high chance that the Wine packagers will neglect to download it before building Wine packages. This is a bummer, as the resulting Wine will not support BiDi, but should have no other side effect.
I'm sure my head will be chopped by my fellow Israeli Wine users when they find out, but I'm hoping to divert their wrath torwards the packagers. It does mean that a visible "it is recommended that you have this installed on your system while building Wine packages" document is a desireable thing (like I said on the meeting). I'm willing to start one, but I don't know all of them.