Table Of Contents
|1.||18�Oct�2002�-�24�Oct�2002||(1 post)||News: Xandros Release, WineX with Lycoris, Klez Virus|
|2.||21�Oct�2002||(4 posts)||RPC Update|
|3.||21�Oct�2002�-�23�Oct�2002||(51 posts)||Listview Update (con't)|
|4.||21�Oct�2002||(2 posts)||Commctrl Update|
|5.||18�Oct�2002||(3 posts)||Wanted: AppDB Maintainer|
|6.||18�Oct�2002||(1 post)||Wine PR Manager Needed|
|7.||18�Oct�2002�-�19�Oct�2002||(6 posts)||Web Browser Integration Needed|
|8.||21�Oct�2002||(1 post)||Running Australia's eTax|
|9.||21�Oct�2002||(4 posts)||Running Native Windows Utilities|
|10.||19�Oct�2002||(4 posts)||Compiling Wine With glibc 2.3|
This is the 141st release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).
Mailing List Stats For This Week
We looked at 236 posts in 947K.
There were 61 different contributors. 33 posted more than once. 35 posted last week too.
The top posters of the week were:
1. News: Xandros Release, WineX with Lycoris, Klez Virus
18�Oct�2002�-�24�Oct�2002 (1 post) Archive Link: "News"
Xandros released their Desktop Linux product this week. You can find coverage from eWeek (http://www.eweek.com/article2/0,3959,640814,00.asp) , NewsForge (http://newsforge.com/newsforge/02/10/21/1749230.shtml?tid=23) , and the press release (http://linuxtoday.com/news_story.php3?ltsn=2002-10-22-014-26-NW-DT-SW) itself. >From the eWeek article:
CrossOver for Xandros will combine functionality from CrossOver Office, which lets applications such as Microsoft Office and IBM's Lotus Software division's Notes run; and CrossOver Plugin, which lets Linux Web browsers use Windows Web applications, such as Windows Media Player, QuickTime and Shockwave.
Xandros Desktop users will be able to run or view these applications without having to buy, configure or install additional software on top of the operating system, officials said.
There is one hook: CodeWeavers will not provide support or maintenance upgrades for Xandros customers, who will have to pay separately for a CrossOver support contract.
Xandros (http://www.xandros.com) also revamped their website in anticipation of the launch. One page discusses Windows compatibility (http://www.xandros.com/windowscompatibility.html) and shows how Xandros integrates with Samba and Wine (though not specifically mentioning either). You can also purchase the Debian-based distribution from their new store (http://shop.xandros.com/) for $99. So what's next for the company? Coming soon (possibly with a very liberal definition of "soon") will be a server edition (http://www.xandros.com/server.html) with SOAP-based remote management tools and Xandros Networks (http://www.xandros.com/xn.html) integrated into both the desktop and server products to provide updates and new releases.
But the question really begs, is any of this the least bit new? I mean, we've been able to buy distributions in the store and online for a heck of a long time. Automatic updates aren't really new. Even the configuration and management of lots of desktops really isn't that cutting edge. CodeWeaver's Wine preview has been available for Mandrake users for years. However, if you think back to when Corel released their distribution you'll remember that it raised the bar for all distributions. In general, Linux distributions seem to go through spurts of changes, and it seems like its happening again. Perhaps within the next year it will just be expected that all distributions will be designed to have tight Samba integration, limited Windows application support, and a desktop that's even easier to navigate. For more on what really differentiates Xandros, check out this interview (http://www.consultingtimes.com/articles/xandros/launch.html) with Ming Poon, Xandros' VP of Software Development.
In other disto news, Lycoris will be releasing it's distribution with WineX included. The press release reads:
Redmond, WA -- (press release) -- Continuing its leadership role in providing alternative desktop software, Lycoris partners with TransGaming to bring unprecedented cross-platform gaming into the hands of Desktop/LX users.
With the new Lycoris GamePak, Desktop/LX users gain simple installation of improved and enhanced Open Source games, plus the ability to play top Windows games, all in one box. Access to TransGaming's WineX software, which allows DirectX games to run on other platforms, will be included with the Lycoris GamePak, on retail store shelves this Holiday season.
Lycoris and TransGaming have reached an agreement that will also enable GamePak subscribers to get discounts on major Linux gaming titles such as TimeGate Studios' award winning game series Kohan, and promises to add value for users who move over to the Desktop/LX platform during the holidays.
Lycoris sees this as an important step to offering a viable alternative to Windows and giving gamers the excitement and action they expect.
Speaking of TransGaming, happy birthday! They're a whopping one-year old. To celebrate, they gave a discount for all subscribers buying products on Tuesday, Oct 22nd. Unfortunately I got the press release too late on Friday to include in last weeks' issue, so if you didn't hear about it you're out of luck. Part of that announcement read: " This is our way of letting you know how much we appreciate TransGamers. Many of you who signed on last year when TransGaming first launched its subscription service supporting a mere six games, are still with us today, now enjoying over 150 titles on Linux. That's awesome and this anniversary gift is our way of thanking you, and all members of the TransGamer community, for the support and interest we have received. "
But none of the above happened to be the big of the week. That prize goes to an article (http://articles.linuxguru.net/view/198/) on linuxguru.net about Wine running the Klez virus. This isn't the first time Wine has had the distinction of running viruses intended for other operating systems, but Klez is a little more known than the others. Several people pointed out KMail really does ask whether programs should be executed, as shown in this screenshot (http://lists.kde.org/?l=kde-devel&m=103548062415354&q=p5) . It should also be noted that Wine only runs with the same permissions as the user executing it. So if a user can mailbomb friends by accessing a local MTA, so can Wine. Securing Wine, daemons, and anything else is left as an exercise for the reader.
2. RPC Update
21�Oct�2002 (4 posts) Archive Link: "An RPC progress report"
Topics: Status Updates
People: Greg Turner,�,�Ove K�ven
Greg Turner set about merging a ton of RPC code written by Ove K�ven and wrote in with an update about the status of the merge and some of the new stuff he's working on:
Above what Ove already implemented, I really haven't done all that much. Frankly, in its current state, it is quite possible that the RPC work I am doing will /detract/ from the stability of wine, until the implementation is more complete. RPC is painfully complicated, and a victim of serious creeping featurism. Microsoft makes it worse by providing poorly documented extentions to the protocol, and a largely undocumented marshalling API (much of which developers typically don't have to learn because the API calls are generated by the MIDL compiler).
My target right now is to get a "hello world" API invocation to work across processes using wine RPC. Once that is achieved, I plan to create a unit test for this. Then, we'll have a framework that we can begin to extend and implement "properly." I am not there yet, but I think I'm getting close. I just have to implement marshalling for strings, which, in theory, looks pretty easy. There are probably many bugs that need squashing before it works, and maybe some additional gaps in functionality that I don't even realize exist yet... but I do think I'm pretty near.
Now, what remains to be done? Well, as Ove mentions in the TODO for his units, "a whole lot." Here are several things in no particular order:
Basically, RPC for wine is a huge beast of a project. IMO it is probably the biggest and most difficult-to-fill hole in wine's feature-completeness ATM. In the short term, don't expect any miracles --- I really doubt that I'm going to "solve" this (in my spare time!) anytime soon. But, once I start getting some results, I imagine others will be enticed to help out, as contributors like Ove already have. (To be clear: Ove enticed me, not the other way around: He did all the "real" work, and deserves way more credit than me for any success I may achieve in the near future).
Greg made available some of his work that hadn't been split up yet and announced a large patch (http://www.winehq.com/hypermail/wine-devel/2002/10/0577.html) :
I'm holding back on submitting an "official" patch to give Alexandre the chance to catch up so I can start a new "F" series and not stay forever conceptually forked from CVS wine. But I thought he or somebody else might like to see what's I'm up to so here goes (I'm also having some HD troubles so, in case I have a meltdown, this will prevent me from losing my work!)
I'm enclosing a diff relative to E_PL15 and also a bigger one of uncomitted changes relative to CVS wine (the E_PLxx series are inclusive of this latter diff, so there is nothing new there). I've indexed it as F_PL1 because presumably F_PL0 will be yet another copy of the unmerged server parts.
the E_PL15_unmerged patch does not include the F_PL1_pre0 patch, so if you take CVS wine, apply E_PL15_unmerged.diff, and then apply F_PL1_pre0.diff on top of that, you have my tree. As usual, this is not a hint to apply.
CHANGELOG (for rpc_F_PL1_pre0 only):
dlls/rpcrt4: ndr_marshall.c, ndr_midl.c, ndr_misc.h; include: rpcndr.h, wine/rpcfc.h:
3. Listview Update (con't)
21�Oct�2002�-�23�Oct�2002 (51 posts) Archive Link: "Third listview status update"
Topics: Status Updates
People: Dimitrie Paun,�
Dimi Paun wrote in with another update about his Listview progress:
With my latest W-series patches, the listview should now be a pleasure to work with: fast, *no* flicker, etc. It should be a lot better than before I started working on it. If this is not the case (there are regressions, there is nasty flicker *anywhere*, it's slow, or in general it's not a pleasure to interact with it, i.e. you don't get a warm and fuzzy feeling) let me know now.
Internally, the code is a lot cleaner. I have started on Sep. 9, 2002, at revision 1.138. A month and a half, and almost 150 revisions later, most of the code has changed multiple times. Large number of visible, and mostly invisible bugs have been fixed, a lot of corner cases covered, features implemented, listview has been made scalable, flicker has been eliminated by redrawing the absolute minimum, etc. We are now on solid ground to implement more stuff.
This has been an extenuating exercise. I am tired, and on top of it all, real life has knocked on my door. This does not mean I'll stop working on it, but it probably means that I will not be able to put as much time into it.
For the above mentioned reasons, I think it's best for everybody if we stabilize the code as much as possible, before we start working on the large number of missing features. For this I need your help -- the few apps that I test with work just fine now.
I would like to thank everybody that helped me with testing, patches, or reporting bugs. I couldn't have done the half of it without that support.
This sounds like this is a done deal. It's not. There's a lot of stuff that remains to be done, but I needed some closure. :)
This pretty much generated a flurry of reports. Dimi squashed a lot more bugs and fixed many of the problems reported. Then he announced:
After my latest X-series patches (currently at X6), I am aware of the following listview bugs:
Yes, you read correctly: NONE. :)
So I ask you for one of two things: bug reports or success stories
Otherwise, I'm gonna declare listview the coolest, nicest, most huggable piece of code out there <g>.
4. Commctrl Update
21�Oct�2002 (2 posts) Archive Link: "updated dlls/comctl32/commctrl.c comments"
Topics: Status Updates
People: Christian Neumair,�
Christian Neumair noticed Dimi's update for listview added to the header, so he decided to do the same for commctrl.c.
This code was audited for completeness against the documented features of Comctl32.dll version 6.0 on Oct. 21, 2002, by Christian Neumair. Unless otherwise noted, we belive this code to be complete, as per the specification mentioned above. If you discover missing features, or bugs, please note them below.
5. Wanted: AppDB Maintainer
18�Oct�2002 (3 posts) Archive Link: "WANTED (dead or alive): additional AppDB maintainer"
Topics: Project Management
People: Andreas Mohr,�,�Bobby Bingham,�Thomas Wickline
Andreas Mohr put out a call for help the the Application Database:
as I'm currently in my studies duties again and the AppDB submissions are piling up enormously (> 20 new entries in less than two weeks), I'm looking for one or two additional AppDB maintainers to do the Beowulf thingy ;-) (I'm talking about http://appdb.winehq.org, here)
The job description can be found at http://www.winehq.org/about/index.php?contrib#active (http://www.winehq.org/about/index.php?contrib#active) Sadly enough, this description page has been online for several months now, with (almost ?) nobody applying for any jobs listed.
Thomas Wickline, Bobby Bingham, and an unknown person offered to help out. Of course the job remains open for anyone else who wants to help the Wine project.
6. Wine PR Manager Needed
18�Oct�2002 (1 post) Archive Link: "Getting actively involved in the Wine project"
Topics: Project Management
People: Thomas Wickline,�CodeWeavers,�
Thomas Wickline looked at the page Andi Mohr referenced above about jobs available and noticed there was one posted for a PR Manager. He reposted it to wine-devel:
Currently we almost have no Public Relationship management at all. This should change for the better.
Currently almost the only form of PR is "preaching to the choir", since we're having articles on online IT sites (by far most are Linux only !). We should have much more coverage on traditional Windowsish sites and, most importantly, in dead-tree newspapers, to enlighten the general public also known as The Great Unwashed Masses !
He went on with some other ideas for drawing attention to Wine:
Wine users, CodeWeavers, & WineX customers could do Previews/Demo's at their local lug meetings as well.. This is what I did a couple months back and it was a huge success there were Windows users at the meeting to see Linux and Win app's being run on Linux ... Also it gives Linux users a look at wine as well. So I suggest that we try to encourage wine users to volinteer to show Wine at their local user groups/Installfest/Computer shows and so on.
This is not a PR manager but it is PR......
Anyone out there ever demo Wine for their LUG? If you'd like to write up some guidelines for how you did it, what you demonstrated, questions asked, etc, I'll post it here to help others out. Send email to vinn -at- theshell.com.
7. Web Browser Integration Needed
18�Oct�2002�-�19�Oct�2002 (6 posts) Archive Link: "Re: WebBrowser"
Topics: Project Management
People: Malte Starostik,�Dante Aliegri,�Dimitrie Paun,�
Malte Starostik posted a patch adding typedefs for IWebBrowser. IWebBrowser is a set of interfaces Microsoft defined for Internet Explorer that allow you to embed it within another program. It provides methods navigation, hyperlinking, etc. Dimi Paun asked if anyone wanted to work on actually hooking the IWebBrowser interface into the Gecko API so that applications could use Mozilla to do page rendering and such.
Malte replied, " Hmm, we're implementing the absolutely neccessary parts in reaktivate with Konqueror, but that's run from inside Konq already, so it's a bit special. Maybe there would be a way to use either browser with those interfaces? :-)"
Dante Aliegri gave a link to some Mozilla hooks that implemented the needed functionality, " Fwiw, this has already been done in mozilla, and there is documentation on it at http://www.iol.ie/~locka/mozilla/control.htm (http://www.iol.ie/~locka/mozilla/control.htm) . So depend on how we want to do this, we could use this, and/or konq. I would think more people would want to go the mozilla way since its tri-licence, and the fact that it already works in windows :) But, thats just something to think about. "
Dimi thought it would be possible to use it, but cautioned, " The only problem is that it's in C++. And it's using ATL, which is, IIRC, some MS lib, right?"
8. Running Australia's eTax
21�Oct�2002 (1 post) Archive Link: "eTax status report"
People: Ben Stanley,�
Ben Stanley wanted to let everyone he used Wine to prepare his tax return:
I have now completed using the eTax program from the Australian Taxation Office ( http://etax.ato.gov.au ) under wine, and have some concluding remarks.
I'll interrupt and point out some things..
Ben's notes were:
I used etax in the desktop windowing mode, as I had problems with both the managed and unmanaged modes. I set all dlls to builtin (except for "*").
This is the first year that I have been able to use eTax to do the tax return. I want to thank all of the wine contributors for making it possible! Last year I gave up and used a Windows box for the whole thing.
9. Running Native Windows Utilities
21�Oct�2002 (4 posts) Archive Link: "using native regedit"
People: Jeff Smith,�Alexandre Julliard,�Sylvain Petreolle,�,�Greg Turner
Jeff Smith wanted to run Windows' native reegedit, but he couldn't figure out how:
I know I must be missing something very simple, but I cannot seem to get native regedit to run. The builtin version always runs instead. The only thing I could think of was an entry in DllOverrides:
"regedit.exe" = "native, builtin".
That did not work.
Greg Turner suggested just renaming it to winregedit.exe before running it. Jeff thought that might be okay, but then a while later found the solution he was looking for:
Found something: it works if I fully qualify the command name.
I was trying this in the DllOverrides / command-line respectively:
"regedit.exe" = "native, builtin"
What I have to do for it to work is this:
"C:\\Windows\\regedit.exe" = "native, builtin"
Some people thought this was pretty confusing, especially because it wasn't really documented. Alexandre explained the reasoning, " It's the way it's supposed to work, because it mimics the way loadorder works for dlls: a simple "regedit.exe" matches only if regedit is in the system directory. Otherwise you need to specify the full path, or use a wildcard entry like "*regedit.exe"."
Sylvain Petreolle changed the sample config (http://cvs.winehq.com/cvsweb/wine/documentation/samples/config) to explain this:
; you can specify applications too
; this one will apply for all notepad.exe
;"*notepad.exe" = "native, builtin"
; this one will apply only for a particular file
;"C:\\windows\\regedit.exe" = "native, builtin"
10. Compiling Wine With glibc 2.3
19�Oct�2002 (4 posts) Archive Link: "Re: glibc 2.3 pthread patch"
People: Ove Kaaven,�Alexandre Julliard,�,�Ove K�ven
Ove K�ven posted a patch with the following note, " Now that glibc 2.3 is available for those bleeding-edge folks on debian unstable, it seems that Wines compiled on 2.2 won't run on 2.3 systems. The glibc folks did warn us about this a while ago though, so here's a patch that implements their suggestion for making wine compatible with as many glibc versions as possible. Perhaps Alexandre wants to use his WINE_GET_SONAME stuff to detect the name of the libc at configure time instead of at runtime like I do, though. "
Ove's patch resolved fork and sigaction at runtime using dlsym() rather than having it defined when compiled. Alexandre replied, " Funny, I was working on the same thing right now... But do you really need to fetch the real libc handle? It seems to me RTLD_NEXT should be enough. "
Ove thought it might not be enough and wondered about other DLL's breaking it, " I'm not sure, what happens if opengl32.dll.so or d3d8.dll.so links against a libGL.so that links against libpthread.so that overrides fork() ? Would RTLD_NEXT then not go to the pthread fork() ? Or perhaps, it seems, you grab the entry point before those dlls are loaded. Hmm."
Alexandre said that was exactly the case and it shouldn't cause any problems, " Yes, that's the idea. By the time we do PTHREAD_init_done only the wine binary and ntdll.dll.so should be loaded, all the rest will be loaded later. I guess it would be possible to break it by doing an LD_PRELOAD of a library linked with pthreads, but I don't think we need to worry about that."
Sharon And Joy