World Wine News

 * Beginnings of ddraw overlay support.
 * Many more crypt32 functions.
 * Improved support for tables in Richedit.
 * Support for NETWM window maximization.
 * Many installer fixes.
 * Tweaks for better PulseAudio support.
 * Various bug fixes.

We recently switched our survey system from a monolithic bi-yearly survey to a monthly rolling survey with a subset of the userbase each month, so we can get a continuous view of changes in hardware amongst our users.

We have 2 months of good data to date, Wine usage has increased from 0.33 to 0.36% over that month, but given the small number of Wine responses any increase would be in the margins of error. So Wine usage looks steady since last year amongst the Steam usebase as a whole.

As always the Steam Survey is an opt-in system so usual reporting biases could apply.

After some discussion with Jeremy and Alexandre about how nice it would be to have some automated way to check patches before Alexandre commits them, I decided to have a go at creating one.

What I have so far is a script that watches wine-patches and applies each patch to current git, then builds, and sends email with a subject line saying whether it worked, and a body containing a short "I'm a build robot" note, the patch, and the build log.

You can see the code at http://code.google.com/p/winezeug/source/browse/#svn/trunk/patchwatcher Its main failing is that it doesn't understand patch series yet, but I should be able to get that going by rewriting get-next-patch.pl to take a bit more context into account.

Right now it only emails the results to me, but it's probably nearly good enough to show results to other people.

Question: where should the results go? I could put them up on a web site and/or email them to the patch's author and/or email them to a dedicated mailing list (e.g. [email protected]?) and/or email them to wine-devel.
- Dan

Just where are you going to run that? To me, a script that builds just every patch is a serious security flaw; I suppose it wouldn't be very hard for someone to send a naughty patch that would take control of your machine. Something like editing a Makefile. I suggest you make it build patches in a chroot as a regular user, and copy over the chroot from a template every time a new patch is being built.

I've written some code for the chroot, though it has proven to be harder than I taught it would, especially because of all the development tools and libraries that need to be copied into the chroot. Right now it will only work on Gentoo, other distributions will require some fine-tuning of paths, especially the toolchain. Dan, if you tell me which distro you use, I'll try to get it working there as well.

To use it, you first need a second user in the system (not the one you're using!) that has read-access to files you create with default permissions (but no write access). Specify that user in the file "config" and run "patchwatcher.sh initialize_chroot". If everything goes well you will be able to get a shell inside the chroot with "patchwatcher.sh chroot-shell" or "patchwatcher.sh chroot-shell-owner" after running some commands displayed as root. After having a working chroot, use the initialize_tree command to setup the wine source (it's inside the chroot), and the "run" option to start continuous building.

For the moment, the results only go to a web page, http://kegel.com/wine/patchwatcher/results/ Most of the results there right now are just test messages so you can see how it will look when real patches with various problems are received. The scripts are a bit ugly, so expect problems to linger for the next week or so while I work out the kinks.

I think I fixed the charset munging, so patches of non-english stretches of code should work now. That was the last big source of false failure reports, so I'm going to enable email notification to people whose patches fail.

I'll probably clear the results page tonight to get rid of all the bogus failure notices caused by the charset conversion bug.

Hi folks,

Here's an update on the DIB engine that I've been working on for the last few months. This work has been made possible by the generosity of Google - so thanks go to them and of course to Dan.

You can find the code at http://repo.or.cz/w/wine/dibeng-hd.git

What's supported
---------------
- All dib section depths (including BI_BITFIELD support).
- Single pixel solid and dashed pens.
- The 16 rop2s.
- Solid and dib pattern brushes.
- A brunch of primitives for drawing onto all dib section surfaces.
- GDI32 apis: LineTo, Rectangle and PatBlt.
- An extensive test suite for all of the above.

What needs to be done
----------------
- Blitting (eg BitBlt, StretchBlt and StretchDIBits) - I have some hacks for these in my tree.
- ExtTextOut
- Many more GDI32 apis - a lot of these should be easy given that we have a set of underlying dib drawing primitives.
- Non-MM_TEXT mapping modes and world transforms.
- The initial interaction with GDI32 in BITMAP_SelectObject is hacky and needs some work.
- Lots more...

Note that at the moment it's essentially useless because of the lack of blitting, so unless you fancy hacking on that yourself then you probably don't want to bother fetching the tree.

I'm going to stop working on this for a while (lots of fun Outlook 2007 bugs for me to look at!), but will endeavour to keep the tree up to date with respect to WineHQ. If someone *does* want to hack on this then feel free to send me patches!

Thanks,
Huw.

Hello, Huw!
Did you hear anything about Jesse Allen's version of DIB Engine: http://article.gmane.org/gmane.comp.emulators.wine.devel/53234 (His version - http://repo.or.cz/w/wine/dibdrv.git ) Do you know why it was neccesary to restart solving this problem with your work instead of accepting and developing that version? We'd like to continue develop your version. When are you going to remain this project?

