August 2010 - Wine-Devel - list.winehq.org

Re: [4/7] comctl32/imagelist: Fix failure code for IImageList_Remove()

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4591 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [3/7] comctl32/imagelist: Fix failure code for IImageList_Draw()

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4590 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [2/7] comctl32/tests: Use reduced IMAGELISTDRAWPARAMS structure size for tests

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4589 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [1/7] comctl32/tests: Use better names for test functions, discover some new test failures

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4588 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: oleau32: Try both SYS_WIN64 and SYS_WIN32 syskind in QueryPathOfRegTypeLib on win64.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4582 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: gdi32: Properly set ERROR_NOACCESS when GetObject receives invalid arguments

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4581 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH 4/4] explorerframe: Some additional basic tests.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4578 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH 3/4] explorerframe: Implement EnsureItemVisible.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4577 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH 2/4] explorerframe: Implement HitTest

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4576 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4574 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [5/5] urlmon/tests: Added tests for IUriBuilder_GetFragment

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4571 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Ongoing Debian package maintenance.

by Ben Klein

Hello everyone, My health has not improved at all since my last call for help with the Debian package management. I really need someone to take over from me, or at least some help to devise a new set of (semi-)automated build scripts. Any volunteers? Kind regards, Ben

Aug. 20, 2010

problem with ./configure & libGLU vs. libice-dev

by wylda＠volny.cz

Hi, isn't there a problem with wine's configure script? I'm running on new Debian Squezee and noticed (luckily), that when libice-dev is installed, than ./configure can't find "-lGLU". But libice-dev doesn't have any influence on file "libGLU.so.1". So why configure says me "-lGLU... not found" when file "/usr/lib/libGLU.so.1" is present? Desperate W.

Aug. 20, 2010

Re: [website]Japanese Translation for "About Wine" page

by Jeremy Newman

I'll accept this patch when we also have a JA translation of the Front landing page. No point having other pages translated without at least that. -Newman On 08/17/2010 11:00 PM, kikuchy.h(a)gmail.com wrote: > From: Hiroshi Kikuchi<kikuchy.h(a)gmail.com> > > I want to join wine project. Nice to meet you. > Hiroshi Kikuchi > --- > templates/ja/about.template | 27 +++++++++++++++++++++++++++ > 1 files changed, 27 insertions(+), 0 deletions(-) > create mode 100644 templates/ja/about.template > > diff --git a/templates/ja/about.template b/templates/ja/about.template > new file mode 100644 > index 0000000..b83fad7 > --- /dev/null > +++ b/templates/ja/about.template > @@ -0,0 +1,27 @@ > + > + > + > +<h1 class="title">Wine について</h1> > + > +<p>Wine は、 Windows のソフトウェアを Windows 以外のOSで動作させるものです。Wine を使えば、Windows でするように Windows アプリケーションのインストールと実行が出来るようになります。</p> > + > +<p>Wine は現在活発に開発されています。まだ全てのプログラムが動作する訳ではありませんが、すでに<a href="http://wiki.winehq.org/UsageStatistics" title="Wine Usage Statistics">何人もの人たちが</a> Wine を使ってソフトウェアを動かしています。</p> > + > +<h3>オープンソース、そしてユーザーによる支援</h3> > + > +<p>Wine は未来永劫<a href="http://wiki.winehq.org/Licensing" title="Wine licensing">フリーソフト</a>です。Wine のソースコードのおよそ半分がボランティアによって書かれています。残り半分は商業的利潤のため、特にサポートがあるバージョンの Wine を発売している<a href="http://www.codeweavers.com/products/" title="Codeweavers Crossover Office">Codeweavers</a>によって支えられています。</p> > + > +<p>Wine はユーザーコミュニティに大きく頼っています。ユーザーのテストが私たちの、プログラムの動作状況を記録した<a href="http://appdb.winehq.org/" title="Wine Application Database">アプリケーションデータベース</a>を埋めてくれていますし、<a href="http://forums.winehq.org/" title="WineHQ Forums">フォーラム</a>の質問に対する答えも全てボランティアによるものです。</p> > + > +<h3>こちらもご覧ください:</h3> > +<ul> > +<li><a href="http://wiki.winehq.org/ImportanceOfWine">Wine が重要な理由</a></li> > +<li><a href="http://wiki.winehq.org/Debunking_Wine_Myths">Wine にまつわるウソ・ホント</a></li> > +<li><a href="http://wiki.winehq.org/WineHistory">Wine プロジェクトの歴史</a></li> > +<li><a href="http://wiki.winehq.org/ProjectOrganization">Organization and Leadership</a></li> > +</ul> > + > +<hr> > +<div class="link-container"> > +<p class="right-link">Wine の歴史:<a href="{$root}/history">次へ</a></p> > +</div> > > > >

Aug. 20, 2010

Re: appwiz.cpl: Removed sign comparison warning

by Nikolay Sivov

