Table Of Contents
|1.||(1 post)||News: Wine 0.9.11|
|2.||(5 posts)||Software Freedom Law Center Update|
|3.||(6 posts)||Non-Profit Status?|
|4.||(11 posts)||Using Photoshop Plugins with Gimp|
|5.||(1 post)||Vista App Compatibility|
|6.||(1 post)||New Kernel Option & Wine|
|7.||(1 post)||New apt Repository|
|8.||(24 posts)||Major Changes to Desktop Mode|
|9.||(5 posts)||Finishing advpack.dll|
This is the 310th issue of the Wine Weekly News publication. Its main goal is to let the golf clubs fight with the skis in the back of the pickup. 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 (http://www.winehq.org)
Mailing List Stats For This Week
We looked at 272 posts in 550K.
There were 91 different contributors. 45 posted more than once. 39 posted last week too.
The top posters of the week were:
1. News: Wine 0.9.11
(1 post) Archive Link: "News"
People: Alexandre Julliard, News
At the end of last week Alexandre released Wine 0.9.11. There were a bunch of notable updates including:
Check out our download page (http://www.winehq.org/site/download) for packages or download the source and compile.
2. Software Freedom Law Center Update
(5 posts) Archive Link: "Update on Software Freedom Law Center work"
Topics: Project Management
People: Alexandre Julliard, Scott Ritchie, Kai Blin
Last year we announced the Software Freedom Law Center (http://www.softwarefreedom.org/) was going to take on Wine as a client to provide legal assistance. (See WWN #260 (http://www.winehq.org/site/?issue=260#Software%20Freedom%20Law%20Center) for more info.) Well, a year has gone by and we haven't announced anything more concerning that relationship. Part of that was due to the SFLC getting off the ground and coming up to speed. Another part of it was due to things happening quietly behind the scenes. This week Alexandre announced what's been going on and things we can expect:
As announced at the last Wineconf, Jeremy and myself have been working for a few months now with the Software Freedom Law Center on a number of legal issues concerning Wine. We've been mostly quiet about it, so I thought I'd post a status update. There are two major tasks going on at the moment:
1. Code audit
We are doing an audit of the code base, to make sure we have proper records of all contributions, and spot any potentially troublesome code. The goal is to be able to show to people who don't want to dig through the source that we have done our development properly, and that they can use Wine without fear of legal trouble.
Currently, a survey is being sent out to people we have identified as major contributors, so that we can collect some information from them, like employers, license agreements, that sort of thing. This will enable us to build a complete track record for all contributions.
We are still processing the results, at this point the responses we received cover approximately half of the code base (many thanks to everybody who took the time to answer!). We'll be sending the survey to more contributors in the near future to try to get as close to 100% coverage as we can.
2. Non-profit organization
There are many advantages to having a non-profit organization for a project, for instance to allow tax-exempt donations, or hold assets like trademarks. However it's a lot of paperwork to do, so we never went to the trouble of setting one up.
Now the SFLC is starting an organization called the Software Freedom Conservancy, that will be officially launched on Monday. It's basically an umbrella non-profit that provides services to free software projects. By joining that organization, we will get all the advantages of having our own non-profit, without having to do any of the work, so that seems like a good deal...
There will also be the possibility of assigning our copyrights to that organization, which would make it easier to enforce the license, and provide some liability protection for developers. However this will only be done if most developers are comfortable with it, so I'd be interested to hear your feedback on this issue.
The part about non-profit status started some discussion and we'll cover that bit in next thread. The other issue that provoked discussion concerned copyrights. Here's my theory: there's no better way to get a bunch of software developers to care about law than to mention licenses or copyrights. Two comments stand out (keeping in mind IANAL nor do I play one on TV), the first from Scott Ritchie:
Fortunately, in order to enforce the license they don't really need rights to all of it, or even most of it - just rights to substantial portions of the useful stuff. Heck, Alexandre's contributions alone could probably be enough code to cover virtually the entire project.
And the second from Kai Blin:
I'm still unsure about this "assigning the copyright to someone else" thing. I'm living in the EU, where the copyright is split into "usage rights" and "creator's rights" and only the usage rights are transferable. I'm not into that legal stuff too much, so I'd leave that to experts to decide on, but I'd like to see a conclusive explanation on how this will apply to all of us new and old Europeans.
Given that this discussion started at the end of the week, I'd expect there to be a lot more comments in the next few days.
3. Non-Profit Status?
(6 posts) Archive Link: "Software Freedom Conservancy"
Topics: Project Management
People: Jeremy White, CodeWeavers
Regarding the Software Freedom Conservancy, a new thread was started by Jeremy White to discuss whether non-profit status should be considered:
I'd like to start a separate thread on this subject, so we don't lose the chance to discuss this.
I think it's a really good idea for us to join.
Right now, I manage the finances for 'The Wine Project'. The money literally flows into my personal bank account; I registered a 'Doing Business As' (DBA) in Minnesota so I could take checks and stuff as 'The Wine Project'.
It's not tons of money, but the account is now up to about $2400 (which is nice, as our Wineconf fees will be about that much). (Of course, without the embezzling, it'd be much more, but that's the way it goes <grin>).
Further, we had a challenge when we needed to manage the money from Google for the Summer of Code. Again, I handled it via CodeWeavers, but it wasn't quite 'right'.
So I think it would be better for us to have a professional organization to hold these funds, and to serve as an umbrella organization for us.
Candidly, I'm not sure I see any down side. They do all the nasty work, and we get someone to help us out with annoying admin chores. What's not to like?
I guess if they prove to be incompetent or unresponsive it could be an issue (like if we send them the $2400 but can never get a check cut). But right now I don't see much risk of that; the SFLC at least has been very responsive (which, considering what we're paying them [$0] is nothing short of miraculous).
Anyone else have any objections or other thoughts on it?
Obtaining real non-profit organization (http://en.wikipedia.org/wiki/Non-profit_organization) (NPO) status in the US generally means obtaining a tax exempt status. A lot of paperwork is involved and it can take a while, especially if you're not a lawyer. The issue has come up several times in the past and we've generally decided the hassle of setting everything up wouldn't be worth it. However, every year we find yet another situation where it would be nice to have it. Jeremy's email came late in the week and there wasn't much discussion other than a bunch of positive comments.
4. Using Photoshop Plugins with Gimp
(11 posts) Archive Link: "Photoshop plugins in Gimp on Linux using Wine!"
Topics: Winelib, Integration
People: Dan Kegel, Tor Lillqvist
Some rumblings began a few weeks ago about work to support Photoshop plugins in Gimp using Wine. Well, that's now a reality. Dan Kegel forwarded a message to wine-devel wit a link to the PSPI project:
I've been hearing rumblings about people using Wine to run windows photoshop plugins on Linux Gimp, but hadn't seen anything concrete. Well, here it is: http://www.gimp.org/~tml/gimp/win32/pspi.html (http://www.gimp.org/~tml/gimp/win32/pspi.html) Have a look. Congratulations, Wine!
Despite the success of Gimp, one of the drawbacks often cited is the lack of Photoshop plugins. Sure, there's about a million Gimp plugins and they're pretty awesome. But there's about a billion Photoshop plugins and some are incredible. Tor Lillqvist is the author behind PSPI and on the page above he describes exactly what a Photoshop filter is:
Photoshop plug-in filters (for the Windows version of Photoshop, which is what we are talking about here) are actually Windows DLLs, which are dynamically loaded into the plug-in host process's address space. They are files with the extension .8bf, though, not .dll. (GIMP plug-ins, on the other hand, are separate processes.)
Unlike GIMP plug-ins, 3rd-party Photoshop plug-ins don't use any common user interface library. (GIMP plug-ins use GTK+, obviously.) This is because 3rd-party Photoshop plug-ins are usually available both for the Windows and Macintosh versions of Photoshop. Typically each company uses some homegrown widget library, with a look and feel that is widely different than the normal Windows common control look and feel, or the GTK+ look and feel.
Ironically, we covered this topic about 2 and a half years ago in WWN #198 (http://www.winehq.com/?issue=198#Running%20Photoshop%20Plugins%20in%20the%20GIMP%20With%20Wine) . You can also find news about in on heise online in German (http://www.heise.de/newsticker/meldung/71270) or translated to English (http://translate.google.com/translate?u=http%3A%2F%2Fwww.heise.de%2Fnewsticker%2Fmeldung%2F71270&langpair=de%7Cen&hl=en&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools) via Google.
5. Vista App Compatibility
(1 post) Archive Link: "stir stir stir"
Topics: Microsoft Windows
People: Mike Hearn, Microsoft
Microsoft has rewritten the Win32 API four different times: NT, Win9x, WinCE, and Win32S. Are they doing it a fifth? More recent news from the company suggests they're not, but apparently whatever they're doing, it's not going well. Mike Hearn sent a link this week outlining internal problems with Windows Vista:
In the comments of this anonymous MS employees blogs post (great reporting here huh) we can find this post by somebody who claims to be on an appcompat testing team:
in which the following totally astonishing claim is made:
which is explained due to reduction of testing staff, loss of team morale and outsourcing of testing.
Can it really be true that the Vista builds have such appallingly low application compatibility? Anybody who has access to Vista builds want to comment on this?
Given they (now) have half a year to clean it up, does anybody want to take bets on what the score will be by the time it releases? I wonder what this number means (presumably that 40% of apps work perfectly out of the box), and I also wonder what our own appcompat score is.
Wouldn't it be scary if Linux ends up more Windows compatible than Windows is! :)
Given the subtle nuances in the Win32 API, nailing down all of the corner cases in 6 months sounds like an overwhelming task.
6. New Kernel Option & Wine
(1 post) Archive Link: "linux 2.6.16 and 2G/2G-split"
People: Jens Axboe, Sven Kohler, Alexandre Julliard
There's a new configuration option in the new 2.6.16 kernel that's apparently causing some problems with Wine. We probably won't see this appear with any vendor kernels, but some folks compiling on their own have apparently stumbled across it. The issue at hand involves the new VMSPLIT option. Here's how the kernel config file describes it:
If the address range available to the kernel is less than the physical memory installed, the remaining memory will be available as "high memory". Accessing high memory is a little more costly than low memory, as it needs to be mapped into the kernel first. Note that increasing the kernel address space limits the range available to user programs, making the address space there tighter. Selecting anything other than the default 3G/1G split will also likely make your kernel incompatible with binary-only kernel modules.
Jens Axboe explained a little more about when this could be helpful:
Basically the option boils down to how much virtual address space you want to assign to the kernel and user space. The kernel can always access all of memory, but in some cases part of that memory will be available as high memory that needs to be mapped in first (see references to kmap() and kmap_atomic() in the kernel). So whether changing the mapping or using highmem is the best option for you, depends entirely on what you run on that machine. If you require a huge user address space, then you don't want to change away from the 3/1 user/kernel default setting. However, if you don't need the full 3G of address space to user apps, then you are better off increasing the kernel address space range to get rid of the high memory mapping.
Right now this is marked as experimental, but apparently that hasn't stopped a couple different people from wondering why Wine is broken. Sven Köhler asked on wine-devel this week:
Since I upgraded my kernel to 2.6.16, wine segfaults immediatly after I start it. When I upgraded to 2.6.16, I also chose to use the 2G/2G vmsplit.
Is wine supposed to work with that config?
Alexandre actually replied on a different mailing list explaining the problem to someone:
It's a constraint of the Windows architecture. You can use a 2G/2G split when Windows version is set to win2k, but many apps still require win98, and in that mode we need 3G of user address space.
So there ya have it. This likely won't be a problem as long as none of the major distros ship with that option enabled, but it doesn't seem likely they will.
7. New apt Repository
(1 post) Archive Link: "Budget Dedicated has provided us with a server and a ton of free bandwidth"
Topics: Project Management
People: Scott Ritchie, CodeWeavers, WineHQ
Scott Ritchie announced a new server that's been donated by Budget Dedicated for use by Wine. Currently CodeWeavers hosts most of WineHQ and there's no plan to change that. We also have a few other servers used by the project, such as the wiki server hosted by lattica.com and a backup CVS server in Germany. Scott announced what the new server would be used for:
Just wanted to let everyone know that I finished setting up the server Budget Dedicated has given us. (http://www.budgetdedicated.com)
Currently it's hosting the APT repository:
Now, here's the cool thing: we're not confined by disk space anymore here, so we can host .deb packages in the APT repository for different distributions. This includes backports to Debian Sarge, as well as forward ports to new versions of Ubuntu like Dapper, or even whatever other crazy deb distro we want to package.
Budget Dedicated has also given permission for other things to be moved there, such as the Wine website (or parts thereof). The server is super fast and on a very fat pipe in the Netherlands, so for anyone in Europe it'll almost certainly be better to download things from there.
For now, however, it's just an APT repository, and the APT repository just has Ubuntu Breezy packages, however it would be very easy to add packages for other distributions or architectures - just send me an email and I can take care of it.
8. Major Changes to Desktop Mode
(24 posts) Archive Link: "Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process."
People: Alexandre Julliard, Tony Lambregts, Vitaliy Margolen
Sometimes progress in Wine comes with growing pains. In fact, it seems to happen more than most people would like to see. Alexandre committed a bunch of changes last week to enable interprocess desktop support in Wine and a lot of folks expressed concern it could lead to problems. First, here's Alexandre's commit notes that describe how to use the new desktop mode:
x11drv: Moved desktop mode handling to the explorer process.
Per-application desktop mode settings are no longer supported. Apps can be launched in a specific desktop window by using:
explorer /desktop=name[,widthxheight] app.exe [args]
If the named desktop already exists the app is launched inside it. The default desktop is cleverly named "default".
Tony Lambregts thought of some of the problems with it:
So if I understand this correctly all programs will share the same desktop. Is it also true that I cannot specify in winecfg that one program can run full screen and another in a desktop window.
If this is the case we will have a fair amount of crying over this one.
Vitaliy Margolen cited a specific example that could be a problem:
Ok so now say with Steam and all of it's games - it will be almost 100% unusable! Because we still haven't fixes managed/unmamaged windows. And Steam itself would be on top of everything. So the way people were able to work-around this is by putting Steam into virtual desktop. Now that means their game will run in the same desktop as well.
We really really really have to fix managed/unmanaged mode then. I can't even imagine how many people will stay with current or older Wine because of this patch.
Also I remember some users were using other two parameters of the desktop (top left corner - changing manually in the registry). I didn't seen anything that indicates they are still supported with this patch.
Alexandre confirmed those options were no longer supported. A lot of people then turned the discussion into whether hacks should be introduced to make things appear to work better. Most developers agreed the proper solution was to get the window management behaving correctly.
Those of you using desktop mode will need to update the way you launch your Wine process (desktop shortcut, etc) to take advantage of the new method.
9. Finishing advpack.dll
(5 posts) Archive Link: "advpack: The Plan"
People: James Hawkins
James Hawkins outlined his game plan for finishing off his work on advpack.dll. That library is responsible for working with INF files for managing software packages. He wrote:
As you've probably noticed, I've been working on implementing advpack for a couple months now; a lot of progress has been made, and I'm glad to say that the end is in sight. The rest of this email details the game plan for finishing advpack.
advpack has five main install functions: DoInfInstall, ExecuteCab, LaunchINFSection, LaunchINFSectionEx, and RunSetupCommand. They all basically do the same thing with minor differences in functionality. ExecuteCab extracts the files to install from a cab archive, LaunchINFSectionEx provides backup and rollback capability, and RunSetupCommand can also launch executables. When installing an INF section, advpack calls setupapi to install the base INF commands, such as CopyFiles and AddReg. After this, advpack parses the Advanced INF for advanced commands that are only installable when using advpack. These commands include:
Internally, there will be three main install functions: install_init, which will open the INF, make sure it's legit, and other initializations, spapi_install, which will call setupapi to install the base INF commands, and adv_install, which will parse the install section and run the provided commands. Each advanced command will be implemented by a function of similar name, e.g., RegisterOCXs would be implemented by the function register_ocxs, etc. All the command functions will be in a hash map, the key being the command name, the value being a pointer to the function that implements the command. adv_install will use setupapi to parse the entries of the install section, calling the function returned by a query to the hash map. According to INF Web , some commands are run before others, so there will probably be three or four maps, the functions in the maps grouped according to the order in which the commands should be run. For example, RunPreSetupCommands is to be executed after the BeginPrompt command, so begin_prompt would be in the phase 1 map, and run_pre_setup_commands would be in the phase 2 map. We would call the parser like so:
If a command in the install section is not in the map, we just ignore it.
This is The Plan so far, so if anyone has any ideas or suggestions, I'd love to hear from you.
There were a few small suggestions regarding implementation and James was quite receptive to the ideas.
Sharon And Joy