Wine Traffic #228 For 25 Jun 2004

This is the 228th issue of the Wine Weekly News publication. Its main goal is to teleport. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org

There were 54 different contributors. 22 posted more than once. 25 posted last week too.

Mike Hearn pointed out I made a mistake last week when I said Microsoft Project isn't supported by CrossOver Office. In fact, thanks to the work of Dmitry Timoshkov you can now use MS Project 2000 and 2002 with CrossOver Office. They're currently supported at the 'bronze' level. MS Project 2003 is not yet supported.

TransGaming announced some stuff this week. Their new website was launched on the same day they released WineX 4.0, titled "Cedega". The release notes are much more interesting than the press release. There really is some cool, new gaming technology in it. In related TransGaming news, over at DesktopOS.com there's an interview with TransGaming's Vikas Gupta, Gavriel State, and Peter Hunnisett:

DesktopOS.com: When TransGaming was founded, the company promised to release the entire code tree for WineX/Cedega under an open source license when the subscriber base reached 20,000. What happened to this goal?

Vikas Gupta: This has got to be one of the most commonly asked questions when we are interviewed. The philosophy related to releasing our source code was conceived almost four years ago and was representative of the state of the Linux community at that time. A lot has changed since then, including dramatic changes to the Wine license itself. TransGaming has to evolve as the Linux community itself evolves and we are adapting to changing times. Today, Cedega contains some extremely sophisticated source code that we simply cannot share publicly due to our agreements and relationships with some of the very companies whose games and technologies we support; this includes source code that handles copy-protection, DRM, and other IP that allows us to continue to offer a valuable product to our customers. That being said, we still contribute a great deal back but it must also be noted that Cedega, today, is very different from Wine.

Gavriel State: One of our original concepts was that of the 'Street Performer Protocol': set a goal and release everything when that goal is reached. We had hoped to have a continual series of goals that we could set that we could use on an ongoing basis. Unfortunately, external factors such as the LGPL relicensing of the Wine code made it impossible for us to maintain that model.

Instead, we have moved to a model where we release and share certain portions of our work, but still keep our graphics crown jewels to ourselves. Over the years, we've released tens of thousands of lines of code to both the Wine and ReWind projects and we expect that we will continue to do so with some portions of our work.

Some of our Open Source contributions include: the complete rearchitecture of the DirectDraw 2D graphics system and the DirectSound audio system, a number of DirectInput improvements, a 2D DIB rasterizer, the TG-Martlett font, vast amounts of work on the OLE, COM, and DCOM APIs used for Installers and other software, the Wine IDL compiler, WIDL, work on the WinInet APIs, including support for https over SSL, and the prototype ShmServer for accelerated Win32 Kernel calls.

A quick look at ReWind shows the project to be even more stagnant than usual. While it may be useful for it's liberal BSD-style license, the technology is vastly out of date compared to WineHQ. There's been a whopping 11 patches submitted to their mailing list over the past 2 years. They've had as many CVS commits in all of 2004 as Alexandre committed to WineHQ this past week.

Wine has had a control panel utility for a while - basically a small Winelib application that launches control panel applets that have been installed by other applications. It's not pretty, but it does work. Steven Edwards shared a new version this week:

This a replacement control panel that was developed for ReactOS until the Control Panel namespace in Shell32 is done. Its far from perfect but seems to be a little better than the older implementation. Feedback is welcome.

Mike Hearn asked for a screenshot and Steven replied with one a few hours later.

From time to time Wine is fortunate enough to receive donations. We actually have a pretty good track record of using the money for something good. Jeremy White wondered if we should look into spending a bit of it right now:

Say, I've gotten in a few fairly generous donations lately, and so the Wine fund has a bit of money (around $800, afair).

Now, the bulk of that is marked for embezzlement <g>, but it does leave a bit left over that could go to help Wine.

The question is: how could that money be spent effectively?

I have several thoughts on this, but would like to open it up for discussion.

My suggestions are:

Buy software for proven Wine hackers

If Wine hackers are lacking for licensed software, I could buy + ship it to them. My financially prudent side suggests that games would be a great way to do that, because we can buy a lot of games for $800, and only 1 copy of MS Office for the same price... :-/

The trouble with this idea is that the few times I've tried to offer software to Lionel and others they tell me that they have all they need.

Sponsor Wineconf 2005

We spent about $1500 of the Wine fund sponsoring some folks to travel to Wineconf this year. We could similarly use the funds for the next Wineconf. That suggests saving it for this purpose would be prudent.

Thoughts? Suggestions? Comments?

Mike Kost wrote back and suggested a hardware purchase or two could be useful for developers that might need it. A few other people were in favor of saving it to support a Wine conference.

