WWN Issue 287

This is the 287th issue of the Wine Weekly News publication. Its main goal is to prove the relativity of measurements of time. 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, 150 posts consumed 565 K. There were 58 different contributors. 29 (50%) posted more than once. 23 (39%) posted last week too.

The top 5 posters of the week were:

10 posts in 25K by Alexandre Julliard
10 posts in 30K by Mike McCormack
8 posts in 23K by Vitaliy Margolen
7 posts in 17K by Saulius Krasuckas
7 posts in 20K by Andreas Mohr

News: CodeWeavers Roadmap	08/06/2005	Archive
News This week at LinuxWorld CodeWeavers announced a product roadmap for 2005 and 2006. This is significant for a lot of reasons. We get glimpses of the direction CodeWeavers is heading from time to time, and if you follow the daily CVS commits and wine-patches you can glean even more info. However, rarely do we get a concise summary of what's going on. CodeWeavers drives a lot of the development behind Wine, especially when it comes to implementing new features from the ground up. I would include the full press release , but you can just as easily read it on your own. Just some highlights from that: Version 5.0 of CrossOver Office, to be released in September, will include Linux support for Microsoft Office 2003 as well as bottles, a programming concept that enables enterprises to manage and isolate deployments of one or more Windows applications on a customized basis throughout an enterprise. CrossOver Office 5.0 also offers major improvements to the software's MS Installer (Microsoft Installer) and COM (Component Object Model) portions, increasing by threefold the likely successful first-time Linux installs of applications from the vast Windows universe. ... CrossOver Office Version 6.0, expected to debut in Q4, will add even more capability to the world's leading and most reliable Windows-to-Linux application solution. Among the many computer improvements and new capabilities planned for 6.0 are support for Windows versions of many popular games; new copy protection protocols will also be supported that will enable users to reliably operate games along with products like Photoshop CS and Macromedia Dreamweaver MX 2004. ... With the move by Apple to the Intel chips in 2006, CodeWeavers will be providing a version of CrossOver Office for Macintosh users as well as extending its porting services to the Macintosh for Windows software developers. With this change, users and developers will be able to step over the applications barrier to entry and more freely choose their platforms, enabling a richer and more market driven computing landscape. Reading into that, it appears version 5.0 will be followed within a few months by version 6.0. If you're concerned about holding off until v6.0 comes out, remember that purchasing even the Standard version comes with six months of free updates. With regards to the rest of the news in there, you can imagine where we'll see development head - improved DirectX support, better NT/XP support, more MSI/DCOM additions, and lots of bugfixes. We'll also see development shift a bit over the next few months. With CXO 5 due in September we're likely to see CodeWeavers focus on stability and lots of bugfixes come through. Late September and early October might see a shift to implementing some new functionality. Keeping with the plan of a beta release at the end of September means we'll probably see some improvements in usability along the way.

News: CodeWeavers Roadmap

08/06/2005

Archive

News

This week at LinuxWorld CodeWeavers announced a product roadmap for 2005 and 2006. This is significant for a lot of reasons. We get glimpses of the direction CodeWeavers is heading from time to time, and if you follow the daily CVS commits and wine-patches you can glean even more info. However, rarely do we get a concise summary of what's going on. CodeWeavers drives a lot of the development behind Wine, especially when it comes to implementing new features from the ground up. I would include the full press release , but you can just as easily read it on your own. Just some highlights from that:

Version 5.0 of CrossOver Office, to be released in September, will include Linux support for Microsoft Office 2003 as well as bottles, a programming concept that enables enterprises to manage and isolate deployments of one or more Windows applications on a customized basis throughout an enterprise. CrossOver Office 5.0 also offers major improvements to the software's MS Installer (Microsoft Installer) and COM (Component Object Model) portions, increasing by threefold the likely successful first-time Linux installs of applications from the vast Windows universe.

...

CrossOver Office Version 6.0, expected to debut in Q4, will add even more capability to the world's leading and most reliable Windows-to-Linux application solution. Among the many computer improvements and new capabilities planned for 6.0 are support for Windows versions of many popular games; new copy protection protocols will also be supported that will enable users to reliably operate games along with products like Photoshop CS and Macromedia Dreamweaver MX 2004.

...

