wine-devel June 2013

wine-devel@winehq.org

65 participants
128 discussions

Re: [PATCH] gdi32: do not overwrite variables (Coverity) (resubmit)
by Alexandre Julliard 17 Jun '13

17 Jun '13

Marcus Meissner <marcus(a)jet.franken.de> writes: > Hi, > > CID 743138,743137,743136 > wrote a DWORD (32bit) into a SHORT (16bit) entity. > > Not sure what is wrong with this one... it is a pretty clear bug to me. It's a bug, but it can be fixed in a better way. That helper function is badly designed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [Wine] Call for Translators
by Frédéric Delanoy 16 Jun '13

16 Jun '13

On Sun, Jun 16, 2013 at 2:02 PM, Martin Gregorie <martin(a)gregorie.org> wrote: > On Sun, 2013-06-16 at 08:52 +0200, Francois Gouget wrote: >> On Sun, 16 Jun 2013, Yaron Shahrabani wrote: >> >> > Hey Francois, sorry for trolling but I guess this is the time to revisit >> > our stand regarding web translation platform (because I suspect it might be >> > the cause for the lack of participation). >> > >> > What do you guys think? >> >> Do you mean the stance on making sure every contribution is properly >> attributed to its author? I don't think that's negotiable. >> > As a native English speaker I'm not really affected by WINE's language > support. > > My main gripe with WINE is the evident lack of regression testing. > > Martin Please don't hijack threads. Feel free to open a new thread on this subject on wine-devel. Frédéric

1 0

Call for Translators
by Francois Gouget 16 Jun '13

16 Jun '13

With the advent of PO files, Wine went from 12 good translations in the pre-1.4 days to 20 now. What's even more encouraging is that there are an extra 6 translations that are already half done. So can we reach 26 translations in time for Wine 1.6? More? So I'm calling on all translators of good will to review, refresh, complete or even start new Wine translations. You will find instructions to get started there: http://wiki.winehq.org/Translating And just as for Wine 1.4 you can track the translations status here: http://fgouget.free.fr/wine-po/ This site also collects reports about potential translation issues: * Mismatched printf format specifiers. (Note that these can cause Wine crashes!) * Mismatched trailing ellipsis. * Other mismatched trailing punctuation like full stop, question mark, space, etc. * Mismatched line feeds, trailing or not. * Spaces followed by line feeds. * Untranslated strings. Obviously some of these result in false positives. For instance 'Document' is written exactly the same in English and in French so to the script it will look like it was not translated. If you send me the corresponding error lines I'll make sure they are ignored by putting them in an 'ignore' file. This way the next translator looking things over won't have to skip over all these false positives. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Theory is where you know everything but nothing works. Practice is where everything works but nobody knows why. Sometimes they go hand in hand: nothing works and nobody knows why.

3 4

Re: [bugzilla] Add descriptions for additional resolutions
by Henri Verbeet 16 Jun '13

16 Jun '13

On 16 June 2013 01:26, André Hentschel <nerv(a)dawncrow.de> wrote: > + <dt> > + [% display_value("resolution", "UPSTREAM") FILTER html %] > + </dt> > + <dd> > + The problem is not a [% terms.bug %] in Wine, > + but in some upstream software Wine depends on. > + </dd> I don't care that much, but note that this isn't strictly limited to upstream, and also applies to e.g. broken packages. Also mostly fwiw, most other bug trackers I'm aware of call this NOTOURBUG.

1 0

Re: [PATCH 1/4] wined3d: Handle fog_start == fog_end with table fog
by Henri Verbeet 16 Jun '13

16 Jun '13

On 14 June 2013 22:34, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + { > + float increase = eps; > + volatile float fogend2 = fogend; > + do > + { > + fogend2 += increase; > + increase *= 2.0f; > + } > + while (fogstart == fogend2); > + fogend = fogend2; > + } Why is this needed? When end == start I'd expect (end - c) / (end - start) to evaluate to +/-INF, and then get clamped to [0, 1], which is pretty much what you'd want. In my (very limited) testing, that's also what actually happens with at least the GLSL backend.

2 3

Call for help with the new WineTestBot
by Francois Gouget 16 Jun '13

16 Jun '13