On 8/20/2010 20:04, Marko Nikolic wrote: > Changed variable type to match function return type. > --- > dlls/appwiz.cpl/appwiz.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/appwiz.cpl/appwiz.c b/dlls/appwiz.cpl/appwiz.c > index ffd2b24..1b3370b 100644 > --- a/dlls/appwiz.cpl/appwiz.c > +++ b/dlls/appwiz.cpl/appwiz.c > @@ -406,7 +406,7 @@ static void UpdateButtons(HWND hWnd) > { > APPINFO *iter; > LVITEMW lvItem; > - DWORD selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, LVM_GETNEXTITEM, -1, > + LRESULT selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, LVM_GETNEXTITEM, -1, > LVNI_FOCUSED | LVNI_SELECTED); > BOOL enable_modify = FALSE; > There's no need for that, return value means integer item index. What are you fixing with that?

Aug. 20, 2010

Re: The Test Bot seems to be having issues

by André Hentschel

Am 20.08.2010 17:15, schrieb Greg Geldorp: > Hi Thomas, > >> From: Thomas Mallaly >> >> First off, I'm not sure who should be contacted about this, but, it > appears >> that the test bot has got itself stuck while trying to run tests on a > patch >> submitted last night. > > Sorry, hadn't noticed it got stuck. Usually it doesn't need much > baby-sitting, > so I don't keep a close look on it. > You can always use the "Feedback" link on the TestBot home page. > >> The job in question is here [1], it's been over 12 >> hours since any progress has been made on it and no other submissions have >> run since then. Also, the Windows 98SE has been "reverting" this whole > time, >> so I'm not sure if this is the culprit or not. >> >> I also hate to admit that the job in question is from one of my patches I >> sent in last night (although I'm pretty sure it doesn't have anything to > do >> with the quality of the code in the patch ;-) ). > > The Win9x VMs are on a different (physical) machine, it appears there was a > network problem between the Test Bot host and the machine hosting the Win9x > VMs. The Win98SE VM getting stuck in the "reverting" state is the cause of > the problems, nothing to do with your patch. > >> Anyways, I'm hoping that somebody in charge of the test bot might be able > to >> fix the traffic jam it's causing. > > It's back up and running again, trying to catch up. > > Ge. > > > > Thx, will be a hard weekend for testbot, as today there should be two commits :) -- Best Regards, André Hentschel

Aug. 20, 2010

RE: The Test Bot seems to be having issues

by Greg Geldorp

Hi Thomas, > From: Thomas Mallaly > > First off, I'm not sure who should be contacted about this, but, it appears > that the test bot has got itself stuck while trying to run tests on a patch > submitted last night. Sorry, hadn't noticed it got stuck. Usually it doesn't need much baby-sitting, so I don't keep a close look on it. You can always use the "Feedback" link on the TestBot home page. > The job in question is here [1], it's been over 12 > hours since any progress has been made on it and no other submissions have > run since then. Also, the Windows 98SE has been "reverting" this whole time, > so I'm not sure if this is the culprit or not. > > I also hate to admit that the job in question is from one of my patches I > sent in last night (although I'm pretty sure it doesn't have anything to do > with the quality of the code in the patch ;-) ). The Win9x VMs are on a different (physical) machine, it appears there was a network problem between the Test Bot host and the machine hosting the Win9x VMs. The Win98SE VM getting stuck in the "reverting" state is the cause of the problems, nothing to do with your patch. > Anyways, I'm hoping that somebody in charge of the test bot might be able to > fix the traffic jam it's causing. It's back up and running again, trying to catch up. Ge.

Aug. 20, 2010

CVS gateway down for good

by Alexandre Julliard

Folks, The git->CVS gateway broke again, so I'm going to pull the plug on it. It doesn't make sense for me to spend more time fixing something that sees so little usage at this point. If you are still using CVS, you'll have to switch to git (or volunteer to host the gateway yourself...) Sorry about the inconvenience. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2010

Re: The Test Bot seems to be having issues

by Thomas Mullaly

On Fri, Aug 20, 2010 at 4:44 AM, GOUJON Alexandre <ale.goujon(a)gmail.com>wrote: > > It's Grep Geldorp but wine-devel is a good place too. > Thanks, hopefully he notices the thread. > There are some <div> and </div> in your patch. > Anyway, the bot applied your patch successfully and began to run some of > your tests. > Hmm... All my patches (coming through wine-patches) seem to end up with those <div> tags in them, but, they've never caused problems. > Now, the only thing to do is waiting... > At this point I would be surprised if the Test bot started randomly working without any assistance. The job has been in the "running" state for 24+ hours already, without any progress being made. -- Thomas Mullaly thomas.mullaly(a)gmail.com

Aug. 20, 2010

Re: user32/dialog.c: GetNextDlgTabItem returns hwndDlg if it does not contain controls. [try 2]

by Alexandre Julliard

"Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > GetNextDlgTabItem returns hwndDlg if it does not contain controls and > searching next item. > GetNextDlgTabItem returns the first child if next TABSTOP control not > found. > > And returns 0 in both cases if searching prev item It breaks the tests: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so propsheet.c && touch propsheet.ok propsheet.c:312: Test failed: Focus should have been set to the Next button. Expected: 12324, Found: 65535 propsheet.c:363: Test failed: Focus should have been set to the Next button. Expected: 12324, Found: 65535 make[1]: *** [propsheet.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2010

