December 2013 - Wine-devel - list.winehq.org

Launchpad project for Wine
by Tae Wong 18 Dec '13

18 Dec '13

There's a Launchpad project for Wine: https://launchpad.net/wine But there's a misspelling: ...a compatability layer... It says compatability instead of compatibility. The account https://launchpad.net/~seotaewong40 has been disabled. How to enable this account to file bugs? When trying to visit the page, it says: Page gone. There’s no page with this address in Launchpad. If this is blocking your work, let us know by asking a question at Launchpad Support . Otherwise, complain to the maintainers of the page that linked here.

2 1

Travel sponsorship for Wine to FOSDEM
by Jeremy White 17 Dec '13

17 Dec '13

Folks, I neglected to put this out there, but the Wine party fund is able to provide travel sponsorships for Wine contributors (where contributors is not limited to programmers, and can be fairly loosely defined). If you are interested in such a sponsorship, please write me privately. We could still use some novel presentations in our dev room; so if you want to get sponsored to come talk about Wine users or pitch the use of Wine on the lunar lander, I'd be delighted by the combination. Cheers, Jeremy

1 0

Re: [PATCH] msxml3: Store document url in properties so every instance could see it
by Marvin 17 Dec '13

17 Dec '13

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3762 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: taskschd: Add new dll.
by Nikolay Sivov 17 Dec '13

17 Dec '13

On 12/17/2013 13:30, Dmitry Timoshkov wrote: > +WINE_CONFIG_DLL(taskschd,,[implib]) Does it really need implib?

1 0

Re: winemenubuilder: Return error for missing link in InvokeShellLinkerForURL function
by Dmitry Timoshkov 16 Dec '13

