World Wine News

Last year's poll results revealed that about 60 percent of the 3,946 readers polled had both currently used Windows applications under Linux and expected to do so in the future.

The numbers haven't changed at all in the year since, nor have the solutions. Both this year and last year, Wine surfaced as the top choice of 34 percent of respondants. About 16 percent expressed a preference for CrossOver, and VMware exhibited a stable base of 14 percent both years.

Videos will appear here

http://wineconf.geldorp.nl/

enjoy.

I set up a page with various video and presentation sites at

https://wiki.winehq.org/WineConf

Feel free to add further stuff there!

A few things:

1. We've been attacked Wed by one or two idiots from Slashdot. They kept replacing the content of the front page with some silly Balmer images :) Not a big deal, since MoinMoin makes it a snap to revert to an older version. However, this episode forced me to at least require that you sign up before you can edit a page. This is probably a good idea anyway, I hope people agree.
2. I've placed the modifications to the code on the Wine CVS repository at SourceForge in the 'wiki' module. Please feel free to check it out and send in patches (sending them to wine-patches_at_winehq.org with a subject prefix of 'Wiki:' is fine, or directly to me if you prefer).
3. Mike is right, the namespacing stuff if not a good idea. I'll try to get rid of it, I'm going to try to rename the page, but first I have to enable the feature. If not, I'll just simply recreate them.

I've put an updated patch and some new screenshot on sourceforge for the time being http://directxwine.sourceforge.net/ , I'm now at the point where I'm happy to stop fixing bugs in DirectX 9 and start sending in more patches..

Thanks for everyone's help and support.

I was recently messing around with Oliver's new patch and it took me a while to figure out how to apply it. So, in case anyone else is like me and doesn't want to ask, the command that I used to patch wine-20050419 from within the wine directory was:

patch -p2 < (path_to_patch)/d3d9patch.2005-04-28-2.diff

I hope that this will help someone. I know that most people on here already know how to use the patch utility, but I did not.

I'm trying to figure out if there is a way to short-circuit a dialog box. Basically, I want to trap calls to DialogBoxParam, pump calls into lpDialogFunc for dialog init, and then clicking of the "Ok" button, and finally trap calls to EndDialog.

It seems that this is ... hard. :) There is a lot of resource loading, window initialization code, etc that goes on inside DialogBoxParam, and I'd need to handle all of that, I think. There even appears to be issues with 16 vs 32 bit handler addresses, etc. Looks really ugly.

Is there a simpler way to programmatically click "Ok" on a dialog box? (The dialog box coming from code that I don't have source for...)

For simple things, merely sending the dialog a WM_COMMAND with the right parameters will do it for you. You can programmatically find the dialog using "FindWindow".

I've done such things before. For simple things, this works very well. As soon as things stop being simple, this gets very hairy very fast. Just hope that your case is a simple one.

Ah-ha, yes. I ended up using EnumWindows (filtering out the HWND from GetTopWindow). Thanks! WM_COMMAND, IDOK, 0 did the trick.

Now, a final note, is there any way to stop a dialog from displaying itself? (i.e., let dialogs become active, but not draw themselves?) The ttydrv doesn't like trying to open the dialog:

fixme:ttydrv:TTYDRV_GetBitmapBits (0x7d, 0x76d3501c, 128): stub

You should do this as close to Windows as possible, so that it's easier to adapt it to work correctly later on. If you do everything right except you replace the encryption step by a dummy XOR, then it's obvious how to fix it. With the registry approach, if someone wants to fix it they first have to rip out all the code and restart from scratch; that makes it much less likely that it ever will get fixed.

I'd really like to get my Crypt*Protect data patches in, so I want to make sure that I do this rewrite in a way that'll be accepted. If I understand correctly, you want me to:

• parse the Windows data format as best I can
• produce output that looks like the Windows data format
• do some kind of encryption on the data so that nothing needs to be stored to the computer between calls of CryptProtectData and CryptUnprotectData. (The existing patches intentionally avoid any encryption.)

Someone previously posted pretty good information about the format of CryptProtectData on MSDN. I think it should be possible to implement a close facsimile, except that the user's credentials (password) would be missing in Wine since there isn't any at the moment. If you have time to do this, it would be ideal. Failing that, doing any stateless transformation (e.g. no change at all, or xor-ing with some magic value) would be preferrable to storing this data in the registry, if I understood Alexandre's comments correctly.

We're trying to avoid proliferation of OpenSSL in Wine. Relying on CryptoAPI is a safer bet.

Okay. The article (while very good: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/windataprotection-dpapi.asp ) doesn't fully address the "opaque data blob". I have taken it apart and found some common lengths, etc, so I think I can produce a reasonable guess at it, so that the future implementations will have very little to change. The clues in the section "Protected data blob" is what I'm using for the guesses at the data blob format sections.

I should have a new patch ready soon. Luckily all the tests and documentation will remain valid. :)

Is there somewhere I can find details on what's been completed in the CryptoAPI? The http://winehq.com/winapi_stats page say it's at "21%".

You don't have to store this data. Actually it would be quite a bad idea to do so, for security reasons. What windows does conceptionally, is to compute a new key based on the following parameters: A hash of the user's login password, the description and the entropy. The client provided DATA_BLOB is then encrypted given this key and passed back to the user. It is not stored anywhere. In fact AFAIK, the Crypt(Un)ProtectData functions do not store anything whatsoever. The caller is responsible for storing the encrypted DATA_BLOB somewhere. He also has to be able to restore in some way the entropy and the description, if he wants to decrypt the DATA_BLOB at some later time.