Re: [PATCH] gdi32/enhmfdrv: Do not leak a HDC

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > --- > dlls/gdi32/enhmfdrv/init.c | 14 ++++++++------ > 1 files changed, 8 insertions(+), 6 deletions(-) It would be cleaner to move the CreateDCW call where it's needed. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2010

Re: cmd: Improved a FIXME in WCMD_filesize64

by Alexandre Julliard

"Konrad Wartke" <kwartke(a)googlemail.com> writes: > cmd: Improved a FIXME in WCMD_filesize64 by using a better algorithm. It's not much better. Anyway, this should be done by using one of the existing formatting functions, maybe VarFormatNumber. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2010

Re: [PATCH 7/8] msvcp90/tests: Added basic_string<char> tests

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -0,0 +1,30 @@ > +/* > + * Copyright 2010 Piotr Caban for CodeWeavers > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +/* basic_string<char, char_traits<char>, allocator<char>> */ > +#define BUF_SIZE_CHAR 16 > +typedef struct _basic_string_char > +{ > + void *allocator; > + union _data { > + char buf[BUF_SIZE_CHAR]; > + char *ptr; > + } data; > + size_t size; > + size_t res; > +} basic_string_char; Unless there's going to be a ton of definitions in there used by many different files, it's better to put that sort of thing directly in the C file to make it easier to build stand-alone. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2010

Re: The Test Bot seems to be having issues

by GOUJON Alexandre

On 08/19/2010 07:56 PM, Thomas Mullaly wrote: > First off, I'm not sure who should be contacted about this It's Grep Geldorp but wine-devel is a good place too. > , but, it appears that the test bot has got itself stuck while trying > to run tests on a patch submitted last night. The job in question is > here [1], it's been over 12 hours since any progress has been made on > it and no other submissions have run since then. Also, the Windows > 98SE has been "reverting" this whole time, so I'm not sure if this is > the culprit or not. There are some <div> and </div> in your patch. Anyway, the bot applied your patch successfully and began to run some of your tests. Now, the only thing to do is waiting...

Aug. 20, 2010

Re: gdi32: Properly set ERROR_NOACCESS when GetObject receives invalid arguments

by Jerome Leclanche

That's what I was going for originally, but AJ on IRC deemed it not necessary. J. Leclanche On Fri, Aug 20, 2010 at 12:27 AM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > On Thu, Aug 19, 2010 at 4:56 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: >> Broken programs will crash on wine if they, for example, pass >> arguments to GetObject in the wrong order. >> This fixes bug #18864. > >> + if (buffer && ((ULONG_PTR)buffer >> 16) == 0) > > Wouldn't a __TRY ... __EXCEPT_PAGE_FAULT be better / safer? > > Octavian > > >

Aug. 19, 2010

Re: gdi32: Properly set ERROR_NOACCESS when GetObject receives invalid arguments

by Octavian Voicu

On Thu, Aug 19, 2010 at 4:56 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > Broken programs will crash on wine if they, for example, pass > arguments to GetObject in the wrong order. > This fixes bug #18864. > + if (buffer && ((ULONG_PTR)buffer >> 16) == 0) Wouldn't a __TRY ... __EXCEPT_PAGE_FAULT be better / safer? Octavian

Aug. 19, 2010

Re: PDB files generated by Intel C++ Compiler

by Eric Pouech

Le 19/08/2010 19:36, Peter Urbanec a écrit : > > I have some x64 binaries and associated PDBs that have been generated > using Intel C++ Compiler 11.1. These PDBs cause issues such as this: > > 1 0x00000000781cc1ba in msvcr80 (+0x9c1b9) (0x00007ff047a4c840) > fixme:dbghelp_msc:codeview_fetch_type Cannot locate type 670 > err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading > symbols > 2 0x000000006189a00d in lua5.1 (+0xa00c) (0x00007ff047a4c840) > > > Now, from a quick look at mscvpdb.h, it looks like these PDBs contain > datatypes with 64-bit near pointers, however wine does not seem to > understand this mode. How would one go about adding support for this > type of PDB? I actually don't have access to the Intel C++ Compiler to > do much testing. :-( > > > > > if the near 64bit pointer, is a 64bit pointer, that's trivial, just add the needed types to dlls/dbghelp/msc.c and include/dbghelp.h with things like: cv_basic_types[T_64PVOID] = cv_basic_types[T_PVOID]; .... if it's something else, then that's another issue... A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Aug. 19, 2010

The Test Bot seems to be having issues

by Thomas Mullaly

Hi all, First off, I'm not sure who should be contacted about this, but, it appears that the test bot has got itself stuck while trying to run tests on a patch submitted last night. The job in question is here [1], it's been over 12 hours since any progress has been made on it and no other submissions have run since then. Also, the Windows 98SE has been "reverting" this whole time, so I'm not sure if this is the culprit or not. I also hate to admit that the job in question is from one of my patches I sent in last night (although I'm pretty sure it doesn't have anything to do with the quality of the code in the patch ;-) ). Anyways, I'm hoping that somebody in charge of the test bot might be able to fix the traffic jam it's causing. [1] https://testbot.winehq.org/JobDetails.pl?Key=4570 <https://testbot.winehq.org/JobDetails.pl?Key=4570> -- Thomas Mullaly thomas.mullaly(a)gmail.com

