September 2012 - Wine-Devel

Re: Wine Mono 0.0.6 Release - Because hey, why not?

by Vincent Povirk

So, it seems I've screwed up this release. Sorry about that. It won't be added to Wine, and I'll try again later. Specifically, I messed up the flags on the mono-registry64 msi component, and I forgot to commit the guids for the new System.Web.Http.SelfHost msi components (which means packages built from the source tarball will have different guids, and weird things could happen to that component when upgrading from them).

Sept. 25, 2012

Re: ImmIsUIMessageA/W

by Henri Verbeet

On 25 September 2012 21:12, André Hentschel <nerv(a)dawncrow.de> wrote: > I don't remember the app, be free to patch it in again, at best with tests. > Wasn't that for World of Tanks?

Sept. 25, 2012

Re: ImmIsUIMessageA/W

by André Hentschel

Am 25.09.2012 14:48, schrieb Aric Stewart: >> >>> also you eliminate the part where if the incoming hWndIME is NULL we send the message to the thread's default IME window. >> >> my changes made an app happy IIRC, further i think i was skeptical about IMM_GetThreadData()->hwndDefault because of the dead code. >> maybe it should be patched in again, not sure. >> >> > > I would be curious about this. What was your app and could I test it? I find there are many applications that are half-ime aware. That use ImmIsUIMessage with a NULL hwnd and expect the message to be processed but the default IME window. So we need that behavior to remain true. > > I would be curious why your app was unhappy about that. I don't remember the app, be free to patch it in again, at best with tests. -- Best Regards, André Hentschel

Sept. 25, 2012

Re: imm32: there is only 1 default Hwnd per thread

by Aric Stewart

On 9/25/12 1:38 PM, Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> @@ -2323,12 +2323,18 @@ BOOL WINAPI ImmSetOpenStatus(HIMC hIMC, BOOL fOpen) >> >> if (data->imeWnd == NULL) >> { >> - /* create the ime window */ >> - data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, >> - data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, 1, 1, 0, >> - 0, data->immKbd->hIME, 0); >> - SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); >> - IMM_GetThreadData()->hwndDefault = data->imeWnd; >> + HWND def = IMM_GetThreadData()->hwndDefault; >> + if (def == NULL) >> + { >> + /* create the ime window */ >> + data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, >> + data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, 1, 1, 0, >> + 0, data->immKbd->hIME, 0); >> + SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); >> + IMM_GetThreadData()->hwndDefault = data->imeWnd; >> + } >> + else >> + data->imeWnd = def; > > So what happens to the window if the first IMC is destroyed? > The window should stick around until the thread data is destroyed. Theoretically the IMC that has this window is the default one for the thread. Which cannot be destroyed until the thread data is destroyed. I see the issue you are worried about and I will work to resolve that. -aric

Sept. 25, 2012

Re: imm32: there is only 1 default Hwnd per thread

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -2323,12 +2323,18 @@ BOOL WINAPI ImmSetOpenStatus(HIMC hIMC, BOOL fOpen) > > if (data->imeWnd == NULL) > { > - /* create the ime window */ > - data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, > - data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, 1, 1, 0, > - 0, data->immKbd->hIME, 0); > - SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); > - IMM_GetThreadData()->hwndDefault = data->imeWnd; > + HWND def = IMM_GetThreadData()->hwndDefault; > + if (def == NULL) > + { > + /* create the ime window */ > + data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, > + data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, 1, 1, 0, > + 0, data->immKbd->hIME, 0); > + SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); > + IMM_GetThreadData()->hwndDefault = data->imeWnd; > + } > + else > + data->imeWnd = def; So what happens to the window if the first IMC is destroyed? -- Alexandre Julliard julliard(a)winehq.org

Sept. 25, 2012

Re: [PATCH] iphlpapi: Set DhcpEnabled to TRUE for all interfaces.

by André Hentschel

