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

Launchpad project for Wine
by Tae Wong Dec. 17, 2013

Dec. 17, 2013

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 Dec. 17, 2013

Dec. 17, 2013

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 Dec. 17, 2013

Dec. 17, 2013

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 Dec. 17, 2013

Dec. 17, 2013

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 Dec. 16, 2013

Dec. 16, 2013

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 Dec. 15, 2013

Dec. 15, 2013

-----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 Dec. 15, 2013

Dec. 15, 2013

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 Dec. 14, 2013

Dec. 14, 2013

-----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 Dec. 14, 2013

Dec. 14, 2013

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 Dec. 14, 2013

Dec. 14, 2013

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

Re: wined3d: Ensure wined3d_ftoa() exponent is 2 digits on Windows.
by Henri Verbeet Dec. 14, 2013

Dec. 14, 2013

On 14 December 2013 06:28, Jonathan Liu <net147(a)gmail.com> wrote: > > This fixes a regression introduced by commit > 12f16f2127ffce9a05eedf008c3aa3732751a7e3 where the returned exponent > is 3 digits on Windows instead of 2 digits which results in rendering > errors. The printf implementation in the Microsoft Visual C runtime > uses three digits for the exponent by default. > If the issue here is that the buffers the callers pass are too small, I think that's what should be fixed, perhaps with a comment added to wined3d_ftoa(). Ideally we wouldn't use fixed size buffers there to begin with though.

1 0

Re: winealsa.drv: midiSeq must be protected by a mutex
by Alexandre Julliard Dec. 13, 2013

Dec. 13, 2013

Alexandre Bique <bique.alexandre(a)gmail.com> writes: > @@ -95,6 +95,7 @@ static int MODM_NumDevs = 0; > /* this is the total number of MIDI out devices found */ > static int MIDM_NumDevs = 0; > > +static CRITICAL_SECTION midiSeqLock = { NULL, -1, 0, 0, 0, 0 }; Please add debug information like it's done in other places. -- Alexandre Julliard julliard(a)winehq.org

1 0

Bugzilla attachment links arriving with &action=edit
by Bruno Jesus Dec. 13, 2013

Dec. 13, 2013

Hi all, since the update yesterday all links in emails received from the bugzilla have the action=edit so it's not no longer possible to directly open the attachements. Examples: --- Comment #8 from The Source <xxx(a)mail.ru> --- Created attachment 46837 --> http://bugs.winehq.org/attachment.cgi?id=46837&action=edit Launcher log (local.log) --- Comment #1 from Bruno Jesus <xxx(a)gmail.com> --- Created attachment 46835 --> http://bugs.winehq.org/attachment.cgi?id=46835&action=edit standard output --- Comment #3 from Travis Greenman <xxx(a)cartman-2000.net > --- Created attachment 46833 --> http://bugs.winehq.org/attachment.cgi?id=46833&action=edit Console output, with gl error and nvidia-smi output. Regards, Bruno

8 11

Re: [PATCH 3/5] ddraw: Change surface pitch before width.
by Henri Verbeet Dec. 13, 2013

Dec. 13, 2013

On 13 December 2013 12:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + switch(hr) > + { > + case WINED3DERR_INVALIDCALL: > + wined3d_mutex_unlock(); > + return DDERR_INVALIDPARAMS; > + default: > + break; /* Go on */ > + } That's called hr_ddraw_from_wined3d(). On its own this patch is perhaps innocent enough, but it looks like this is supposed to make 4/5 safe, in which case that patch ends up depending on a somewhat obscure implementation detail. I think it may be better to merge wined3d_surface_set_mem() into wined3d_surface_update_desc(), at least as far as the public interface is concerned. (And in the long term we really want that to be wined3d_texture_update_desc().)

2 3

Re: [PATCH] ddraw: add dsurface dimension tests, try 4
by Marvin Dec. 13, 2013