Aug. 19, 2010

PDB files generated by Intel C++ Compiler

by Peter Urbanec

I have some x64 binaries and associated PDBs that have been generated using Intel C++ Compiler 11.1. These PDBs cause issues such as this: 1 0x00000000781cc1ba in msvcr80 (+0x9c1b9) (0x00007ff047a4c840) fixme:dbghelp_msc:codeview_fetch_type Cannot locate type 670 err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 2 0x000000006189a00d in lua5.1 (+0xa00c) (0x00007ff047a4c840) Now, from a quick look at mscvpdb.h, it looks like these PDBs contain datatypes with 64-bit near pointers, however wine does not seem to understand this mode. How would one go about adding support for this type of PDB? I actually don't have access to the Intel C++ Compiler to do much testing. :-(

Aug. 19, 2010

Re: winepath bug without arguments?

by Austin English

On Mon, Aug 9, 2010 at 5:41 AM, Paul Chitescu <paulc(a)voip.null.ro> wrote: > On Monday 09 August 2010 01:23:24 pm Jerome Leclanche wrote: >> Hi >> >> After fixing a bug in MPQEdit related to opening directories, I >> noticed winepath returns a different result with and without quotes: >> >> adys(a)azura:~/.wine/drive_c$ winepath -w >> adys(a)azura:~/.wine/drive_c$ winepath -w "" >> C:\ >> >> With quotes it returns the current directory. Is that intended? If not >> I'll open a bug... >> >> >> >> J. Leclanche > > Yes, it's intended. winepath converts zero or more arguments. An empty > argument means "start from current dir... and print!" > > [paulc(a)bussard drive_c]$ winepath -w "" users "Program Files" > C:\ > C:\users > C:\Program Files Then it seems there's still a bug: austin(a)midna:~$ winepath -w ; echo $? 0 either a path should be returned or a non-zero status... -- -Austin

Aug. 19, 2010

Re: [01/11] d3dx10: Add stub for d3dx10_43

by Owen Rudge

> At least with all d3dx10 DLLs released so far, D3D10_SDK_VERSION has not > changed. Obviously, if it does change in the future, we will need to > accommodate that in new DLLs. Although I suppose we could hard-code the SDK version into the DLLs now, rather than having to change it later, which I guess is what you were getting at, Henri. I'm not too convinced Microsoft is likely to change it during the D3D10 lifecycle, but I guess it doesn't hurt to be safe. Cheers, -- Owen Rudge http://www.owenrudge.net/

Aug. 19, 2010

Re: [01/11] d3dx10: Add stub for d3dx10_43

by Owen Rudge

> Is it really safe to assume D3D10_SDK_VERSION will always keep the > same value? (I know d3dx9 does it as well.) For d3d9 the SDK version > changed between d3d9b and d3d9c, for example. At least with all d3dx10 DLLs released so far, D3D10_SDK_VERSION has not changed. Obviously, if it does change in the future, we will need to accommodate that in new DLLs. -- Owen Rudge http://www.owenrudge.net/

Aug. 19, 2010

Re: [PATCH 3/5] ddraw/tests: New CreateSurface for 3D DDSCAPS_BACKBUFFER tests. (try 5, resend)

by Stefan Dösinger

