WineHQ

World Wine News

All the news that fits, we print.

03/13/2006
by Brian Vincent
Issue: 308

XML source
More Issues...

This is the 308th issue of the Wine Weekly News publication. Its main goal is to make eggrolls. 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


This week, 201 posts consumed 368 K. There were 73 different contributors. 38 (52%) posted more than once. 29 (39%) posted last week too.

The top 5 posters of the week were:

  1. 11 posts in 11K by lav at etersoft.ru (Vitaly Lipatov)
  2. 11 posts in 33K by stefandoesinger at gmx.at (Stefan Dösinger)
  3. 10 posts in 10K by julliard at winehq.org (Alexandre Julliard)
  4. 9 posts in 8K by dank at kegel.com (Dan Kegel)
  5. 8 posts in 7K by hverbeet at gmail.com (H. Verbeet)

News: CodeWeavers News Archive
News

There's a little news out of CodeWeavers this week. First, they've teamed up with Versora to offer a Linux desktop migraton and productivity bundle. Versora has a product called Progression Desktop that will migrate settings from Windows to Linux. That product runs $29.00 allows you to:

Migrate Microsoft Outlook and Outlook Express to Novell Evolution, KMail, Mozilla or Thunderbird, Microsoft Internet Explorer to Mozilla, Firefox or Konqueror, Microsoft Office to OpenOffice.org and more.

At this point it looks like the Versora deal is just a bundling that contains the Progression Desktop and CrossOver Office 5.0. The products are not integrated together at all. It seems like a good deal though - $49.00 for both. For more info, read the press release .

I stumbled across more news from a few weeks ago concerning CodeWeavers and porting some software. From the article :

CodeWeavers and WorldVistA have announced a strategic partnership aimed at making low-cost healthcare management software more freely available worldwide. As the centerpiece of that partnership, CodeWeavers is porting the CPRS (Computerized Patient Record System) component of VistA, a free electronic health records software application developed by the U.S. Department of Veterans Affairs, for use on Linux open source computers.

CodeWeavers' version of the VistA CPRS (Computerized Patient Record System) graphical user interface will be promoted by WorldVistA to non-profits as well as healthcare providers in developing nations around the world. The goal of the two organizations is to increase the viability of implementing VistA, thereby giving providers the same capabilities in records management enjoyed by their better-funded counterparts in the industrialized West.

VistA (Veterans Health Information Systems and Technology Architecture), a robust and proven client-server application, has been used and continuously improved by the VA since the mid 1980's to support high-quality medical care i for military veterans in the United States. Available for free public use via the U.S. Freedom of Information Act, VistA and its accompanying CPRS is of great value to healthcare organizations that cannot afford the immense cost of proprietary commercial alternatives.

Neato. It sounds like a win-win situation.

Completely unrelated, things that make you say "hm ."


Wine on Mac OS X Archive
Ports

Things have been a bit vague concerning Wine on Mac OS X (Intel). Questions arrive on wine-devel almost weekly concerning whether such a port will happen. It's known that CodeWeavers is working on it, and even has a developer or two dedicated to it. Over on the Darwine side, things have been really quiet. So what exactly is going on? Will Wine ever work with Mac OS X? Jeremy White sent an email to the Darwine mailing list with some details about what's happening:

There are a range of issues with OS/X. For one, Apple has demanded a 16 byte stack alignment on every call. Modifying that is non trivial; it requires a gcc patch.

Further, there are a lot of *nix functionality that Wine relies on being done correctly. Things like signal handlers, access to system registers, and these sorts of things that OS/X does not provide, or when they do, they provide a buggy implementation. Sadly, the net effect is that only a handful of applications work properly right now; apps such as notepad and so on.

These are all issues we're working on at CodeWeavers; I'm hoping we'll be able to release our changes in the relatively near future (our current official line is second quarter).

But there is still a lot of hard work to be done, and a lot of kludges that need to be cleaned up.

I know that it doesn't help that Alexandre commits our changes to the WineHQ tree with very little fanfare. But, don't worry, we plan on making a lot of fanfare when we think Wine is usable on an Intel Mac

