WineHQ

World Wine News

All the news that fits, we print.

05/22/2002
by Brian Vincent
Issue: 123

XML source
More Issues...

This is the 123rd 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).

Over at the Kernel Traffic Zack included a note about the new system in place here. Since it's kind of interesting I'll just quote what he said:

Kernel Traffic has just changed its publication system. It used to use a home-grown XML parser that interfaced with a database back-end to produce flat HTML, which would then be uploaded to the various machines in the DNS round-robin.

The new system uses XSLT files to transform the XML into HTML, and uses 'make' to ensure that only the right files are rebuilt. Eventually the publication system will be released with version numbers, revision control, etc., but for now you can still view the files at http://kt.zork.net/xslt/ . The key XSLT file used to produce the HTML on the site is http://kt.zork.net/xslt/kt.xsl , which in turn references files in the various subdirectories.

I'll have more to say about this, and some documentation, in upcoming weeks. For now I'm just letting folks know the files are there, in case anyone wants to experiment with them, and maybe send me patches and feature ideas.

Special thanks go to Joerg Heinicke and Jeni Tennison from the XSL mailing list, who wrote the <kcref> handler in http://kt.zork.net/xslt/html/misc.xsl .

Damian Wojslaw is now translating KC Wine into Polish. It looks great, but since I'm not fluent in Polish that probably doesn't mean much.


This week, 428 posts consumed 1345 K. There were 86 different contributors. 51 (59%) posted more than once. 49 (56%) posted last week too.

The top 5 posters of the week were:

  1. 35 posts in 86K by Alexandre Julliard
  2. 32 posts in 72K by Andriy Palamarchuk
  3. 30 posts in 94K by Francois Gouget
  4. 29 posts in 111K by Steven Edwards
  5. 25 posts in 69K by Andreas Mohr

News: wine-20020509, Wine Press 05/10/2002 Archive
News

Head on over and grab the monthly wine CVS snapshot: wine-20020509. Alexandre noted the following changes:

    More dll separation work.
  • Many async I/O improvements.
  • Still more unit tests.
  • A lot less multimedia code.
  • Many portability fixes, esp. for ReactOS.
  • Lots of bug fixes.

Francois Gouget posted some links to recent Wine articles in the press. In addition, he updated the press section on WineHQ with some older articles. The first article has a decent description of Wine, some of the commercial entities involved, and even a prediction Wine will reach 1.0 some day. The second article discuss Linux penetration in the marketplace with a note that Wine provides an important element for Linux on the desktop.

Last week's broadcast of "The Linux Show" had an interview with Jeremy White of CodeWeavers.I've been traveling for a few weeks now (and fighting with dial-up connections) and just got a chance to listen to it. Fast-forward to about 63 minutes into it to hear the interview.

CodeWeavers released version 1.1.1 of their CrossOver Plugin. Notable additions include support for Macromedia Flash Player 6, Superscape Viscape plugin, and better Mozilla support.

TransGaming will be at the E3 expo on May 21-24 in LA. If you're in town, stop by and see them. They'll be in a booth with Transitive Technologies . (Transitive seems to specialize in optimizing and translating CPU instruction sets from architecture to another.)

Lindows.com got to keep their name . Microsoft lost a motion for reconsideration of the preliminary injunction order from a few months ago. They celebrated by redesigning their website.


Component Owners 05/13/2002 Archive
Project Management

Andriy Palamarchuk has been spearheading an effort to get developers and users to use Wine's Bugzilla . Part of this involves assigning owners to the various parts of Wine and informing those owners when bugs are entered for their subsystem. Andriy submitted a list of possible component owners which generated a fair amount of feedback from people claiming or not claiming responsibility for various areas. Francois Gouget suggested looked at the list of developers on WineHQ, but pointed out the list was horribly out of date. Andriy revised his list and resubmitted it:

List of developers who contacted me:

  • Guy L. Albetelli - common controls
  • Robert 'Admiral' Coeyman - DOS
  • Huw Davies - TrueType support, printing, gdi
  • Francois Gouget - Winelib, Winemaker, headers, icmp
  • Dustin Navea - wine tools
  • Mike McCormack - file system, serial port, named pipes, SMB
  • Marcus Meissner - COM, OLE
  • Andreas Mohr - documentation, installers, memory handling
  • Andriy Palamarchuk - wine applications
  • Juergen Schmied - console, file open dialog

Developers who has not confirmed nor declined suggestion to own a component:

  • Alexandre Julliard - wineserver, kernel, IPC
  • Laurent Pinchart - copy protection
  • Dmitry Timoshkov - NLS, Unicode, keyboard I/O
  • Martin Wick - sockets

Still available components:

  • DDE
  • loader
  • msvcrt
  • x11drv
  • window handling

