Wine Traffic #177 For 4 Jul 2003

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:

• Add DShow headers
• Remove IID's defined in uuids.h that should only be in strmif.h
• Add needed const's in FilterGraph implementation

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:

• Implement IFilterMapper2

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

Changelog:

• Implement DevEnum DLL

This patch allows Graph Editor to start.

Changelog:

• Improve QueryInterface FIXME message
• Add stubs for IMediaFilter interface in IGraphBuilder
• Implement some simple methods

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

No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHDOCVW.DLL' (0x71000000)
Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x411ed9c9). In 32-bit mode.
0x411ed9c9 (ITypeInfo_fnGetContainingTypeLib+0x49 [typelib.c:4801] in oleaut32.dll.so): call *0x4(%edx)
4802 TRACE("returning ppTLib=%p", *ppTLib);
Wine-dbg>WineDbg terminated on pid a


using in wine.config:

[AppDefaults\\KazaaLite.kpp\\DllOverrides]
"*" = "builtin, native, so"
;"shdoclc" = "native"
"shdocvw" = "native"
"shlwapi" = "native"
"commctrl" = "native"
;"comdlg32" = "native"


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

http://www.winehq.org/hypermail/wine-devel/2003/06/0414.html

and the patch below which was applied to dlls/oleaut32/typelib.c

This caused the crash, reversing it fixes the error.

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

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.

This is the commit:

Log message:
Ulrich Czekalla

• use global atoms for the format ids
• add timeout when calling XCheckTypedWindowEvent
• fix broken IsClipboardFormatAvailable; it tried to do a trick with EnumClipboardFormats by making incorrect assumptions
• in X11DRV_IsClipboardFormatAvailable do a quick exit if no one owns the selection
• add 1 second *minimum* time lapse between XSelectionOwner calls
• sync clipboard ownership between different wine processes
• prevents apps from getting into wierd state where they thought they didn't own the selection but they did and as a result queried themselves for available selection data

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

Causing in Agent several problems:

• copy&paste from Agent to 'X' doesn't work, occasionally I see some rubbish characters;
• copy&paste from 'X' to Agent doesn't work at all;
• copy&paste within Agent does not always work. For instance I cannot copy Ulrich's email address from the text editor to the To:list at all. Copying within the editor or from the cc:list to the To:list is no problem.

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?

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:

| err:clipboard:X11DRV_CLIPBOARD_UpdateCache Failed to cache clipboard data owned by another process.

and when trying to paste into Agent:

| err:clipboard:X11DRV_CLIPBOARD_RenderFormat Failed to cache clipboard data owned by another process. Format=1

Do you think another trace would be helpfull?

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.

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?

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.

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.