World Wine News

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.

Any objections?

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.

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.

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.

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:

./configure CC=winegcc LD=winegcc

You can turn off the win32 font backend, if you want, by doing --disable-win32-font . The main problem with the build system at this point though is that libtool decides that winelib cannot make shared libraries. So it builds static libs only. I'll look into fixing that later.

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.

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:

• Add a winver Windows Vista to make version checkers happy :-)
• Create the d3d10 lib and start the .idl file for header generation
• Write stubs for the functions to allow the app to create all the interfaces
• Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules
• Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d.
• Implement them as far as you feel like :-)

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.

Opinions? Suggestions?

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.

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" ?

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.

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.

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.

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?

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
John Smith, Vice President, ACME Corp.

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).

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.

Sample text for LGPL release

To the extent ACME Corporation ("Company") has any copyright interest in the contribution written by Jane Doe for the program "Wine", including original Wine code and documentation and support files, changes and enhancements to Wine and files, and any future modifications of Wine and files, Company hereby licenses that contribution under the GNU Lesser General Public License. Company affirms that it has no other obligation or interest that would undermine this license, or the use of the Wine, and will do nothing to undermine it in the future.

[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.

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

http://kegel.com/wine/winetricks

Usage: winetricks
[dcom98|fakeie6|mdac26|mfc40|mono|vbrun60|vcrun6|wsh51|wsh56jscript] ...

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.

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.