In my opinion, the Crypt(Un)ProtectData APIs should basically be implemented as no-ops at the moment (IMHO XOR-ing with some magic value is senseless in an open source project. I think it's not a good idea, since it gives the impression of security, where there is none). As far as I understand, passing back the input DATA_BLOB just as it was given by the caller should work just fine. A FIXME on the command line telling the user that his data is not actually protected would be appropriate.

parse the Windows data format as best I can
DATA_BLOB's are opaque by nature. Applications should not expect anything of the format. So there is no benefit in trying to mimic the Windows data format. (Sometimes MSDN states that a format should be considered opaque, while certain components of Windows don't treat it this way. In these cases it's necessary to mimic the native binary format. As far as I know, that's not the case here.) We don't have access to a hash of the user's login password, so we can't provide real security here. Therefore I think we should not try to pretend it. IMO you shouldn't do any encryption. Just pass back the DATA_BLOB.

That said, if the caller actually provides the pszDataDescription and pOptionalEntropy parameters, you could derive a key from those. The CryptoAPI is accessible by the Crypt* family of APIs in advapi32.dll. All that is necessary for this to implement should be available in wine already.

The idea of using a XOR is not to provide any security, it's just to make sure the code goes through the proper motions so that plugging in real encryption later on is easier. If you simply pass the data through you are not really exercising the functionality. Of course it would be even better to do true encryption with a hardcoded key; it still doesn't provide any security, but it's much closer to the desired end result, which makes it more likely that someone will be able to plug in the missing step.

http://msdn.microsoft.com/library/default.asp ?url=/library/en-us/seccrypto/security/example_c_program_deriving_a_session_key_from_a_password.asp

gives a pretty good introduction on how to derive a key from a password using CryptoAPI. You should hash the following: 1.) A placeholder for the user's login password, 2.) the pszDescription parameter (if present) and 3.) the pEntropy (if present).

If you apply the user's login name as the placeholder for 1.) you are even closer to Windows in the sense that one user can't decrypt another users DATA_BLOB's. (Well, he can of course. But only with some hacking involved.)

New program in programs/getsffile (Get Sourceforge File). It downloads a file from Sourceforge download section, finding a suitable mirror by itself.

This should solve part of the mirroring problem we have for the Mozilla ActiveX control, to make it easy to install on demand, and can most probably be used by other similar things as well.

You can also specify a preferred mirror in the registry (Software\\Wine\\getsffile, key SFPreferredMirror. If the file is not available from that mirror (mirror down, not yet synced, etc.), it'll try another one (up to 3 times). The list of mirrors is retrieved from sf.net, it's not maintained in getsffile.

Basically, to use it to get the Mozilla ActiveX control, what needs to be done is to actually put the control on sf (along with a zip containing 2 needed dlls, one of them is msvcp60.dll), and change the download logic in shdocvw to call getsffile for both files rather than do the download itself. The installation part is almost the same (it'd be nice if the zip would be installed at the same time, even nicer if it wouldn't be needed but that's Mozilla's part).

Note that it's still not 100% proof, some mirrors give a 404 back and it's not properly detected. Is it possible to detect such things while using URLDownloadToFile?

The whole dialog is ripped from shdocvw (Mike McCormack's work), the rest is my own development.

Before you put any merit into any of my results I would highly recommend that you run the benchmark software yourself. I am only sharing MY results, your results may vary depending on your Linux distro, Linux config, Wine config as well as your system's hardware.

I persist in thinking that it's useful to write down thoughts on WineConf to remember for next year, so that we can perhaps have a better event the next year.

Sadly, I do not think there is much chance that we will have a better event next year; I cannot imagine finding more gracious hosts, a nicer venue, or better weather than we had this weekend.

I did not talk to anyone that didn't think that this was a fantastic event, and I think we are all in shock at how helpful the Fachschaft Elektrotechnik were, and how generous WRS was.

However, I want to correct an oversight. I was glad we were able to publicly thank our hosts, but there are a few people from our own community that deserve a round of virtual applause as well.

Without Brian, I don't think we would have had WineConf; he spurred us to thinking of it, pulled us together, and juggled the thorny issue of the agenda quite well.

Further, several folks from Germany really helped out as well. David Gumbel, Andreas Mohr, Michael Stefaniuc, (and others I've forgotten) were extremely helpful to us all. You all certainly helped this American feel very welcome and at home.

So thank you all.

I did want to file a few practical thoughts away:

First, I thought we did audio and video just right this year; we made an honest attempt at it, but it didn't interfere with the conference at all.

However, I think we need to recognize that we Wine hackers are badly addicted to Internet access, and I think we need to set aside a formal time on day 1 to make sure that all access is good. We did have mounting frustrations over the connectivity, only getting it all ironed out midway through day two. I found myself being increasingly distracted by the problems until we finally ironed it out.

(There were counter proposals on the train to eliminate internet access so that folks would focus on the talks; I'm not sure how I feel about that, but it's an interesting point).

We also seem to crave massive amounts of power; we should probably sponsor a box of power strips for our host next year.

Brian was feeling that we might have done better with a slightly lighter schedule, but others didn't seem to feel that so strongly, so I'm ambivalent. But the healthy and flexible breaks were once again invaluable.

At any rate, it was great to see you all. I look forward to planning Wine 1.0 at Huw's house next year *grin*.

Thanks again to everyone that helped bring off a brilliant WineConf!