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

Re: [00/11] msi/tests: Prepare action.c for the switch to -D__WINESRC__.

by Marvin

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

Oct. 15, 2013

Re: [10/11] msi/tests: Prepare msi.c for the switch to -D__WINESRC__.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2769 Your paranoid android. === wvista (32 bit msi) === The test timed out === w2008s64 (32 bit msi) === The test timed out === w7pro64 (32 bit msi) === Timeout === w2008s64 (64 bit msi) === Timeout === w7pro64 (64 bit msi) === Timeout

Oct. 15, 2013

Re: [11/11] msi/tests: Compile with -D__WINESRC__.

by Marvin

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

Oct. 15, 2013

Re: [04/11] msi/tests: Prepare install.c for the switch to -D__WINESRC__.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2763 Your paranoid android. === wxppro (32 bit install) === No test summary line found Failure running script in VM: network read timed out === wvista (32 bit install) === Timeout === w2008s64 (32 bit install) === Failure running script in VM: network read timed out === w7pro64 (32 bit install) === Timeout Failure running script in VM: timed out waiting for the child process === w864 (32 bit install) === install.c:2439: Test failed: Directory not created === w2008s64 (64 bit install) === Timeout

Oct. 15, 2013

Re: dlls/explorerframe: build tests with -D__WINESRC__

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2750 Your paranoid android. === wvista (32 bit nstc) === nstc.c:1934: Test failed: Got event 7, count 0 nstc.c:1936: Test failed: Got event 4, count 0 nstc.c:1949: Test failed: Got event 4, count 0

Oct. 14, 2013

Re: wsock32: Add a fallback for inet_network.

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> writes: > --- > dlls/wsock32/protocol.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) This doesn't build on MingW: protocol.o: In function `WSOCK32_inet_network(a)4': /home/julliard/wine/build/obj-pe32/dlls/wsock32/../../../wine/dlls/wsock32/protocol.c:55: undefined reference to `_inet_addr' /home/julliard/wine/build/obj-pe32/dlls/wsock32/../../../wine/dlls/wsock32/protocol.c:55: undefined reference to `_ntohl' collect2: ld returned 1 exit status winegcc: i686-w64-mingw32-gcc failed -- Alexandre Julliard julliard(a)winehq.org

Oct. 14, 2013

RE: Help / Mentoring

by Hugh McMaster

On Monday, 14 October 2013 9:50 PM, Ricardo Filipe wrote: >I'd be more than happy to help you review your patches, although I am no wineconsole expert, I believe I could help you get your changes into wine. >Contact me if no better offer comes around :) cheers Hello Ricardo, Thank you for your kind offer. I'll contact you via email. Hugh

Oct. 14, 2013

Re: Help / Mentoring

by Ricardo Filipe

Hello Hugh, I'd be more than happy to help you review your patches, although I am no wineconsole expert, I believe I could help you get your changes into wine. Contact me if no better offer comes around :) cheers 2013/10/11 Hugh McMaster <hugh.mcmaster(a)masterindexing.com>: > Can anyone help me on this? I do realize that wineconsole is only a minor focus of development. > > Hugh > > ------------------------------------------------- > > Hi everyone, > > I just wanted to know if anyone would mind helping/mentoring me with a few small patches. > > I am working primarily on wineconsole's screen buffer problems (to which I believe I have the solution), but am also looking at implementing some stub Win32 console functions found in dlls/kernel32. Obviously, my aim is to have these patches committed, as the changes will benefit the entire Wine community. > > I had initially thought of Eric Poeuch, a significant wineconsole developer, however he appears to be extremely busy. So I'm not sure who else to contact. > > If time is a consideration, please note that I won't be constantly contacting you to review patches or answer questions. > > Thank you, > > Hugh > >

Oct. 14, 2013

Re: Mono Update

by Ricardo Filipe

IMHO it is more than time. Mono has several release cycles of new features that we are not taking advantage of with wine-mono cheers 2013/10/14 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > > wine-mono hasn't been updated in nearly a year. Should it be time to > consider a new release? > > Thoughts. > > Best Regards > Alistair Leslie-Hughes > >

Oct. 14, 2013

Re: [PATCH] d3drm: added some freeing of memory in error paths (Coverity)

by Henri Verbeet

On 13 October 2013 11:13, Marcus Meissner <marcus(a)jet.franken.de> wrote: > 1104553 Resource leak > Fixing the memory leak is fine of course, but I think it would be better to handle the array initialization in d3drm_visual_array_create() etc. instead, so that those functions actually return an object that's properly initialized.

Oct. 14, 2013