Hi, Can you try to create a d3d device with this surface? In the first d3d version this works by querying the d3d device ID from the surface. Patch 4 looks OK. Thank you for your persistence with the patches by the way! Cheers, Stefan Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/d3d.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 82 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c > index 53ef04b..a83b0d5 100644 > --- a/dlls/ddraw/tests/d3d.c > +++ b/dlls/ddraw/tests/d3d.c > @@ -3536,6 +3536,87 @@ static void FindDevice(void) > "Expected IDirect3D1::FindDevice to return D3D_OK, got 0x%08x\n", hr); > } > > +static void BackBuffer3DCreateSurfaceTest(void) > +{ > + DDSURFACEDESC ddsd; > + DDSURFACEDESC created_ddsd; > + DDSURFACEDESC2 ddsd2; > + IDirectDrawSurface *surf; > + IDirectDrawSurface4 *surf4; > + IDirectDrawSurface7 *surf7; > + HRESULT hr; > + IDirectDraw2 *dd2; > + IDirectDraw4 *dd4; > + IDirectDraw7 *dd7; > + DDCAPS ddcaps; > + > + const DWORD caps = DDSCAPS_BACKBUFFER | DDSCAPS_3DDEVICE; > + const DWORD expected_caps = DDSCAPS_BACKBUFFER | DDSCAPS_3DDEVICE | DDSCAPS_VIDEOMEMORY | DDSCAPS_LOCALVIDMEM; > + > + memset(&ddcaps, 0, sizeof(ddcaps)); > + ddcaps.dwSize = sizeof(DDCAPS); > + hr = IDirectDraw_GetCaps(DirectDraw1, &ddcaps, NULL); > + if (!(ddcaps.ddsCaps.dwCaps & DDSCAPS_VIDEOMEMORY)) > + { > + skip("DDraw reported no VIDEOMEMORY cap. Broken video driver? Skipping surface caps tests.\n"); > + return ; > + } > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd.dwWidth = 64; > + ddsd.dwHeight = 64; > + ddsd.ddsCaps.dwCaps = caps; > + memset(&ddsd2, 0, sizeof(ddsd2)); > + ddsd2.dwSize = sizeof(ddsd2); > + ddsd2.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd2.dwWidth = 64; > + ddsd2.dwHeight = 64; > + ddsd2.ddsCaps.dwCaps = caps; > + memset(&created_ddsd, 0, sizeof(created_ddsd)); > + created_ddsd.dwSize = sizeof(DDSURFACEDESC); > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &surf, NULL); > + todo_wine ok(SUCCEEDED(hr), "IDirectDraw_CreateSurface failed: 0x%08x\n", hr); > + if (surf != NULL) > + { > + hr = IDirectDrawSurface_GetSurfaceDesc(surf, &created_ddsd); > + ok(SUCCEEDED(hr), "IDirectDraw_GetSurfaceDesc failed: 0x%08x\n", hr); > + todo_wine ok(created_ddsd.ddsCaps.dwCaps == expected_caps, > + "GetSurfaceDesc returned caps %x, expected %x\n", created_ddsd.ddsCaps.dwCaps, > + expected_caps); > + IDirectDrawSurface_Release(surf); > + } > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw2, (void **) &dd2); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd, &surf, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw2_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw2_Release(dd2); > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw4, (void **) &dd4); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2, &surf4, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw4_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw4_Release(dd4); > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw7, (void **) &dd7); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2, &surf7, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw7_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw7_Release(dd7); > +} > + > START_TEST(d3d) > { > init_function_pointers(); > @@ -3571,6 +3652,7 @@ START_TEST(d3d) > TextureLoadTest(); > ViewportTest(); > FindDevice(); > + BackBuffer3DCreateSurfaceTest(); > D3D1_releaseObjects(); > } > > -- > 1.7.2 > > >

Aug. 19, 2010

Re: user32/dialog.c: GetNextDlgTabItem returns hwndDlg if it does not contain controls.

by Alexandre Julliard

"Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > @@ -1695,7 +1696,19 @@ HWND WINAPI GetNextDlgTabItem( HWND hwndDlg, HWND hwndCtrl, > */ > if (!hwndCtrl && fPrevious) return 0; > > - return DIALOG_GetNextTabItem(hwndDlg,hwndDlg,hwndCtrl,fPrevious); > + nextItem = DIALOG_GetNextTabItem(hwndDlg,hwndDlg,hwndCtrl,fPrevious); > + > + /* if next tab item not found return the first child even if it does not have TABSTOP > + Checked on XP > + */ > + if (!nextItem && !fPrevious) nextItem = GetWindow(hwndDlg,GW_CHILD); > + > + /* if there is no controls on hwndDlg return hwndDlg > + Checked on XP > + */ > + if (!nextItem && !fPrevious) nextItem = hwndDlg; > + > + return nextItem; You should test the fPrevious case too, it's probably similar. -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2010

