|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
Table Of Contents
| 1. | (1 post) | News: Wine 0.9.10 | |
| 2. | (11 posts) | Fedora Packages Available | |
| 3. | (2 posts) | Windows Vista & Wine | |
| 4. | (8 posts) | Confusing Macros | |
| 5. | (3 posts) | Disabling Networking | |
| 6. | (1 post) | Mech Commander 2 Source Available |
Introduction
This is the 309th issue of the Wine Weekly News publication. Its main goal is to become long overdue for a Spring cleaning. 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 236 posts in 390K.
There were 76 different contributors. 39 posted more than once. 34 posted last week too.
The top posters of the week were:
1. News: Wine 0.9.10
(1 post) Archive Link: "News"
Topics: News
People: Alexandre Julliard, Slashdot, News
Last Wednesday, Alexandre released Wine 0.9.10. It followed less than 2 weeks on the heels of 0.9.9. He noted the following changes:
As usual, you can find the latest binaries on our download page. Or, grab the source and start compiling. It's fun for the whole family.
Last week we missed reporting on a story from Slashdot. It seems a gamer using World of Warcraft under Wine was banned. Although Wine was part of the news story, it appears Wine wasn't responsible for the player getting banned: he had keyboard macros set up and got banned for botting.
2. Fedora Packages Available
(11 posts) Archive Link: "What happened to the Fedora packages?"
Topics: Packaging
People: Neal Gompa, Michel Ludwig, Eddy Nigg
Wine's Red Hat and Fedora packages haven't been updated since Wine-0.9.2 a few months ago. There were some grumblings on wine-devel this week that something should be done about it. Neal Gompa asked, " What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs..."
Normally that many exclamation points would turn into a flamefest on a mailing list, but several people responded with solutions. Michel Ludwig provided the first one:
Fedora Wine packages are in Fedora Extras:
And even a "yum install wine" should do it (as root of course :-)).
Well, that's pretty simple. Andreas Bierfert noted that Wine made it into the x86_64 tree of Fedora Extras as well and a yum install wine should work.
Eddy Nigg of StartCom Linux mentioned they had Wine in RPM packages that should be compatible:
We just compiled the latest wine rpm for our upcoming MultiMedia Edition....no problems at all...We made only minor adjustments, to reflect the fact, that it's a StartCom build and not Fedora....
The files can be used of course by any compatible OS:
[ed. note: list expanded from original email to be more download friendly]
That's a lot more packages than a typical Wine installation; it almost looks like something Debian would come up with.
3. Windows Vista & Wine
(2 posts) Archive Link: "Vista compatibility page"
Topics: Microsoft Windows
People: Mike Hearn, Scott Ritchie, Microsoft
As we get closer to the next Windows release, there's bound to be some questions regarding how it affects Wine. Well, the short answer is, it won't for quite some time. It will be quite a few years before software specifically targets Vista, although it's likely Microsoft Office will lead the way. It's only been within the last year or so we've seen Windows 98 begin to be unsupported. So it'll be a while before we have to worry Vista (especially now that the release has been pushed out until 2007.)
Mike Hearn shared some info this week about some of the API changes within Vista:
Potentially this is old news, but via Raymond Chen we learn of this page:
Which talks about Vistas application compatibility. Interesting points that stand out:
So there we have it - this appears to be the first release in which they simply started dropping APIs.
That led Scott Ritchie to remark, " And, therefore, the first time for which we can categorically state that Wine will be more compatible with Windows applications than Windows itself."
One item I found rather amusing is the User Account Control. Vista will now have separate administrator and user accounts with almost all programs running as a regular user. This isn't much different than *nix where root privileges are separate from user privileges. While NT has had this for years, it hasn't been something home users have really dealt with. Congratulations Microsoft, you've once again reimplemented a concept thirty years old.
4. Confusing Macros
(8 posts) Archive Link: "Prevent the use of windowsx.h with Wine source."
Topics: Fixes
People: Rob Shearman, Mike McCormack, Alexandre Julliard, cvs
Consider the following line of code:
ListBox_SetItemData(hlbox, idx, pTxt);
Though taken completely out of context, it appears we just have a some ListBox control call going on. Nothing fancy at all. Internally, Wine uses the Win32 API as much as possible until you get down into the low-level stuff and this just looks similar to any other Win32 call.
However, behind the scenes ListBox_SetItemData() is simply a macro that lives in include/windowsx.h. It's actually defined as:
#define ListBox_SetItemData(hwndCtl, index, data)
((int)SendMessage((hwndCtl), LB_SETITEMDATA, (WPARAM)(int)(index), (LPARAM)(DWORD)(data)))
Not so pretty, eh? It also generates GCC warnings due to the casts, which is generally considered a bad thing. Mike McCormack sent a series of patches last week to replace code like that. It sparked some controversy whether his patches were actually better or not. Rob Shearman fired the first shot:
Why don't we fix the macros as suggested by Francois, rather than preventing its use? It seems like a big waste of time to have submitted all of the patches to the files using windowsx.h when fixing the macros is necessary for Winelib anyway.
Mike explained his reasoning:
No, it's not a waste of time. Having warning free Wine source code is far more important than any warnings that might be in 3rd party winelib code.
Francois' solution is still not perfect, as it requires use of a non-portable C construct.
Rob didn't think that was an issue and reminded everyone of Francois' original idea:
We're trying to work around GCC warnings that probably aren't generated using any other compiler so using non-portable C constructs is perfectly fine. Here is Francois' solution again:
#ifndef WINE_CAST
# if __GNUC__
# define WINE_CAST(ctype, val) ({ctype r=(ctype)(val);r;})
# else
# define WINE_CAST(ctype, val) ((ctype)(val))
# endif
#endif
#define Header_SetImageList(hwnd,himl)
(HIMAGELIST)SNDMSGA((hwnd),HDM_SETIMAGELIST,0,(LPARAM)himl)
WINE_CAST(HIMAGELIST, SNDMSGA((hwnd),HDM_SETIMAGELIST,0,(LPARAM)himl))
It seemed to be ignored by both you and Alexandre last time it was sent, and all of your patches applied anyway despite objections from several developers.
Alexandre then explained why he applied the patches:
I think these windowsx macros are confusing things more than helping, especially since they don't look like macros. It's better to have explicit SendMessage calls than some pseudo function calls, it makes much more obvious what's going on, especially for people who try to debug the code without being very familiar with the Windows API. The fact that getting rid of the macros also avoids the warnings is just icing on the cake.
An example was cited where the new code looked pretty messy compared to the old stuff and it was questioned whether it was really better. Alexandre felt it was:
the code makes it obvious that we are sending a message here, not calling a function (or worse, a macro disguised as a function). In many cases that's important information, for instance when you try to match a message trace with the code. The casts are ugly but they are present in the macro too, so it isn't any more typesafe, it just looks like it is.
The changes stayed in.
5. Disabling Networking
(3 posts) Archive Link: "disallow networking flag"
Someone wrote in suggesting Wine should have a way to disable networking within applications:
I think it would be very useful to disallow an application started with wine i to connect to the network/internet by an options flag.
That's a valid question - a lot of apps like to "phone home" and that's rather annoying. Currently Wine just inherits and utilizes the underlying networking available. Along those lines, a solution was presented using iptables:
I don't know how much of wine's source would need to be changed to disallow all network commands, but I know that this kind of thing is possible using iptables (particularly with the owner extension).
If you create a new user id (which will be the one you use to start the application, using su or sudo), something like 'nonet', then run the following:
iptables -I OUTPUT -m owner --uid-owner nonet -j REJECT --reject-with
imcp-net-unreachableor something like that (I haven't tested it), it will block the 'nonet' user and any applications started as it from sending network packets.
6. Mech Commander 2 Source Available
(1 post) Archive Link: "Another fun winelib project"
People: Steven Edwards, Olaf Leidinger, Microsoft
Steven Edwards let everyone know about a large chunk of Windows code that's been let loose:
It seems Microsoft has MS-FOSSed Mech Commander 2 under a shared source license
According to the appdb it does not run so maybe having the source could better help us find out what we are missing.
It's not every day the source code to a large Windows program becomes available, especially one owned by Microsoft. It could be a fun project to get it running under Wine.
Olaf Leidinger mentioned the source to another game has been available for a while:
The source of Civilization "Call to Power 2" was also released some years ago. Have a look at
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. |