So where does that put us? Well, it seems CodeWeavers has waded deep into the waters and has started tackling the big issues. Those issues seem pretty difficult though, so it may be some time before we see something usable. It doesn't appear anyone other than CodeWeavers is working on this (or, at least they're not contributing patches back to Wine.) Right now that appears to be a good thing - overlap with development being done behind closed doors can lead to wasteful duplication.

Even after the problems Jeremy mentioned are solved, there's likely to be some integration issues. One problem that gets mentioned quite a bit concerns what kind of display driver to use. OSX doesn't install X Windows by default, so it would be nice to have a native Quartz display driver. Fortunately, Wine has been written to abstract a lot of the display driver stuff away from the rest of the code and it's possible to create a drop-in replacement. Some initial stabs have been taken at that, but it may be too large of a task at this point. Even then, things like hardware accelerated DirectX might have a lot of problems so the initial versions will likely focus on office applications.


WineD3D Issues Archive
DirectX

The DirectX code in Wine continues to be developed. There's some very dedicated developers, but their time seems to be limited. With everything in flux, issues pop up every week of things that need to be addressed. I'm just going to cover some of these that appeared in different threads so you can get a feel for what is and isn't working.

First, Tomas Carnecky was concerned because the World of Warcraft "public test release" requires the DirectDraw DLL to be unloaded and right not that isn't possible in Wine. Stefan Dösinger elaborated on what the problem was and explained the correct solution is to migrate ddraw to a new implementation (see WWN #307 ) rather than patch up the current code:

The ddraw implementation has some unloading bugs at the moment. Not restoring the glx context (that's the problem you reported, right) is only one of them. Another is that the screen resolution isn't restored when the app doesn't care for releasing its object.

I have this problem in mind, and I'll check WineD3D for it, as it most likely affects all D3D libs. Once it's fixed in wineD3D and ddraw uses wineD3D for rendering, this should be sorted out.

Sorry for not fixing this at once, but time is limited ;). If you want a solution now, you're free to fix ddraw. But I registered that issue and it's on my lengthy todo list.

In another thread, Adam Luchjenbroers began looking into a big chunk of code regarding surfaces:

I've been using and tracking Stefan Dösinger's work re: DDraw over WineD3D and decided to try and find out if IWineD3DSurface was far enough along to be able to be used in place of IWineX11Surface for 2d applications (Hopefully to eliminate depth conversion issues).

Short answer, no.

Long answer, Screen displays blank, trace log shows that glReadPixels at line 615 in wined3d\surface.c (LockRect) is failing with error GL_INVALID_OPERATION. Further investigation reveals that this is because glFormat is GL_COLOR_INDEX, yet the display is an RGB visual (presumably because an indexed colour visual was not available, and this buffer is connected directly to the screen).

I figured I'd look to the people already familiar with the WineD3D\DDraw codebase before I tried to figure out my own solution.

Stefan replied with details about that:

That is not supported right now. My current priority is to get all previously supported apps working in the way they where working before. Roderic has posted a patch for the current ddraw code to address this, this could be used to extend WineD3D.

At the moment I have problems with LockRect / UnlockRect, described here: http://archives.free.net.ph/message/20060213.220622.51814d8e.en.html (The sf.net archives broke the attachment). This is needed for DDraw, and it's also a showstopper for many D3D7 games.

So what's basically needed for DDraw over opengl:

  • Indexed colours
  • Better UnlockRect code
  • Handling for all Blit cases in BltOverride
  • A opengl accelerated BltFast override

Finally, Stefan wondered about a refcounting problem and sent a long email describing what he ran into along with a possible workaround:

I have a question regarding some code that might be rejected by Alexandre when I submit it. The problem is that I have to do a refcount hack in my new ddraw code to destroy textures properly. I CC this mail to AJ because it's him who has the last word ;)

