Wine Traffic #246 For 29 Oct 2004

I've worked on an OpenSSL based implementation of rsaenh.dll in my spare time over the last three months. Although it is by no means complete, I feel that the coarse structure should be stable by now. The patch is appended to this mail as a gzipped tape archive. I'm aware that small patches are preferable, but I hope someone helps me to get this beast in: Please give me feedback on what remains to be done.

If you want to try the patch note the following:

• After you have applied the patch you have to run autoheader and autoconf. Then cd dlls ; make_dlls ; cd .. ; configure.
• After you have compiled and installed wine, you have to unregister rsabase and register rsaenh (regsvr32 /U rsabase ; regsvr32 rsaenh). rsaenh.dll is meant to replace rsabase.dll sometime (Windows XP also has rsaenh.dll only).
• This patch was tested with the attached regression tests and with some MSDN example code. No real application was tested until now.
• This code is not secure! The user's persistent private RSA signature and key exchange key pairs are stored in the registry in _plaintext_. Do not use this with your homebanking application ;)
• The code depends on CUR_BLOB_VERSION being defined in wincrypt.h. This is implemented in a distinct trivial patch, which I've submitted this morning and which will probably go into CVS tonight (that is if you live in germany ;)
• You ain't see a whole lot, if you don't have the openssl headers installed (libssl-dev on debian). The code will compile without, but you'll get a lot of FIXME's and some of the regression tests will fail.

1. MD4, MD5, and SHA1 are now implemented in wine's advapi32. Please use these instead of OpenSSL's.
2. The regression tests should be written so they don't fail if OpenSSL isn't available.
3. Get rid of magic numbers: What do the values 0x36 and 0x5c mean in copy_hmac_info? What is the length 64?
Finally, some stylistic nits:
4. Please break long lines.
5. In some of the files you have the incorrect filename in the comments, e.g. dlls/rsabase/handle.c, dlls/rsabse/handle.h
6. Your indentation in some places is inconsistent; you mix spaces and tabs, and that makes it hard for me to guess the appropriate tab size.

There is also a DES implementation in dlls/advapi32/crypt_des.c. However, this one is not exported by advapi32.dll. I could copy the code over to dlls/rsaenh, but this would mean unnecessary code duplication. How are such cases handled in wine typically?

They are typically handled by copying the code. If linking between the two requires a private export, then our DLLs can't work with native ones, and that's something we try to avoid. If we use a static library, the number of static libraries can potentially get very large, and the makefiles unmanageable. It's really best to accept code duplication, especially for something like DES that is quite stable.

I have a question about dependencies when writing tests. Some tests use LoadLibraryA and GetProcessAddress to get access to Windows / Wine APIs, and other tests just include the appropriate header files and link to the DLLs. One example of the first type is dlls/oleaut32/olefont.c:

================ <snip> ==============================================
static HMODULE hOleaut32;
static HRESULT (WINAPI *pOleCreateFontIndirect)(LPFONTDESC,REFIID,LPVOID*);
START_TEST(olefont)
{
LPVOID pvObj = NULL;
HRESULT hres;
IFont* font = NULL;

hOleaut32 = LoadLibraryA("oleaut32.dll");
pOleCreateFontIndirect = (void*)GetProcAddress(hOleaut32, "OleCreateFontIndirect");
if (!pOleCreateFontIndirect)
return;
=====================================================================

What is the reason for this difference? Which example should new tests follow? My guess is that LoadLibraryA and GetProcAddress are used if the headers, DLLs, and APIs might not be present on some Windows machines, so that the tests don't fail. If that's correct, is there a list somewhere of which ones are safe and which ones should be handled like in the olefont test?

If the API is not going to be available on all Windows systems, then use LoadLibrary()+GetProcAddress() so we can at least run the other parts of the test on these platforms. In extreme cases you may have to tweak the test so it does not link at all with the dll it's supposed to test if that dll may be missing on some Windows versions (e.g. Windows 95 or 98).

Otherwise just use the standard header+link method. If in doubt, go with with the header+link method and someone will fix the test if it does not compile/run on Windows anymore.

The MSDN may tell you that the API is Windows 2000+ or some such. But that's not very reliable: it's quite possible the API is there and just returns ERROR_NOT_IMPLEMENTED or some such.

I am unable to download the RedHat 20041019 packages; any idea why? (Did they get built?)

I can download a SuSE one (well, it at least asks me if I want to save it) but for all the Red Hat ones I've tried the mirror page keeps repeatedly coming up and it never actually tries to download.

They're all built and uploaded to sourceforge. Unfortunately, it seems there are some problems with some mirrors, which are not yet updated (it's been at least 72 hours that the last packages have been uploaded).

