Wine Traffic Brian Vincent

This is the 103rd 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).

I just got back from traveling and put this together. I was in New York City all of last week and returned late Sunday. Little did I realize I would be one of the last people to see the World Trade Center standing. I still cannot comprehend the tragedy that took place and I feel fortunate all of my friends in the city were scattered in other parts of Manhattan that day. My heart goes out to anyone affected by this disaster.

Anyway... there's been some interesting Wine press. First off, we have Codeweavers announcing their CrossOver Plugin. This is a Linux Netscape browser plugin that allows you to run plugins meant for Windows. For example, you can install Microsoft's Word Viewer program to read those pesky office files. Likewise for Excel. This also mean Quicktime and Shockwave files can be viewed out of the browser. This is excellent work and the Codeweavers team should be commended for the code that has been contributed back into Wine. Check out the press release here:
http://www.codeweavers.com/about/press_releases/?id=20010827.xml
and more details here:
http://www.codeweavers.com/products/crossover/the_real_dirt.php#j

We also saw the release of another vintage of Wine. The full changelog can be found in the CVS repository. Noted changes include:

  • Inter-process SendMessage support.
  • More DDE improvements.
  • Preparation work for shared window handles.
  • Several debugger improvements.
  • Better GDI objects management.

The folks over at ZDNet decided to do a head-to-head shootout among Windows-on-Linux solutions. Included were VMWare products, Win4Lin, WinToNet, and Wine. The article has a page dedicated to Wine.

Patrik Stridval

Travis Michielsen posted a message requesting some ideas on implementing the advapi32.dll - the cryptography API that is being used in more and more applications. Currently Microsoft splits this into several small DLL's and Travis was wondering if he should use the same architecture or simply create one monolithic DLL. One large DLL would prevent using the smaller native versions, but it would also be easier to implement using the capabilities of something like the OpenSSL library. Vladimir Vukicevic had also thought about doing the same thing but using libgcrypt from GnuPG. This quickly turned into a licensing issue concerning GPL'ed code. Wine uses the X11 license so it's not possible to ship external GPL'ed libraries with Wine. Patrik Stridvall also noted, However, OpenSSL's license is incompatible with the GPL, hence any GPL'd applications that wish to use an OpenSSL-backed CryptoAPI implementation would be unable to do so. Travis Michielsen went on to explain:

Hmm, I never thought about libgcrypt, but if we can somehow use it legally then it could be a possible back-end as opposed to or inconjunction with OpenSSL. Naturally, I would prefer not to re-invent the wheel by having to re-write every needed algorithm used in the M$ API, if we can find a library that is legal in all circumstances :-!

But has anyone considered the following:

  • Writing code that interfaces with either OpenSSL or libgcrypt depending on what the USER (or any winelib developer) requires AND has installed on their system. Providing this is legal. From what I understand this *should* be legal long as we're not DISTRIBUTING whatever is illegal to do so.
  • Use OpenSSL by default if it is more compatible with our own license.
  • Disabling the cryptoAPI to winelib developers by default to make them aware of these issue and allow them to choose the interface that matches their requirements.
  • Provide adequate documentation that discusses these points and touches the legalities of this software.

One thing we should probably do no matter what is contact the developers for both OpenSSL and libgcrpyt and make them aware of out situation. (and possibly see which one or both is willing to bend on their license(s)).

For now Travis is concentrating on stubbing out the DLL. It will be interesting to see how this unfolds.

Patrik Stridval Guy Alberte

Guy Albertelli was having a problem with specmaker, Recently had a problem with specmaker not generating prototypes. Traced it down to a problem in function_grep.pl. I suspect that the preprocessor elimination did not expect multiline condition. I don't know perl so I can't fix it.It seems that if you have a header file that defined something like this:

    #define SOMETHING \
      METHOD(foo, bar, \
      blee)

it would break specmaker.

Patrik Stridvall posted a small patch and noted, Indeed. Here is a working fix I think (not tested). I found a bug in winapi_check a while ago but the fix didn't find its way the function_grep.pl it seems. The problem might also be that there is whitespace after on of the \:es. This is forbidden by ANSI C but most compilers accept it anyway.

Guy wrote back with a patch of his own and noted, No the above patch merely resulted in an infinite loop. After much consultation with "Perl in a Nutshell", I came up with the following patch. The header file in question is "shlobj.h". The patch has two sections. First gets rid of the \n imbeded with the lookahead for preprocessor statements. The second gets rid of the ICOM_DEFINE statement (poorly I know) because it has no ";". This seems to make things work and generate correct headers.

codeweavers Daniel Sabo Eric Pouech

Daniel Sabo inquired about work that needed to be done. Francois Gouget posted an updated version of his hefty Call for Volunteers:

Note that I did not get much time to update it so please send me your ideas. Also I'm thinking about starting an additional section for 'hard(er)' projects that would significantly improve Wine. Maybe it could also list projects that are already underway and for which help would be appreciated (DCOM?, STRICT handles?).

But first, many thanks go to all those who fixed bugs from the previous call for volunteers and especially to Maciek Kaliszewski for his wrc fixes.

What is the "Call for Volunteers"? I have built a list of projects that should be easy to tackle by new Wine developpers. The main goal is to provide the needed inspiration to potential Wine developpers that just are not motivated by the standard 'grep FIXME' answer (and I can understand them).

So here goes.

Easy:

  • PrgWin95/98: System metrics differ from the Win9x values
    #48: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=48
    One day I'll fix this one... I swear. Unless you want to work on it first. In that case I'll provide you with my test application and dumps of the metrics for Win95, Win98, NT4, 2000, ...
  • The doc about the command line arguments and the config file is out of date. See TextCP, XVideoPort and Synchronous for instance. I'm sure there are plenty of other things that are out of date.
  • Metabug: Test Wine with the VXCL samples
    #242: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=242
    Get the VXCL samples, test them with Wine and report the bugs in the bugzilla database. I know there's lots of them. Then people (or yourself) can start fixing these bugs in a distributed fashion. You can probably start reporting the most obvious bugs just by testing in Wine, but for more subtle bugs you will need two computers (or Win4Lin/VmWare) to more easily compare the behavior in Windows and in Wine.
  • Metabug: Test Wine with the Common Control Spy Samples
    #239: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=239
    Get the Common Control Spy samples and test Wine with them. You will need the native comctl32 dll but you can do the tests without rebooting between each test or using two computers.
  • PrgWin95: Listbox getting a recessed border instead of a flat one
    #56: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=243
    (I can provide you with the sample application) This one my be fixed, to check...
  • I think it would be nice to add a tool that displays the dlls version information like 'About' does in the windows explorer. I have some code you could use as a starting point and I think it could be merged with winver. In fact this would be almost stabdard windows programming.
  • Tabs are missing their inner border
    #243: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=243
    There's a bug in the drawing of the border of the common control tabs. Fixing each of the four instances of the code is easy. It would be interesting to find a way to factorize some of this code.

Medium (I expect these would take longer or be a bit harder)

  • Quickbooks Pro Timer does not accept date (GetCalendarInfoA error)
    #276: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=276
    GetCalendarInfoA/W are not implemented yet. They involve quite a lot of internationalisation aspects, but providing a first implementation that at least handles the common cases should be feasible.
  • Provide a pedump utility #91:
    http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91

    I know there's sample code that does that already floating around so it should be relatively simple. Eric Pouech seems to be working on this. I did not check if his pedump dump the imports/exports but it probably does.
  • CreateIcon does not resize bitmaps
    #175: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=175
    I did a similar fix somewhere some time ago. I can provide a sample application and I might be able to point you in the right direction.
  • winemaker: 'winemaker --nomfc' does not have the intended effect
    #227: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=227
  • winemaker: Ignores the '--with-{mfc,wine}' options once they are cached
    #225: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=225
    If you're familiar with autoconf and know how configure scripts should behave...
  • StrokePath ignores PS_JOIN_xxx
    #11: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=11
    This should not be too difficult to fix but it would certainly help if you are familiar with GDI.
  • Checking the differences between what's in the Windows dlls and what's in our spec files... and fix the contents of our spec files as appropriate. I already have a list of all the APIs in each of the dlls for Win95, Win98, NT4 and Wine2000, plus a script that can show the differences.
  • Enhancing the above perl script. In particular it could be made smarter wrt. detecting whether an API is exported by ordinal or not.

Robert Lowery wondered:

Under Windows 98 (using PowerDVD), I get fantastic performance on my Pention 233MMX as it supports YUV->RGB, Motion Compensation and iDCT in hardware. This chipset is not currently supported under Linux.

What do you think the chances are of PowerDVD working with hardware acceleration under WINE/WINEX?

What sort of performance should I expect?

A couple people replied that as long as the chipset is unsupported by Linux that there's no chance of getting it to work. But Francois Gouget went on to explain, Once XFree86 provides XVideo support for your chipset (or even better, the newer brand of XVideo, the one that also include motion compensation, I don't remember the name), then you may get hardware acceleration in Wine. But I think that currently DDraw does not support hardware acceleration for these things. So it will probably require some work on Wine too.

Ove Kåven

Stefan Leichter was trying to get a game to work and ran into some problems with the handling of keyboard input:

after a long time of debugging (because of my little experience with windows programing and debugging), i found the problem that breaks the keyboard input of my favorite game "You Don't Know Jack" (demos of newer versions downloadable at http://www.take2.de/downloads/demos.php).

The problem is that the game is waiting for keyboard input by checking for the messages WM_KEYDOWN, WM_CHAR and WM_KEYUP at least for the keys 1-0 and a-z. But wine generates the messages WM_SYSKEYDOWN, WM_SYSCHAR? and WM_SYSKEYUP.

The problem is in the file "windows/message.c" in the methode "process_raw_keyboard_message" in the line 383:

    if (msg->message < WM_SYSKEYDOWN) msg->message += WM_SYSKEYDOWN - WM_KEYDOWN;

For some reason i do not understand the message becomes changed. If i remove this line the game recognize the keyboard input and is playable (somehow).

An other option(untested) for the game is to change the line to something like this:

    if (msg->message < WM_KEYDOWN) msg->message += WM_SYSKEYDOWN - WM_KEYDOWN;

Does anyone know why the message becomes changed? Or does anyone know a better fix for the problem? Is there a program the need the line as it is?

Stefan also explained that he was running this in fullscreen mode using the --desktop option. Ove Kåven replied:

If I remember right, a keyboard message must be changed to a syskey message when one of these conditions are true:

  • the ALT key is pressed
  • a menu is being navigated (the system menu in particular)
  • the active/focused window is minimized (an icon)

May be others, but I don't think so. Which do you think applies?

Daniel Sabo thought this particular bit was ok, but that the problem might actually lie with the GetFocus since that's relied on for sending messages to the active window. He posted a description of what the function relied on, The WM_SYSKEYDOWN message is posted to the window with the keyboard focus when the user presses the F10 key or holds down the alt key and then presses another key. It also occurs when now windows has the keyboard focus; in this case, the WM_SYSKEYDOWN message is send to the active window

Gerard Patel didn't think the problem was actually with GetFocus() , but rather that the active window handling was not behaving like Windows. He also added, Another possibility (less probable in this case) could be that the Ms doc about WM_SYS* messages is inaccurate or incomplete.

Alexandre Julliard Uwe Bonnes

Uwe Bonnes had a problem getting an application to run and noticed it was crashing somewhere it hadn't been. He posted some debugging information and noted some strange changes. Gerard Patel explained:

Windows handles are now generated on the server.

This is a historical moment, btw :-) Now Wine has all the architectural features of Win 95

Not everything is implemented, FindWindow does not yet work across processes for example. But it's an important step nonetheless.

Alexandre Julliard has implemented the 'generation' feature of handles. The higher part of a 32 bit handle is used for a counter that is incremented from a window creation to another, avoiding the age-old problem of windows being deleted, then braindead application trying to use their handles, using newly created windows instead.

He also posted more backtraces for crashes he was having. Alexandre replied that patches had been posted that should fix them.

Francois Gouget landed some changes that affected commandline handling. He'd been working on this for a while. Here's what he did:

Some time ago I realized that the command line handling in Wine did not work properly when arguments with spaces or double-quotes are involved. For instance I would start a Wine application like this:

    main "a b" c

and it would tell me something like this:

    GetCommandLine=[./main a b c]

Or I would call CreateProcess(... "main \"a b\" c" ...) and main would get:

    main -> argc=4
    0 [./main]
    1 [a]
    2 [b]
    3 [c]

So I investigated this and found that

  • double-quotes, '"', have the same meaning in win32 as in unix (tested on Win95 & Win2000)
  • backslash, '\', work as on unix, especially wrt double-quotes
  • single-quotes, ''', have no special meaning

So CreateProcess(... "main \"a b\" c" ...) should give me:

    GetCommandLine=[./main "a b" c] main -> argc=3 0 [./main] 1 [a b] 2 [c]

I searched for places where we convert command lines to argv lists and reciprocally and modified them to work as on windows. With this patch things should be correct, whether you call a Wine application from Unix, from another Wine application via CreateProcess, or if you call a Unix application from Wine. There's just one little bit in the msvcrt code which I treated in a separate patch (p20010902-cmdline2.diff).

In the process I wrote a few test applications:

  • hello - regular hello world unix app
  • main - A Wine console application which dumps its argc/argv and then calls GetCommandLine, ... You can also call it with a '-i' parameter to test CommandLineToArgvW, except that _getws is not implemented in Wine so you can only do that on windows
  • winmain - A Wine Gui application which dumps lpCmdLine and then calls __getmainargs, CommandLineToArgvW(GetCommandLineW), ...
  • createp - Which reads a command line from stdin and calls CreateProcess with it
  • spawnv - Reads a list of arguments from stdin and calls spawnv with it (spawn* don't handle ' ' and '"', see p20010902-cmdline3.diff)
  • spawn - Same but the command is fixed

I know that there has been discussions about the command line handling before and that some applications do very weird things. Please test this patch and let me know how it goes.