May 2006 - Wine-Devel - list.winehq.org

Release Information on Fedora Extras!
by Neal Gompa May 29, 2006

May 29, 2006

I have noticed that since my post about how Fedora packages are inaccessible, you have added the string "Currently official Fedora packages lag behind, but you can get Wine-0.9.10 by running yum install wine from Fedora Extras<http://fedoraproject.org/extras/4/i386/repodata/repoview/W.group.html>." Well, that is not totally correct. Usually about a week after Wine Project releases a version, Fedora Extras updates to the newest version! Currently, it is at Wine-0.9.13. I believe it will be a week before Fedora Extras releases Wine-0.9.14 packages... I will reply when Wine packages are updated you that an accurate guage is made of the lag... Note: For Wine-0.9.13, and it only took 3 days after Wine official release to release it on Fedora Extras. It is a good idea to assume anywhere from 3-5 days for Wine to be updated in Fedora Extras. The links below are to the webview of Fedora Extras: -=Repositories for i386=- Fedora Extras for Fedora Core 5: http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/repodata/r… Fedora Extras for Fedora Core 4: http://download.fedora.redhat.com/pub/fedora/linux/extras/4/i386/repodata/r… Fedora Extras for Fedora Core 3: http://download.fedora.redhat.com/pub/fedora/linux/extras/3/i386/repodata/r… -=Repositories for x86_64=- Fedora Extras for Fedora Core 5: http://download.fedora.redhat.com/pub/fedora/linux/extras/5/x86_64/repodata… <http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/repodata/r…> Fedora Extras for Fedora Core 4: http://download.fedora.redhat.com/pub/fedora/linux/extras/4/x86_64/repodata… Fedora Extras for Fedora Core 3: http://download.fedora.redhat.com/pub/fedora/linux/extras/3/x86_64/repodata… Note that it is viewing the alphabet group of "W". Scroll down a bit and you will see Wine packages. Please keep download form updated, you make people believe that Wine is not being updated by Fedora Extras, when in fact it is...

2 3

AppBar support
by Paul Chitescu May 29, 2006

May 29, 2006

Hello! I plan to add proper SHAppBarMessage support in wine. I'm using as base some old code I've written to extend Win32s so it shouldn't be very difficult. I have however to choose a window to manage all appbars. It will have to receive WM_COPYDATA messages, much like currently Shell_NotifyIcon does with "Shell_TrayWnd". Obviously it has to reside somewhere in the explorer.exe as it's shared among running programs. The most obvious choice would be to use the desktop window itself as its geometry has to be used anyway. I am however afraid that programs may blindly send a WM_COPYDATA to it, so an option may be to create another, invisible window. What do you think about this? Do you know many applications that use the desktop window as an universal junk receiver? The /dev/null of the GUI world ;-) Regards, Paul Chitescu

1 0

winmm/joystick/joystick.c: Name Clash ("SW_MAX")
by Andrew Talbot May 29, 2006

May 29, 2006

There seems to be a name conflict in this file. "SW_MAX" is defined in linux/input.h as a switch event, with value 0x0f. But our winuser.h has it defined as a ShowWindow() code, with value 11 (decimal). This joystick.c file includes linux/input.h and linux/joystick.h (which, in turn, includes linux/input.h). Does anyone wish to take this up, and should I create a bug report in the meantime? Thanks, -- Andy.

1 1

Bug 5124
by Tom Booker May 29, 2006

May 29, 2006

http://bugs.winehq.org/show_bug.cgi?id=5124 There is a solution in the bug.. Could someone please look and let the person know if that would be something that AJ would commit? If so, could you assist him with deriving a patch from his solution so that he can submit it to wine-patches. I would, but the lights are flickering at my place due to storms and so I need to turn off the comp.

1 0

Myst IV Installer breakage
by Ulrich Dobramysl May 29, 2006

May 29, 2006

Hello! On wine-users I was told I should go here for my problem. So here it is: The game "Myst IV - Revelation" by Cyan Worlds / Ubisoft installed fine in earlier versions of wine (although it was and is not playable). Recently I tried again, and the setup crashed just before the copying of files would start. I was able to isolate the patch that caused the regression (with git bisect). Here is the commit message: >commit 19fad8e71032707cb036239f69f085e1b0249d01 >Author: Robert Shearman <rob(a)codeweavers.com> >Date: Fri May 19 16:03:13 2006 +0100 > > rpcrt4: Don't set the memory pointer to NULL before calling >PointerUnmarshall. > > Call it with fMustAlloc set to TRUE instead to achieve the same >result > without side-effects. The output of wine is here: fixme:ole:ITypeInfo_fnRelease destroy child objects err:ole:get_unmarshaler_from_stream Failed to read common OBJREF header, 0x00000001 fixme:ole:NdrClearOutParameters (0x7c5fd6a0,0x7c174212,0x7c5fd7d4): stub fixme:win:SetWindowTextA setting text "TITLE_CAPTIONBAR" of other process window (nil) should not use SendMessage fixme:win:SetWindowTextA setting text "Myst IV - Revelation - InstallShield Wizard" of other process window (nil) should not use SendMessage fixme:win:SetWindowTextA setting text "TITLE_CAPTIONBAR" of other process window (nil) should not use SendMessage fixme:win:SetWindowTextA setting text "Myst IV - Revelation - InstallShield Wizard" of other process window (nil) should not use SendMessage fixme:x11drv:X11DRV_SetWindowRgn not supported on other thread window 0x3002c err:ole:get_unmarshaler_from_stream Failed to read common OBJREF header, 0x00000001 err:ole:get_unmarshaler_from_stream Failed to read common OBJREF header, 0x00000001 err:ole:marshal_object object doesn't expose interface {be6115a1-7de5-48dc-ad2a-25060e00fce2}, failing with error 0x80004002 err:ole:ClientIdentity_QueryMultipleInterfaces IRemUnknown_RemQueryInterface failed with error 0x80004002 err:ole:xCall RpcChannelBuffer SendReceive failed, 8007000e err:ole:xCall Failed to serialize param, hres 8007000e err:ole:xCall RpcChannelBuffer GetBuffer failed, 8007000e err:ole:xCall Failed to serialize param, hres 8007000e err:ole:xCall RpcChannelBuffer GetBuffer failed, 8007000e err:ole:xCall Failed to serialize param, hres 8007000e ... The last two lines are repeated very often. I would fix it myself but my insight in the wine code is limited. Ulrich Dobramysl

1 0

How do fonts work ?
by Robert Lunnon May 29, 2006

May 29, 2006

Hmm, more on the Google earth saga, I have been looking at the font traces and get things like the following but freetype doesn't support these tags (except GSUB) ??? trace:font:WineEngGetFontData Can't find table 4a535446. This is tag JSTF trace:font:WineEngGetFontData font=7ff405d8, table=534f5047, offset=00000000, buf=0, cbData=0 trace:font:WineEngGetFontData Can't find table 47504f53. Tag GPOS trace:font:WineEngGetFontData font=7ff405d8, table=42555347, offset=00000000, buf=0, cbData=0 trace:font:WineEngGetFontData Can't find table 47535542. Tag GSUB trace:font:WineEngGetFontData font=7ff405d8, table=46454447, offset=00000000, buf=0, cbData=0 trace:font:WineEngGetFontData Can't find table 47444546. Tag GDEF Should freetype be able to find these tables ?

2 1

user32,x11drv: window maximization issues / sending WM_SIZE
by Juris Smotrovs May 29, 2006

May 29, 2006

In an attempt to solve bug 4964, I found several issues where Wine behaves incorrectly (e.g. not sending the messages it should send) or simply differently (e.g. not sending messages where Windows sends them, but perhaps there is no real reason in Wine case to send them) than Windows during window maximization/restoration. I wrote a patch correcting these issues and making succeed 10 of the TODO tests in dlls/user/tests/msg.c related with window maximization/restoration, however it was not accepted, possibly due to its size and dealing with several issues at once. Thus, I ask your opinion on a patch correcting the first issue, the actual reason of bug 4964. Namely, as specified in documentation, the WM_SIZE message should be sent when the window is being resized (i.e. when its width or height is changed) *or* when it changes state between maximized/minimized/restored. However, in dlls/user/defwnd.c, DEFWND_HandleWindowPosChanged(...) Wine looks only for client width and height changes (signaled by flag SWP_NOCLIENTSIZE). There is another flag, 0x8000 signaling exactly the window state change. The patch consists of: 1. Introducing a constant for the flag 0x8000, since it is going to be used in several places. 2. Replacing 0x8000 with the constant in the place where the flag is set. 3. Using the flag in DEFWND_HandleWindowPosChanged to send WM_SIZE also at state change. Now, when the WM_SIZE message is sent at maximization, the testcase WmMaximizeMDIchildInvisibleParentSeq in msg test, written especially for this problem, proceeds further than before patch, however stucks to another issue: though being a test marked with TODO, it produces error messages, because in the message sequence expected default window procedure messages coincide with actual non-defwinproc messages (which are expected later), and for such collision the checking for TODO flag is not written. Therefore, the patch also 4. Adds checking for TODO flag in the case of the defwinproc collision. What is your opinion of the patch? Is there anything wrong with it? Cheers, Juris

1 0

Test results for ddraw patches
by Alexander Nicolaysen Sørnes May 29, 2006

May 29, 2006

Greetings, My testing reveals that a large number of ddraw games crash with the new ddraw patch. These ran fine with the version from 8th April. Games that crash on startup - Heroes of Might and Magic IV - Heroes of Might and Magic III Complete - Stronghold - Warlords Battlecry - Warlords Battlecry II Age of Empires II crashes when starting a game, and I have attached its console output to this message. The version of Wine I used to test with was a fresh CVS checked out a few hours after the patch announcement, then patched with the new ddraw patch. It is available here http://www.thehandofagony.com/alex/wine-wd3dp/ Regards, Alexander N. Sørnes

2 1

Google earth mysteries
by Robert Lunnon May 29, 2006

May 29, 2006

I am having a look at a google earth problem where Google earth says "Google earth has a problem and needs to close, sorry for the inconvenience". Seems to be font related, here is the relay dump just prior to the crash. The exception occurs in Application code. Any guesses would be appreciated... 0009:Call kernel32.98(7fba4e60) ret=7fb67b9d 0009:Call ntdll.NtCurrentTeb() ret=7fe18dc3 0009:Ret ntdll.NtCurrentTeb() retval=7ffe0000 ret=7fe18dc3 0009:Call ntdll.RtlLeaveCriticalSection(7fba4e60) ret=7fe18f01 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7fe18f01 0009:Ret kernel32.98() retval=00000000 ret=7fb67b9d 0009:Ret gdi32.GetDeviceCaps() retval=00000060 ret=7301ef64 0009:Call gdi32.GetDeviceCaps(00000468,00000058) ret=7301ef76 0009:Call kernel32.97(7fba4e60) ret=7fb67a2c 0009:Call ntdll.NtCurrentTeb() ret=7fe18dc3 0009:Ret ntdll.NtCurrentTeb() retval=7ffe0000 ret=7fe18dc3 0009:Call ntdll.RtlEnterCriticalSection(7fba4e60) ret=7fe18d06 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=7fe18d06 0009:Ret kernel32.97() retval=7fea6580 ret=7fb67a2c 0009:Call winex11.drv.GetDeviceCaps(7ff44e40,00000058) ret=7fb40b62 0009:Ret winex11.drv.GetDeviceCaps() retval=00000060 ret=7fb40b62 0009:Call kernel32.98(7fba4e60) ret=7fb67b9d 0009:Call ntdll.NtCurrentTeb() ret=7fe18dc3 0009:Ret ntdll.NtCurrentTeb() retval=7ffe0000 ret=7fe18dc3 0009:Call ntdll.RtlLeaveCriticalSection(7fba4e60) ret=7fe18f01 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7fe18f01 0009:Ret kernel32.98() retval=00000000 ret=7fb67b9d 0009:Ret gdi32.GetDeviceCaps() retval=00000060 ret=7301ef76 0009:Call kernel32.MulDiv(000001e0,0000000b,000001e0) ret=7301ef7d 0009:Ret kernel32.MulDiv() retval=0000000b ret=7301ef7d 0009:Call ntdll.RtlLeaveCriticalSection(73052204) ret=7301f47b 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7301f47b 0009:Call gdi32.GetCharABCWidthsI(00000468,00000000,00000040,00000000,7fd7f29c) ret=7301f288 0009:Call kernel32.97(7fba4e60) ret=7fb67a2c 0009:Call ntdll.NtCurrentTeb() ret=7fe18dc3 0009:Ret ntdll.NtCurrentTeb() retval=7ffe0000 ret=7fe18dc3 0009:Call ntdll.RtlEnterCriticalSection(7fba4e60) ret=7fe18d06 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=7fe18d06 0009:Ret kernel32.97() retval=7fea6580 ret=7fb67a2c 0009:Call kernel32.98(7fba4e60) ret=7fb67b9d 0009:Call ntdll.NtCurrentTeb() ret=7fe18dc3 0009:Ret ntdll.NtCurrentTeb() retval=7ffe0000 ret=7fe18dc3 0009:Call ntdll.RtlLeaveCriticalSection(7fba4e60) ret=7fe18f01 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7fe18f01 0009:Ret kernel32.98() retval=00000000 ret=7fb67b9d 0009:Ret gdi32.GetCharABCWidthsI() retval=00000001 ret=7301f288

1 0

re: [RICHED20] Implement some methods of ITextInterfaces
by Dan Kegel May 29, 2006

May 29, 2006

Say, whatever happened to Maarten Lankhorst from Feb 2, http://www.winehq.org/pipermail/wine-patches/2006-February/023911.html that implemented part of what's needed for windowless RichEdit support? Was it too much of a stub? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1