Also, since the stats already show 8500+ downloads (if I total all the packages for RH/FC/WBEL, minus the devel ones), some people are getting access to the files.

Nevertheless, here's what my results are for wine-20041019-1fc1winehq.athlon.rpm (other files will probably vary):

Aleron (US): not available
OptusNet (AU): available
UMN (US): not available
Heanet (EU): not available
OVH (EU): not available
Mesh (EU): not available
UNC (US): not available
Voxel (US): not available
Puzzle (EU): available
Belnet (EU): not available

So the availability stats are not pretty, but it is possible to download it. Also, on each mirror (except Heanet), the page returned instead of the file said "The mirror you've selected, umn.dl.sourceforge.net does not currently have the file you requested. (This is an error on our part which will be fixed)." I don't know how to fix their problems, unless we begin to host them on winehq.org (which I don't think will anytime happen soon).

To finish, some fun stats on 20040914 from sf.net: The total size of completed downloads is a bit over 1.7 TB. This amounts to about 658 kB/s throughout the month. Counting the binary versions and the source downloads (and not the devel packages), there were about 94000 downloads from sf.net mirrors for 20040914.

GradientFill is pretty slow, as it files the rectangle line by line. I'm not sure how much this is going to slow down a normal application. It used to draw pixel by pixel, and that was a very noticable slowdown... line by line is much faster than that, but it still may cause a slowdown in some circumstances.

Anybody have any ideas about how to speed up GradientFill?

What I would like to be able to deploy would be a system which runs multiple Win32 compatible desktops and multiple logins on a server, with the clients accessing the desktops via RDP or ICA protocols. How many of the pieces required to accomplish that already exist, and what pieces have yet to be built? A quick search on freshmeat shows me a few different rdp clients, so it looks like the protocol spec is known. What would be involved in creating a RDP server that shows up as a video driver as far as the win32 programs are concerned?

That's something we've investigated fairly closely, as it seems like a Good Idea (TM).

First, as far as I know, there is no public implementation around the ICA protocol, so that doesn't seem like a good option.

Now RDP is based on an IETF protocol spec, so implementing that looks like a good, clean option.

So, in theory, writing a rdpdrv that is parallel to x11drv should be straightforward (and that's the task, just replace x11drv with rdpdrv).

Unfortunately, the reality is that it will be a lot of work. Although the architectural design that the x11 driver is supposed to be separated out, that separation isn't that clean, and then there are a lot of underlying OS resources (e.g. sound etc) that are not so clearly isolated. So we felt it would be more work than we could afford to bite off in the near term (which is not to say we won't contemplate doing this in the medium term future).

As an fyi, we chose to follow an alternate course in the interim. Specifically, by examining the use of the X protocol that Wine uses, and working to optimize that, we should be able to make Wine work decently well over an ssh -C compressed X link. This was the consensus we came to after long discussions with Keith Packard and Alexandre Julliard. So, Alexandre has been steadily (if slowly :-/) working to reduce round trips to the X server within Wine, with the hopes that we'll get there.

Further, there are protocol proxies, like that of nomachine.com, that try to take some of that sting out (last I knew, NX helped, but still wasn't in ICA or RDP class with Wine).

While browsing the web i found a little tool which i expect to be quite helpfull: the opengl extension viewer. Though its written for windows, it runs perfectly on wine and allows people working on d3d and so on to have a quick overview of the functions.

http://www.realtech-vr.com/glview/