Wine Traffic #144 For 15�Nov�2002

• 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

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.

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

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.

Please note that the FAQ, and the TODO got moved to a new location:

• http://www.dssd.ca/wine/Wine-0.9-TODO.html
• http://www.dssd.ca/wine/Wine-FAQ.html

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.... :)

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 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 :

1. 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 :-)
2. Put all HDC function in GDI itself and replace in OpenGL's spec file all of these by forwards to GDI.
3. 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 :-)

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).

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.

Check up on directory notifications in Linux. A way cool thing.

• catch SIGIO ...
• fcntl(fd, F_NOTIFY, DN_xxx|DN_yyy);

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.

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.

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.

• 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.