So while the translators are busy updating Wine's translations, what better time than a freeze for developers to fix Wine's conformance tests, particularly on the new WineTestBot: http://newtestbot.winehq.org It does not have as many VMs as the old one but it does have some interesting new configurations: * Two Windows 8 VMs: 32 and 64 bits. These have a lot of failures. * A Windows 7 VM with IE 10 (and one with IE 9 for comparison). * A Vista VM configured for Arabic, a right-to-left language. There's also a Japanese Windows 7 VM. * Two VMs with no sound card (the 64-bit Vista and Windows 2008 ones). These new configurations have uncovered quite a few test failures. But the more traditional configurations have some test failures too which is annoying and warrants investigation to figure out what's wrong: otherwise there will be trouble when patches have to go through the new WineTestBot. So I'm hoping some kind souls (or bored developers) will take it onto themselves to chime in and fix some of these test failures, or figure out what is causing them. Here are some known issues: * Bug 24631 - listview NM_HOVER tests sometimes fail http://bugs.winehq.org/show_bug.cgi?id=24631 * Bug 33718 - comctl32:propsheet Add button test failure http://bugs.winehq.org/show_bug.cgi?id=33718 * Bug 33719 - comctl32:propsheet custom window proc test failure http://bugs.winehq.org/show_bug.cgi?id=33719 You can also find test results from the new WineTestBot on the WineTest site: look for tags starting with 'newtb-'. http://test.winehq.org/data/ And for more information on the VMs configuration and some other known test failures go to this Wiki page: http://wiki.winehq.org/WineTestBotVMs Note that the VMs are missing some Windows dlls (atl100, localspl, msvcp100, qmgr). Information on the best way to get those is welcome. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

1 0

Re: [PATCH 3/3] wined3d: Handle pre-transformed vertices in the GLSL vertex pipe.
by Stefan Dösinger 15 Jun '13

15 Jun '13

Am 14.06.2013 um 09:07 schrieb Henri Verbeet <hverbeet(a)codeweavers.com>: > + shader_addline(buffer, "if (gl_Vertex.w != 0.0) gl_Position /= gl_Vertex.w;\n"); I think you have to disable the rhw divide in drawStridedSlow in case the application falls back to it despite this patch, e.g. because of specular fog or float16 emulation.

1 0

Re: gdiplus: fix a clipping regression in GdipDrawString (try 3)
by Dmitry Timoshkov 14 Jun '13

14 Jun '13

Rafał Mużyło <galtgendo(a)gmail.com> wrote: > Going on an assumption, that 0 is a magic value (standing for 'point'), > compare against it. Fixes 6ab04040e52465e77558a067309e8a54bdc0f32c regression, > so would be nice if this got into wine 1.6. It would be nice to see some test cases first. -- Dmitry.

1 0

Fwd: [GSoC Mentors Announce] GSoC 2013: Mentor Summit Travel and Details
by Austin English 14 Jun '13

14 Jun '13