Thanks, Serge.

Mainly because I don't have time, I only have access to that git, and I have another job :) I did a bit of work on it last december that I didn't release. It's still on my hard drive. Huw's DIB tree is similar in concept to what I did. He was my mentor if you remember. But it doesn't mean what I was doing was usable. I trust Huw can manage building the basis of a DIB engine alot better than me. But I will likely download his tree and play around with it before school starts again.

An important thing to note about this work is that its architecture should be acceptable to Alexandre. So it can go into WineHQ, the only blocker being that it's not quite complete enough yet.

So that leads to the most important question:

what's needed to allow it to go into WineHQ?

Blitting I guess. Everything else in the list below? Can we avoid having to implement everything before we can commit it?

Could we forward unimplemented stuff back to x11drv now? That's one thing I never really did so my code seemed like it broke alot of stuff because of how much was missing.

Great! Please send me patches and I'll apply them. I'll probably merge with WineHQ on every WineHQ release.

I'm not planning on doing any work on it for a while, but will probably return to it at some point in the future.

While debugging some force-feedback issues ran into an interesting problem. The size of one struct from include/linux differs between 32-bit and 64-bit. That wouldn't be a major problem except that size is the part of the ioctl() request. Which results in EINVAL.

In more details:

input.h: #define EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect))

The simple test program: #include linux/input.h #include stdio.h int main(int argc, char * argv[]) { printf("sizeof(struct ff_effect) = %d EVIOCSFF=%#x\n", sizeof(struct ff_effect), EVIOCSFF); return 0; }

$ gcc test_size.c -o test_size && ./test_size sizeof(struct ff_effect) = 48 EVIOCSFF=0x40304580 $ gcc -m32 test_size.c -o test_size32 && ./test_size32 sizeof(struct ff_effect) = 44 EVIOCSFF=0x402c4580

The question is what do we do about it? I'm sure there are might be more cases like that.
Vitaliy

64-bit kernel should take care of translating the parameters between native 64-bit and emulated 32-bit modes. If that's not the case that's a kernel bug, and should be reported appropriately.

This guide seems rather well written: http://ldn.linuxfoundation.org/how-participate-linux-community Wine could probably use something similar.

By looking at both Rico's patch (http://bugs.winehq.org/attachment.cgi?id=15501) and this patch here by [email protected] (http://bugs.winehq.org/attachment.cgi?id=15361) I made a new patch which is kind of a combination of the two.

The patch gets rid of the UI bug (http://bugs.winehq.org/show_bug.cgi?id=13988), the part descriptions not showing bug (http://bugs.winehq.org/show_bug.cgi?id=14818) and the problem with the creature being hidden behind the grass. The problem with there being black squares on the creature when in windowed mode still exists (http://bugs.winehq.org/show_bug.cgi?id=14921).

I have run the program over 20 times and it runs every time correctly even if I change all the settings in ConfigManager.txt to "$High".

Regards,
Andrew

These changes may be correct, but they need a test. Take a look at dlls/d3d9/tests/device.c to see how the other tests look. I guess the changes are likely to be correct, but they have to be tested

I'm alittle confused, are you suggesting that if SetScissorRect receives a null value that if should default to the window size? or do you mean that perhaps GetScissorRect should call SetScissorRect and return a correct value instead of null?

If I understand you correctly it sounds like another problem and I think that checking should still be done on SetScissorRect as currently there is no checking being done where as the documentation states that D3DERR_INVALIDCALL is returned if SetScissorRect gets an invalid or null rectangle.

I'm currently rewriting the tests and patch so I'll let you know when I am done.

PS: I just looked at wine's implementation of GetScissorRect and it looks wrong as well. It should be returning D3DERR_INVALIDCALL if there is no value and perhaps maybe if scissor test hasn't been enabled.

No. {0,0,0,0} is a valid scissorrect. You could set it and get it. It is valid. Wines default scissorect is wrong, it has to be the size of the first swapchains backbuffer. I have a patch for this one. I'll send it later today.

Hi all,
As you may know yesterday was the pens down for summer of code 2008 Students are still allowed to write code, but it won't count for the mentors evaluation any more.

I would like to request from the mentors to fill in the final evaluation form and from the students to give a final write up: What went well? Did you meet the goals you set? Did you have fun? Is there anything we can do to make wines summer of code better and do you feel like you've become part of the wine community?

I also believe that students will have to fill in a final evaluation form as well, so get writing. ;-)

Cheers,
Maarten.