With the move by Apple to the Intel chips in 2006, CodeWeavers will be providing a version of CrossOver Office for Macintosh users as well as extending its porting services to the Macintosh for Windows software developers. With this change, users and developers will be able to step over the applications barrier to entry and more freely choose their platforms, enabling a richer and more market driven computing landscape.

Reading into that, it appears version 5.0 will be followed within a few months by version 6.0. If you're concerned about holding off until v6.0 comes out, remember that purchasing even the Standard version comes with six months of free updates. With regards to the rest of the news in there, you can imagine where we'll see development head - improved DirectX support, better NT/XP support, more MSI/DCOM additions, and lots of bugfixes.

We'll also see development shift a bit over the next few months. With CXO 5 due in September we're likely to see CodeWeavers focus on stability and lots of bugfixes come through. Late September and early October might see a shift to implementing some new functionality. Keeping with the plan of a beta release at the end of September means we'll probably see some improvements in usability along the way.

Summer of Code Projects	08/12/2005	Archive
Project Management After the Summer of Code projects were selected we never told anyone what they were. Google themselves haven't published anything because they're still sorting out paperwork (taxes, etc). So I've done a little legwork and tried to figure out what's going on. You might remember that Wine had 6 projects approved by Google out of a total of 18 recommended by a group consisting of Alexandre, Jeremy White, Dimi Paun, Lionel Ulmer, and Dan Kegel. Of those six, it appears one has gone MIA. So that leaves us with five: Jacek Caban has been working on implementing MSHTML using a Gecko rendering engine. We've covered this quite a bit over the past few months, including a status update two weeks ago in WWN #285 . The MozillaIntegration page has more info. Mike McCormack is mentoring this project. Theming support being tacked by Frank Richter, alluded to in Alexandre's last CVS drop and also covered in WWN #285 , has also been progressing. The work centers on hooking theming into Wine's controls and making them paint the current theme. This past week saw a lot of patches hit wine-patches and were subsequently committed by Alexandre. Kevin Koltzau is mentoring this one. Daniel Remenak has been working on improving DirectInput support in Wine. A few weeks ago we talked about the addition of force feedback code that was just starting to appear (WWN #285 ). Daniel is behind that work and there's even more stuff to come. Lionel Ulmer is mentoring this project. Now we get into two projects we haven't really discussed. Kai Blin is just starting to post patches to get authentication working in Wine. His wiki page, referenced in that link, contains a good project roadmap. There's a lot of code to wrap your head around and it sounds like he's getting there. The goal is to implement Microsoft's SSPI security API's using Samba's GENSEC module. Kai's mentor is Juan Lang. Finally, Ivan Pechorin is working on wire-compatible DCOM. Rob Shearman is mentoring the project. Although initial contact has been made, nothing has appeared yet. The project that appears to be dropped was proposed by Ivan Memruk involving Active Server Pages support.

Summer of Code Projects

08/12/2005

Archive

Project Management

After the Summer of Code projects were selected we never told anyone what they were. Google themselves haven't published anything because they're still sorting out paperwork (taxes, etc). So I've done a little legwork and tried to figure out what's going on.

You might remember that Wine had 6 projects approved by Google out of a total of 18 recommended by a group consisting of Alexandre, Jeremy White, Dimi Paun, Lionel Ulmer, and Dan Kegel. Of those six, it appears one has gone MIA. So that leaves us with five:

Jacek Caban has been working on implementing MSHTML using a Gecko rendering engine. We've covered this quite a bit over the past few months, including a status update two weeks ago in WWN #285 . The MozillaIntegration page has more info. Mike McCormack is mentoring this project.
Theming support being tacked by Frank Richter, alluded to in Alexandre's last CVS drop and also covered in WWN #285 , has also been progressing. The work centers on hooking theming into Wine's controls and making them paint the current theme. This past week saw a lot of patches hit wine-patches and were subsequently committed by Alexandre. Kevin Koltzau is mentoring this one.
Daniel Remenak has been working on improving DirectInput support in Wine. A few weeks ago we talked about the addition of force feedback code that was just starting to appear (WWN #285 ). Daniel is behind that work and there's even more stuff to come. Lionel Ulmer is mentoring this project.
Now we get into two projects we haven't really discussed. Kai Blin is just starting to post patches to get authentication working in Wine. His wiki page, referenced in that link, contains a good project roadmap. There's a lot of code to wrap your head around and it sounds like he's getting there. The goal is to implement Microsoft's SSPI security API's using Samba's GENSEC module. Kai's mentor is Juan Lang.
Finally, Ivan Pechorin is working on wire-compatible DCOM. Rob Shearman is mentoring the project. Although initial contact has been made, nothing has appeared yet.

The project that appears to be dropped was proposed by Ivan Memruk involving Active Server Pages support.

News: WGA on Slashdot 08/05/2005 Archive

News: WGA on Slashdot	08/05/2005	Archive
News Apparently the community loves the story about Microsoft discriminating against Wine users. If you remember back in late February and early March (WWN #263 and #264 ) there was a bunch of news items about Microsoft building a check for Wine into their Windows Genuine Advantage program. Before downloading things from Microsoft, this check must be made to ensure you're running on a legal operating system. Wine is not considered such a system and Wine users aren't entitled to download anything requiring that check (regardless of whether you actually own a licensed copy of Windows.) Now, the interesting thing is, Microsoft can use this to directly tie applications to their operating systems - a clear antitrust violation. With all the scrutiny being done by the EU these days, it'll be interesting to see if they would tempt fate and try it. This week someone figured out the WGA check once again succeeds and the news appeared on Slashdot. Just before that, the news was reported on wine-devel, It's actually a fluke that it works because the original check is still in place. Francois Gouget explained why it appears to work again: IIRC it's checking the location of the old Wine config registry key. This has all moved as part of the config file removal (and as was planned long before WPA came around). No doubt they will update their WPA checks at some point... If you've kept up with Wine updates over the past month and half you'll remember that most of the keys that used to live in `HKEY_LOCAL_MACHINE\Software\Wine\Wine` have since been moved to `HKEY_CURRENT_USER\Software\Wine` . The keys were moved back in June, then we switched over to using winecfg for configuration, and finally the config file was removed. It was the config file code that was responsible for populating HKLM\Software\Wine\Wine.

News

Apparently the community loves the story about Microsoft discriminating against Wine users. If you remember back in late February and early March (WWN #263 and #264 ) there was a bunch of news items about Microsoft building a check for Wine into their Windows Genuine Advantage program. Before downloading things from Microsoft, this check must be made to ensure you're running on a legal operating system. Wine is not considered such a system and Wine users aren't entitled to download anything requiring that check (regardless of whether you actually own a licensed copy of Windows.) Now, the interesting thing is, Microsoft can use this to directly tie applications to their operating systems - a clear antitrust violation. With all the scrutiny being done by the EU these days, it'll be interesting to see if they would tempt fate and try it.

This week someone figured out the WGA check once again succeeds and the news appeared on Slashdot. Just before that, the news was reported on wine-devel, It's actually a fluke that it works because the original check is still in place. Francois Gouget explained why it appears to work again:

IIRC it's checking the location of the old Wine config registry key. This has all moved as part of the config file removal (and as was planned long before WPA came around).

No doubt they will update their WPA checks at some point...

If you've kept up with Wine updates over the past month and half you'll remember that most of the keys that used to live in HKEY_LOCAL_MACHINE\Software\Wine\Wine have since been moved to HKEY_CURRENT_USER\Software\Wine . The keys were moved back in June, then we switched over to using winecfg for configuration, and finally the config file was removed. It was the config file code that was responsible for populating HKLM\Software\Wine\Wine.

Ejecting CD's	08/08/2005	Archive
Filesystems A lot of time patches come through and it's not immediately obvious what the ramifications are (at least to me.) For example, buried in a slew of CVS commits this week was this one from Alexandre: Added an unmount_device request that invalidates all file descriptors open on a given Unix device. With regard to "request", Alexandre meant to the wineserver. However, it didn't really catch my attention when it came through. However, it led Vincent Béron to ask: Does that mean we can now eject a CD even if an installer program keeps a file open on it? If so, should we have a wineeject to call that server request, or is it planned to be taken care of in some other way? Ah! Now that makes a lot more sense. In fact, that's a really useful thing to have. Alexandre explained that was the eventual goal, however there was more work to be done to make it reality. With regard to a separate program, Alexandre wasn't sure, That's one of the possibilities, it's not really clear yet what the user interface should be.

Ejecting CD's

08/08/2005

Archive

Filesystems

A lot of time patches come through and it's not immediately obvious what the ramifications are (at least to me.) For example, buried in a slew of CVS commits this week was this one from Alexandre:

Added an unmount_device request that invalidates all file descriptors open on a given Unix device.

With regard to "request", Alexandre meant to the wineserver. However, it didn't really catch my attention when it came through. However, it led Vincent Béron to ask:

Does that mean we can now eject a CD even if an installer program keeps a file open on it? If so, should we have a wineeject to call that server request, or is it planned to be taken care of in some other way?

Ah! Now that makes a lot more sense. In fact, that's a really useful thing to have. Alexandre explained that was the eventual goal, however there was more work to be done to make it reality. With regard to a separate program, Alexandre wasn't sure, That's one of the possibilities, it's not really clear yet what the user interface should be.

Registering DLLs	08/10/2005	Archive
Configuration If you have a problem installing a program, sometimes you can copy all the files directly off a Windows partition. If that actually works, you may notice you have a bunch of new registry entries for the various libraries, just as if an installer had put them there. What you're seeing is DLL registration. Wine's own DLLs do "self-registration" and Francois Gouget had a question about that this week: I'm relaying a question from Vincent Béron: we both had a look at the winapi_check output and noticed that the comments of these functions claim they are exported but in fact they are not: they are not mentioned anywhere in the spec file. Now if I look at the APIs exported by d3dxof.dll on various versions of Windows I don't see these APIs either. However it's possible that they are only exported in recent versions of DirectX and I'm not sure the DirectX dlls I have are that recent. So I think the question boils down to this: should the Dll(Un)RegisterServer functions be removed or should they be exported? Alexandre told him how to do it, They should probably be removed, and the corresponding classes and interfaces should be registered by some other dll. Christian Costa thought there was an easy way around it, All d3dxof dlls I have seen so far do not export them so I didn't put them in the spec (but forgot to remove the regsvr.c file). I don't know how d3dxof objects are registered in Windows but the wine.inf should be a good place for that.

Registering DLLs

08/10/2005

Archive

Configuration

If you have a problem installing a program, sometimes you can copy all the files directly off a Windows partition. If that actually works, you may notice you have a bunch of new registry entries for the various libraries, just as if an installer had put them there. What you're seeing is DLL registration. Wine's own DLLs do "self-registration" and Francois Gouget had a question about that this week:

I'm relaying a question from Vincent Béron: we both had a look at the winapi_check output and noticed that the comments of these functions claim they are exported but in fact they are not: they are not mentioned anywhere in the spec file.

Now if I look at the APIs exported by d3dxof.dll on various versions of Windows I don't see these APIs either. However it's possible that they are only exported in recent versions of DirectX and I'm not sure the DirectX dlls I have are that recent.

So I think the question boils down to this: should the Dll(Un)RegisterServer functions be removed or should they be exported?

Alexandre told him how to do it, They should probably be removed, and the corresponding classes and interfaces should be registered by some other dll.

Christian Costa thought there was an easy way around it, All d3dxof dlls I have seen so far do not export them so I didn't put them in the spec (but forgot to remove the regsvr.c file). I don't know how d3dxof objects are registered in Windows but the wine.inf should be a good place for that.

ALSA Hardware Acceleration Fix 08/09/2005 Archive

ALSA Hardware Acceleration Fix	08/09/2005	Archive
Multimedia Fixes Alex Villacis Lasso described a problem with ALSA and asked if anyone experienced the same thing: For a long time, I have been annoyed by a faint crackling that can be heard on the sound output of any DirectSound program when full hardware acceleration is enabled on the ALSA driver. Even after a patch I sent earlier (which corrected a bigger artifact), this crackling remained. Last night, I finally set upon removing this crackling, based on a comment in IDsDriverBufferImpl_GetPosition() in dlls/winmm/winealsa/audio.c, line 3302: `//* /FIXME/: snd_pcm_mmap_hw_ptr() should not be accessed by a user app. // // It will NOT return what why want anyway. // hw_ptr = _snd_pcm_mmap_hw_ptr(wwo->pcm);` I thought, maybe it is not returning the correct information for GetPosition, so that is why the crackling exists, since new samples are off-position from what they should be in order to guarantee a smooth sound. So I deduced, maybe the IDsDriverBufferImpl object can keep a simulation of a hardware pointer and use that instead of the (slightly incorrect) hardware pointer. My original intention was to remove entirely the need to reference _snd_pcm_mmap_hw_ptr(), since this is obviously an internal alsa-lib function and should not be used from inside the app (as the comment rightly indicates). However, I found out that the simulated hardware pointer tends to lag behind the real hardware pointer, and horrible mixups happen if the difference approaches or exceeds the length of the mmap buffer. So the simulated pointer is loosely kept close to the hardware pointer in the supplied patch. The good news: the patch sort of works (in my setup, at least, with Fedora Core 4). All the games I have (Japanese RPGs) now have smooth sound, unless the CPU load is too high. The bad news: the patch does nothing to make the dsound tests pass in Wine (but they were already failing before the patch :-) Also, can some ALSA or DirectSound guru comment on the specifics of why* the patch actually works? I am not entirely convinced that a mere loose updating of the simulated pointer from the hardware pointer is enough to have a smooth sound, but it works. I also don't understand how did the crackling appear in the first place, even though the direct hardware pointer was used. A few days later he found the proper fix and described it: Reading through my own previous explanation, I realized that the original crackling problem lies in the fact that the hardware pointer is ahead of the proper position for mixing. So, if the hardware pointer is set back by a fixed amount before reporting in GetPosition, this crackling could be fixed without resorting to the simulated pointer hack. The attached patch does just this. It is an one-line fix, and solves the problem just as well as the original patch, without being as sensitive to CPU usage as the first patch. So please ignore the previous patch and use this one instead.

Multimedia Fixes

Alex Villacis Lasso described a problem with ALSA and asked if anyone experienced the same thing:

For a long time, I have been annoyed by a faint crackling that can be heard on the sound output of any DirectSound program when full hardware acceleration is enabled on the ALSA driver. Even after a patch I sent earlier (which corrected a bigger artifact), this crackling remained. Last night, I finally set upon removing this crackling, based on a comment in IDsDriverBufferImpl_GetPosition() in dlls/winmm/winealsa/audio.c, line 3302:


    //* /*FIXME*/: snd_pcm_mmap_hw_ptr() should not be accessed by a user app. *//

    //*        It will NOT return what why want anyway. *//

    hw_ptr = _snd_pcm_mmap_hw_ptr(wwo->pcm);

I thought, maybe it is not returning the correct information for GetPosition, so that is why the crackling exists, since new samples are off-position from what they should be in order to guarantee a smooth sound. So I deduced, maybe the IDsDriverBufferImpl object can keep a simulation of a hardware pointer and use that instead of the (slightly incorrect) hardware pointer. My original intention was to remove entirely the need to reference _snd_pcm_mmap_hw_ptr(), since this is obviously an internal alsa-lib function and should not be used from inside the app (as the comment rightly indicates). However, I found out that the simulated hardware pointer tends to lag behind the real hardware pointer, and horrible mixups happen if the difference approaches or exceeds the length of the mmap buffer. So the simulated pointer is loosely kept close to the hardware pointer in the supplied patch.

The good news: the patch sort of works (in my setup, at least, with Fedora Core 4). All the games I have (Japanese RPGs) now have smooth sound, unless the CPU load is too high. The bad news: the patch does nothing to make the dsound tests pass in Wine (but they were already failing before the patch :-)

Also, can some ALSA or DirectSound guru comment on the specifics of *why* the patch actually works? I am not entirely convinced that a mere loose updating of the simulated pointer from the hardware pointer is enough to have a smooth sound, but it works. I also don't understand how did the crackling appear in the first place, even though the direct hardware pointer was used.

A few days later he found the proper fix and described it:

Reading through my own previous explanation, I realized that the original crackling problem lies in the fact that the hardware pointer is ahead of the proper position for mixing. So, if the hardware pointer is set back by a fixed amount before reporting in GetPosition, this crackling could be fixed without resorting to the simulated pointer hack. The attached patch does just this. It is an one-line fix, and solves the problem just as well as the original patch, without being as sensitive to CPU usage as the first patch. So please ignore the previous patch and use this one instead.

World Wine News