FYI for GSoC mentors. It's a ways away, but have the date in mind if you'd like to attend. Remember we have two slots, so if there are more than 2 people, we'll give preference to people that haven't gone before. -Austin ---------- Forwarded message ---------- From: Carol Smith <carols(a)google.com> Date: Thu, Jun 13, 2013 at 11:23 AM Subject: [GSoC Mentors Announce] GSoC 2013: Mentor Summit Travel and Details To: gsoc-mentors-announce <gsoc-mentors-announce(a)googlegroups.com> Hi everyone, The Google Summer of Code Mentor Summit is approaching! When: 19-20 October, 2013 Where: Google Headquarters, Mountain View, California Some brief background: The Google Summer of Code Mentor Summit is a two-day "unconference" [0] that brings together two mentors (or org admins) from each of the mentoring organizations that has participated in GSoC that year. Google pays for a two-night hotel stay, transportation costs, conference facilities, and food for the weekend, and the attendees make the agenda. We've consistently heard from mentors over the years that the summit was one of the best conferences of the year for them. The opportunity to meet face-to-face with other FOSS community members is a valuable experience, as is the time spent discussing ideas in a casual forum where everyone's voice can be heard. I'd encourage your organization to send delegates to the summit even if you don't quite understand of the utility of it now - I feel confident you won't be disappointed with the results. Attendees stay at the Wild Palms hotel [1] while they're in town and we serve a traditional dinner of thai food on Friday night and have a pool party on Saturday night. Here's how to proceed with booking and attending: 1) Your organization will need to decide on two delegates [2] to send to the event. Any people who want to attend above and beyond the two from your org will need to list themselves on the Waiting List [3] and wait for word from me about extra space as we get closer to the event. NB: The wiki requires a login when visiting for the first time. The username is "mentor" and the password is "yourock." I highly recommend creating your own account with a unique password once you have logged in for the first time. 2) Once your organization has decided on the two delegates it would like to send to this year's event, those individuals can feel free to book their hotel rooms at the Wild Palms [4] now. Please note that if the Wild Palms fills up you will need to make your reservation with the Domain Hotel instead [5]. If you really want to stay at the Wild Palms, make sure to book early! We'll have shuttles running between the hotels and to campus for the whole weekend. NB: The hotel registration deadline is 6 September. If you really want to stay at the Wild Palms, I'd recommend you book early. :-) 3) Please fill out the Mentor Summit Preparation form [6] as soon as you have confirmed your hotel room. 4) We include the reimbursement for travel to the mentor summit and the mentor stipends in one PO to your organization. Please see the payment info page [7] for more detail on this. These POs will be issued to your org soon after it has made the payment request. 5) Flights should be purchased once you have a confirmed PO. All orgs pay for plane tickets ahead of time and then request reimbursement via invoice against the PO once you have receipts for the flights. 6) Please check out the wiki [8] and fill in your name if you're attending. Look around the rest of the site - it has lots of useful information for you about the event and what to expect. 7) In the unlikely event that your organization does not plan to attend the mentor summit at all, please fill out this form [9] to let me know. Please only fill this out if you are not sending *any* delegates to the summit. 8) We are doing session scheduling for this year's summit via Google Moderator. Please fill in your ideas for sessions on the webpage [10] by 27 September and vote for your favorite ideas! You can read more about how we're running session scheduling this year on the wiki [11]. 9) Please remember that any organization that misses two or more evaluation deadlines may not attend the summit. If you book travel and then get uninvited from the summit after the either the midterm or the final evaluations you will not be reimbursed for travel costs and your hotel stays will be cancelled. So don't miss those evaluations or you jeopardize missing the event! [0] - http://en.wikipedia.org/wiki/Unconference [1] - http://www.jdvhotels.com/hotels/siliconvalley/wild_palms [2] - A "delegate" is defined as either a mentor or org admin who participated in this year's GSoC program. We're sorry, but we can't accomodate other people from your organization who did not mentor or administer this year. Also, we will not accept any mentors who miss an evaluation deadline in this year's program. Please contact me if you have questions about if a person from your organization is on this list. [3] - https://docs.google.com/a/google.com/forms/d/1bfuIJ_U76rznjfqBYdRKfFlfmvhqr… [4] - https://www.jdvhotels.com/book/reservations/wld?start_date=2013-10-14&end_d… [5] - https://www.jdvhotels.com/book/reservations/dom?start_date=2013-10-18&end_d… [6] - http://goo.gl/oyM2y [7] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc20… [8] - https://gsoc-wiki.osuosl.org/index.php/2013 [9] - http://goo.gl/OTxuo [10] - http://goo.gl/EH0ZH [11] - https://gsoc-wiki.osuosl.org/index.php/Proposed_Session_Topics_2013 As always, please contact me directly with any questions or concerns you may have about any of these instructions. Cheers, Carol -- You received this message because you are subscribed to the Google Groups "Google Summer of Code Mentors Announce List" group. To unsubscribe from this group and stop receiving emails from it, send an email to gsoc-mentors-announce+unsubscribe(a)googlegroups.com. Visit this group at http://groups.google.com/group/gsoc-mentors-announce. For more options, visit https://groups.google.com/groups/opt_out. -- -Austin

2 1

Re: oledb32: Add IErrorInfo Support
by Nikolay Sivov 14 Jun '13

14 Jun '13

On 6/14/2013 14:12, Alistair Leslie-Hughes wrote: > +typedef struct ErrorInfoImpl > +{ > + IErrorInfo IErrorInfo_iface; > + LONG ref; > + > + GUID m_Guid; > + WCHAR *source; > + WCHAR *description; > + WCHAR *help_file; > + DWORD m_dwHelpContext; > +} ErrorInfoImpl; Please use consistent naming, for example avoid prefixed names. Also it would be cleaner to use BSTR here, but it will work either way. > + TRACE("(%p)->(pBstrSource=%p)\n",This,pBstrSource); No need for parameter names in traces.

1 0

Re: ole32: Postpone removing a being destroyed apartment from the global list.
by Alexandre Julliard 13 Jun '13

13 Jun '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > StdMarshalImpl_ReleaseMarshalData called from apartment_release() needs to > access apartment data, but fails because an apartment has already been removed > from the global list. That leads to lost connections and memory leaks. But now you can have someone find a half-destroyed apartment in the list... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] [cmd, try2] move filename . deletes file
by Alexandre Julliard 13 Jun '13

13 Jun '13

Jason Edmeades <jason(a)edmeades.me.uk> writes: > move is not tollerent of the source and destination being the same > and happily removes the destination (after prompting) ready to > move the file, only to appear shocked that the file is no longer > there... > > This was sent originally where I compared filenames, and was given > feedback to use a better system of equality. This now uses something > the MSDN implies is the best way to tell for equivalent destinations This should be done in MoveFile, and cmd should use that instead of duplicating the checks. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: oleaut32: Add DECIMAL tests
by Marvin 13 Jun '13