WineD3D and Direct3D7 have different ideas about handling mipmap textures. In d3d7 they are complex surfaces - a bunch of surfaces with a root and sublevels. All surfaces in the compound have their own refcount, but they are all destroyed when the root is destroyed. In WineD3D there's the texture as a container, and the surfaces in the container have their refcount linked to the container (See the patch H. Verbeet sent a few days ago).

In d3d7 the application destroys the first surface to release the whole texture. My first idea was to Release the WineD3DTexture. It would then call the Release method of all the sublevel ddraw surfaces, which would destroy them. This works for a correctly written application, but applications call GetAttachedSurface for the sublevels, which addrefs, and many do not Release the sublevels after GetAttachedSurface(). This leaves the sublevel surfaces with a refcount of 2 or more when the root is destroyed. To make sure that they are destroyed, I set their refcount to 1 when the root is destroyed. When the last reference to the WineD3D Texture is released, wineD3D will destroy the sublevel surfaces.

Is such a thing acceptable for Wine? Does anyone have a better solution? If you need some code to look at, I'll upload an updated patch to my homepage later.

One suggestion that had been mentioned in the past was to simply destroy the object regardless of the refcount. Stefan noted that that the problem with that is WineD3D can crash in some cases.


WineTools.. part II Archive
Utilities

WineTools came up again this week. For some background, you can check out WWN #304 . Basically everyone falls into three camps:

  • Those who think WineTools makes life easier to install programs and should therefore be an integral part of using Wine.
  • Those who think WineTools should be eradicated because it covers up some big problems and does it in a way that makes troubleshooting problems really hard.
  • Those who think WineTools provides a handy service in theory, but falls apart in implementation.

Of those, there doesn't seem to be a lot of productive discussion between the first two groups. The third group hasn't expressed a lot of ideas on how to fix the problem. This week Rich Gilson jumped in and sort of summarized the current state of affairs and then brought up a new idea:

The reality that I have come up with is this: Even following the instructions provided in the appdb to install IE6 (which is necessary for almost anything else to work properly) I can't seem to get it to install properly. When I run an install through WineTools, it works flawlessly. When I try to install TurboTax under "pure" Wine, it fails miserably without having to do dll overrides and such. When I install it under WineTools, I have no problems getting it to run without having to tweak the hell out of it.

Please don't misunderstand me, I have a great deal of respect for what what the Wine developers have accomplished so far; however, I feel that those that have put the effort into WineTools have done so because they saw a need and filled it. In the realm of ease of use and user-friendliness, Wine is horribly lacking. Yes, it is getting better, but I think that WineTools is the closest thing I've seen that would make it so that an average user could use it.

IMHO, the Wine developers should spend less time b*tching about WineTools and more time figuring out how they can 1) build a front-end that is better than WineTools, or 2) help improve WineTools so that it works more to their liking but still offers an easy, user-friendly interface.

