World Wine News

• Support for Xcursor.
• A range of fixes for various installers.
• New builtin xcopy tool.
• The usual assortment of Direct3D fixes.

Linspire, Inc. developer of the Linspire commercial and Freespire community desktop Linux operating systems and developer of CNR, a one-click digital software delivery service for desktop Linux applications, libraries and packages, and CodeWeavers, Inc., the leading Windows-to-Linux software developer, today announced the release and support of CrossOver Linux 6.0 for CNR. This marks the latest CodeWeavers upgrade for the market leading product that allows the running of native Windows applications within a desktop Linux operating system. Incorporating substantially improved support for many popular games, including World of Warcraft, Half-Life 2 and Counterstrike, CrossOver Linux 6.0 now offers CNR users more flexibility than ever to run the Windows applications they need. CrossOver Linux 6.0 is immediately available via digital download using the CNR one-click download and installation software delivery system at: http://www.linspire.com/crossoveroffice

Anyway, with Wine (the Windows emulator) installed on Linux I found that I can run my favorite Windows-based email client and RSS application, so I don't have to switch to some other Linux-based varieties. Not that I'd use them very much anyway - my primary desktop system is Windows-based, but it's nice to have them available if the need arises.

I've been following the list for about a year now, just reading and learning. Through this process, I've come to wonder about the following question -- what should be the goal for Wine 1.0? I know a lot of development is focused around getting one particular application or another to work, especially from the folks over at CodeWeavers, but with version numbers approaching 1.0, should there not be a set goal of functionality? My personal thought is that Wine should head in the direction of 100% compatibility with a particular version of Windows. Anything that ran on that version should run on Wine 1.0 with no problems. Any thoughts?

Yes indeed. And the only reason I haven't jumped up and posted a proposed list of applications to support for 1.0 is that real app testing is gobs of work, more than we have resources for.

The tests at http://cxtest.org could be an important part of the equation.

FWIW, a couple of us have been puttering away on a scheme to make writing application regression testers easier. No promises, though.

I see Wine 1.0 as a set of features that AJ has decided upon, once the feature set is in the tree then a feature freeze will go onto effect... Then one to six months of only bug fixes. Then ouila! 1.0 is born. At the last Conf if memory serves me correctly there was mention of a feature freeze happening sometime early this year. And I would only guess to say the release notes after the freeze would read "X" amount of bugs were fixed in this release, as no new features would be implemented.

That's still the plan, yes. I'm mostly waiting for the games support to stabilize; the other main areas, office apps and installers, both seem in good enough shape at this point. I'm also hoping we can make some progress on the x11drv factorisation before the freeze, so that we don't need to change the interface too much to add the quartz driver later on, we'll see how that goes. And if we delay it a bit more maybe we can slip in Safedisc support too...

Clearly there will always be "office" apps that don't work, the question for the code freeze is whether we have all the pieces we need; I don't think there's a major feature at this point that would prevent typical office apps from working. Now, whether a specific app works is a different question, but as long as it only requires bug fixes it can be addressed after the freeze, or on the stable branch after 1.0.

In another thread Alexandre has mentioned to wait for game stuff to stabilize before the 1.0 freeze. I think it's time for another brainstorm of what features are still missing which we want in 1.0. The DirectX Todo has a long list but it tends to be useless to me. And I see that it can use some more cleanup ( /me blames Tom-W for not nagging me enough :-) ) It also sounds like AJ takes games as an excuse to delay the freeze for the display driver cleanup, and I was tempted to take the display driver cleanup as an excuse to get more dx stuff in.

So which of the following things do we want for 1.0?

Direct3D:

• Some SM 3.0 features are still missing. Instancing is now in, vertex textures and some other stuff still missing. Not widely used among games yet.
• Multithreading. OpenGL part done (except of 3 patches which I'll NOT send for now (see note below), but needs synchronisation. Will take a lot of time.
• OpenGL ddraw. Render target locking improvements, multithreading.
• Many games do not run yet, problems on Mac OS X drivers and fglrx. For the D3D part I see that as bugfixes which can happen after the freeze as far as I understand things.
• Direct3D10. Will see if someone applies for my SoC proposal.

note: The patches that do the context selection. I won't send them because with my testing patches people started hunting phantom bugs which were the result of missing synchronisation.

DirectSound: Maarten plans to work on that for SoC I think. Freezing now would make that difficult. Would mean to delay the freeze until September / October most at least. I'd personally really appreciate dsound and alsa working better in 1.0.

OpenGL: I don't really know of the windowed opengl state, and the wined3d -> wgl move. Still planned?

DirectPlay: Kai works on the protocol, but I think he doesn't plan to implement it anytime soon. It seems the current idea is to improve our networking libs to get native dplay working.

While nice to have, I don't think d3d10 or some of the more advanced SM 3.0 features should block 1.0. You already know my opinion on broken drivers.

Things that aren't there, but IMO should be:

• Make GLSL default
• Make FBOs default
• Support HDR / float textures

There are various cleanups that should be done as well (eg, getting rid of FVFs completely), but I'm not sure if those should block 1.0 or not.

OpenGL needs to get proper windowed opengl rendering support. The best route to that seems to be by using opengl child windows. There's a patch for it but it needs cleanups and then AJ needs to accept it ...

After that the rest of OpenGL can be cleaned up. For instance the pixelformat limitation can be lifted and because of that various things can be done in a proper way. Second multisampling will be possible as well.

After OpenGL is stable, WineD3D can be moved over to WGL.

I have the 0.9.33 page done, and you may notice that Wine regressed in a couple of the tests. When looking at these scores you will need to take into account the actual visual quality . The scores were somewhat high in past tests because everything wasn't being rendered, while that makes for a nice score the visual wasn't on par with that of Windows.

As of 0.9.33 the visual quality is very close to that of Windows, so in a test like 3DMark2001SE we not only got drastically improved visual quality, we also have a 50% improvement in performance! And 3DMark 03 has a nice showing out of the gate as well.

Why no OpenGL test?

I plan to wait for a resolution to a couple outstanding OpenGL bugs, and then run the tests again. I also plan to dramatically increase the screen resolution in the next update, GL-Excess in the past was run at only 640x480x16; in the future all tests will be run at a resolution of 1024x768x32 or greater.

If all goes well in a couple months there should be another update with OpenGL tests and 3DMark 05/06 results. If 3DMark 2000, 2001SE or 2003 should drastically change i'll also update them as well at that time.

I also updated the CAPS page with 0.9.33 and 1.0.9755.

0.9.33 results:

https://wiki.winehq.org/BenchMark-0.9.33

Past results:

https://wiki.winehq.org/BenchMarks

CAPS results:

https://wiki.winehq.org/DirectX-Caps

Some screen shots of past test results.... You may want to look at them ASAP if you are interested in them, I plan to ask Dimi to rm -rf the page in a couple weeks to save the HD space on the wiki server, this way I can start a new "In Progress" page and not feel guilty about uploading all the shots :D

https://wiki.winehq.org/BenchMark-0.9.6

yesterday a patch of mine was committed to test more profile stuff from kernel32. When I have a look now at test.winehq.org I see that some test(s) crash on win98 but not on others.

Although I could use a if(0) construction (as is done in several other tests), I'm wondering if we should just not run specific tests on specific Windows versions. It's a shame that one OS version blocks the running of several other tests.

I have no idea yet how to achieve this without building in GetVersion style things, as logic and return values don't always make a good distinction.

So if we only have crashes on win9x we don't care. If we can avoid crashes/failures on win9x (by skip or other means) we don't run them on win9x. And if they crash on something higher than win9x we disable them totally.

Sure; the thing we want to avoid is version checks in tests, because then things don't get tested on Wine when the version is changed. But as long as win98 is detected by its missing features then skipping things is fine.

A few days ago I've received an email from Mikolaj Zalewski requesting an account for Coverity !?

I know that in the past some of us dealt with Coverity already. I had a look at the new website and apparently things changed with respect to creating (and approving) new accounts. (Before the new website came alive I think just sending an email got you an account). I must say it's not clear to me how the process currently works but sending an email to [email protected] should do the trick. The approval then has to be done by the main contact(s).

The next step will be that the main contact(s) will have some kind of administration rights to add/change/delete(?) accounts (at least that's how I understood it).

I'm currently in contact with one of the Coverity guys and volunteered to be one of the main contacts. I had a look through the list of current users and all of them look valid to me.

I think it will be good to have one or two more main contacts. So anyone volunteering? There will hardly be any work involved (I hope). Mainly dealing with approving new accounts and communicating things back to the Wine community.