13 Jun '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=25961 Your paranoid android. === W2KPROSP4 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === WXPPROSP2 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === WXPX64 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === W2K3R2SESP2 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === WVISTAX64 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === W2K8SE (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === W7PROX64 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === TEST64_W7SP1 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === WXPX64 (64 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === WVISTAX64 (64 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === W7PROX64 (64 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === TEST64_W7SP1 (64 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000

1 0

Re: oleaut32:
by Marvin 13 Jun '13

13 Jun '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=25960 Your paranoid android. === W2KPROSP4 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === WXPPROSP2 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === WXPX64 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === W2K3R2SESP2 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === WVISTAX64 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === W2K8SE (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === W7PROX64 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === TEST64_W7SP1 (32 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === WXPX64 (64 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === WVISTAX64 (64 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === W7PROX64 (64 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000 === TEST64_W7SP1 (64 bit vartype) === vartype.c:4339: Test failed: expected (0,0,-1,(ffffff84 ffffffff)), got (0,0,-1,(ffffffff ffffff84)) hres 0x00000000

1 0

Re: gdiplus: fix a clipping regression in GdipDrawString (try 2)
by Vincent Povirk 12 Jun '13

12 Jun '13

What if rect.Width is 0.25? Shouldn't we still clip then?

1 0

Wine's Tahoma...
by Aric Stewart 12 Jun '13

12 Jun '13

Hi, So working on Arabic font issues I have started really looking at wine's Tahoma font. Windows Tahoma covers glyphs in quite a few ranges, Latin, Cyrillic, Hebrew, Arabic, Thai to name a few. Wine's Tahoma has bit a fraction of this coverage. Looking to improve our Arabic support, I found that our Tahoma heavily uses glyphs from DejaVu fonts already, which are public domain. I was wondering if we wanted to take the leap and just replace our Tahoma completely with DejaVu Sans? We can generate a fontforge sfd file for the file and adjust the family names as required. We would retain the copyrights so that we honer the source. But it would give us the glyphs we need to have a fully functional Tahoma. What is the thought on this? If there is strong opposition then I have a patch to include Arabic in our font, but it really seems like many users in other scripts would benefit greatly from having a more fully fleshed out tahoma. -aric

2 1

Re: [PATCH] d3dx9_36: Implement D3DXGetShaderInputSemantics + tests.
by Matteo Bruni 12 Jun '13

12 Jun '13

