World Wine News

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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