Dec. 13, 2013

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=3751 Your paranoid android. === build (build) === Patch failed to apply

1 0

Firefox says mirrors.ibiblio.org is a reported attack page
by Rosanne DiMesio Dec. 12, 2013

Dec. 12, 2013

A forum user reported that they got a "Reported Attack Page!" warning when they tried to download the Wine source tarball from mirrors.ibiblio.org. I checked, and I got the warning from Firefox, too. Chrome and Opera don't have a problem going to the site from the link here, but googling ibiblio.org brings up a warning that "This site may harm your computer" in all three browsers. -- Rosanne DiMesio <dimesio(a)earthlink.net>

1 0

Re: kernel32/tests: Remove some expected values for test_DeleteFileA()
by Dmitry Timoshkov Dec. 12, 2013

Dec. 12, 2013

Zhenbo Li <litimetal(a)gmail.com> wrote: > There're too many expected values from GetLastError(), and I think it > might be confusing. Usually there was a reason why there are so many different results in ok() statements, it would be a good idea to check git history and find out that reasons it out instead of simply declaring them as confusing and removing them altogether. -- Dmitry.

2 1

Re: [3/4] secur32/tests: Add a test for QueryCredentialsAttributes(SECPKG_CRED_ATTR_NAMES). Take 2.
by Nikolay Sivov Dec. 12, 2013

Dec. 12, 2013

On 12/12/2013 09:13, Dmitry Timoshkov wrote: > + > + st = pQueryCredentialsAttributesA(&cred, SECPKG_CRED_ATTR_NAMES, &names); > + ok(st == SEC_E_NO_CREDENTIALS || st == SEC_E_UNSUPPORTED_FUNCTION /* before Vista */, "expected SEC_E_NO_CREDENTIALS, got %08x\n", st); > + Second possible return code should be broken(), otherwise your code change in next patch won't make any effect on tests.

2 5

Re: [PATCH 3/6] d3d9/tests: Test user memory and getdc interaction.
by Henri Verbeet Dec. 11, 2013

Dec. 11, 2013

On 11 December 2013 12:22, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + data = HeapAlloc(GetProcessHeap(), 0, sizeof(data) * 16 * 16); > + memset(data, 0xaa, sizeof(data) * 16 * 16); I think you meant "sizeof(*data)" here.

2 1

Re: [2/2] programs/msiexec: MSI service should report SERVICE_STOPPED when appropriate.
by André Hentschel Dec. 11, 2013

Dec. 11, 2013