2013/6/11 Christian Costa <titan.costa(a)gmail.com>: > Fixes bug 22682. > --- > dlls/d3dx9_36/d3dx9_36.spec | 2 +- > dlls/d3dx9_36/shader.c | 50 ++++++++++++++++++++++++++++++++++++++ > dlls/d3dx9_36/tests/shader.c | 55 ++++++++++++++++++++++++++++++++++++++++++ > include/d3dx9shader.h | 1 + > 4 files changed, 107 insertions(+), 1 deletion(-) > > diff --git a/dlls/d3dx9_36/d3dx9_36.spec b/dlls/d3dx9_36/d3dx9_36.spec > index f2c229a..0f1387e 100644 > --- a/dlls/d3dx9_36/d3dx9_36.spec > +++ b/dlls/d3dx9_36/d3dx9_36.spec > @@ -159,7 +159,7 @@ > @ stdcall D3DXGetPixelShaderProfile(ptr) > @ stdcall D3DXGetShaderConstantTable(ptr ptr) > @ stdcall D3DXGetShaderConstantTableEx(ptr long ptr) > -@ stub D3DXGetShaderInputSemantics(ptr ptr ptr) > +@ stdcall D3DXGetShaderInputSemantics(ptr ptr ptr) > @ stub D3DXGetShaderOutputSemantics(ptr ptr ptr) > @ stdcall D3DXGetShaderSamplers(ptr ptr ptr) > @ stdcall D3DXGetShaderSize(ptr) > diff --git a/dlls/d3dx9_36/shader.c b/dlls/d3dx9_36/shader.c > index 75bc9b5..3b71b4b 100644 > --- a/dlls/d3dx9_36/shader.c > +++ b/dlls/d3dx9_36/shader.c > @@ -1,6 +1,7 @@ > /* > * Copyright 2008 Luis Busquets > * Copyright 2009 Matteo Bruni > + * Copyright 2010, 2013 Christian Costa > * Copyright 2011 Travis Athougies > * > * This library is free software; you can redistribute it and/or > @@ -1778,3 +1779,52 @@ HRESULT WINAPI D3DXGetShaderSamplers(const DWORD *byte_code, const char **sample > > return D3D_OK; > } > + > +HRESULT WINAPI D3DXGetShaderInputSemantics(const DWORD *byte_code, D3DXSEMANTIC *semantics, UINT *count) > +{ > + const DWORD *ptr = byte_code; > + UINT i = 0; > + > + TRACE("byte_code = %p, semantics = %p, count = %p\n", byte_code, semantics, count); > + > + if (!byte_code) > + return D3DERR_INVALIDCALL; > + > + TRACE("Shader version: %#x\n", *ptr); > + > + /* Look for the END token, skipping the VERSION token */ > + while (*++ptr != D3DSIO_END) I think you should be a bit more careful in skipping non-opcode DWORDs, otherwise you could e.g. potentially match with constants from DEF instructions - very unlikely to happen in practice, sure, but since it can be easily avoided, why not? Take a look at shader_skip_opcode() from wined3d/shader_sm1.c. You can probably get away without having to write a table with the parameters count for each SM1 opcode by just skipping DWORDs with the most significant bit set (see shader_skip_unrecognized() from the same file). Of course you still have to special case DEF but that should be it. > + { > + /* Skip comments */ > + if ((*ptr & D3DSI_OPCODE_MASK) == D3DSIO_COMMENT) > + { > + ptr += ((*ptr & D3DSI_COMMENTSIZE_MASK) >> D3DSI_COMMENTSIZE_SHIFT); > + } > + else if ((*ptr & D3DSI_OPCODE_MASK) == D3DSIO_DCL) > + { > + DWORD param1 = *++ptr; > + DWORD param2 = *++ptr; > + DWORD usage = param1 & 0x1f; > + DWORD usage_index = (param1 >> 16) & 0xf; > + DWORD reg_type = (((param2 >> 11) & 0x3) << 3) | ((param2 >> 28) & 0x7); > + > + TRACE("D3DSIO_DCL param1: %#x, param2: %#x, usage: %u, usage_index: %u, reg_type: %u\n", > + param1, param2, usage, usage_index, reg_type); > + > + if (reg_type == D3DSPR_INPUT) > + { > + if (semantics) > + { > + semantics[i].Usage = usage; > + semantics[i].UsageIndex = usage_index; > + } > + i++; > + } > + } > + } > + > + if (count) > + *count = i; > + > + return D3D_OK; > +} Have you tried to implement D3DXGetShaderOutputSemantics too? I suspect most of the code will be pretty much the same, in that case you could move the common code to a helper function and use it from both. You don't necessarily need to do this right now, just mentioning a potential follow-up. > diff --git a/dlls/d3dx9_36/tests/shader.c b/dlls/d3dx9_36/tests/shader.c > index f7be174..471cd8c 100644 > --- a/dlls/d3dx9_36/tests/shader.c > +++ b/dlls/d3dx9_36/tests/shader.c > @@ -1,5 +1,6 @@ > /* > * Copyright 2008 Luis Busquets > + * Copyright 2010, 2013 Christian Costa > * Copyright 2011 Travis Athougies > * > * This library is free software; you can redistribute it and/or > @@ -271,6 +272,22 @@ static const D3DXCONSTANT_DESC ctab_samplers_expected[] = { > {"sampler2", D3DXRS_SAMPLER, 3, 1, D3DXPC_OBJECT, D3DXPT_SAMPLER3D, 1, 1, 1, 0, 4, NULL}, > {"notsampler", D3DXRS_FLOAT4, 2, 1, D3DXPC_VECTOR, D3DXPT_FLOAT, 1, 4, 1, 0, 16, NULL}}; > > +static const DWORD semantics_vs11[] = { > + 0xfffe0101, /* vs_1_1 */ > + 0x0000001f, 0x80000000, 0x900f0000, /* dcl_position0 v0 (input) */ > + 0x0000001f, 0x80000005, 0x900f0001, /* dcl_texcoord0 v1 (input) */ > + 0x0000001f, 0x80010005, 0x900f0002, /* dcl_texcoord1 v2 (input) */ > + 0x0000001f, 0x8000000a, 0xe00f0000, /* dcl_color0 oD0 (output) */ > + 0x0000ffff}; /* END */ > + > +static const DWORD semantics_vs30[] = { > + 0xfffe0300, /* vs_3_0 */ > + 0x0000001f, 0x80000000, 0x900f0000, /* dcl_position0 v0 (input) */ > + 0x0000001f, 0x80000005, 0x900f0001, /* dcl_texcoord0 v1 (input) */ > + 0x0000001f, 0x80010005, 0x900f0002, /* dcl_texcoord1 v2 (input) */ > + 0x0000001f, 0x8000000a, 0xe00f0000, /* dcl_color0 o0 (output) */ > + 0x0000ffff}; /* END */ > + > static void test_get_shader_size(void) > { > UINT shader_size, expected; > @@ -1900,6 +1917,43 @@ static void test_get_shader_constant_variables(void) > ok(count == 0, "Release failed, got %u, expected %u\n", count, 0); > } > > +static void test_get_shader_semantics(void) > +{ > + HRESULT ret; > + D3DXSEMANTIC semantics[MAXD3DDECLLENGTH]; > + UINT count; > + > + /* Check parameters */ > + ret = D3DXGetShaderInputSemantics(NULL, semantics, &count); > + ok(ret == D3DERR_INVALIDCALL, "Returned %#x, expected %#x\n", ret, D3DERR_INVALIDCALL); > + ret = D3DXGetShaderInputSemantics(semantics_vs11, semantics, NULL); > + ok(ret == D3D_OK, "Failed with %#xn", ret); > + count = 0xdeadbeef; > + ret = D3DXGetShaderInputSemantics(semantics_vs11, NULL, &count); > + ok(ret == D3D_OK, "Failed with %#xn", ret); > + ok(count == 3, "Got %u, expected 1\n", count); > + > + ret = D3DXGetShaderInputSemantics(semantics_vs11, semantics, &count); > + ok(ret == D3D_OK, "Failed with %#xn", ret); > + ok(count == 3, "Got %u, expected 1\n", count); > + ok(semantics[0].Usage == D3DDECLUSAGE_POSITION, "Got %u, expected %u\n", semantics[0].Usage, D3DDECLUSAGE_POSITION); > + ok(semantics[0].UsageIndex == 0, "Got %u, expected 0\n", semantics[0].UsageIndex); > + ok(semantics[1].Usage == D3DDECLUSAGE_TEXCOORD, "Got %u, expected %u\n", semantics[1].Usage, D3DDECLUSAGE_TEXCOORD); > + ok(semantics[1].UsageIndex == 0, "Got %u, expected 0\n", semantics[0].UsageIndex); > + ok(semantics[2].Usage == D3DDECLUSAGE_TEXCOORD, "Got %u, expected %u\n", semantics[2].Usage, D3DDECLUSAGE_TEXCOORD); > + ok(semantics[2].UsageIndex == 1, "Got %u, expected 1\n", semantics[0].UsageIndex); > + > + ret = D3DXGetShaderInputSemantics(semantics_vs30, semantics, &count); > + ok(ret == D3D_OK, "Failed with %#xn", ret); > + ok(count == 3, "Got %u, expected 1\n", count); > + ok(semantics[0].Usage == D3DDECLUSAGE_POSITION, "Got %u, expected %u\n", semantics[0].Usage, D3DDECLUSAGE_POSITION); > + ok(semantics[0].UsageIndex == 0, "Got %u, expected 0\n", semantics[0].UsageIndex); > + ok(semantics[1].Usage == D3DDECLUSAGE_TEXCOORD, "Got %u, expected %u\n", semantics[1].Usage, D3DDECLUSAGE_TEXCOORD); > + ok(semantics[1].UsageIndex == 0, "Got %u, expected 0\n", semantics[0].UsageIndex); > + ok(semantics[2].Usage == D3DDECLUSAGE_TEXCOORD, "Got %u, expected %u\n", semantics[2].Usage, D3DDECLUSAGE_TEXCOORD); > + ok(semantics[2].UsageIndex == 1, "Got %u, expected 1\n", semantics[0].UsageIndex); > +} > + > START_TEST(shader) > { > test_get_shader_size(); > @@ -1911,4 +1965,5 @@ START_TEST(shader) > test_get_sampler_index(); > test_get_shader_samplers(); > test_get_shader_constant_variables(); > + test_get_shader_semantics(); > } > diff --git a/include/d3dx9shader.h b/include/d3dx9shader.h > index 0b30519..f5ba1c4 100644 > --- a/include/d3dx9shader.h > +++ b/include/d3dx9shader.h > @@ -269,6 +269,7 @@ DWORD WINAPI D3DXGetShaderVersion(const DWORD *byte_code); > const char * WINAPI D3DXGetVertexShaderProfile(struct IDirect3DDevice9 *device); > HRESULT WINAPI D3DXFindShaderComment(CONST DWORD* byte_code, DWORD fourcc, LPCVOID* data, UINT* size); > HRESULT WINAPI D3DXGetShaderSamplers(CONST DWORD *byte_code, LPCSTR *samplers, UINT *count); > +HRESULT WINAPI D3DXGetShaderInputSemantics(const DWORD *byte_code, D3DXSEMANTIC *semantics, UINT *count); > > HRESULT WINAPI D3DXAssembleShaderFromFileA(const char *filename, const D3DXMACRO *defines, > ID3DXInclude *include, DWORD flags, ID3DXBuffer **shader, ID3DXBuffer **error_messages); > > >