Some developers are interested by areas which are not components per se. For example - Andreas Mohr worked a lot on installers issues and would like installer bugs forwarded to him. The issue will be forwarded to a person who is the most interested in an issue. Everybody else is also welcome to give me your particular areas of interest even if they do not match component boundaries.

All the developers, QA engineers who is going to work with Bugzilla, please create an account and request privileges to change bugs status at bugs at codeweavers.com.

You do not need to subscribe to wine-bugs if you are not planning to work in the first line of the bugs hanlding (handling of bugs with status UNCONFIRMED).

Please, let me know if I missed anybody. Other comments are welcome too.

Andriy also worked on a form to make bug submission easier and more accurate.


Patch Trading 05/10/2002 Archive
Licensing

Gavriel State wrote in with a proposal for exchanging some code that was developed by TransGaming:

As we have mentioned before, TransGaming would like to offer a trade to Wine authors who have decided to license their code under the LGPL. We have a number of different components that we have developed for WineX that are currently not in the LGPLed Wine tree or the X11-licensed ReWind tree. We are willing to re-licence some these components and allow them to be integrated into the public tree, if we can reach an agreement with current copyright holders of LGPLed code.

As we have stated, we do not believe that it is possible for us to do our work within a pure LGPLed framework. This is for a variety of reasons, ranging from concerns about copy protection issues to working with proprietary platforms. That having been said, we would still like to make use of some individual LGPLed DLLs, and we will be very happy to make any changes we make to those DLLs available under the LGPL as well.

Currently however, we cannot easily take an LGPLed DLL and ship it with WineX due to changes that have happened in the Wine tree for DLL separation. In order for us to do this, the DLL separation work that has gone on in the Wine tree would also have to be made available in the ReWind tree, under the X11 license.

We would like to see the following dll-separation related patches made available to ReWind:

    links deleted, see Archive Link above for complete list

We would also like to see some of the recent async I/O patches made available by Martin Wilck and Mike McCormack in ReWind, and patches based on that work, ie:

    links deleted, see Archive Link above for complete list

In exchange for this, we're willing to make the following code available to ReWind (and thus to Wine) under the X11 license:

  • All of the current work in WineX that supports DCOM and InstallShield (The WineX version of DCOM and InstallShield support works with every InstallShield 6 installer that we've tried)
  • Portions of our copy protection code that are related to low-level CD-Reading and reentrant wineserver calls.
  • A 2D DIB rasterization engine with full support for complex brushes and ROP modes. The DIBEngine is configurable from the ~/.wine/config file, and coexists with the existing X11drv mechanisms for supporting DIBSections. IE: If the DIBSection is in gdimod mode, it will use the X11 primitives, and if it is in appmod mode it will use the DIBEngine if the DIBEngine supports that primitive. Our work on the DIBEngine is ongoing.
  • Our up-to-date SDLDrv, the first really useful non-X11 backend driver
  • Various DirectSound improvements

A number of other miscellaneous fixes, such as:

  • Support for Gamma ramps in desktop mode
  • WSADuplicateSocket support in WinSock
  • Mousewheel support in DInput
  • Left vs right alt/ctl/shift key mapping
  • DInput keyboard buffering
  • DirectPlay improvements

Some of these changes are already available for viewing on the WineX tree on SourceForge. Other parts (ie: the DIB Engine, etc) will be made available for viewing shortly.

In addition, we'll also be willing to redirect some of our engineering time to completing any remaining DLL separation tasks in Wine. Also, the work we intent to sponsor to speedup the WineServer will be made available under licenses compatible with both ReWind and Wine.

We have other things we're willing to trade as well, in exchange for more LGPLed code being made available to ReWind, or commitments to dual-license other code:

  • New under-development work on DCOM to get away from the current typelib marshalling hacks (this will also eliminate some of the visual glitches with InstallShield Installers)
  • XSharedPixmap support in the x11drv. This vastly improves DIBSection performance in some cases, and compliments the DIBEngine work.
  • 3D Sound support in DirectSound
  • Improved support for winelib C++ apps, including msvcrt improvements and support for delayed initialization.

Finally, Alexandre has repeatedly charged that the public availability of our WineX code is discouraging people from contributing games related code to Wine. If the other LGPL copyright holders agree that this is a problem, we're willing to consider limiting the availability of our AFPLed code in some way. We'll have to figure out exactly how though.

We look forward to your feedback.

Alexandre sent a short reply, As I explained already, I think the idea of trading patches is fundamentally flawed. I also think Wine will be much better off in the long run by sticking to the LGPL than by giving it up now for a small short-term gain. So no, I'm not interested in trading any of my patches.


Global Wine Configuration? 05/14/2002 Archive
Fixes

Gerald Pfeifer wondered what was going on with a global wine configuration file, I noticed that in the absence of ~/.wine/config Wine simply refuses to start, and truss (on FreeBSD) and trace (on GNU/Linux) reveal that no other location is consulted for a config file.

Alexandre explained what was going on, The global configuration is no longer supported at this point, mainly because it doesn't play well with WINEPREFIX. I'm planning to implement a more general solution at some point that will again enable global config files. At the moment if you want that behavior you have to create a symlink from ~/.wine/config to some global config.


What is WineLib? 05/14/2002 Archive
Winelib

Lonnie Cumberland wondered:

I have been reading over the Wine documentation but have not come across this yet.

I am interested in having a windows DLL that can access some functions native to Linux.

For instance, possibly an application under wine that allows me to add a new user to my Linux box.

My guess is that I should be able to write up a windows dll that will talk to Linux. Is this correct?

Geoff Thorpe agreed, and thought the benefit would be huge, Won't it be wonderful when some applications will actually work *better* under Wine than in native windows? Ie. under native windows, "click here" will just open IE or whatever, but under wine with a "talk-through" API, it could instead allow the browsing to be hosted either through the 'normal' windows API (presumably launching IE) *or* be passed out to a native browser of choice on the host system (mozilla, konqueror, whatever).

Francois Gouget pointed out that it's such a great idea that it's already been done, The way to do this would be to be writing a Winelib library. This library can be used by the rest of the application, be it Winelib or native Windows, and this library can call both Win32 and Unix APIs. When in a Winelib library, calling a Unix API is no different from calling it from any other Unix library.

He also added a link to a URL where Microsoft Word is showed opening Mozilla to access a URL: http://www.codeweavers.com/products/office/images/msword2000_url.gif


Cross-compiling Wine 05/09/2002 Archive
Ports

Jakob Eriksson announced getting tests to compile with the Mingw compiler:

If you compile with:

    i586-mingw32msvc-gcc -o FILE.EXE -DREAL_EXE file.c

The magic is the defines of ok, todo_wine and START_TEST.

See this as proof of concept, I'm sure someone can make this look better.

(If you have Debian 3.0, just "apt-get install mingw32-runtime mingw32 ".)

How do I make this happen automagically when doing "make tests"?

He went on to explain:

What I want is for the Wine configure to detect that mingw32 is present, then modify Makefiles so that when "make tests" is run, EXE-files are modified. I also don't want to do #ifdef REAL_EXE or whatever in every c-file, I want all that to happen automagically in wine/test.h ! I want the configure script to take care of all that and always compile unit tests twice, once for linux target, once for Windows target. (EXE)

Then a .BAT file could easily be created that runs all the EXEs.

Bang, native unit testing in a box!

Steven Edwards offered some tips, then Alexandre offered a patch:

OK I have hacked the makefiles to make cross-compilation possible. It's a bit tricky because some parts of Wine need to be compiled twice, since they are used both at compile-time and at run-time. The way to do it is:

  • create 3 empty directories: wine-src, wine-gcc, wine-mingw
  • put the full source in wine-src, making sure you don't have any binaries in there
  • in wine-gcc, do:
    ../wine-src/configure
    make depend
    make tools
  • then in wine-mingw do:
    ../wine-src/configure --host=i586-mingw32msvc --with-wine-tools=../wine-gcc
    make depend
    make

This should build a full cross-compiled Wine. Of course most of it doesn't actually compile at this point, but fixing that is left as an exercise for the reader...


WineHQ: .org or .com? 05/15/2002 Archive
Project Management

Andriy Palamarchuk saw a reference Jeremy Newman made to WineHQ.org and wondered why he didn't reference WineHQ.org. Historically, WineHQ was a ".com" address even though it was an open source community site. Jeremy explained:

The story is pretty simple. The .com site is the original name to WineHQ before and after Corel hosted the site. CodeWeavers originally registered .org to simply be a mirror of the .com site. But, since they are now both hosted on the exact same server it does not really matter which you use.

It is my suggestion to use .org as the preferred as it seems to sound better than .com on an open source site.

This generated a bunch of opinions. Everyone felt whatever name was used should be used consistently throughout all Wine documentation and references. Jeremy White felt if it wasn't broke, don't fix it. But others pointed out that ".org" sounded better, and now was the time to fix it (i.e. before Wine hits 1.0). Alexandre complained that switching addresses would generate twice as much spam in his mailbox. Andreas Mohr then called for a vote on the matter (which didn't seem to generate many public replies.)


SoundBlaster Emulation 05/15/2002 Archive

Christian Costa sent in a patch implementing preliminary support for DMA and SoundBlaster emulation. Dustin Navea wondered exactly what it was for. Andreas Mohr explained that that all the old DOS games required it and added, Thanks for this very cool patch !!!

Christian pointed out that it wasn't quite as exciting as it might seem because most old DOS games don't run under Wine.


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.