Re: oleau32: Use correct sysking in QueryPathOfRegTypeLib.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/oleaut32/typelib.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) It breaks the 64-bit tests: ../../../../wine/tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so ../../../../wine/dlls/oleaut32/tests/typelib.c && touch typelib.ok typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.0) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.1) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.22) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.37) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.40) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(65535.65535) returned 8002801d make: *** [typelib.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2010

Re: [PATCH 2/5] ddraw/tests: New visual back buffer flipping tests. (try 5, resend)

by Stefan Dösinger

This test contains a C++ comment, please remove it. Otherwise it looks ok, as does patch 1 Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/visual.c | 123 +++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 123 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/visual.c b/dlls/ddraw/tests/visual.c > index 290cb76..aecc2ab 100644 > --- a/dlls/ddraw/tests/visual.c > +++ b/dlls/ddraw/tests/visual.c > @@ -2920,6 +2920,128 @@ static void depth_clamp_test(IDirect3DDevice7 *device) > ok(SUCCEEDED(hr), "SetViewport failed, hr %#x.\n", hr); > } > > +static void DX1_BackBufferFlipTest(void) > +{ > + HRESULT hr; > + int ret; > + IDirectDraw *DirectDraw1 = NULL; > + IDirectDrawSurface *Primary = NULL; > + IDirectDrawSurface *Backbuffer = NULL; > + WNDCLASS wc = {0}; > + DDSURFACEDESC ddsd; > + DDBLTFX ddbltfx; > + COLORREF color; > + const DWORD white = 0xffffff; > + const DWORD red = 0xff0000; > + BOOL attached = FALSE; > + > + wc.lpfnWndProc = DefWindowProc; > + wc.lpszClassName = "DX1_BackBufferFlipTest_wc"; > + RegisterClass(&wc); > + window = CreateWindow("DX1_BackBufferFlipTest_wc", "DX1_BackBufferFlipTest", > + WS_MAXIMIZE | WS_VISIBLE | WS_CAPTION , 0, 0, 640, 480, 0, 0, 0, 0); > + > + hr = DirectDrawCreate( NULL, &DirectDraw1, NULL ); > + ok(hr==DD_OK || hr==DDERR_NODIRECTDRAWSUPPORT, "DirectDrawCreate returned: %x\n", hr); > + if(FAILED(hr)) goto out; > + > + hr = IDirectDraw_SetCooperativeLevel(DirectDraw1, window, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN); > + ok(hr==DD_OK, "SetCooperativeLevel returned: %x\n", hr); > + if(FAILED(hr)) goto out; > + > + hr = IDirectDraw_SetDisplayMode(DirectDraw1, 640, 480, 32); > + if(FAILED(hr)) { > + /* 24 bit is fine too */ > + hr = IDirectDraw_SetDisplayMode(DirectDraw1, 640, 480, 24); > + } > + ok(hr==DD_OK || hr == DDERR_UNSUPPORTED, "SetDisplayMode returned: %x\n", hr); > + if (FAILED(hr)) { > + goto out; > + } > + > + memset(&ddsd, 0, sizeof(DDSURFACEDESC)); > + ddsd.dwSize = sizeof(DDSURFACEDESC); > + ddsd.dwFlags = DDSD_CAPS; > + ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &Primary, NULL); > + ok(hr==DD_OK, "IDirectDraw_CreateSurface returned: %08x\n", hr); > + > + memset(&ddsd, 0, sizeof(DDSURFACEDESC)); > + ddsd.dwSize = sizeof(DDSURFACEDESC); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | DDSD_PIXELFORMAT; > + ddsd.ddsCaps.dwCaps = DDSCAPS_BACKBUFFER; > + ddsd.dwWidth = 640; > + ddsd.dwHeight = 480; > + ddsd.ddpfPixelFormat.dwSize = sizeof(ddsd.ddpfPixelFormat); > + ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB; > + U1(ddsd.ddpfPixelFormat).dwRGBBitCount = 32; > + U2(ddsd.ddpfPixelFormat).dwRBitMask = 0x00ff0000; > + U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x0000ff00; > + U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x000000ff; > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &Backbuffer, NULL); > + todo_wine ok(hr==DD_OK, "IDirectDraw_CreateSurface returned: %08x\n", hr); > + if(FAILED(hr)) goto out; > + > + hr = IDirectDrawSurface_AddAttachedSurface(Primary, Backbuffer); > + todo_wine ok(hr == DD_OK || broken(hr == DDERR_CANNOTATTACHSURFACE), > + "Attaching a back buffer to a front buffer returned %08x\n", hr); > + if (FAILED(hr)) goto out; > + > + attached = TRUE; > + > + memset(&ddbltfx, 0, sizeof(ddbltfx)); > + ddbltfx.dwSize = sizeof(ddbltfx); > + U5(ddbltfx).dwFillColor = red; > + hr = IDirectDrawSurface_Blt(Backbuffer, NULL, NULL, NULL, DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx); > + ok(hr == DD_OK, "IDirectDrawSurface_Blt returned: %x\n", hr); > + > + U5(ddbltfx).dwFillColor = white; > + hr = IDirectDrawSurface_Blt(Primary, NULL, NULL, NULL, DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx); > + ok(hr == DD_OK, "IDirectDrawSurface_Blt returned: %x\n", hr); > + > + // Check it out > + color = getPixelColor_GDI(Primary, 5, 5); > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && GetBValue(color) == 0xFF, > + "got R %02X G %02X B %02X, expected R FF G FF B FF\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + > + color = getPixelColor_GDI(Backbuffer, 5, 5); > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0, > + "got R %02X G %02X B %02X, expected R FF G 00 B 00\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + > + hr = IDirectDrawSurface_Flip(Primary, NULL, DDFLIP_WAIT); > + todo_wine ok(hr == DD_OK, "IDirectDrawSurface_Flip returned 0x%08x\n", hr); > + > + if (hr == DD_OK) > + { > + color = getPixelColor_GDI(Primary, 5, 5); > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0, > + "got R %02X G %02X B %02X, expected R FF G 00 B 00\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + > + color = getPixelColor_GDI(Backbuffer, 5, 5); > + ok((GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && GetBValue(color) == 0xFF) || > + broken(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0), // broken driver > + "got R %02X G %02X B %02X, expected R FF G FF B FF\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + } > + > + out: > + > + if (Backbuffer) > + { > + if (attached) > + IDirectDrawSurface_DeleteAttachedSurface(Primary, 0, Backbuffer); > + IDirectDrawSurface_Release(Backbuffer); > + } > + if (Primary) IDirectDrawSurface_Release(Primary); > + if (DirectDraw1) IDirectDraw_Release(DirectDraw1); > + if (window) DestroyWindow(window); > +} > + > START_TEST(visual) > { > HRESULT hr; > @@ -2983,6 +3105,7 @@ START_TEST(visual) > > D3D3_ViewportClearTest(); > p8_primary_test(); > + DX1_BackBufferFlipTest(); > > return ; > > -- > 1.7.2 > > >

