- wine-devel - winehq.org

D3D command stream abandoned?
by Forest 23 Dec '13

23 Dec '13

I haven't seen any news of the command stream lately. The last thing I read was the mention of "more preparation work" in the 1.7.4 release announcement. Has the project been abandoned? I maintain a wine build for gamers, and currently have it frozen at version 1.7.1 with Stefan's September 2 command stream patches, because they seem to boost performance quite a bit for some folks. I'd love to get something more mature into my users' hands if it's available.

2 1

Re: add japanese man page(try 2)
by Akihiro Sagawa 23 Dec '13

23 Dec '13

On Fri, 20 Dec 2013 00:00:38 +0900, Akira Nakagawa wrote: > Subject: [PATCH] add japanese man page(try 2) Looks mostly fine. Please review following five points. 1. Changes for loader/Makefile.in was forgotten in try 2. 2. There were typos. Double punctuations, 「、、」 (two points) > +CUIの実行可能プログラム(Windows コンソールプログラム)を実行するには、、 > +は単にそれぞれ小さなヘルプメッセージ、、またはバージョン情報を表示して終了します。 3. Please don't use `タイプ' for different meanings. The former should be updated. > +はすべてのdll をロードするのに使用されるdll の上書きとロード順位のタイプを定義します。 > +Wineプロセスのアドレス空間にロードされるライブラリには現在2つのタイプがあります。 4. You added a space character after almost half-width characters, but some points not updated. For instance, you might need to add a space character after `X11'. > 使用するX11のディスプレイを指定します。 And you didn't insert a space character *before* a half-width character. Are they intentional? 5. There is still `.UE .' in the document. > +多くのアプリケーションのステータス報告が > +.UR http://appdb.winehq.org > +.B Wine Application Database > +にあります。 > +.UE . This should be: 多くのアプリケーションのステータス報告が .UR http://appdb.winehq.org .B Wine Application Database .UE にあります。 Regards, Akihiro Sagawa

1 0

Re: [2/4] taskschd: Add registration for TaskScheduler interfaces.
by Alexandre Julliard 23 Dec '13

23 Dec '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > +[ > + threading(both), > + progid("Schedule.Service.1"), > + vi_progid("Schedule.Service"), > + uuid(0f87369f-a4e5-4cfc-bd3e-73e6154572dd) > +] > +coclass TaskService { interface ITaskService; } This should go in the public header, with the correct name. It's also supposed to be a typelib. -- Alexandre Julliard julliard(a)winehq.org

1 0

ldd for wine dll- Sorry for preview spell errors,
by 逸天不羁 23 Dec '13

23 Dec '13

hello every one, I have write a application just like ldd of GNU/Linux, I don't how to push it to the upstream. Here is the patchs.

3 2

Re: [PATCH] oleacc: Added DllGetClassObject() stub
by 中川祥 22 Dec '13

22 Dec '13

You need to add registry for it. And why don't you implement it? Some other dlls did it. 2013/12/22, Nikolay Sivov <nsivov(a)codeweavers.com>: > --- > dlls/oleacc/main.c | 6 ++++++ > dlls/oleacc/oleacc.spec | 1 + > 2 files changed, 7 insertions(+) > > >

2 1

ldd for wine dll---cpp codes removed
by 逸天不羁 22 Dec '13

22 Dec '13

hello, Every one , although we have the winedump, this little tool can be useful sometime. And I have remove all the cpp codes .

1 0

ldd for wine dll
by 逸天不羁 21 Dec '13

21 Dec '13

hell every one, I have write a application just like ldd of GNU/Linux, I don't how to push it to the upstream. Here is the patchs.

2 1

Fwd: ldd for wine dll
by David Quintana (gigaherz) 21 Dec '13

21 Dec '13

(forwarding to the list) ---------- Forwarded message ---------- From: David Quintana (gigaherz) <gigaherz(a)gmail.com> Date: 21 December 2013 12:16 Subject: Re: ldd for wine dll To: 逸天不羁 <yitianbuji(a)qq.com> Read this guide: http://wiki.winehq.org/SubmittingPatches On 21 December 2013 12:12, 逸天不羁 <yitianbuji(a)qq.com> wrote: > hell every one, > I have write a application just like ldd of GNU/Linux, I don't how to push > it to the upstream. Here is the patchs. > > > >

