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 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 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.
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:
The project that appears to be dropped was proposed by Ivan Memruk involving Active Server Pages support.
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.
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.
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.
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 fixed 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.