World Wine News

All the news that fits, we print.
by Brian Vincent
Issue: 299

XML source
More Issues...

This is the 299th issue of the Wine Weekly News publication. Its main goal is to not fall behind on WWN issues. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at

This week, 721 posts consumed 1289 K. There were 137 different contributors. 93 (67%) posted more than once. 56 (40%) posted last week too.

The top 5 posters of the week were:

  1. 36 posts in 67K by wino at
  2. 33 posts in 33K by julliard at (Alexandre Julliard)
  3. 27 posts in 69K by rob at (Robert Shearman)
  4. 27 posts in 37K by saulius2 at (Saulius Krasuckas)
  5. 26 posts in 57K by oliver_stieber at (Oliver Stieber)

News: Two Releases and Three Reviews Archive

I took a bit of a break since things have been pretty busy, but we're finally back this week. There's a lot that's been going on around Wine and this issue won't do nearly enough justice toward catching up on that.

Let's start off by covering the two CVS drops we've had this month. Keep in mind, these are just drops - I have no idea how it fits in with the whole beta thing other than the naming scheme seems in line with the beta release. First, we had Wine 0.9.1 released on November 9th and Alexandre noted the following changes:

  • Support for Find function in regedit.
  • Winelib app to eject a CD.
  • Many MSI improvements.
  • Better support for running text-mode apps without X.
  • Improved support for various code obfuscation tools.
  • Lots of bug fixes.

Less than two weeks later on November 22nd Wine 0.9.2 appeared:

What's new in this release:

  • Winelib Explorer app (just a wrapper around winefile for now).
  • Debugger cleanups and improvements.
  • Many wininet fixes.
  • Better autogenerated API manpages.
  • A bunch of Korean translations.
  • Lots of bug fixes.

As always, check out the ChangeLog for complete details of what's gone into the releases. Head over to the WineHQ download page to snag the latest release.

In other news, Wine was recently reviewed by and received a 5-star rating. For those of you who don't speak italian, here's a Google translation . They included some technical bits to illustrate using Wine.

Steven J. Vaughan-Nichols reviewed CrossOver Office 5 for eWeek and had a lot of positive comments. Interestingly, Steven included a link to a CrossOver mailing list post which shows he's more familiar with the product than just being a casual reviewer. From his review:

Surprisingly, I found there to be little difference between the applications' performance running on Linux with CrossOver Office and on XP. Indeed, I found some applications, such as Word 2000, to actually run faster on Linux.

Who knew?

Another review , by Jem Matzan, included a nice interview with Jon Parshall. Jon is the COO of CodeWeavers and does a lot of behind the scenes work to promote Wine and CrossOver Office. From that interview:

How likely is it that someday all Windows programs will work perfectly through CrossOver Office?

Jon: I think the answer to your question really hinges on the effort level behind Wine. Right now, the Wine community and CodeWeavers comprise a relatively small group of developers. And while we've managed to achieve a minor technological miracle with that limited resource pool, we could continue advancing that miracle a whole lot quicker if there were more developers and more money behind the effort. With proper backing, I'm convinced that Wine can move itself from being a niche technology--something that works brilliantly in some cases, but poorly in others--and towards a technology that 1) people perceive as being widely and generally useful, and 2) is relatively easily fixable from a development standpoint. Not perfect. But broadly accepted and easier to improve. That's the goal.

Safedisc Update Archive
Status Updates

We've talked about Safedisc for several months now. Things are starting to get sorted out, but there's a few projects that need to get sorted out surrounding it. Ivan Leo Puoti sent a message to the list this week about it:

Raphael Junqueira asked on bugzilla what the safedisc status is. Currently it works fine, and I believe what we have is more or less ready for CVS. However Vitaliy told me Alexandre didn't like the object manager Vitaliy wrote, mostly he didn't like permanent objects, that drivers depend on. I haven't talked to Alexandre about this but hopefully some reasonable solution can be found so we can get Vitaliy's OM into wineserver (I mean my original implementation that uses pointers as handles also works, but things look better with a real OM). So let's try and trigger some community discussion, we are talking about the guts of wine after all. Vitaliy, what's the OM status currently? Alexandre, what didn't you like about it?

Vitaliy Margolen replied:

Following Alexandre's suggestions I've managed to get OM working without support for permanent objects. There will be some modification required for ntoskrnl for that to work. I'm just about finished integrating new OM into ntoskrnl tree and almost ready to give it a try.