1 0

Re: [3/5] ntdll: Allow passing NULL buffer to printf functions
by Alexandre Julliard 20 Dec '13

20 Dec '13

Sebastian Lackner <sebastian(a)fds-team.de> writes: > @@ -72,7 +73,12 @@ static inline int pf_output_stringW( pf_output *out, LPCWSTR str, int len ) > > if( len < 0 ) > len = strlenW( str ); > - if( out->unicode ) > + if (!out->buf.X) > + { > + out->used += len; > + return len; > + } > + else if (out->unicode) That's not correct for Unicode conversions. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] port: MSVC provides a correct getenv prototype.
by Stefan Dösinger 19 Dec '13

19 Dec '13

Am 19.12.2013 um 15:23 schrieb Jonas Maebe <jonas.maebe(a)elis.ugent.be>: > Shouldn't the title of this patch read "getopt" instead of "getenv"? Uh, now that you mention it, the title isn’t quite right. It should be more like "port: MSVC does not provide a conflicting getopt prototype." - It doesn’t provide a getopt prototype at all. The stdlib.h include is needed for getenv, which is used in the file. I misread the "getopt" in the comment as "getenv" on my quick read. (And yes, I did wonder how this code is supposed to work without defining getenv at all, but my conclusion was that maybe a warning about undefined getenv was considered better than a compile error. It makes a lot more sense with a conflicting getopt.) I took the liberty to CC wine-devel on my reply.

1 0

Re: taskschd: Add new dll.
by Saulius Krasuckas 18 Dec '13

18 Dec '13

* On Tue, 17 Dec 2013, Dmitry Timoshkov wrote: > 4 files changed, 123 insertions(+) > create mode 100644 dlls/taskschd/Makefile.in > create mode 100644 dlls/taskschd/taskschd.c > create mode 100644 dlls/taskschd/taskschd.spec Could you please tell what app does need it? I find zero bugs with the bugzilla query. [*] S. [*] http://bugs.winehq.org/buglist.cgi?query_format=advanced&longdesc=taskschd&…

3 3

Wine + ICC (Intel XE Compiler)
by jordan 18 Dec '13

18 Dec '13

Hey List, I've been playing around with ICC and i am curious if anyone has instructions and/or Patches for building Wine using Intel's XE Compiler?? ...I'm using the latest version; icc version 14.0.1 (gcc version 4.8.0 compatibility) I've noticed older link on winehq; http://wiki.winehq.org/icc ... It seems he was able to get wine32 to build on x86_64, but obviously, 2008 was a little early for wine64 / ICC tests... Currently, it doesn't get to far through configure; checking for gcc... icc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether icc accepts -g... yes checking for icc option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether icpc accepts -g... yes checking for cpp... cpp checking whether icc supports __builtin_ms_va_list... no configure: error: You need gcc >= 4.4 to build Wine as 64-bit. (and then it terminates). ICC is setup properly on my machine(s), ie: i have used it to compile other packages. (mostly 64bit, but i did test 32bit, which worked fine too). Anyway, If anyone has any tips and/or patches they could share, I would be very grateful / interested. :) ... Jordan

3 4

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

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

14 Dec '13

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 13 Dec '13

13 Dec '13

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 13 Dec '13

13 Dec '13

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 13 Dec '13

13 Dec '13

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 13 Dec '13

13 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=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 13 Dec '13

13 Dec '13

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 12 Dec '13

12 Dec '13

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 12 Dec '13

12 Dec '13

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 11 Dec '13

11 Dec '13

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 11 Dec '13

11 Dec '13

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 11 Dec '13

11 Dec '13

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 11 Dec '13

11 Dec '13

-----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 11 Dec '13

11 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=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 11 Dec '13

11 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=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 11 Dec '13

11 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=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 11 Dec '13

11 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=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 11 Dec '13

11 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=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 11 Dec '13

11 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=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 11 Dec '13

11 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=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 11 Dec '13

11 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=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 11 Dec '13

11 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=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 11 Dec '13

11 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=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 11 Dec '13

11 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=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 11 Dec '13

11 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=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 10 Dec '13

10 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=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 10 Dec '13

10 Dec '13

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 10 Dec '13

10 Dec '13

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 10 Dec '13

10 Dec '13

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel