World Wine News

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

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://bugs.winehq.org/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://bugs.winehq.org/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://bugs.winehq.org/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://bugs.winehq.org/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://bugs.winehq.org/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://bugs.winehq.org/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://bugs.winehq.org/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://bugs.winehq.org/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://bugs.winehq.org/show_bug.cgi?id=227
• winemaker: Ignores the '--with-{mfc,wine}' options once they are cached
  #225: http://bugs.winehq.org/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://bugs.winehq.org/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.

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?

after a long time of debugging (because of my little experience with windows programming 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?

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?

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.

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.