3 4

Possible wine bug concerning the case of the DbgHelp.h header filename
by Alan W. Irwin 12 Jun '13

12 Jun '13

I successfully built the ultra-fast ninja build tool on Wine using the MinGW g++ compiler. To achieve that success I had to deal with a small number of issues including one wine/ninja header name inconsistency which is that DbgHelp.h (#included by the ninja code) has a lower-case name (dbghelp.h) on wine, and the MinGW suite of compilers is sensitive to the case of header file names. I worked around this issue with the following symlink /home/wine/wine_build/install-git/include/wine/windows/DbgHelp.h -> dbghelp.h where /home/wine/wine_build/install-git is my install prefix for my wine-git build. Is Wine following the correct Windows naming convention for this header? For what it is worth, I did a google search for <windows dbghelp.h> and most of the hits were for DbgHelp.h rather than dbghelp.h so I can understand why the ninja developers used #include<DbgHelp.h> rather than the lower-case version of that name. If the wine developers here decide this is definitely a wine issue, I am willing to write up the bug report on your bugtracker so this issue doesn't get lost. A search there for <header case filename> did not turn up anything relevant. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________

4 4

Re: [PATCH] d3dx9_36: Set compilation_errors to NULL when no error encountered + tests.
by Rico Schüller 12 Jun '13

12 Jun '13

On 11.06.2013 22:08, Christian Costa wrote: > Fixes bug 26598. > --- > dlls/d3dx9_36/effect.c | 4 ++++ > dlls/d3dx9_36/tests/effect.c | 17 +++++++++++++++++ > 2 files changed, 21 insertions(+) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c > index 1924c07..bab4560 100644 > --- a/dlls/d3dx9_36/effect.c > +++ b/dlls/d3dx9_36/effect.c > @@ -5792,6 +5792,10 @@ HRESULT WINAPI D3DXCreateEffectEx(struct IDirect3DDevice9 *device, const void *s > > *effect = &object->ID3DXEffect_iface; > > + /* Must be set to NULL if no compilation error */ > + if (compilation_errors) > + *compilation_errors = NULL; > + No, this is wrong! Your test case doesn't cover all cases. Cheers Rico

2 2

Re: wininet/tests: Avoid proxy test failures on old wininet.
by Marvin 12 Jun '13

12 Jun '13

1 0

Re: [PATCH] d3dx9_36: Implement D3DXGetShaderInputSemantics + tests.
by Rico Schüller 12 Jun '13

12 Jun '13

On 11.06.2013 22:08, Christian Costa wrote: > + TRACE("byte_code = %p, semantics = %p, count = %p\n", byte_code, semantics, count); The rest of the file seems to use the trace without the "=". > + ok(ret == D3D_OK, "Failed with %#xn", ret); > + ok(count == 3, "Got %u, expected 1\n", count); Should be "\n" and "expected 3". Both several times. As the return value for semantics is in both tests the same, it might be useful to initialize the semantics first to check that the values are really set in both cases. What does D3DXGetShaderInputSemantics(semantics_vs11, NULL, NULL); and D3DXGetShaderInputSemantics(NULL, NULL, NULL); return? Well both are corner cases without much meaning. You may check for the semantics where the count is NULL like D3DXGetShaderInputSemantics(semantics_vs11, semantics, NULL); Cheers Rico

2 1

Re: comdlg32: Store client GUID with SetClientGuid()
by Marvin 12 Jun '13

12 Jun '13

1 0

[PATCH v6 0/7] Add O_DENY* support for VFS and CIFS/NFS
by Pavel Shilovsky 11 Jun '13

11 Jun '13

Main changes from v5: 1) O_DENYDELETE is now supported by VFS. 2) ESHAREDENIED erro code is introduced to be returned on sharelock conflicts. 3) forcemand dependancy is removed. CIFS module detects if it should use NTCreateAndX command according to existence of O_DENY flags. 4) Term 'deny lock' is replaced by 'sharelock' (function names, code comments, patch descriptions). Main changes from v4: 1) deny_lock_file uses FS_DOES_SHARELOCK flag from fs_flags to determine whether to use VFS locks or not. 2) Make nfs code return -EBUSY for share conflicts (was -EACCESS). Main changes from v3 1) O_DENYMAND is removed, sharelock mount option is introduced. 2) Patch fcntl.h and VFS patches are united into one. 3) flock/LOCK_MAND is disabled for sharelock mounts. This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic. These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients. According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why extra mount option 'sharelock' is added for switching on/off O_DENY* flags processing. It allows us to avoid use of these flags on critical places (like /, /lib) and turn them on if we really want it proccessed that way. So, we have 3 new flags: O_DENYREAD - to prevent other opens with read access, O_DENYWRITE - to prevent other opens with write access, O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module), The patchset avoid data races problem on newely created files: open with O_CREAT can return the -ETXTBSY error for a successfully created file if this files was locked with a sharelock by another task. Also, it turns flock/LOCK_MAND capability off for mounts with 'sharelock' option. This lets us not mix one share reservation approach with another. The #1 patch adds flags to fcntl and implements VFS part. The patches #3, #4, #5 are related to CIFS-specific changes, #6 and #7 describe NFS and NFSD parts. The preliminary patch for Samba that replaces the existing use of flock/LOCK_MAND mechanism with O_DENY* flags: http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=… The future part of open man page patch: ----- O_DENYREAD, O_DENYWRIYE, O_DENYDELETE - used to inforce a mandatory share reservation scheme of the file access. If these flag is passed, the open fails with -ESHAREDENIED in following cases: 1) if O_DENYREAD flag is specified and there is another open with READ access to the file; 2) if O_DENYWRITE flag is specified and there is another open with WRITE access to the file; 3) if READ access is requested and there is another open with O_DENYREAD flags; 4) if WRITE access is requested and there is another open with O_DENYWRITE flags. If O_DENYDELETE flag is specified and the open succeded, any further unlink operation will fail with -ESHAREDENIED untill this open is closed. Now this flag is processed by VFS and CIFS filesystem. This mechanism is done through flocks. If O_DENY* flags are specified, flock syscall is processed after the open. The share modes are translated into flock according the following rules: 1) !O_DENYREAD -> LOCK_READ | LOCK_MAND 2) !O_DENYWRITE -> LOCK_WRITE | LOCK_MAND 3) !O_DENYDELETE -> LOCK_DELETE | LOCK_MAND ----- Pavel Shilovsky (7): VFS: Introduce new O_DENY* open flags VFS: Add O_DENYDELETE support for VFS CIFS: Add share_access parm to open request CIFS: Add O_DENY* open flags support NFSv4: Add O_DENY* open flags support NFSD: Pass share reservations flags to VFS locks: Disable LOCK_MAND support for MS_SHARELOCK mounts fs/cifs/cifsacl.c | 8 +- fs/cifs/cifsfs.c | 2 +- fs/cifs/cifsglob.h | 18 ++++- fs/cifs/cifsproto.h | 8 +- fs/cifs/cifssmb.c | 50 +++++++------ fs/cifs/dir.c | 16 ++-- fs/cifs/file.c | 25 +++++-- fs/cifs/inode.c | 21 +++--- fs/cifs/link.c | 25 ++----- fs/cifs/netmisc.c | 2 +- fs/cifs/readdir.c | 5 +- fs/cifs/smb1ops.c | 16 ++-- fs/cifs/smb2file.c | 10 +-- fs/cifs/smb2inode.c | 4 +- fs/cifs/smb2maperror.c | 2 +- fs/cifs/smb2ops.c | 10 ++- fs/cifs/smb2pdu.c | 6 +- fs/cifs/smb2proto.h | 14 ++-- fs/fcntl.c | 5 +- fs/locks.c | 158 ++++++++++++++++++++++++++++++++++++--- fs/namei.c | 48 +++++++++++- fs/nfs/dir.c | 4 + fs/nfs/internal.h | 3 +- fs/nfs/nfs4file.c | 4 + fs/nfs/nfs4proc.c | 4 +- fs/nfs/nfs4super.c | 9 ++- fs/nfs/nfs4xdr.c | 21 +++++- fs/nfs/super.c | 7 +- fs/nfsd/nfs4state.c | 46 +++++++++++- fs/nfsd/nfsproc.c | 1 + fs/proc_namespace.c | 1 + include/linux/fs.h | 14 ++++ include/uapi/asm-generic/errno.h | 2 + include/uapi/asm-generic/fcntl.h | 12 +++ include/uapi/linux/fs.h | 1 + 35 files changed, 443 insertions(+), 139 deletions(-) -- 1.8.1.5

4 13

Patch 96712
by Christian Costa 11 Jun '13

11 Jun '13

Hi, Is there something wrong with this patch? The only feedback I got is a typo (fixed). http://source.winehq.org/patches/data/96712 Thanks

1 0

Re: [PATCH 1/1] wined3d: Introduce a helper function for printing floats in GLSL shaders.
by Stefan Dösinger 11 Jun '13

11 Jun '13

Am 11.06.2013 um 09:27 schrieb Henri Verbeet: > We always want to use '.' as decimal separator in GLSL, instead of the locale > specific one. Reported on IRC. I think this should be added as a code comment above shader_glsl_ftoa, I don't think the reason why we need our own conversion function is obvious. The ARB shader backend will need this as well, but I can take care of this. What external software triggers this behavior? > case WINED3D_DATA_FLOAT: > - sprintf(register_name, "%.8e", *(const float *)reg->immconst_data); > + shader_glsl_ftoa(*(const float *)reg->immconst_data, register_name); > break; shader_glsl_ftoa doesn't handle inf or nan. I assume that's intentional because they would only trigger a parser error.

2 1

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 June 2013