Aug. 19, 2010

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5, resend)

by Stefan Dösinger

Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > + if(DDSD->ddsCaps.dwCaps & DDSCAPS_FRONTBUFFER) { > + WARN("Application tried to create an explicit front buffer\n"); > LeaveCriticalSection(&ddraw_cs); > return DDERR_INVALIDCAPS; > } This test seems redundant now. The ddraw1 thunk removes the flag, and all other thunks check for the frontbuffer flag on their own.

Aug. 19, 2010

Re: [01/11] d3dx10: Add stub for d3dx10_43

by Henri Verbeet

On 18 August 2010 23:01, Owen Rudge <orudge(a)codeweavers.com> wrote: > +BOOL WINAPI D3DX10CheckVersion(UINT d3dsdkvers, UINT d3dxsdkvers) > +{ > + if ((d3dsdkvers == D3D10_SDK_VERSION) && (d3dxsdkvers == 43)) > + return TRUE; > + > + return FALSE; > +} Is it really safe to assume D3D10_SDK_VERSION will always keep the same value? (I know d3dx9 does it as well.) For d3d9 the SDK version changed between d3d9b and d3d9c, for example.

Aug. 19, 2010

Re: have all MCI tests in winmm/tests/ or distributed across mci*/tests/?

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > although my patch creates mcicda/tests/ > I'd like to query whether it would make more > sense to have all mci tests grouped in winmm/tests/. That's probably better, yes. -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2010

Re: [1/2] user32: add a way to poll for messages on extra handles

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > diff --git a/dlls/user32/driver.c b/dlls/user32/driver.c > index f2f9892..05c83d4 100644 > --- a/dlls/user32/driver.c > +++ b/dlls/user32/driver.c > @@ -126,6 +126,7 @@ static const USER_DRIVER *load_driver(void) > GET_USER_FUNC(WindowMessage); > GET_USER_FUNC(WindowPosChanging); > GET_USER_FUNC(WindowPosChanged); > + GET_USER_FUNC(GetExtraMessageHandles); That's ugly, it doesn't correspond to anything in the Windows API. -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2010

Re: [PATCH 2/2] ntdll/tests: Add tests for RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 4]

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > + ok( (res == (void *)~0) || > + broken(res == (NULL + len)), /* XP and w2003 */ You can't do that. -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2010

Re: msvideo: Forward MCIWndCreate16 to MCIWndCreateA (2nd)

by Alexandre Julliard

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > + HINSTANCE hinst32; > + if (hinst16 == GetModuleHandle16("msvideo.dll")) > + hinst32 = GetModuleHandleA("msvfw32.dll"); > + else > + hinst32 = HINSTANCE_32(GetExePtr( hinst16 )); This doesn't seem right. Why do you need this? -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2010

Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.

by Austin Lund

On 19 August 2010 16:34, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On Thu, Aug 19, 2010 at 9:50 AM, Austin Lund <austin.lund(a)gmail.com> wrote: >> http://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx > > Hi, Austin. > > This information is outdated probably. There's a message to set a > calendar for MonthCal at least, see: > > http://msdn.microsoft.com/en-us/library/bb760995%28VS.85%29.aspx > > Not sure about DateTimePicker, it uses Monthcal internally so a > calendar could still be switched. > Anyway this won't work on pre-Vista and without a manifest for v6, but > you could enable tests using V6 loading > helpers that we have already and MCM_SETCALID message, so tests will > run on Arabic or some Asian boxes. > I don't understand what you are suggesting exactly. Is it that the CALID of the MonthCal be set to the locale CALID or to set it to the Gregorian CALID? Either way I don't see how it helps as the problem is with the control of functions like GetDateFormat to choose a CALID which matches the one which the controls falls back on when the locale has a non-Gregorian calendar (something I haven't figured out).

Aug. 19, 2010

Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.

by Nikolay Sivov

On Thu, Aug 19, 2010 at 9:50 AM, Austin Lund <austin.lund(a)gmail.com> wrote: > http://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx Hi, Austin. This information is outdated probably. There's a message to set a calendar for MonthCal at least, see: http://msdn.microsoft.com/en-us/library/bb760995%28VS.85%29.aspx Not sure about DateTimePicker, it uses Monthcal internally so a calendar could still be switched. Anyway this won't work on pre-Vista and without a manifest for v6, but you could enable tests using V6 loading helpers that we have already and MCM_SETCALID message, so tests will run on Arabic or some Asian boxes.

Aug. 19, 2010

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5, resend)

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4557 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:1619: Test failed: Got color 000a246a, expected 00ff0040 or near visual.c:1625: Test failed: Got color 006b8bbd, expected 00ff0080 or near === W98SE (32 bit dsurface) === No test summary line found

Aug. 19, 2010

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5, resend)

by testbot＠testbot.winehq.org

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

Aug. 19, 2010

Re: [PATCH 2/2] gameux/tests: verifying registry values created by GameExplorer (try 2)

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4552 Your paranoid android. === W98SE (32 bit gameexplorer) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit gameexplorer) === Timeout === WXPPROSP3 (32 bit gameexplorer) === Timeout