Am 25.09.2012 18:40, schrieb Qian Hong: > Hi Juan, > > On Tue, Sep 25, 2012 at 11:53 PM, Juan Lang <juan.lang(a)gmail.com> wrote: >> >> I think this is fine, but you'd want to remove/fix some outdated >> comments I wrote at the same time: > > Thank you very much! > I'll send an improved version tomorrow since I just drank some beer > right now and I think it is not compatible with Wine ;-) That's a known bug http://bugs.winehq.org/show_bug.cgi?id=27162 -- Best Regards, André Hentschel

Sept. 25, 2012

Re: [PATCH] iphlpapi: Set DhcpEnabled to TRUE for all interfaces.

by Qian Hong

Hi Juan, On Tue, Sep 25, 2012 at 11:53 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > > I think this is fine, but you'd want to remove/fix some outdated > comments I wrote at the same time: Thank you very much! I'll send an improved version tomorrow since I just drank some beer right now and I think it is not compatible with Wine ;-) -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

Sept. 25, 2012

Re: [PATCH] iphlpapi: Set DhcpEnabled to TRUE for all interfaces.

by Juan Lang

Hi Qian, > There is a winpcap based network authentication client which check for the DhcpEnabled value, this patch make the app happy and then the app works with André's pcap wrapper [1]. > > Please let me know if this is acceptable, or we have to correctly implement DhcpEnabled status? I think this is fine, but you'd want to remove/fix some outdated comments I wrote at the same time: * NOTES * Since GetAdaptersInfo never returns adapters that have DHCP enabled, * this function does nothing. * * FIXME * Stub, returns ERROR_NOT_SUPPORTED. */ DWORD WINAPI IpReleaseAddress(PIP_ADAPTER_INDEX_MAP AdapterInfo) { TRACE("AdapterInfo %p\n", AdapterInfo); /* not a stub, never going to support this (and I never mark an adapter as DHCP enabled, see GetAdaptersInfo, so this should never get called) */ The same comments are in IpRenewAddress. Historical reason: when I wrote iphlpapi's first implementation, I had recently been working on a Windows app that released and renewed IP addresses on DHCP-enabled interfaces, because Windows at the time was pretty poor at doing so in response to changes to wireless connection state. I figured I wouldn't be the only one to have had to work around this issue, so I didn't want to have to implement IpReleaseAddress and IpRenewAddress in Wine. That was almost 10 years ago now, so these reasons no longer apply. I'm pretty sure the app I wrote isn't in use any longer, and even if it is, it isn't in use on Wine (I also wrote a Linux version.) Thanks, --Juan

Sept. 25, 2012

Re: ImmIsUIMessageA/W

by Aric Stewart

Hi Andre, On 9/24/12 3:00 PM, André Hentschel wrote: > Am 21.09.2012 18:46, schrieb Aric Stewart: >> Hi Andre, >> >> I have a quick question for you. I am looking into why IME unaware applications are no longer showing their composition window and found it was because of: >> >> commit 7673d67c1e1cfdcdf7560beea9162c3699329aa5 >> Author: André Hentschel <nerv(a)dawncrow.de> >> Date: Sat Jun 25 16:13:41 2011 +0200 >> >> imm32: Test and fix ImmIsUIMessageA/W. >> >> in that patch I see that you eliminate the part where we check if there is a default IME window and if not then create one. >> >> if (!IMM_GetThreadData()->hwndDefault) >> ImmGetDefaultIMEWnd(NULL); > > Hi, > this code snippet was a useless construct it seems, because ImmGetDefaultIMEWnd returns IMM_GetThreadData()->hwndDefault which is obviously zero and it's not stored. > You are correct here. It was previously the case that we did not create the default IME window until it was requested. That changed and so now it is useless and can be removed. > >> also you eliminate the part where if the incoming hWndIME is NULL we send the message to the thread's default IME window. > > my changes made an app happy IIRC, further i think i was skeptical about IMM_GetThreadData()->hwndDefault because of the dead code. > maybe it should be patched in again, not sure. > > I would be curious about this. What was your app and could I test it? I find there are many applications that are half-ime aware. That use ImmIsUIMessage with a NULL hwnd and expect the message to be processed but the default IME window. So we need that behavior to remain true. I would be curious why your app was unhappy about that. thanks! -aric

Sept. 25, 2012

Re: vbscript: Added Space() implementation

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=21787 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Sept. 25, 2012