If you shop online you can also support Wine just by following these links and purchasing things at Amazon.com or CDnow. We'll get a few pennies of that donated back to us and you'll get a warm, fuzzy feeling knowing you've contributed something back.

We reported a few weeks ago that there were problems running Wine on an AMD64. A few days after that Christof Meerwald reported that it worked ok for him, however it was important to make sure the system was using new software:

Hmm, wine 20040505 works on my AMD64 system (using a biarch 2.6.6 kernel, Debian woody for the 32-bit stuff and the Debian AMD64 port in a chroot environment for the 64-bit stuff).

So I guess, either your kernel is outdated (there have been lots of improvements in the 32-bit emulation layer in recent kernels), or there is some problem with your 32-bit compiler setup or libraries.

That's all fine and well - it makes sense that the emulation layer might cause problems. This week however, Sean Kormilo inquired about the feasibility of a native 64-bit port:

I'm interested in porting Wine to run in native x86_64 mode, and was wondering if anyone had attempted to do such a thing already? I notice that there does not appear to be any support in CVS to do this, but figured that perhaps someone else is already undertaking such an effort.

My main motivation for doing so has to do with video driver support, in that the 32bit "emulated" applications are unable to use the 64bit 3D accelerated drivers, and fall back to software rendering - which is less than ideal. While this may eventually be resolved by the device drivers, I'd rather not wait for them.

Any comments, or hints as to what needs to be done (other than the obvious compile time fixes) would be appreciated. I've got software development experience, but none porting code from a 32bit architecture to a 64bit one.

Alexandre pointed out some architecture concerns, " I hope you realize that a 64-bit Wine is not going to let you run Win32 binaries, so it will only solve your problem if you have either a Win64 version of your app, or a Winelib app. But as long as you are aware of that, by all means go ahead, I don't think anybody else is working on that at the moment."

Sean then asked why an application couldn't see a 32-bit environment: " I would have thought it possible to have WINE itself compiled as a 64 bit application (such that it can pick up and use 64 bit linux libraries), but still represent itself as a 32 bit environment for the windows binaries. "

Alexandre explained, " Well, it would be possible, but it would require adding a translation layer for every single API call, which would be a huge task for very little benefit. It's much easier to do it at the syscall level."

James Courtier-Dutton wanted to know if anyone had figured out how Windows handled DVD's:

The Windows api method uses the function call IDvdInfo2::GetDiscID

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/htm/idvdinfo2getdiscid.asp

This returns a unique 64bit ID for a DVD. Has anyone found out what exactly it does to create this 64bit ID. It would be nice to get linux DVD players to be able to use the same method.

Tim Hentenaar was also interested and mentioned he might try figuring it out. However, if someone out there already knows the answer you might want to write to wine-devel -at- winehq.org.

A few weeks ago (issue #225) we discussed some problems with the MSVCRT library. Dimi has been working on it and this week announced:

Here is a patch that separates the implementation headers from the public ones. It's not yet ready for inclusion, but it's pretty close, so I'm sending it off to the list for comments.

Some of the things in here:

cleanup of naming conventions. Things shared with the public header *always* start with MSVCRT_
stuff that's private, doesn't start with MSVCRT_ From this two rules follows that a symbol starts with MSVCRT_ if and only if it's shared with the public headers, where it appears without MSVCRT_
most private functions start with msvcrt_ now, a convetion that was already in place, but not followed to the letter
there is a sh script that uses this simple rule to generate the test file. Do we integrate the script with the build system?

What's left to do:

if we keep the test generation script, it needs to get integrated in the build system
there are still a bunch of functions that are shared with the public headers that don't have the MSVCRT_ prefix. They need to be renamed
more cleanup in the public headers, remove the MSVCRT_ from the sentries.

Comments, flames, etc. appreciated. It's been sitting on my HD long enough, it's time to get it into the tree.

Alexandre requested some things to be done differently. Dimi made the changes, but thus far the patch is uncommitted.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	19 Jun 2004 - 25 Jun 2004	(2 posts)	News: Errata - MS Project, TG News
2.	22 Jun 2004 - 23 Jun 2004	(3 posts)	Control Panel Replacement
3.	18 Jun 2004 - 19 Jun 2004	(3 posts)	Using Donations
4.	21 Jun 2004 - 22 Jun 2004	(4 posts)	64-Bit Support?
5.	19 Jun 2004	(2 posts)	Need DVD Info
6.	18 Jun 2004	(1 post)	Remove the MSVCRT() Macro

Wine Traffic #228 For 25 Jun 2004

By Brian Vincent