Aug. 19, 2010

Re: ntdll: IMAGE_REL_BASED_HIGH, IMAGE_REL_BASED_HIGH and IMAGE_REL_BASED_HIGHLOW are supported on win64.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4548 Your paranoid android. === W98SE (32 bit rtl) === Failure running script in VM: Exceeded timeout limit of 315 sec

Aug. 19, 2010

Re: dlls/d3dx9_36/bytecodewriter.c oddity

by Matteo Bruni

2010/8/18 Gerald Pfeifer <gerald(a)pfeifer.com>: > Metteo et al, > > I noticed d3dx9_36/bytecodewriter.c can be simplified as follows, but > somewhat tells me this may rather point out a problem somewhere in that > code, so I am not sending this to wine-patches. > > (The only functional difference should be the missing WARN in some cases, > and I could restore that if desired, but...see above.) > > Thoughts? Guidance? > > Gerald > > > diff --git a/dlls/d3dx9_36/bytecodewriter.c > b/dlls/d3dx9_36/bytecodewriter.c > index 07f96e7..e7bd8a5 100644 > --- a/dlls/d3dx9_36/bytecodewriter.c > +++ b/dlls/d3dx9_36/bytecodewriter.c > @@ -1035,7 +1035,7 @@ static const struct bytecode_backend vs_1_x_backend = { > static void instr_ps_1_0123_texld(struct bc_writer *This, > const struct instruction *instr, > struct bytecode_buffer *buffer) { > - DWORD idx, srcidx; > + DWORD idx; > struct shader_reg reg; > DWORD swizzlemask; > > @@ -1074,17 +1074,6 @@ static void instr_ps_1_0123_texld(struct bc_writer *This, > /* map the temp dstreg to the ps_1_3 texture temporary register */ > This->funcs->dstreg(This, &instr->dst, buffer, instr->shift, instr->dstmod); > } else if(instr->src[0].type == BWRITERSPR_TEMP) { > - if(instr->src[0].regnum == T0_REG) { > - srcidx = 0; > - } else if(instr->src[0].regnum == T1_REG) { > - srcidx = 1; > - } else if(instr->src[0].regnum == T2_REG) { > - srcidx = 2; > - } else if(instr->src[0].regnum == T3_REG) { > - srcidx = 3; > - } else { > - WARN("Invalid address data source register r%u\n", instr->src[0].regnum); > - } > > swizzlemask = (3 << BWRITERVS_SWIZZLE_SHIFT) | > (3 << (BWRITERVS_SWIZZLE_SHIFT + 2)) | > Hmm, so srcidx is unused. Yes, that piece of code is useless now, it's a remnant of an older version of that function where the source register was handled by some ad-hoc code, which I since then replaced with a call to the generic This->funcs->srcreg(). The function is correct otherwise, there are some tests to confirm that. In my opinion you can send the patch as is. Alternatively you can replace that piece of code with just a check for instr->src[0].regnum != T[0123]_REG, to keep the WARN, but it's not worth the effort probably. Thanks!

Aug. 18, 2010

dlls/d3dx9_36/bytecodewriter.c oddity

by Gerald Pfeifer

Metteo et al, I noticed d3dx9_36/bytecodewriter.c can be simplified as follows, but somewhat tells me this may rather point out a problem somewhere in that code, so I am not sending this to wine-patches. (The only functional difference should be the missing WARN in some cases, and I could restore that if desired, but...see above.) Thoughts? Guidance? Gerald diff --git a/dlls/d3dx9_36/bytecodewriter.c b/dlls/d3dx9_36/bytecodewriter.c index 07f96e7..e7bd8a5 100644 --- a/dlls/d3dx9_36/bytecodewriter.c +++ b/dlls/d3dx9_36/bytecodewriter.c @@ -1035,7 +1035,7 @@ static const struct bytecode_backend vs_1_x_backend = { static void instr_ps_1_0123_texld(struct bc_writer *This, const struct instruction *instr, struct bytecode_buffer *buffer) { - DWORD idx, srcidx; + DWORD idx; struct shader_reg reg; DWORD swizzlemask; @@ -1074,17 +1074,6 @@ static void instr_ps_1_0123_texld(struct bc_writer *This, /* map the temp dstreg to the ps_1_3 texture temporary register */ This->funcs->dstreg(This, &instr->dst, buffer, instr->shift, instr->dstmod); } else if(instr->src[0].type == BWRITERSPR_TEMP) { - if(instr->src[0].regnum == T0_REG) { - srcidx = 0; - } else if(instr->src[0].regnum == T1_REG) { - srcidx = 1; - } else if(instr->src[0].regnum == T2_REG) { - srcidx = 2; - } else if(instr->src[0].regnum == T3_REG) { - srcidx = 3; - } else { - WARN("Invalid address data source register r%u\n", instr->src[0].regnum); - } swizzlemask = (3 << BWRITERVS_SWIZZLE_SHIFT) | (3 << (BWRITERVS_SWIZZLE_SHIFT + 2)) |

Aug. 18, 2010