IamTheRealMike writes "In January, Microsoft announced a new anti-piracy initiative called Genuine Advantage. From this summer onwards all users of Microsoft Downloads 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 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."

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

SOFTWARE\Wine\Wine\Config

the Wine configuration key.

The Windows Genuine Advantage program press release

http://www.microsoft.com/presspass/press/2005/jan05/01-26GenuineAdvantagePR.asp

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.

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.

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 ;)

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 a month.

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.

Diffstat:

compobj.c	|	2
compobj_private.h	|	6
marshal.c	|	3
rpc.c	|	1001
+++++++++++++++++++-----------------------------------
stubmanager.c	|	4
5 files changed, 369 insertions(+), 647 deletions(-)

Changelog:

Make COM use the RPC runtime as the backend for RPC calls. Based on a patch by Ove Kåven.

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.

on the downside..

• Shaders aren't working yet, but the DirectX 8 shaders can be migrated reasonably easily.
• Stencil buffers aren't working properly either, which affects shadows and odd shaped windows etc...
• Offscreen textures aren't working fully.

on the up side.

• Stateblock support seems to be more complete than TransGaming's.
• Swapchains are working, TransGaming doesn't have them.
• Non-power of two textures should work on all opengl video cards, transgaming only supports a subset of cards.
• Querys are stubbed, and I've got a version of Occlusion query to test (but I think ATI's drivers are broken), occlusion queries may give fairly large performance increases in some games.
• A few other minor things like point sprites are working.

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 some point.

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.

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.

http://www.microsoft.com/downloads/details.aspx?FamilyID=C8F904E1-B4CA-402B-ACCF-AAA2BD60DA74&displaylang=en

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!

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

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

• http://roderick.student.utwente.nl/hl2.png
• http://roderick.student.utwente.nl/cstrike.png

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

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.

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.

http://www.winehq.org/hypermail/wine-cvs/2004/10/0395.html

As discussed (but nothing really done about it), this patch is directly known to break painting in at least the following applcations:

• DeusEx
• Trickstyle
• Foobar2000
• Zoo Tycoon 1 demo

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.

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 effect of this patch - application icon is not displayed in the task bar anymore. Now it's back to wine's logo.

Changelog:

Set pointers to NULL in delete_drive to prevent heap corruption in load_drives

Changelog:

Include config.h to reenable reading /etc/fstab on platforms that support it. Implemented a black list of mount directories, which should not be mapped. Ensure that the user's home directory is mapped.

Changelog:

Added support for command line parameter '/D' to do drive detection from wineprefixcreate

I was just about to send a patch doing almost exactly the same things. Including the fix you put in to properly 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?

Just made a little patch 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.

Hey, we won by a large margin!

http://www.linuxquestions.org/questions/showthread.php?s=&threadid=272137

Wine	293	42.59%
CrossOver Office	139	20.20%
Cedega	131	19.04%
VMware	101	14.68%
Win4lin	24	3.49%

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