Personally, I would like to see an application (be it WineTools or something else, it doesn't really matter to me) that would interface with the appdb. You could launch this front-end and it would pull up a list of all the applications in the appdb that have special "config" files. These files would tell this front-end EXACTLY what dll overrides are necessary, what files to run, what needs to be installed beforehand, etc. Then, if there is ever a change (due to Wine improving support for a particular dll so that an override is no longer needed, for example) all that would have to be done is to update the "config" file attached to the program in the appdb and *bingo*, you've just "updated" your front-end!

I say I would like to see it because I do not personally have the requisite programming skill to accomplish such a task, but I'm convinced it could be done and that there are programmers out there in the Wine community that would easily be able to accomplish such a task.

This whole Wine/WineTools argument has been a thorn in my side for a while because I see both sides of the argument and can understand both stances. However, I'm also watching and not seeing any compromise being made. It's like both sides have formed ranks and dug in.

It's not my intention to just whine and cry about things, but I'm not in a position to directly help. What I can do is offer my ideas and opinions. I hope I haven't pissed too many people off because that was not my intention.

I do look forward to every new release of Wine that comes out, hoping that it's that much closer to allowing me to leave Windows behind for good.

Tony Lambregts, one of the AppDB developers, replied with more details about what could potentially be accomplished:

I think this is a "Good Idea" (tm)

There are always going to be programs that need tweaks to get them to run.

I know of a few that will work fine just by changing the windows version but fail miserably with a "clean wine" [1]. These programs usually fail in XP as well but it would be nice for the users to have an easy way to get them to run "out of the box" in wine

There are others that look for a certain file and if it does not exist the program fails[2]. Just creating an empty file with the appropriate name is often enough to get the program working. This is a class of bug that is sure to be around for a while.

The last class of bugs are the ones that require native (windows) DLLs [3]. It would be nice to be able to keep track of these somewhere so that developers know which files need to be worked on

Most people are not programmers and even fewer are capable of being developers but if we can find a way to make everyone's life easier, both developers and users, then we should do it.

In simple terms we get WineTools to query the AppDB with an application name (ie somename.exe) and we return a list of applications for the user to choose from and then, after the user selects the program, WineTools gets the appropriate overrides from the AppDB and sets them for the user.

I think that that this is do-able if we work together.

Jason Green gave a braindump of a tasklist:

here's a [very incomplete] list of what would need to be done to pull this off:

  • AppDB would have to be extended to be able to get and report this data, and it would make sense for each App's maintainer to be able to manage that information.
  • Biggest issue here is that this information could have a tendency to change very rapidly, so it might overload the app maintainers if they had to track this for each version of wine. What I think would make sense is to have regular snapshots (every 3 months?) and release a new version of "WineTools Plus" or whatever you want to call this thing a month later to give the maintainers time to update each of their apps based on the frozen version.
  • Data needed: AppID, AppVersionID, WineVersionID, Window Version, DLL Overrides, Window settings (fullscreen/windowed - sometimes an issue), Sound options, Video acceleration required, General notes or HOWTOs, etc. You would need separate overrides/settings for Installing vs. Running the app.
  • AppDB could dump this information to an xml format which "WineTools Plus" could be distributed with. Maybe have an option to download the latest xml file directly from winehq.org.
  • The 'WineTools Plus' front-end would just be a menu which would query all of the apps in the xml dump. The user picks the app they want to install, and it reads the necessary information, verifies the source installation media, and goes at it.
  • Applying patches to apps might get tricky (e.g., where wine only successfully runs version 1.5 of the app, but 1.0 is on the CD), but I'm sure it could be worked out.

Anyway, there's a start. That would encourage users to get involved in the AppDB reporting process as well as better organize how to just "get things done" using wine.

Will the idea ever get off the ground? Sadly, I don't think it will. It seems like the AppDB guys might be able to get the necessary additions made, but WineTools is another story. There aren't very many WineTools developers (two?) and the changes needed seem pretty large.


AMD64, FAT32, and Failing Apps Archive
Fixes

A few weeks ago Christian Schneider reported a problem that no one had the answer to. Apparently at some point he upgraded to an AMD64 and some of his DirectX games stopped working with Wine. The errors he was seeing were kind of strange. This week he reported that he figured out what the problem was. While this is probably an uncommon configuration, it's quite possible someone else is running into this:

I found out that the problem doesn't seem to be related DirectX nor x86_64 libs. My games were all installed on a FAT32 partition which is also available for my parallel installed Windows XP. But the programs that worked I had installed directly to drive C: (~/.wine/drive_c).

Now after I installed any of the games to the fake windows directory, they worked again! Renaming the installation directory and setting a symlink to the same game directory on the FAT32 parition, and the game crashed again.

The debug messages showed that the last called function always was ntdll.NtQueryDirectoryFile. Grepping this function name from the log file showed the last call to it:

    0009:Call ntdll.NtQueryDirectoryFile(0000009c, 00000000, 00000000, 00000000, 55dad048, 558f2a58, 00002000, 00000003, 00000000, 558f2a3c, 00000000) ret=559c6246
    err:seh:setup_exception nested exception on signal stack in thread 0009 eip 55725f43 esp 55589c90 stack 0x55ca1000-0x55db0000


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.