16 Dec '13

Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > --- a/programs/winemenubuilder/winemenubuilder.c > +++ b/programs/winemenubuilder/winemenubuilder.c > @@ -3030,7 +3030,7 @@ static BOOL InvokeShellLinkerForURL( IUniformResourceLocatorW *url, LPCWSTR link > if ( !link ) > { > WINE_ERR("Link name is null\n"); > - return TRUE; > + return FALSE; > } This doesn't follow the behaviour of other failure cases in this helper. -- Dmitry.

2 1

Re: [PATCH] ddraw: add dsurface dimension tests, try 5
by Stefan Dösinger 15 Dec '13

15 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-12-14 12:34, schrieb Patrick Rudolph: > + /* Test maximum surface width */ + memset(&desc, 0, > sizeof(desc)); + desc.dwSize = sizeof(desc); + desc.dwFlags = > DDSD_CAPS | DDSD_HEIGHT | DDSD_WIDTH; + desc.ddsCaps.dwCaps |= > DDSCAPS_OFFSCREENPLAIN; + desc.dwHeight = 1; + desc.dwWidth = > 0xffff; + ret = IDirectDraw_CreateSurface(lpDD, &desc, > &dsurface, NULL); + if(!(ddcaps.ddsCaps.dwCaps & > DDSCAPS_VIDEOMEMORY)) + { + ok(ret == > DDERR_INVALIDPARAMS, "Creating an offscreen plain surface with > width 0xffff and height 1 returned %08x\n", ret); + } + else > + { + todo_wine ok(ret == DD_OK, "Creating an offscreen > plain surface with width 0xffff and height 1 returned %08x\n", > ret); + } I found the reason for this behavior. Some drivers seem to have a pitch limit of slightly under 128kb, specifically 131008 bytes. If you use a P8 pixel format here, the test passes on at least my Nvidia machine with this behavior. The same machine still has the 0xffff width limitation. So a 0x10000 width P8 surface isn't allowed, even though the pitch stays below the limit. I guess you could test for the pitch limit by setting DDSD_PITCH, either in CreateSurface, if it works, or pass it to SetSurfaceDesc. I don't think we have to test this unless we know an application that depends on this limitation - which I guess is unlikely because not all Windows drivers have it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSrZ1sAAoJEN0/YqbEcdMw6S0P/iZxvm5yH7hVoRJySKTtlDdD JB5JgGnG64ghBFX3SNRY38WP5iJT/Sgq2J8ueN2m/J5r83Ms7gtVz/2e0dm8ENgs MI2ln+0rXeC9vIAXNaM3VRTLKoOKql3sYSXEGvQNPtS56kvENz/2Mgfk00d6MfTJ 7tVtrgqfewR4KUjRzPnVDZO1Ofu4SiILFIYV75qAPO0ZQbEpqJGhxxJqoBYhpcpR GM9bD+4zajM9NJhZR4w3G8p23JVpUySso3xEXiV9RL16SvODnedf5o69wEB6ihyl zbSoyvntqDDiFkUSbrjPdu89TNVJ9vYRQsxEm/56P6DtN9SqHkQpQVBAFC370Tbd fAHQQWVnG0yr7/YAhRcB5+8hoyeX7H8p5Vk8nbcYNNQouKFVLMmRICGoaRLHPnqC 7cnrXw6/fL583FgsnevuX/n+ENsqwa7OkkVzlNLm746SPTnF1I+14ERHe8ADh25l 3ushOkUCJvQISDmRAzV0T4m8if6ljMPIIfMCPR0xNDTAFt5tBcYaHexw0GOh9UCD jGp9d6NYRuEf49jH3oYwVcdleGY8e1HrhT/N/s8pbMIWctgu/1s3RAERy5DEd8Hl otUR9I4DbCD4qWcaF3tW1K3syL8E3UTYjzlQ1GBlc018MsaIfebH7ds44oE1tVgk m0KcynUFCzigbONka3IB =XDx8 -----END PGP SIGNATURE-----

1 0

Re: add japanese man page
by Akihiro Sagawa 15 Dec '13

15 Dec '13

On Thu, 12 Dec 2013 16:57:58 +0900, Akira Nakagawa wrote: > diff --git a/loader/wine.ja.UTF-8.man.in b/loader/wine.ja.UTF-8.man.in > new file mode 100644 > index 0000000..8c6f851 > --- /dev/null > +++ b/loader/wine.ja.UTF-8.man.in Great work! Updated man page is almost good. This includes much improvements from previous one. But some issues are remain. Typical issue is line length. Because groff, used for formatting man-pages, doesn't handle Japanese non-spacing line-breaking well. I have two suggestions about this: 1. Insert a space character between half-width character and full-width one. e.g. Windows のプログラムを Unix で実行します 2. Insert a space character between English words. e.g. Windows コンソールプログラム Other (mistranslation, nit-picking) issues as follows. > +.SH 説明 > +.B wine > +は引数に指定されたDOS、Windows > +3.X、 Win32またはWin64の実行可能なプログラムを読み込んで実行します(64bitシステム上の場合)。 How about reorder parenthesis text near by Win64? I feel a reader can't find where the end parenthesis depends on. In other words, he or she can't find out what application can be run on 32-bit systems. Please use 「64-bit」 like others, but I prefer 「64 bit」(without hyphen) or 「64ビット」(translate `bit' to Japanese transcription). > +CUIの実効可能プログラム(Windowsコンソールプログラム)を実行するには, > +.BR wine の代わりに > +.B wineconsole > +を使用してください。 Conversion error: 実効可能 -> 実行可能 Last comma, 「実行するには,」, should be Japanese punctuation mark. > +これはすべての出力を別々のウィンドウに出力します(これを実行するには > +X11が必要です)。 CUIプログラム用の > +.B wineconsole > +は非常に制限されたコンソールのサポートを提供するだけで、 > +プログラムはおそらく正しく機能しないでしょう。 The original text says `Not using wineconsole... ', but your translation says `wineconsole for CUI programs provides...'. > +.PP > +.B --help > +または > +.B --version > +だけを引数として実行した場合、 > +.B wine > +はただ小さなヘルプメッセージまたはバージョン情報をそれぞれ表示して終了します。 A reader might not get a meaning at the first reading. Because 「ただ」(simply)～「表示して」(print) are separated in the translation. > +.B wine > +を実行する際にコマンドラインの最後尾に実行するプログラムの引数を付け加えることで、 > +そのプログラムに引数を渡すことができます。 > +(例えば: \fIwine notepad C:\(rs\(rsTEMP\(rs\(rsREADME.TXT\fR). > +注:シェル上でWineを実行する際には、 > +エスケープシーケンス「\(rs」(とスペース)を付ける必要があります。 I think this is misleading. The original text mentions the need for escaping, and that is for special characters and spaces (because this might not be a character). Your translation just says need to add escape-sequence '\' (and spaces). > +.TP > +.B WINESERVER > +.B wineserver > +のパスと名前を指定します。 > +binary. これを指定しない場合、Wineは > +.IR @bindir@/wineserverを > +ロードしようとします。 Delete `binary.', please. > +.TP > +.B WINELOADER > +が新しいWindowsプロセスを立ち上げるためには > +.B wine > +のバイナリのパスと名前を指定します。 This text is unnatural and wrong. > .PP > .I クラス > はオプションで、次のいずれかです。 > .BR err > .BR warn > .BR fixme > .BR trace Please add punctuations for each keywords, and use a column at the end of the sentence. > +If > +.I クラス > +が指定されない場合、指定されたチャンネルのすべてのデバッグメッセージが表示されるようになります。それぞれのチャンネルは固有のWineのメッセージを出力します。 Please delete `If.' line. > +.TP > +WINEDEBUG=warn+dll,+heap > +はDLLの警告メッセージとすべてのヒープメッセージ有効にします。 > +.br メッセージ有効に --> メッセージを有効に > +.TP > +.B WINEDLLOVERRIDES > +はすべてのdllをロードするのに使用されるdllの上書きとロード命令のタイプを定義します。 You might think there is a load instruction type, but the original just says [override type] and [load order]. So, there is no types for load order. Additionally, in this case, I prefer to use 「ロード順序(=load sequence)」 for translating `load order', not 「ロード命令(=load directive)」. > +現在2つのタイプのWineプロセスのアドレス空間にロードされるライブラリがあります。 A reader might not get a meaning at the first reading. How about reordering like this? 「Wineプロセスのアドレス空間にロードされるライブラリには現在2つのタイプがあります。」 > +つまり、ネイティブのwindows dll.RI ( native ") とWine内蔵版dlls (" builtin )です。 This line needs to break before `.RI'. Plural word (dlls) is not common in Japanese text, please use `Wine内蔵版dll'. > +Ｗindowsのサポートするアーキテクチャを指定します。この変数は The first `W' is full-width form, please use half-width form like others. > +.TP > +OSSのサウンドドライバを設定する変数 A colon is needed at the end of this line. > .SH 製作者 > Wineは多くの開発者の働きによって成り立っています。製作者を一覧するには、ソースディストーションの最上層ディレ > クトリにあるテキストファイル > .I AUTHORS > を参照してください。 Unknown word: ディストーション (distortion?) Please reconsider to use this word. > +WineはLGPLライセンスの下で発布されています。ライセンスのコピーは Less commonly usage. Please consider to use following words, `発布' (distribute) -> `配布' `コピー' (copy) -> `写し' > +バグ報告は > +.UR http://bugs.winehq.org > +.B Wine bug tracker > +で行えます。 > +.UE . There is a redundant dot at the end of the sentence. How about changing as following: バグ報告は .UR http://bugs.winehq.org .B Wine bug tracker .UE で行えます。 > +最新のバージョンの > +.B wine > +はWineHQ > +.UR http://www.winehq.org/ > +.B Wine development headquarters > +から入手できます。 > +.UE . ditto. Regards, Akihiro Sagawa