As far as OM goes it's mostly finished and passes all but two om tests. Also it don't see any side-effects from it either. All the programs I've tested work in the same way as they were before. All named object moved to directories and using RootDirectory part of OBJECT_ATTRIBUTES for create/open.

Attached is the final revision of the directory object implementation. If it looks ok I'm ready to send some patches <g>

The next day the patches he referred to began appearing. This touches on some very low-level components of Wine, including wineserver. Both Alexandre and Rob Shearman had some ideas for improving the implementation. It looks like Vitaliy will need to make at least one more round of changes before they'll get in.

Based on what Ivan said, the next step will be to have the ntoskrnl.exe implementation be based off the directory objects. From there, ntoskrnl.exe can go into Wine and Safedisc will begin loading it's special copy protection driver.

WineD3D and DirectX 7/8 Archive

Followers of WWN will remember the threads we've covered about the new WineD3D library that was implemented for Direct3D 9. The eventual goal is to shift Direct3D 7 and 8 over to it as well. Currently that process seems to be divvied up between Stefan Dösinger and Oliver Stieber. Stefan is working on D3D7 and Oliver on D3D8. Stefan reported success this week in getting things to render:

Today I have finally managed to get some usable graphics with D3D7 and WineD3D. The Tomb Raider 3 Demo is running. :)

The only visible problem I can see are textures: They only have a solid color, all other things seem to work. I've uploaded a screenshot to , if anyone wants to have a look.

I'll try to fix the textures and get some more games running, then I'll upload a beta patch somewhere for others to try. (Well, if anyone is interested, I can mail the current code too).

He must have kept plugging away at it, because 4 hours later he replied to himself:

I have sorted out that texture problem out now(Incorrect Loading and the TEXTUREHANDLE render state was missing), and to my eyes Tomb Raider 3 runs correct now with WineD3D.

Does anyone know any other games which are running with the old Direct3D 7 implementation? I will give Prince of Persia 3D a try tomorrow, but the last time I tried it crashed before initialising DDraw.

Raphael Junqueira had some ideas about other games to try:

Many users want wine to play Diablo2, Starcraft, Civ3, Sacrifice, ... (I don't know if these games use ProcessVertices or Multithreading)

You can see most wanted games (and how to download demos) here :)

Dustin Navea replied and mentioned Starcraft is actually DX5 based.

Over on the D3D8 side of things, Oliver wrote in a few weeks ago about what he was doing:

I've put together a Direct3D 8 wrapper for wined3d which should hopefully replace the current Direct3D 8 code. The patch needs a little bit of tidying, some work on vertex declarations and a hell of a lot of testing before it can go into Wine.

So far I've tested Rail Road Tycoon 3, Celebrity Death match, Madden NFL 2004 all the d3d8 demos from , a few more games I can't remember at the moment and everything's seems to be working as good as or better than the current Direct3D 8 code.

I would be grateful if anyone with DirectX 8 games or applications that currently work or they would like to get working could test the patch and report back any errors they come across.

The patch is against Wine cvs 2005-11-05 and can be downloaded from for the time being.

Varying degrees of success, mostly centered around varying degrees of crashing, were initially reported. It appears things are beginning to work though. Oliver then followed up this week with:

I've updated the directX 8 wrapper with a load more bug fixes notably Max Payne 2 now works correctly. For anyone who's interested the update patch is available here:

Wine API Docs Archive

Wine has documented the Win32 similarly to how Microsoft has done with MSDN. While it's definitely a work in progress, it does provide an alternative source of information for various API's. Robert Shearman mentioned WineHQ was out of date regarding it:

At the moment we have a very outdated version of the auto-generated "make htmlpages" Wine API documentation at

I want to fix this.

I believe that the API documentation is important for a number of reasons:

  1. It might provide info to ISVs that might think about porting an app to Wine as to whether the APIs that they use are implemented or not.
  2. It provides info about undocumented functions.
  3. It provides an alternative source to MSDN in case it becomes unavailable for whatever reason.
  4. It spreads the word about Wine through high search engine rankings, making it more likely that someone will stumble upon Wine and start coding for fun.

It appears that this was previously generated at release time by the wine_release script ( ), but was disabled over 2 years ago. I was wondering what the reason was, but I guess it is that it takes a long time to build and a lot of CPU time. We don't really want the WineHQ web server to be running at 100% CPU for ~20 minutes while it builds the API documentation.

Therefore I propose that I could send a tarball of the documentation to Newman every release, every month, or after a major update of the documentation (whichever is sooner) and he can put it up in the appropriate location. Alternatively, we could also put the auto-generated docs in cvs and generate diffs.

Alexandre, any comments about how the release process should work with regard to the Wine API documentation? Newman, which method of updating would you prefer? Any one else have any comments at all about this?

Everyone was in agreement it should be done, but there was concern about the load it would generate to make the docs. Alexandre didn't think it was a big deal though and added it back into the Wine release script. Since we had a release a few weeks ago and again this week, the docs are now up to date.

A Destroyed MBR Archive

Don't run Wine as root. We've mentioned that before, right? The corrollary to that rule is don't run Wine as a user who has root-like access. A problem was reported a few weeks ago that sparked a large discussion. It began with this post:

I've just submitted a bug (3889) about destroyed MBR and Dustin Navea asked me to subscribe to this list. Here comes some detailed description:

As a regular user I've launched winecfg as a regular user, then proceeded to the dist setup. I've tried several options like automatic configuration, manual configuration. Then I've tried to change some drive letters manually. After reboot a "PRESS A KEY TO REBOOT" message appeared instead of a GRUB screen. Next time I booted with grub-floppy and then restored the MBR with grub-install /dev/hda. Please let me know what additional information you need. It's happened on Slackware 10.2 system, 2.6.14 kernel with ck-3 patches.

A bunch of people asked for different output to try to figure out the exact cause of the problem. This is what it ended up being.. see if you can spot the issue:

bash-3.00$ ls -l /dev/hda*
brw-rw---- 1 root disk 3, 0 2005-11-20 20:33 /dev/hda
brw-rw---- 1 root disk 3, 1 2005-11-20 20:33 /dev/hda1
brw-rw---- 1 root disk 3, 2 2005-11-20 20:33 /dev/hda2
brw-rw---- 1 root disk 3, 3 2005-11-20 20:33 /dev/hda3
brw-rw---- 1 root disk 3, 4 2005-11-20 20:33 /dev/hda4
brw-rw---- 1 root disk 3, 5 2005-11-20 20:33 /dev/hda5
brw-rw---- 1 root disk 3, 6 2005-11-20 20:33 /dev/hda6

bash-3.00$ groups
users disk lp floppy audio video cdrom scanner

That's right, the user was a member of the disk group and therefore had access to the raw Linux device. That prompted a lot of discussion and at one point Peter Beutner said:

This never would have been possible with a normal user account. But if somebody "creates a special user" by extending his rights and putting him into the disks group, he should be aware of the implications. I don't think there is a "documentation bug".

Of course that is not an excuse why Wine wants to write to the MBR ;)

Then it was discovered that simply making some winecfg changes with a user who had those kinds of permissions would do the damage. Alexandre took a stab at what the problem was, Yes, changing the label is the most likely culprit. It's supposed to check for a FAT filesystem first, but maybe the detection is broken.

Various folks asked for more info to help debug the problem, but nothing more was provided. Instead, Alexandre committed two changes to CVS that will hopefully prevent Wine (though not an app) from doing bad things even when the permissions are set that way:

(dlls/kernel/volume.c) Don't try to set the label in the superblock of FAT filesystems, that doesn't do the right thing anyway.

And in winecfg:

Only set label and serial number when they are actually changed.

What Would Most Aid Wine Development? Archive

Susheel Daswani started off a thread that generated a lot of response:

My name is Susheel Daswani. I am a second-year law student at Berkeley School of Law. I am also a software engineer - I used to develop the LimeWire open source Gnutella p2p application. Nice to meet everyone.

For my 'Antitrust & IP' course this semester I am writing a brief about why I think the remedy in the Microsoft antitrust case was inadequate. My main recommendation is that the 'applications barrier to entry' phenomenon (users like OSes with lot of applications, developers like OSes that users like) need not aid Windows' dominance. This is of course familiar thinking to the WINE community - if a *nix (or any other OS) could effortlessly run every Windows application, then we wouldn't have a monopolist over in Redmond, or at least we'd have some fervent competition in the personal desktop OS space.

So my question for the WINE developers is "What materials from Microsoft would most aid the development of WINE"? The Windows API is of course public, so my guess is that isn't a huge bar to creating WINE. So what are the bars? Is it simply the scope of the project? Is there information that MS could divulge that would greatly aid the WINE effort? Would open sourcing part of Windows help?

I plan to use your answers for no other purpose than educating my professor on what, alas, *could* have been done to help restore competition to the personal desktop OS market.

Juan Lang replied first:

Unfortunately, you guess incorrectly. While the API may legally be public (the interface can't be protected, as far as we know,) it isn't always documented. MS uses undocumented APIs very, very frequently in its own products, and I don't just mean in its applications: parts of its API depend on other, hidden parts of its API. Even the parts that are documented are not documented completely. For example, many APIs take 32-bit flags parameters, some of whose meanings are documented. But the behavior for all possible values is not well-specified, nor are the return values. I continue this thread next:

> Is it simply the scope of the project?

This is a large part of the problem. It's difficult to appreciate just how large it is. (There was a presentation about this once, maybe by David Korn, but I've lost track of it.) We can only learn the behavior through experimentation, and so do application developers. The application developers depend on undocumented behaviors, so we have to replicate them, including bugs. The problem is, there are many more of application developers (and Windows developers) than there are of us.

Also part of the problem, though I don't think it comes close to scale as far as its impact, is that our architectures are different. For example, the code obfuscation tools (securom, safedisk et al) depend on device drivers being loaded by ntoskrnl.exe. This is related to the hidden assumptions problem I described already, but sometimes we have to implement a large amount of silliness that we didn't anticipate having to do, or reimplement stuff that was already working for some apps. ReactOS can potentially avoid some of these issues, since they're copying much more of Windows's architecture.

Dmitry Timoshkov described the bundling problem Microsoft is known for and gave a specific example:

One of the problems is that microsoft uses a vague term "Operating System component" for almost everything one might expect to get free access to. This includes Internet Explorer and its components including upgrades, Windows Media Player and its components, MDAC, and many other things like MFC which don't exist in older Windows versions, and which are allowed to download only for "genuine windows" users. It effectively removes a visible border between an application, a redistributable component, and the OS itself. Microsoft simply wants to tell the users that everything it develops is Windows OS, and therefore is illegal to use on any other platform. It's nonsense to require an OS license to install an application.

For instance Office 2003 does not install MFC dlls while its components don't work without MFC. Since Wine doesn't have MFC, and clearly MFC is not an OS component, and developing MFC is out of the Wine scope, that's a problem.

Jeremy White agreed with both points:

That is, the documentation of the API has gotten substantially better. However, there is no way for anyone in the 'public' to request a clarification or visibility into this process. The process is overseen by a committee and they are not responsible to anyone but the judge. So, the documentation gets better, but it happens overnight, invisibly. We have no way of knowing that the documenation was improved, and no way of knowing where further improvements are coming next, and no way to ask for specific clarifications.

I think Dmitry was quite right in his point as well. Given that the original lawsuit was over the illegal use of Internet Explorer, I find it quite bitter indeed that Microsoft is still able to claim IE as part of the operating system. That is, there are a wide range of applications that will not function without Internet Explorer. Their failure is not because of a simple API that can be replaced with Firefox, but because of deep interwoven dependencies.

So, to summarize, the punishment to Microsoft for illegally pushing IE and destroying Netscape is...the continued use of IE as a monopolistic lever. Nice.

From there the thread went in different directions.

Running Non-Graphical Programs Archive

Charles A wanted to know how to go about using Wine on a machine without X running, specifically running a cron job:

I'm not able to use wine command in crontab due to it giving the following error "Error opening terminal: unknown"

I'm using wine 0.9, i have added the following command in crontab

    20 10 * * * /home/Maven/

In the "" file has the following wine comments

    ssdir=/mnt/VSS-DB < VSS DB mounted folder --> path=$path;......

    export ssdir
    export path

    wine "z:/mnt/winsys/Program Files/Microsoft Visual Studio/Common/VSS/win32/ss.exe" Workfold $/xyz/Development/src "z:/mnt/workfold/" -Yarunm,maven
    wine "z:/mnt/winsys/Program Files/Microsoft Visual Studio/Common/VSS/win32/ss.exe" get $/xyz/Development/src -yarunm,maven -R -f

Vitaliy Margolen replied that it should just work out of the box with a new version of Wine:

What you need is to upgrade to 0.9.1. It should work, as aforementioned ttydriver is no more and replaced with nulldriver.

Paul Millar gave a longer solution that would also work for apps requiring a graphical display but not actually using it:

OK, so what I suspect is happening is crontab has no DISPLAY variable set, so wine is defaulting to using the ttydriver. Unfortunately, crontab environment isn't attached to any tty, so that fails too with the error message you see.

What you really want is the nulldriver (which I think Alexandre mentioned once a while back) but that doesn't exist yet. [ed. note: it does exist ] I'm not sure how to start up a pseudo-tty for your crontab entry. It should be possible but I'm not sure if there's standard tools to achieve it.

What I do for WRT is start up a VNC for the duration, then shut it down again. See script snippets below for some ideas. This should work for you, but its something of a hammer to crack a nut.

I used to use Xvfb (from XFree86) as the (virtual) frame-buffer device and have some scripts to support that. Unfortunately, that had a nasty habit of crashing whenever one tried any openGL/glx stuff and the XF86 people weren't interested in fixing the bugs.

Do something like:


    . /usr/local/share/wine/wine-functions # or wherever

    eval $(startVNC)
    wine some-prog.exe
    eval $(stopVNC)


    function startVNC()

     $VNCDIR/vncserver :$disp -geometry ${res} -depth $depth
     echo "export DISPLAY=:${disp};"
     echo "echo vncserver up and running..."

    function stopVNC()

     $VNCDIR/vncserver -kill :$disp

     echo "unset DISPLAY;"
     echo "echo vncserver stopped."

Unfortunately, I had to patch vncserver script to stop it from writing to ~/.vnc. Here's the patch:

    --- /usr/bin/vncserver Fri Feb 27 09:19:42 2004
    +++ VNC/vncserver Sun Sep 25 21:18:34 2005
    @@ -18,6 +18,8 @@  # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
     # USA.
    +# APM - 2005-05-13: work solely out of WRT directory. Unfortunately, this
    +# requires patching this executable
     # vncserver - wrapper script to start an X VNC server.
    @@ -37,7 +39,7 @@
     $depth = 24;
     $desktopName = "X";
     $vncClasses = "/usr/share/vnc/classes";
    -$vncUserDir = "$ENV{HOME}/.vnc";
    +$vncUserDir = "$ENV{VNCDIR}" || "$ENV{HOME}/.vnc";
     $fontPath = "unix/:7100";
so, running this patched version of vncserver with VNCDIR set somewhere writable by cron's userid should work.

Winemailer/Winebrowser Extension Archive

Hans Leidekker came up with a little Winelib app in the spirit of winebrowser to handle sending email:

Modeled after winebrowser. Local testing found that thunderbird (know as mozilla-thunderbird on Debian-based systems) and evolution accept a mailto: url on the command line. kmail however has its own interface. Any other GUI-based mail client of interest that handles these urls? Test it like so:

    $ mua 'mailto:wine-devel at'

This should bring up a new mail window with To: and Subject: fields and text body set accordingly.

Alexandre didn't think it was necessary to have a separate app just for that, I think this could just as well go into winebrowser, it's really a very similar functionality.

Hans redid the patch to move the functionality into winebrowser and it was committed to CVS.

Desktop Summit Archive
Project Management

In about a week in a half there's going to be a conference hosted by OSDL about desktop integration on Linux. An invite was sent to wine-devel:

On December 1-2, OSDL is hosting a meeting for the desktop architects from the various Linux desktop organizations to help decide on ways to improve and promote Linux on the Desktop. An electronic copy of the invitation can be found at the following URL. This contains a full agenda, preparation info, and logistical info.

If anyone from wine is interested in participating, they are encouraging everyone to register for the meetings. They will be limiting attendance to 45, so they may only be able to accept 2 or 3 from every desktop organization, but they need your name on the list. A finalized list of attendees will be sent out afterwards. To register go to the following web site:

After some discussion, Jeremy White wrote back to the list that he was planning on attending. He asked for input from the Wine community about things we need help with from other projects. He posted a prelimary outline of things he plans on covering:

Wine Project Overview
Purpose: Implement Windows API for Unix

    Wine loader - run Windows Applications
    Winelib - port Windows applications
Deliverables (the dream)
    All PE format files (.exe + .dll) 'just work' with binary loader.
    C/C++ code recompiles and 'just works' with Winelib
    ReactOS project

Wine Project History

    Founded 1993
    Single Maintainer
    797 Contributors over Lifetime, ~40 active
    Alpha Software, limited functionality, through 2005
    First Beta (0.9) released October 2005
    Many things work
    Server interface stable
    Some ABI stability