Am 11.12.2013 09:16, schrieb Dmitry Timoshkov: > --- > programs/msiexec/service.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/programs/msiexec/service.c b/programs/msiexec/service.c > index 4b72fe0..fdd29bd 100644 > --- a/programs/msiexec/service.c > +++ b/programs/msiexec/service.c > @@ -81,6 +81,8 @@ static BOOL UpdateSCMStatus(DWORD dwCurrentState, DWORD dwWin32ExitCode, > > static void WINAPI ServiceCtrlHandler(DWORD code) > { > + DWORD state = SERVICE_RUNNING; > + > WINE_TRACE("%d\n", code); > > switch (code) > @@ -89,13 +91,14 @@ static void WINAPI ServiceCtrlHandler(DWORD code) > case SERVICE_CONTROL_STOP: > UpdateSCMStatus(SERVICE_STOP_PENDING, NO_ERROR, 0); > KillService(); > + state = SERVICE_STOPPED; > return; Hi, setting the variable here seems to have no effect i just have seen that from the patch without a look at the code, so i still might be wrong...

1 0

Bugzilla emails in html format after update
by Bruno Jesus Dec. 11, 2013

Dec. 11, 2013

Hi, after the bugzilla update today I started receiving all emais in html format even with the preferences set to text email (double checked). For some reason gmail/firefox uses very small fonts to display the bug comments in this new format and it's quite unreadable for me. Is anyone else receiving html emails even with text emails configured in preferences? Or is there any other preference that need to be changed in order to have the text emails back? Best wishes, Bruno

3 3

Re: [PATCH 2/5] wined3d: Recreate DIB sections in wined3d_surface_update_desc().
by Stefan Dösinger Dec. 11, 2013

Dec. 11, 2013

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-12-11 14:32, schrieb Henri Verbeet: > Since commit 6bc69c271bf440b4ecad012dc57888fdffc075d5, the GDI > implementation assumes DIB sections always exist. Actually the idea behind this patch was that all paths that need a DIB section create one if necessary. Is there a place where that's not true? If it's about x11_copy_to_screen I think the better fix is calling surface_getdc from there. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSqHuLAAoJEN0/YqbEcdMwreEP/RCg6dr20bqTzc+P3HB+mvIO JCURzQz25PzWTnIn4+M3f8a/NcHP0Fu6621Te71Y2kk+be1ncIDMI9SAEAOzP4cW ELwmSlxgDUgZIx8w+cR8ce56Jg+ESesNEfPqwT7oWSVHnJqZnouo8IBp8xXCHc3K J+ACLw8PWZoorXg9YVVLrVWwEyxr1mamQE/35WlXEMRJ/6gqZwdML6bCY/wVJ/Vf 18lBebBy9aluiXKyuEUQA1rz1n4Ji7Cz6IFiK+TGGkiPk9WHJekG3tREI9LoT4Hi VFrktfl/3P1wNb4/ab2U0xjbVOPdtqHqSU6RWfB+jjI3VvzLjjtinI/5I5ip2f8u f7XFm8EV2+0czBjXwgaIouWYYEKIEE1wZKZBPjUU+RQUKfdohuSD/QCNC9E3uf7f qhR01J3M4O6z41RJGwBMBwI2lHsEQWZaj3rsryJzo2mxRoMvv/ksV7oB75mgPQaz jShTnEvs4SMFh9PMkANNpRVUWvVu0b27hUeIvlo2GbNDhJKsnll0YFQfL6eKm29y Kr7ltkqRoWyeA/2Q3IGBTFF0l1a1F9JAgZxy8SRqpykglfc0ekCazGhQUku0Vi1/ 1lvnzf2K9RkT5gIPlMmxuHTmEunc4wdk2T7SsEZK8htnMTqIyV+XoaSyjezg1K2R uDCAYLqI+6lx9j5r31xR =tLfE -----END PGP SIGNATURE-----

2 2

Re: [5/5] ws2_32: Move the buffer used by inet_ntoa into the per thread data.
by Marvin Dec. 11, 2013

Dec. 11, 2013

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=3722 Your paranoid android. === wxppro (32 bit sock) === sock.c:520: Test failed: oob_server (4c0): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 00000000 === w2008s64 (32 bit sock) === sock.c:520: Test failed: oob_server (750): unexpectedly at the OOB mark: 0

1 0

Re: [4/5] ws2_32/tests: Add a test for inet_ntoa called from two threads.
by Marvin Dec. 11, 2013

Dec. 11, 2013

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=3721 Your paranoid android. === wxppro (32 bit sock) === sock.c:520: Test failed: oob_server (c0): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:520: Test failed: oob_server (750): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:520: Test failed: oob_server (654): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 000007FEFE4C9CD9

1 0

Re: [4/4] secur32: Make schannel implementation of QueryCredentialsAttributes(SECPKG_CRED_ATTR_NAMES) return SEC_E_NO_CREDEN
by Marvin Dec. 11, 2013

Dec. 11, 2013

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=3720 Your paranoid android. === wxppro (32 bit schannel) === schannel.c:305: Test failed: expected SEC_E_NO_CREDENTIALS, got 80090302 schannel.c:800: Test failed: expected SEC_E_NO_CREDENTIALS, got 80090302

1 0

Re: [3/4] secur32/tests: Add a test for QueryCredentialsAttributes(SECPKG_CRED_ATTR_NAMES).
by Marvin Dec. 11, 2013

Dec. 11, 2013

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=3719 Your paranoid android. === wxppro (32 bit schannel) === schannel.c:306: Test failed: expected SEC_E_NO_CREDENTIALS, got 80090302 schannel.c:802: Test failed: expected SEC_E_NO_CREDENTIALS, got 80090302

1 0

Re: [PATCH 5/5] d3d9: shared_handle must be NULL in non-ex d3d9 (try 2).
by Marvin Dec. 11, 2013

Dec. 11, 2013

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=3709 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 4/5] d3d9: Implement user memory for offscreen plain surfaces (try 4).
by Marvin Dec. 11, 2013

Dec. 11, 2013

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=3708 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/5] d3d9: Buffers do not support user memory (try 4).
by Marvin Dec. 11, 2013

