Wine Traffic #177 For 4 Jul 2003

By Brian Vincent

Table Of Contents

Introduction

This is the 177th release of the weekly Wine Weekly News publication. It's main goal is to It also serves inform you of what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 128 posts in 412K.

There were 51 different contributors. 28 posted more than once. 20 posted last week too.

The top posters of the week were:

1. News: Updated DLL Status Page

28 Jun 2003 - 4 Jul 2003 (1 post) Archive Link: "News"

Topics: News

People: News

Happy 4th of July to everyone. I hope everyone in the US is enjoying a day off work. If you're in the UK, I guess you can be thankful you got rid of those obnoxious colonies a few hundred years ago.

Tom Wickline updated the DLL's status page (http://www.winehq.com/?page=status_dlls) on WineHQ. If you've ever wondered what a particular DLL in Wine does check out the new links to NSDN info. Tom has moved on to updating the "Core" status page.

2. DirectShow / Quartz Patches

24 Jun 2003 - 2 Jul 2003 (4 posts) Archive Link: "[DSHOW-01] Add Headers For DirectShow"

Topics: Multimedia

People: Robert ShearmanMicrosoft

Tom Wickline suggested covering some of the recent Quartz developments. (note: I don't get many requests for covering a specific topic, but I'm always willing to. Just email me.) This hasn't really caused any threads on Wine-devel, well, except for ones complaining about CVS breakage. Here's the descriptions of the patches Robert Shearman submitted:

[DSHOW-01]

This marks the start of a series of patches from me adding support for DirectShow to Wine. This patch adds headers (both IDL and .h) required for development to start on the rest of DShow, removes some clashing IID's from uuids.h and fixes some compile warnings caused from the new headers interacting with Lionel's existing work in the quartz directory. Note that these headers are not complete at the moment, but I hope I've added enough to keep me (and other volunteers?) busy for a while. In particular axextend.idl only defines about a third of the stuff it should define.

Now a few apologies:

  1. Sorry for the size of the patch
  2. Sorry for it being compressed (it is over 300Kb uncompressed)
  3. Lionel: Sorry for completely replacing your strmif.h!

Changelog:

[DSHOW-02]

This patch is the implementation of IFilterMapper2 which will form the basis for the IGraphBuilder interface. Naturally, it depends on DSHOW-01, the big header patch.

Changelog:

[DSHOW-03]

This patch implements the DevEnum DLL. It doesn't depend on DSHOW-02, but does depend on DSHOW-01.

Changelog:

[DSHOW-04]

This patch allows Graph Editor to start.

Changelog:

Let me attempt to explain a little bit about all this. DirectShow uses a set of filters that perform specific tasks such as opening and closing a file, decompressing a stream, etc. These filters are strung together forming a filter graph. Part of the DirectX API specifies making calls into an interface that manages the filter graph (not surprisingly this is refered to as the Filter Graph Manager.)

