This is the 144th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).
This weeks' issue is brought to you by Frei Brothers Pinot Noir (Reserve, 2000). Is there some kind of irony in using Wine while drinking wine writing the Wine Weekly News?
TransGaming released WineX 2.2.1 with some impressive speedups. From the release notes:
- Support for glibc 2.3, which is now the default glibc version for Debian Unstable
- Improvements in the quality of text rendering in Direct3D mode for WarCraft III and EverQuest
- Direct3D geometry rendering improvements; EverQuest: Shadows of Luclin armour is now visible.
- Performance improvements of 10% in some 3DMark2000 benchmarks
- 200-300% performance improvements in some Quake-3 engine based games such as Jedi Knight 2
- Massive performance improvements for some games such as EverQuest when running on stock RedHat 8.0 kernels
- Support for Quake 3-Engine games based off of Quake 3 1.32
How did it get faster? They noted the following:
On the performance front, WineX 2.2.1 includes three separate new performance improvements. Most of these changes relate to performance measurement API several games were spending significant amounts of time simply calling the APIs used to measure when it was time to advance to the next frame (or sync with audio). These changes resulted in a 10% boost to 3DMark2000 scores, and a doubling or more of performance in some Quake 3 engine based games, such as Jedi Knight 2. Some issues with RedHat 8.0 based kernels were also resolved for some games.
Also included in WineX 2.2.1 are improvements which should reduce the in-memory footprint of games which use large amounts of texture data. While overall memory requirements for textures remains high, swap performance should be somewhat improved. In the future, we hope to lower the overall requirements as well.
For more info and lots of other good stuff, check out November's development status and voting reports.
And in the yet-another-review category we have one of Xandros Desktop over at LinuxPlanet. Skip to page 4 to read the part about Wine. It's hard to tell if the author tried Wine out, but there is a screenshot showing his resume.
As discussed last week, work started on a new Wine FAQ. Dimitrie Paun posted a link to a (almost) completed version:
As promised, the new Wine FAQ (in beautiful color, and an amazing bouquet), is ready for public review before the end of the week. So there. :) At the moment, it is available for your viewing pleasure here:
http://www.dssd.ca/wine/Wine-FAQ.html
Editor's note: the URL was changed later in the week, the URL above reflects the new location.
Keith Matthews, and Thomas Wickline did most of the work on this one; we owe it to them. We've also received a number of useful comments from Jeremy White, thanks Jer!
Please direct all comments, suggestion, and (last, but not least) flames, to the brand new wine-faq@winehq.org. All are most appreciated.
Hopefully we'll have this one on the site not before long.
One of the first questions asked was whether it was available as SGML for conversion to other formats. Dimi replied that currently it was only HTML, though the formatting was quite simple. Discussion then delved into setting up Docbook so HTML, PDF, etc could be later generated from the SGML.
Dimi Paun did a lot of updates on the TO-DO list and announced a new URL for it. At the same time he moved the work on the new Wine FAQ:
Please note that the FAQ, and the TODO got moved to a new location:
Dimi also put together a list of "fun" projects. They range from quite useful to just plain weird. You can find his complete list at: http://www.dssd.ca/wine/Wine-Fun.html. A short summary goes like this:
Carlos Lozano sent out two lists rating some applications from Tucows' Top 100 list and their compatibility with Wine. Dimi Paun reformatted the lists and created a mock-up Supported Applications List. The programs making the "Gold List" (i.e. programs that install and run on an out-of-the-box Wine setup) were:
More work is being done in this area, look for an updated list in the future.
Ender dropped a note mentioning Stuart Caie offered his Cabextract program with a LGPL license for inclusion in Wine. This program extracts files from Microsoft's CAB format:
There you go, now who wants to look into merging cabextract with WINE? [ http://www.kyz.uklinux.net/cabextract.php3]
It'll be useful for at least three things:
- Remove external dependency in urlmon (dlls/urlmon/umon.c)
- Implement advapi32:ExtractFiles and fix dlls/setupapi/queue.c
- Implement cabinet.dll
- Probably some other misc cabinet functions here and there
- CHM viewer (in the future)
I don't think it would be too hard to merge the 0.7 changes into any merging work done with 0.6, so I wouldn't think it necessary to hold out until then. The only major bug he mentions is fixed by simply changing scope of a variable, so.... :)
This is somewhat Wine related.. I didn't dig into the gory details or even try it, but it seems everyone's favorite movie player, mplayer, now supports a QuickTime format using Wine. This post appeared on the Mplayer-dev-eng mailing list:
Thanks to Sascha Sommer, SVQ3 (and probably all the others too, but not added/tested yet) video is now playable with mplayer! Yes it still requires libwine, but we're at least over STEP 1, and can go to STEP 2: hacking loader to work with QT dlls.
But anyway, playing SVQ3+QDM2 MOVs with mplayer in fullscreen using hw yuv accel and direct rendering (yes, it seems the qt dlls support DR2!) and all the mplayer features, filters etc sounds much better than running the original slow qt5 player in wine window :)
The work involved snagging some DLL's from QuickTime 5 and the SDK, using wine-20020310, and other messy stuff. The mplayer folks hope to clean this up soon. Oh, here's a screenshot.
Lionel Ulmer, OpenGL guru, wanted some ideas for separating the 3D code from the X11 driver:
The current OpenGL code (well, to be more precise, the current WGL code) is really X11 dependant and is only separated through hacks via ExtEscape mechanisms to get X11 specific variables.
As I never was able to find documentation about the OpenGL ICD mechanism (ie the way all this is handled in real Windows), I see three possible solutions :
- As almost all WGL functions have an HDC or OpenGL context argument (for those having a context argument, the corresponding HDC can easily be found). Thus one solution would be to use 'DC_GetDCPtr' to get the DC pointer and then move all these functions in the GDI function pointer table.
The problem with that is that 'DC_GetDCPtr' is already flagged as a hack and so I am bit reluctant to use it :-)- Put all HDC function in GDI itself and replace in OpenGL's spec file all of these by forwards to GDI.
- Use the ExtEscape mechanism to not only get specific variables, but something akin to what DDraw does to get the HAL function pointer table and then use these pointers to do the real low level work in the WGL functions.
For the moment, I think 3) is the best. Feel free to propose other solutions :-)
Alexandre replied,
I don't know, I think the current way is not so bad. It's better to
export just a couple of internal things like display and drawable than
a full table of functions that will be a pain to keep compatible
across versions. If you really want to get rid of the escapes then I
think 2) would be cleaner.
Lionel explained the problem he was really trying to solve:
Well, the problem with the current way is that 'display' and 'drawable' are really X11 concepts... This means that the current OpenGL code will ever only work with the X11DRV. While I agree that it's separated, it's not 'clean' (in the sense that we have X11 code elsewhere than in X11DRV itself).
The only problem with 2) is that there is one function that lacks the proper context variable (wglGetProcAddress).
Alexandre didn't really think there was much of a problem,
Note that the escapes will fail gracefully if x11drv is not present,
so it would be perfectly possible to make the opengl dll support other
drivers too. I agree it's not completely clean, and I'm certainly open
to other solutions, as long as we don't introduce some major ugliness
just to get rid of a minor one...
Ian Pilcher wanted some thoughts on implementing some new functions:
Is anyone working on implementing FindFirstChangeNotification and friends? If not, this looks like something that may be both within my capabilities and non-trivial enough to be useful (a rare combination!).
My thought is to use SGI FAM, which is shipped with Red Hat and (according to bug #588) Mandrake. I'm not sure about any other distributions, but the FAQ on the web page states that Enlightenment, GNOME, and KDE all use it, so it should be pretty widespread.
If no one is working on this, start preparing for an endless series of questions about the wineserver's internal workings.
FindFirstChangeNotification and FindNextChangeNotification can be used with Wait functions to have the operating system signal when a change has been made on a file or directory. In particular, FindFirstChangeNotification sets up the conditions to check for.
Marcus Meissner suggested an alternative to using fam:
Check up on directory notifications in Linux. A way cool thing.
- catch SIGIO ...
- fcntl(fd, F_NOTIFY, DN_xxx|DN_yyy);
Ender agreed that might be a good way to go and gave a link to some Samba code that used it. However, the problem remained that it was Linux specific. It was pointed out that under FreeBSD you could use kqueue and kevent. Of course the most portable (and simple) option was just to do some polling. Ian thought maybe that's what he'd do first and then worry about supporting some platform specific methods later.
Andreas Mohr wanted some thoughts about better
supporting Visual Basic applications,
I keep encountering people mentioning that VB stuff has lotsa problems
on Wine.
While I really can't say that I like VB, a lot of people seem to use it
for critical tasks in companies on a daily basis, so it sounds like perfect
VB compatibility would be utterly important.
IMHO improving that should be a goal of 0.8.
Ender felt things were working pretty well and gave some first-hand experience:
A few weeks ago I was writing a VB app for some contract work I was doing - and I wrote, and tested, the application under WINE.
The visual studio VB IDE has a few odd problems with property sheets and the like, but I never experienced a single problem running the application itself under WINE.
-- Sidenote:
I've just quickly played with various VB testcases under Wine.... and not had a single problem with any of them. Even down to writing a simple DirectX game in VB, that worked fine too. I've tested VB3 and VB6 as that's all I've got on hand.
Can you point to any actual examples of failure? From my testing I cannot find anything which specifically points VB as having problems. It's more likely just your every day problem of a program calling unimplemented APIs. Eg, nothing related to the program being written in Visual Basic as opposed to C/Assembly/Delphi/Python/whatever.
Roderick Colenbrander had run into more serious problems and posted a link to some test cases to illustrate:
To demonstrate some important VB problems I made a few VB test apps. Those test apps are located at http://www.xs4all.nl/~sailsup/wine-vb.tar.gz
The package contains some database applications using various MS database implementations (DAO, ADO), two simple tests. Next to this the package contains one of those tests combined with a VB installer application.
To run these apps the VB 6.0 runtime library should be installed and perhaps dcom98. The app that is bundled with an installer contains the vb runtime library and most of the files from dcom98 I think. (get dcom98 from here if you need it: http://www.microsoft.com/com/dcom/dcom98/download.asp)
Now I will tell about problems when running those very basic apps. I'll start with the app with installer. When this app starts the installer, the installer first tries to install parts of the VB 6.0 runtime and some other files. It crashes somewhere during the extraction of the files. (I think it crashes because builtin oleaut32.dll is used and not the to be extracted native oleaut32.dll). When installing dcom98 before running this setup the setup app still doesn't run, but when you tell wine to use native oleaut32 from dcom98 it works fine.
After the app is installed, it doesn't runIt crashes while loading the activex database control which is needed for this app and then launches winedbg. (control is installed by the setup)
After this there are two very simple apps one containing only an empty form and one containing a button on a form that run well. The only minor problem is in the button app. When you click on the button it should show a messagebox containing a text. On windows the text in the messagebox is alligned to the left or perhaps to the center, but on wine the text is alligned to the right. (looks ugly)
Next to these two simple apps there are three database apps (db1, db2 and db3). (one of them called db2 is the one bundled with the setup package) Neither of those apps works well. These apps report various errors "runtime error 335: can't access the system registry" and more of this crap.
I hope these simple apps already help a lot. Most VB problems are very similar to these. If more and better tests are needed, just ask.
Jason Edmeades had worked on getting a VB program to run and
explained his experiences,
I have a VB prog (see
www.badcomp.co.uk
) which I spent a long time getting
working under Wine and fixed all the oleaut32 Var* routines it used. However
if you look at that dll, there are still a huge number of stubs.
Additionally the date/time handling is (was, anyway) pretty useless. I would
strongly recommend if anyone starts writing VB testcases they try and
exercise the Variant cases as well as the standard types (...and no, I dont
have time!)
Marcus Meissner pointed out another potential problem,
most of those VB apps appear to try to load PICTYPE_ICON,
which we do not support yet.
Dimi Paun posted a message about my offer last week to accept screenshots. If you don't know how to make a screenshot stop reading news about Wine development and go find out how to use ksnapshot. Heck, xv has been around for the past million years, use that. Then send me a screenshot doing something interesting. Send it to vinn -at- theshell.com.
Dimi noted the following good points of a screenshot (which saves me from typing the same thing):
A screenshot for Wine should showcase what Wine can do. In theory, it should run apps well, so we should try to show exactly that:
- Do not complicate the screen with other apps.
- We try to show Wine, not that you have a complicated desktop. For example, what am I showing here?
- Include the desktop in the shot.
- This should make it clear that the app is running under Linux, and that it integrates nicely with the desktop of your choice. Is this running under Wine?
- Show a complex scenario for the app.
- This will show that Wine is capable of running complex setups, and makes the screeshot a lot more interesting. A screen with an empty Word window is very borring, and unimpressive: "Wow, Wine can draw a large white background...". Take a look at this.
- Do not make the screenshot too large.
- The images should be 800x600; many people don't have very large resolutions, and it is very annoying to have to scroll to view the image. See?
A more decent try is this. It shows Word, nicely integrated in the KDE desktop (notice how it is listed in the task bar like all the other apps), displaying a reasonable document with tables. It can be improved a bit if the document would show some embedded pictures, a bunch of fonts, complicated embedded formulae, etc. Stuff that shows how much of Word is actually usable under Wine.
Hm. Honestly, I don't know what he meant to show in the first screenshot above. But if she's single let me know.
Francois Gouget gave some additional pointers:
- you say big screenshots are bad which I mostly agree with. If a standard size were to be decided upon I would rather vote for 1024x768 than for 800x600. However that's not my point here. My point is that one should not take a screenshot of 1600x1200 and scale it to 800x600. This makes the fonts unreadable as is shown by your last screenshot (http://www.dssd.ca/wine/wine-ss-ok-small.png). Instead I would recommend to start a VNC server or a second X session with the right resolution and take a screenshot of that.
- the second recommendation would be to make sure it shows nice fonts. So install the fonts from http://sourceforge.net/projects/corefonts/ and make sure you have a FreeType library with hinting (or use CrossOver Office ;-).
- if you take the full desktop, then avoid fancy backgrounds. The best would be to use the distribution's default look and feel to make it more recongnizable.
