Wine Traffic Brian Vincent

This is the 139th 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).

News Martin Wilck Francois Gouget News Thomas Wickline

Alexandre announced Wine-20021007 on Monday:

WHAT'S NEW with Wine-20021007: (see ChangeLog for details)

  • Massive listview rewrite.
  • New MS RLE codec.
  • winemaker should be working again.
  • Beginnings of Direct3D 8 support.
  • Lots of bug fixes.

The listview rewrite is ongoing, fifteen more have been committed since Wine-20021007 was tagged. Dimi Paun has sent a flurry of patches over the past few weeks. The fact that he organized them in a logical manner and separated out the changes no doubt helped get them committed. The winemaker work by Francois Gouget and Martin Wilck was aimed at restoring functionality broken by new naming conventions and other changes. The RLE video codec was a last minute addition - the patch appeared Monday courtesy of Michael Günnewig.

The status page on WineHQ had more work done. I took some time and referenced WWN coverage for each of the items. Digging through 130+ issues took some time, so the list is by no means complete, but for most things it should be a good primer. Thomas Wickline updated the "To Do" part of the page. The list is not necessarily 1.0 specific.

TransGaming released WineX 2.2 on Tuesday. This was based off the same codebase as 2.1. Changes include:

  • Many improvements have been made to the sound system in WineX. Several new combinations of hardware and device drivers should now work better than previously.
  • Hardware sound buffering is supported when explicitly activated. It can be configured in the ~/.transgaming/config file, along with support for Full Duplex mode. See the WineX Beginners Guide v. 2.2 for more information.
  • DirectShow support has been significantly improved, both in performance, as well as with support for additional media types. DirectShow performance is best when hardware sound buffering is enabled.
  • Several improvements have been made to DirectInput, including support for Unicode APIs and multi-button mice.
  • A number of fixes have been made to Direct3D 8, including support switching rendering between threads, as well as various Transformation and Lighting fixes.
  • Preliminary support for EverQuest. The Game is now fully playable using the default 'new' EverQuest user interface mode, however the auto-updater may not always work properly. The standard UI mode is not fully functional, and performance improvements will be made in future releases. For more information, see the WineX 2.2 Release Notes.
  • Fixes for Mandrake 9.0 and RedHat 8.0 CD device auto-detection. Note that Mandrake 9.0 appears to have a bug with SuperMount which can cause problems reading files from a CD-ROM in some circumstances. To work around the problem, disable the SuperMount feature in the OS.

TransGaming also posted a development status outlining progress they've made and their future plans. TransGaming's development is partly driven by subscribers who vote each for the work they'd like to see done. The EverQuest work is an example. The top ranked poll items from September requested improvements on Direct3D, sound support, and InstallShield support.

It looks like Frank's World has now moved to Frank's Corner. Along with it there's all kinds of new stuff. Check out:

  • Wine/WineX forum
  • application/game specific installation instructions
  • Wine howto's

Multimedia

Chris Morgan asked Eric Pouech about a new audio driver:

I have an audio driver for the jack audio server, http://jackit.sourceforge.net. This is a callback based server, so each time the server needs audio data it executes a client callback function. I was wondering if there was any interest in having this driver as part of mainline wine code as an example of how to write a wine audio driver for a callback based architecture.

Eric replied:

well, it depends what you look at jack way well be the standardized API for audio application interoperability on Linux but, some folks may argue that arts may well become the same as of today, I don't like the number of sound drivers that we already have (OSS, alsa, arts, nas) just for linux it, of course, reflects the mess in low level audio interface in linux what I really fear is the real maintenance of those drivers as of today, OSS is maintained, I cannot really tell the same for the others it's never a bad idea to share code, but I fear we're not going to be able to maintain all the drivers (but we don't maintain them all today anyway) so go for it (sorry for thinking while writing ;-)

No code appeared on wine-patches nor did Alexandre commit it directly.

Testing Ove Kaaven

Greg Turner has been busy porting and fixing up Ove Kaaven's RPC code. After submitting a few patches Greg decided to tackle creating some tests. He detailed what he did to get the framework in place for the new rpcrt4 DLL and it's probably a good intro for another new DLL:

I'm trying to create a tests directory for rpcrt4. So far I've done the following:

  • Create a dlls/rpcrt4/tests directory
  • Change dlls/rpcrt4/Makefile.in:
      --- Makefile.in.A_PL2 2002-10-04 09:26:11.000000000 -0500
      +++ Makefile.in 2002-10-06 17:59:31.000000000 -0500
      @@ -13,6 +13,8 @@
        rpc_binding.c \
        rpcrt4_main.c
      +SUBDIRS = tests
      +
      @MAKE_DLL_RULES@

      ### Dependencies:
  • add dlls/rpcrt4/tests/Makefile.in:
      TOPSRCDIR = @top_srcdir@
      TOPOBJDIR = ../../..
      SRCDIR = @srcdir@
      VPATH = @srcdir@
      TESTDLL = rpcrt4.dll
      IMPORTS = rpcrt4

      CTESTS = \
        rpc.c
      @MAKE_TEST_RULES@

      ### Dependencies:
  • add dlls/rpcrt4/tests/rpc.c:
      #include "wine/test.h"
      #include <winbase.h>
      #include <winnt.h>
      #include <winerror.h>

      START_TEST( rpc )
      {
        trace ( " **** STARTING TEST %d **** \n", 0 );
        ok (1);
      Exit();
      }

