Table Of Contents
|1.||12�Feb�2005�-�18�Feb�2005||(1 post)||News: Microsoft Looks for Wine|
|2.||16�Feb�2005�-�18�Feb�2005||(14 posts)||Microsoft's Wine Check: Details|
|3.||14�Feb�2005||(3 posts)||COM & InstallShield|
|4.||18�Feb�2005||(28 posts)||DirectX 9 and HalfLife2|
|5.||12�Feb�2005�-�15�Feb�2005||(6 posts)||Window Management Problems|
|6.||11�Feb�2005||(5 posts)||Drive Detection|
|7.||18�Feb�2004||(1 post)||distcc Patch|
|8.||11�Feb�2005||(3 posts)||LQ Members Choice Awards|
This is the 262nd issue of the Wine Weekly News publication. Its main goal is to ponder beaches. 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 267 posts in 937K.
There were 86 different contributors. 48 posted more than once. 29 posted last week too.
The top posters of the week were:
1. News: Microsoft Looks for Wine
12�Feb�2005�-�18�Feb�2005 (1 post) Archive Link: "News"
People: Slashdot,�,�Ivan Leo Puoti,�Microsoft,�WineHQ,�News
Slashdot covered a story that first appeared on wine-devel and WineHQ about Microsoft checking for Wine. The Slashdot story (http://linux.slashdot.org/article.pl?sid=05/02/17/1318212&tid=125&tid=109&tid=106) read:
IamTheRealMike (http://navi.cx/~mike/) writes "In January, Microsoft announced a new anti-piracy initiative (http://www.microsoft.com/presspass/press/2005/jan05/01-26GenuineAdvantagePR.asp) called Genuine Advantage. From this summer onwards all users of Microsoft Downloads (http://downloads.microsoft.com/) will be required to validate using either an ActiveX control or a standalone tool. Yesterday Ivan Leo Puoti, a Wine developer, discovered that the validation tool checks directly for Wine (http://winehq.com/hypermail/wine-devel/2005/02/0441.html) and bails out with a generic error when found. This is significant as it's not only the first time Microsoft has actively discriminated against users running their programs via Wine, but it's also the first time they've broken radio silence on the project."
Well, that's a pretty good summary of the news. The actual thread is covered in the next section, so we'll save the details for that. Surprisingly, most of the armchair lawyers stayed at home and didn't ponder some of the ramifications.
As far as Wine is concerned, Microsoft certainly chose an interesting time to try this out. In the past, several free downloads such as DCOM and MSI were necessary to get a lot of apps to install and run. However, work is progressing at a phenomenal rate in both of those areas. By the time this tool is required, Wine's own builtin versions will be more than adequate.
It sure is nice to be noticed.
2. Microsoft's Wine Check: Details
16�Feb�2005�-�18�Feb�2005 (14 posts) Archive Link: "Microsoft genuine downloads looking for wine"
People: Ivan Leo Puoti,�Mike Hearn,�,�Microsoft,�Shachar Shemesh,�News
What spawned the news above originated with a post from Ivan Leo Puoti:
As some of you may know, Microsoft is planning to totally restrict access to the Microsoft download center to all non-genuine Windows users. So you would expect some check for pirated copies of Windows to be involved. If you visit the download center with IE you get an activex control, but if you try with Firefox, you'll have to download a little program, that returns a code you have to copy into the download page, to get access to the download you selected.
By quickly looking at the program, I noticed it looks for a registry key, this key is...
the Wine configuration key.
The Windows Genuine Advantage program press release
says that in the second half of 2005, all users connecting to the Microsoft download center or to Windows update will have to validate their copy of Windows. Interestingly if you run the validation program on wine, and the version of windows you're emulating is prior to 2000 or is windows server 20003, you get a message saying a validation code couldn't be found, because of technical difficulties or because you're running an unsupported operating system. If you set winver to win2000, you'll get a validation code that doesn't work, this may be a bug in wine, or in the validation program. A valid and working code is returned if the version is set to XP.
Still, even if this is only an initial attempt, they appear to want to discriminate Wine users, while this may be acceptable for operating system components/updates, this is probably a violation of anti-trust law for all other downloads.
It's also the first time Microsoft acknowledges the existence of Wine.
Ivan provided a link showing the Wine registry key in the executable, http://spazioinwind.libero.it/nonsolomicrosoft/GenuinceCheck.html (http://spazioinwind.libero.it/nonsolomicrosoft/GenuinceCheck.html) and provided an MD5 hash of the program: 05499eaa4d4f55af32f5b14561ee7e55. Other developers verified they found the same thing. You should try it too; it's fun for the whole family.
Shachar Shemesh noted that it would be relatively simple to work around the problem. Mike Hearn thought it would be a waste of time:
I don't think we want to go there. I demonstrated a way of checking for Wine to Rob last night that we really cannot fix or workaround, and if I can think of it they certainly can too.
Basically if we start integrating workarounds into Wine, it'll lead to an arms race we cannot possibly win. Better to ensure our users don't need anything from that website.
And now, back to our regularly scheduled program of Wine development news.
3. COM & InstallShield
14�Feb�2005 (3 posts) Archive Link: "Re: working installshield?"
Topics: RPC / COM / OLE
People: Marcus Meissner,�Mike Hearn,�Robert Shearman,�,�Ove K�ven
Marcus Meissner wanted to know exactly when the huge COM rewrite will wrap up. Or rather, when it will make a lot of things work again:
Is there any chance to have a working installshield at some time?
I don't really want to fall back to the December or even earlier WINE releases for our spring SUSE Linux product ;)
Mike Hearn gave a quick update on where things were at:
Rob has a patch that should (touch wood) fix the remaining issues. I'm not sure when he is going to submit it but it looked pretty complete last time I saw it.
We may also need to adjust the RPC runtime so that it runs a message loop (for re-entrancy), but I don't think that'd be too hard.
So, maybe a week or two? It certainly should not be broken for more than month.
Rob followed up a few hours later with the patch:
This patch is significant as it changes the RPC backend of our COM implementation from using named pipes to using any transport implemented by the RPC runtime. As a matter of coincidence, this patch is numbered 69, which is my favourite number, and this patch is my favourite patch. This is because it is one of the last steps in getting our architecture right and consistent with the way the native version does. Not only this, but it should also solve some real problems with having way too many threads (one and only one per apartment) and some complex deadlocking situations caused by this. It also significiantly reduces the amount of code in the file and reduces most of it to simple wrappers around the RPC runtime functions.
|5 files changed, 369 insertions(+), 647 deletions(-)|
Rob verified Mike's initial observation about needing a message loop as well as gave Marcus a solution if things weren't worked out:
I haven't been testing against InstallShield for a while, but last time I checked it was hanging because we do not process window messages during RPCs. If you want to implement this yourself, I can give you details on how to do this. I will get around to this eventually, but at the moment I have other priorities. If the worst happens and InstallShield is still not working, then you can still ship the December ole32 with the most recent Wine.
4. DirectX 9 and HalfLife2
18�Feb�2005 (28 posts) Archive Link: "Halflife II"
Topics: Build Process
People: Jonathan Wilson,�Oliver Stieber,�Andreas Mohr,�Roderick Colenbrander,�Roderick Colenbrader,�,�Transgaming,�Microsoft,�TransGaming,�cvs
A long thread about World of Warcraft came up this week. I won't go into much of the details of that one, but if you're a WoW fan you may way to read the thread (http://www.winehq.com/hypermail/wine-devel/2005/02/0391.html) . In the course of the discussion, Jonathan Wilson asked, " Also, how does the work we have here in this project compare to what TransGaming have as far as Direct3D functionality? "
Oliver Stieber gave a ran through the status:
on the downside..
on the up side.
With the exception of a few areas performance is on-par with cedega.
I'm looking at offscreen surfaces soon.
There are lots of easy performance boosters that can be implemented at somepoint.
Of the games I've tested this version works more often than Cedega, but that doesn't mean too much since most games are failing with non DirectX related issues.
I've been developing with an ATI graphics card, so there shouldn't be the odd dropout because of ATI driver bugs that happens with Cedega.
Oliver went on to describe an area he may focus on:
I'm not sure what I'm going to work on next, possibly more 'completeness' and performance in DirextX 9 to give applications a good chance of running as well as games, or maybe some d3dx9 work so that winelib can compile more DirextX 9, or maybe try getting Microsoft's new GUI, Avalon, working under Wine.
Andi Mohr wondered why that should be a target:
I'm certainly not authorized to tell you what to do, but what benefit would Avalon bring us? It's not even really released, i.e. its applicability should be very limited.
OTOH almost perfect support for DX9 games would be MUCH more useful IMHO, since lack of gaming support is the #1 reason for many people for not being able to switch to Linux...
Thanks for the incredible work so far!
Oliver explained why he wanted to look into it:
Avalon depends heavily on DirectX 9, I'm not out to do Transgaming out of work so I'd prefer to focus on what isn't currently supported by Cedega/Crossover office, this would be things like Directx 9 applications, and games that aren't FPS's or RTS's.
If Half Life 2 happens to work so be it, but I'm even less a fan of DRM/steam then I am of duplicating Transgaming's work.
If you would like me to work on something just ask. (I have to get a Job soon though, so my output will drop quite a bit!)
Oliver is maintaining a website dedicated to his DirectX 9 work (http://www.oliverthered.f2s.com/projects/wine/) . If you're into testing bleeding edge patches, you'll be overjoyed. The screenshots are pretty cool too.
Roderick Colenbrander tried out the latest patch from Oliver's website and reported:
The past few weeks I have been experimenting a bit with Wine's d3d9. After new updates appeared in cvs I tried games like halife2. Yesterday I tried (a cracked) halflife2 and cstrike:source again using Oliver's latest d3d9 patch and it now shows stuff! For shots check
Both games come to the menu screens I think (not sure what it all has to look like) but from then on not much happens. In case of halfife2 I see some birds flying on the background so the game isn't stuck. I think the menus aren't drawn and I guess that might be related to the fixme "d3d:IWineD3DDeviceImpl_SetSamplerState out of range sampler 0" which I'm seeing hundreds of times.
I'm amazed with the progress made on the d3d9 front. During the weekend I will try to get halflife2 working on Windows to see what it has to look like and I might also have time to fix this problem if it is trivial. Just wanted to let you know that some major d3d9 game is now starting to work.
Roderick replied to himself a few minutes later with an update:
Did some more experiments and the game is also playable! The issue regarding the menu is that some font isn't showing up, the same problem appears in the halflife2 console. After some fiddling I loaded a save game from the hl2 console and it loaded the game.
For a screenshot check http://roderick.student.utwente.nl/hl2-2.png
Haven't looked at the performance yet, it is not slow guess 20-30fps or more. Note that this is using a radeon9000Mobility and further options like -dxlevel 50/60/70/80/90 might help tweaking performance in hl2. Further I don't know how fast/slow this game is on Windows.
Stop drooling, Newman.
5. Window Management Problems
12�Feb�2005�-�15�Feb�2005 (6 posts) Archive Link: "A call to fix the BeginPaint issue"
People: Nick Hornback,�Alexandre Julliard,�Vitaliy Margolen,�Rein Klazes,�,�Paul Vriens,�cvs
The window management changes have caused a few problems. It's not entirely clear the extent of what's going on. Nick Hornback voiced some frustration this week:
Alright, this is probably the last time I will bring it up before I realize that there is essentially no interest in fixing this, but this has been bothering me for quite some time now. A few others have brought it up over the past couple months as well.
As discussed (but nothing really done about it), this patch is directly known to break painting in at least the following applcations:
This is because, as far as I'm aware, these applications don't send BeginPaint/EndPaint as they technically should, but they all work fine on native Windows. Now, before, it has simply been a matter of reversing the patch, no big deal. However, since the region handling has been moved to the server, that is not possible without a lot of tinkering, something that I just don't have the mad skillz to do.
Alexandre asked for some help tracking down the issues, " There is a lot of interest in fixing it, but it's far from trivial especially for apps that I don't have. You can help by posting traces (+server,+win,+message is usually a good start) of the offending behavior."
Rein Klazes explained a little more about the problem as well as provided a link to an application that was having the same issue. Paul Vriens wondered if a different issue that had been reported had the same root cause. Alexandre explained one of the differences between Wine and Windows in this area, " there are a number of cases where redraws are synchronous on Windows and there are some apps that depend on that. It wasn't done that way in Wine mostly because it caused a lot of unnecessary refreshes, but now that we no longer get expose events on child windows we can move towards more synchronous behavior."
Another issue involves minimizing Windows. Lauri Tulmin posted a patch to the X11 driver to address the problem, but Vitaliy Margolen reported new problems:
Ok, that semi-helps. Now I don't have an extra window that was showing up after minimize. But programs still don't want to stay minimized. They blink in the task bar and immediately restore themselves. Any suggestions where could it be?
People have commented on this before. To reiterate: all programs (that I have) behave in this manner, not staying minimized.
BTW one side affect of this patch - application icon is not displayed in the task bar anymore. Now it's back to wine's logo.
6. Drive Detection
11�Feb�2005 (5 posts) Archive Link: "Re: winecfg: various drive detection enhancements"
People: Michael Jung,�Paul van Schayck,�
Some patches came in this week for Wine's configuration tool, winecfg. For those of you just joining us, winecfg is set to take over Wine's configuration settings and provide an easy interface for making the changes. It's been in the plans for a couple of years now. This week some patches came in for winecfg from Michael Jung. This follows on the heels of drive detection support that has been added to winecfg. The first was a bugfix followed by some more significant ones:
Paul van Schayck asked:
I was just about to send a patch doing almost exactly the same things. Including the fix you put in to properply add a drive letter to the working_mask.
And are we ready to let wineprefixcreate use winecfg? Or do we want more testing of the autodetect code?
Michael went ahead and posted a small patch (http://www.winehq.com/hypermail/wine-devel/2005/02/att-0359/01-wineprefixcreate.diff) that actually called the new drive detect code from wineprefixcreate. (Wineprefixcreate is the script responsible for setting up a new Wine user's configuration.) After processing the wine.inf script to set up the registry, Michael just added one line to call the drive detection code. Alexandre committed all the patches except the last one to actually call it. Michael asked for people to please test it out and make sure it works.
7. distcc Patch
18�Feb�2004 (1 post) Archive Link: "Re: distcc and wine-installer"
Topics: Build Process
People: Damian Dimmich,�
Does Wine compile too slow for you? Do you have access to some other machines? Damian Dimmich posted a patch for integrating distcc support into the wineinstall script:
Just made a little patch (http://www.winehq.com/hypermail/wine-devel/2005/02/att-0525/01-wineinstall_distcc.diff) to the wine installer script which allows the user to specify a commandline flag to enable distcc support (using --distcc).
This makes compiling loads faster if you have more than one machine to compile on.
Let me know if it does not work for you.
8. LQ Members Choice Awards
11�Feb�2005 (3 posts) Archive Link: "Wine, CrossOver wins LQ Members Choice awards 2004"
People: Mike Hearn,�
Mike Hearn reported the results of a LinuxQuestions poll:
Hey, we won by a large margin!
Good going chaps and chapettes! Nice also to see the results are ranked in rough order of "freeness" too.
Let's see if we can win again in the 2005 voting :)
So, the actual category Wine won in was titled, Windows on Linux App of the Year.
Sharon And Joy