Associations With Other Desktop Organizations

    Wine is a power user of the kernel, glibc, and
    Have very specific needs around memory, threading, and display control
    We break X more than any other app I know
    We get no respect
    exec shield, glibc threading changes, feels like a constant arms race; be nice if we could be more involved, given time to respond
    Also touch: OpenGL, ALSA/Jack/ESD/Arts/OSS
    Hurray for
    Menu Specifications
    Xembed Protocol

Gap Analysis In Current Implementations

    Missing capabilities
    Many things don't work == a whole lotta bugs
    Developing capabilities
    Most core pieces are there, most things 'should' work
    DirectX coming along nicely
    Sound still needs work
    Many things at 90%+, but still need work
    Top priority development items in plan
    "We have not yet begun to optimize"
    Regression testing
    Driving to 1.0

Major Plans

    6 month plan
    Refine beta releases of 0.9, drive towards 1.0
    2 year plan
    World Domination?

There was a lot of response with specific details on things Jeremy had outlined. Dimi Paun added:

I guess we need to spell out what we need from other projects to better integrate Win32 apps with the rest of Linux. These things take time, and we need to bring them on their radar.

Also, if OSDL is willing to put some of their uber-kernel hackers on Desktop Linux, would be nice if we could come up with a spec on what needs to be done on the kernel side to speed up Wine. I know, this has been hashed out to death before, but I guess it would be interesting to probe and find out their willingness to help us out on the kernel side of things.

Dmitry Timoshkov wanted a deficiency in X fixed:

How about inability of X server to handle pixmaps larger than 32767 x 32767 and an ugly workaround introduced by the following patch:

This has been discussed under the "Re: Regression: Winrar fails to start" topic.

Lionel Ulmer then wrote a long email with other items that fell into the realm of X:

OK, here is my wish list from the guys:

  • relative mouse movement reporting. This is a must-have to have proper DInput support without the hacks we currently have in the code. Extension already discussed with X people on the mailing lists and they seem OK with it. Now we just need to find someone who codes it :-)

    As said, need to check if the XInput stuff could be re-used (last time I checked no as you cannot take control with XInput of the 'core' device - i.e. the mouse).
  • full support for resolution / depth switching. A nice idea was discussed the other day on the fd.o lists: what about being able to easily start a new display using an X API which would start a new X screen. This screen could then be used for full-screen games and would support any requested depth / resolution change (the problem with the former - depth change - is that clients need to support it and so the 'new screen' idea would solve this problem as one could still have legacy X applications running on the 'main screen' while still have complete control of depth / resolution on this secondary screen).

Then some 'nice to have' which would help in the GL / D3D front but may be out of FD.O scope (and for which work-arounds are known):

  • GL (GLX ?) extension which would remove the 'thread-affinity' from GL. I.e. a GL context would be at the process level and not at an application level. An even better solution would to be able to create 'shareable' contexts which another thread could attach to (i.e. remove the one thread <=> one context rule).
  • GLX extension that would export the 'clip-list' functionnalities of cards (or at least the one which is in the X code itself). Would help on applications (like Wine) that do their own in-window clipping.
  • same point as before but for Xv the day we will re-add this code for accelerated YUV display.

Some 'misc' stuff that is really in the 'we could use it' category:

  • have 'connection-level' configuration. Basically, if a client X change an X setting (resolution, mouse acceleration, ...), as soon as this client exits, restore the previous configuration. Would be useful to prevent having people restarting X because Wine crashed after having changed the resolution using XRandR.
  • have a non-connection limited mouse-grab. To explain better, this would enable one to grab the pointer into a window (i.e. the mouse would never leave this window) while still sending events to all connections and not only to the connection which started the grab. This could be nice to simulate 'full-screen desktop mode' or for DXGrab. No idea if with Wine's current event model this is still useful though.

Another 'let's dream' possibilities:

  • direct frame buffer access :-)

And finally, not in my domain, but investigate re-using something from FD.O for the fabled DIB engine (extensions to Cairo, ...) ?

Starting Without WinMain Archive

James Liggett went through an interesting little exercise last week. It goes to show if there's multiple ways of doing something that a sufficiently large enough programmer population will eventually try to find all of them:

First, apologies for the length. It's quite a complex issue:

A few days ago someone sent to the list asking why a program he'd written on WinXP runs under WineDbg but not under plain wine. Over the weekend I debugged the program and found out that his program doesn't use the standard WinMain entrypoint function. As such, he was using GetStartupInfo to get startup flags. He uses the wShowWindow flag to control the showing of the program's main window. Trouble is, this value is zero unless the program is started as a child process using CreateProcess, given a STARTUPINFO with wShowWindow set to something other than 0 (usually SW_SHOWNORMAL or SW_SHOW.) So my question is, how does the information in STARTUPINFO get set initially? I looked through the code for winecrt0 and found that before WinMain is called, the wShowWindow flag is set to SW_SHOWNORMAL. But because this program does not use WinMain, this value doesn't get set. However, the program works fine on native Windows XP. I looked at ntdll and kernel32 dll code, but I'm not sure I'm looking in the right place. Can someone give me some hints as to how to attack this problem?

Eric Pouech had a quick tip, You likely have to fix dlls/ntdll/thread.c (in thread_init) so that the RTL_USER_PROCESS_PARAMETERS has the correct flag set (or alternatively, in dlls/kernel/process.c, in for example build_initial_environment). Note that winecrt0 is only used for winelib apps, so it's not used in case of windows native program.

James replied, I tried modifying the RTL_USER_PROCESS_PARAMETERS settings after creation in dlls/ntdll/thread.c (in thread_init, right after the structure is allocated,) but that didn't work. So I put the change in dlls/kernel/process.c, at the end of build_initial_environment, and that worked. But it seems a little out of place there. Do you think such a change stands a chance of getting into CVS?

Eric must have thought about it a bit because he followed up a few days later with a one-liner that fixed the problem.

VB Apps & OLEAUT32 Archive

Dan Kegel has been putting a lot of time into coaxing apps to run. This week he took on Visual Basic apps and wanted to know where the monsters lurked:

What would it take to really support MS database client apps in Wine? The situation is not copacetic; everywhere you turn, it's easy to find enough problems to stop the average VB database app.

I tried installing a real world small government app. It used VBSQL.OCX, and required a file from the SQL 7.0 Client redistributables. Here's the script I used to install it (yikes): I lost touch with the guy who needed this app, presumably he gave up because it was so hard to install under Wine. Here are all the bugs related to mdac installation:

Another VB database app installed (after some effort), but failed with an "automation error".

Other VB apps use "dbgrid32", and a small sample app that uses that currently fails. See

Perhaps it's time to create an open source torture test in VB 6 that exhibits as many of these problems as possible, and use that as a regression test in Wine.

Anyone willing/able to take that on? Roderick Colenbrander wrote the DBGRID32.OCX test; perhaps he'd be willing to write an expanded set of tests?

Michael Stefaniuc, who worked on Wine's OLEAUT32.DLL over the summer explained what some of the likely problems were:

I do not know what special needs the VB database apps have but for sure they need a good oleaut32.dll. At least the variant arithmetic functions aren't good enough for your requirements. With good enough what I mean is that they do not handle all the input variants that native oleaut32 are handling. That isn't hard to implement but requires a lot of tests as these functions are very poorly documented and are designed specifically to support only the variants they get passed down by the VB runtime. Good examples of such tests and implementation are VarMul, VarAdd and 1-2 other functions (from which I adapted the tests for VarMul and VarAdd). A sign for a not "fully" implemented variant arithmetic function is a fixme which says something like "VarXxx partial implementation, doesn't support vt ..." (if you get this it is the source of the automation error you more than probably got too) or if the function returns E_FAIL. From my experience so far with variant arithmetic functions those return in the native oleaut32 DISP_E_BADVARTYPE or DISP_E_TYPEMISMATCH.

Automation errors are of different kinds: easy to fix and hard to fix. #2480 would be an easier one to fix: The problem is in the VarCmp (variant arithmetic) function and the function would need to be changed to accept that combination of variant types the fixme is complaining about. No need to do it here as I resumed my work on VarCmp to make it accept the same input variants as native function in WinXP does. #1713 is a hard to fix bug as the OLE object functionality isn't implemented yet for richedit. Nor will it be according to the last comment in the bug report.

With regard to Dan's idea about a VB torture test, Michael didn't think it was needed to uncover problems with oleaut32. Wine's own test suite worked just fine for that.

All Kernel Cousin issues and summaries are copyright their original authors, and distributed under the terms of the
GNU General Public License, version 2.0.