Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins|
Table Of Contents
|1.||25 Oct 2004 - 28 Oct 2004||(4 posts)||MS Enhanced Provider Library|
|2.||27 Oct 2004 - 28 Oct 2004||(2 posts)||Test Dependencies|
|3.||25 Oct 2004||(3 posts)||Download Problems|
|4.||26 Oct 2004 - 28 Oct 2004||(7 posts)||Gradient Fills|
|5.||28 Oct 2004||(2 posts)||Remote Application Deployment|
|6.||23 Oct 2004 - 24 Oct 2004||(3 posts)||OpenGL Extension Viewer|
This is the 246th issue of the Wine Weekly News publication. Its main goal is to vote. 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
Mailing List Stats For This Week
We looked at 142 posts in 616K.
There were 50 different contributors. 27 posted more than once. 31 posted last week too.
The top posters of the week were:
1. MS Enhanced Provider Library
25 Oct 2004 - 28 Oct 2004 (4 posts) Archive Link: "rsaenh [beware: 27kB attachment]"
People: Michael Jung, Juan Lang, , Microsoft
Microsoft began shipping a new Cryptographic Service Provider a few years ago called MS Enhanced Provider and put it in a DLL called rsaenh.dll. It's part of the Crypto API and provides algorithms for DES, 3DES, and RSA among others. Until now, Wine hasn't had an implementation of it. Michael Jung has apparently been working on it for a while now this week posted a preview:
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:
Juan Lang had some ideas for improving the patch:
With regards to using the hash functions in advapi32, Michael wanted to know if the two could share an implementation implemented elsewhere, " Would it be possible to move the SHA1, MD4 and MD5 related code to some other directory in the wine tree and link to it statically from both advapi32 and rsaenh? Is the misc directory meant for this purpose?"
Juan explained in this case there was no reason for it, " No. Generally, creating static libs is something we avoid in wine. More specifically, these functions are already exported by advapi32, and you already link advapi32 (to get access to the registry) so there's no advantage to having a copy in both places."
That led Michael to ask about something else implemented in advapi32:
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?
Now, this is a topic that comes up quite frequently with Wine. Most developers hate the idea of duplicating code, especially on parts that require frequent maintenance. However, Juan pointed out that this wonderful design trait comes to us from the folks in Redmond:
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.
After a few more rounds of back and forth discussion, Michael submitted a final version of the patch to wine-patches.
2. Test Dependencies
27 Oct 2004 - 28 Oct 2004 (2 posts) Archive Link: "Writing tests"
People: Walter Ogburn, Francois Gouget,
Wine's test suite has seen sizable improvements in the past few years. Tons of new tests have been added enabling more and more bugs and regressions to be caught. We even have an automated testing facility that compiles the tests on a daily basis and runs them on actual Windows clients to see how accurate they are. Accurate tests mean an accurate interpretation of Win32 leading to a more accurate reimplementation. There was a bit of a hiccup with some of the reporting, but it appears to be straightened out. If you're curious about that data, check out http://test.winehq.com/data. Raw reports can be seen within Hypermail archives at http://www.winehq.com/hypermail/wine-tests-results/. If you happen to have a spare Windows machine laying around you might be interested in downloading the winrash client and have it automatically run the tests.
Walter Ogburn was poking around with tests this week and noticed something odd:
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*);
LPVOID pvObj = NULL;
IFont* font = NULL;
hOleaut32 = LoadLibraryA("oleaut32.dll");
pOleCreateFontIndirect = (void*)GetProcAddress(hOleaut32, "OleCreateFontIndirect");
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?
Francois Gouget explained the difference:
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.
3. Download Problems
25 Oct 2004 (3 posts) Archive Link: "Problems downloading the RedHat packages"
Topics: Project Management
People: Bill Medland, Vincent Beron,
Most developers, and by that I mean all developers not just Wine developers, are thankful for SourceForge. It provides an invaluable service to the open source community. This week Bill Medland noticed something weird with it though:
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.
Vincent Béron, the Red Hat packager, did a little research and came up with:
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):
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.
This likely affects more than just the Red Hat packages. So, the moral of the story is.. if at first you don't succeed, try and try again.
4. Gradient Fills
26 Oct 2004 - 28 Oct 2004 (7 posts) Archive Link: "Re: Gradient Color for Caption Bar"
People: Dmitry Timoshkov, William Poetra, Andreas Mohr, Mike McCormack, Shachar Shemesh, , Microsoft
A patch came in this week from William Poetra implementing gradients for the title bar. It led Dmitry Timoshkov to comment, " Use gdi32.GdiGradientFill instead of msimg32.GradientFill, the latter one is forwarded to gdi32 anyway."
William couldn't find a reference to that API though, " Well, I can't find GdiGradientFill by searching at MSDN. I found some links through Google, though. Is it a deprecated, old API? If that's the case, I think we'd better link to msimg32. "
Dmitry explained, " GdiGradientFill is the gdi32 entry point to which msimg32's GradientFill is forwarded. "Deprecated" is the Microsoft term which they usually use to force developers to go the way Microsoft wants and has nothing to do with reality and especially with Wine development. "
Andi Mohr seconded the motion, " It might be a deprecated API, but it doesn't matter since you can bet that they won't throw that export away. Or at least if they do, then there's still no reason for us to throw it away, since there must be some Windows programs depending on that export. "
Mike McCormack cautioned:
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?
Shachar Shemesh threw out an idea, " How many colors are typically drawn across a single bar? If this number is significantly less than the number of vertical lines, you can precalculate the width of each color bar, and draw a series of boxes. "
Meanwhile, William made the change suggested by Dmitry and resubmitted the patch.
5. Remote Application Deployment
28 Oct 2004 (2 posts) Archive Link: "How difficult would it be to make the equivalent of Windows Terminal Server with Wine?"
People: Andrew Quigley, Jeremy White, Alexandre Julliard,
Andrew Quigley thought of an idea similar to Citrix and asked:
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?
Unbeknowst to Andrew, the idea has already been thought of and Jeremy White outlined some of the difficulties:
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).
6. OpenGL Extension Viewer
23 Oct 2004 - 24 Oct 2004 (3 posts) Archive Link: "OpenGL Extension Viewer"
Nikolas provided a link to a utility some developers might find helpful:
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.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.