This is the 132nd 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).
Some big announcements from the Wine commercial front. We'll start with TransGaming.
The press release from TransGaming announced three new games available: "KOHAN: Immortal Sovereigns", "KOHAN: Ahriman's Gift" and "KOHAN: Immortal Sovereigns - Special Awards Edition." Available where? At TransGaming's new webstore. Itching for a new addiction? Twenty dollars will get you a new game. The Kohan games are available for download through the webstore.
CodeWeavers has released a beta of a server edition of CrossOver Office version 1.2. From their web page:
CrossOver Office Server Edition allows you to run your favorite Windows productivity applications in a distributed thin-client environment under Linux, without needing Microsoft Operating System licenses for each client machine. CrossOver Office Server Edition allows you to satisfy the needs of literally hundreds of concurrent users, all from a single server.
Server Edition is also a great addition to Solaris environments, since our built-in support for Solaris desktops makes running Windows applications a possibility on Sun workstations as well. This makes CrossOver Office Server Edition an outstanding choice for engineering, CAD/CAM, scientific, and other high-performance workgroup computing environments.
I imagine one of the first things people will think of is licensing. Obviously the above statement about not "needing Microsoft Operating System licenses for each client machine" is no different than the standard CrossOver Office product. But what about the usage of the applications? No doubt CodeWeavers has thought long and hard about this. They have a page about licensing on their website.
And out of LinuxWorld came this report on OSNews.com:
CodeWeavers were there, they were presenting Office under Linux, and they are creating two new products, one of which is the ability to run Photoshop properly under Linux! In fact, they had a beta ready to ship, but they found some last minute bugs, that put the release on hold.
In case you're wondering, here's what the app database says about Adobe Illustrator 9.0 and Photoshop 6.0
Fabian Cenedese wanted to know a good way to view the Wine
documention,
What is the easiest way to view/print the wine-help files that are in sgml?
I fiddled around with sgmltools but couldn't get a useful output
Vincent Beron answered first,
Running '
make' in the documentation directory. It will create an HTML and a
PS copy of it. Else, I think there's a current copy on
http://www.winehq.org.
Andriy Palamarchuk clarified that,
I'm afraid just running "make" is not enough. You'll have to run "
make html".
Lawson Whitney produced a little one-liner shell script to be used as a viewer:
I use this:
#!/bin/sh
#<wine>/documentation/*.sgml reader (c) 2000- Lawson Whitney
# Use, distribute, or change at your own risk.
sed -e 's/<[^<>]*>//g' -e 's/</</g' -e 's/>/>/g' $1 |less -ni
Jeremy Newman suggested a different, low-tech, approach and the rationale for it:
The EASIEST would be to download the PDF versions at: http://www.winehq.com/Docs/
This would give you the best output. Printing the HTML would not look nearly as nice.
You could make the PDF versions yourself from the tree, but you would need to have all the correct SGML to PDF utils installed. There is a script in the documentation directory called 'make_winehq'. Take a look at that script, or just run it to build the HTML, PDF, and PS versions of the documentation.
Shachar Shemesh posted some infrastructure for forthcoming bidi support via the fribidi libraryu. Alexandre suggested:
I suggest you write the real code first, and let us worry about the configure stuff later. There is no point in adding configure dependencies for non-existing code, and once the code is done we can have a better idea of what dependencies you actually need.
As mentioned already, I think including the fribidi algorithms directly in the code is a better approach, but the only way to really say which is the right way is to get something working.
Shachar pointed out,
I have the creeping suspicion you don't realize just how much of a
shortcut using fribidi is. All of the stuff we have there already that
says "exteremely preliminary" is going to be replaced with approximately
four to five lines of code.
Alexandre replied,
Knowing Microsoft, I have the creeping suspicion that it's not going
to be that easy. I'd be very happy to be proven wrong, but there's
only one way to do that, and it's to show us the code. Not the
configure checks, the actual code.
Shachar had some ideas about the implementation though,
At the moment, I think it is particularily counter-useful to have
mandatory BiDi support in Wine, as this means (among mere applying the
BiDi algorithm) translating each string printed to UTF-32 and back
(unless we can say for sure that no BiDi is going to be required -
havn't found a really good algorithm for that yet, but I'm working on
it). Not having the proper library on your machine is a pretty good way
of indicating that BiDi is not interesting to you (and is, more or less,
the way MS tackled the exact same dillema).
Alexandre wondered about using FriBiDi as an external library:
Well, obviously the number one reason for having that code inside Wine is that we can make it work with UTF-16 and skip the conversion step. And if there's really a need to disable BiDi for performance reasons, a config option is a much better way than trying to guess depending on the existence of an external library.
The only interesting question is whether using the external library allows us to do everything we need with reasonable performance, and whether it makes things easier. The only way to answer that is to try it one way or the other and see what you come up with.
If you think using the external library is the way to go, fine, do it that way and submit a patch. Then we can start really discussing it. And don't worry about configure checks or packaging issues; we'll deal with that later on.
Shachar posted a preliminary patch and noted:
No actual patch, yet, as I still have a few heap corruptions in certain cases. Attached, however, is the preliminary "Wine with external libfribidi". Do your worst, come back with an opinion. This is not, yet, cleaned up, but the interface is a pretty good representation of what the final version is going to be.
As a bynote, I will add that it seems that libfribidi may not be as mature as I have hoped, and if problems keep popping up, I will put it into our code myself (or, more preciseley, try). It will not be an easy task, as it currently carries it's own unicode tables, configure scripts, and so on. Since you vulenteered to help with this.... ;-).
Later, he added,
Is fribidi going to support all the functionality we are likely to need?
Yes, I believe it will. That is why I tried to stress the amount of
shortcutting this library is going to get us. Implementing the various
unicode algorithms is a pain, and one to be avoided. If, at some stage
in the future, it turns out that some programs really do need classes
from GetCharacterPlacement, well, we'll have this discussion again.
Alexandre disagreed,
That's not acceptable. It's perfectly OK to say that we won't
implement some things until we find something that needs them, but
it's not OK to pick a design that will prevent us from implementing
them once they are needed (and they *will* become needed someday).
Shachar felt it was good enough and didn't think there would
ever really be a need to develop this further. Alexandre was cautious
though,
What I'm saying is that it's not a good idea to start using fribidi,
create dependencies and problems for packagers, etc. if we know that
it's a wrong design and that we will need to replace it. The truth is
that bidi is not really a priority feature (as shown by the number of
people interested in making it work), and so it doesn't really matter
if it works tomorrow or only in 3 months. What matters is to pick a
correct design so that if more people start to care they can build on
it, instead of having to throw it away and restart from scratch.
Alexandre did a CVS commit and noted,
Moved a large number of 16-bit functions to a separate gdi16.c file.
Dimi Paun thought it was good start:
This is a great idea that I've been advocating for a loooong time now <g>.
I think moving 16 bit code into separate files is cool:
- runtime efficiency: If 16 bit code is not invoked, it's not going to be paged in during execution
- code neatness: developers working on the 32-bit code (which is _the_ code in Wine) will not get distracted by silly 16-to-32-to-16 bit conversions.
- helps correctness: 16-bit code is in general a simple:
Which means there is a lot of repetition, template-like coding. Any departure from the usual pattern is a *lot* more easily spotted by the naked eye if it's present in a file that does just that.
- 16-to-32 bit conversion
- call the 32-bit equivalent function
- 32-to-16 bit conversion
- 16-to-32 bit: we can more easily see (and fix) cases where 32 bit code calls 16 bit code.
For all these reasons, I think we should have _all_ 16-bit code into separate files. Always. Who knows, maybe we can have makefiles done such a way that we can avoid compiling 16 bit code altogether! :) Even if only as a simple check that no 32 bit code calls down to 16 bit...
And again, the _same_ rationale applies to xxxW & xxxA functions, but I'll not pursue this point for now ;).
Mark Hannessen noticed:
i just found out that transgaming has a new "quartz dll" in there CVS. it apears to use ffmpeg libavcodec.
the good news: libavcodec is LGPL !!!
so there is a good chance that the entire quartz dll is going to be LGPL
Ove Kåven pointed him to the license file:
Going to be? It has been for a while already... from the LICENSE file that was in effect for the WineX 2.1 release (CVS tag "winex-2-1", in the "winex-2-0-branch", where the new quartz code is taking shape):
Additionally, the following components are covered by the GNU Lesser General Public License, found in the LICENCE.LGPL file:
dlls/avicap32/
dlls/msdmo/
dlls/quartz/
dlls/msacm/winemp3
programs/regsvr32
Someone pointed out there's a toolchain using Wine that compiles EPOC applications:
GnuPoc makes it possible to develop EPOC applications on your GNU/Linux machine.
It is using GNU make, Wine and GCC crosscompiler for ARM.
What is EPOC you ask? It's a "32 bit operating system developed by Psion and now Symbian Ltd (also called Symbian OS)". Typical uses are cell phones and PDA's. Using Wine it's possible to run the software development kits published by various manufacturers.