Hi everyone, I'm glad to say that my project to implement PrintDlgEx* went very well, as I've implemented almost everything by the deadline, and have test cases for every meaningful non-interactive scenario, AFAICT. The only feature that I have not had time to implement and test is the lpCallback member (see here: http://msdn.microsoft.com/en-us/library/ms646844(VS.85).aspx ), which is tricky due to the COM involved, and to the fact that there is nothing to test against. The only application that I know of that uses it is Windows Address Book, which does not work in Wine. The up side of this situation is of course that no application is affected by the stubbing of this feature, at least for now.

The list of applications that benefit from this new implementation includes mostly Microsoft software, such as IE6 (and probably IE7, for anyone who can get it running in Wine), Paint, and (Microsoft's) Notepad. Bibleworks has also been reported to require this function.

Plans for now and beyond: Get all this SoC code committed into trunk, then stick around for whatever maintenance that may be needed, and hopefully find another piece of the codebase that I would like to work on.

Overall, this summer of code has been a great learning opportunity for me and a great a experience.

Thank you!
-Gal

Hi all, I'd say my project has gone quite well. I've completed the main objectives of my project, including fixing the shell namespace implementation of Control Panel, improving the built-in control panel, and working on some new control panels to improve Wine's configuration options (Add/Remove Programs, plus a new Desktop control panel that I'm just tidying up ready to submit this week). While I will have university-related things to carry on with in September, I'm not intending to disappear completely - I'm hoping to split off and tidy up the multimedia settings in winecfg to its own control panel, too, and then tidy up winecfg a bit, making it more logical by restricting it to panels that are specific to Wine itself. So hopefully you'll still see me around a bit. :-)

Overall, I rather enjoyed Summer of Code, and learnt a lot about how to go about getting things done in an open source environment. Thanks to all, particularly my mentor Juan, for help and support along the way!

Cheers,

I think that my Summer of Code worked well. My task was to implement SAX reader and fix other bugs from bugzilla. SAX reader is currently complet enough for apps that I've tested. I've fixed many bugs from bugzilla. My main problem was that I couldn't reproduce many bugs. Also there are many bugs that wait for retesting or are not actual.

Regards, Piotr Caban

I greatly enjoyed summer of code, and I would like to think that I emerged a much better programmer than when I started, and yes, it was a lot of fun. A lot of bugs I saw for Gdiplus were installer bugs, so hopefully many more applications are installable under Wine -- but when people discover that there may be even more bugs opened :-)

While it can be annoying to have a patchset rejected five times, it's satisfying to fix myself it rather than see "based on a patch from..."; also I love the quality standards and peer-review that Wine has, as that made the code a lot easier to work with, because just about everything was in good shape when I got it, and I hope that the next person who looks at Gdiplus will think so too.

I will try to stay a part of the Wine community, but now that Summer of Code is done I have a lot fewer itches to scratch (Quicktime is my new target, but I have no idea how long that will take with school).

All in all, its been a blast. I would like to thank my mentor, Lei for helping me when I was completely stuck, Alexandre for dealing with me over IRC when I ask "why?", and everyone else who's posted comments saying "You can't do it like that".

My project didn't go bad, but I was only able to complete around 40% of what I expected to do in the begining, it turned out to be bigger than I thought. I'll try to finish it, but I probably won't be able to start working on it again until mid-september (exams, other projects abbandoned due to GSoC, etc), and then my progress will be much slower.

I really enjoyed this SoC, I was able to update my skills and learn to work in a big project. Thanks to kblin and to all the people who reviewed my code and bothered to suggest improvements :)

Cheers

I am happy that I got the complete main task that I wanted to get done, which was adding support for tables in richedit controls. There are some finer details that I would still like to finish, such as the selection behaviour within tables. I also need to fix a regression that has come to my attention, and review any of my patches that weren't accepted yet. All of this will be easier to do once I get back to my development computer, since I am still away from my home in Ottawa.

I was also able to spend time on plenty of other richedit control issues that weren't related to implementing tables. I found this helped me to get to know the richedit code quite well, as well as the code for wordpad which I often used for ad hoc testing. I did end up spending more time on this than expected, so I decided not to attempt working on windowless richedit controls during the GSoC coding period, however I only mentioned that I would work on windowless richedit controls if sufficient time were available.

I have also managed to learn a lot during this project, which was the first open source project that I had contributed to. I have also learned a lot more about development in a unix environment since windows was my main operating system until 9 months ago when forced myself to use linux primarily and confine windows to a VM.

I am also glad that I have the opportunity to continue working on Wine, since it is open source. Hopefully I will find enough free time during my Masters to continue contributing to Wine.

So, one of the things one learns when writing a patch robot is that flaky tests are very annoying.

Each time it gets a new git tree, the robot does five baseline "make -k test" runs, remembers the tests that fail, and doesn't penalize patches for failing any of those tests. See http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/patchwatcher.sh#92

Annoyingly, that's not enough. Some tests stubbornly refuse to fail during the baseline test runs. So I added a second, manual blacklist for those tests; see http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/patchwatcher.sh#63 The list is currently user32:msg.c user32:input.c d3d9:visual.c ddraw:visual.c urlmon:protocol.c kernel32:thread.c and will continue growing as I keep plugging away at getting the patch robot happy.