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

Re: [PATCH 1/6] ole32: Added IExternalConnection support.
by Alexandre Julliard 03 May '13

03 May '13

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/ole32/compobj_private.h | 2 ++ > dlls/ole32/stubmanager.c | 16 ++++++++++++++++ > 2 files changed, 18 insertions(+) It doesn't work here: ../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so defaulthandler.c && touch defaulthandler.ok defaulthandler.c:189: Test failed: unexpected interface: {00000019-0000-0000-C000-000000000046} make: *** [defaulthandler.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] d3dcompiler: Add a LUT to find compilation targets info.
by Matteo Bruni 03 May '13

03 May '13

2013/5/2 Christian Costa <titan.costa(a)gmail.com>: > > --- > dlls/d3dcompiler_43/compiler.c | 101 +++++++++++++++++++++++------ > dlls/d3dcompiler_43/d3dcompiler_private.h | 1 > 2 files changed, 81 insertions(+), 21 deletions(-) > > diff --git a/dlls/d3dcompiler_43/compiler.c b/dlls/d3dcompiler_43/compiler.c > index 4942985..a6a9867 100644 > --- a/dlls/d3dcompiler_43/compiler.c > +++ b/dlls/d3dcompiler_43/compiler.c > @@ -490,6 +490,66 @@ HRESULT WINAPI D3DAssemble(const void *data, SIZE_T datasize, const char *filena > return hr; > } > > +struct { Please make it static const. > + const char *name; > + enum shader_type type; > + DWORD sm_major; > + DWORD sm_minor; > + DWORD level_major; > + DWORD level_minor; > + BOOL sw; > + BOOL support; > +} targets_info[] = { > + /* SM 1 */ > + { "vs_1_0", ST_VERTEX, 1, 0, 0, 0, FALSE, TRUE }, > + { "vs_1_1", ST_VERTEX, 1, 1, 0, 0, FALSE, TRUE }, > + { "ps_1_0", ST_PIXEL, 1, 0, 0, 0, FALSE, TRUE }, > + { "ps_1_1", ST_PIXEL, 1, 1, 0, 0, FALSE, FALSE }, > + { "ps_1_2", ST_PIXEL, 1, 2, 0, 0, FALSE, FALSE }, > + { "ps_1_3", ST_PIXEL, 1, 3, 0, 0, FALSE, FALSE }, > + { "ps_1_4", ST_PIXEL, 1, 4, 0, 0, FALSE, FALSE }, > + { "tx_1_0", ST_UNKNOWN, 1, 0, 0, 0, FALSE, FALSE }, > + /* SM 2 */ > + { "vs_2_0", ST_VERTEX, 2, 0, 0, 0, FALSE, TRUE }, > + { "vs_2_a", ST_VERTEX, 2, 1, 0, 0, FALSE, FALSE }, > + { "vs_2_sw", ST_VERTEX, 2, 0, 0, 0, TRUE, FALSE }, > + { "ps_2_0", ST_PIXEL, 2, 0, 0, 0, FALSE, TRUE }, > + { "ps_2_a", ST_PIXEL, 2, 1, 0, 0, FALSE, FALSE }, > + { "ps_2_b", ST_PIXEL, 2, 2, 0, 0, FALSE, FALSE }, > + { "ps_2_sw", ST_PIXEL, 2, 0, 0, 0, TRUE, FALSE }, > + { "fx_2_0", ST_UNKNOWN, 2, 0, 0, 0, FALSE, FALSE }, > + /* SM 3 */ > + { "vs_3_0", ST_VERTEX, 3, 0, 0, 0, FALSE, TRUE }, > + { "vs_3_sw", ST_VERTEX, 3, 0, 0, 0, TRUE, FALSE }, > + { "ps_3_0", ST_PIXEL, 3, 0, 0, 0, FALSE, TRUE }, > + { "ps_3_sw", ST_PIXEL, 3, 0, 0, 0, TRUE, FALSE }, > + /* SM 4 */ > + { "vs_4_0_level_9_0", ST_VERTEX, 4, 0, 9, 0, FALSE, FALSE }, > + { "vs_4_0_level_9_1", ST_VERTEX, 4, 0, 9, 1, FALSE, FALSE }, > + { "vs_4_0_level_9_3", ST_VERTEX, 4, 0, 9, 3, FALSE, FALSE }, > + { "vs_4_0", ST_VERTEX, 4, 0, 0, 0, FALSE, TRUE }, > + { "vs_4_1", ST_VERTEX, 4, 1, 0, 0, FALSE, TRUE }, > + { "ps_4_0_level_9_0", ST_PIXEL, 4, 0, 9, 0, FALSE, FALSE }, > + { "ps_4_0_level_9_1", ST_PIXEL, 4, 0, 9, 1, FALSE, FALSE }, > + { "ps_4_0_level_9_3", ST_PIXEL, 4, 0, 9, 3, FALSE, FALSE }, > + { "ps_4_0", ST_PIXEL, 4, 0, 0, 0, FALSE, TRUE }, > + { "ps_4_1", ST_PIXEL, 4, 1, 0, 0, FALSE, TRUE }, > + { "gs_4_0", ST_UNKNOWN, 4, 0, 0, 0, FALSE, FALSE }, > + { "gs_4_1", ST_UNKNOWN, 4, 1, 0, 0, FALSE, FALSE }, > + { "cs_4_0", ST_UNKNOWN, 4, 0, 0, 0, FALSE, FALSE }, > + { "cs_4_1", ST_UNKNOWN, 4, 1, 0, 0, FALSE, FALSE }, > + { "fx_4_0", ST_UNKNOWN, 4, 0, 0, 0, FALSE, FALSE }, > + { "fx_4_1", ST_UNKNOWN, 4, 1, 0, 0, FALSE, FALSE }, > + /* SM 5 */ > + { "vs_5_0", ST_VERTEX, 5, 0, 0, 0, FALSE, TRUE }, > + { "ps_5_0", ST_PIXEL, 5, 0, 0, 0, FALSE, TRUE }, > + { "hs_5_0", ST_UNKNOWN, 5, 0, 0, 0, FALSE, FALSE }, > + { "gs_5_0", ST_UNKNOWN, 5, 0, 0, 0, FALSE, FALSE }, > + { "ds_5_0", ST_UNKNOWN, 5, 0, 0, 0, FALSE, FALSE }, > + { "cs_5_0", ST_UNKNOWN, 5, 0, 0, 0, FALSE, FALSE }, > + { "fx_5_0", ST_UNKNOWN, 5, 0, 0, 0, FALSE, FALSE }, > +}; > + > static HRESULT compile_shader(const char *preproc_shader, const char *target, const char *entrypoint, > ID3DBlob **shader_blob, ID3DBlob **error_messages) > { > @@ -500,38 +560,37 @@ static HRESULT compile_shader(const char *preproc_shader, const char *target, co > ID3DBlob *buffer; > char *pos; > enum shader_type shader_type; > + ULONG i; > + ULONG nb = sizeof(targets_info) / sizeof(targets_info[0]); > > TRACE("Preprocessed shader source: %s\n", debugstr_a(preproc_shader)); > > TRACE("Parsing compilation target %s.\n", debugstr_a(target)); > - if (strlen(target) != 6 || target[1] != 's' || target[2] != '_' || target[4] != '_') > + for (i = 0; i < nb; i++) > { > - FIXME("Unknown compilation target %s.\n", debugstr_a(target)); > - return D3DERR_INVALIDCALL; > + if (!strcmp(target, targets_info[i].name)) > + { > + if (!targets_info[i].support) > + { > + FIXME("Compilation target %s not yet supported\n", debugstr_a(target)); > + return D3DERR_INVALIDCALL; > + } > + else > + { > + shader_type = targets_info[i].type; > + major = targets_info[i].sm_major; > + minor = targets_info[i].sm_minor; > + break; > + } > + } > } > > - if (target[0] == 'v') > - shader_type = ST_VERTEX; > - else if (target[0] == 'p') > - shader_type = ST_PIXEL; > - else > + if (i == nb) > { > - FIXME("Unsupported shader target type %s.\n", debugstr_a(target)); > + FIXME("Unknown compilation target %s\n", debugstr_a(target)); > return D3DERR_INVALIDCALL; > } > > - major = target[3] - '0'; > - if (major == 0 || major > 5) > - { > - FIXME("Unsupported shader target major version %d.\n", major); > - return D3DERR_INVALIDCALL; > - } > - minor = target[5] - '0'; > - if (minor > 1 || (minor == 1 && (shader_type != ST_VERTEX || major > 1))) > - { > - FIXME("Unsupported shader target minor version %d.\n", minor); > - return D3DERR_INVALIDCALL; > - } > shader = parse_hlsl_shader(preproc_shader, shader_type, major, minor, entrypoint, &messages); > > if (messages) > diff --git a/dlls/d3dcompiler_43/d3dcompiler_private.h b/dlls/d3dcompiler_43/d3dcompiler_private.h > index c8a92f1..63745e0 100644 > --- a/dlls/d3dcompiler_43/d3dcompiler_private.h > +++ b/dlls/d3dcompiler_43/d3dcompiler_private.h > @@ -51,6 +51,7 @@ enum shader_type > { > ST_VERTEX, > ST_PIXEL, > + ST_UNKNOWN > }; > I'd prefer ST_UNKNOWN to be in the first place here (so that it doesn't get pushed down when we'll add more target types) but it's not a big deal. > typedef enum BWRITER_COMPARISON_TYPE { > > > The patch is probably fine otherwise but can you check that targets in the form "vs.1.0" aren't accepted by native D3DCompile? I suppose those tokens are assembler-only, but better be safe than sorry.

2 1

IID mess
by Daniel Jeliński 03 May '13

03 May '13

Hello, I just tried compiling all of Wine with my patch series applied and, to my surprise, compilation failed. The reason was that IID_IResourceManager was already declared elsewhere. Now, according to this page: http://mikolajapp.appspot.com/uuid/query?q={56a868ac-0ad4-11ce-b03a-0020af0… Wine's strmif.h declares IID_IResourceManager, while SDK declares __declspec(uuid) as IResourceManager. SDK declares IID_IResourceManager elsewhere: http://mikolajapp.appspot.com/uuid/query?q={03741d21-87eb-11ce-8081-0080c75… I'm new to COM, so I'm not sure what exactly is the difference between IID and declspec(uuid). Could anyone explain or suggest a fix? Thanks, Daniel

2 3

Re: [PATCH 5/6] ieframe: Added more InternetExplorer object tests.
by Marvin 03 May '13

03 May '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 http://testbot.winehq.org/JobDetails.pl?Key=25429 Your paranoid android. === W2KPROSP4 (32 bit ie) === Timeout

1 0

Re: [AppDB] version: Only display comments section in case version has maintainers
by Hin-Tak Leung 02 May '13

02 May '13

------------------------------ On Fri, May 3, 2013 00:35 BST Rosanne DiMesio wrote: >On Thu, 2 May 2013 23:26:24 +0100 (BST) >Hin-Tak Leung <htl10(a)users.sourceforge.net> wrote: >> >> - "volunteer" is what it means: "volunteer". To try to make anybody "volunteer" in any activity any manner which is less than whole-heartedly willingly, sounds wrong. >> > >Nobody's trying to make anyone volunteer. I doubt anyone will. > >> There is no reason why the AppDB shouldn't work that way. i.e. just deal with the persistent ones, and let the individual readers skip over the occasional rest as they come. > >And who do you propose should "deal with" the persistent spammers? people who are bothered by them, or people who are paid to spend such time. I am neither. To be honest, i am more bothered by this thread (in a list which i subscribe to) than spam on appdb (which i don't). >> To ban such exchanges - between people who ask for help and might even offer incentives, and those who can offer help but not willing/possible to commit to a regular role - seem over-zealous. > >We have a perfectly good user's forum for such exchanges. > >-- >Rosanne DiMesio <dimesio(a)earthlink.net>

1 0

Re: [AppDB] version: Only display comments section in case version has maintainers
by Frédéric Delanoy 02 May '13

02 May '13

On Thu, May 2, 2013 at 7:23 PM, Rosanne DiMesio <dimesio(a)earthlink.net>wrote: > On Thu, 2 May 2013 17:57:16 +0200 > Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > > > > > This won't prevent it, but I'm not sure hiding/disabling comments won't > do > > more harm than good. > > My opinion, based on close to 5 years experience as an active AppDB admin > and maintainer, is it will inconvenience a few people, but overall do far > more good than harm, for reasons that go beyond simple spam control. The > number of unmaintained apps with an active community of commenters is > small; in most unmaintained apps, questions posted just sit there > unanswered. Users seeking help would be much better off posting on the forum. > Of course, but we don't want people to ask the same questions over and over again on the forum. I thought the whole point of the appdb entry was to centralize information on running apps with wine (comments being common to all versions of the software tested)... > Since Andre's patch (thank you, Andre) merely disables comments for > unmaintained apps, any user who really thinks it's vital that the comments > appear in a particular entry can make that happen themselves simply by > volunteering to be a maintainer. If it's not important enough to someone to > put forth the trivial effort required to do that, then it's not important > to them, period. Maintaining/testing app entries may not be so trivial for everyone, and you can't expect everyone wanting to know how to run an app to become a maintainer... Maybe merely disabling *new* (vs all) comments for unmaintained apps would also do the job??? Frédéric

3 2

Google Summer of Code 2013, Tools - Implement new control panel applets
by Brock York 02 May '13

02 May '13

Hey Everyone, I've been wanting to get into Google Summer of Code and Wine development for quite a while now. I was looking on the wine ideas page : http://wiki.winehq.org/SummerOfCode I'm interested in doing the first one: Tools - Implement new control panel applets, but am wondering what I would actually be able to do. I've done basic opengl applications before but using a library like SDL to do the lowerlevel stuff. What kind of opengl test would be preferred? Something like a port of GLXgears to wine or something that just tests if it can create a Opengl context and then exits saying success? I don't know how to test whether opengl was compiled into wine either, would that be very hard to do? I've never had write code to test if a feature was enabled before. Any suggestions on what kind of test I should try and implement would be greatly appreciated so I can try and get a proposal in. I know I'm leaving it pretty late but I only found out it was open a few hours ago. For a background of my knowledge I'm currently in my 3rd year of a computer science degree at my University, I also did a year of programming at a college. I've been using linux for 6 years but haven't been able to get to grips with programming for wine I always get confused or lost when trying to learn how wine works when trying to debug a game. I'm hoping doing something like this will be able to get me started on wine with a mentors help to guide me. Thanks. Regards Brock York

2 1

Re: [2/6] uuid: add transact.h and txdtc.h
by Frédéric Delanoy 02 May '13

02 May '13

On Wed, May 1, 2013 at 11:19 PM, Daniel Jeliński <djelinski1(a)gmail.com>wrote: > #include "msdasc.h" > > +#include "transact.h" > +#include "txdtc.h" > > A patch only adding new headers for inclusion is likely not acceptable. You should merge it with another patch making use of it. Frédéric

2 1

Re: [AppDB] version: Only display comments section in case version has maintainers
by Christopher Cope 02 May '13

02 May '13

I understand the premise, but I disagree. A lot of apps that I use don't have maintainers. However, the comments are typically helpful. I believe this should be approached differently. "André Hentschel" <nerv(a)dawncrow.de> wrote: >Am 28.04.2013 18:57, schrieb Rosanne DiMesio: >> Forced moderation of comments could work for apps with maintainers >who are doing their job, but most of the spam I recently deleted was in >unmaintained apps. My suggestion would be to block comments altogether >on unmaintained apps, not just because of spam, but because of other >inappropriate things that are not being monitored, such as posting >links to illegal downloads. As for the maintainers who clearly aren't >doing their jobs (about 20-25% of the spam I found was in entries with >maintainers), admins already have the capability of removing them. > > >--- > include/version.php | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > >diff --git a/include/version.php b/include/version.php >index 8f02b24..bf1d7ab 100644 >--- a/include/version.php >+++ b/include/version.php >@@ -1180,9 +1180,12 @@ class version { > > echo note::displayNotesForEntry($this->iVersionId); > >- // Comments Section >- if($this->iVersionId) >- Comment::view_app_comments($this->iVersionId); >+ if(sizeof($aMaintainers)>0) >+ { >+ // Display comments section in case version has >maintainers >+ if($this->iVersionId) >+ Comment::view_app_comments($this->iVersionId); >+ } > } > > public static function lookup_name($versionId) >-- >1.7.10.4

3 4

Re: Re: msi/tests: Add a trailing '\n' to an ok() call.
by Marvin 02 May '13

02 May '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 http://testbot.winehq.org/JobDetails.pl?Key=25396 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0