• Fake dll files created in the system directory to help installers.
• Desktop mode now properly supports multiple processes.
• Better type parsing in dbghelp.
• Several OpenGL fixes.
• A bunch of Unicode functions in advpack.

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.

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.

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.

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?

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 Have a look. Congratulations, Wine!

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.

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:

http://minimsft.blogspot.com/2006/03/vista-2007-fire-leadership-now.html#c114300669155836359

in which the following totally astonishing claim is made:

"Results: Client appcompat % hovering at <40% (GASP - INTERNAL INFO... better moderate this one out!!!!)"

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! :)

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.

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.

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?

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.

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:

• deb http://wine.lowvoice.nl/apt breezy main
• deb-src http://wine.lowvoice.nl/apt breezy main

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.

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

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.

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.

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:

Values:

• RequiredEngine - Use either setupapi or setupx, we will ignore it.
• CustomDestination - assigns ldids to extra directories.
• SmartReboot - same reboot options as LaunchINFSection.
• Cleanup - deletes the INF when the install/uninstall is finished if this is 1.
• CheckAdminRights - check if the user is admin if this is 1.

• RegisterOCXs
• UnregisterOCXs
• BeginPrompt
• EndPrompt
• RunPreSetupCommands
• RunPostSetupCommands
• DelDirs
• PerUserInstall

Backup/Rollback:

• ComponentName
• ComponentVersion
• BackupReg
• PreRollBack
• BackupPath

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 [1], 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:

run_adv_commands("InstallSection", phase1_map);
run_adv_commands("InstallSection", phase2_map);
run_adv_commands("InstallSection", phase3_map);

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.