1 0

Re: [PATCH] ddraw: add dsurface dimension tests, try 5
by Stefan Dösinger 14 Dec '13

14 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks for your persistence on this issue. I'll try to run those tests on some of my Windows machines to spot any card / driver dependent results. Some of your tests could be fragile, but I'll have a better opinion on that after trying them myself. Overall, you could reduce the number of lines of code here by organizing the test data in a table. Try something like static const struct { DWORD flags, width, height; HRESULT expect_hr; } test_data[] = { {DDSD_HEIGHT, 0, 128, DDERR_INVALIDPARAMS}, {DDSD_WIDTH, 128, 0, DDERR_INVALIDPARAMS}, {DDSD_WIDTH | HEIGHT, 128, 128, DD_OK}, {DDSD_WIDTH | HEIGHT, 0, 128, DDERR_INVALIDPARAMS}, {DDSD_WIDTH | HEIGHT, 128, 0, DDERR_INVALIDPARAMS}, etc. } Some things, like the video memory size exhaustion checks and the primary surface size checks are hard to handle this way. You can keep them in separate code blocks. Here are a few more issues, mostly minor style points: > + IDirectDrawSurface *dsurface = NULL; + IDirectDraw *lpDD; Please don't use the hungarian notation. I recommend to use the names ddraw and surface. > + ok(ret == DDERR_INVALIDPARAMS, "Creating an offscreen plain surface without a size info returned %08x (dsurface=%p)\n", ret, dsurface); This is a minor issue, but please add interpunctuation for consistency's sake. I don't think there's a reason to write dsurface here, other tests already establish that it should be NULL in case of an error. > + if(dsurface) + { + trace("Surface at %p\n", > dsurface); + IDirectDrawSurface_Release(dsurface); + > dsurface = NULL; + } The trace looks like it is a debugging leftover. > + /* Sanity check */ + memset(&desc, 0, sizeof(desc)); + > desc.dwSize = sizeof(desc); + desc.dwFlags = DDSD_CAPS | > DDSD_HEIGHT | DDSD_WIDTH; + desc.ddsCaps.dwCaps |= > DDSCAPS_OFFSCREENPLAIN; + desc.dwHeight = 128; + desc.dwWidth > = 128; + ret = IDirectDraw_CreateSurface(lpDD, &desc, &dsurface, > NULL); This isn't really necessary, if surface creation fails here many other tests wouldn't work. If you use a test data table like described above I'd leave it in to make sure the test loop works properly. > + desc.dwHeight = 1; + desc.dwWidth = 0xffff; + ret = > IDirectDraw_CreateSurface(lpDD, &desc, &dsurface, NULL); + > if(!(ddcaps.ddsCaps.dwCaps & DDSCAPS_VIDEOMEMORY)) + { + > ok(ret == DDERR_INVALIDPARAMS, "Creating an offscreen plain surface with width 0xffff and height 1 returned %08x\n", ret); > + } + else + { + todo_wine ok(ret == DD_OK, > "Creating an offscreen plain surface with width 0xffff and height 1 returned %08x\n", ret); > + } You can drop the curly brackets here, the existing code doesn't use them for single-line code blocks. (Well, mostly. It's not entirely consistent). I don't really like the DDSCAPS_VIDEOMEMORY check. I'll see how my Windows boxes behave, then we'll know if there's any deeper relationship between software-only ddraw and a maximum surface size. > + ret = IDirectDraw_CreateSurface(lpDD, &desc, &dsurface, > NULL); + todo_wine ok(ret == DDERR_INVALIDPARAMS, "Creating an > offscreen plain surface with width 0x10000 and height 1 returned %08x\n", ret); > + if(dsurface) + { + > IDirectDrawSurface_Release(dsurface); + dsurface = NULL; + > } If all possible paths expect a failure from CreateSurface, there's no need to try to release the surface. Just leak it, the test fails anyway. > + ret = IDirectDraw_SetCooperativeLevel(lpDD, NULL, > DDSCL_NORMAL); + ok(ret == DD_OK, "SetCooperativeLevel failed > with %08x\n", ret); I don't think this is needed. Also, is there a reason why you're not passing the window to the first SetCooperativeLevel call? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSrIlaAAoJEN0/YqbEcdMw48UP/R686XgOaYmgwxP23u5AUpM2 +zemL+zkTAmQdLXA0yrFTmXvQcEvJtd1j7Pbg32hCh1P4X27ygBO5L+XJ4oxfTwH ymYYyIJsU96iTIDqojOlqzAvQ/Z/aibIfrfmviWx0LIClUymu5+VWYgYmONqbf5p QAkVrAV12DRrQq1sJPXoqSZDaDvtsuj5hjuZbGdZBoP0vJygl+yZXgxdNsrfDh3l TIRrYyETdWdCFjjxEbJyFeB6lrFweAHOel54cuvAlGjErlSczdj8oCMGoHHGtnNr JOD5dK0LI1o9ngkbmIMSHfRo4Sk6Ug6476B9zNR/fETRXsBEPCVQfWoUIV3h0RI0 RjX5NMFRHANYRjXSQd8yXcpdyNWYONu0BhyBrMnHBNln+CpXyUJ8PM0nMptnVSKD 1fWzQfnQNnaklxYuHVvSuVctOPLmbf5PIHNSE333Xj0ddDA2uCtEzOkSH1aMStjV TMZUa7ggY0wCjeLP1NKOY6jN7ExhANx8ItzXn4h8n9eWNMyqJXi9kpfiVGJA9/v8 /Xmi2nWivBBWUh8qq5nPUGnWcLgeKuvFTobGq3jUbCYEf3/T7sZz58xuFdAp/xUt Yzg2ztvP9DUi8BuJuk51c0dtujgtIRMKkNCG/ISe7za2QhGloAGs0T/LWdUmrTxo ++uOj6zpdlFWCapAen6e =13rk -----END PGP SIGNATURE-----

1 1

Re: [PATCH] ddraw: add dsurface dimension tests, try 5
by Marvin 14 Dec '13

14 Dec '13

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3756 Your paranoid android. === w2008s64 (64 bit ddraw4) === ddraw4.c:5910: Test failed: Creating an offscreen plain surface with width 0x2001 and height 0xffff returned 8007000e === w7pro64 (64 bit ddraw4) === ddraw4.c:5910: Test failed: Creating an offscreen plain surface with width 0x2001 and height 0xffff returned 8007000e === w2008s64 (64 bit ddraw2) === ddraw2.c:5313: Test failed: Creating an offscreen plain surface with width 0x2001 and height 0xffff returned 8007000e === w7pro64 (64 bit ddraw2) === ddraw2.c:5313: Test failed: Creating an offscreen plain surface with width 0x2001 and height 0xffff returned 8007000e === w2008s64 (64 bit ddraw1) === ddraw1.c:4254: Test failed: Creating an offscreen plain surface with width 0x2001 and height 0xffff returned 8007000e === w7pro64 (64 bit ddraw1) === ddraw1.c:4254: Test failed: Creating an offscreen plain surface with width 0x2001 and height 0xffff returned 8007000e === w2008s64 (64 bit ddraw7) === ddraw7.c:5804: Test failed: Creating an offscreen plain surface with width 0x2001 and height 0xffff returned 8007000e === w7pro64 (64 bit ddraw7) === ddraw7.c:5804: Test failed: Creating an offscreen plain surface with width 0x2001 and height 0xffff returned 8007000e

1 0

Re: Ken Thomases : user32: Respect monitor work area when sizing or moving a top-level window.
by Ken Thomases 14 Dec '13

14 Dec '13

Hi Alexandre, This doesn't do the same thing as what I submitted. May I ask why you changed it? For instance, you shouldn't be able to drag the title bar even partially behind the menu bar. On Windows, I don't believe you can drag the title bar partially off the top of the screen. I'm certain that, if you position the task bar at the top of the screen, you can't drag the title bar partially behind it, either. (I tested both but my memory of the former isn't certain.) -Ken On Dec 13, 2013, at 12:46 PM, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 03f8f85ddae0cb7d7ff85d0478f1d9a77c88b26b > URL: http://source.winehq.org/git/wine.git/?a=commit;h=03f8f85ddae0cb7d7ff85d047… > > Author: Ken Thomases <ken(a)codeweavers.com> > Date: Thu Dec 12 16:49:48 2013 -0600 > > user32: Respect monitor work area when sizing or moving a top-level window. > > This prevents dragging a window's title bar behind a menu bar across the top > of a screen, for example. > > --- > > dlls/user32/winpos.c | 20 ++++++++++++++++++++ > 1 files changed, 20 insertions(+), 0 deletions(-) > > diff --git a/dlls/user32/winpos.c b/dlls/user32/winpos.c > index 22ee290..7cae0ad 100644 > --- a/dlls/user32/winpos.c > +++ b/dlls/user32/winpos.c > @@ -2625,6 +2625,7 @@ void WINPOS_SysCommandSizeMove( HWND hwnd, WPARAM wParam ) > BOOL moved = FALSE; > DWORD dwPoint = GetMessagePos (); > BOOL DragFullWindows = TRUE; > + HMONITOR mon = 0; > > if (IsZoomed(hwnd) || !IsWindowVisible(hwnd)) return; > > @@ -2673,6 +2674,7 @@ void WINPOS_SysCommandSizeMove( HWND hwnd, WPARAM wParam ) > { > parent = 0; > mouseRect = get_virtual_screen_rect(); > + mon = MonitorFromPoint( pt, MONITOR_DEFAULTTONEAREST ); > } > > if (ON_LEFT_BORDER(hittest)) > @@ -2749,6 +2751,24 @@ void WINPOS_SysCommandSizeMove( HWND hwnd, WPARAM wParam ) > pt.y = max( pt.y, mouseRect.top ); > pt.y = min( pt.y, mouseRect.bottom ); > > + if (!parent) > + { > + HMONITOR newmon; > + MONITORINFO info; > + > + if ((newmon = MonitorFromPoint( pt, MONITOR_DEFAULTTONULL ))) > + mon = newmon; > + > + info.cbSize = sizeof(info); > + if (mon && GetMonitorInfoW( mon, &info )) > + { > + pt.x = max( pt.x, info.rcWork.left ); > + pt.x = min( pt.x, info.rcWork.right ); > + pt.y = max( pt.y, info.rcWork.top ); > + pt.y = min( pt.y, info.rcWork.bottom ); > + } > + } > + > dx = pt.x - capturePoint.x; > dy = pt.y - capturePoint.y; > > > >

2 1