Re: [2/4] dnsapi/tests: Compile with -D__WINESRC__.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2733 Your paranoid android. === wxppro (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === wvista (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w2008s64 (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w7pro64 (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w864 (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w2008s64 (64 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w7pro64 (64 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w864 (64 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly

Oct. 14, 2013

Mono Update

by Alistair Leslie-Hughes

Hi, wine-mono hasn't been updated in nearly a year. Should it be time to consider a new release? Thoughts. Best Regards Alistair Leslie-Hughes

Oct. 14, 2013

Re: ntdll: Support pinning module refcount with LdrAddRefDll()

by Nikolay Sivov

On 10/14/2013 05:21, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> + FreeLibrary(mod); > Please add the tests for FreeLibrary return value. > Makes sense, thanks.

Oct. 14, 2013

Re: ntdll: Support pinning module refcount with LdrAddRefDll()

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + FreeLibrary(mod); Please add the tests for FreeLibrary return value. -- Dmitry.

Oct. 14, 2013

Re: MSYS touch.exe timestamp resolution issue on Wine-1.6

by Peter Rosin

On 2013-10-12 23:28, Alan W. Irwin wrote: > Under MSYS bash.exe if I use the touch command I only get 1-second > resolution when reading the results. > > bash.exe-3.1$ touch touch1.test touch2.test > bash.exe-3.1$ ls --full-time touch*.test > -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.000000000 -0700 touch1.test > -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.000000000 -0700 touch2.test > > Would somebody be willing to make the above test for MSYS on > the Microsoft version of Windows (which I don't have access to) to see > if time stamps are being read with 1-second resolution as above. That test > should help distinguish whether this is a Wine issue or else an MSYS > issue. I tested this on Windows 7, with MSYS 1.0.18, and I get the exact same experience. ls --full-time has a one second resolution (on NTFS, I expect a two second resolution on FAT, at least for some FAT variations). > I have also done some tests with the MSYS find.exe and make.exe > commands, and in all cases touch2.test is not newer than touch1.text. > This can be an important issue for the make command where one-second > time resolution can potentially screw up file dependencies. > > If I use the equivalent Linux ls (and find and make) commands to read the > time stamps on the above files, then touch2.test is newer than touch1.text, > e.g., Same here if I use an equivalent Cygwin ls, i.e. the actual time stamps are more fine grained than MSYS is capable of detecting. > wine(a)raven> ls --full-time touch*.test > -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.391000000 -0700 touch1.test > -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.408000000 -0700 touch2.test > > So I think this implies the MSYS touch.exe command is writing > high-resolution (i.e., millisecond) time stamps, and it is only > reading that high-resolution time stamp that seems to be an > issue for MSYS on Wine. Indeed. Since Cygwin has a different view, the situation should improve with MSYS 2. Cheers, Peter

Oct. 13, 2013

RE: d3d11 patch

by Max .

Hum... WIR= When it's ready ??? Ok ok, i still wait > From: frederic.delanoy(a)gmail.com > Date: Sun, 13 Oct 2013 01:49:04 +0200 > Subject: Re: d3d11 patch > To: asnlien(a)hotmail.com > CC: wine-devel(a)winehq.org > > On Fri, Oct 11, 2013 at 7:20 PM, Max . <asnlien(a)hotmail.com> wrote: > > Hi, > > > > I would like to know when the first patchs for d3d11 will be introduce into > > wine ? > > Beginning of 2014 ? middle 2014 ? End 2014 ? > > > > Thanks, > > WIR

Oct. 13, 2013

Clang Static analysis

by C.W. Betts

I have been doing a Clang static analysis of Wine on OS X using the one provided at http://clang-analyzer.llvm.org and storing the results on my PogoPlug drive. If someone wants to see the results, please tell me and I'll set up your e-mail. You will need a free PogoPlug account to view them. While the contents are zipped, they expand to about 1.2 GB. They are displayed as basic HTML pages, so you don't need anything special other than a web browser to see the results. Or you could click on this link for the analysis of 1.7.4: http://ppl.ug/ND-7PZ3cSzM/

Oct. 13, 2013

Re: *** GMX Spamverdacht *** MSYS touch.exe timestamp resolution issue on Wine-1.6

by Thorsten Kani

Am 12.10.2013 23:28, schrieb Alan W. Irwin: > Under MSYS bash.exe if I use the touch command I only get 1-second > resolution when reading the results. > > bash.exe-3.1$ touch touch1.test touch2.test > bash.exe-3.1$ ls --full-time touch*.test > -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.000000000 -0700 touch1.test > -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.000000000 -0700 touch2.test > > Would somebody be willing to make the above test for MSYS on > the Microsoft version of Windows (which I don't have access to) to see > if time stamps are being read with 1-second resolution as above. That > test > should help distinguish whether this is a Wine issue or else an MSYS > issue. > > I have also done some tests with the MSYS find.exe and make.exe > commands, and in all cases touch2.test is not newer than touch1.text. > This can be an important issue for the make command where one-second > time resolution can potentially screw up file dependencies. > > If I use the equivalent Linux ls (and find and make) commands to read the > time stamps on the above files, then touch2.test is newer than > touch1.text, > e.g., > > wine(a)raven> ls --full-time touch*.test > -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.391000000 -0700 touch1.test > -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.408000000 -0700 touch2.test > > So I think this implies the MSYS touch.exe command is writing > high-resolution (i.e., millisecond) time stamps, and it is only > reading that high-resolution time stamp that seems to be an > issue for MSYS on Wine. > > 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 > _________________________ Sure -- seems to be a MSYS issue though: root(a)me ~ $ touch touch1 touch2 root(a)me ~ $ ls --full-time touch* -rw-r--r-- 1 root Administratoren 0 2013-10-13 13:33:47.000000000 +0000 touch1 -rw-r--r-- 1 root Administratoren 0 2013-10-13 13:33:47.000000000 +0000 touch2 root(a)me ~ $ uname MINGW32_NT-6.1 root(a)me ~ $ Have a nice Day ! Thorsten

Oct. 13, 2013

Re: mscoree: Add support for ICLRMetaHostPolicy interface

by Dmitry Timoshkov

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > +static HRESULT WINAPI metahostpolicy_QueryInterface(ICLRMetaHostPolicy *iface, REFIID riid, void **ppvObject) > +{ > + TRACE("%s %p\n", debugstr_guid(riid), ppvObject); > + > + if ( IsEqualGUID( riid, &IID_ICLRMetaHostPolicy ) || > + IsEqualGUID( riid, &IID_IUnknown ) ) > + { > + *ppvObject = iface; > + } > + else > + { > + FIXME("Unsupported interface %s\n", debugstr_guid(riid)); > + return E_NOINTERFACE; > + } > + > + ICLRMetaHostPolicy_AddRef( iface ); > + > + return S_OK; > +} I think that a common COM convention is to set the object pointer to NULL in case of an unsupported interface. Also you're doing pretty good job in avoiding hungarian notation except for ppvObject. Another nitpick is the choice for if/else construct (although I understand that other places also use this sub-optimal one). A more elegant way of implementing QueryInterface would be IMHO: static HRESULT WINAPI xxx_QueryInterface(IFace *iface, REFIID riid, void **object) { if (IsEqualGUID(riid, &IID_IUnknown) || IsEqualGUID(riid, &IID_IAnotherSupported) { xxx_AddRef(iface); *object = iface; return S_OK; } *object = NULL; return E_NOINTERFACE; } -- Dmitry.

Oct. 13, 2013

Re: d3d11 patch

by Frédéric Delanoy

On Fri, Oct 11, 2013 at 7:20 PM, Max . <asnlien(a)hotmail.com> wrote: > Hi, > > I would like to know when the first patchs for d3d11 will be introduce into > wine ? > Beginning of 2014 ? middle 2014 ? End 2014 ? > > Thanks, WIR

Oct. 12, 2013

MSYS touch.exe timestamp resolution issue on Wine-1.6

by Alan W. Irwin

Under MSYS bash.exe if I use the touch command I only get 1-second resolution when reading the results. bash.exe-3.1$ touch touch1.test touch2.test bash.exe-3.1$ ls --full-time touch*.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.000000000 -0700 touch1.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.000000000 -0700 touch2.test Would somebody be willing to make the above test for MSYS on the Microsoft version of Windows (which I don't have access to) to see if time stamps are being read with 1-second resolution as above. That test should help distinguish whether this is a Wine issue or else an MSYS issue. I have also done some tests with the MSYS find.exe and make.exe commands, and in all cases touch2.test is not newer than touch1.text. This can be an important issue for the make command where one-second time resolution can potentially screw up file dependencies. If I use the equivalent Linux ls (and find and make) commands to read the time stamps on the above files, then touch2.test is newer than touch1.text, e.g., wine(a)raven> ls --full-time touch*.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.391000000 -0700 touch1.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.408000000 -0700 touch2.test So I think this implies the MSYS touch.exe command is writing high-resolution (i.e., millisecond) time stamps, and it is only reading that high-resolution time stamp that seems to be an issue for MSYS on Wine. 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 __________________________

Oct. 12, 2013

Re: winmm/tests: Use BOOL type where appropriate

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2721 Your paranoid android. === wxppro (32 bit wave) === wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 13211 bytes, should be 13230 wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 13229 bytes, should be 13230 wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 13075 bytes, should be 13230 wave.c:509: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 13091 samples (13091 bytes), should be 13230 (13230 bytes) wave.c:522: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 594 ms, (13108 bytes), should be 600 (13230 bytes) wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 13220 bytes, should be 13230 wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 17621 bytes, should be 17640 wave.c:509: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 17634 samples (17634 bytes), should be 17640 (17640 bytes) wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 22016 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 22027 samples (22027 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 999 ms, (22044 bytes), should be 1000 (22050 bytes)

Oct. 11, 2013

Re: wined3d: Use BOOL type where appropriate

by Henri Verbeet

On 11 October 2013 22:51, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > - DWORD onesided_enable = FALSE; > - DWORD twosided_enable = FALSE; > + DWORD onesided_enable = 0; > + DWORD twosided_enable = 0; Actually, all of those initializations are redundant.

Oct. 11, 2013

d3d11 patch

by Max .

Hi, I would like to know when the first patchs for d3d11 will be introduce into wine ? Beginning of 2014 ? middle 2014 ? End 2014 ? Thanks,

Oct. 11, 2013

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.

by Qian Hong

Hmm... It still fails today. I have a better idea to fix it, will send a patch tomorrow. Sorry for introducing the failures :(

Oct. 11, 2013

Fwd: Re: kernel32/tests: Add tests for job objects (try 7)

by Andrew Cook

(no idea why my client sent this to wine-patches) On 10/10/13 15:23, Andrew Cook wrote: > --- > dlls/kernel32/tests/process.c | 159 > +++++++++++++++++++++++++++++++++++++++++- > include/winbase.h | 1 + > include/winnt.h | 90 ++++++++++++++++++++++++ > 3 files changed, 249 insertions(+), 1 deletion(-) > > there appears to be a window between the all processes leaving a job and the job actually being considered empty, and no apparent way to wait for this. I can't reproduce this locally either. Is there an accepted way to wait for some inaccessible kernel-side event? reordering some calls would likely hide the issue but i'd rather avoid that. https://newtestbot.winehq.org/JobDetails.pl?Key=2687 failure on w8 https://newtestbot.winehq.org/JobDetails.pl?Key=2709 failure on w864 https://newtestbot.winehq.org/JobDetails.pl?Key=2685 same patch, success on w864

Oct. 11, 2013

RE: Help / Mentoring

by Hugh McMaster

Can anyone help me on this? I do realize that wineconsole is only a minor focus of development. Hugh ------------------------------------------------- Hi everyone, I just wanted to know if anyone would mind helping/mentoring me with a few small patches. I am working primarily on wineconsole's screen buffer problems (to which I believe I have the solution), but am also looking at implementing some stub Win32 console functions found in dlls/kernel32. Obviously, my aim is to have these patches committed, as the changes will benefit the entire Wine community. I had initially thought of Eric Poeuch, a significant wineconsole developer, however he appears to be extremely busy. So I'm not sure who else to contact. If time is a consideration, please note that I won't be constantly contacting you to review patches or answer questions. Thank you, Hugh

Oct. 11, 2013

Re: xmllite: Use BOOL type where appropriate

by Henri Verbeet

On 10 October 2013 16:59, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > Basically cleanup/clarity. Using boolean values when expressing > logical expressions results does make sense (and it makes the intent > clearer) IMHO. I just think it would have been nice if we could have used the C99 bool type, but clearly C99 is much too new for any real compilers to support.

Oct. 10, 2013

Re: xmllite: Use BOOL type where appropriate

by Frédéric Delanoy

On Thu, Oct 10, 2013 at 12:40 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On 10/10/2013 00:36, Frédéric Delanoy wrote: >> >> --- >> dlls/xmllite/reader.c | 16 ++++++++-------- >> 1 file changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/dlls/xmllite/reader.c b/dlls/xmllite/reader.c >> index 0a4423c..a216951 100644 >> --- a/dlls/xmllite/reader.c >> +++ b/dlls/xmllite/reader.c >> @@ -726,7 +726,7 @@ static void readerinput_grow(xmlreaderinput >> *readerinput, int length) >> } >> } >> -static inline int readerinput_is_utf8(xmlreaderinput *readerinput) >> +static inline BOOL readerinput_is_utf8(xmlreaderinput *readerinput) > > I don't actually see what this will achieve, but I see such patches are > accepted. Is it a new style rule? Basically cleanup/clarity. Using boolean values when expressing logical expressions results does make sense (and it makes the intent clearer) IMHO. The fact that it translates to integer values is just a C implementation/design detail. Why using an integer type when one only needs one of two truth values like TRUE/FALSE? -- Frédéric Delanoy

Oct. 10, 2013

Re: mshtml: Compile tests with __WINESRC__ define.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2689 Your paranoid android. === w864 (64 bit activex) === activex.c:1346: Test failed: unexpected call SetObjectRects === wxppro (32 bit htmldoc) === htmldoc.c:2898: Test failed: mon(0026BFD0) != exmon(00269670) htmldoc.c:7601: Test failed: mon(0026BFD0) != exmon(00269670) htmldoc.c:5978: Test failed: mon(0026BFD0) != exmon(00269670) htmldoc.c:2898: Test failed: mon(0029CA28) != exmon(00286FF8) htmldoc.c:7601: Test failed: mon(0029CA28) != exmon(00286FF8) htmldoc.c:5978: Test failed: mon(0029CA28) != exmon(00286FF8) === wvista (32 bit htmldoc) === No test summary line found === w7pro64 (32 bit htmldoc) === No test summary line found

Oct. 10, 2013

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.

by Qian Hong

On Thu, Oct 10, 2013 at 8:42 PM, Qian Hong <qhong(a)codeweavers.com> wrote: > Sorry for introduced the failures, I'd like to investigate, however I > can't reproduce the failures on my own Win7. I try to run > winetest-latest.exe on the testbot, but it ran timeout (as expect), is > there any way I can increase the timeout value from 120 to something > like 1800? Oh, forgot to say: the test failures are most likely caused by side effects of other tests, I can't reproduce it on our testbots if only winstation tests are executed, that is why I asked for increasing the timeout so I can run a full test of winetest-latest.exe -- Regards, Qian Hong - http://www.codeweavers.com

Oct. 10, 2013

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.

by Qian Hong

Hello, On Thu, Oct 10, 2013 at 6:48 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Can you please fix the test failures introduced by your previous changes > first? cf. https://test.winehq.org/data/tests/user32:winstation.html Sorry for introduced the failures, I'd like to investigate, however I can't reproduce the failures on my own Win7. I try to run winetest-latest.exe on the testbot, but it ran timeout (as expect), is there any way I can increase the timeout value from 120 to something like 1800? Thanks! -- Regards, Qian Hong - http://www.codeweavers.com

Oct. 10, 2013

Re: ieframe: Compile tests with __WINESRC__ define.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2688 Your paranoid android. === wxppro (32 bit webbrowser) === webbrowser.c:792: Test failed: ReadyState = 1, expected 4

Oct. 10, 2013

Re: wmvcore: Stub implementation of IWMMetadataEditor interface

by Nikolay Sivov

On 10/10/2013 14:58, Jeff Latimer wrote: > --- > dlls/wmvcore/Makefile.in | 2 +- > dlls/wmvcore/wmvcore_main.c | 100 > +++++++++++++++++++++++++++++++++++++++++++- > include/wmsdkidl.idl | 11 ++--- > 3 files changed, 105 insertions(+), 8 deletions(-) > +typedef struct MetadataEditorImpl { > + IWMMetadataEditor MetadataEditor_iface; > + LONG ref; > +} MetadataEditorImpl; > +static inline MetadataEditorImpl *impl_from_MetadataEditor(IWMMetadataEditor *iface) Please follow naming convetions for interfaces. > +HRESULT WINAPI WMCreateEditor_close(IWMMetadataEditor *iface) > +{ > + FIXME("iface=%p\n", iface); > + HeapFree(GetProcessHeap(), 0, iface); > + return S_OK; > +} > +HRESULT WINAPI WMCreateEditor_flush(IWMMetadataEditor *iface) > +{ > + FIXME("iface=%p\n", iface); > + HeapFree(GetProcessHeap(), 0, iface); > + return S_OK; > +} This looks totally wrong. Also please keep implementation functions order and interface methods order the same.

Oct. 10, 2013

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.

by Alexandre Julliard

Qian Hong <qhong(a)codeweavers.com> writes: > --- > dlls/user32/tests/winstation.c | 57 > ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 57 insertions(+) Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html -- Alexandre Julliard julliard(a)winehq.org

Oct. 10, 2013

Re: xmllite: Use BOOL type where appropriate

by Nikolay Sivov

On 10/10/2013 00:36, Frédéric Delanoy wrote: > --- > dlls/xmllite/reader.c | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/dlls/xmllite/reader.c b/dlls/xmllite/reader.c > index 0a4423c..a216951 100644 > --- a/dlls/xmllite/reader.c > +++ b/dlls/xmllite/reader.c > @@ -726,7 +726,7 @@ static void readerinput_grow(xmlreaderinput *readerinput, int length) > } > } > > -static inline int readerinput_is_utf8(xmlreaderinput *readerinput) > +static inline BOOL readerinput_is_utf8(xmlreaderinput *readerinput) > { > static char startA[] = {'<','?'}; > static char commentA[] = {'<','!'}; > @@ -953,7 +953,7 @@ static void reader_skipn(xmlreader *reader, int n) > } > } > > -static inline int is_wchar_space(WCHAR ch) > +static inline BOOL is_wchar_space(WCHAR ch) > { > return ch == ' ' || ch == '\t' || ch == '\r' || ch == '\n'; > } > @@ -1055,7 +1055,7 @@ static HRESULT reader_parse_versioninfo(xmlreader *reader) > } > > /* ([A-Za-z0-9._] | '-') */ > -static inline int is_wchar_encname(WCHAR ch) > +static inline BOOL is_wchar_encname(WCHAR ch) > { > return ((ch >= 'A' && ch <= 'Z') || > (ch >= 'a' && ch <= 'z') || > @@ -1269,7 +1269,7 @@ static HRESULT reader_parse_comment(xmlreader *reader) > } > > /* [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] */ > -static inline int is_char(WCHAR ch) > +static inline BOOL is_char(WCHAR ch) > { > return (ch == '\t') || (ch == '\r') || (ch == '\n') || > (ch >= 0x20 && ch <= 0xd7ff) || > @@ -1279,7 +1279,7 @@ static inline int is_char(WCHAR ch) > } > > /* [13] PubidChar ::= #x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%] */ > -static inline int is_pubchar(WCHAR ch) > +static inline BOOL is_pubchar(WCHAR ch) > { > return (ch == ' ') || > (ch >= 'a' && ch <= 'z') || > @@ -1292,7 +1292,7 @@ static inline int is_pubchar(WCHAR ch) > (ch == '_') || (ch == '\r') || (ch == '\n'); > } > > -static inline int is_namestartchar(WCHAR ch) > +static inline BOOL is_namestartchar(WCHAR ch) > { > return (ch == ':') || (ch >= 'A' && ch <= 'Z') || > (ch == '_') || (ch >= 'a' && ch <= 'z') || > @@ -1312,7 +1312,7 @@ static inline int is_namestartchar(WCHAR ch) > } > > /* [4 NS] NCName ::= Name - (Char* ':' Char*) */ > -static inline int is_ncnamechar(WCHAR ch) > +static inline BOOL is_ncnamechar(WCHAR ch) > { > return (ch >= 'A' && ch <= 'Z') || > (ch == '_') || (ch >= 'a' && ch <= 'z') || > @@ -1336,7 +1336,7 @@ static inline int is_ncnamechar(WCHAR ch) > (ch >= 0xfdf0 && ch <= 0xfffd); > } > > -static inline int is_namechar(WCHAR ch) > +static inline BOOL is_namechar(WCHAR ch) > { > return (ch == ':') || is_ncnamechar(ch); > } I don't actually see what this will achieve, but I see such patches are accepted. Is it a new style rule?

Oct. 10, 2013

Re: [PATCH 5/5] user32: Implement better stub of OpenInputDesktop.

by Qian Hong

Hi Vincent, Thanks a lot for the advice, I'll try that. On Thu, Oct 10, 2013 at 12:41 AM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > I don't think it's possible to properly implement SwitchDesktop in > either the X11 or Mac driver. There's just nothing sensible for it to > do. > That's one reason that I didn't try to implement SwitchDesktop, I was not very sure about this, thanks for confirming. > One possible strategy would be to implement SwitchDesktop in user32 > and wineserver. Wineserver could logically track the input desktop, > and OpenInputDesktop would return the "correct" desktop, but > SwitchDesktop wouldn't really do anything. If in the future we decide > there's something SwitchDesktop can do that makes sense, we can add a > function for it to the user driver, and OpenInputDesktop probably > won't need to change. I ever though about this, but gave up. After more thought, I agree that this is a better approach, thanks again! -- Regards, Qian Hong - http://www.codeweavers.com

Oct. 10, 2013

Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.

by Phil Krylov

Hello, On Thu, Oct 10, 2013 at 3:24 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Oct 9, 2013, at 4:49 PM, Phil Krylov wrote: >> Do you consider adding an option to stop interpreting Command as Alt? > > I have not considered it. What would be gained? Do you want the Command key interpreted as the Windows key? Do you want something else to happen when Command is pressed? Every time I press Cmd-Space to switch keyboard layouts, Wine activates menu as if I would have pressed Alt, so I have to press Command once again to exit it. It does not happen in Windows, though, when I use Alt-Shift to switch layouts, so the real problem is not related to Alt interpretation of Cmd, but to incorrect emulation of Windows behaviour when a keyboard layout switch hotkey is pressed. On the other hand, Option is labeled as Alt, and works this way with the X11 driver, so it seems logical to process Cmd as Win key. And it would hack around my actual problem ;) -- Ph.

Oct. 10, 2013

Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().

by Ralf Habacker

On 01.10.2013 12:12, Alexandre Julliard wrote: > Ralf Habacker <ralf.habacker(a)freenet.de> writes: > >> With other patches i have been told to implement such stuff in the dib >> driver. Unfortunally this do not works in this case, because in the top >> level function it looks like having driver specific stuff using display >> coordinates. > It would still most likely have to be in the driver, though maybe the > driver would not be calling that exact entry point. In any case, you > can't change the DC transform like this. You are refering to the usage of setting hard coded values ? Instead I should decompose the rotation and reset only that part ? Ralf

Oct. 10, 2013

Re: kernel32/tests: Add tests for job objects (try 7)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2683 Your paranoid android. === w864 (64 bit process) === process.c:2092: Test failed: Unexpected completion event: 6, 0000000000000158, 00000000000002F0

Oct. 10, 2013

Re: ddraw/tests: Use BOOL type where appropriate

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2682 Your paranoid android. === wxppro (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === wvista (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w2008s64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w7pro64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag

Oct. 9, 2013

Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.

by Ken Thomases

On Oct 9, 2013, at 4:49 PM, Phil Krylov wrote: > Thanks! You're welcome. > Do you consider adding an option to stop interpreting Command as Alt? I have not considered it. What would be gained? Do you want the Command key interpreted as the Windows key? Do you want something else to happen when Command is pressed? Cheers, Ken

Oct. 9, 2013

Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.

by Phil Krylov

Thanks! Do you consider adding an option to stop interpreting Command as Alt? On Thu, Oct 10, 2013 at 1:30 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > --- > dlls/winemac.drv/cocoa_window.m | 22 ++++++++++++++++++++-- > dlls/winemac.drv/macdrv_cocoa.h | 2 ++ > dlls/winemac.drv/macdrv_main.c | 7 +++++++ > 3 files changed, 29 insertions(+), 2 deletions(-) > > > > -- С уважением, Филипп Крылов.

Oct. 9, 2013

Re: [PATCH 5/5] user32: Implement better stub of OpenInputDesktop.

by Vincent Povirk

I don't think it's possible to properly implement SwitchDesktop in either the X11 or Mac driver. There's just nothing sensible for it to do. One possible strategy would be to implement SwitchDesktop in user32 and wineserver. Wineserver could logically track the input desktop, and OpenInputDesktop would return the "correct" desktop, but SwitchDesktop wouldn't really do anything. If in the future we decide there's something SwitchDesktop can do that makes sense, we can add a function for it to the user driver, and OpenInputDesktop probably won't need to change.

Oct. 9, 2013

Re: [PATCH] d3dx9: Move object initialization into a separate function.

by Matteo Bruni

2013/10/9 Rico Schüller <kgbricola(a)web.de>: > On 09.10.2013 01:12, Matteo Bruni wrote: >> >> Hi Rico, >> >> 2013/10/8 Rico Schüller <kgbricola(a)web.de>: >>> >>> Hi, >>> >>> this moves the object initialization into a separate function, so it >>> could >>> be used for strings and resources. It also removes the STATE_TYPE as we >>> could distinguish the types at the object level. >>> >>> 1. When an object has a destination, it points to another shader >>> variable. >>> This was state ST_PARAMETER. >>> >>> 2. If a variable has something in data, it is fxlc, shader (preshader) or >>> a >>> string. This was state ST_CONSTANT and ST_FXLC. >>> >>> 3. If it has both (destination and data), it points to an array of shader >>> variables. The name is in the destination, the index could be calculated >>> with the data. This will be added in a later patch. >>> >> >> There's still the issue of distinguishing between ST_CONSTANT and >> ST_FXLC, checking object_id and type might cover that though. > > I think we could distinguish between them. I forgot to add, if both are 0, > then it is a constant and the parameter data has already the correct value. > Marking the shader as ST_CONSTANT was a little bit wrong, as we would need > to set the shader/preshader variables. > > >> >>> Also saving the destination parameter in the object gains some speed when >>> we >>> need to access the variable as we don't need to run >>> get_parameter_by_name() >>> each time we need the variable ... >>> >> >> I'm not sure storing additional info into the objects is the right >> thing to do. Take a look at the D3DXFX_NOT_CLONEABLE flag from >> >> http://msdn.microsoft.com/en-us/library/windows/desktop/bb172855%28v=vs.85%…. >> Notice that GetPassDesc() doesn't return the shader data if the object >> was created with the flag. What I've been thinking is that it simply >> can't because the original shader data, stored in an object, were >> freed after parsing. > > Yeah, I'm aware of D3DXFX_NOT_CLONEABLE. But we need to hold the shader blob > or something similar (a reflection of the used preshader variables) to set > the correct values. We also need it in the case for when the parameter needs > to be calculated (fxlc) and in for strings. So imho, we could only release > the blob partially when we have a preshader, nowhere else (and in this case > we still need the "reflection" somehow). So let me conclude: We need to > store the "destination" and the "reflection" somewhere. We may release the > full shader binary. > Yeah, we need to store something for those cases, but not necessarily the original shader blob (we could store some derived information instead). So I essentially agree here. > >> While nothing forces us to do the same (except probably avoiding to >> use more memory than strictly necessary) I think it's better not to >> put additional stuff into the objects or generally assume that the >> objects are still available after parsing. That means creating the >> shaders and the strings at parse time or right after that and storing >> any additional required information (e.g. preshader) in the parameter. >> >> So, directly storing the referenced parameter is a good idea but I'd >> prefer that pointer to be in d3dx_parameter. > > I haven't put it in the parameter as there are much more parameters than > objects. Each state, each array element and each structure member has a > parameter while there are only some parameters that have objects. So we may > use some more bytes when putting it in the parameter than putting it in the > object. > True, my point is that the memory reclaimed by freeing the objects is probably more than the memory wasted by some additional pointers. I don't have any hard data though (and applications might "forget" to specify D3DXFX_NOT_CLONEABLE) so I might be wrong. > I'm fine with both ways, because each object is tight to a specific > parameter, it's mostly a matter of taste where the data is stored. > > Cheers > Rico

Oct. 9, 2013

Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().

by Ralf Habacker

On 01.10.2013 12:40, Alexandre Julliard wrote: > Ralf Habacker <ralf(a)habacker.de> writes: > >> On 01.10.2013 12:12, Alexandre Julliard wrote: >>> Ralf Habacker <ralf.habacker(a)freenet.de> writes: >>> >>>> With other patches i have been told to implement such stuff in the dib >>>> driver. Unfortunally this do not works in this case, because in the top >>>> level function it looks like having driver specific stuff using display >>>> coordinates. >>> It would still most likely have to be in the driver, >> which is freetype_GetTextExtentExPoint() ? >> >>> though maybe the driver would not be calling that exact entry point. >> not sure i understand right: >> >> GetTextExtentExPointW() calls get_char_positions(), which runs >> dev->funcs->pGetTextExtentExPoint(), which is mapped to >> freetype_GetTextExtentExPoint(), which is in the driver. Which entry >> point your are refering else ? > The various text rendering entry points in the graphics drivers. You mean there are more affected places ? > >>> In any case, you can't change the DC transform like this >> then a real solution requires to move the transformation to logical >> coordinates stuff in BOOL GetTextExtentExPointW() to >> freetype_GetTextExtentExPoint() and to manipulate the related matrixes >> in freetype_GetTextExtentExPoint() directly wen using GM_ADVANCED ? > No, I don't think so. The transform is only used to determine the font > scaling factor. the recent implementation of get_glyph_outline() uses in GM_ADVANCED mode a scale which depends somehow on the rotation angle. I got better results with saving the "use GM_ADVANCED case" in font->font_desc.advanced_graphics_mode and the following hunks for freetype.c @@ -6426,10 +6426,24 @@ static DWORD get_glyph_outline(GdiFont *incoming_font, UINT glyph, UINT format, worldMat.xy = -FTFixedFromFloat(font->font_desc.matrix.eM21); worldMat.yx = -FTFixedFromFloat(font->font_desc.matrix.eM12); worldMat.yy = FTFixedFromFloat(font->font_desc.matrix.eM22); pFT_Matrix_Multiply(&worldMat, &transMat); - pFT_Matrix_Multiply(&worldMat, &transMatUnrotated); pFT_Matrix_Multiply(&worldMat, &transMatTategaki); - needsTransform = TRUE; + if (font->font_desc.advanced_graphics_mode) { + worldMat.xx = FTFixedFromFloat(1.0/font->font_desc.matrix.eM11); + worldMat.xy = -FTFixedFromFloat(font->font_desc.matrix.eM21); + worldMat.yx = -FTFixedFromFloat(font->font_desc.matrix.eM12); + worldMat.yy = FTFixedFromFloat(1.0/font->font_desc.matrix.eM22); + } + else { + worldMat = identityMat; + } + + pFT_Matrix_Multiply(&worldMat, &transMatUnrotated); + needsTransform = TRUE; } and @@ -6571,35 +6590,50 @@ static DWORD get_glyph_outline(GdiFont *incoming_font, UINT glyph, UINT format, origin_y = top; } + if (font->font_desc.advanced_graphics_mode) + pFT_Vector_Transform(&vec, &transMatUnrotated); + else + pFT_Vector_Transform(&vec, &transMat); + which works except for using 90° and 270° world transformations angles. Transforming back the list of character width in the top level function GetTextExtentExPointW(). The transformation is done with static inline INT INTERNAL_XDSTOWS(DC *dc, INT width) { double floatWidth; floatWidth = (double)width * dc->xformVport2World.eM11; /* Round to integers */ return GDI_ROUND(floatWidth); } dc->xformVport2World.eM11 is zero in the mentioned angles, so it will always return zero, which means at now the submitted patch is the only working solution. >From what i can see an alternative would require to move the device to logical back transformation into get_glyph_outline() and to refactor all function get_glyph_outline() is called from. Regards Ralf

Oct. 9, 2013

Re: winspool: ERROR_INVALID_NAME in GetDefaultPrinter() ?

by Hamzat

Dears, I faced the same problem, but, unfortunally, link to answer is invalid. Please, tell me, how did you resolve situation? Thanks. -- View this message in context: http://wine.1045685.n5.nabble.com/winspool-ERROR-INVALID-NAME-in-GetDefault… Sent from the Wine - Devel mailing list archive at Nabble.com.

Oct. 9, 2013

Help / Mentoring

by Hugh McMaster

Hi everyone, I just wanted to know if anyone would mind helping/mentoring me with a few small patches. I am working primarily on wineconsole's screen buffer problems (to which I believe I have the solution), but am also looking at implementing some stub Win32 console functions found in dlls/kernel32. Obviously, my aim is to have these patches committed, as the changes will benefit the entire Wine community. I had initially thought of Eric Poeuch, a significant wineconsole developer, however he appears to be extremely busy. So I'm not sure who else to contact. If time is a consideration, please note that I won't be constantly contacting you to review patches or answer questions. Thank you, Hugh

Oct. 9, 2013

Re: [PATCH 4/5] d3drm: Compare with the correct IID in IDirect3DRMVisualArrayImpl_QueryInterface().

by Henri Verbeet

On 9 October 2013 11:26, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > >> +static HRESULT WINAPI IDirect3DRMVisualArrayImpl_QueryInterface(IDirect3DRMVisualArray *iface, REFIID riid, void **out) >> { >> - TRACE("(%p)->(%s, %p)\n", iface, debugstr_guid(riid), ret_iface); >> + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); >> >> - if (IsEqualGUID(riid, &IID_IUnknown) || >> - IsEqualGUID(riid, &IID_IDirect3DRMFrameArray)) >> + if (IsEqualGUID(riid, &IID_IDirect3DRMVisualArray) >> + || IsEqualGUID(riid, &IID_IUnknown)) >> { >> - *ret_iface = iface; >> IDirect3DRMVisualArray_AddRef(iface); >> + *out = iface; >> return S_OK; >> } > > Although this is existing code the assignment '*out = iface' is wrong, > especially since next patch introduces impl_from_IDirect3DRMVisualArray() > helper. Looks like that file needs a bit of COM clean up. > The entire dll needs some cleanup in general, but that assignment is correct, since it's querying for the same interface that gets passed in.

Oct. 9, 2013

Re: [PATCH 4/5] d3drm: Compare with the correct IID in IDirect3DRMVisualArrayImpl_QueryInterface().

by Dmitry Timoshkov

Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > +static HRESULT WINAPI IDirect3DRMVisualArrayImpl_QueryInterface(IDirect3DRMVisualArray *iface, REFIID riid, void **out) > { > - TRACE("(%p)->(%s, %p)\n", iface, debugstr_guid(riid), ret_iface); > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > > - if (IsEqualGUID(riid, &IID_IUnknown) || > - IsEqualGUID(riid, &IID_IDirect3DRMFrameArray)) > + if (IsEqualGUID(riid, &IID_IDirect3DRMVisualArray) > + || IsEqualGUID(riid, &IID_IUnknown)) > { > - *ret_iface = iface; > IDirect3DRMVisualArray_AddRef(iface); > + *out = iface; > return S_OK; > } Although this is existing code the assignment '*out = iface' is wrong, especially since next patch introduces impl_from_IDirect3DRMVisualArray() helper. Looks like that file needs a bit of COM clean up. -- Dmitry.

Oct. 9, 2013

Re: [PATCH] d3dx9: Move object initialization into a separate function.

by Rico Schüller

On 09.10.2013 01:12, Matteo Bruni wrote: > Hi Rico, > > 2013/10/8 Rico Schüller <kgbricola(a)web.de>: >> Hi, >> >> this moves the object initialization into a separate function, so it could >> be used for strings and resources. It also removes the STATE_TYPE as we >> could distinguish the types at the object level. >> >> 1. When an object has a destination, it points to another shader variable. >> This was state ST_PARAMETER. >> >> 2. If a variable has something in data, it is fxlc, shader (preshader) or a >> string. This was state ST_CONSTANT and ST_FXLC. >> >> 3. If it has both (destination and data), it points to an array of shader >> variables. The name is in the destination, the index could be calculated >> with the data. This will be added in a later patch. >> > > There's still the issue of distinguishing between ST_CONSTANT and > ST_FXLC, checking object_id and type might cover that though. I think we could distinguish between them. I forgot to add, if both are 0, then it is a constant and the parameter data has already the correct value. Marking the shader as ST_CONSTANT was a little bit wrong, as we would need to set the shader/preshader variables. > >> Also saving the destination parameter in the object gains some speed when we >> need to access the variable as we don't need to run get_parameter_by_name() >> each time we need the variable ... >> > > I'm not sure storing additional info into the objects is the right > thing to do. Take a look at the D3DXFX_NOT_CLONEABLE flag from > http://msdn.microsoft.com/en-us/library/windows/desktop/bb172855%28v=vs.85%…. > Notice that GetPassDesc() doesn't return the shader data if the object > was created with the flag. What I've been thinking is that it simply > can't because the original shader data, stored in an object, were > freed after parsing. Yeah, I'm aware of D3DXFX_NOT_CLONEABLE. But we need to hold the shader blob or something similar (a reflection of the used preshader variables) to set the correct values. We also need it in the case for when the parameter needs to be calculated (fxlc) and in for strings. So imho, we could only release the blob partially when we have a preshader, nowhere else (and in this case we still need the "reflection" somehow). So let me conclude: We need to store the "destination" and the "reflection" somewhere. We may release the full shader binary. > While nothing forces us to do the same (except probably avoiding to > use more memory than strictly necessary) I think it's better not to > put additional stuff into the objects or generally assume that the > objects are still available after parsing. That means creating the > shaders and the strings at parse time or right after that and storing > any additional required information (e.g. preshader) in the parameter. > > So, directly storing the referenced parameter is a good idea but I'd > prefer that pointer to be in d3dx_parameter. I haven't put it in the parameter as there are much more parameters than objects. Each state, each array element and each structure member has a parameter while there are only some parameters that have objects. So we may use some more bytes when putting it in the parameter than putting it in the object. I'm fine with both ways, because each object is tight to a specific parameter, it's mostly a matter of taste where the data is stored. Cheers Rico

Oct. 9, 2013

Re: ws2_32/tests: Use BOOL type where appropriate

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2674 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (bc): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (2c8): unexpectedly at the OOB mark: 0 === w7pro64 (32 bit sock) === sock.c:509: Test failed: oob_server (8a4): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (8a4): unexpectedly at the OOB mark: 0 === w864 (32 bit sock) === sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (118): unexpectedly at the OOB mark: 0

Oct. 9, 2013

Re: [PATCH] d3dx9: Move object initialization into a separate function.

by Matteo Bruni

Hi Rico, 2013/10/8 Rico Schüller <kgbricola(a)web.de>: > Hi, > > this moves the object initialization into a separate function, so it could > be used for strings and resources. It also removes the STATE_TYPE as we > could distinguish the types at the object level. > > 1. When an object has a destination, it points to another shader variable. > This was state ST_PARAMETER. > > 2. If a variable has something in data, it is fxlc, shader (preshader) or a > string. This was state ST_CONSTANT and ST_FXLC. > > 3. If it has both (destination and data), it points to an array of shader > variables. The name is in the destination, the index could be calculated > with the data. This will be added in a later patch. > There's still the issue of distinguishing between ST_CONSTANT and ST_FXLC, checking object_id and type might cover that though. > Also saving the destination parameter in the object gains some speed when we > need to access the variable as we don't need to run get_parameter_by_name() > each time we need the variable ... > I'm not sure storing additional info into the objects is the right thing to do. Take a look at the D3DXFX_NOT_CLONEABLE flag from http://msdn.microsoft.com/en-us/library/windows/desktop/bb172855%28v=vs.85%…. Notice that GetPassDesc() doesn't return the shader data if the object was created with the flag. What I've been thinking is that it simply can't because the original shader data, stored in an object, were freed after parsing. While nothing forces us to do the same (except probably avoiding to use more memory than strictly necessary) I think it's better not to put additional stuff into the objects or generally assume that the objects are still available after parsing. That means creating the shaders and the strings at parse time or right after that and storing any additional required information (e.g. preshader) in the parameter. So, directly storing the referenced parameter is a good idea but I'd prefer that pointer to be in d3dx_parameter. > Cheers > Rico > > --- > dlls/d3dx9_36/effect.c | 98 > ++++++++++++++++++-------------------------------- > 1 Datei geändert, 34 Zeilen hinzugefügt(+), 64 Zeilen entfernt(-) > Cheers, Matteo

Oct. 8, 2013

Re: [PATCH 5/5] user32: Implement better stub of OpenInputDesktop.

by Qian Hong

Hello, this patch is in pending status, is there any way I can improve it? IMO there is no way to 'correctly' implement OpenInputDesktop before implementing SwitchDesktop, as far as SwitchDesktop is a stub, it is safe to assume that OpenInputDesktop will always return either NULL or Winsta0/Default, that is what the patch does and what the tests in [PATCH 3/5] shows.. It is not trivial to implement SwitchDesktop, also I don't know any real world app needing SwitchDesktop except some virtual desktop manager, so I'm not sure it is worth to spend time on implementing SwitchDesktop. However, OpenInputDesktop is needed by multiple apps (TeamViewer, QQ International, Inspect tool from Windows Platform SDK as bug 12067), is it acceptable to submit such a 'better stub' to Wine and leaving SwitchDesktop as a stub? Any comment is great appreciated! On Tue, Oct 8, 2013 at 11:41 AM, Qian Hong <qhong(a)codeweavers.com> wrote: > Fixed http://bugs.winehq.org/show_bug.cgi?id=12067 , let QQ users happy :) > > --- > dlls/user32/tests/winstation.c | 22 ---------------------- > dlls/user32/winstation.c | 22 +++++++++++++++++++--- > 2 files changed, 19 insertions(+), 25 deletions(-) > > -- Regards, Qian Hong - http://www.codeweavers.com

Oct. 8, 2013

Re: Wrong status of gdi32

by Austin English

On Tue, Oct 8, 2013 at 11:54 AM, C.W. Betts <computers57(a)hotmail.com> wrote: > Some of those are probably Wine-specific, and/or are forwarded from other > DLLs. > > On Oct 8, 2013, at 8:35 AM, Akira Nakagawa <matyapiro31(a)gmail.com> wrote: > > I found this page shows that gdi32 dll has more than 800 functions,but the > spec file has only 500 . That info is from the windows 8 dll, not wine's. Wine doesn't implement the full win32 API, only what is needed to run applications. If you've got an application that doesn't run because of a missing gdi32 function, please report it to bugzilla: https://bugs.winehq.org -- -Austin

Oct. 8, 2013

Re: Wrong status of gdi32

by C.W. Betts

Some of those are probably Wine-specific, and/or are forwarded from other DLLs. On Oct 8, 2013, at 8:35 AM, Akira Nakagawa <matyapiro31(a)gmail.com> wrote: > I found this page shows that gdi32 dll has more than 800 functions,but the spec file has only 500 . > >

Oct. 8, 2013

RE: binfmt support

by xantares 09

From: xantares09(a)hotmail.com To: hverbeet(a)gmail.com Subject: RE: binfmt support Date: Mon, 7 Oct 2013 11:47:05 +0000 > Date: Mon, 7 Oct 2013 12:23:30 +0200 > Subject: Re: binfmt support > From: hverbeet(a)gmail.com > To: xantares09(a)hotmail.com > CC: wine-devel(a)winehq.org > > On 7 October 2013 12:06, xantares 09 <xantares09(a)hotmail.com> wrote: > > ... I don't see a reason why to not include it at the wine level instead of > > every linux distros, see: > > https://github.com/xantares/wine/commit/76ebd5d29effaf4b6b39ceecb689f7008bf… > > > > What do you think ? > > > Ignoring the discussion if we want this or not for the moment, I'd > guess this would break as soon as you pass something other than /usr > for --prefix to configure. Yes, It'll only work when prefix=/usr, which is always what happens when building packaging. This is what we want ; we still want to honor the prefix var. x.

Oct. 8, 2013

Re: gdi32/tests: Skip linked font like SimSun-ExtB in fixed-pitch font selection.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2669 Your paranoid android. === wvista (32 bit font) === The test timed out === w2008s64 (32 bit font) === Timeout Failure running script in VM: network read timed out

Oct. 8, 2013

Wrong status of gdi32

by Akira Nakagawa

I found this page <http://www.nirsoft.net/dll_information/windows8/gdi32_dll.html> shows that gdi32 dll has more than 800 functions,but the spec file has only 500 .

Oct. 8, 2013

Re: (try 6)[3/5] imm32: use thread data from target HWND

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -1597,7 +1612,9 @@ BOOL WINAPI ImmGetConversionStatus( > HWND WINAPI ImmGetDefaultIMEWnd(HWND hWnd) > { > HWND ret; > - IMMThreadData* thread_data = IMM_GetThreadData(0); > + IMMThreadData* thread_data = IMM_GetThreadDataForWindow(hWnd); > + if (!thread_data) > + return NULL; > if (thread_data->hwndDefault == NULL) > thread_data->hwndDefault = CreateWindowExW( WS_EX_TOOLWINDOW, > szwIME, NULL, WS_POPUP, 0, 0, 1, 1, 0, 0, 0, 0); It doesn't seem right to create the default window from a different thread. -- Alexandre Julliard julliard(a)winehq.org

Oct. 8, 2013

Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.

by Henri Verbeet

On 8 October 2013 13:44, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Are you sure? E.g. if a texture is used with srgb=true and sRGB_decode > is supported, wined3d_texture_bind sets WINED3D_TEXTURE_IS_SRGB. If > the application later calls PreLoad manually, texture2d_preload is > called with SRGB_ANY. Because of the set IS_SRGB flag it chooses to > load the srgb copy. It correctly uses the rgb texture structure and > binds the rgb GL texture, but still passes srgb=true to > surface_load(), which results in SFLAG_INSRGBTEX being passed to > surface_load_location, even though we want to load the RGB copy. > Right. It should be pretty easy to fix that by taking EXT_TEXTURE_SRGB_DECODE into account in texture_srgb_mode() though.

Oct. 8, 2013

Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-10-08 12:06, schrieb Henri Verbeet: > On 8 October 2013 00:27, Stefan Dösinger <stefan(a)codeweavers.com> > wrote: >> diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c >> index 52eac16..eb8ca7e 100644 --- a/dlls/wined3d/surface.c +++ >> b/dlls/wined3d/surface.c @@ -5608,8 +5608,6 @@ HRESULT >> surface_load_location(struct wined3d_surface *surface, DWORD >> location, c } } >> >> - if (location == SFLAG_INSRGBTEX && >> gl_info->supported[EXT_TEXTURE_SRGB_DECODE]) - location = >> SFLAG_INTEXTURE; >> >> if (surface->flags & location) { @@ -5671,12 +5669,6 @@ HRESULT >> surface_load_location(struct wined3d_surface *surface, DWORD >> location, c surface_evict_sysmem(surface); } >> >> - if (surface->flags & (SFLAG_INTEXTURE | SFLAG_INSRGBTEX) - >> && gl_info->supported[EXT_TEXTURE_SRGB_DECODE]) - { - >> surface->flags |= (SFLAG_INTEXTURE | SFLAG_INSRGBTEX); - } - >> return WINED3D_OK; } >> > This change seems good on its own, as far as I can tell all > callers already handle this correctly. Are you sure? E.g. if a texture is used with srgb=true and sRGB_decode is supported, wined3d_texture_bind sets WINED3D_TEXTURE_IS_SRGB. If the application later calls PreLoad manually, texture2d_preload is called with SRGB_ANY. Because of the set IS_SRGB flag it chooses to load the srgb copy. It correctly uses the rgb texture structure and binds the rgb GL texture, but still passes srgb=true to surface_load(), which results in SFLAG_INSRGBTEX being passed to surface_load_location, even though we want to load the RGB copy. I'll see if I can simplify the sRGB_decode handling while still keeping it in the texture. Patches 4 and 5 should apply without this one by the way. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSU/AfAAoJEN0/YqbEcdMwIP8P/iJUb9d3dfTQgdDAYNSx0fFc wp7tJZSZKDNlSLz8oTNx7k2Lmcv7ZSInce+R1oaGxS7QjkhxD7U25CdnvgaXV+Oy IInOFuauZ7m6zO+FfBbHd9ujM1pC1Mi7BtsE59LNypJT9ym6iqe2MLocLUjDCfbL koro3I3rzjkMb3XVUQapMevobYBr0jfl3G3q7zirrVuh1fYnL3a1Ge4ckIGsRneL 98ZjmcQyfT8lo9zxtwXPTOR23j1oLnJDNWhn63he1sX6Vg7XQvPZwszXwbN30Jof CjbrTzBmaKq/yY4jXnffu84tDygvWFr0a9sklX7qtaGd4cNBaiSscR6gBAgvZQdI 1533llMChhOqIUBrS5i8d3t24DLdAzd6PiD4LBCjJXzqfTiqWp3JjChR9FUvq+P1 G5gEldxF+MHPXKhZgpq1MoAy13NDYAFNT/EZSgIH/yRGcm9qVTnI98A6gFZnvel4 DQ3p05mMN4dSvGsQJt/l42k8I5IT1nYqetE1ybZd/45LgHKyjYc80z8lt6f0fhrS j9KtY3Pu6Ks8hIjsIrnVPX7SSbiaNzytEwTpECXsmnB6T2Co+d5YOYzKmWLIqOqL ZSTBkStiBzfxi+2KWlnfUHzWmOthaPo98ZRsiwtaux9W+8xvIDMnWD5x51EPlcjt ca93bMIW9i8aPNOOMeKb =dp6t -----END PGP SIGNATURE-----

Oct. 8, 2013

Re: [1/3] xmllite: Use buffer offset instead of pointers

by Nikolay Sivov

On 10/8/2013 10:56, Alexandre Julliard wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> writes: > >> On 10/6/2013 19:06, Nikolay Sivov wrote: >>> It's normal to grow destination buffer, in this case all stored >>> pointers will be trashed. This patch uses offsets from start of a >>> buffer instead. >>> >> Hi, Alexandre. >> >> Patches list shows a build failure for this one, and I don't see any >> failures on testbot for it so assuming something it fails on your >> machine. So what's the exact failure you get? > It's compiler warnings, you have several uninitialized or unused > variables. Please review your changes carefully. > Okay, will do. Strangely I see no warnings here, but that's probably a different gcc version.

Oct. 8, 2013

Re: riched20: Set control content in WM_CREATE message

by Piotr Caban

Hi Akihiro, On 10/08/13 12:51, Akihiro Sagawa wrote: > On Sat, 05 Oct 2013 14:54:07 +0200, Piotr Caban wrote: >> + if (!(editor->styleFlags & ES_MULTILINE)) >> + { >> + len = 0; >> + while(textW[len] != '0' && textW[len] != '\r' && textW[len] != '\n') >> + len++; >> + } > > Although this patch has been committed as e660bf676c111ce20d9e868280094f1c5bb81c79, > I doubt that it works properly. Did you mean '\0' or 0? I meant to check for terminating null-character. I'll fix it. Thanks, Piotr

Oct. 8, 2013

Re: riched20: Set control content in WM_CREATE message

by Akihiro Sagawa

On Sat, 05 Oct 2013 14:54:07 +0200, Piotr Caban wrote: > + if (!(editor->styleFlags & ES_MULTILINE)) > + { > + len = 0; > + while(textW[len] != '0' && textW[len] != '\r' && textW[len] != '\n') > + len++; > + } Although this patch has been committed as e660bf676c111ce20d9e868280094f1c5bb81c79, I doubt that it works properly. Did you mean '\0' or 0? Regards, Akihiro Sagawa

Oct. 8, 2013

Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.

by Henri Verbeet

On 8 October 2013 00:27, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 52eac16..eb8ca7e 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -5608,8 +5608,6 @@ HRESULT surface_load_location(struct wined3d_surface *surface, DWORD location, c > } > } > > - if (location == SFLAG_INSRGBTEX && gl_info->supported[EXT_TEXTURE_SRGB_DECODE]) > - location = SFLAG_INTEXTURE; > > if (surface->flags & location) > { > @@ -5671,12 +5669,6 @@ HRESULT surface_load_location(struct wined3d_surface *surface, DWORD location, c > surface_evict_sysmem(surface); > } > > - if (surface->flags & (SFLAG_INTEXTURE | SFLAG_INSRGBTEX) > - && gl_info->supported[EXT_TEXTURE_SRGB_DECODE]) > - { > - surface->flags |= (SFLAG_INTEXTURE | SFLAG_INSRGBTEX); > - } > - > return WINED3D_OK; > } > This change seems good on its own, as far as I can tell all callers already handle this correctly. I'm less sure about the other changes, the texture code seems like the right place to handle EXT_texture_sRGB_decode.

Oct. 8, 2013

Re: winemac.drv: add fullscreen mode support for Mac OS X 10.7+

by Ken Thomases

Hi, I finally got around to working on support for Cocoa full-screen mode in the Mac driver, based on the work of Kevin Eaves. I've attached a new patch. This patch can only be applied on top of the other Mac driver patches I just submitted to wine-patches. Some changes from Kevin's original, in no particular oder: * I have not used the user32 hack to increase the max tracking size and let windows grow so their non-frame area covers the screen. Instead, the call to SetWindowPos() that results from a WINDOW_FRAME_CHANGED event uses SWP_NOSENDCHANGING for Cocoa-full-screen windows. That prevents any immediate modification of the new window rect to be within the max tracking size. However, some programs (e.g. Guild Wars) end up moving the window again shortly afterward and then it gets constrained. This results in a window that doesn't quite fill the screen, showing a plain background around the edges. This isn't ideal. As previously discussed, this may require a new driver entry point to allow it to override the size limits. (Although I got slapped down for trying to add a similar entry point for some other work.) * Cocoa understandably refuses to minimize a window that's in full-screen mode. So, if Win32-land tries to programmatically minimize a full-screen window, Cocoa just immediately tells it that it's been unminimized. This shouldn't come up much. (One can access a window's system menu using the keyboard to test.) * We can't distinguish the program trying to make a window Win32 full-screen vs. it merely echoing back the frame set by Cocoa full-screen. So, we never consider a window to be in Win32 full-screen mode if it's in Cocoa full-screen mode. That means that the menu and Dock auto-unhide. Many (most?) apps will modify the window style in addition to just setting the frame such that it becomes incompatible with Cocoa full-screen mode. In that case, the window is first taken out of Cocoa full-screen and then put into Win32 full-screen mode. The menu and Dock are properly hidden, but the window went back to its original space, which may not be what the user wants. * I have added the standard menu item for controlling Cocoa full-screen, Enter Full Screen, to the Window menu. Cocoa automatically renames that to Exit Full Screen and back as the window enters and exits full-screen mode. As with other items in the Mac menus, I don't allow keyboard shortcuts that don't include Option among the modifiers. So, I've used Command-Option-Control-F instead of just Command-Control-F. * The menu item and the window widget are properly disabled when the window is disabled. * The maximum tracking size set by the app for the window is respected in full-screen mode. If the app leaves the default max tracking size alone, then the full-screen size is unconstrained (and so fills the screen) even though the Win32 default is slightly too small to allow that. * If the app programmatically changes the window rect while the window is in Cocoa full-screen mode, that change is honored. This may end up looking a bit odd, but is necessary for correctness. Furthermore, the changed rect is maintained as the window exits full-screen mode, which is not what Cocoa would normally do. (Cocoa restores the window to the size and position it had before entering full-screen.) This is necessary when, for example, a game switches from windowed (in Cocoa full-screen mode) to Win32 full-screen. It will often change the window style in such a way that forces it out of Cocoa full-screen and changes its size to fill the screen. We don't want Cocoa negating that size change as it transitions out of Cocoa full-screen mode. Programmatic changes of the window rect that occur during and shortly after the transition into full-screen are not interpreted as setting the frame that should be restored when exiting full-screen mode. Those are probably just responses from Wine and the app to the changes that Cocoa has initiated. * I set NSWindowCollectionBehaviorFullScreenAuxiliary on any windows which don't get NSWindowCollectionBehaviorFullScreenPrimary. I'm not certain that this is right. That flag is not as clearly documented as I would like. My intent is to allow other Wine windows to share the space with a full-screen-primary window. * WS_EX_TOOLWINDOW windows (utility windows, in Cocoa parlance) are not eligible for Cocoa full-screen. This means that they get NSWindowCollectionBehaviorFullScreenAuxiliary as per the previous point, so they can share a space with a full-screen primary window. * I have left out any attempt to reconcile Cocoa full-screen with changes to the display mode which result in the displays being captured. I don't know of an app which does that while leaving its window eligible for Cocoa full-screen, although I haven't tested many yet. I invite everybody who's interested to test and/or review. Cocoa full-screen was introduced in Mac OS X 10.7, so you have to be running that or later. Kevin, first, thanks again for your original work on this. Second, you seem to have tested with a variety of apps, including some games or other full-screen apps or ones which changed the display mode. Can you run some new tests and let me know about failures and rough edges? I'd welcome your review and feedback. Thanks, Ken

Oct. 8, 2013

Re: [1/3] xmllite: Use buffer offset instead of pointers

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > On 10/6/2013 19:06, Nikolay Sivov wrote: >> It's normal to grow destination buffer, in this case all stored >> pointers will be trashed. This patch uses offsets from start of a >> buffer instead. >> > Hi, Alexandre. > > Patches list shows a build failure for this one, and I don't see any > failures on testbot for it so assuming something it fails on your > machine. So what's the exact failure you get? It's compiler warnings, you have several uninitialized or unused variables. Please review your changes carefully. -- Alexandre Julliard julliard(a)winehq.org

Oct. 8, 2013

Re: msi/tests: Use BOOL type where appropriate (resend)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2667 Your paranoid android. === wvista (32 bit msi) === Timeout === w2008s64 (32 bit msi) === Timeout Failure running script in VM: network read timed out === w2008s64 (64 bit msi) === Timeout

Oct. 8, 2013

Re: msi/tests: Use BOOL type where appropriate

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2660 Your paranoid android. === wvista (32 bit msi) === The test timed out === w2008s64 (32 bit msi) === The test timed out === w7pro64 (32 bit msi) === No test summary line found Failure running script in VM: network read timed out === w2008s64 (64 bit msi) === Timeout === w7pro64 (64 bit msi) === Timeout

Oct. 7, 2013

Re: [1/3] xmllite: Use buffer offset instead of pointers

by Nikolay Sivov

On 10/6/2013 19:06, Nikolay Sivov wrote: > It's normal to grow destination buffer, in this case all stored > pointers will be trashed. This patch uses offsets from start of a > buffer instead. > Hi, Alexandre. Patches list shows a build failure for this one, and I don't see any failures on testbot for it so assuming something it fails on your machine. So what's the exact failure you get?

Oct. 7, 2013

Re: mscoree: Partial implement ICLRMetaHost RequestRuntimeLoadedNotification (try 2)

by Vincent Povirk

HRESULT CLRMetaHost_CreateInstance(REFIID riid, void **ppobj) { + GlobalCLRMetaHost.callback = NULL; return ICLRMetaHost_QueryInterface(&GlobalCLRMetaHost.ICLRMetaHost_iface, riid, ppobj); } I don't think we should be changing global state every time someone creates an instance of this object. We can't assume it only happens once.

Oct. 7, 2013

Re: riched20: Set control content in WM_CREATE message

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/riched20/editor.c | 21 +++++++++++++++++++++ > dlls/riched20/tests/editor.c | 38 ++++++++++++++++++++++++++++++++++++++ > 2 files changed, 59 insertions(+) It doesn't work: ../../../tools/runtest -q -P wine -M riched20.dll -T ../../.. -p riched20_test.exe.so txtsrv.c && touch txtsrv.ok wine: Unhandled page fault on read access to 0x00000024 at address 0x7ac23e94 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000024 in 32-bit code (0x7ac23e94). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7ac23e94 ESP:0032f290 EBP:0032fb98 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:7ac58c00 ECX:0032fc80 EDX:003338e8 ESI:003338e8 EDI:00000001 Stack dump: 0x0032f290: 0032fc80 00000000 00000000 00000000 0x0032f2a0: 00000001 00000000 00000000 00333428 0x0032f2b0: 4d430002 00000008 00000004 7bc3c8e3 0x0032f2c0: 00333558 00333550 00000000 7bc3c8e3 0x0032f2d0: 00000780 000004b0 0032f300 6890a34c 0x0032f2e0: 00000000 0000001f 0032f318 688bd210 Backtrace: =>0 0x7ac23e94 ME_HandleMessage+0x32d4(editor=0x3338e8, msg=0x1, wParam=0, lParam=0, unicode=0x1, phresult=0x32fbdc) [/home/julliard/wine/wine/dlls/riched20/editor.c:4029] in riched20 (0x0032fb98) 1 0x7ac3d3ab CreateTextServices+0x11a(pUnkOuter=<couldn't compute location>, pITextHost=<couldn't compute location>, ppUnk=<couldn't compute location>) [/home/julliard/wine/wine/dlls/riched20/txtsrv.c:417] in riched20 (0x0032fbf8) 2 0x686569cb func_txtsrv+0x2fa() [/home/julliard/wine/wine/dlls/riched20/tests/txtsrv.c:864] in riched20_test (0x0032fd38) 3 0x6862a5a7 main+0x386(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/riched20/tests/../../../include/wine/test.h:570] in riched20_test (0x0032fe08) 4 0x68657e30 __wine_spec_exe_entry+0x7f(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in riched20_test (0x0032fe58) 5 0x7b85f36c call_process_entry+0xb() in kernel32 (0x0032fe78) 6 0x7b86054b start_process+0x6a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1085] in kernel32 (0x0032feb8) 7 0x7bc7fe70 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 8 0x7bc82d7d call_thread_func+0x7c(entry=0x7b8604e0, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2602] in ntdll (0x0032ffa8) 9 0x7bc7fe4e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 10 0x7bc54a1e start_process+0x1d(kernel_start=0x7b8604e0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2694] in ntdll (0x0032ffe8) 11 0x6803128d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 12 0x6803134b wine_switch_to_stack+0x2a(func=0x7bc54a00, arg=0x7b8604e0, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xff8b7288) 13 0x7bc5a557 LdrInitializeThunk+0x3a6(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2750] in ntdll (0xff8b72f8) 14 0x7b866ac0 __wine_kernel_init+0xbbf() [/home/julliard/wine/wine/dlls/kernel32/process.c:1257] in kernel32 (0xff8b8208) 15 0x7bc5ac23 __wine_process_init+0x182() [/home/julliard/wine/wine/dlls/ntdll/loader.c:2959] in ntdll (0xff8b8298) 16 0x6802eeda wine_init+0x2b9(argc=0x3, argv=0xff8b87d4, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:952] in libwine.so.1 (0xff8b82f8) 17 0x7bf00d3b main+0x7a(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:237] in <wine-loader> (0xff8b8738) 18 0x682518c5 __libc_start_main+0xf4() in libc.so.6 (0x00000000) 0x7ac23e94 ME_HandleMessage+0x32d4 [/home/julliard/wine/wine/dlls/riched20/editor.c:4029] in riched20: movl 0x24(%eax),%eax 4029 : (void*)((CREATESTRUCTA*)lParam)->lpszName); -- Alexandre Julliard julliard(a)winehq.org

Oct. 7, 2013

Re: [PATCH 2/3] msvcrt: Add support for vcall thunks demangling (try2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2651 Your paranoid android. === wxppro (32 bit cpp) === cpp.c:1329: Test failed: 125: Got name "?_dispatch(a)_impl_Engine@SalomeApp@@$R4CE(a)BA@PPPPPPPM(a)7AE_NAAVomniCallHandle@@@Z" cpp.c:1332: Test failed: 125: Expected "[thunk]:public: virtual bool __thiscall SalomeApp::_impl_Engine::_dispatch`vtordispex{36,16,4294967292,8}' (class omniCallHandle &)"

Oct. 7, 2013

Re: [PATCH 3/3] msvcrt: Add support for vtordispex demangling

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2650 Your paranoid android. === wxppro (32 bit cpp) === cpp.c:1328: Test failed: 124: Got name "[thunk]: __thiscall CView::`vcall'{392,{flat}}' " cpp.c:1331: Test failed: 124: Expected "[thunk]: __thiscall CView::`vcall'{392,{flat}}' }'" cpp.c:1328: Test failed: 125: Got name "?_dispatch(a)_impl_Engine@SalomeApp@@$R4CE(a)BA@PPPPPPPM(a)7AE_NAAVomniCallHandle@@@Z" cpp.c:1331: Test failed: 125: Expected "[thunk]:public: virtual bool __thiscall SalomeApp::_impl_Engine::_dispatch`vtordispex{36,16,4294967292,8}' (class omniCallHandle &)"

Oct. 7, 2013

Re: [PATCH 2/3] msvcrt: Add support for vcall thunks demangling

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2649 Your paranoid android. === wxppro (32 bit cpp) === cpp.c:1326: Test failed: 124: Got name "[thunk]: __thiscall CView::`vcall'{392,{flat}}' " cpp.c:1329: Test failed: 124: Expected "[thunk]: __thiscall CView::`vcall'{392,{flat}}' }'"

Oct. 7, 2013

Re: msvcrt: add support for _chsize_s (try #2)

by Piotr Caban

Hi, On 10/06/13 00:45, morphiend wrote: > + * _chsize_s (MSVCRT.@) > + */ > +int CDECL MSVCRT__chsize_s(int fd, __int64 size) > +{ > + LARGE_INTEGER cur, pos; > + LARGE_INTEGER temp = { 0 }; This causes compilation warnings. There's also a trailing space in this line. > + TRACE("(fd=%d, size=%lld)\n", fd, size); You can't print 64-bit numbers this way, it's not portable. You can use wine_dbgstr_longlong function. > + handle = msvcrt_fdtoh(fd); > + if (!MSVCRT_CHECK_PMT_ERR(handle == INVALID_HANDLE_VALUE, MSVCRT_EBADF) || > + !MSVCRT_CHECK_PMT_ERR(size < 0, MSVCRT_EINVAL)) You're validating parameters incorrectly. Did you test this patch? > + { > + ret = SetEndOfFile(handle); > + if (!ret) > + { > + msvcrt_set_errno(GetLastError()); > + ret = *MSVCRT__errno(); > + } This causes the _chsize_s function to return TRUE in case of success. > + /* restore the file pointer */ > + MSVCRT__lseek(fd, cur.QuadPart, SEEK_SET); MSVCRT__lseek takes LONG as second argument. Cheers, Piotr

Oct. 7, 2013

Re: binfmt support

by Henri Verbeet

On 7 October 2013 12:06, xantares 09 <xantares09(a)hotmail.com> wrote: > ... I don't see a reason why to not include it at the wine level instead of > every linux distros, see: > https://github.com/xantares/wine/commit/76ebd5d29effaf4b6b39ceecb689f7008bf… > > What do you think ? > Ignoring the discussion if we want this or not for the moment, I'd guess this would break as soon as you pass something other than /usr for --prefix to configure.

Oct. 7, 2013

binfmt support

by xantares 09

Hello, I made a patch to add a configuration file to be picked up by binfmt to allow to associate windows executables to wine. As binfmt is now a part of systemd in most linux disttributions: http://www.freedesktop.org/software/systemd/man/systemd-binfmt.service.html ... I don't see a reason why to not include it at the wine level instead of every linux distros, see: https://github.com/xantares/wine/commit/76ebd5d29effaf4b6b39ceecb689f7008bf… What do you think ? x.

Oct. 7, 2013

Re: msvcrt: add support for _chsize_s (try #2)

by Henri Verbeet

On 6 October 2013 20:32, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > On Sun, Oct 6, 2013 at 12:45 AM, morphiend <morphiend(a)gmail.com> wrote: >> This patch adds the _chsize_s() to the mscvrt and corresponding mscvr*s. >> This was tested on Ubuntu 12.10 using IDA 6.4 as a test application. Without >> the implementation of _chsize_s(), certain binaries caused an internal crash >> of IDA. This patch fixed that crash. >> > You need to use your real name when sending patches. > Well, it is actually there in the patch.

Oct. 6, 2013

Re: msvcrt: add support for _chsize_s (try #2)

by Frédéric Delanoy

On Sun, Oct 6, 2013 at 12:45 AM, morphiend <morphiend(a)gmail.com> wrote: > This patch adds the _chsize_s() to the mscvrt and corresponding mscvr*s. > This was tested on Ubuntu 12.10 using IDA 6.4 as a test application. Without > the implementation of _chsize_s(), certain binaries caused an internal crash > of IDA. This patch fixed that crash. > You need to use your real name when sending patches. -- Frédéric Delanoy

Oct. 6, 2013

Re: mshtml/tests: Fix compilation on systems that don't support nameless unions.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2637 Your paranoid android. === wxppro (32 bit htmldoc) === htmldoc.c:2898: Test failed: mon(0026BF78) != exmon(00269670) htmldoc.c:7601: Test failed: mon(0026BF78) != exmon(00269670) htmldoc.c:5978: Test failed: mon(0026BF78) != exmon(00269670) htmldoc.c:2898: Test failed: mon(002ADFE8) != exmon(00265FE8) htmldoc.c:7601: Test failed: mon(002ADFE8) != exmon(00265FE8) htmldoc.c:5978: Test failed: mon(002ADFE8) != exmon(00265FE8) === wvista (32 bit htmldoc) === No test summary line found === w7pro64 (32 bit htmldoc) === No test summary line found

Oct. 5, 2013

Re: kernel32/tests: Fix compilation on systems that don't support nameless unions.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2634 Your paranoid android. === w7pro64 (64 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:883: Test failed: WaitCommEvent error 0 comm.c:885: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:889: WaitCommEvent for EV_TXEMPTY took 1014 ms (timeout 1000) comm.c:891: Test failed: WaitCommEvent used 1014 ms for waiting

Oct. 5, 2013

Re: BiDi, Unicode 6.3 and Wine.

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > Hello, > > So Unicode 6.3 was just recently released. One of the things it > features is an updated BIDI (Bidirectional) algorithm. This is > revision 29 to the > algorithm. (http://www.unicode.org/reports/tr9/tr9-29.html#Modifications) > Looking at the code I moved from gdi32 to usp10, it looks like the > existing code is based off of revision 17. This implementation was > originally by Shachar and Maarten. I simply integrated it into > uniscribe. > > I am tempted to update our code to match the revision 29 version of > the algorithm. But this raises a question. Right now our code mostly > correctly mimics Windows. It may be that I am not testing the correct > edge cases that would reveal if windows is coded to a later version of > the algorithm or not. But if we update to revision 29 then we will > almost assuredly be using a later version of the algorithm. > > What is more important to us in this regard? Do we want to have the > latest algorithm based on the unicode standard, or do we want to try > to match the algorithm that Windows makes use of? I'm not sure that there's any evidence that the existing version is identical to Windows. It's probably just what happened to be the current version when the code was written. As long as it passes reasonable tests, it shouldn't be an issue to use a more recent version. -- Alexandre Julliard julliard(a)winehq.org

Oct. 4, 2013

Re: [3/3] ntdll: Add support for FILE_APPEND_DATA to NtWriteFile. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -979,6 +986,12 @@ NTSTATUS WINAPI NtWriteFile(HANDLE hFile, HANDLE hEvent, > goto done; > } > > + if (append_write) > + { > + offset_eof.QuadPart = (LONGLONG)-1; /* FILE_WRITE_TO_END_OF_FILE */ > + offset = &offset_eof; > + } > + Please add a test for the file position after the write, to show that this is the correct behavior. -- Alexandre Julliard julliard(a)winehq.org

Oct. 4, 2013

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

by Stefan Dösinger

Am 04.10.2013 um 17:15 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > I guess that makes it ok in practice, but I'd still feel happier about > this kind of patch if we actually enforced resource access flags > first. (At which point you could also just check the access flags > instead of the pool.) My plan is to enforce this in resource_load_location similar to how it's currently done for volumes. That'd be at the end of my surface cleanup patchset though, and it'll need some additional work (downloading a texture to a bigger sysmem surface to handle get_front_buffer_data). I think my surface patches should work ok without the assumption that client storage and user memory are mutually exclusive, so feel free to skip this patch for now. The other 4 patches in this series should work ok. Some later patches in the big patchset need minor adjustments though.

Oct. 4, 2013

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

by Henri Verbeet

On 4 October 2013 15:51, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.) > I guess that makes it ok in practice, but I'd still feel happier about this kind of patch if we actually enforced resource access flags first. (At which point you could also just check the access flags instead of the pool.)

Oct. 4, 2013

Re: [PATCH 5/5] wininet: Added InternetLockRequestFile tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2625 Your paranoid android. === w2008s64 (64 bit http) === http.c:3521: Test failed: HttpQueryInfo failed 0 === w7pro64 (64 bit http) === http.c:3521: Test failed: HttpQueryInfo failed 0

Oct. 4, 2013

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded

by Lasse Rasinen

Stefan Dösinger <stefandoesinger(a)gmail.com> writes: > Am 2013-10-03 21:45, schrieb Henri Verbeet: >> On 3 October 2013 21:16, Lasse Rasinen <lrasinen(a)iki.fi> wrote: >>> According to debugging output, Artemis Spaceship Bridge Simulator >>> 2.0 calls LockRect twice on the same texture (for whatever >>> reason) and crashes. >>> >>> http://bugs.winehq.org/show_bug.cgi?id=34271 >>> >>> This change prevents the locked_rect being overwritten with >>> garbage in that case, and the game no longer crashes. >>> >> I think this patch makes sense, but could you please add a test >> case as well? Ideally we'd also have similar tests for other >> resources (i.e., textures, volumes, vertex buffers, index buffers) >> and D3D versions (ddraw, d3d8), but that's not a strict >> requirement. > I'd expect that the correct behavior is to set pBits to NULL. > test_volume_locking() demonstrates this for volumes. That appears to work too, thanks. I'll have a look at the existing tests; let's see what I come up with. -- Lasse Rasinen lrasinen(a)iki.fi

Oct. 4, 2013

Re: [PATCH 2/2] advapi32: Don't cache HKCR if WOW64 redirection flags are set

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2624 Your paranoid android. === wxppro (32 bit registry) === Timeout

Oct. 4, 2013

Re: BiDi, Unicode 6.3 and Wine.

by Kyle Auble

While I have no experience contributing code to wine itself so far, BiDi or not, I smell a high-level design choice here. If the new revision to the Unicode algorithm looks superior, my first idea would be to try rebasing the code on that and then explicitly overriding it for Windows quirks. I don't know enough about wine's code or performance issues to advocate when that redirection should take place. I suppose it could be done during compilation and linking, during runtime, or even by just hard-coding and commenting "standards" and "quirks" versions in the source. Mine's not the most informed opinion though so I would take it with a grain of salt. -Kyle On 10/04/2013 07:54 AM, Aric Stewart wrote: > Hello, > > So Unicode 6.3 was just recently released. One of the things it features is an updated BIDI (Bidirectional) algorithm. This is revision 29 to the algorithm. (http://www.unicode.org/reports/tr9/tr9-29.html#Modifications) Looking at the code I moved from gdi32 to usp10, it looks like the existing code is based off of revision 17. This implementation was originally by Shachar and Maarten. I simply integrated it into uniscribe. > > I am tempted to update our code to match the revision 29 version of the algorithm. But this raises a question. Right now our code mostly correctly mimics Windows. It may be that I am not testing the correct edge cases that would reveal if windows is coded to a later version of the algorithm or not. But if we update to revision 29 then we will almost assuredly be using a later version of the algorithm. > > What is more important to us in this regard? Do we want to have the latest algorithm based on the unicode standard, or do we want to try to match the algorithm that Windows makes use of? > > Thanks! > -aric > >

Oct. 4, 2013

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

by Stefan Dösinger

Am 04.10.2013 um 15:51 schrieb Stefan Dösinger <stefandoesinger(a)gmail.com>: > No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.) Fwiw, the other patches are independent of this patch.

Oct. 4, 2013

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

by Stefan Dösinger

Am 04.10.2013 um 15:28 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > On 4 October 2013 15:02, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >> Client storage only applies to GL textures, which won't be created for sysmem surfaces. >> > I don't think that's necessarily true at the moment. In particular, > ddraw blits can in principle cause a texture to be created for sysmem > surfaces. There might be restrictions in the ddraw API that prevent > this from happening in practice, but even if there are, we certainly > don't enforce them. No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.)

Oct. 4, 2013

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

by Henri Verbeet

On 4 October 2013 15:02, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Client storage only applies to GL textures, which won't be created for sysmem surfaces. > I don't think that's necessarily true at the moment. In particular, ddraw blits can in principle cause a texture to be created for sysmem surfaces. There might be restrictions in the ddraw API that prevent this from happening in practice, but even if there are, we certainly don't enforce them.

Oct. 4, 2013

BiDi, Unicode 6.3 and Wine.

by Aric Stewart

Hello, So Unicode 6.3 was just recently released. One of the things it features is an updated BIDI (Bidirectional) algorithm. This is revision 29 to the algorithm. (http://www.unicode.org/reports/tr9/tr9-29.html#Modifications) Looking at the code I moved from gdi32 to usp10, it looks like the existing code is based off of revision 17. This implementation was originally by Shachar and Maarten. I simply integrated it into uniscribe. I am tempted to update our code to match the revision 29 version of the algorithm. But this raises a question. Right now our code mostly correctly mimics Windows. It may be that I am not testing the correct edge cases that would reveal if windows is coded to a later version of the algorithm or not. But if we update to revision 29 then we will almost assuredly be using a later version of the algorithm. What is more important to us in this regard? Do we want to have the latest algorithm based on the unicode standard, or do we want to try to match the algorithm that Windows makes use of? Thanks! -aric

Oct. 4, 2013

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

by Henri Verbeet

On 4 October 2013 00:03, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -2883,10 +2886,6 @@ HRESULT CDECL wined3d_surface_set_mem(struct wined3d_surface *surface, void *mem > /* Now the surface memory is most up do date. Invalidate drawable and texture. */ > surface_validate_location(surface, SFLAG_INSYSMEM); > surface_invalidate_location(surface, ~SFLAG_INSYSMEM); > - > - /* For client textures OpenGL has to be notified. */ > - if (surface->flags & SFLAG_CLIENT) > - surface_release_client_storage(surface); > } > else if (surface->flags & SFLAG_USERPTR) > { > @@ -2899,9 +2898,6 @@ HRESULT CDECL wined3d_surface_set_mem(struct wined3d_surface *surface, void *mem > surface->resource.allocatedMemory = NULL; > surface->flags &= ~(SFLAG_USERPTR | SFLAG_INSYSMEM); > > - if (surface->flags & SFLAG_CLIENT) > - surface_release_client_storage(surface); > - > surface_prepare_system_memory(surface); > } > What makes this safe, and why is it needed?

Oct. 4, 2013

Re: [PATCH 3/3] winemac: Tell Wine when Cocoa has brought a window to the front.

by Ken Thomases

On Oct 4, 2013, at 12:17 AM, Ken Thomases wrote: > --- > dlls/winemac.drv/cocoa_app.m | 8 ++++++-- > dlls/winemac.drv/cocoa_window.h | 1 + > dlls/winemac.drv/cocoa_window.m | 16 +++++++++++++--- > dlls/winemac.drv/event.c | 5 +++++ > dlls/winemac.drv/macdrv.h | 1 + > dlls/winemac.drv/macdrv_cocoa.h | 1 + > dlls/winemac.drv/window.c | 12 ++++++++++++ > 7 files changed, 39 insertions(+), 5 deletions(-) > > <0003-winemac-Tell-Wine-when-Cocoa-has-brought-a-window-to.patch> Don't commit this one. It has caused some strange behavior on Mavericks. The other two in the series are OK and useful independently of this one. -Ken

Oct. 4, 2013

Re: [PATCH 1/5] wined3d: Store valid locations in the resource.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-10-03 16:05, schrieb Henri Verbeet: > I don't think this patch makes sense before you actually unify the > location management. In particular, after this patch you'd have > location management in resources that really only does anything > for volumes, while from the surface point of view you'd have > duplicate location management. I think the harm in that is only cosmetic because the surface one will go away, but reordering the patches is easy. I do prefer to deal with buffers after merging the location management of surfaces and volumes though. Merging buffers will require considerable additional work, most notably removing the buffer conversion code and preferably (but not necessarily) adding an arbvp vertex pipeline that can handle rhw vertices and forwards everything else to the fixed function code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTegzAAoJEN0/YqbEcdMw85sP/1Em4RWi2dPAP+fNtGGhBSql sUJcVkGLhSPvqNxLqhzoGMzzh+3JzvmzPtrT3b/BLRZDYemm60x8Mcxirab0RIAv XRLPd0WG1W9xFoft8I8gYSf2MBxidfEKNc/wnusj/6hgni9rPDEfhJfK9AwJt0ok NnVuvSl6NCPEhyjPX0A/Dh/rqOC1+h8bmUnKKQaONnjNiOpcbrw0LHmLbPXC1UOE WjqUJck6tm6FmRHo+pLPQzRqHNZDNqyI4k5BhVy59rDC7wI4xlzSikQGjLv3/ik5 8SQIu6bn+Inq3Ruc+kSoskY1mThEdYZVi3yPkdRwcGHeyihb0klME68z9+xQPqWN ZA3hYpnNlMDb40iMwq0mGeMdbZufsFvYXqe9PsottOhPKeCksNavEe1TFlt0rQFi MukG514G7QMfKRUJtayxvvo5b/ZaxDLs9PCjOH0A9M1ki6nsViw/aAlF/xg2lTC4 ZCziB74bai2ss9OVAZwRWYMUqkDEhp9ot2SE4gnRPnQK/+KY8ncq7boxeohFM0/W ENC8F6E+IfkdENj4vhVICQ5Ttbo0i/NO4LsSe5MqFpvTidQbLTDYNIcKqW7lBJv6 aqw+8DCH7oragx70W4P2VEC0v2p8RHvzVa25Ea/SuktJTsQh/lkul5jijmVsAZPr zjQ6a8VOc+yUONvh/zba =xm5i -----END PGP SIGNATURE-----

Oct. 3, 2013

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-10-03 21:45, schrieb Henri Verbeet: > On 3 October 2013 21:16, Lasse Rasinen <lrasinen(a)iki.fi> wrote: >> According to debugging output, Artemis Spaceship Bridge Simulator >> 2.0 calls LockRect twice on the same texture (for whatever >> reason) and crashes. >> >> http://bugs.winehq.org/show_bug.cgi?id=34271 >> >> This change prevents the locked_rect being overwritten with >> garbage in that case, and the game no longer crashes. >> > I think this patch makes sense, but could you please add a test > case as well? Ideally we'd also have similar tests for other > resources (i.e., textures, volumes, vertex buffers, index buffers) > and D3D versions (ddraw, d3d8), but that's not a strict > requirement. I'd expect that the correct behavior is to set pBits to NULL. test_volume_locking() demonstrates this for volumes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTdihAAoJEN0/YqbEcdMwFOoP/RJbSrIe02Zs+3kZ3orWZTW9 kYDUNQd1kBPE4FPn4XxRBN4n8imOylpNj5M8hrAVSUlXzHhYJ7r3MWCGL9p+Xgra ycYCN36u9eRMgo3LLzw3HH1z/D3qObwzHEgVZFa6UVgBfUqKxuWmbRLRm51uF9B+ YslkqGyX6d3+BqFO3Xw1h4AA+BxeEBmR/dCmMhEdzcRhgUPaCRjd0UiPnAD9SNLk 9hNbkmp6P5dfvz4fbYFmtbCiGwy0ma6BuyA9Oh925fQ7vcka6OHmIU78R5FU1zMF GEMQ9rNz/coWGWs+eFh0u09WXK3BlgN+cz8YTF/bH6iRazsyfuKNrmyVXXAyxG/c PuqTt4HhJ459KuFUGsa+he/VdqOKeoxj/h/0s/aNRnn/k6L5Coa0HUVT2BqOVi3e 4wLnHog5nwJzPMzCu89QZtJVtg9lCpfkRPPSMxt5YuM1SRoZFXCjSs9mms9TBhtt b41UK9Oy3bJVh16YdPxNj1AFpdXpngeK19jpjErH+nhXtjm6uOKinFsKYD/8L285 cRLvyND3SYK2JxyezAEEuUJlA95qKFZdcLqUPjj2ZAoXEeMCgVefIJIRPQ/znM8V vZHH1ejo0SvtcpidTa4LLCyccbUqTPl1BpSXPLbrRiTqwdIeDuWHNo/rTVRVLGBZ JmhUXEaVBE3Uuo+VzPbD =38ER -----END PGP SIGNATURE-----

Oct. 3, 2013

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded

by Henri Verbeet

On 3 October 2013 21:16, Lasse Rasinen <lrasinen(a)iki.fi> wrote: > According to debugging output, Artemis Spaceship Bridge Simulator 2.0 > calls LockRect twice on the same texture (for whatever reason) and crashes. > > http://bugs.winehq.org/show_bug.cgi?id=34271 > > This change prevents the locked_rect being overwritten with garbage in > that case, and the game no longer crashes. > I think this patch makes sense, but could you please add a test case as well? Ideally we'd also have similar tests for other resources (i.e., textures, volumes, vertex buffers, index buffers) and D3D versions (ddraw, d3d8), but that's not a strict requirement. > + if (hr == WINED3D_OK) { > + locked_rect->Pitch = map_desc.row_pitch; > + locked_rect->pBits = map_desc.data; > + } > Minor style issue, this should be: if (SUCCEEDED(hr)) { ... }

Oct. 3, 2013

Re: kernel32: Add tests for job objects (try 4)

by Alexandre Julliard

Andrew Cook <ariscop(a)gmail.com> writes: > + sprintf(buffer, "\"%s\" tests/process.c ignored \"%s\"", selfname, "wait"); > + > + IOPort = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 1); > + ok(IOPort != INVALID_HANDLE_VALUE, "CreateIoCompletionPort (%d)", GetLastError()); > + > + JobObject = pCreateJobObjectW(NULL, NULL); > + ok(JobObject != INVALID_HANDLE_VALUE, "CreateJobObject (%d)\n", GetLastError()); These functions don't return INVALID_HANDLE_VALUE. -- Alexandre Julliard julliard(a)winehq.org

Oct. 3, 2013

Re: Looking for an icon for the Mac driver: generic program running under Wine

by Jeremiah Flerchinger

The window for that icon was made from a screenshot of a window from my desktop. The Wine glass was from a png on the WineHQ website. So there should be no copyright issues there, so long as Wine agrees to letting itself use it. I made it in icon composer which only supports up to 512x512 which is the max resolution supported in XCode's icon composer. A Mac-themed icon seems more appropriate in my opinion. I've cc'd Linda who might be willing to make one that's cleaned up and contains better reduced resolution versions, if that's the desired direction. Thanks, J On Wed, Oct 2, 2013 at 11:01 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > Hi, > > I have a need for a new icon in Wine and I'm hoping somebody with some graphics-design skills might be able to create it. > > The Mac driver attempts to extract an icon from the executable to use for the Dock icon of its process. This is also the icon that appears in the Command-Tab application switcher. This often works, but not always. When it doesn't, the Dock just uses the generic "Unix executable" icon from Mac OS X. You can see that here: <http://i.imgur.com/b1JrMDJ.png>. It's not very nice. > > I would prefer to have a Wine-specific generic program icon. > > > Any graphic designer care to take on the task of creating such an icon? > > > I'm told Wine has been using the Tango icons as the template for its. Tango provides application-x-executable.svg at <http://cgit.freedesktop.org/tango/tango-icon-theme/tree/svg> that might be suitable. That could be badged with the Wine glass logo to produce an icon for a program running under Wine. > > On the other hand, if this icon were to be used only by the Mac driver, it might be more appropriate to use a Mac-themed icon. > > Some time back, Jeremiah posted an archive of icons. <http://www.winehq.org/pipermail/wine-devel/2013-February/098783.html> That included one which had a miniature Mac window badged with the Wine glass logo. I'm not sure of the copyright/licensing situation with that icon. It's bitmap-only, not vector, but that might be fine for a Mac-only icon. It does have some issues with rough edges around the window, rather than a smooth alpha-blended edge. > > Although Mac app icons can go up to 1024x1024 pixels (512x512 "points" at 2x resolution for Retina displays), this icon would only appear in the Dock and the application switcher. So, it needn't be larger than 256x256 pixels (128x128(a)2x). > > Thanks, > Ken >

Oct. 3, 2013

Re: [PATCH 1/5] wined3d: Store valid locations in the resource.

by Henri Verbeet

On 3 October 2013 15:03, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Am 2013-10-03 13:45, schrieb Henri Verbeet: >> It sounds like you have some ordering issues in that patch set. > Correct. Patches before patch 24 shouldn't be affected by that though. > I didn't get around to splitting and recombining patch 24 and some > later bugfixes yet due to other priorities. > > Unless you mean to imply that you disagree with the ordering of the > first 23 patches, where the order is mostly a matter of opinion > instead of technical constraints. > I don't think this patch makes sense before you actually unify the location management. In particular, after this patch you'd have location management in resources that really only does anything for volumes, while from the surface point of view you'd have duplicate location management.

Oct. 3, 2013

Re: [PATCH 1/5] wined3d: Store valid locations in the resource.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-10-03 13:45, schrieb Henri Verbeet: > On 3 October 2013 13:22, Stefan Dösinger <stefan(a)codeweavers.com> > wrote: >> Will be updated as well. See >> http://www.winehq.org/pipermail/wine-devel/2013-October/101575.html >> >> for the surface part and more explanations. > It sounds like you have some ordering issues in that patch set. Correct. Patches before patch 24 shouldn't be affected by that though. I didn't get around to splitting and recombining patch 24 and some later bugfixes yet due to other priorities. Unless you mean to imply that you disagree with the ordering of the first 23 patches, where the order is mostly a matter of opinion instead of technical constraints. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTWsrAAoJEN0/YqbEcdMwXnMP/1mN/d6iy/pXtftkIEvLsDLb Av1zqQpPs92UU/H/TPlkQ0B2jMgBaefpuAsIWFc856lRjPUXUlbZ6cz17G502g7b cqn6idjqEqIpPfF5dQ+U3SY4mAznUI0mxWqGdiqKNyq1uuPA1PoUxS1zTIrK68sQ TXf4CgVsz0wObN7rEdpLUrGY+wPAG0PeNSCQaQsOMkvV5J0QpOHy++p9bOlV7W1K IiwpVdorT7G3ru0KMYVChdsPiFvEVE0uj+/6+b1oewaA3r2XIOKiMeCLhPGgOTnh jJxWfJA+MO3tI1RjUxXC1Pxl5fcuMTbr9saj01+WSfI/BMAnNnzdumo84yX8ME5l ypAu2UwXWSSU4cFPRx4ok/+iQ/JW533QoSZ50j4MevFl4OPAtFl+k8tfpdhfuaop tC/NuvB8SlPFLLsN1ELiBNWXyFdW5LGruTl9Fxb5in1XwQIxy/t4u1aS23cbU30K 3cYYCfk14nG6XWnAmjBq7I+gTWY55P34dIqf/q0bQPtHWUD31lP/Vdi++md8g+32 6FbMQm+/2NZfoX/fJQyRIaDQSnE0NIjpsRfEtKRPqZGehT3D2KbFJIaVJrh/X7w6 LShdXa4q7R+bQyHT6weg4nMcyoHfHDUokUctSgvAsUpVdT/0kMt/Z/kRlEvtcygi KTaXODUsfmXBin8sKlyt =3Dy9 -----END PGP SIGNATURE-----

Oct. 3, 2013

Re: [PATCH 1/5] wined3d: Store valid locations in the resource.

by Henri Verbeet

On 3 October 2013 13:22, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Am 2013-10-03 13:14, schrieb Henri Verbeet: >> On 3 October 2013 13:08, Stefan Dösinger <stefan(a)codeweavers.com> >> wrote: >>> --- dlls/wined3d/volume.c | 46 >>> +++++++++++++++++++++--------------------- >>> dlls/wined3d/wined3d_private.h | 6 ++++-- 2 files changed, 27 >>> insertions(+), 25 deletions(-) >>> >> What about surfaces and buffers? > Will be updated as well. See > http://www.winehq.org/pipermail/wine-devel/2013-October/101575.html > for the surface part and more explanations. It sounds like you have some ordering issues in that patch set.

Oct. 3, 2013

Re: [PATCH 1/5] wined3d: Store valid locations in the resource.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-10-03 13:14, schrieb Henri Verbeet: > On 3 October 2013 13:08, Stefan Dösinger <stefan(a)codeweavers.com> > wrote: >> --- dlls/wined3d/volume.c | 46 >> +++++++++++++++++++++--------------------- >> dlls/wined3d/wined3d_private.h | 6 ++++-- 2 files changed, 27 >> insertions(+), 25 deletions(-) >> > What about surfaces and buffers? Will be updated as well. See http://www.winehq.org/pipermail/wine-devel/2013-October/101575.html for the surface part and more explanations. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTVN9AAoJEN0/YqbEcdMw9hwP/insKmUabEOtn+87MOY8RSqw gEHY1dYyi8L+ECVcjJx/x7BzLGDDC8lfISWHQkVZ6RcF7X8TegVwxQwgJY1e1isM YD8ECNRW96mBgSumrvtLUJVvdOlOOW0HU9L4U7DvqXLTrc1n6toaCvALW2v+OyTz aZy2+5iRu6SL5zoTsdt5AAOVg/xqBaY1svnBvEAyDJ3w/ztPmLReMGaM95cLzStG 6NzPhg3nd4YCb2hHvpAXypM9PQLFgMAGqOIS/4PXIVa1N5sbnNABWs0tmqOeP8DJ Oul8vSsNysEViWdsRBvQFa9m3s5lvpY3RMXKdfWjQjjpDQv6Ii3f6D8xzEUnguI4 BrysvAkrz2dcQAdkLm2LmLIe9pCEbL+FHaFXjydgRWBLY7iK5Y68WMpVyyKA8SVv jYdd/e+hLu1IvYWRgSU9Z3tNBnIwTqZyrb6exwlsUztvkoMZvTKEGuDShnTvPLX5 FornFmxCYflneZO6fjFtI+y9OgAQLsdqCPKb6JzPlQS+d3baR1IZeY/j9/iS8U0I 0xknAEGZ63gVUWONJB55S6Kt7tSEjI7fTMZfKBPm+oDU36//2PxDtuA58K7aUnnG +dAOSz0Fndpnei7dZQSCSNyCwujWqetAdXK3n13uzHxL2QZIxWiHrEo8nqawVLWL wkzlLCqE9605fthCQYf6 =Q81u -----END PGP SIGNATURE-----

Oct. 3, 2013

Re: [PATCH 1/5] wined3d: Store valid locations in the resource.

by Henri Verbeet

On 3 October 2013 13:08, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > --- > dlls/wined3d/volume.c | 46 +++++++++++++++++++++--------------------- > dlls/wined3d/wined3d_private.h | 6 ++++-- > 2 files changed, 27 insertions(+), 25 deletions(-) > What about surfaces and buffers?

Oct. 3, 2013

Re: rpcss: Convert to a service

by Andrew Cook

Ignore this, for some reason this randomly forks a huge number of rpcss instances, and decided to not do so while i was testing it On 03/10/13 14:00, Andrew Cook wrote: > --- > dlls/rpcrt4/rpc_epmap.c | 40 ++++++++----------- > programs/rpcss/Makefile.in | 2 +- > programs/rpcss/rpcss_main.c | 97 > +++++++++++++++++++++++++++++++++++---------- > tools/wine.inf.in | 11 +++++ > 4 files changed, 104 insertions(+), 46 deletions(-) > >

Oct. 3, 2013

Re: server: Set the unix file write mode bit also for FILE_APPEND_DATA access.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > diff --git a/server/file.c b/server/file.c > index 2ecf97c..94d3060 100644 > --- a/server/file.c > +++ b/server/file.c > @@ -459,7 +459,7 @@ static mode_t file_access_to_mode( unsigned int access ) > > access = generic_file_map_access( access ); > if (access & FILE_READ_DATA) mode |= 4; > - if (access & FILE_WRITE_DATA) mode |= 2; > + if (access & (FILE_WRITE_DATA|FILE_APPEND_DATA)) mode |= 2; > if (access & FILE_EXECUTE) mode |= 1; > return mode; > } I don't think that this patch should be in 'superseded' state. -- Dmitry.

Oct. 3, 2013

Looking for an icon for the Mac driver: generic program running under Wine

by Ken Thomases

Hi, I have a need for a new icon in Wine and I'm hoping somebody with some graphics-design skills might be able to create it. The Mac driver attempts to extract an icon from the executable to use for the Dock icon of its process. This is also the icon that appears in the Command-Tab application switcher. This often works, but not always. When it doesn't, the Dock just uses the generic "Unix executable" icon from Mac OS X. You can see that here: <http://i.imgur.com/b1JrMDJ.png>. It's not very nice. I would prefer to have a Wine-specific generic program icon. Any graphic designer care to take on the task of creating such an icon? I'm told Wine has been using the Tango icons as the template for its. Tango provides application-x-executable.svg at <http://cgit.freedesktop.org/tango/tango-icon-theme/tree/svg> that might be suitable. That could be badged with the Wine glass logo to produce an icon for a program running under Wine. On the other hand, if this icon were to be used only by the Mac driver, it might be more appropriate to use a Mac-themed icon. Some time back, Jeremiah posted an archive of icons. <http://www.winehq.org/pipermail/wine-devel/2013-February/098783.html> That included one which had a miniature Mac window badged with the Wine glass logo. I'm not sure of the copyright/licensing situation with that icon. It's bitmap-only, not vector, but that might be fine for a Mac-only icon. It does have some issues with rough edges around the window, rather than a smooth alpha-blended edge. Although Mac app icons can go up to 1024x1024 pixels (512x512 "points" at 2x resolution for Retina displays), this icon would only appear in the Dock and the application switcher. So, it needn't be larger than 256x256 pixels (128x128(a)2x). Thanks, Ken

Oct. 2, 2013

Re: [5/5] ws2_32: Always return the source address from WSAAccept.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2610 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (c8): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (618): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 74AA9799 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (600): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 0000000000000000

Oct. 2, 2013

Re: [4/5] ws2_32: Return an error from accept if the address buffer is too small.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2609 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (c8): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (520): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 74AA9799 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (78c): unexpectedly at the OOB mark: 0

Oct. 2, 2013

Re: [3/5] ws2_32: Add some tests for getpeername.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2608 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (c8): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (320): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 74AA9799 === w2008s64 (64 bit sock) === sock.c:509: Test failed: oob_server (808): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (808): unexpectedly at the OOB mark: 0

Oct. 2, 2013

Re: [2/5] ws2_32: Always clear res on error in getaddrinfo/GetAddrInfoW.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2607 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (108): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (7c4): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 74AA9799 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (470): unexpectedly at the OOB mark: 0

Oct. 2, 2013

Re: [1/2] gdi32: Fix the B spacing value of empty glyph. (try 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2605 Your paranoid android. === wvista (32 bit font) === The test timed out === w2008s64 (32 bit font) === Failure running script in VM: network read timed out

Oct. 2, 2013

Re: [2/2] gdi32: Don't modify output glyph metrics unless the function succeeds. (resend)

by Alexandre Julliard

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > --- > dlls/gdi32/freetype.c | 12 ++++++++---- > dlls/gdi32/tests/font.c | 5 +++++ > 2 files changed, 13 insertions(+), 4 deletions(-) It looks like something is not quite right, this is causing strange spacing, for instance in the About dialog. -- Alexandre Julliard julliard(a)winehq.org

Oct. 2, 2013

Re: I'm not sure why it was rejected

by Vincent Povirk

> I guess if you SetLastError to not implemented you cannot return S_OK too It doesn't make sense to use SetLastError at all for functions returning HRESULT.

Oct. 2, 2013

Re: [PATCH 4/7] msvcr90/tests: Use the W form of CreateEvent().

by Marvin

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

Oct. 2, 2013

Re: [PATCH 2/7] qedit/tests: Use the W version of FindResource().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2455 Your paranoid android. === w2008s64 (32 bit mediadet) === mediadet.c:149: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 0040184A === w2008s64 (64 bit mediadet) === mediadet.c:149: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 00000000004017A3

Oct. 2, 2013

Re: I'm not sure why it was rejected

by Marcus Meissner

On Wed, Oct 02, 2013 at 12:26:51PM -0300, Bruno Jesus wrote: > On Wed, Oct 2, 2013 at 12:17 PM, Akira Nakagawa <matyapiro31(a)gmail.com> wrote: > > I cannnot make sure my patch 99266 was rejected. > > I can't really tell why it was rejected but I can tell there are mixed > space/tabs in the SetLastError lines. > > I guess if you SetLastError to not implemented you cannot return S_OK too > > Try comparing your patch with other patches that added new dlls. It > looks like you're missing the changes in configure and Makefile.in. > http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=commit&s=new+dll no, he is not as they are autogenerated. Last open issue was the incorrect licenses. Ciao, Marcus

Oct. 2, 2013

Re: I'm not sure why it was rejected

by Bruno Jesus

On Wed, Oct 2, 2013 at 12:17 PM, Akira Nakagawa <matyapiro31(a)gmail.com> wrote: > I cannnot make sure my patch 99266 was rejected. I can't really tell why it was rejected but I can tell there are mixed space/tabs in the SetLastError lines. I guess if you SetLastError to not implemented you cannot return S_OK too Try comparing your patch with other patches that added new dlls. It looks like you're missing the changes in configure and Makefile.in. http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=commit&s=new+dll Regards, Bruno

Oct. 2, 2013

I'm not sure why it was rejected

by Akira Nakagawa

I cannnot make sure my patch 99266 <cid:part1.07050802.08000504(a)gmail.com> was rejected. From: Akira Nakagawa <matyapiro31(a)gmail.com> Subject: add ualapi directory(try 15) Message-Id: <52496BA8.1020908(a)gmail.com> Date: Mon, 30 Sep 2013 21:16:40 +0900 I think it has no problem without what Bruno said. So this is the last one. >From e7b788f927621f5d8544bbf73f1e155e05098387 Mon Sep 17 00:00:00 2001 Message-Id: <e7b788f927621f5d8544bbf73f1e155e05098387.1380543383.git.matyapiro31(a)gmail…> From: Akira Nakagawa <matyapiro31(a)gmail.com> Date: Mon, 30 Sep 2013 21:13:52 +0900 Subject: [PATCH] add ual directory (try 15) --- dlls/ualapi/Makefile.in | 6 ++++ dlls/ualapi/main.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++ dlls/ualapi/ualapi.spec | 4 +++ include/ual.h | 47 +++++++++++++++++++++++++++ 4 files changed, 143 insertions(+) diff --git a/dlls/ualapi/Makefile.in b/dlls/ualapi/Makefile.in new file mode 100644 index 0000000..59e56fe --- /dev/null +++ b/dlls/ualapi/Makefile.in @@ -0,0 +1,6 @@ +MODULE = ualapi.dll +IMPORTLIB = ualapi + +C_SRCS = main.c + +(a)MAKE_DLL_RULES@ diff --git a/dlls/ualapi/main.c b/dlls/ualapi/main.c new file mode 100644 index 0000000..7b3ff7b --- /dev/null +++ b/dlls/ualapi/main.c @@ -0,0 +1,86 @@ +/* + * main.c + * This file is part of wine + * + * Copyright (C) 2013 - Akira Nakagawa + * + * wine 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. + * + * wine 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 wine. If not, see <http://www.gnu.org/licenses/>. + */ +#include <stdio.h> +#include "windef.h" +#include "winbase.h" +#include "winuser.h" +#include "wine/debug.h" +#include "ual.h" + +WINE_DEFAULT_DEBUG_CHANNEL(ualapi); + +/***************************************************** + * DllMain + */ +BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) +{ + TRACE("(%p, %d, %p)\n", hinstDLL, fdwReason, lpvReserved); + switch (fdwReason) + { + case DLL_WINE_PREATTACH: + return FALSE; /* prefer native version */ + case DLL_PROCESS_ATTACH: + DisableThreadLibraryCalls(hinstDLL); + break; + } + return TRUE; +} + +/* + * Return S_OK if succeed,or return error code + * It records Data of the user. + */ +HRESULT +WINAPI +UalStart( + PUAL_DATA_BLOB Data){ + FIXME("This function is not supported.\n"); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return S_OK; +} + +HRESULT +WINAPI +UalStop( + PUAL_DATA_BLOB Data){ + FIXME("This function is not supported.\n"); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return S_OK; +} + +HRESULT +WINAPI +UalInstrument( + PUAL_DATA_BLOB Data){ + FIXME("This function is not supported.\n"); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return S_OK; +} + +HRESULT +WINAPI +UalRegisterProduct( + const WCHAR* wszProductName, + const WCHAR* wszRoleName, + const WCHAR* wszGuid){ + FIXME("This function is not supported.\n"); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return S_OK; +} diff --git a/dlls/ualapi/ualapi.spec b/dlls/ualapi/ualapi.spec new file mode 100644 index 0000000..b7682fb --- /dev/null +++ b/dlls/ualapi/ualapi.spec @@ -0,0 +1,4 @@ +@ stdcall UalStart(ptr) +@ stdcall UalStop(ptr) +@ stdcall UalInstrument(ptr) +@ stdcall UalRegisterProduct(wstr wstr wstr) diff --git a/include/ual.h b/include/ual.h new file mode 100644 index 0000000..14f1c74 --- /dev/null +++ b/include/ual.h @@ -0,0 +1,47 @@ +/* + * ual.h: User Access Logging + * This file is part of wine + * + * Copyright (C) 2013 - Akira Nakagawa + * + * wine 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. + * + * wine 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 wine. If not, see <http://www.gnu.org/licenses/>. + */ + + +#ifndef _UAL_H_INCLUDED +#define _UAL_H_INCLUDED + +#include <winsock2.h> + +typedef struct tagUAL_DATA_BLOB +{ + DWORD Size; + GUID RoleGuid; + GUID TenantId; + SOCKADDR_STORAGE Address; + WCHAR UserName[MAX_PATH]; +} UAL_DATA_BLOB, *PUAL_DATA_BLOB; + +HRESULT WINAPI UalStart(PUAL_DATA_BLOB Data); + +HRESULT WINAPI UalStop(PUAL_DATA_BLOB Data); + +HRESULT WINAPI UalInstrument(PUAL_DATA_BLOB Data); + +HRESULT WINAPI UalRegisterProduct( + const WCHAR* wszProductName, + const WCHAR* wszRoleName, + const WCHAR* wszGuid); +#endif + -- 1.8.1.2

Oct. 2, 2013

Re: Re: kernel32/tests: Fix the test_waittxempty() timeout.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2434 Your paranoid android. === wxppro (32 bit comm) === comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... No test summary line found Failure running script in VM: network read timed out === w2008s64 (32 bit comm) === comm.c:1670: test_AbortWaitCts timeout 500 handle 000000C4 comm.c:1637: Changing CommMask on the fly for handle 000000C4 after timeout 500 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 No test summary line found Failure running script in VM: network read timed out === w7pro64 (32 bit comm) === comm.c:1670: test_AbortWaitCts timeout 500 handle 00000130 comm.c:1637: Changing CommMask on the fly for handle 00000130 after timeout 500 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1094: Test failed: WriteFile failed with a timeout comm.c:1096: Test failed: GetOverlappedResult reported error 996 comm.c:1097: Test failed: expected 64000, written 0 Timeout === w2008s64 (64 bit comm) === comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 Timeout === w7pro64 (64 bit comm) === comm.c:887: WaitCommEvent for EV_TXEMPTY took 0 ms (timeout 1000) comm.c:1670: test_AbortWaitCts timeout 500 handle 00000000000000CC comm.c:1637: Changing CommMask on the fly for handle 00000000000000CC after timeout 500 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:1064: Test failed: WaitCommEvent failed with a timeout comm.c:1075: recovering after WAIT_TIMEOUT... comm.c:1086: Test failed: WaitCommEvent error 0 comm.c:1087: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 Timeout

Oct. 2, 2013

Re: Assorted spelling fixes.

by Marvin

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

Oct. 2, 2013

Re: Assorted spelling fixes.

by Marvin

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

Oct. 2, 2013

Re: Assorted spelling fixes.

by Marvin

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

Oct. 2, 2013

Re: Assorted spelling fixes.

by Marvin

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

Oct. 2, 2013

Re: Assorted spelling fixes.

by Marvin

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

Oct. 2, 2013

Re: [5/5] gdi32: Don't modify output glyph metrics unless the function succeeds. (resend)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2426 Your paranoid android. === wvista (32 bit font) === The test timed out === w2008s64 (32 bit font) === Failure running script in VM: network read timed out === w2008s64 (64 bit font) === Failure running script in VM: network read timed out

Oct. 2, 2013

Re: kernel32: Add tests for job objects (try 3)

by Nikolay Sivov

On 10/2/2013 12:58, Andrew Cook wrote: > + if(!pCreateJobObjectW) { > + win_skip("No job object support\n"); > + return; > + } Once you checked that I suppose you don't need to check for pIsProcessInJob being null, or it still could happen? > + if (option && strcmp(option, "wait") == 0) { > + /* for job object tests */ > + Sleep(3000); > + return; > + } Is it really necessary?

Oct. 2, 2013

Re: winemac: Reapply display modes when switching back to app after "escaping" with Command-Tab.

by Ken Thomases

On Oct 1, 2013, at 11:24 PM, Ken Thomases wrote: > May fix bug <http://bugs.winehq.org/show_bug.cgi?id=34475>. Should fix bug <http://bugs.winehq.org/show_bug.cgi?id=34209>, too. -Ken

Oct. 2, 2013

Re: mshtml: Added support for 'document' and 'window' script for attribute values.

by Marvin

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

Oct. 1, 2013

Re: imm32: ImmGetCandidateWindow should not return unset data

by Aric Stewart

Ok, fixed and resent -aric On 10/1/13 2:13 PM, Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> @@ -663,6 +663,8 @@ HIMC WINAPI ImmCreateContext(void) >> gl->dwSize = sizeof(GUIDELINE); >> ImmUnlockIMCC(new_context->IMC.hGuideLine); >> >> + memset(new_context->IMC.cfCandForm, -1, sizeof(new_context->IMC.cfCandForm)); >> + > > That's ugly. If you are using the index for validity checking then you > should put some appropriate value in there, there's no reason to put > garbage in the whole structure. >

Oct. 1, 2013

Re: imm32: ImmGetCandidateWindow should not return unset data

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -663,6 +663,8 @@ HIMC WINAPI ImmCreateContext(void) > gl->dwSize = sizeof(GUIDELINE); > ImmUnlockIMCC(new_context->IMC.hGuideLine); > > + memset(new_context->IMC.cfCandForm, -1, sizeof(new_context->IMC.cfCandForm)); > + That's ugly. If you are using the index for validity checking then you should put some appropriate value in there, there's no reason to put garbage in the whole structure. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2013

Re: mscoree: Implement CreateInterface

by Vincent Povirk

Any reason not to share code with CLRCreateInstance?

Oct. 1, 2013

Re: [4/5] gdi32: Fix the B spacing value of empty glyph. (try 2)

by Alexandre Julliard

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Try 2: > - Get rid of redundant trace message in the last patch. > > --- > dlls/gdi32/freetype.c | 2 +- > dlls/gdi32/tests/font.c | 8 +++++++- > 2 files changed, 8 insertions(+), 2 deletions(-) This is causing failures here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok font.c:1133: Test succeeded inside todo block: LTR -1 advanced: abcA's sign should be unchanged font.c:1141: Test succeeded inside todo block: LTR -1 advanced: abcfA's sign should be unchanged font.c:1133: Test succeeded inside todo block: RTL 1 advanced: abcA's sign should be unchanged font.c:1141: Test succeeded inside todo block: RTL 1 advanced: abcfA's sign should be unchanged -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2013

Re: kernel32/tests: Fix the test_waittxempty() timeout.

by Francois Gouget

On Tue, 1 Oct 2013, Francois Gouget wrote: [...] > The timeout was too short and would only work for UARTs that have a > FIFO and where the trigger level was set just right. With this patch > we calculate how much time sending the test data will actually take > and tack on a small margin to take into account scheduling delays. I should note that this does not fix the test failuers on the QEmu VMs, specifically the WineTestBot ones. If QEmu 1.1.2 is anything like QEmu 1.6.0, then the serial port seems to operate at a fixed speed of about 1800000bps. This is so out of line with the 150bps that we request that it causes the test to fail. [...] > * Windows reports that all bytes have been sent not when the UART's > buffer is empty but when they all made it to the UART's buffer. Note > that this can be tested (see next mail). And here is this test. IT IS NOT MEANT TO BE COMMITTED. (but seeing the WineTestBot results would still be interesting) On my one Windows PC with a real UART (Intel(R) 82801DBM LPC Interface Controller - 24CC, i.e. ICH4 which emulates a 16550A UART) I get the following results which clearly illustrate the impact of the FIFO/trigger level. comm.c:1100: WaitCommEvent(1 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(2 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(3 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(4 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(5 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(6 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(7 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(8 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(9 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(10 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(11 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(12 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(13 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(14 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(15 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(16 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(17 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(18 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(19 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(20 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(21 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(22 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(23 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(24 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(25 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(26 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(27 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(28 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(29 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(30 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(31 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(32 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(33 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(34 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(35 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(36 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(37 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(38 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(39 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(40 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(41 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(42 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(43 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(44 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(45 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(46 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(47 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(48 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(49 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(50 bytes) for EV_TXEMPTY took 2734 ms -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

Oct. 1, 2013

Re: [3/3] ws2_32: Always return the source address from WSAAccept.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2421 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (b0): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (5a0): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (624): unexpectedly at the OOB mark: 0

Oct. 1, 2013

Re: [2/3] ws2_32: Return an error from accept if the address buffer is too small.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2420 Your paranoid android. === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (5a0): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 757A9799 === w7pro64 (32 bit sock) === sock.c:528: Test failed: oob_server (778): not at the OOB mark: 1 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (7f8): unexpectedly at the OOB mark: 0

Oct. 1, 2013

Re: [PATCH] dsound: fixup IDirectSoundCaptureBuffer_QueryInterface

by Andrew Eikum

Seems reasonable, but could you put together some tests to show this? Andrew On Sat, Sep 28, 2013 at 10:41:15AM +0200, Maarten Lankhorst wrote: > diff --git a/dlls/dsound/capture.c b/dlls/dsound/capture.c > index 40f1702..0fe300c 100644 > --- a/dlls/dsound/capture.c > +++ b/dlls/dsound/capture.c > @@ -51,7 +51,7 @@ typedef struct IDirectSoundCaptureBufferImpl > IDirectSoundCaptureBuffer8 IDirectSoundCaptureBuffer8_iface; > IDirectSoundNotify IDirectSoundNotify_iface; > LONG numIfaces; /* "in use interfaces" refcount */ > - LONG ref, refn; > + LONG ref, refn, has_dsc8; > /* IDirectSoundCaptureBuffer fields */ > DirectSoundCaptureDevice *device; > DSCBUFFERDESC *pdscbd; > @@ -241,8 +241,9 @@ static HRESULT WINAPI IDirectSoundCaptureBufferImpl_QueryInterface(IDirectSoundC > > *ppobj = NULL; > > - if ( IsEqualGUID( &IID_IDirectSoundCaptureBuffer, riid ) || > - IsEqualGUID( &IID_IDirectSoundCaptureBuffer8, riid ) ) { > + if ( IsEqualIID( &IID_IUnknown, riid ) || > + IsEqualIID( &IID_IDirectSoundCaptureBuffer, riid ) || > + (This->has_dsc8 && IsEqualIID( &IID_IDirectSoundCaptureBuffer8, riid )) ) { > IDirectSoundCaptureBuffer8_AddRef(iface); > *ppobj = iface; > return S_OK; > @@ -1239,6 +1240,8 @@ static HRESULT WINAPI IDirectSoundCaptureImpl_CreateCaptureBuffer(IDirectSoundCa > > if (hr != DS_OK) > WARN("IDirectSoundCaptureBufferImpl_Create failed\n"); > + else > + This->device->capture_buffer->has_dsc8 = This->has_dsc8; > > return hr; > } > > >

Oct. 1, 2013

Re: [3/3] ws2_32: Always return the source address from WSAAccept.

by Hans Leidekker

On Tue, 2013-10-01 at 09:32 -0300, Bruno Jesus wrote: > On Tue, Oct 1, 2013 at 6:37 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > > --- > > dlls/ws2_32/socket.c | 9 +-------- > > dlls/ws2_32/tests/sock.c | 6 +++--- > > 2 files changed, 4 insertions(+), 11 deletions(-) > > > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > > index c34de4b..6855298 100644 > > --- a/dlls/ws2_32/socket.c > > +++ b/dlls/ws2_32/socket.c > > @@ -6546,12 +6546,8 @@ SOCKET WINAPI WSAAccept( SOCKET s, struct WS_sockaddr *addr, LPINT addrlen, > > TRACE("Socket %04lx, sockaddr %p, addrlen %p, fnCondition %p, dwCallbackData %ld\n", > > s, addr, addrlen, lpfnCondition, dwCallbackData); > > > > - > > - size = sizeof(src_addr); > > - cs = WS_accept(s, &src_addr, &size); > > - > > + cs = WS_accept(s, addr, addrlen); > > The parameter addr may be NULL in WSAAccept, I can't check the source > code right now but what will WS_accept do in this case? It will skip the WS_getpeername call. Good point, I'll add some tests for this case and resubmit the series.

Oct. 1, 2013

Re: [1/3] ws2_32: Always clear res on error in getaddrinfo/GetAddrInfoW.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2419 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (2a4): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (774): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (884): unexpectedly at the OOB mark: 0 === w7pro64 (64 bit sock) === sock.c:509: Test failed: oob_server (af8): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (af8): unexpectedly at the OOB mark: 0 sock.c:288: Test failed: do_synchronous_recv (af8): error 10054: sock.c:534: Test failed: oob_server (af8): not at the OOB mark: 1

Oct. 1, 2013

Re: [3/3] ws2_32: Always return the source address from WSAAccept.

by Bruno Jesus

On Tue, Oct 1, 2013 at 6:37 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > --- > dlls/ws2_32/socket.c | 9 +-------- > dlls/ws2_32/tests/sock.c | 6 +++--- > 2 files changed, 4 insertions(+), 11 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index c34de4b..6855298 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -6546,12 +6546,8 @@ SOCKET WINAPI WSAAccept( SOCKET s, struct WS_sockaddr *addr, LPINT addrlen, > TRACE("Socket %04lx, sockaddr %p, addrlen %p, fnCondition %p, dwCallbackData %ld\n", > s, addr, addrlen, lpfnCondition, dwCallbackData); > > - > - size = sizeof(src_addr); > - cs = WS_accept(s, &src_addr, &size); > - > + cs = WS_accept(s, addr, addrlen); The parameter addr may be NULL in WSAAccept, I can't check the source code right now but what will WS_accept do in this case? Best wishes, Bruno

Oct. 1, 2013

Re: [PATCH 2/5] wined3d: Move location management into the resource.

by Henri Verbeet

Please split this.

Oct. 1, 2013

Re: [PATCH 2/5] wined3d: Move location management into the resource.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, To illustrate the goal of these patches I've attached an archive of all surface cleanup patches to this mail. The goal is to merge GL buffer object handling of buffers, surfaces and volumes. The main motivation for this is to handle WINED3D_MAP_DISCARD in one central place once dynamic resource handling is implemented in the command stream. The 4 patches in this series move location and buffer handling code from volume.c to resource.c. The next patches remove broken(overlay, partial rectangle handling) and half-broken(direct DIB maps, buffers) surface features. The next step is migrating surfaces to the resource location and loading code in resource.c. After that WINED3D_LOCATION_DISCARDED handling is improved and previously removed surface features re-added. Due to the removal of some surface features, performance regressions are possible. I think it's unlikely because the existing surface PBO code doesn't really do what it is supposed to do. Functional regressions should not happen. This patchset does not deal with d3d buffers. The central aspect of merging buffer handling is removing color and rhw conversion support. (or, alternatively, adding a separate location WINED3D_LOCATION_CONVBUFFER if we really want to keep the conversion code.) There are some problems later in the patchset that need fixing: Patch 24 is too big, patches 48 and 52 need to be moved. Non-GL ddraw rendering is broken at the moment (black screen). My patches don't make this any worse, but I'd like to fix it to make sure non-GL operation works as intended. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSSqzhAAoJEN0/YqbEcdMww1wP/jYYo0B/igDHd0QwOkwk8DIz ip4PKHxRgqaSYzswcBGZge+iBrJrvXSHh3cScG9KJ1a/VeaRlPyhDsFDzPce1VDK 0IX7iF/gKpZazPVy21lSIPQMlErSVy58fkIsd/PqKV/zyU8zNyZDkYU3n80itYrq Y3hPhaKbJIDN8QbhIOZu0egaiHObcwomBgZCfrUv+hr+xf+gMERYbqN9gj2JWFwJ dx4EzdeTFw1CZkFExbAJKt5zWA2KeFyitVU887WOSJpa3UbqemGpOID8vnYZlABZ mmqrS22XWjXlo2+0s0NufxeQJHvzpkcludLkg8a12r4FDs+ORYYnGbUeUy2o2Rud uV2quoeucA1TEAyF20JCrVNuCvDz5nvQq19rzR51k7FF/IsKGiI823ZGA54F4Dkn DZkyDcE0rnI2Re+br1aM31ZUt/maTxQMpk10BAAjwz1jbXQ4plZ9dtO9/DObdw8r nfPDJz+DsuBv19Th7MPjTxvXRjxVFTzlfuXNk/cOfAhgNdpEFSOGCAexGi6moSq1 6slQeLb8PqmO/83JQBuz4OI86dSoGSC6O9c/TtWXdW1PgCDyHgFvNb3jmQHsf7ya U1o2TkkNhLvfYz5Eo85Ep8oyVIF09CDrqQzUo10q33K5Y2E3RM8Xbxc+crGtjgxA TGwCwR8SRvAW+DfeP7bq =MEk/ -----END PGP SIGNATURE-----

Oct. 1, 2013

Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().

by Ralf Habacker

On 01.10.2013 12:40, Alexandre Julliard wrote: > Ralf Habacker <ralf(a)habacker.de> writes: > >> On 01.10.2013 12:12, Alexandre Julliard wrote: >>> Ralf Habacker <ralf.habacker(a)freenet.de> writes: >>> >>>> With other patches i have been told to implement such stuff in the dib >>>> driver. Unfortunally this do not works in this case, because in the top >>>> level function it looks like having driver specific stuff using display >>>> coordinates. >>> It would still most likely have to be in the driver, >> which is freetype_GetTextExtentExPoint() ? >> >>> though maybe the driver would not be calling that exact entry point. >> not sure i understand right: >> >> GetTextExtentExPointW() calls get_char_positions(), which runs >> dev->funcs->pGetTextExtentExPoint(), which is mapped to >> freetype_GetTextExtentExPoint(), which is in the driver. Which entry >> point your are refering else ? > The various text rendering entry points in the graphics drivers. > >>> In any case, you can't change the DC transform like this >> then a real solution requires to move the transformation to logical >> coordinates stuff in BOOL GetTextExtentExPointW() to >> freetype_GetTextExtentExPoint() and to manipulate the related matrixes >> in freetype_GetTextExtentExPoint() directly wen using GM_ADVANCED ? > No, I don't think so. The transform is only used to determine the font > scaling factor. how then ? >>> and you'll need test cases. >>> >> Do you mean in detail: >> >> 1. Create a specific font >> 2. Run GetTextExtentExPointW() which specific parameters >> 3. check if it results expected values > Well, yes, that's what all tests do. >

Oct. 1, 2013

Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > The tests show that this is how fully up to date Windows versions starting > from XP behave, isn't that convincing enough? If not, what else do you need > to see? An application that breaks because of this. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2013

Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > Do you propose to leave NtWriteFile/NtReadFile in the state when they > > return STATUS_SUCCESS for overlapped writes and reads? But that's clearly > > not how Windows implements this accordingto the tests, and that would > > require changing all the tests to accept both values so that they pass > > under Wine. > > Well, the tests fail mostly because you have decided that this behavior > is broken. I'm not convinced. The tests show that this is how fully up to date Windows versions starting from XP behave, isn't that convincing enough? If not, what else do you need to see? -- Dmitry.

Oct. 1, 2013

Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().

by Alexandre Julliard

Ralf Habacker <ralf(a)habacker.de> writes: > On 01.10.2013 12:12, Alexandre Julliard wrote: >> Ralf Habacker <ralf.habacker(a)freenet.de> writes: >> >>> With other patches i have been told to implement such stuff in the dib >>> driver. Unfortunally this do not works in this case, because in the top >>> level function it looks like having driver specific stuff using display >>> coordinates. >> It would still most likely have to be in the driver, > which is freetype_GetTextExtentExPoint() ? > >> though maybe the driver would not be calling that exact entry point. > not sure i understand right: > > GetTextExtentExPointW() calls get_char_positions(), which runs > dev->funcs->pGetTextExtentExPoint(), which is mapped to > freetype_GetTextExtentExPoint(), which is in the driver. Which entry > point your are refering else ? The various text rendering entry points in the graphics drivers. >> In any case, you can't change the DC transform like this > > then a real solution requires to move the transformation to logical > coordinates stuff in BOOL GetTextExtentExPointW() to > freetype_GetTextExtentExPoint() and to manipulate the related matrixes > in freetype_GetTextExtentExPoint() directly wen using GM_ADVANCED ? No, I don't think so. The transform is only used to determine the font scaling factor. >> and you'll need test cases. >> > Do you mean in detail: > > 1. Create a specific font > 2. Run GetTextExtentExPointW() which specific parameters > 3. check if it results expected values Well, yes, that's what all tests do. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2013

Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Do you propose to leave NtWriteFile/NtReadFile in the state when they > return STATUS_SUCCESS for overlapped writes and reads? But that's clearly > not how Windows implements this accordingto the tests, and that would > require changing all the tests to accept both values so that they pass > under Wine. Well, the tests fail mostly because you have decided that this behavior is broken. I'm not convinced. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2013

Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().

by Ralf Habacker

On 01.10.2013 12:12, Alexandre Julliard wrote: > Ralf Habacker <ralf.habacker(a)freenet.de> writes: > >> With other patches i have been told to implement such stuff in the dib >> driver. Unfortunally this do not works in this case, because in the top >> level function it looks like having driver specific stuff using display >> coordinates. > It would still most likely have to be in the driver, which is freetype_GetTextExtentExPoint() ? > though maybe the driver would not be calling that exact entry point. not sure i understand right: GetTextExtentExPointW() calls get_char_positions(), which runs dev->funcs->pGetTextExtentExPoint(), which is mapped to freetype_GetTextExtentExPoint(), which is in the driver. Which entry point your are refering else ? > In any case, you can't change the DC transform like this then a real solution requires to move the transformation to logical coordinates stuff in BOOL GetTextExtentExPointW() to freetype_GetTextExtentExPoint() and to manipulate the related matrixes in freetype_GetTextExtentExPoint() directly wen using GM_ADVANCED ? > and you'll need test cases. > Do you mean in detail: 1. Create a specific font 2. Run GetTextExtentExPointW() which specific parameters 3. check if it results expected values Regards Ralf

Oct. 1, 2013

Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> I don't see the point. Do you actually have an app that depends on this? > > > > When I started to work on this I had an app that has one of the reasons to > > require running under Vista+ was the difference in overlapped IO behavior. > > On the other hand the tests clearly show that up-to-date Windows versions > > (including Windows XP) always return STATUS_PENDING for asynchronous read > > and write on disk files. Is there another way to remove all those todo_wine > > statements from the tests? > > The tests also show that returning success is allowed for other file > types, so I don't see a need to add complexity to treat files > differently, unless there's a demonstrated need. Do you propose to leave NtWriteFile/NtReadFile in the state when they return STATUS_SUCCESS for overlapped writes and reads? But that's clearly not how Windows implements this accordingto the tests, and that would require changing all the tests to accept both values so that they pass under Wine. -- Dmitry.

Oct. 1, 2013

Re: ntdll: Fix the version reported for 64-bit Windows XP.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > @@ -129,11 +129,19 @@ static const RTL_OSVERSIONINFOEXW VersionData[NB_WINDOWS_VERSIONS] = > 4, 0, 0, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field with a value! */ > }, > /* WINXP */ > +#ifdef _WIN64 > + { > + sizeof(RTL_OSVERSIONINFOEXW), 5, 2, 0xECE, VER_PLATFORM_WIN32_NT, > + {'S','e','r','v','i','c','e',' ','P','a','c','k',' ','1',0}, > + 1, 0, VER_SUITE_SINGLEUSERTS, VER_NT_WORKSTATION, 0 > + }, > +#else > { > sizeof(RTL_OSVERSIONINFOEXW), 5, 1, 0xA28, VER_PLATFORM_WIN32_NT, > {'S','e','r','v','i','c','e',' ','P','a','c','k',' ','3',0}, > 3, 0, VER_SUITE_SINGLEUSERTS, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field with a value! */ > }, > +#endif This would mean that the 32-bit side sees a different version. I don't think that's correct. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2013

Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().

by Alexandre Julliard

Ralf Habacker <ralf.habacker(a)freenet.de> writes: > With other patches i have been told to implement such stuff in the dib > driver. Unfortunally this do not works in this case, because in the top > level function it looks like having driver specific stuff using display > coordinates. It would still most likely have to be in the driver, though maybe the driver would not be calling that exact entry point. In any case, you can't change the DC transform like this. and you'll need test cases. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2013

mscoree: Implement CreateInterface

by Alistair Leslie-Hughes

Hi, Changelog: mscoree: Implement CreateInterface Best Regards Alistair Leslie-Hughes

Oct. 1, 2013

oledb32: Implement IDataSourceLocator get/put hWnd (try 4)

by Alistair Leslie-Hughes

Hi, Corrected warnings. Changelog: Implement IDataSourceLocator get/put hWnd Best Regards Alistair Leslie-Hughes

Oct. 1, 2013

Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> I don't see the point. Do you actually have an app that depends on this? > > When I started to work on this I had an app that has one of the reasons to > require running under Vista+ was the difference in overlapped IO behavior. > On the other hand the tests clearly show that up-to-date Windows versions > (including Windows XP) always return STATUS_PENDING for asynchronous read > and write on disk files. Is there another way to remove all those todo_wine > statements from the tests? The tests also show that returning success is allowed for other file types, so I don't see a need to add complexity to treat files differently, unless there's a demonstrated need. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2013

Re: ws2_32: Implement WSASendMsg() (try 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2414 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (210): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (5a0): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (6b0): unexpectedly at the OOB mark: 0

Oct. 1, 2013

RE: Increasing max_req_size and subsequent errors

by Hugh McMaster

Solved. server/protocol.def is the correct place to adjust the request_max_size value.

Oct. 1, 2013

Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > I don't see the point. Do you actually have an app that depends on this? When I started to work on this I had an app that has one of the reasons to require running under Vista+ was the difference in overlapped IO behavior. On the other hand the tests clearly show that up-to-date Windows versions (including Windows XP) always return STATUS_PENDING for asynchronous read and write on disk files. Is there another way to remove all those todo_wine statements from the tests? -- Dmitry.

Oct. 1, 2013

Re: [1/3] gdi32: Return fake BBox when requested empty glyph metrics. (try 3)

by Bruno Jesus

On Fri, Sep 27, 2013 at 8:16 AM, Akihiro Sagawa <sagawa.aki(a)gmail.com> wrote: > > Fixes bug 18440, 20847. > > Try 3: > - Rebase to recent source. > - Separate ABC metrics change. > - Use conditional operator. > --- > dlls/gdi32/freetype.c | 4 ++-- > dlls/gdi32/tests/font.c | 24 ++++++++---------------- > 2 files changed, 10 insertions(+), 18 deletions(-) > + ok(gm.gmBlackBoxY == 1, "%2d:expected 1, got %u\n", fmt[i], gm.gmBlackBoxX); There seems to be a copy&paste issue in all lines related to gmBlackBoxY reporting the error as gmBlackBoxX. Regards, Bruno

Oct. 1, 2013