But that wasn't enough and Greg couldn't figure out what he was missing. However, since it was the weekend the list traffic was pretty slow and no one responded. Greg kept at it and discovered the problem a few hours later - a line needed in configure.ac for autoconf:

    diff -u -r1.81 configure.ac
    --- configure.ac 2 Oct 2002 19:58:27 -0000 1.81
    +++ configure.ac 7 Oct 2002 03:09:02 -0000
    @@ -1435,6 +1435,7 @@
    dlls/rasapi32/Makefile
    dlls/richedit/Makefile
    dlls/rpcrt4/Makefile
    +dlls/rpcrt4/tests/Makefile
    dlls/serialui/Makefile

He then submitted a patch for the new framework with some actual tests.

Internationalization

Steve Lustbader posted a patch to implement GetUserDefaultUILanguage and GetSytemDefaultUILanguage but wasn't sure of the details of using them:

I implemented these functions in codepage.c since similar functions (GetDefaultLangID and GetDefaultLCID) were already there. Why are these functions in this file, instead of in dlls/kernel/locale.c?

It seems locales and languages aren't really implemented yet (just hardcoded to English) - is this going in for 1.0 or is it not planned for the immediate future?

As to the first question, Alexandre said the functions were needed by ntdll, so for now they live in codepage.c. Eventually that will be changed. As for the implementation, Alexandre pointed out a lot of it has been done and lives in dlls/kernel/locale.c and ole/ole2nls.c.

Someone else wondered about how locales work, I often see Dutch stuff while using Wine (other than Dutch programs of course), so I don't think everything is hardcoded to english. Shachar Shemesh explained:

You see dutch because the english locales in many of our apps are marked as sublanguage "NEUTRAL" instead of "DEFAULT".

This causes a problem when your locale is not matched by any of the resources. Usually, English is picked as a fallback, but since the english resource is incorrectly defined, English is not matched either. As a second fallback, the first resource language is picked, which happens to be Dutch.

I fixed the problem for Notepad a while back ( http://www.winehq.com/hypermail/wine-patches/2002/08/0078.html). I fixed it only for the English locale there (the rest are not that important to my specific problem), but as far as I understand the matter, "DEFAULT" should be used for all lanugagues unless the sublang is important. If I understand correctly, sublang NEUTRAL should only be used when asking to perform a match, never when defining resources.

As an interesting anacdote, when loading resources with LANG_HEBREW, Visual Studio works great. It won't let you define such resources from the GUI, however. I always thought this was because they didn't want to support that language for some strange reason, until I tried loading resources from WINE that had languages only defined in WINE. Visual Studio kept complaining and wouldn't load the resources, despite the fact that the languages were defined as numbers and no symbols were missing.

Now I am confused regarding the reason that Visual Studio won't let me define Hebrew resources. It appears that it is aware of the language, but will not give it a GUI. A deliberate action? Just one more to life's little misteries.

Integration Filesystems

Alexandre committed a patch that allowed CreateProcess to attempt to run a program even if SHGetFileInfo failed. The theory being it would still allow Unix binaries to run if the executable was able to be found. Sylvain Peteolle wondered if that was really a good idea though and though some programs might maliciously gain access to something that couldn't normally be launched. Specifically, Sylvain wondered what would happen if a program had access to ping. Alexandre didn't think it was a big deal though:

There is no way to prevent a Windows application running under Wine from doing everything a Unix application could do. Even if you don't let CreateProcess launch Unix programs the Windows app can always do a straight system call. If you want to avoid inadvertently running /bin/ping you can make sure /bin is not accessible from a DOS drive. But you can't prevent a malicious app from doing it.

Joerg Mayer summarized that as, This leaves just two options for the paranoid: Don't run untrusted applications - yeah I know that comes as a surprise :-) or run Wine inside UserModeLinux.

Geoff Thorpe thought this was worth having in Wine and suggested another option, Or run it as a different user? Wine doesn't run a virtual machine, so you can't prevent running code (ie. whether it was loaded by wine or not) from doing anything that the user it's running as could do. Therefore, logically, the only rules that wine-loaded win32 code can't break are the same rules that no other program running as the same user can't break. So the way I see it there's no logical argument for putting restrictive rules into WINE that only make something *potentially* useful more difficult (and a lot less elegant) to do. In fact it could be very useful, especially for people wanting to mix "shell"-like tools which are in some cases native to win32 (eg. "cl.exe" or "somewebserver.exe") or native to unix (eg. "gmake" and "/etc/init.d/w32server/index.html", respectively).