Dec. 11, 2013

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=3707 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/5] d3d9: Volume and cube textures do not support user memory (try 4).
by Marvin Dec. 11, 2013

Dec. 11, 2013

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=3706 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/5] d3d9/tests: Test user memory with D3DPOOL_SCRATCH (try 3).
by Marvin Dec. 11, 2013

Dec. 11, 2013

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=3705 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 5/5] d3d9: shared_handle must be NULL in non-ex d3d9.
by Marvin Dec. 11, 2013

Dec. 11, 2013

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=3704 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 4/5] d3d9: Implement user memory for offscreen plain surfaces (try 3).
by Marvin Dec. 11, 2013

Dec. 11, 2013

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=3703 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/5] d3d9: Buffers do not support user memory (try 3).
by Marvin Dec. 11, 2013

Dec. 11, 2013

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=3702 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/5] d3d9: Volume and cube textures do not support user memory (try 3).
by Marvin Dec. 10, 2013

Dec. 10, 2013

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=3701 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [1/2] gdi32: Return ANSI character code as glyph index for bitmap fonts.
by Alexandre Julliard Dec. 10, 2013

Dec. 10, 2013

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > @@ -5975,7 +5975,7 @@ static FT_UInt get_GSUB_vert_glyph(const GdiFont *font, UINT glyph) > return GSUB_apply_feature(header, feature, glyph); > } > > -static FT_UInt get_glyph_index(const GdiFont *font, UINT glyph) > +static FT_UInt get_glyph_index(const GdiFont *font, UINT glyph, BOOL ret_char_code) > { > FT_UInt glyphId; > It would be better to have a separate function instead of having the same function return two different types of index. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: include: Add taskschd.idl.
by Jacek Caban Dec. 10, 2013

Dec. 10, 2013

Hi Dmitry, On 12/10/13 10:12, Dmitry Timoshkov wrote: > + HRESULT get_Connected([out, retval] VARIANT_BOOL *connected); > + HRESULT get_TargetServer([out, retval] BSTR *server); > + HRESULT get_ConnectedUser([out, retval] BSTR *user); > + HRESULT get_ConnectedDomain([out, retval] BSTR *domain); > + HRESULT get_HighestVersion([out, retval] DWORD *version); Those should use [propget] attribute instead of explicit get_* prefix. Same for other get_* and put_* methods (with [propput]). Cheers, Jacek

1 0

Re: [PATCH 1/5] d3d9/tests: Test user memory with D3DPOOL_SCRATCH (try 2).
by Henri Verbeet Dec. 10, 2013

Dec. 10, 2013

On 10 December 2013 12:23, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @Henri: I'm not sure what kind of control flow you had in mind here. The > best understanding I could come up with was a nested if (first check for > D3DPOOL_DEFAULT, then handle the D3DPOOL_SYSTEMEM special case), which I > think is ugly. I removed the case check for D3DPOOL_SCRATCH, at the cost > of not writing a visible FIXME for pool 0x6. ... > if (shared_handle) > { > - if (pool == D3DPOOL_SYSTEMMEM) > + switch (pool) > { > - if (levels != 1) > + case D3DPOOL_DEFAULT: > + FIXME("Resource sharing not implemented, *shared_handle %p.\n", *shared_handle); > + break; > + > + case D3DPOOL_SYSTEMMEM: > + if (levels != 1) > + { > + WARN("Trying to create a mipmapped user memory texture.\n"); > + return D3DERR_INVALIDCALL; > + } > + set_mem = TRUE; > + break; > + > + default: > + WARN("Trying to create a texture with pool %#x and shared_handle %p.\n", > + pool, shared_handle); > return D3DERR_INVALIDCALL; > - set_mem = TRUE; > } > - else > - FIXME("Resource sharing not implemented, *shared_handle %p.\n", *shared_handle); > } > + { + if (pool != D3DPOOL_DEFAULT) + { + WARN("Trying to create a shared texture in pool %#x.\n", pool); + return D3DERR_INVALIDCALL; + } FIXME("Resource sharing not implemented, *shared_handle %p.\n", *shared_handle); + }

1 0

Re: [PATCH 1/5] d3d9/tests: Test user memory with D3DPOOL_SCRATCH (try 2).
by Marvin Dec. 10, 2013

Dec. 10, 2013

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=3700 Your paranoid android. === build (build) === Could not copy the patch to the VM: Unable to connect to testnet.winehq.org:22001:10.42.42.130:4242: No route to host

1 0

Implementing msvcrt.__CxxFrameHandler
by Alexandre Bique Dec. 9, 2013

Dec. 9, 2013

Hi, I found that __CxxFrameHandler is not implemented for wine64, and I'd like to fix this because I think it is the reason why Ableton Live 9.1 is crashing at start up. If someone can implement it, then it is great! Otherwise if someone can give me guidelines, I can try to understand how it works and do it myself. Here is a previous email talking about this: http://www.winehq.org/pipermail/wine-devel/2011-April/089617.html Here is the bug about Ableton Live 9.1: http://bugs.winehq.org/show_bug.cgi?id=35092 Regards, -- Alexandre Bique

1 0

Re: [PATCH 1/4] d3d9/tests: Test user memory with D3DPOOL_SCRATCH.
by Henri Verbeet Dec. 9, 2013

Dec. 9, 2013

On 9 December 2013 13:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > The undocumented d3d9ex managed pool with enum value 6 does not allow > user memory textures either. I'm not including tests for that yet > until our d3d9 can handle this pool. I'm not quite sure I see the point of this test. The way the docs say this works is that in the general case resource sharing only works with default pool resources. Creating system memory textures with user memory backing is an exception to that. So I'd expect this test to fail in the first place because the resource is not in the default pool, and in the second place because the handle you're passing is most likely not a valid resource handle.

1 0

Re: [PATCH 2/4] d3d9: Volume and cube textures do not support user memory (try 2).
by Henri Verbeet Dec. 9, 2013

Dec. 9, 2013

On 9 December 2013 13:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > if (shared_handle) > + { > + if (pool != D3DPOOL_DEFAULT) > + { > + WARN("User memory is not allowed on volume textures.\n"); Similarly, I don't think this warning really represent what's going on. The issue is that resource sharing is only allowed with default pool resources. (And quite possibly only on d3d9ex devices.)

1 0

Mobile version input methods (on-screen buttons, keyboards, virtual joysticks)
by WineBuG Dec. 8, 2013

Dec. 8, 2013

How would you deal with lack of the keyboard and mouse in the future ARM (Android) version of Wine? Will one be able to add virtual on-screen buttons and joysticks in some way? Are you going to analyze controls solutions of other mobile apps (for example, games)? Regards, WineBuG

1 0

Build issues with winemac.drv and Mavericks
by C.W. Betts Dec. 8, 2013

Dec. 8, 2013

I’ve run into issues when building winemac.drv on Mavericks. Attached is the log.

3 3

Mobile version input methods (on-screen buttons, keyboards, virtual joysticks)
by WineBuG Dec. 7, 2013

Dec. 7, 2013

How would cope with lack of the keyboard and mouse in the future ARM (Android) version of Wine? Will one be able to add virtual on-screen buttons and joysticks in some way? Are you going to analyze other mobile apps (for example, games) controls solutions? Regards, WineBuG

1 0

Re: [PATCH] user32: Don't send message to get window text, avoid a deadlock.
by Dmitry Timoshkov Dec. 7, 2013

Dec. 7, 2013

Qian Hong <qhong(a)codeweavers.com> wrote: > - Fixed http://bugs.winehq.org/show_bug.cgi?id=27282, affects Arcania: > Gothic 4 and online bank of abchina and > - Makes Anastasius happy :p This patch needs at least some tests. -- Dmitry.

2 1

Re: [PATCH 2/5] ole32: Simplify enumeration cloning using duplicated key
by Alexandre Julliard Dec. 6, 2013

Dec. 6, 2013

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > - new_this->IEnumCATEGORYINFO_iface = This->IEnumCATEGORYINFO_iface; > - new_this->ref = 1; > - new_this->lcid = This->lcid; > - /* FIXME: could we more efficiently use DuplicateHandle? */ > - open_classes_key(HKEY_CLASSES_ROOT, keyname, KEY_READ, &new_this->key); > - new_this->next_index = This->next_index; > + cloned->IEnumCATEGORYINFO_iface = This->IEnumCATEGORYINFO_iface; > + cloned->ref = 1; > + cloned->lcid = This->lcid; > > - *ppenum = &new_this->IEnumCATEGORYINFO_iface; > + if (!DuplicateHandle(GetCurrentProcess(), This->key, GetCurrentProcess(), (HANDLE*)&cloned->key, 0, FALSE, DUPLICATE_SAME_ACCESS)) > + { > + IEnumCATEGORYINFO_Release(&cloned->IEnumCATEGORYINFO_iface); > + return E_FAIL; > + } Using DuplicateHandle is not a good idea on registry keys, particularly for HKEY_CLASSES_ROOT keys. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shell32/tests: Use GetVersion() to skip Timeout test (try 2)
by Nikolay Sivov Dec. 5, 2013

Dec. 5, 2013

On 12/6/2013 09:10, Zhenbo Li wrote: > I'm using win_skip() for Vista&Win2008 this time. > > --- > dlls/shell32/tests/shlfileop.c | 36 +++++++++++++++++++----------------- > 1 file changed, 19 insertions(+), 17 deletions(-) > > Hm, it's the same issue. Please don't use GetVersion().

1 0

Re: shell32/tests: Use GetVersion() to skip Timeout test (try 2)
by Marvin Dec. 5, 2013

Dec. 5, 2013

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=3671 Your paranoid android. === wvista (32 bit shlfileop) === Timeout === w2008s64 (32 bit shlfileop) === Timeout === w2008s64 (64 bit shlfileop) === Timeout

1 0

Re: wined3d: Use BOOL type where appropriate
by Henri Verbeet Dec. 5, 2013

Dec. 5, 2013

On 5 December 2013 23:14, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > Note: in surface.c, used "?1:0" construct to avoid implicit BOOL arithmetic > --- > dlls/wined3d/arb_program_shader.c | 19 +++++++++---------- > dlls/wined3d/context.c | 20 ++++++++++---------- > dlls/wined3d/device.c | 2 +- > dlls/wined3d/gl_compat.c | 4 ++-- > dlls/wined3d/shader.c | 20 ++++++++++---------- > dlls/wined3d/stateblock.c | 22 +++++++++++----------- > dlls/wined3d/surface.c | 8 ++++---- > dlls/wined3d/utils.c | 8 ++++---- > 8 files changed, 51 insertions(+), 52 deletions(-) > I don't think so, most of these are bitfields, and the surface.c change is actually making the code worse.

1 0