All the news that fits, we print.
This is the 122nd release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator).
This week, 392 posts consumed 1145 K. There were 85 different contributors. 46 (54%) posted more than once. 43 (50%) posted last week too. The top 5 posters of the week were:
|
News: Xandros Beta, CodeWeavers Wine Preview 6 | 04/27/2002 | Archive |
---|---|---|
News One company you don't hear a lot about (yet?) is Xandros. Xandros acquired Corel's Linux distribution when Corel got out of the Linux desktop business in August of last year. More importantly, they have some of ex-Corel guys working for them. You can still find an ISO image of the Corel distribution on their website but Xandros is in the process of creating their own product offerings now. They had a call for beta testers a while ago that I totally overlooked. You probably wouldn't have gotten in if you wanted to - 2,000 people applied and 150 were selected. On their about page they describe what they're working on: Xandros is developing a customized Debian-based Linux distribution that is derived from version 3.0 of the award winning Corel LINUX OS. It will support both the KDE and Gnome desktop environments. In addition to the features that Linux users expect, Xandros will be distributing significant additions and enhancements. Furthermore, Xandros is creating a server and enterprise management solution that will significantly reduce the total cost of ownership of computing environments. The overall solution is complete "off the shelf", but Xandros Professional Services can customize and integrate the products as well as provide enhancements to legacy systems as needed. Finally, all Xandros offerings will be backed by world-class support. Xandros plans on releasing their software within the coming months, so stay tuned. One thing I definitely missed last month was CodeWeavers Wine Preview 6 . Dated from April 11th, it came out shortly after the announcement of CodeWeavers Office. CodeWeavers wine is known for it's ease of installation, integration with Gnome and KDE, and having some of the fixes (or, sometimes, ugly hacks that work) that haven't made it into the official Wine CVS. Their releases are somewhat infrequent with the last being five months ago. However, if you haven't tried Wine in a while and aren't comfortable with CVS , tarballs , or even getting one of the daily builds you might want to try out their RPM. It's free, so if you break it you can keep all the pieces. Interesting trivia #1 - CodeWeavers Wine is the most downloaded piece of software by members of Mandrakesoft's Mandrake Club. Also this week, a review of TransGaming's WineX 2.0. Notable quotable, I haven't done much to optimize my Linux box for gaming...but I was happy to have a game that has not been ported for Linux running without hangs or crashes. And, also on the TransGaming front, there's a way for subscribers to get credit for their friends subscribing. If you follow this link: http://www.transgaming.com/create_accnt.php?referer=vinn and subscribe I get credit for it. This in no way endorses TransGaming, nor should it encourage or discourage you from subscribing. My only point is if you were planning on subscribing anyway , then maybe you'd find that useful. In case you're wondering, I'll probably only get a t-shirt out of it. |
Quartz.dll Removal | 05/02/2002 | Archive |
---|---|---|
Multimedia
Has anyone ever said anything good about the DMCA? Don't worry,
I won't be the first.
Over the past 9 months Hidenori Takeshima single-handedly worked on
recreating the quartz.dll responsible for implementing ActiveMovie and
DirectShow. The codecs involved are a huge amount of code that's
unfortunately questionable to distribute due to legal concerns. Without
warning the code suddenly disappeared from both the X11 and the
GPL trees. Questioned about why it was removed, Hidenori explained:
My all MultiMedia codes are completely written from scratch.
No disassembling. I believe there are no legal issues.
But, I cannot warrant... I should protect myself from
any potential problems now...
The main issues for me are
|
Bugzilla: A Call to Arms | 04/29/2002 | Archive |
---|---|---|
Debugging
Andriy Palamarchuk put out a call to start using Bugzilla:
We already had discussion on wine-devel about
importance of polishing Wine, making a set of
applications to work very well.
Cruicial in this process is prioritizing of the
issues, work distribution between developers. The
companies already have internal testing and bug fixing
process.
Of course, each company has their own product-specific
work, but most of the problems are general for Wine.
I suggest to share this work more actively using
Bugzilla.
Recently there was some work done in cleaning the
issues database and it is in pretty much usable
condition.
To start using bugzilla more actively I suggest
following steps:
|
SafeDisc Support | 04/28/2002 | Archive |
---|---|---|
Patches
Laurent Pinchart announced:
Here's (at last) the (long awaited ?) SafeDisc patch.
I want to thank Zsolt Rizsanyi who helped me with the CDROM ioctls (his
implementation of IOCTL_SCSI_GET_ADDRESS has not been included in this patch,
as I don't have the latest version), Alexandre Juliard for his help with the
process suspension, Erich Pouech and Andreas Mohr for their help about how to
handle the reentrant wine server calls (even if that has turned out not to be
needed in the end), and all of those who answered my numerous questions on
#winehq. To the ones I forgot (if any), please forgive me. If you help me
with SafeDisc-1 I'll thank you twice :-)
As I don't speak 'legalese', here's the usual disclaimer in nglish:
This patch works on my system, and it will probably work for some of you. For
those who can't get it to work, I'm really sorry, and I'll help if you ask
nicely, but don't blame me or sue me.
One caveat is the Wine needs to be run with --winver nt40
Laurent added,
For those interrested, here's a FAQs about my SafeDisc support implementation.
Feel free to comment.
The FAQs were attached to the email and can be found at:
http://www.winehq.org/hypermail/wine-devel/2002/04/att-0616/01-safedisc.txt
A few people were concerned about DMCA violations, but Laurent
felt what he had implemented was within the guidelines.
|
MinGW and ftruncate() | 05/01/2002 | Archive |
---|---|---|
Ports
One item that doesn't get reported here much is the
work being done to port Wine to ReactOS. Haven't heard
of ReactOS? From their web page,
ReactOS is an Open Source effort to develop a
quality operating system that is compatible
with Windows NT applications and drivers.
Working on the Wine side of things are Steven
Edwards, Casper Hornstrup, and James Tabor.
Currently ReactOS works but the graphics interface
(GDI) is not functioning properly. Win32 console apps
run and the OS is self-hosting using
mingw
. The plan is to
use Wine as the Win32 subsystem once DLL separation is
complete. The main obstacles are:
|
Use Xrender From XFree86 4.2.0+ | 05/01/2002 | Archive |
---|---|---|
Fixes
Duane Clark ran into a problem,
The xrender CVS patch of 4/23 is causing one of my apps to crash
. Huw Davies replied,
I think you have a buggy version of libXrender.so. Could you check
that this patch stops the crash? Unfortunately it will disable client
side font rendering. Jeremy came up with a truly horrible hack to
work around this problem but for some reason that I can't possibly
imagine Alexandre left it out when he committed the last xrender
changes <g>.
Duane reported,
That does fix it, though I was getting used to the client side fonts :(
What version of XFree86 is needed to get a good xrender? I am running
version 4.1.0.
Jeremy White replied:
You need 4.2.0. You can also just build libXrender.so,
which is not that hard to pull out of CVS and build by itself.
Finally, I have attached the king daddy of all kludges that
may let you use your Xrender without modification, but
use at your own risk... (you'll probably also need to
hand assemble the patch, it's a delta from our internal
tree and is not likely to apply).
Jeremy's patch can be found at:
http://www.winehq.org/hypermail/wine-devel/2002/05/0053.html
Mentioned in the patch is:
** Xrender.c bug. (Version 1.4 of Xrender.c had a bug where
Duane still had problems with the patches, but then mentioned:
In any case, I just downloaded the binary tar file:
http://ftp.xfree86.org/pub/XFree86/4.2.0/binaries/Linux-ix86-glibc22/Xbin.tgz
and took out just the libXrender.so.1.1, and installed it. Everything
seems to work fine with that.
|
Native user32 DLL? | 05/03/2002 | Archive |
---|---|---|
Integration Michael Cardenas wondered: I'm still trying to fix aol so it can communicate with the web proxy, and I think I've narrowed down the problem to user32.dll, kernel32.dll, and ws2_32.dll. Is it possible to use the native user32.dll? I know kernel and ws3_32 don't work native. This has actually worked in the past, but because of the address separation going on it's no longer a "feature". A bunch of people jumped in to debate it, but Alexandre squashed it with, I agree it would help for finding bugs. Unfortunately the Win95 architecture is completely brain-damaged, and trying to support it would introduce so many new bugs and instabilities than the end result would be much worse than what we have today. So no, native user is not going to happen. Ulrich Weigand explained in detail: Well, there's Windows and then there's Windows ;-) In Win9x, address spaces are handled in a peculiar way: the lower 2 GB of the address space are changed on context switch, while the upper 2 GB remain the same across all processes. In particular, all 16-bit segments and certain 32-bit DLLs are de facto mapped shared across all 32-bit processes. The user.exe implementation relies on this fact, as I mentioned previously. Before address space separation, we were handling things somewhat like Win 3.1 (with win32s), in that everything shared one space. After address space separation, we are handling things more like Win NT, in that nothing is shared between processes by default, except for explicit shared mappings (and shared PE sections). In particular, 16-bit segments are not shared between processes (like they aren't in Win NT), which means that user.exe won't work. Implementing the weird Win9x address space handling exactly under Linux would be difficult, and in any case we *want* to be more like Win NT for stability reasons ... |
Geography Lesson: Rumantsch | 05/07/2002 | Archive |
---|---|---|
Internationalization Sylvain Petreolle was working on converting winhelp for NLS (native languange support) use and ran into a problem, I have to problems to use Va.rc,since I don't know whis country this file is associed to. (probably due to the fact I was asleep in history & geography :) ). I looked in dlls/kernel/nls but didn't see it. Johan Gill thought it could be the Vatican, and Francois Gouget thought so too. Eric Pouech was suspicious of the naming, looking on google for some of the words used in the file seem to indicate that this is in fact "suisse roman" (romanche in English ?), perhaps Alexandre could give an hint on this very important issue ;-))) I don't think that Vatican guards being Swiss Guards is the explanation of the Va name Alexandre supplied the answer: It's apparently "Rumantsch" (not sure about the English name) which is the 4th Swiss national language (after German, French and Italian). It is only spoken by perhaps a few thousand people in the eastern parts of Switzerland. It should not be confused with "suisse roman" which is the language spoken in the western part of Switzerland (where I'm from), and which is basically French except for a few strange words that make us sound funny when we go to France. In Windows terms I think Rumantsch should be LANG_RHAETO_ROMANCE (though this constant only appears in Wine headers so I'm not sure if that's an official Windows definition). The file is named Va.rc apparently because this is the "Vallader" variant of Rumantsch; there are at least 5 variants according to http://www.christusrex.org/www1/pater/JPN-rumantsch.html (you sure find strange things on google...). Don't ask me what are the differences between the variants <g> |
Trading Patches | 05/06/2002 | Archive |
---|---|---|
Licensing It's funny how mentioning InstallShield provokes lively threads. One of the last mentions of InstallShield lead to the call for an LGPL'ed Wine tree. This time Andriy Palamarchuk pointed out BugZilla bug #629" concerning InstallShield v6 support. Ove Kåven replied: Oh, well, it's a known problem. It's not easily fixable in the official Wine tree without, say, half a man-year of work. There's an ugly hack (an one-liner) to make it work (in conjunction with a stdole32.tlb file from real Windows), but since Alexandre never yet applied this hack to the official Wine (though it might be in CodeWeavers CrossOver), I presume he never will before there's a "real" solution (which will take man-months of work, and writing an IDL compiler to let us generate our own .tlb file instead of using the native one, maybe another month or two). After the WineX 2.0 release, I've once again been working on completing my version of the real solution (I'm close to have it working now), but of course, Gav probably still wants a fair chunk of LGPL-ed code relicensed in exchange... Several people wondered what the "ugly hack" was to make it work. Marcus Meissner, author of the out of process COM code in the LGPL'ed Wine tree replied with a patch you can find at: http://www.winehq.org/hypermail/wine-devel/2002/05/0171.html Alexandre thought the COM code was going to be exchanged with the ALSA driver. However, Eric Pouech did the development of the ALSA stuff and he clarified his position by stating: When I decided starting coding the ALSA driver, TG offered to sponsor the work. I turned down the offer (don't need sponsor for what I'm doing) and suggested using the money for some other use. Furthermore, I'm not for or against Wine nor for or against WineX. I'm just trying not to let an important gap being created between all the different projects. The ALSA driver has been started on a X11/MIT license, some people currently are giving an hand to shape it better (David Hammerton did some testing and bug fixing for 0.5, Marco Pietrobono is currently fighting with the awes of the 0.9 interface, but that's another story), and will remain under the X11/MIT license. Ove replied to Alexandre's original inquiry about trading patches with, What is most important for TransGaming now, is to see the DLL separation work get into ReWind. He's making a list of things to trade it with, such as a DIB drawing engine, fast DIB sections using ShmPixmaps, this COM stuff I'm working on, and of course various DirectX things. Since I've researched and worked on this COM thing (with undocumented stuff all over) for months, I doubt TransGaming would settle with just an ALSA driver, now that their development costs have increased from the forking. The thread turned rather ugly at points, with Alexandre and Jeremy White both stating that they're not interested in the patch trading business. Everyone agrees that the code should be publicly available, but the licensing was once again the divisive point. Gavriel State jumped in to mention: What we are proposing is not "blackmail" but *trade*. Really, the economic problem in this licensing situation comes down to a question of accounting (most economic problems do). What value do you place on a contribution to the project, whether it is your own or someone else's? The LGPL license that Wine is currently using is effectively saying that the value of your current contribution is equal to the expected value of any future contributions. IE: All contributions and contributors, current and future are equivalent. Certainly this simplifies the accounting, but at a serious loss in accuracy. As we've already stated, TransGaming can't operate within that framework, for a wide variety of reasons. Instead, we're going to be making the value picture more specific. We would like access to some code that's currently licensed under the LGPL by copyright holders like yourself and CodeWeavers. In particular, we would like to see address space separation work made available under the X11/ReWind license. That would be a boon for everyone, as it would allow easy interchangability between Wine and ReWind (and WineX) DLLs. There are a few other things that would be nice as well. In exchange, we have a number of things that we would be happy to contribute to ReWind, and thus to the Wine tree. These things include our new DIB engine work, COM/DCOM work, selected portions of our work on copy protection, and a number of other significant features. We're also quite happy to work on any DLLs that need additional separation work. What has to get figured out is simply this: exactly what do current Wine copyright holders want to have for the things that we want from you? I'd like to resolve this question soon, and establish some kind of ongoing framework for how to manage this cooperation in the future. I hope to have a detailed proposal for the Wine LGPL-only contributors shortly. Alexandre came up with analogy in reply: The problem is that you are seeing this in economic terms. That's not how it works. The real value is not in the individual contributions, it's in the collaboration, where everybody works with everybody else on building the best possible Windows emulator. Consider you are organizing a party with your friends: someone who has a large music collection will bring his CDs, some will cook something, others will spend time decorating the room, etc. What value do you place on each contribution? How many cakes do I have to bring to be allowed to listen to the music? That's not how it works. Everybody helps according to his time and ability, and then we all enjoy the party. What you are doing is you come to the party, you eat and drink from what others have brought, but when people want some of your stuff you charge them for it. And when they complain you ask them to start charging for their stuff too, and transform the party into a shopping mall. Sorry, but for me that would take all the fun out of it. If you want to join the party you are expected to participate according to your abilities. And yes, with your full-time programmers you can (and should) contribute more than people who just have a few hours a month to spend on it. That doesn't mean you are somehow entitled to get more fun out of the party than they do. So far we have welcomed you to the party, even though you contributed much less than you could have; but the problem is that you are actually preventing others from enjoying the party, and this can't go on. So you can either start participating and sharing like everybody else, or you can stay home and cook your own dinner. But if you want to eat some of what I've brought, the only way is to join the party. Look for a continuation of this thread. |
CrossOver Office under FreeBSD | 05/01/2002 | Archive |
---|---|---|
CodeWeavers Karel Bosschaart mentioned that he got CrossOver Office to work with FreeBSD: FWIW, I installed the linux version under emulation in FreeBSD and made a little write-up of my experience: http://wop21.wop.wtb.tue.nl/cxoffice Except for the flood of unimplemented ioctl's messages it runs quite OK, but of course I'm looking forward to the FreeBSD version. I'll add more of my experiences while using CrossOver Office. Karel mentions he tested FreeBSD 4.5-R, 4.5-S, and 5.0-DP1 with linux_base 6. Francois Gouget was pleasantly surprised it worked, but concerned about the ioctl's performance impact. |
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License,
version 2.0.