World Wine News
by Brian Vincent
- News: NetTunes
- Cairo Winelib Port
- DirectX 10 For SoC?
- Developing For Fun While Under a Contract
- Lotus Notes Printing Regression
This is the 325th issue of the Wine Weekly News publication. Its main goal is to heal. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org
This week, 204 posts consumed 517 K. There were 91 different contributors. 39 (42%) posted more than once. 34 (37%) posted last week too.
The top 5 posters of the week were:
Wine got an offhand mention in a PC World blog. Apparently there's some new software they're calling a mutual fund for music ". They said, It's Windows only for now (though the software works perfectly under Wine on Linux), and a Mac version's on the way.
Microsoft's standard routine for introducing new APIs is to ship the new libraries with applications for a few years until they're simply shipped with the operating system. We've seen this with a lot of apps including games that install new versions of DirectX and things like DCOM. A lot of you probably run into this right now with Windows apps that like to install MSDE (Microsoft's desktop SQL database) or MSXML. As long as the apps install the library and it works with Wine, there's no problem. Once it gets included with the OS we have to start thinking about supporting it with our own version. One library going through that transition is GDIPLUS . Dan Kegel asked:
An increasing number of apps need gdiplus.dll. Seems like it's time for Wine to include it. Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways.
Huw Davies agreed we should implement it, but wasn't sure the Mono code would be useful because, that's based on top of Cairo, whereas ours should be based on gdi32.
Ivan de Jesus Deras Tabora thought it still might be possible, But cairo has a win32 backend. So I think we can use mono-libgdiplus.
Dmitry Timoshkov wasn't sure that would be a good idea or even if Wine should tackle gdiplus:
Considering that gdiplus has a very poor performance under Windows because it doesn't have a dedicated DDI (device driver interface), adding gdiplus that uses a completely different backend into Wine would have even more performance related problems.
How is that possible to mention gdiplus at all, if even so basic functionality as a DIB engine still is not implemented?
Besides, my personal opinion is that implementing gdiplus is out of scope of the Wine project, just like MFC and similar libraries.
Dan then asked if it should be tackled if a DIB engine wasn't in place. Huw thought there was still a value in it because there was still a potential for optimization:
So I was talking to Ulrich [Czekalla] a few days ago and he was moaning bitterly that a gdiplus app was very slow because the native gdiplus draws lines one pixel at a time blitting into dibsections. Now while a dib engine would indeed help here, another approach would be to have our gdiplus draw lines in a more Wine friendly manner.
Of course when apps stop shipping gdiplus then we're going to need our own version anyway, just like any other dll. We'd like to have something useful before this day comes too.
It seems to me that gdiplus is a great project for an intern; it's scalable and not 'all or nothing' unlike the dib engine.
Rolf Kalbermatter then replied that a DIB engine doesn't necessarily need to be an 'all or nothing' project and outlined some steps that could be taken in that regard.
|Cairo Winelib Port||Archive|
Speaking of Cairo ...
Winelib ports are an interesting stress test both for other applications and for Wine. There was recently some work done to compile Cairo against Winelib. Jeremy White asked if anyone from Wine would like to delve into it a bit to see if there's any issues lurking:
I've chatted privately with Behdad, who doesn't have a ton of time, but would be willing to poke a bit further if he had some help.
I know that from time to time, people like to pick up this sort of project as a fun one, and I thought I'd see if I could spark someone into doing so with Cairo.
All this stems from a post by Behdad Esfahbod on the Cairo mailing list:
I got this idea to use winelib to compile the win32 backend on Linux. Carl and I both have the feeling that even being able to just compile (and not run/test) the win32 (and other) backends increases the quality of our releases because we would know that we've not broken something very silly for the least.
So I started looking into this. Documentation for winelib is four years old, to say the least. So I had to do lots of trials and see how wine builds its dlls itself to find my way out. In the end, it doesn't look that bad, though not as good as I thought either.
I pushed some changes to master that enable using winelib by just doing:
You can turn off the win32 font backend, if you want, by doing
Next problem I still have is that pdf2png and svg2png won't link now. Not sure why's that. Also note that binaries generated by winegcc are in fact a small script calling wine to load the actual .exe.so file generated. This is not much worse than what libtool already does for us, but we may be able to get to plain binaries since we don't use any native Windows binaries and so the wine loader should not be necessary.
Finally, running the test suite. First, for an unknown reason, it crashes if $DISPLAY is set. It does so in a gdi32.something_flush function. Interestingly, if I unset DISPLAY, it kinda works now. The font stuff doesn't look good, so I turned win32-font backend off and used freetype. The other major problem is that it seems like some kind of composite operations are ignored. The most evident effect of this is that about 50 tests fail, and most have a totally black output image. In some testing that I did, painting an image surface to a win32 surface works, but simply painting a solid color to it doesn't work. Wine bug...
Anyway, just wanted to give a heads up, and I'll be looking into this stuff a bit more, but those familiar with windows and wine stuff feel free to give this a try and improve it. Good test for wine in fact. I hope they pick this up and fix their stuff.
Jeremy asked him to submit questions to the wine-devel mailing list, but so far nothing has appeared.
|DirectX 10 For SoC?||Archive|
Summer of Code 2007
Have we been talking too much about DirectX lately? Some people think so and believe that's the main focus of development. It's not - there's a lot more patches for other areas of Wine coming in every day. We've been covering DirectX, actually mostly Direct3D, development simply because it was a stagnant portion of Wine for so long. For about four years we saw little to no development.
Wine's DirectX implementation contains enough features that we can begin working on DirectX10. Part of the recent rewrite of DirectX moved 3D rendering code into a common library shared by all versions of Direct3D. The huge advantage there lies in the ability to have collateral damage on applications. If a bug in Direct3D version 9 gets fixed, there's a chance it'll fix a bug for DirectX version 7 or 8. For that reason, it also means that an initial implementation of DirectX 10 is within striking distance. The rendering pipeline already works, we just need to hook up a new library to it. From there, all the new features of DirectX 10 can be built on top. Stefan Dösinger proposed someone should take this up as a summer of code project and outlined the tasks that need to be done:
Thinking about SoC I thought that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late.
My idea is to start a d3d10 implementation up to the following point:
I think the good thing about this is that there is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it.
Ivan Gyurdiev thought the project needed more definition:
Sounds too easy...if it included something like "HLSL compiler", that would be another story.
Also, you have to have a well-defined project to set completion criteria. "starting the infrastructure" does not define when the project is complete.
Stefan threw out some ideas:
Yeah, Henri had the same concern. We need proper completion conditions. How about: "Have d3d10 headers, a d3d10.dll with creator functions, functions calling wined3d where applicable, at least a stub for each other function and routine tests for reference counting and things that can be checked on the implemented functions" ?
You might be curious what the HLSL compiler does that Ivan referenced. Well, HLSL , Microsoft's High Level Shader Language, allows shaders to be constructed that are essentially miniature programs that describe how to throw pixels on a screen. Another method for that is GLSL , a similar method based on OpenGL and included in the 2.0 spec. Ian Macfarlane pointed out a few months ago that there's an HLSL to GLSL converter.
Anyway, back to the topic at hand: DX 10. Ivan wasn't sure DX10 should count as a SoC project:
Yes, I am sure wine will benefit greatly from a d3d10 stub, mapping 1-to-1 to wined3d where possible, but is it really a project that requires a lot of creativity and the whole summer to do ? I think something that adds new functionality and can't mirror d3d8/d3d9 would be better.
A bunch of people disagreed and felt it would be a good project. Scott Ritchie said:
Why do SOC challenges need to require creativity and be challenging? Seems to me like the BORING projects are the best way for people to learn.
This is especially so when no one else wants to do them. Like, say, writing test cases for all the functions we already have.
Stefan went on to describe why DX 10 is something to be looked at sooner rather than later:
The idea is that our main Direct3D engine, wined3d, is shared between all Direct3D versions, from Direct3D 1 to Direct3D10. Admittedly, the core functionality that is equal between d3d1 and d3d10 is comparably small, and the part that exists should work pretty well by now. But work on d3d10 games can definitely fix bugs in d3d9 apps accidentally, in the same way the d3d7 merge fixed bugs in wined3d that affected d3d9 apps.
Also consider that d3d10 may need some architectural changes to wined3d. I think it is better to make them now and when further optimizing it have things in the d3d10 style than to drive everything to d3d9 and see in a year that we have to turn a few core parts upside down.
Of course having one SoC project on d3d10 does not exclude someone else who wants to do something do a SoC project on d3d9 :-) . Ideas would be Overlay support for movie players or the d3dx9_xy helper DLLs (although those are maybe out of the scope of wine). Or even a completely different area of DirectX. DirectSound, DirectPlay, ...
One problem is nowadays that wined3d is pretty advanced already, and the learning curve is rather hard already. D3D10 is in my eyes an opportunity of an exciting project which allows a new developer to grow into wined3d. I personally won't start hacking on d3d10 immediately, I'll continue to work on d3d9 and below apps. The state of d3d9 does not justify that yet.
And I think that *Direct3D* isn't in a bad shape nowadays. We recently had a nice success when that new Command and Conquer game came out, and ran on the day it hit the shelves. Wine is getting the public opinion that it does better on games than Cedega. What we should not shout out loudly is the shape of other DirectX stuff. DirectSound is an issue, although I must say that Maarten Lankhorst is doing nice work on winealsa :-)
Regarding applications, I have a few of them: BasicHLSL10, GPUSpectrogram, PipesGS, Bin, HDRFormats10, ShadowVolume10, CubeMapGS, HLSLWithoutFX10, SimpleSample10, DisplacementMapping10, Instancing10, Skinning10, DrawPredicated, MotionBlur10, SoftParticles, EmptyProject10, MultiStreamRendering, SparseMorphTargets, FixedFuncEMU, ParticlesGS, Tutorials
21 applications, so it is a widely used API. Oh ooops, those are just the sdk demos. And only 19 of them, bin/ and EmptyProject10/ do not really count...
Jokes aside, there aren't any dx10 apps yet, except some demo apps. The first one to be expected is Halo 2 on April 24th afaik. The only thing is that MS has created some hype around dx10 recently. It would give us some nice publicity if the Halo 2 box states "Runs on Windows Vista and higher" and winehq.org says "Runs Halo 2 on Linux, MacOS, Windows XP and earlier"
I do not think d3d10 hardware is required yet, the reference rasterizer should work for the start. It is a long way to get any actual rendering going. Regaring Vista, the nice thing is that Students get Educational licenses cheap. But the license should be checked carefully. I for example may use it only for educational purposes. As I am working for CodeWeavers my hacking on wine isn't purely for educational purposes. No idea if SoC can be considered an educational thing.
So there ya go. Somewhere in there lies a rough project outline for DirectX 10.
|Developing For Fun While Under a Contract||Archive|
This might be of interest to other free software projects.
The topic came up of what to do when you've signed a contract with a company to do development and then you want to work on a free software project. Even though Wine may not be related to the work, there's still a concern that big, evil corporate lawyers could still put pressure on a developer. In fact, something like that did happen with Wine about 4 years ago. We had a Quartz implementation, Microsoft's library containing codecs to play video, and the developer asked that it be removed from Wine. Part of the reason in that case apparently had something to do with an employer. Anyway, the email that arrived on wine-devel from Nathan Williams asked:
I have been planning to do some work on wine for a while now, but after I started working I got myself a new programming job.
I'm worried about the copyright of any external work I do, so I need a little advice.
What do I need from my employer to clear me to work on wine? Is something verbal ok, or should I get it in writing?
Well, not too many projects have the luxury of free legal counsel like we do, so you might be interested in the answer Jeremy White received when he posed this question to them:
I asked James Vasile, of the Software Freedom Law Center, to comment on this. (For those who don't recall, the SFLC officially represents the Wine project on legal matters).
This is essentially what he had to say (and James, correct me if I get anything wrong :-/):
If you are employed to do programming (even at a university), or have made an agreement with your employer, school or anyone else saying it owns software you write, then you and we need a signed document from them disclaiming any rights they may have to the software. The disclaimer should be signed by a vice president, general manager, or anyone else who is authorized to assign software owned by them. Here is a sample wording:
As a general rule, get everything in writing. The below will suffice. Email is fine, paper is better. The project needs a copy (or, better yet, the original) of the document.
Here's some sample text:
ACME Corporation ("Company") hereby disclaims all copyright interest in the code written by Jane Doe for the program "[insert name of program]" ("Program"), including original Program code and documentation and support files, changes and enhancements to the Program and files, and any future modifications of the Program and files. We do not consider the code as work made for hire for us. Company affirms that it has no other intellectual property interest that would undermine this release, or the use of the Program, and will do nothing to undermine it in the future.
[signature of John Smith], 30 March 2006
Ideally, you would obtain this in writing and then get this on to James (vasille - at - softwarefreedom - dot - org, or use snail mail/fax from their web site).
Shachar Shemesh thought of a different, but similar scenario:
Wouldn't a paper saying they keep their rights, but approve the LGPL distribution also work? Would that still require us to have a written statement? After all, we do not require written statements from other people.
James Vasile replied with:
Sample text for LGPL release
[signature of John Smith], 30 March 2006
John Smith, Vice President, ACME Corp.
And, yes, a writing is still needed. Documentation of the right to release code is important. Employers are usually different from authors, both in their interaction with the copyrights and their interaction with the project, hence the different treatment.
There were other warnings by others on the list that if there's a concern that if an employer had an interest in the code, then use of work resources shouldn't happen. For example, don't use your work laptop to write code or send it to a mailing list using a work email address.
Then there's others of us who've blatantly used work resources for years to covertly work on Wine. In fact, I'd just like to take this opportunity to thank my former employer for the hundreds of hours of labor they unwittingly donated to free software development.
In a move that's sure to be vilified, Dan Kegel wrote a script to automatically install some native components:
OK, I've been doing bug triage on and off for years, but just recently I've gotten to the point where I'm tired of going to the NativeDCOM wiki page to remember how to try an app with native dcom just to see if the bug in question is a COM bug.
So I wrote a trivial script to automate installing that plus a bunch of other redistributables. A draft is at
It's a bit like a programmer's version of winetools: it's so commandline-crufty that normal users won't go near it, but it's simple enough to extend that it will probably end up being pretty handy for anyone working on triaging bugs that appear to be due to missing redistributable libraries. Oh, or commonly-needed registry entries.
So wait... this makes things easier, why is it bad you ask? Well, installing native components has led to lots of problems in the past. (It's also led to millions of successful program installations.) Any time native components get installed they simply provide less of a reason to fix a problem in Wine's builtin libraries. At some point in the near future people will start giving advice like, "Go visit this web page, download this script to automatically install dcom, then run Wine."
|Lotus Notes Printing Regression||Archive|
One thing that seems to get overlooked these days with open source projects is the unprecendented level of access you have to the developer community. The following is a good example. Pedro Araujo Chaves ran into a regression with Lotus Notes and did a little research to figure out what caused it:
There's been a regression in printing in Lotus Notes R5 somewhere between wine-0.9.27 and wine-0.9.28: it seems that the presence of an inline picture (in this case, a logo) in the mail stationery prevents all text (including header text) from being printed.
Odd as it may seem, my regression testing pointed commit 21635133fb271405fefd6bce3078cf971e84c426 as the cause. I positioned my tree just before it, and the mail printed okay; I applied it, the mail came out blank again.
As I still couldn't see any direct relation between the said commit and this issue, I'm posting here in the hope someone would be able to figure out what's going on. If that's the case, then, I'll file a bug report and upload a database containing a message with one of these problematic stationeries.
In about a half hour Alexandre replied with a two-line patch to the Postscript driver and Pedro confirmed it worked.
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License, version 2.0.