So how does an application actually play a file? First, an instance of the Filter Graph Manager is created. The Filter Graph Manager then builds a filter graph for the file that pieces together all of the components necessary for playback of whatever media type is being referenced (that's a key point of DirectShow - it manages all sorts of file types.) From there the filters start doing their thing, events get generated from the filter that get sent to the Filter Graph Manager. Sometimes these events are handled directly, sometimes the events are placed in a queue for the application to deal with.

That brings us to GraphEdit (http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dx81_c/directx_cpp/htm/usinggraphedit.asp) utility that Robert mentioned. Quite simply, this is a tool Microsoft ships with the DirectX SDK. It's a graphical way to work with filter graphs.

3. Fix For Kazaa Lite

26 Jun 2003 (1 post) Archive Link: "[Patch] dlls/oleaut32/typelib.c - Via a CVS search, reverse regression to get Kazza working"

Topics: Fixes

People: Stefan Jones

I meant to include this last week but forgot. A regression apparently caused KaZaa Lite to not work with Wine-20030618. Stefan Jones tracked down the problem:

On upgrading to Wine 20030618 I found that kazaa lite will no longer work and gave me the following error:

using in wine.config:

I looked though the CVS logs and mail archives and I found the following:

and the patch below (http://www.winehq.com/hypermail/wine-devel/2003/06/0627.html) which was applied to dlls/oleaut32/typelib.c

This caused the crash, reversing it fixes the error.

please fix / apply, or I will cry!!!

4. Clipboard Problems

29 Jun 2003 - 30 Jun 2003 (6 posts) Archive Link: "Copy & Paste doesn't work again"

Topics: Fixes

People: Gerhard GruberRein KlazesUlrich CzekallaRein Klaze

Gerhard Gruber reported a clipboard problem, " The last version (CVS from about two weeks ago I guess) supported Copy & Paste from Agent to Linux apps. This doesn't work anymore. "

Rein Klazes felt this was a deeper issue:

This has not worked here correctly, since 2.5 years ago the clipboard code was rewritten for unicode.

Occasionally it seems to work again. Just restart Agent and then you find that it is not.

Gerhard reported that the issues he ran into were relatively new though. It had worked for him in the past. Rein dug through CVS and discovered the specific cause of the problem. He diagnosed the following

This is the commit:

Patch: http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=8573 (http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=8573)

Causing in Agent several problems:

Ulrich,I have never had much luck fixing things related to the clipboard. Do you have a suggestion how to find out what the problem is?

Ulrich wrote back and mentioned he would take a look at it, " I need to look at this anyway to solve problems with klipper interactions. I probably won't get around to this for a couple of days since I'm really busy with other bugs but it is high on my priority list. If you could send me a trace log of Agent with +relay,+clipboard that would really help me out. "

Ulrich posted a patch that fixed some things, but some things still didn't work for Rein:

With the patch copy & paste from Agent to 'X', as well as as within Agent work fine again.

However if I select some text in an xterm, I get a couple of:

and when trying to paste into Agent:

Do you think another trace would be helpfull?

Ulrich explained, " seems like we couldn't fetch the TARGETS from the selection owner for some reason." Ferenc Wagner took a quick look at the first patch and had some suggestions. Ulrich replied that he would look at integrating the ideas into the clipboard.

5. Wine Keyboard Handling

3 Jul 2003 (3 posts) Archive Link: "Word in Hebrew and Wine"

Topics: Internatonalization

People: Shachar ShemeshDmitry Timoshkovcodeweavers

The long promised BiDi support is finally making it's way into Wine. Since the good ol' ASCII character set suits my needs just fine, I don't really know about the specifics of keyboard handling and fancy character sets. Shachar Shemesh began doing some testing and ran into problems:

I have a pretty good estimate of what needs to be done to get Word supported in Hebrew. The current problems have to do with Word calling "GetKeyboardLang" after each character, and using the result as a basis for interpreting each received character. Currently, this function just returns the system locale, which causes Word to assume each and every letter is a Hebrew one, even the English ones. The results are pretty catastrophic, as people have reported (typing "Hi there everyone" typically results in the screen showing "Hthere everyone i", with "yone" highlighted with green to say it has syntax correction to suggest. The correct is to replace "there" with "they're").

I have been itching to do an overhaul of the Wine keyboard handling for some time. I think the current scheme is overly complicated, and causes problems. This is a major task, but I may be able to recrute some local help. I am a bit worried, however, about the fact that some other people may also working on a similar task at the moment. I know Dmitry said in the past he is rennovating the keyboard a little, and I know codeweavers still hold a patch that will allow UTF-8 input locale to work.

I would like to coordinate the effort. If anyone is working on the keyboard right now, please let me know.

Dmitry Timoshkov, internationalization guru, replied:

Actually Alexandre didn't like that patch, and I reworked it and sent to wine-patches as "Add support for CP_UNIXCP". If you could try it and report whether it allows you to type with UTF-8 locale, it would be nice.

Once this patch is commited, all the base for keyboard layout support should be in place, and implementing kbd layout APIs should be a straightforward enough task.

Regarding the current implementation, I don't think that it's over complicated. We have to cope with different virtual key code layouts and should make an attempt to detect current X keyboard layout in order to assign correct keyboard map, and report correct VK_xxx key events. The CP_UNIXCP patch simplifies a bit current scheme by removing the codepage field from layout tables, which should avoid converting X key events to unicode using wrong code page, and therefore make it possible to make international keyboard input work even if we have made a mistake while detecting an X keyboard layout.

What exactly part of it you see could be simplified, and how?

Shachar described a process for handling keyboard events:

I was aiming for the following path:

  1. Detect current keymap. Try to do that independantly for each keymap group (i.e. - have an array - group0 - US, group1 - IL, group2 - RU). The keys will be stored inside the keyboard map in Unicode. I'm not 100% sure how to do that stage yet, but I do have a relatively non-efficient way of doing that to fall back to, if necessary.
  2. Trap the X events that notify about group changes, and pass them on as Windows messages to applications.
  3. When an X event arrives, convert the raw virtual key to a raw Windows key, and pass it on. Do not convert to ASCII, ANSI, or any other non-layout information. In essence, the keyboard mapping is not used at this stage at all.
  4. When an application asks to convert the raw Windows key to ANSI/Unicode, look up the result in the current keymap.

Saving the conversion to ANSI and back should detach us some way from the current Unix locale. In particular, I want Unicode Windows applications to work, with the same level of non-regard to current locale as they have on Windows.

6. Printing Out the Wine Version

1 Jul 2003 (4 posts) Archive Link: "RE: [RESENT] Always print version on startup"

Topics: Debugging

People: Uwe BonnesFrancois GougetSylvain PetreolleMarcus Meissner

Uwe Bonnes resent a patch that always printed out the version of Wine being used. He explained the rationale, " The recent posting about the Altera quartus installer not working seems to be caused by an old version used. The poster shows the startup and messages. If the version was printed by default, it could help debugging " . He also mentioned that the only person who had objected to it the first time had been Marcus Meissner.

Wine's continual development makes something like this extremely helpful. Most developer's initial reaction to debugging something is to have the user upgrade to the latest release (if not the current CVS.) The last few months have seen patches for all different parts of Wine touching on a lot of usability issues. This time, however, Uwe's submission elicited more reaction. Francois Gouget listed some reasons why shouldn't be added:

This patch will break all scripts that use regedit to export part of the registry to stdout. It will also break all applications that run 'uninstaller --list' and then parse the output to determine what Windows applications are installed. It will also break all Winelib applications that print anything to stdout that then needs to be parsed by a script or some other program. Of course we have each of these cases in CrossOver.

Then it will break all Windows application that analyze the output of another Windows application. For instance I expect Visual C++'s nmake+cl will not work anymore (as well as other make+compiler cases). Even compiling from the Visual C++ IDE may stop working.

Finally it's a matter of what Wine is about. Wine is about transparently running Windows applications. Wine itself should be as invisible as possible, it should just get out of the way. We went out of our way (well iirc Alexandre did most of that work) to avoid having the Wine command line options interfer with the application's command line options. Printing garbage (from the Windows application point of vue) on stdout would be a step backwards.

Sylvain Petreolle felt it could be included another way, " I think this can be avoided. Let use stderr to print this, this way you can use redirections with every program you want. "

Francois didn't think that was a good idea though, " Actually, MESSAGE probably prints to stderr already. But still, some programs will assume that an error occurred if something is printed on stderr. For instance this will happen to any application written in tcl unless the developper went to great lengths to avoid it. So such a change would likely break WineSetupTk."

Thus far Alexandre hasn't committed the change.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.