Table Of Contents
|1.||29�May�2002�-�5�Jun�2002||(3 posts)||News: Wine-20020605, Lindows OS SPX|
|2.||3�Jun�2002||(2 posts)||Testing Lotus Notes|
|3.||2�Jun�2002||(6 posts)||Directly Executing Windows Binaries|
|4.||27�May�2002�-�4�Jun�2002||(118 posts)||License Thoughts|
|5.||21�May�2002�-�3�Jun�2002||(16 posts)||The Future of Wine Debugging|
This is the 125th 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 267 posts in 1068K.
There were 64 different contributors. 44 posted more than once. 36 posted last week too.
The top posters of the week were:
1. News: Wine-20020605, Lindows OS SPX
29�May�2002�-�5�Jun�2002 (3 posts) Archive Link: "News"
Alexandre unleashed Wine-20020605. There's some interesting additions, many of which have occurred over the past week. Noted among the changes are:
This kind of dovetails nicely with last weeks' blurb about Win4Lin. "Open for Business" has an article this week titled Breaking Windows: CodeWeavers and NeTraverse Bring Office to Linux (http://www.ofb.biz/modules.php?name=News&file=article&sid=119) :
This all leads to the question, which one should you buy - Win4Lin or CrossOver Office? The answer really depends on your needs. If you are mainly interested in using Word and Excel, or the other applications supported by CrossOver Office, then that is definitely the best choice. CrossOver Office ends up being more affordable due to its lower sticker price and the fact that it frees you from needing a Windows license.
On the other hand, if you want to run applications not yet supported by CrossOver Office such as Access, Office XP, Quicken, or Photoshop, Win4Lin is for you. It is also for you if you use older Windows software or custom software that may never be supported by CrossOver Office. If you are currently using Windows, the cost of a Windows license is not of concern and the vast benefits of avoiding constant rebooting between Windows and Linux will pay off the Win4Lin license in no time.
And Tom's Hardware has a great review (http://www.tomshardware.com/howto/02q2/020531/index.html) of WineX. There's some benchmark numbers in there too that are interesting.
Lindows.com has put together "Preview Release X". Unless you're part of their Insider program you can't get it. Which, by the way sounds almost interesting now that they've promised (http://www.lindows.com/lindows_michaelsminutes_archives.php?id=12) that anyone who signs up for the Insider program will also get the final version when it's released. Anyway, over the past few months there seems to have been a steady stream of subtle changes to what Lindows.com is putting together. So here's the basic scoop of how you could use this stuff:
What I'd really like to see is a way for all of my preferences for every application to be saved on their site and a way to migrate my preferences over to a new user. Wouldn't it be cool to sit down at your friend's computer, create a new account (or use a generic "guest" account), and automatically download your settings to it? Sure, there's privacy concerns, but I can't tell you how many times I've edited .xinitrc files or wished I had my own .muttrc settings on hand. But to take this a step further, maybe my friend wants to use all of my KDE preferences (background, theme, etc) but not my .vimrc or kppp settings - it would be nice if all those could be easily migrated between users.
2. Testing Lotus Notes
3�Jun�2002 (2 posts) Archive Link: "Lotus Notes application owner"
People: Ian Pilcher,�Dan Schwarz,�
There's been a push lately for "application owners" - people who regularly use a Windows application that could occasionally test that application with Wine to check for regressions or new functionality. Ian Pilcher stepped up to volunteer to own the Lotus Notes R4 client:
I was under the impression that there already was one, but it looks like I was mistaken. I will volunteer to own the Notes *R4* client, which I regularly use. (I suggest having a different owner for Notes R5.)
My employer only recently began providing a VPN access option for Linux, so I've only been back to using Notes with Wine for a few weeks, but it seems to be working very well. The only bug I've noticed is that the left pane of the mail window (in which the "views" are shown) is resized to a zero width when the window is redrawn.
Dan Schwarz responded, " I'm the Lotus Notes application owner. I regularly use and test R5 on Linux, and I run a Linux Domino server at home. If you are interested in owning R4, that's fine by me. For what it's worth, from 1993-97 I was a programmer on the team that designed and wrote Notes R4 and R5 (Iris Associates) so I have some knowledge of application internals (although, sadly, no source code.)"
3. Directly Executing Windows Binaries
2�Jun�2002 (6 posts) Archive Link: "linux kernel thoughts"
People: William Knop,�Shachar Shemesh,�Marco Pietrobono,�
William Knop asked:
I'm sure people have asked questions about integrating wine into the linux kernel. Probably got flamed by everybody, yeah? But that's not what I'm posting about. Not directly, anyway. =)
I'm thinking of writing a kernel patch for PE executable support. Is there any reason why wine libraries should not be used in a similar manner as standard linux libraries? Granted wine is more than just it's libraries. Anyway, good idea, bad idea?
In this manner running a Windows executable could be as simple as typing "winword.exe" from a commandline. Shachar Shemesh responded with:
It's been a while since I looked at the compilation options of the kernel, but there used to be specific support for java applets in the kernel (running a userland jvm, mind you). That was later deprecated by a "MISC" handler, that (I guess) could be configured to run java, and probably also PE.
The idea is that trying to execve a PE file, will find the userland wine program and run it. This would make your effort needless.
Marco Pietrobono gave the details of setting it up:
FWIW, it seems that both RedHat and Mandrake come with a script that does the correct setup at boot.
All it does is:
/sbin/modprobe binfmt_misc &>/dev/null
echo ':windows:M::MZ::/usr/local/bin/wine:' > /proc/sys/fs/binfmt_misc/register
echo ':windowsPE:M::PE::/usr/local/bin/wine:' > /proc/sys/fs/binfmt_misc/register
Thus endeth the thread.
4. License Thoughts
27�May�2002�-�4�Jun�2002 (118 posts) Archive Link: "WineX and the AFPL"
People: Alexandre Julliard,�Ove Kaaven,�Jeremy White,�Dimitrie Paun,�Patrik Stridvall,�Deven Corzine,�CodeWeavers,�,�Transgaming,�Patrik Stridval,�Ove K�ven,�Brian Vincent,�TransGaming
(ed. [Brian Vincent] I started out not wanting to cover this thread. I don't think there's a lot of news in it, however the discussion is ongoing and there may be some value noting how everyone feels. A lot of developers think the move to the LGPL license was the right thing to do, but it hasn't been without problems. And please don't consider this summary in any way complete - a lot has been left out and there seems to be a lot of discussion taking place off the lists. This summary may not seem coherent, and the quote are definitely taken out of context. )
First, I'll refer you to the top level thread from which the following quotes came from: WineX and the AFPL (http://www.winehq.com/hypermail/wine-license/2002/05/0090.html)
Here's random quotes in no particular order.
the point of the LGPL is not to make Transgaming release their code, they have clearly no intention of doing that anyway; it's to encourage other companies to not adopt Transgaming's model and instead choose a business model based on collaboration instead of code hoarding. We have seen the first effects of that in the fact that Lindows is now working from the LGPL code base instead of their private tree. This increased collaboration between all Wine companies will be much better for Wine in the long run than whether or not Transgaming releases an (already obsolete) version of their COM code.
And from my personal perspective, I no longer enjoy seeing my code being used by Transgaming in a way that hurts Wine by discouraging future development. And that's what I like about the LGPL: I no longer need to worry about license changes, proprietary extensions, etc. I can simply have fun writing code again. I'm not going to give that up just to help Transgaming to continue with their broken model.
But CodeWeavers (and Alexandre) are clearly less interested in such collaboration (they've so far refused all requests for ways to collaborate), so that argument doesn't apply either. Alexandre apparently values the fun of coding more than collaboration, and CodeWeavers apparently values the power of the LGPL during negotiations more than collaboration. Beats me why you consider them OSD-compatible.
I'm perfectly willing to collaborate with Transgaming, and any other company out there, under *reasonable* terms. I happen to think the LGPL is an example of perfectly reasonable terms, and all the other Wine companies I talked to (CodeWeavers, Lindows, Macadamian, OsoComm) agree with that.
I'm also willing to make specific exceptions to the license for Transgaming if that turns out to be necessary for copy protection etc. as I already mentioned to Gav in private mail.
Jeremy White: (the full email can be found here. (http://www.winehq.com/hypermail/wine-license/2002/05/0126.html) )
First, I resent the implications that CodeWeavers somehow forced a switch to the LGPL. Please understand that this is something that Alexandre, as Wine maintainer, felt was important to do. If Alexandre had acted on my behest in this matter, Wine would have been LGPL a long time ago (and boxed comments would be mandatory <grin>). Further, Alexandre was very uncomfortable taking this action until he felt that a majority of the non CodeWeavers Wine developers were behind the switch as well.
Second, I resent the portrayal of our actions as being intended to harm Transgaming. I have known Gav personally for a long time, and I wish both he and Transgaming the best.
I guess what I'm saying is that I still feel the switch to LGPL is better, *despite* the distress it has caused Transgaming; everyone seems to be implying that I advocate for the LGPL *because* of the harm it does to Transgaming - and that's the part I resent.
This is like having sex/children. That is, some people are content to just have sex all their lives, without caring to have children. Most other though enjoy having sex, but they want kids as well. Obviously, the analogy I'm trying to make here is sex=coding, children=project :). Nobody denies that the sex/coding thing is the fun part ;). Now, if you don't care about the result of your fun, you're a BSD guy, 'cause you only like to share. On the other hand, if you care about the well being of said result, you may be willing to even give up a little on the fun part to protect it. Most people actually do that -- they do give up quite a bit of fun to have & protect (their) kids.
We have been through this before and again there is a difference between the MEANS and the GOALS.
We doesn't really disagree on the goals, that is not the problem. The means (the LGPL) is the problem. Please focus on that instead of trying to sell the goal to people that already mostly agree.
Alexandre:(the full email can be found here. (http://www.winehq.com/hypermail/wine-license/2002/05/0125.html) )
As I tried to explain, the value to the project is not in a specific patch, or in a number of lines of code. It's in the collaboration that allows everybody to build on each other's code. *That* is what makes the open source model so powerful to build software, and that is precisely what Transgaming is hurting with their release policy.
The important point about the LGPL is that it ensures that *future* versions of the code will be available, which in turn allows anybody to work on improving the code, knowing that the work they do will be useful.
And in another email:
Given that there is no evidence whatsoever that the LGPL has caused harm (and no, Transgaming hasn't stopped contributing as you seem to think, they have submitted some patches since the change), I think it's a reasonable conclusion to say that 3 months after the change the LGPL has already helped Wine a good deal. No it's not a mathematical proof, so feel free to continue denying it if that makes you happy.
(ed. [Brian Vincent] Was any of that news? I don't think so. The theme comprising this thread seems to center on how the license change will affect future commercial development. TransGaming didn't add to the discussion, but I don't blame them. They've made their view known and I don't think there's much to add. As Deven Corzine put it, " Whether they're right or wrong, they should be allowed to succeed or fail on the merits of the business model they choose to use." )
5. The Future of Wine Debugging
21�May�2002�-�3�Jun�2002 (16 posts) Archive Link: "Improving debugging (gdb) support"
People: Tijs van Bakel,�Michael Cardenas,�Eric Pouech,�
Tijs van Bakel asked for thoughts concerning future development of debugging under Wine. Currently Wine has it's own built in debugger, but there's been some discussion of heading in a different direction. Tijs wrote, " I'd like to improve debugging support for Wine, and have time to undertake a larger project. Either I could work on winedbg to match gdb's features, or I could try to make gdb understand Wine better. Given the amount of useful frontends for gdb, it seems wiser to go for the second option. I'd love to be corrected if you think working on winedbg is a better choice."
Michael Cardenas mentioned:
This was discussed at wineconf, well, getting gdb to work with wine was discussed at wineconf because of the huge value in having a graphical front end for debugging.
One major problem is that gdb doesn't understand wine's handling of windows threads, even if it does understand the windows pe format.
Eric Pouech had already started looking at it:
I already have up & running (even if everything is not perfect)
an implementation of the gdb remote target in winedbg. Basically,
this allows the following scheme:
gdb <gdb remote protocol> winedbg <Win32 debug API> wineserver
winedbg is in this case just a proxy between the gdb remote protocol and the Win32 debug API.
This works quite well, with decent performance (even using the remote protocol). However, this doesn't support the standard Windows debug formats (as winedbg does). I've also started looking at the way to integrate this into gdb, but it still requires lots of work before being operational.
Eric went on (http://www.winehq.com/hypermail/wine-devel/2002/05/0659.html) to list the various options available for improving the debugger and the features needed.
Michael Wetherell had some ideas (http://www.winehq.com/hypermail/wine-devel/2002/06/0051.html) on how to use gdb. Specifically he discussed symbol loading and working with threads.
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.