March 2017 - Wine-Devel - list.winehq.org

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Stas Sergeev

31.03.2017 17:11, Alexandre Julliard пишет: > In fact it would be nice to be able to make sidt/sgdt/etc. segfault > too. I know a new syscall is a pain, Maybe arch_prctl() then?

March 31, 2017

Re: [PATCH] wmvcore: Add WMReader stubs.

by Andrew Eikum

On Thu, Mar 30, 2017 at 05:30:09PM -0500, Jefferson Carpenter wrote: > Do FIXME statements need to print out the passed-in arguments? Only > outputting the method name, you can still tell what needs to be > implemented. Also, to output each argument, there are typedefs to > consider, and you have to choose whether to dereference any pointer > arguments, which makes it rather difficult to automate the process. > It's nice if you can put in the effort, but for just stubbing interfaces I think you can get away with FIXME("%p\n", This). Actual function implementations should trace the arguments correctly. Andrew

March 31, 2017

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Alexandre Julliard

Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> writes: > On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote: >> 30.03.2017 08:14, Ricardo Neri пишет: >> >>>> But at least dosemu implements it, so probably it is needed. >> >>> Right. >> >>> >> >>>> Of course if it is used by one of 100 DOS progs, then there >> >>>> is an option to just add its support to dosemu2 and pretend >> >>>> the compatibility problems did not exist. :) >> >>> Do you mean relaying the GP fault to dosemu instead of trapping it and >> >>> emulating it in the kernel? >> >> Yes, that would be optimal if this does not severely break >> >> the current setups. If we can find out that smsw is not in >> >> the real use, we can probably do exactly that. >> >> But other >> >> instructions are not in real use in v86 for sure, so I >> >> wouldn't be adding the explicit test-cases to the kernel >> >> that will make you depend on some particular behaviour >> >> that no one may need. >> >> My objection was that we shouldn't >> >> write tests before we know exactly how we want this to work. >> > OK, if only SMSW is used then I'll keep the emulation for SMSW only. >> In fact, smsw has an interesting property, which is that >> no one will ever want to disable its in-kernel emulation >> to provide its own. >> So while I'll try to estimate its usage, emulating it in kernel >> will not be that problematic in either case. > > Ah good to know! > >> As for protected mode, if wine only needs sgdt/sidt, then >> again, no one will want to disable its emulation. Not the >> case with sldt, but AFAICS wine doesn't need sldt, and so >> we can leave sldt without a fixups. Is my understanding >> correct? > > This is my understanding as well. I could not find any use of sldt in > wine. Alexandre, would you mind confirming? Some versions of the Themida software protection are known to use sldt as part of the virtual machine detection code [1]. The check currently fails because it expects the LDT to be zero, so the app is already broken, but sldt segfaulting would still cause a crash where there wasn't one before. However, I'm only aware of one application using this, and being able to catch and emulate sldt ourselves would actually give us a chance to fix this app in newer Wine versions, so I'm not opposed to having it segfault. In fact it would be nice to be able to make sidt/sgdt/etc. segfault too. I know a new syscall is a pain, but as far as Wine is concerned, being able to opt out from any emulation would be potentially useful. [1] https://www.winehq.org/pipermail/wine-bugs/2008-February/094470.html -- Alexandre Julliard julliard(a)winehq.org

March 31, 2017

Re: [PATCH 2/2] regedit: Handle comment lines with leading spaces and tabs

by Hugh McMaster

On Friday, 31 March 2017 11:07 PM, Alexandre Julliard wrote: > You can also ignore white space before comments, but still return it for > other lines, if there is a case where the callers would want that. > Otherwise getting rid of whitespace right away is fine. A few test cases > with leading whitespace may be a good idea. Somewhat strangely, we actually call isspaceW() in processSetValue() before we get the registry value name. But it is already too late. We need to check for whitespace in processRegEntry() or earlier; otherwise, the import fails. So I think handling whitespace in get_lineA/W() will be far more efficient and easier to maintain. But to be certain, I'll add some tests with whitespace variations first. Thanks for the advice. -- Hugh McMaster

March 31, 2017

Re: [PATCH 2/2] regedit: Handle comment lines with leading spaces and tabs

by Alexandre Julliard

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > I guess it depends on how you think we should handle such whitespace. parse_file_header() checks for whitespace > before processing the file header. We don't bother checking in processRegEntry() or processRegEntry31(). > > On Windows, all lines in registry files can have leading spaces and tabs. The exception is Windows 3.1, which > doesn't allow leading whitespace at all. > > In Wine, we ignore any registry line with leading whitespace. So importing a file like the following will fail. > (In case it's not clear, there are two spaces before the opening square bracket.) > > REGEDIT4 > [HKEY_CURRENT_USER\Software\Wine\regedit_test] > "Value"="Data" > > One option is to move the check for ';' and '#' to processRegEntry(), but that would require A->W line conversion first. > We would then add an appropriate while loop in that function, handling all line cases. > > Otherwise, we could add the while loops into get_lineA/W() and remove the whitespace check from parse_file_header(), > as it would be redundant. You can also ignore white space before comments, but still return it for other lines, if there is a case where the callers would want that. Otherwise getting rid of whitespace right away is fine. A few test cases with leading whitespace may be a good idea. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2017

Re: [PATCH 04/13] msvcrt: Add CurrentScheduler class stub

by Piotr Caban

Hi, On 03/31/17 11:42, Gijs Vermeulen wrote: > But shouldn't this also change: > > ?_Get(a)_CurrentScheduler@details(a)Concurrency@@SA?AV_Scheduler(a)23@XZ > ?_GetNumberOfVirtualProcessors(a)_CurrentScheduler@details(a)Concurrency@@SAIXZ > ?_Id(a)_CurrentScheduler@details(a)Concurrency@@SAIXZ > -arch=win32 > ?_ScheduleTask(a)_CurrentScheduler@details(a)Concurrency@@SAXP6AXPAX(a)Z0@Z > -arch=win64 > ?_ScheduleTask(a)_CurrentScheduler@details(a)Concurrency@@SAXP6AXPEAX(a)Z0@Z > > Or do these not do the same? It's a different class (_CurrentScheduler vs CurrentScheduler). Thanks, Piotr

March 31, 2017

Re: [PATCH 04/13] msvcrt: Add CurrentScheduler class stub

by Gijs Vermeulen

Hi, I'm sorry if this is a stupid question. But shouldn't this also change: ?_Get(a)_CurrentScheduler@details(a)Concurrency@@SA?AV_Scheduler(a)23@XZ ?_GetNumberOfVirtualProcessors(a)_CurrentScheduler@details(a)Concurrency@@SAIXZ ?_Id(a)_CurrentScheduler@details(a)Concurrency@@SAIXZ -arch=win32 ?_ScheduleTask(a)_CurrentScheduler@details(a)Concurrency@ @SAXP6AXPAX(a)Z0@Z -arch=win64 ?_ScheduleTask(a)_CurrentScheduler@details(a)Concurrency@ @SAXP6AXPEAX(a)Z0@Z Or do these not do the same? Sorry if I'm wasting your time. Sincerely, Gijs 2017-03-30 22:47 GMT+02:00 Piotr Caban <piotr(a)codeweavers.com>: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/concrt140/concrt140.spec | 40 ++++++++--------- > dlls/msvcr100/msvcr100.spec | 28 ++++++------ > dlls/msvcr110/msvcr110.spec | 40 ++++++++--------- > dlls/msvcr120/msvcr120.spec | 40 ++++++++--------- > dlls/msvcr120_app/msvcr120_app.spec | 40 ++++++++--------- > dlls/msvcrt/scheduler.c | 88 ++++++++++++++++++++++++++++++ > +++++++ > 6 files changed, 182 insertions(+), 94 deletions(-) > > > > > >

March 31, 2017

Re: [PATCH 2/2] regedit: Handle comment lines with leading spaces and tabs

by Hugh McMaster

On Friday, 31 March 2017 4:43 AM, Alexandre Julliard wrote: > Hugh McMaster writes: >> --- a/programs/regedit/regproc.c >> +++ b/programs/regedit/regproc.c >> @@ -749,6 +749,7 @@ static char *get_lineA(FILE *fp) >> next = line; >> continue; >> } >> + while (*line == ' ' || *line == '\t') line++; >> if (*line == ';' || *line == '#') >> { >> line = next; > > This is going to affect non-comment lines too, is that what you want? > If so, the commit message is a bit misleading. I guess it depends on how you think we should handle such whitespace. parse_file_header() checks for whitespace before processing the file header. We don't bother checking in processRegEntry() or processRegEntry31(). On Windows, all lines in registry files can have leading spaces and tabs. The exception is Windows 3.1, which doesn't allow leading whitespace at all. In Wine, we ignore any registry line with leading whitespace. So importing a file like the following will fail. (In case it's not clear, there are two spaces before the opening square bracket.) REGEDIT4 [HKEY_CURRENT_USER\Software\Wine\regedit_test] "Value"="Data" One option is to move the check for ';' and '#' to processRegEntry(), but that would require A->W line conversion first. We would then add an appropriate while loop in that function, handling all line cases. Otherwise, we could add the while loops into get_lineA/W() and remove the whitespace check from parse_file_header(), as it would be redundant. I'm open to other ideas as well. Thanks for raising this. -- Hugh McMaster

March 31, 2017

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Ricardo Neri

On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote: > 30.03.2017 08:14, Ricardo Neri пишет: > >>>> But at least dosemu implements it, so probably it is needed. > >>> Right. > >>> > >>>> Of course if it is used by one of 100 DOS progs, then there > >>>> is an option to just add its support to dosemu2 and pretend > >>>> the compatibility problems did not exist. :) > >>> Do you mean relaying the GP fault to dosemu instead of trapping it and > >>> emulating it in the kernel? > >> Yes, that would be optimal if this does not severely break > >> the current setups. If we can find out that smsw is not in > >> the real use, we can probably do exactly that. > >> But other > >> instructions are not in real use in v86 for sure, so I > >> wouldn't be adding the explicit test-cases to the kernel > >> that will make you depend on some particular behaviour > >> that no one may need. > >> My objection was that we shouldn't > >> write tests before we know exactly how we want this to work. > > OK, if only SMSW is used then I'll keep the emulation for SMSW only. > In fact, smsw has an interesting property, which is that > no one will ever want to disable its in-kernel emulation > to provide its own. > So while I'll try to estimate its usage, emulating it in kernel > will not be that problematic in either case. Ah good to know! > As for protected mode, if wine only needs sgdt/sidt, then > again, no one will want to disable its emulation. Not the > case with sldt, but AFAICS wine doesn't need sldt, and so > we can leave sldt without a fixups. Is my understanding > correct? This is my understanding as well. I could not find any use of sldt in wine. Alexandre, would you mind confirming? > In this case, I suppose, we are very well on a way to avoid > the extra syscalls to toggle the emulation features. Great! Then I will keep the emulation for sgdt, sidt, and smsw but not for str and sldt; for both vm86 and protected mode. This seems to be the agreement. Thanks and BR, Ricardo

March 31, 2017

Re: [PATCH] wmvcore: Add WMReader stubs.

by Jefferson Carpenter

Do FIXME statements need to print out the passed-in arguments? Only outputting the method name, you can still tell what needs to be implemented. Also, to output each argument, there are typedefs to consider, and you have to choose whether to dereference any pointer arguments, which makes it rather difficult to automate the process. I could submit just the IDL changes, without the stubs added to wmvcore_main.c. Sorry Alistair, they seem to include your additions as well. On Thu, Mar 30, 2017 at 8:20 AM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Thu, Mar 30, 2017 at 08:25:03AM +0000, Alistair Leslie-Hughes wrote: > > I have a basic patch for adding tests in the works, but I was waiting > > for my IDL changes to be accepted first. > > > > So, If someone wants to review the IDL changes, Since Sebastian has been > > busy with other stuff. > > > > https://source.winehq.org/patches/data/131403 > > > > Okay :) I just noticed one thing: > > > + HRESULT GetAttributeCountEx( > > + [in] WORD stream_num, > > + [out] WORD attributes ); > > If attributes is an out-param, it should be a pointer, right? > > Andrew >

March 30, 2017

Re: COM tracing ...

by Michael Stefaniuc

Hello, On 03/30/2017 04:58 PM, Michael Meeks wrote: > Rather a peripheral question; apologies for that - but I'd imagine > there are experts here that may be able to help. > > I have a black-box problem - a Windows app dealing with confidential > data that I can't easily touch (and thus can't get to run under Wine) - > which does some small but critical automation of MS Office - using VBS / > COM scripting. > > I'd -really- love some input on how best to trace that series of COM > method calls on Windows itself ie. the (remote) service activation, and > the RPC beyond that - particularly the method names, parameters etc. of > the COM/OLE Office API. I've tried (so far): don't you have at least a tlb file for the culprit COM stuff? You can look at that with oleview; Wine implements one too should you be on Linux. > > http://www.rohitab.com/apimonitor > which, while closed, looks interesting; but traces a lot > in a hard-to-search way and doesn't appear to do the > trick. > > https://support.microsoft.com/en-us/help/926098/how-to-enable-com-and-com-d… > Sounds useful: using Event Tracing for Windows (ETW) but > has this rather unhelpful property: > "The binary file must be formatted by Microsoft > so that it can be analyzed. Please forward the > .etl files to your support contact. ..." ;-) > > Component models used to be all the rage in my youth ;-) surely someone > solved the "strace for COM calls" problem elegantly some-when ! Well Wine has that built in for the stuff it implements. For the rest we write tests that exercises the respective API. > Crazily - might it be possible to instrument, interpose and use Wine's > COM impl. on Windows [ which sounds a bit 'exciting' ;-], or ? You don't need Wine for that. You can write wrappers around the COM classes you need, easily if you have the info from the TLB. > Anyhow - help much appreciated & sorry for the noise ! bye michael

March 30, 2017

Re: [PATCH 2/2] regedit: Handle comment lines with leading spaces and tabs

by Alexandre Julliard

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/regproc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/programs/regedit/regproc.c b/programs/regedit/regproc.c > index 131149f..bce551b 100644 > --- a/programs/regedit/regproc.c > +++ b/programs/regedit/regproc.c > @@ -749,6 +749,7 @@ static char *get_lineA(FILE *fp) > next = line; > continue; > } > + while (*line == ' ' || *line == '\t') line++; > if (*line == ';' || *line == '#') > { > line = next; This is going to affect non-comment lines too, is that what you want? If so, the commit message is a bit misleading. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2017

Re: d3d10: sync spec file to Windows 10

by Alexandre Julliard

Austin English <austinenglish(a)gmail.com> writes: > On Thu, Mar 30, 2017 at 7:25 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> On 29 March 2017 at 23:51, Austin English <austinenglish(a)gmail.com> wrote: >>> -- >> We may not necessarily care, but RevertToOldImplementation() is the >> first export instead of the last on my Windows 10. > > My reasoning was that for non-ordinals, it doesn't matter, and that > sorting was preferred. Usually if it's not sorted on Windows it's because the ordinal matters. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2017

Re: [2/3] windowscodecs: Test for png codec seeking too far

by Viktor Semykin

Okay, I split the patch and put it in the tail of the series. It's up to you to accept it or not. On 30/03/17 03:57, Vincent Povirk wrote: > I think you should either split the patch, or leave it using HGLOBAL. > > On Wed, Mar 29, 2017 at 11:12 PM, Viktor Semykin <thesame.ml(a)gmail.com> wrote: >> No, there's no such a reason. This test would pass with HGLOBAL as well. >> What should I do in this situation? Would it better to leave it as it used >> to be? >> >> >> >> On 29/03/17 20:54, Vincent Povirk wrote: >>> Is there a reason to switch to SHCreateMemStream to do this test in >>> particular? If not, it would probably make more sense as a separate >>> cleanup project. >>> >>> On Mon, Mar 27, 2017 at 3:09 PM, Viktor Semykin <thesame.ml(a)gmail.com> >>> wrote: >>>> Signed-off-by: Viktor Semykin <thesame.ml(a)gmail.com> >>>> --- >>>> dlls/windowscodecs/tests/Makefile.in | 2 +- >>>> dlls/windowscodecs/tests/pngformat.c | 19 ++++++++++--------- >>>> 2 files changed, 11 insertions(+), 10 deletions(-) >>>> >>>> diff --git a/dlls/windowscodecs/tests/Makefile.in >>>> b/dlls/windowscodecs/tests/Makefile.in >>>> index e11d184..e006e3d 100644 >>>> --- a/dlls/windowscodecs/tests/Makefile.in >>>> +++ b/dlls/windowscodecs/tests/Makefile.in >>>> @@ -1,5 +1,5 @@ >>>> TESTDLL = windowscodecs.dll >>>> -IMPORTS = windowscodecs oleaut32 ole32 user32 gdi32 >>>> +IMPORTS = windowscodecs oleaut32 ole32 user32 gdi32 shlwapi >>>> >>>> C_SRCS = \ >>>> bitmap.c \ >>>> diff --git a/dlls/windowscodecs/tests/pngformat.c >>>> b/dlls/windowscodecs/tests/pngformat.c >>>> index 34cb533..20b6e93 100644 >>>> --- a/dlls/windowscodecs/tests/pngformat.c >>>> +++ b/dlls/windowscodecs/tests/pngformat.c >>>> @@ -25,6 +25,7 @@ >>>> #include "windef.h" >>>> #include "wincodec.h" >>>> #include "wine/test.h" >>>> +#include "shlwapi.h" >>>> >>>> /* 1x1 pixel PNG image */ >>>> static const char png_no_color_profile[] = { >>>> @@ -277,21 +278,16 @@ static IWICImagingFactory *factory; >>>> >>>> static IWICBitmapDecoder *create_decoder(const void *image_data, UINT >>>> image_size) >>>> { >>>> - HGLOBAL hmem; >>>> - BYTE *data; >>>> HRESULT hr; >>>> IWICBitmapDecoder *decoder = NULL; >>>> IStream *stream; >>>> GUID format; >>>> LONG refcount; >>>> + ULARGE_INTEGER pos; >>>> + LARGE_INTEGER zero; >>>> >>>> - hmem = GlobalAlloc(0, image_size); >>>> - data = GlobalLock(hmem); >>>> - memcpy(data, image_data, image_size); >>>> - GlobalUnlock(hmem); >>>> - >>>> - hr = CreateStreamOnHGlobal(hmem, TRUE, &stream); >>>> - ok(hr == S_OK, "CreateStreamOnHGlobal error %#x\n", hr); >>>> + stream = SHCreateMemStream (image_data, image_size); >>>> + ok(stream != NULL, "SHCreateMemStream error\n"); >>>> >>>> hr = IWICImagingFactory_CreateDecoderFromStream(factory, stream, >>>> NULL, 0, &decoder); >>>> ok(hr == S_OK, "CreateDecoderFromStream error %#x\n", hr); >>>> @@ -302,6 +298,11 @@ static IWICBitmapDecoder *create_decoder(const void >>>> *image_data, UINT image_size >>>> ok(IsEqualGUID(&format, &GUID_ContainerFormatPng), >>>> "wrong container format %s\n", wine_dbgstr_guid(&format)); >>>> >>>> + zero.QuadPart = 0; >>>> + IStream_Seek (stream, zero, STREAM_SEEK_CUR, &pos); >>>> + todo_wine ok(pos.QuadPart < image_size, "seek beyond the end of >>>> stream: %lu >= %u\n", >>>> + pos.QuadPart, image_size); >>>> + >>>> refcount = IStream_Release(stream); >>>> ok(refcount > 0, "expected stream refcount > 0\n"); >>>> >>>> -- >>>> 2.12.1 >>>> >>>> >>>> >> -- >> best, Viktor. >> -- best, Viktor.

March 30, 2017

Re: d3d10: sync spec file to Windows 10

by Henri Verbeet

On 30 March 2017 at 18:06, Austin English <austinenglish(a)gmail.com> wrote: > On Thu, Mar 30, 2017 at 7:25 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> On 29 March 2017 at 23:51, Austin English <austinenglish(a)gmail.com> wrote: >>> -- >> We may not necessarily care, but RevertToOldImplementation() is the >> first export instead of the last on my Windows 10. > > My reasoning was that for non-ordinals, it doesn't matter, and that > sorting was preferred. > Good enough for me.

March 30, 2017

Re: d3d10: sync spec file to Windows 10

by Austin English

On Thu, Mar 30, 2017 at 7:25 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 29 March 2017 at 23:51, Austin English <austinenglish(a)gmail.com> wrote: >> -- > We may not necessarily care, but RevertToOldImplementation() is the > first export instead of the last on my Windows 10. My reasoning was that for non-ordinals, it doesn't matter, and that sorting was preferred. -- -Austin GPG: 14FB D7EA A041 937B

March 30, 2017

COM tracing ...

by Michael Meeks

Hi guys, Rather a peripheral question; apologies for that - but I'd imagine there are experts here that may be able to help. I have a black-box problem - a Windows app dealing with confidential data that I can't easily touch (and thus can't get to run under Wine) - which does some small but critical automation of MS Office - using VBS / COM scripting. I'd -really- love some input on how best to trace that series of COM method calls on Windows itself ie. the (remote) service activation, and the RPC beyond that - particularly the method names, parameters etc. of the COM/OLE Office API. I've tried (so far): http://www.rohitab.com/apimonitor which, while closed, looks interesting; but traces a lot in a hard-to-search way and doesn't appear to do the trick. https://support.microsoft.com/en-us/help/926098/how-to-enable-com-and-com-d… Sounds useful: using Event Tracing for Windows (ETW) but has this rather unhelpful property: "The binary file must be formatted by Microsoft so that it can be analyzed. Please forward the .etl files to your support contact. ..." ;-) Component models used to be all the rage in my youth ;-) surely someone solved the "strace for COM calls" problem elegantly some-when ! Crazily - might it be possible to instrument, interpose and use Wine's COM impl. on Windows [ which sounds a bit 'exciting' ;-], or ? Anyhow - help much appreciated & sorry for the noise ! Regards, Michael. -- michael.meeks(a)collabora.com <><, Pseudo Engineer, itinerant idiot

March 30, 2017

Re: [PATCH 3/3] shlwapi/tests: A test to query ISequentialStream from memory stream

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://testbot.winehq.org/JobDetails.pl?Key=29831 Your paranoid android. === wxppro (32 bit istream) === istream.c:44: Test failed: got 0x80004002 istream.c:45: Test failed: unexpected interface pointer 09f0:istream: unhandled exception c0000005 at 00405AEC === w2003std (32 bit istream) === istream.c:44: Test failed: got 0x80004002 istream.c:45: Test failed: unexpected interface pointer 05f0:istream: unhandled exception c0000005 at 00405AEC

March 30, 2017

Re: [PATCH 2/3] shlwapi: Fix QueryInterface for file-based streams

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://testbot.winehq.org/JobDetails.pl?Key=29830 Your paranoid android. === wxppro (32 bit istream) === istream.c:44: Test failed: got 0x80004002 istream.c:45: Test failed: unexpected interface pointer 09ec:istream: unhandled exception c0000005 at 00405AEC === w2003std (32 bit istream) === istream.c:44: Test failed: got 0x80004002 istream.c:45: Test failed: unexpected interface pointer 05f0:istream: unhandled exception c0000005 at 00405AEC

March 30, 2017

Re: [PATCH] wmvcore: Add WMReader stubs.

by Andrew Eikum

On Thu, Mar 30, 2017 at 08:25:03AM +0000, Alistair Leslie-Hughes wrote: > I have a basic patch for adding tests in the works, but I was waiting > for my IDL changes to be accepted first. > > So, If someone wants to review the IDL changes, Since Sebastian has been > busy with other stuff. > > https://source.winehq.org/patches/data/131403 > Okay :) I just noticed one thing: > + HRESULT GetAttributeCountEx( > + [in] WORD stream_num, > + [out] WORD attributes ); If attributes is an out-param, it should be a pointer, right? Andrew

March 30, 2017

Re: d3d10: sync spec file to Windows 10

by Henri Verbeet

On 29 March 2017 at 23:51, Austin English <austinenglish(a)gmail.com> wrote: > -- We may not necessarily care, but RevertToOldImplementation() is the first export instead of the last on my Windows 10.

March 30, 2017

Re: wine-2.0.1-rc1 Available

by Michael Stefaniuc

Hi, On 2017-03-30 03:10, NP-Hardass wrote: > I'd like to request that the final tarballs be made available with xz > compression. Releases for 2.x are all xz, but 2.0 was released with > bz2 > compression. 2.0.x will be xz. I have just forgotten to update the download links as Alexandre and I had that discussion a long time ago. Thanks for noticing it. bye michael

March 30, 2017

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Stas Sergeev

30.03.2017 08:14, Ricardo Neri пишет: >>>> But at least dosemu implements it, so probably it is needed. >>> Right. >>> >>>> Of course if it is used by one of 100 DOS progs, then there >>>> is an option to just add its support to dosemu2 and pretend >>>> the compatibility problems did not exist. :) >>> Do you mean relaying the GP fault to dosemu instead of trapping it and >>> emulating it in the kernel? >> Yes, that would be optimal if this does not severely break >> the current setups. If we can find out that smsw is not in >> the real use, we can probably do exactly that. >> But other >> instructions are not in real use in v86 for sure, so I >> wouldn't be adding the explicit test-cases to the kernel >> that will make you depend on some particular behaviour >> that no one may need. >> My objection was that we shouldn't >> write tests before we know exactly how we want this to work. > OK, if only SMSW is used then I'll keep the emulation for SMSW only. In fact, smsw has an interesting property, which is that no one will ever want to disable its in-kernel emulation to provide its own. So while I'll try to estimate its usage, emulating it in kernel will not be that problematic in either case. As for protected mode, if wine only needs sgdt/sidt, then again, no one will want to disable its emulation. Not the case with sldt, but AFAICS wine doesn't need sldt, and so we can leave sldt without a fixups. Is my understanding correct? In this case, I suppose, we are very well on a way to avoid the extra syscalls to toggle the emulation features.

March 30, 2017

Re: [PATCH] wmvcore: Add WMReader stubs.

by Alistair Leslie-Hughes

Hi Jefferson, On 30/03/17 10:18, Jefferson Carpenter wrote: > > I have not written unit tests for this code. I would like to add some > wmvcore tests, but am not very familiar with Wine's build system > autotools, and have not been able to get tests to compile and run. > I have a basic patch for adding tests in the works, but I was waiting for my IDL changes to be accepted first. So, If someone wants to review the IDL changes, Since Sebastian has been busy with other stuff. https://source.winehq.org/patches/data/131403 > > Signed-off-by: Jefferson Carpenter > --- > dlls/wmvcore/wmvcore_main.c | 1234 +++++++++++++++++++++++++++++++++++++++++++ > +static HRESULT WINAPI WMHeaderInfo_GetScriptCount(IWMHeaderInfo3 *iface, WORD *pcScripts) > +{ > + WMReader *This = impl_from_IWMHeaderInfo3(iface); > + FIXME("(%p)->(WMHeaderInfo_GetScriptCount)\n", This); This is incorrect. The FIXME will insert the function name into the logs. You need to specify each parameter in the FIXME, there are plenty of examples of how to do this. Best Regards Alistair Leslie-Hughes

March 30, 2017

Re: [PATCH] wmvcore: Add WMReader stubs.

by Alistair Leslie-Hughes

Hi Jefferson, On 30/03/17 10:18, Jefferson Carpenter wrote: > > I have not written unit tests for this code. I would like to add some > wmvcore tests, but am not very familiar with Wine's build system > autotools, and have not been able to get tests to compile and run. > I have a basic patch for adding tests in the works, but I was waiting for my IDL changes to be accepted first. So, If someone wants to review the IDL changes, Since Sebastian has been busy with other stuff. https://source.winehq.org/patches/data/131403 > > Signed-off-by: Jefferson Carpenter > --- > dlls/wmvcore/wmvcore_main.c | 1234 +++++++++++++++++++++++++++++++++++++++++++ > +static HRESULT WINAPI WMHeaderInfo_GetScriptCount(IWMHeaderInfo3 *iface, WORD *pcScripts) > +{ > + WMReader *This = impl_from_IWMHeaderInfo3(iface); > + FIXME("(%p)->(WMHeaderInfo_GetScriptCount)\n", This); This is incorrect. The FIXME will insert the function name into the logs. You need to specify each parameter in the FIXME, there are plenty of examples of how to do this. Best Regards Alistair Leslie-Hughes

March 30, 2017

Re: dpnaddr: sync spec file to Windows 10

by Alistair Leslie-Hughes

On 30/03/17 08:51, Austin English wrote: > > > You appear to be comparing the stub version of this DLL. (It would be about 8k in size, the real version is larger). Same goes for dpnlobby. Best Regards Alistair Leslie-Hughes

March 30, 2017

Re: [2/3] windowscodecs: Test for png codec seeking too far

by Vincent Povirk

I think you should either split the patch, or leave it using HGLOBAL. On Wed, Mar 29, 2017 at 11:12 PM, Viktor Semykin <thesame.ml(a)gmail.com> wrote: > No, there's no such a reason. This test would pass with HGLOBAL as well. > What should I do in this situation? Would it better to leave it as it used > to be? > > > > On 29/03/17 20:54, Vincent Povirk wrote: >> >> Is there a reason to switch to SHCreateMemStream to do this test in >> particular? If not, it would probably make more sense as a separate >> cleanup project. >> >> On Mon, Mar 27, 2017 at 3:09 PM, Viktor Semykin <thesame.ml(a)gmail.com> >> wrote: >>> >>> Signed-off-by: Viktor Semykin <thesame.ml(a)gmail.com> >>> --- >>> dlls/windowscodecs/tests/Makefile.in | 2 +- >>> dlls/windowscodecs/tests/pngformat.c | 19 ++++++++++--------- >>> 2 files changed, 11 insertions(+), 10 deletions(-) >>> >>> diff --git a/dlls/windowscodecs/tests/Makefile.in >>> b/dlls/windowscodecs/tests/Makefile.in >>> index e11d184..e006e3d 100644 >>> --- a/dlls/windowscodecs/tests/Makefile.in >>> +++ b/dlls/windowscodecs/tests/Makefile.in >>> @@ -1,5 +1,5 @@ >>> TESTDLL = windowscodecs.dll >>> -IMPORTS = windowscodecs oleaut32 ole32 user32 gdi32 >>> +IMPORTS = windowscodecs oleaut32 ole32 user32 gdi32 shlwapi >>> >>> C_SRCS = \ >>> bitmap.c \ >>> diff --git a/dlls/windowscodecs/tests/pngformat.c >>> b/dlls/windowscodecs/tests/pngformat.c >>> index 34cb533..20b6e93 100644 >>> --- a/dlls/windowscodecs/tests/pngformat.c >>> +++ b/dlls/windowscodecs/tests/pngformat.c >>> @@ -25,6 +25,7 @@ >>> #include "windef.h" >>> #include "wincodec.h" >>> #include "wine/test.h" >>> +#include "shlwapi.h" >>> >>> /* 1x1 pixel PNG image */ >>> static const char png_no_color_profile[] = { >>> @@ -277,21 +278,16 @@ static IWICImagingFactory *factory; >>> >>> static IWICBitmapDecoder *create_decoder(const void *image_data, UINT >>> image_size) >>> { >>> - HGLOBAL hmem; >>> - BYTE *data; >>> HRESULT hr; >>> IWICBitmapDecoder *decoder = NULL; >>> IStream *stream; >>> GUID format; >>> LONG refcount; >>> + ULARGE_INTEGER pos; >>> + LARGE_INTEGER zero; >>> >>> - hmem = GlobalAlloc(0, image_size); >>> - data = GlobalLock(hmem); >>> - memcpy(data, image_data, image_size); >>> - GlobalUnlock(hmem); >>> - >>> - hr = CreateStreamOnHGlobal(hmem, TRUE, &stream); >>> - ok(hr == S_OK, "CreateStreamOnHGlobal error %#x\n", hr); >>> + stream = SHCreateMemStream (image_data, image_size); >>> + ok(stream != NULL, "SHCreateMemStream error\n"); >>> >>> hr = IWICImagingFactory_CreateDecoderFromStream(factory, stream, >>> NULL, 0, &decoder); >>> ok(hr == S_OK, "CreateDecoderFromStream error %#x\n", hr); >>> @@ -302,6 +298,11 @@ static IWICBitmapDecoder *create_decoder(const void >>> *image_data, UINT image_size >>> ok(IsEqualGUID(&format, &GUID_ContainerFormatPng), >>> "wrong container format %s\n", wine_dbgstr_guid(&format)); >>> >>> + zero.QuadPart = 0; >>> + IStream_Seek (stream, zero, STREAM_SEEK_CUR, &pos); >>> + todo_wine ok(pos.QuadPart < image_size, "seek beyond the end of >>> stream: %lu >= %u\n", >>> + pos.QuadPart, image_size); >>> + >>> refcount = IStream_Release(stream); >>> ok(refcount > 0, "expected stream refcount > 0\n"); >>> >>> -- >>> 2.12.1 >>> >>> >>> > > -- > best, Viktor. >

March 30, 2017

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Ricardo Neri

On Wed, 2017-03-29 at 23:55 +0300, Stas Sergeev wrote: > 29.03.2017 07:38, Ricardo Neri пишет: > >> Probably you could also remove > >> the sldt and str emulation for protected mode, because, > >> as I understand from this thread, wine does not > >> need those. > > I see. I would lean on keeping the emulation because I already > > implemented it :), for completeness, and because it is performed in a > > single switch. The bulk of the emulation code deals with operands. > But this is not for free. > As Andy said, you will then need a syscall and > a feature mask to be able to disable this emulation. > And AFAIK you haven't implemented that yet, so > there is something to consider. Right, I see your point. > >>>> You know the wine's > >>>> requirements now - they are very small. And > >>>> dosemu doesn't need anything at all but smsw. > >>>> And even smsw is very rare. > >>> But emulation is still needed for SMSW, right? > >> Likely so. > >> If you want, I can enable the logging of this command > >> and see if it is used by some of the DOS programs I have. > > It would be great if you could do that, if you don't mind. > OK, scheduled to the week-end. > I'll let you know. Thanks! > > >> But at least dosemu implements it, so probably it is needed. > > Right. > > > >> Of course if it is used by one of 100 DOS progs, then there > >> is an option to just add its support to dosemu2 and pretend > >> the compatibility problems did not exist. :) > > Do you mean relaying the GP fault to dosemu instead of trapping it and > > emulating it in the kernel? > Yes, that would be optimal if this does not severely break > the current setups. If we can find out that smsw is not in > the real use, we can probably do exactly that. > But other > instructions are not in real use in v86 for sure, so I > wouldn't be adding the explicit test-cases to the kernel > that will make you depend on some particular behaviour > that no one may need. > My objection was that we shouldn't > write tests before we know exactly how we want this to work. OK, if only SMSW is used then I'll keep the emulation for SMSW only.

March 30, 2017

Re: [2/3] windowscodecs: Test for png codec seeking too far

by Viktor Semykin

No, there's no such a reason. This test would pass with HGLOBAL as well. What should I do in this situation? Would it better to leave it as it used to be? On 29/03/17 20:54, Vincent Povirk wrote: > Is there a reason to switch to SHCreateMemStream to do this test in > particular? If not, it would probably make more sense as a separate > cleanup project. > > On Mon, Mar 27, 2017 at 3:09 PM, Viktor Semykin <thesame.ml(a)gmail.com> wrote: >> Signed-off-by: Viktor Semykin <thesame.ml(a)gmail.com> >> --- >> dlls/windowscodecs/tests/Makefile.in | 2 +- >> dlls/windowscodecs/tests/pngformat.c | 19 ++++++++++--------- >> 2 files changed, 11 insertions(+), 10 deletions(-) >> >> diff --git a/dlls/windowscodecs/tests/Makefile.in b/dlls/windowscodecs/tests/Makefile.in >> index e11d184..e006e3d 100644 >> --- a/dlls/windowscodecs/tests/Makefile.in >> +++ b/dlls/windowscodecs/tests/Makefile.in >> @@ -1,5 +1,5 @@ >> TESTDLL = windowscodecs.dll >> -IMPORTS = windowscodecs oleaut32 ole32 user32 gdi32 >> +IMPORTS = windowscodecs oleaut32 ole32 user32 gdi32 shlwapi >> >> C_SRCS = \ >> bitmap.c \ >> diff --git a/dlls/windowscodecs/tests/pngformat.c b/dlls/windowscodecs/tests/pngformat.c >> index 34cb533..20b6e93 100644 >> --- a/dlls/windowscodecs/tests/pngformat.c >> +++ b/dlls/windowscodecs/tests/pngformat.c >> @@ -25,6 +25,7 @@ >> #include "windef.h" >> #include "wincodec.h" >> #include "wine/test.h" >> +#include "shlwapi.h" >> >> /* 1x1 pixel PNG image */ >> static const char png_no_color_profile[] = { >> @@ -277,21 +278,16 @@ static IWICImagingFactory *factory; >> >> static IWICBitmapDecoder *create_decoder(const void *image_data, UINT image_size) >> { >> - HGLOBAL hmem; >> - BYTE *data; >> HRESULT hr; >> IWICBitmapDecoder *decoder = NULL; >> IStream *stream; >> GUID format; >> LONG refcount; >> + ULARGE_INTEGER pos; >> + LARGE_INTEGER zero; >> >> - hmem = GlobalAlloc(0, image_size); >> - data = GlobalLock(hmem); >> - memcpy(data, image_data, image_size); >> - GlobalUnlock(hmem); >> - >> - hr = CreateStreamOnHGlobal(hmem, TRUE, &stream); >> - ok(hr == S_OK, "CreateStreamOnHGlobal error %#x\n", hr); >> + stream = SHCreateMemStream (image_data, image_size); >> + ok(stream != NULL, "SHCreateMemStream error\n"); >> >> hr = IWICImagingFactory_CreateDecoderFromStream(factory, stream, NULL, 0, &decoder); >> ok(hr == S_OK, "CreateDecoderFromStream error %#x\n", hr); >> @@ -302,6 +298,11 @@ static IWICBitmapDecoder *create_decoder(const void *image_data, UINT image_size >> ok(IsEqualGUID(&format, &GUID_ContainerFormatPng), >> "wrong container format %s\n", wine_dbgstr_guid(&format)); >> >> + zero.QuadPart = 0; >> + IStream_Seek (stream, zero, STREAM_SEEK_CUR, &pos); >> + todo_wine ok(pos.QuadPart < image_size, "seek beyond the end of stream: %lu >= %u\n", >> + pos.QuadPart, image_size); >> + >> refcount = IStream_Release(stream); >> ok(refcount > 0, "expected stream refcount > 0\n"); >> >> -- >> 2.12.1 >> >> >> -- best, Viktor.

March 30, 2017

Re: wine-2.0.1-rc1 Available

by NP-Hardass

Hi Michael, I'd like to request that the final tarballs be made available with xz compression. Releases for 2.x are all xz, but 2.0 was released with bz2 compression. Thanks, NP-Hardass

March 30, 2017

Re: Darren Stevens II -- Outreachy Internship

by Austin English

On Tue, Mar 28, 2017 at 8:31 PM, Darren M. Stevens II <darren8(a)umbc.edu> wrote: > Hello, my name is Darren and I'm a computer science major at the University > of Maryland Baltimore County. I've never worked in open source software > before, but the idea of letting windows apps run for linux sounds appealing, > especially for games. > > Though it's my first time in open source, I have some experience in C. > Looking at the project list, the graphical user interface seems to be the > most interesting, but I'm also interested in the resource and dialog editor > since I'd like to get some UI experience. I've also worked in html, php, and > mysql before, so improving the AppDB website also interests me. If pressed, > I'd prefer to work with the gui and learn about what goes into making one. > > I look forward to potentially working with you all more during the summer. Hi Darren, For a start, you'll want to make sure you can download and build wine from source. Once you can do that, please send a small (but useful!) patch to Wine. Ideally it would be one related to the area of code you'd want to work in, to show us you can work with the code. I.e., if you wanted to work on a Winetest GUI, fixing a smaller problem in winetest would be a good idea. For the AppDB, what ideas do you have for it? -- -Austin GPG: 14FB D7EA A041 937B

March 30, 2017

Re: [2/3] windowscodecs: Test for png codec seeking too far

by Vincent Povirk

Is there a reason to switch to SHCreateMemStream to do this test in particular? If not, it would probably make more sense as a separate cleanup project. On Mon, Mar 27, 2017 at 3:09 PM, Viktor Semykin <thesame.ml(a)gmail.com> wrote: > Signed-off-by: Viktor Semykin <thesame.ml(a)gmail.com> > --- > dlls/windowscodecs/tests/Makefile.in | 2 +- > dlls/windowscodecs/tests/pngformat.c | 19 ++++++++++--------- > 2 files changed, 11 insertions(+), 10 deletions(-) > > diff --git a/dlls/windowscodecs/tests/Makefile.in b/dlls/windowscodecs/tests/Makefile.in > index e11d184..e006e3d 100644 > --- a/dlls/windowscodecs/tests/Makefile.in > +++ b/dlls/windowscodecs/tests/Makefile.in > @@ -1,5 +1,5 @@ > TESTDLL = windowscodecs.dll > -IMPORTS = windowscodecs oleaut32 ole32 user32 gdi32 > +IMPORTS = windowscodecs oleaut32 ole32 user32 gdi32 shlwapi > > C_SRCS = \ > bitmap.c \ > diff --git a/dlls/windowscodecs/tests/pngformat.c b/dlls/windowscodecs/tests/pngformat.c > index 34cb533..20b6e93 100644 > --- a/dlls/windowscodecs/tests/pngformat.c > +++ b/dlls/windowscodecs/tests/pngformat.c > @@ -25,6 +25,7 @@ > #include "windef.h" > #include "wincodec.h" > #include "wine/test.h" > +#include "shlwapi.h" > > /* 1x1 pixel PNG image */ > static const char png_no_color_profile[] = { > @@ -277,21 +278,16 @@ static IWICImagingFactory *factory; > > static IWICBitmapDecoder *create_decoder(const void *image_data, UINT image_size) > { > - HGLOBAL hmem; > - BYTE *data; > HRESULT hr; > IWICBitmapDecoder *decoder = NULL; > IStream *stream; > GUID format; > LONG refcount; > + ULARGE_INTEGER pos; > + LARGE_INTEGER zero; > > - hmem = GlobalAlloc(0, image_size); > - data = GlobalLock(hmem); > - memcpy(data, image_data, image_size); > - GlobalUnlock(hmem); > - > - hr = CreateStreamOnHGlobal(hmem, TRUE, &stream); > - ok(hr == S_OK, "CreateStreamOnHGlobal error %#x\n", hr); > + stream = SHCreateMemStream (image_data, image_size); > + ok(stream != NULL, "SHCreateMemStream error\n"); > > hr = IWICImagingFactory_CreateDecoderFromStream(factory, stream, NULL, 0, &decoder); > ok(hr == S_OK, "CreateDecoderFromStream error %#x\n", hr); > @@ -302,6 +298,11 @@ static IWICBitmapDecoder *create_decoder(const void *image_data, UINT image_size > ok(IsEqualGUID(&format, &GUID_ContainerFormatPng), > "wrong container format %s\n", wine_dbgstr_guid(&format)); > > + zero.QuadPart = 0; > + IStream_Seek (stream, zero, STREAM_SEEK_CUR, &pos); > + todo_wine ok(pos.QuadPart < image_size, "seek beyond the end of stream: %lu >= %u\n", > + pos.QuadPart, image_size); > + > refcount = IStream_Release(stream); > ok(refcount > 0, "expected stream refcount > 0\n"); > > -- > 2.12.1 > > >

March 29, 2017

Re: Packaging related changes

by Michael Stefaniuc

On 03/29/2017 08:42 AM, Alexandre Julliard wrote: > Michael Müller <michael(a)fds-team.de> writes: > >> Nevertheless, we believe that these changes are very >> useful and will make things much easier in the long term. > > Indeed. Thanks for your work! Thanks Michael and Sebastian! Right in time for 2.0.1 ;) bye michael

March 29, 2017

wine-2.0.1-rc1 Available

by Michael Stefaniuc

Hello guys, I have pushed wine-2.0.1-rc1 (with tag) to https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ Nothing particularly special in this release. Slow start into 2.0.x due to lack of time on my side as well as to give the more risky patches some more time to burn in. Same old, same old: one week for feedback followed by another rc if needed with the final release 3-4 days later. And now the interesting parts from the ANNOUNCE file: What's new in this release (see below for details): - Various bug fixes - Deprecated tools/wineinstall ---------------------------------------------------------------- Bugs fixed in 2.0.1 (total 47): 14897 DirectDraw games (Jojo's Fashion Show 2: Las Cruces demo, The Chosen: Well of Souls) try to lock surface with invalid dwSize 14939 Black & White: DXTC to ARGB converter not implemented 17495 Open dialog crashes if the desktop folder is at a Unicode path that cannot be represented in the current locale 18477 Need For Speed Most Wanted crashes after accepting video settings changes 19888 Venom Codename: Outbreak - initial menu screen is black (no menu items) 25700 MessageBox does not display last word if string contains '&' (ampersand) 26603 iMesh 10 crashes at startup (needs wmvcore.dll.WMCreateReaderPriv) 27580 Wine Notepad command line parser eats the first 2 letters when the path starts with / (it should only do this for valid command line options) 30308 Property sheet fails to display Page Title 35993 Graphical Glitches in Agarest Generations of War 38354 Multiple games and applications need msvcr120.dll._except1 (Audacity 2.1.0, Tera Online) 38485 New Marvel Heroes 2015 Launcher crashes on unimplemented function dhcpcsvc.dll.DhcpRequestParams 39048 MIDI Clock Messages are Corrupted Between Wine and ALSA 39920 Nanocad 5.: file open/import dialog does not open 40392 ComicRack 0.9.x (.NET 4.5 app) hangs/crashes on startup when executing WMI query 40938 UE4 games (Ether One Redux, Into the Stars) crash while loading with "BackBuffer->GetResource() has 3 refs, expected 1" error 40952 improper escaping of quotes in command line 41448 Civilization II Unhandled page fault on read access 41579 Rush for Berlin Gold crashes after the intro videos 41623 Odallus The Dark Call crashes while starting if a force feedback enabled controller is plugged in 41648 AmiBroker 6.00 fails, when run, with raise_exception Unhandled exception 41725 Unimplemented function api-ms-win-crt-math-l1-1-0.dll._except1 (Starcraft 2 main menu, Firefox) 41830 Updating group box text causes garbage 41926 Zafehouse demo crashes with Call from 0x7b43c14c to unimplemented function ddraw.dll.GetSurfaceFromDC, aborting 42001 SC2 unimplemented function ucrtbase.dll._except1 42022 The Magic School Bus Explores The Solar System needs msvideo.dll16.DRAWDIBPROFILEDISPLAY 42023 The Magic School Bus Explores The Solar System crashes on launch; appears to be missing some files 42078 Dungeons & Dragons: Chronicles of Mystara needs d3dx11_43.dll.D3DX11CreateShaderResourceViewFromMemory 42093 Git for Windows 2.7.0 needs unimplemented function rstrtmgr.dll.RmShutdown 42094 winamp needs unimplemented function ntoskrnl.exe.IoStopTimer 42096 Steam -> RPGMaker 2003 needs unimplemented function KERNEL32.dll.BaseFlushAppcompatCache 42159 Sega Bug crashes immediately 42212 WOLF RPG Editor: Division by zero when winegstreamer is enabled 42218 mshtml/tests/dom crashes in xul while running test_doc_elem 42244 QQ 2013 needs ntoskrnl.exe.IoCreateFile 42245 QQ 2013 needs ntoskrnl.exe.KeClearEvent 42257 Warpath 21st Century does not have sound 42303 Magic: The Gathering Online 4.0 crashes when entering the battle 42306 One Note Free Retail installer crashes in xmllite 42315 Piriform Speccy 1.3 needs setupapi.dll.CM_Get_Child_Ex 42361 DX Library: PlaySoundFile() doesn't play MP3 files with specific extra headers 42365 Unimplemented function msvcr120.dll.fesetenv 42367 KiriKiri Z based games: main screen doesn't update. 42469 GetOpenFileName should expand environment variables in lpstrInitialDir 42483 Build for Ubuntu Precise fails because MPG123_IGNORE_INFOFRAME is undeclared 42557 NVIDIA GeForce GT 525M detected as GeForce GTX 470 42567 Acid Pro Trial 7.0e fails to install ---------------------------------------------------------------- Changes since 2.0: Adam Bolte (1): wined3d: Add GPU information for AMD FIJI. Akihiro Sagawa (3): d3d9/tests: Add LockRect tests with dynamic textures. d3d8/tests: Add LockRect tests with dynamic textures. wined3d: Upload textures if NO_DIRTY_UPDATE flag is set when locking dynamic textures. Alex Henrie (3): ddraw: Don't crash if writing out a new ddraw1 surface segfaults. comdlg32: Don't crash if an IShellFolder could not be created. user32: Include space for ampersands when determining MessageBox size. Alexandre Julliard (1): make_announce: Update version number parsing for the new versioning scheme. Alistair Leslie-Hughes (1): include: Add dhcpcsdk.h. Andrew Wesie (1): ntdll: Read entry point in LdrInitializeThunk. Andrey Gusev (2): setupapi: Add CM_Get_Child_Ex stub. d3dx11: Add D3DX11CreateShaderResourceViewFromMemory stub. Anton Romanov (1): user32: Add OCR_RDR* cursors. Austin English (6): ntoskrnl.exe: Add IoCreateFile stub. ntoskrnl.exe: Add stub KeClearEvent. kernel32: Add BaseFlushAppcompatCache stub. rstrtmgr: Add RmShutdown stub. dhcpsvc: Add DhcpRequestParams stub. readme: Remove wineinstall. Bruno Jesus (8): winmm: Fix the ordinal number for function PlaySound. dinput: DISFFC_RESET will not release the effects. notepad: Only skip valid command options. winemp3.acm: Ignore XING headers when parsing MP3 files. winemp3.acm: Fixes compilation for older mpg123 library versions. winealsa.drv: Fix handling of system real time MIDI messages. wined3d: Recognize Geforce GT 525M. wined3d: Recognize GeForce 940M. Can Taşan (3): wine.desktop: Add Turkish translation. kernel32: Add Unicode character for Turkish lira. documentation: Update Turkish translation. Christoph Brill (1): setupapi: Stub CM_Open_DevNode_Key and CM_Get_Child. Daniel Lehman (1): msvcrt: Implement nan. Dmitry Timoshkov (4): avifil32: AVIFileGetStream should set stream to NULL in case of an error. user32: BUTTON_CalcLabelRect should use the button font. user32: Fix groupbox rectangle calculation in the button's WM_SETTEXT handler. kernel32: Replace Peb->BeingDebugged check by CheckRemoteDebuggerPresent(). Fabian Maurer (1): msvcr120: Add fesetenv stub. François Gouget (3): readme: Note that Wine may also use Mac APIs. readme: Adjust a couple of section separators. readme: Update and rewrap the French translation. Gerald Pfeifer (1): winedump: Increase buffer size and potential string length inoutput_spec_symbol. Hans Leidekker (1): wbemprox: Only include matching rows in the table row count. Henri Verbeet (5): ddraw/tests: Rewrite GetDCTest(). ddraw: Implement GetSurfaceFromDC(). ddraw: Kill stray tabs. wined3d: Allow decompression blits on system memory resources in arbfp_blit_supported(). wined3d: Disallow upload conversion from compressed formats in surface_convert_format(). Jacek Caban (1): mshtml: Initialize nsAString in IHTMLDocument3::get_dir. Jacob Lifshay (1): kernel32: Fix improper escaping of quotes in command line. Jarkko Korpi (1): ntoskrnl: Add IoStopTimer stub. Jefferson Carpenter (1): wmvcore: Implement WMCreateReaderPriv. Julian Rüger (2): readme: Update German translation. readme: Fix typo in German translation. Józef Kucia (6): d3d11/tests: Add tests showing that views do not keep resource reference. d3d11: Do not keep reference to resources. ddraw: Relax "dwSize" validation in ddraw_surface*_Lock(). ddraw: Implement D3DOP_TEXTURELOAD. ddraw/tests: Add basic test for D3DOP_TEXTURELOAD. d3d9: Do not decrease swapchain surface refcount when it is already 0. Lauri Kenttä (2): readme: Update Finnish translation. readme: Update Swedish translation. Louis Lenders (2): xmllite/reader: Handle NULL node type argument in Read(). wmvcore: Add version resource. Masanori Kakura (1): winegstreamer: Avoid zero division in amt_from_gst_caps_video(). Matteo Bruni (1): d3d9: Fix DrawIndexedPrimitiveUP with non-zero min_vertex_idx. Michael Müller (2): msvideo.dll16: Implement DrawDibProfileDisplay. msvideo.dll16: Check if any 16 bit thunks have been allocated before accessing pointer. Michael Stefaniuc (1): tools: Get the ANNOUNCE bug list from the stable-notes git notes. Nikolay Sivov (5): comdlg32: Always use original Open File dialog template. comctl32/propsheet: Force wizard header if any of pages has title/subtitle. comctl32/propsheet: Only use header bitmap when asked for it. comdlg32: Expand initial directory path for file open dialog. readme: Update Russian translation. Piotr Caban (2): msvcrt: Add fesetenv implementation. msvcr120: Add _except1 implementation. Zebediah Figura (7): storage.dll16: Fix bad type in IStorage16_fnOpenStorage. winebuild: Use unsigned int in spec file variable parameters. compobj: Implement several IIDs. ole2: Implement several IIDs. avifile: Implement several IIDs. ole2disp: Implement several IIDs. typelib: Implement several IIDs. -- Michael Stefaniuc mstefani(a)winehq.org

March 29, 2017

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Stas Sergeev

29.03.2017 07:38, Ricardo Neri пишет: >> Probably you could also remove >> the sldt and str emulation for protected mode, because, >> as I understand from this thread, wine does not >> need those. > I see. I would lean on keeping the emulation because I already > implemented it :), for completeness, and because it is performed in a > single switch. The bulk of the emulation code deals with operands. But this is not for free. As Andy said, you will then need a syscall and a feature mask to be able to disable this emulation. And AFAIK you haven't implemented that yet, so there is something to consider. >>>> You know the wine's >>>> requirements now - they are very small. And >>>> dosemu doesn't need anything at all but smsw. >>>> And even smsw is very rare. >>> But emulation is still needed for SMSW, right? >> Likely so. >> If you want, I can enable the logging of this command >> and see if it is used by some of the DOS programs I have. > It would be great if you could do that, if you don't mind. OK, scheduled to the week-end. I'll let you know. >> But at least dosemu implements it, so probably it is needed. > Right. > >> Of course if it is used by one of 100 DOS progs, then there >> is an option to just add its support to dosemu2 and pretend >> the compatibility problems did not exist. :) > Do you mean relaying the GP fault to dosemu instead of trapping it and > emulating it in the kernel? Yes, that would be optimal if this does not severely break the current setups. If we can find out that smsw is not in the real use, we can probably do exactly that. But other instructions are not in real use in v86 for sure, so I wouldn't be adding the explicit test-cases to the kernel that will make you depend on some particular behaviour that no one may need. My objection was that we shouldn't write tests before we know exactly how we want this to work.

March 29, 2017

Re: Packaging related changes

by Michael Müller

Am 29.03.2017 um 01:48 schrieb Rosanne DiMesio: > I'm running into the CDN sync issue; http://dl.winehq.org/wine-builds/ doesn't show a directory for Ubuntu, but http://dl.winehq.org/wine-builds/ubuntu does exist. This shouldn't cause any problem for now except when manually clicking through the file listing. There are also a few other paths that will change with the next release, but I think it is sufficient when Jeremy updates the configuration afterwards. > We should also post a notice on the forum. I can take care of that. This is a good idea. > Fedora 22 is also EOL. You are right, I forgot to include it in the list. Regards, Michael

March 29, 2017

Re: [v2 1/2] d3dx9: Support relative addressing in preshader.

by Paul Gofman

Sorry, regarding my 1st question, I realized that of course first write make sense, as the size will be updated through output register. But still I would suggest to keep the currently implemented scheme to better much native approach (which is tolerant to missing constants definition). On 03/29/2017 09:23 PM, Paul Gofman wrote: > On 03/29/2017 09:17 PM, Matteo Bruni wrote: >> I haven't looked at the v3 patches yet, but in the meantime: >> >> 2017-03-29 2:09 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: >> >>> Oh, its a bug actually now, we should not mind absolute offset >>> here if >>> relative addressing is on, we know if it is out of bound or not when >>> we add >>> index register value only, which can be negative. Yes, it looks the >>> only >>> tables where we need to do this update table size are temporary >>> register >>> table (for which we don't have any size known in advance) and output >>> tables. >>> I would check that and if I am not missing something now would leave >>> just >>> update table size where required. >> Yeah and temporaries are supposed to be written before being read so >> in theory you can entirely skip the update_table_size() calls for >> source arguments. > But update_table_sizes is required to calculate memory allocation > size for table, what is the difference if temporary registers are > written first in this regard? In v3 I u sed correct offset for > updating table sizes when relative addressing is used in operand. I > didn't change table size update though to update temporary register > table size only, as doing so currently breaks one test. It is > test_effect_preshader_op(), which writes instructions to the effect > blob and unintentionally corrupts the data past end of the preshader > code being updated. This effectively results in destroying 'CTAB' for > the next preshader in blob, so that preshader is parsed ok but it does > not have input constant definition anymore, thus no table sizes set > from input registers definition. Still such an effect and preshader is > created ok by native implementation, and also by our current > implementation. So So I thought it is better to keep the current logic > of table size updates based on actual register access in preshader for > all tables, as according to the test native implementation does not > fail preshader creation if it access the constants outside defined > input range.

March 29, 2017

Re: [v2 1/2] d3dx9: Support relative addressing in preshader.

by Paul Gofman

On 03/29/2017 09:17 PM, Matteo Bruni wrote: > I haven't looked at the v3 patches yet, but in the meantime: > > 2017-03-29 2:09 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > >> Oh, its a bug actually now, we should not mind absolute offset here if >> relative addressing is on, we know if it is out of bound or not when we add >> index register value only, which can be negative. Yes, it looks the only >> tables where we need to do this update table size are temporary register >> table (for which we don't have any size known in advance) and output tables. >> I would check that and if I am not missing something now would leave just >> update table size where required. > Yeah and temporaries are supposed to be written before being read so > in theory you can entirely skip the update_table_size() calls for > source arguments. But update_table_sizes is required to calculate memory allocation size for table, what is the difference if temporary registers are written first in this regard? In v3 I u sed correct offset for updating table sizes when relative addressing is used in operand. I didn't change table size update though to update temporary register table size only, as doing so currently breaks one test. It is test_effect_preshader_op(), which writes instructions to the effect blob and unintentionally corrupts the data past end of the preshader code being updated. This effectively results in destroying 'CTAB' for the next preshader in blob, so that preshader is parsed ok but it does not have input constant definition anymore, thus no table sizes set from input registers definition. Still such an effect and preshader is created ok by native implementation, and also by our current implementation. So So I thought it is better to keep the current logic of table size updates based on actual register access in preshader for all tables, as according to the test native implementation does not fail preshader creation if it access the constants outside defined input range.

March 29, 2017

Re: [PATCH 10/10] xmllite/tests: Added tests for returned string pointers.

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://testbot.winehq.org/JobDetails.pl?Key=29805 Your paranoid android. === wxppro (32 bit reader) === reader.c:2517: Test failed: ns != value reader.c:2549: Test failed: xmlns_name != prefix reader.c:2555: Test failed: xmlns_name != prefix reader.c:2560: Test failed: p != prefix reader.c:2561: Test failed: empty != namespace reader.c:2566: Test failed: q != prefix reader.c:2567: Test failed: nsq != namespace reader.c:2570: Test failed: q == qname reader.c:2597: Test failed: ns+1 != p === w2003std (32 bit reader) === reader.c:2517: Test failed: ns != value reader.c:2549: Test failed: xmlns_name != prefix reader.c:2555: Test failed: xmlns_name != prefix reader.c:2560: Test failed: p != prefix reader.c:2561: Test failed: empty != namespace reader.c:2566: Test failed: q != prefix reader.c:2567: Test failed: nsq != namespace reader.c:2570: Test failed: q == qname reader.c:2597: Test failed: ns+1 != p

March 29, 2017

Re: [v2 1/2] d3dx9: Support relative addressing in preshader.

by Matteo Bruni

I haven't looked at the v3 patches yet, but in the meantime: 2017-03-29 2:09 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Oh, its a bug actually now, we should not mind absolute offset here if > relative addressing is on, we know if it is out of bound or not when we add > index register value only, which can be negative. Yes, it looks the only > tables where we need to do this update table size are temporary register > table (for which we don't have any size known in advance) and output tables. > I would check that and if I am not missing something now would leave just > update table size where required. Yeah and temporaries are supposed to be written before being read so in theory you can entirely skip the update_table_size() calls for source arguments. > Otherwise, if to leave the way it is done now, if relative addressing is > used update_table_size should be called on index register table/offset > instead of main register. > Regarding absolute offset check, if the absolute offset (without > relative addressing) is out of bound fxc does not allow to compile that. If > to test what happens to native implementation in this case I need to update > the blob manually. So do you suggest to check if the absolute offset to > input table is in bound and print a FIXME/fail preshader creation in this > case? Failing with a WARN is probably the best option. I don't think we necessarily need a Wine test for that, once you tested what happens with native. If you want you can add a test with a small effect manually hacked to contain an invalid argument. > Immediate const count is not necessarily the multiple of 4 (it is not the > case in the present tests). If we set PRES_REGTAB_IMMED count to 4 it breaks > new out of bounds index tests (due to incorrect size to wrap to). Hmm, I've never seen any effect with a number of immediates not multiple of 4. Can you point me to one?

March 29, 2017

Re: [PATCH 3/9] xmllite: Merge reader_lookup_ns and reader_lookup_nsdef implementations.

by Jacek Caban

On 28.03.2017 22:20, Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > >> Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> >> --- >> dlls/xmllite/reader.c | 53 >> +++++++++++++++++++++------------------------------ >> 1 file changed, 22 insertions(+), 31 deletions(-) > This fails here: It needs more work, sorry about that. I will send more tests first. Jacek

March 29, 2017

Re: [PATCH 5/5] user32: Store the item rects as relative to the items_rect.

by Huw Davies

On Tue, Mar 28, 2017 at 10:16:46PM +0200, Alexandre Julliard wrote: > Huw Davies <huw(a)codeweavers.com> writes: > > > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > > --- > > dlls/user32/menu.c | 68 ++++++++++++++++++++++++++---------------------------- > > 1 file changed, 33 insertions(+), 35 deletions(-) > > This fails here: > > ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so win && touch win.ok > win.c:1104: Test failed: window rect does not match: style:exstyle=0x94000000:0x00000000, menu=1, win=(110,100)-(335,300), calc=(110,99)-(335,300) Sorry about that. That'll teach me to: i. Run the entire set of tests. ii. Not to remove mysterious '+1's without more testing (see i.). Huw.

March 29, 2017

Re: Packaging related changes

by Alexandre Julliard

Michael Müller <michael(a)fds-team.de> writes: > Nevertheless, we believe that these changes are very > useful and will make things much easier in the long term. Indeed. Thanks for your work! -- Alexandre Julliard julliard(a)winehq.org

March 29, 2017

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Ricardo Neri

On Tue, 2017-03-28 at 12:38 +0300, Stas Sergeev wrote: > 28.03.2017 02:46, Ricardo Neri пишет: > > On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote: > >> 11.03.2017 02:59, Ricardo Neri пишет: > >>> On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: > >>> > >>>> Why would you need one? > >>>> Or do you really want to allow these instructions > >>>> in v86 by the means of emulation? If so - this wasn't > >>>> clearly stated in the patch description, neither it was > >>>> properly discussed, it seems. > >>> It str and sldt can be emulated in vm86 but as Andy mention, the > >>> behavior sould be the same with and without emulation. > >> Why would you do that? > >> I looked up the dosemu2 CPU simulator code that > >> is used under x86-64. It says this: > > Stas, I apologize for the delayed reply; I missed your e-mail. > >> It only implements smsw. > >> So maybe you can make your code much > >> simpler and remove the unneeded emulation? > >> Same is for prot mode. > > Do you mean the unneeded emulation for SLDT and STR? > Not quite, I meant also sgdt and sidt in vm86. > Yes that it will be a somewhat "incompatible" change, > but if there is nothing to stay compatible with, > then why to worry? My idea of compatibility was to have the emulation code behave exactly as a processor without UMIP :) > Probably you could also remove > the sldt and str emulation for protected mode, because, > as I understand from this thread, wine does not > need those. I see. I would lean on keeping the emulation because I already implemented it :), for completeness, and because it is performed in a single switch. The bulk of the emulation code deals with operands. > > Note that these days dosemu2 uses v86 mode set > up under kvm rather than vm86(). Your patches > affect that the same way as they do for vm86() > syscall, or can there be some differences? My code does not touch kvm at all. I would need to assess how kvm will behave. > Or should > the UMIP be enabled under kvm by hands? There was an attempt to emulate UMIP that was submitted a while ago: https://lkml.org/lkml/2016/7/12/644 > > >> You know the wine's > >> requirements now - they are very small. And > >> dosemu doesn't need anything at all but smsw. > >> And even smsw is very rare. > > But emulation is still needed for SMSW, right? > Likely so. > If you want, I can enable the logging of this command > and see if it is used by some of the DOS programs I have. It would be great if you could do that, if you don't mind. > But at least dosemu implements it, so probably it is needed. Right. > Of course if it is used by one of 100 DOS progs, then there > is an option to just add its support to dosemu2 and pretend > the compatibility problems did not exist. :) Do you mean relaying the GP fault to dosemu instead of trapping it and emulating it in the kernel? Thanks and BR, Ricardo

March 29, 2017

Re: Packaging related changes

by Aaryaman Vasishta

Awesome! On Wed, Mar 29, 2017 at 7:05 AM, Michael Müller <michael(a)fds-team.de> wrote: > > As you can see there are plenty of changes, and there are even more > developer related changes ahead. Although we would like to avoid any > inconvenience, there is some manual work involved for some of our users. > Ubuntu users will have to switch to the WineHQ repository, and > repos.wine-staging.com users will have to update repository paths for > all distributions. Nevertheless, we believe that these changes are very > useful and will make things much easier in the long term. > > Agreed. If the pros overshadow the cons, no reason not to go for it. In the long run, I think it'll be more useful, and as you mentioned, scalable too. Cheers, Aaryaman

March 29, 2017

Darren Stevens II -- Outreachy Internship

by Darren M. Stevens II

Hello, my name is Darren and I'm a computer science major at the University of Maryland Baltimore County. I've never worked in open source software before, but the idea of letting windows apps run for linux sounds appealing, especially for games. Though it's my first time in open source, I have some experience in C. Looking at the project list, the graphical user interface seems to be the most interesting, but I'm also interested in the resource and dialog editor since I'd like to get some UI experience. I've also worked in html, php, and mysql before, so improving the AppDB website also interests me. If pressed, I'd prefer to work with the gui and learn about what goes into making one. I look forward to potentially working with you all more during the summer. Thank you for your time, -- --------------------------------------------- Darren Stevens II Meyerhoff Scholar [M25] Computer Science (Game Design Track) Major University of Maryland Baltimore County (UMBC)

March 29, 2017

Re: [v2 1/2] d3dx9: Support relative addressing in preshader.

by Paul Gofman

On 03/29/2017 02:37 AM, Matteo Bruni wrote: > 2017-03-24 23:12 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > >> @@ -697,13 +739,13 @@ static HRESULT parse_preshader(struct d3dx_preshader *pres, unsigned int *ptr, u >> for (i = 0; i < pres->ins_count; ++i) >> { >> for (j = 0; j < pres_op_info[pres->ins[i].op].input_count; ++j) >> - update_table_size(pres->regs.table_sizes, pres->ins[i].inputs[j].table, >> - get_reg_offset(pres->ins[i].inputs[j].table, >> - pres->ins[i].inputs[j].offset + pres->ins[i].component_count - 1)); >> + update_table_size(pres->regs.table_sizes, pres->ins[i].inputs[j].reg.table, >> + get_reg_offset(pres->ins[i].inputs[j].reg.table, >> + pres->ins[i].inputs[j].reg.offset + pres->ins[i].component_count - 1)); >> >> - update_table_size(pres->regs.table_sizes, pres->ins[i].output.table, >> - get_reg_offset(pres->ins[i].output.table, >> - pres->ins[i].output.offset + pres->ins[i].component_count - 1)); >> + update_table_size(pres->regs.table_sizes, pres->ins[i].output.reg.table, >> + get_reg_offset(pres->ins[i].output.reg.table, >> + pres->ins[i].output.reg.offset + pres->ins[i].component_count - 1)); > Do these update_table_size() always do the right thing with relative addressing? > If I'm not mistaken, they should be fine because we only accept > relative addressing for CONST and IMMED and the former is taken care > by update_table_sizes_consts() just below while the latter's size is > set statically just above this chunk. I think that means though that > we don't need to call update_table_size() on the input arguments. > If that sounds right to you, you could drop that "for(j)" altogether > or, probably better, replace the update_table_size() with a check that > the argument is not out of bounds (probably returning failure if the > check doesn't pass). That should be a separate patch. > Oh, its a bug actually now, we should not mind absolute offset here if relative addressing is on, we know if it is out of bound or not when we add index register value only, which can be negative. Yes, it looks the only tables where we need to do this update table size are temporary register table (for which we don't have any size known in advance) and output tables. I would check that and if I am not missing something now would leave just update table size where required. Otherwise, if to leave the way it is done now, if relative addressing is used update_table_size should be called on index register table/offset instead of main register. Regarding absolute offset check, if the absolute offset (without relative addressing) is out of bound fxc does not allow to compile that. If to test what happens to native implementation in this case I need to update the blob manually. So do you suggest to check if the absolute offset to input table is in bound and print a FIXME/fail preshader creation in this case? >> @@ -1088,18 +1130,65 @@ static HRESULT init_set_constants(struct d3dx_const_tab *const_tab, ID3DXConstan >> return ret; >> } >> >> +static double exec_get_reg_value(struct d3dx_regstore *rs, enum pres_reg_tables table, unsigned int offset) >> +{ >> + if (!regstore_is_val_set_reg(rs, table, offset / table_info[table].reg_component_count)) >> + WARN("Using uninitialized input, table %u, offset %u.\n", table, offset); >> + >> + return regstore_get_double(rs, table, offset); >> +} >> + >> static double exec_get_arg(struct d3dx_regstore *rs, const struct d3dx_pres_operand *opr, unsigned int comp) >> { >> - if (!regstore_is_val_set_reg(rs, opr->table, (opr->offset + comp) / table_info[opr->table].reg_component_count)) >> - WARN("Using uninitialized input, table %u, offset %u.\n", opr->table, opr->offset + comp); >> + unsigned int offset, base_index, reg_index, table; >> + >> + table = opr->reg.table; >> + >> + if (opr->index_reg.table == PRES_REGTAB_COUNT) >> + base_index = 0; >> + else >> + base_index = lrint(exec_get_reg_value(rs, opr->index_reg.table, opr->index_reg.offset)); >> + >> + /* '4' is used instead of reg_component_count, as immediate constants (which have >> + * reg_component_count of 1) are still indexed as 4 values according to the tests. >> + */ >> + offset = base_index * 4 + opr->reg.offset + comp; > Actually, is there any reason why reg_component_count for > PRES_REGTAB_IMMED isn't 4? Maybe change it to 4 and in > parse_preshader() check that const_count is a multiple of 4 (which is > something we're depending on anyway). That would be a separate patch > too. > > Clue me if I'm missing anything. Immediate const count is not necessarily the multiple of 4 (it is not the case in the present tests). If we set PRES_REGTAB_IMMED count to 4 it breaks new out of bounds index tests (due to incorrect size to wrap to). Besides, immediate constants do not treated as 4-value registers anywhere else in preshader code, other than for relative addressing. fxc compiler can "pack" constants one after another for there "normal" usage (as it was in all our previous tests). So I don't see why we would change reg_component_count to 4 for them. But when indexing immed constants all the cases I could construct so far index them as 4-value packs, even if they are used to index vec3 and just 3 values are used from there. I think it is unlikely could be done some other way (if they are already undexed in 4-packs in this case), as otherwise each use of index to immediate constant would require its own aligment of those constants. > >> + reg_index = offset / table_info[table].reg_component_count; >> + >> + if (reg_index >= rs->table_sizes[table]) >> + { >> + unsigned int wrap_size; >> + >> + if (table == PRES_REGTAB_CONST) >> + { >> + /* As it can be guessed from tests (by iterating base register value and >> + * observing the period of result values repeat), offset into floating >> + * constant table are wrapped to the nearest power of 2 and not to the >> + * actual table size. >> + */ >> + for (wrap_size = 1; wrap_size < rs->table_sizes[table]; wrap_size <<= 1) >> + ; > Please close the comment on the last text line (i.e. "*/" shouldn't be > on its own line) and maybe remove the part in parentheses which is > pretty obvious. I like the comment otherwise. > > Another thing on this, maybe add a WARN() on wrapped accesses to show > what offset (or value) is returned in that case? Ignore it if you > don't think that's useful. > Yes, I also think WARN won't hurt in this case.

March 29, 2017

Re: Packaging related changes

by Rosanne DiMesio

On Wed, 29 Mar 2017 00:05:51 +0200 Michael Müller <michael(a)fds-team.de> wrote: Great news! > > We already added the new Ubuntu repository to the CDN, so that users can > start switching by now and don't have to wait till the next release. I'm running into the CDN sync issue; http://dl.winehq.org/wine-builds/ doesn't show a directory for Ubuntu, but http://dl.winehq.org/wine-builds/ubuntu does exist. > > To make sure that all users will be informed about this change, I will > push at least one additional update (Wine 2.5) to the PPA that displays > a warning during the package upgrade containing the necessary > instructions We should also post a notice on the forum. I can take care of that. > > Wine Stable is now available as package > --------------------------------------- > A lot of users will be happy about that. > > Added / removed distros > ----------------------- > > The following distros have been removed as they are no longer supported > or reach their EOL within the next month: > * Ubuntu Precise > * Fedora 23 > * Mageia 4 > Fedora 22 is also EOL. > > Nevertheless, we believe that these changes are very > useful and will make things much easier in the long term. > I agree. Thanks! -- Rosanne DiMesio dimesio(a)earthlink.net

March 28, 2017

Re: [v2 2/2] d3dx9/tests: Add more tests for preshader relative addressing.

by Matteo Bruni

2017-03-24 23:12 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> Again, I'd separate the update of the test effect blob and the existing test from the addition of a new test. Aside from that, I just had a quick glance. expected_light_specular_2[] doesn't seem like a good name, you can call that "test_light_specular_2" or similar and rename its "result" field "expected" (i.e. always calling the table driving the test "test_something" is nice and consistent, as is calling the array with expected results "expected").

March 28, 2017

Re: [v2 1/2] d3dx9: Support relative addressing in preshader.

by Matteo Bruni

2017-03-24 23:12 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -697,13 +739,13 @@ static HRESULT parse_preshader(struct d3dx_preshader *pres, unsigned int *ptr, u > for (i = 0; i < pres->ins_count; ++i) > { > for (j = 0; j < pres_op_info[pres->ins[i].op].input_count; ++j) > - update_table_size(pres->regs.table_sizes, pres->ins[i].inputs[j].table, > - get_reg_offset(pres->ins[i].inputs[j].table, > - pres->ins[i].inputs[j].offset + pres->ins[i].component_count - 1)); > + update_table_size(pres->regs.table_sizes, pres->ins[i].inputs[j].reg.table, > + get_reg_offset(pres->ins[i].inputs[j].reg.table, > + pres->ins[i].inputs[j].reg.offset + pres->ins[i].component_count - 1)); > > - update_table_size(pres->regs.table_sizes, pres->ins[i].output.table, > - get_reg_offset(pres->ins[i].output.table, > - pres->ins[i].output.offset + pres->ins[i].component_count - 1)); > + update_table_size(pres->regs.table_sizes, pres->ins[i].output.reg.table, > + get_reg_offset(pres->ins[i].output.reg.table, > + pres->ins[i].output.reg.offset + pres->ins[i].component_count - 1)); Do these update_table_size() always do the right thing with relative addressing? If I'm not mistaken, they should be fine because we only accept relative addressing for CONST and IMMED and the former is taken care by update_table_sizes_consts() just below while the latter's size is set statically just above this chunk. I think that means though that we don't need to call update_table_size() on the input arguments. If that sounds right to you, you could drop that "for(j)" altogether or, probably better, replace the update_table_size() with a check that the argument is not out of bounds (probably returning failure if the check doesn't pass). That should be a separate patch. > @@ -1088,18 +1130,65 @@ static HRESULT init_set_constants(struct d3dx_const_tab *const_tab, ID3DXConstan > return ret; > } > > +static double exec_get_reg_value(struct d3dx_regstore *rs, enum pres_reg_tables table, unsigned int offset) > +{ > + if (!regstore_is_val_set_reg(rs, table, offset / table_info[table].reg_component_count)) > + WARN("Using uninitialized input, table %u, offset %u.\n", table, offset); > + > + return regstore_get_double(rs, table, offset); > +} > + > static double exec_get_arg(struct d3dx_regstore *rs, const struct d3dx_pres_operand *opr, unsigned int comp) > { > - if (!regstore_is_val_set_reg(rs, opr->table, (opr->offset + comp) / table_info[opr->table].reg_component_count)) > - WARN("Using uninitialized input, table %u, offset %u.\n", opr->table, opr->offset + comp); > + unsigned int offset, base_index, reg_index, table; > + > + table = opr->reg.table; > + > + if (opr->index_reg.table == PRES_REGTAB_COUNT) > + base_index = 0; > + else > + base_index = lrint(exec_get_reg_value(rs, opr->index_reg.table, opr->index_reg.offset)); > + > + /* '4' is used instead of reg_component_count, as immediate constants (which have > + * reg_component_count of 1) are still indexed as 4 values according to the tests. > + */ > + offset = base_index * 4 + opr->reg.offset + comp; Actually, is there any reason why reg_component_count for PRES_REGTAB_IMMED isn't 4? Maybe change it to 4 and in parse_preshader() check that const_count is a multiple of 4 (which is something we're depending on anyway). That would be a separate patch too. Clue me if I'm missing anything. > + reg_index = offset / table_info[table].reg_component_count; > + > + if (reg_index >= rs->table_sizes[table]) > + { > + unsigned int wrap_size; > + > + if (table == PRES_REGTAB_CONST) > + { > + /* As it can be guessed from tests (by iterating base register value and > + * observing the period of result values repeat), offset into floating > + * constant table are wrapped to the nearest power of 2 and not to the > + * actual table size. > + */ > + for (wrap_size = 1; wrap_size < rs->table_sizes[table]; wrap_size <<= 1) > + ; Please close the comment on the last text line (i.e. "*/" shouldn't be on its own line) and maybe remove the part in parentheses which is pretty obvious. I like the comment otherwise. Another thing on this, maybe add a WARN() on wrapped accesses to show what offset (or value) is returned in that case? Ignore it if you don't think that's useful.

March 28, 2017

Packaging related changes

by Michael Müller

Hi everyone, I would like to announce some very important build server / packaging related changes that will take effect with the next release. As most of you should know, Sebastian and I took care of the Wine Development and Staging builds for more than a year now. So far we were using a collection of scripts which were run on a dedicated machine to build and upload the packages. This solution did not scale very well, so we decided to rework the whole build system. The new system can not only be controlled using a command line utility but also provides an easy to use website which gives us the possibility to provide some great new features. Interested Wine developers will be able to request access to the system so that they can start their own builds. This can for example be used to provide a patched Wine version for testing in a bug report or to verify that a patch is compatible with all platforms and compilers. Nevertheless, in this mail I would like to concentrate on the user related changes. The developer related features need some further polishing and will be announced in a separate mail. Starting with the next release, we will use our new build server to compile the packages, leading to the following differences: ====================================================================== Launchpad is no longer used for the Ubuntu builds ------------------------------------------------- In order to provide the possibility for Wine developers to create their own builds through our system, we had to move away from Launchpad. This will also have the advantage that we can provide older builds (see below). The disadvantage of this change is that our users will have to manually switch from the PPA to the new repository, since there is no way to push prebuilt Debian/Ubuntu packages into a PPA on Launchpad (not even with a commercial subscription). We already added the new Ubuntu repository to the CDN, so that users can start switching by now and don't have to wait till the next release. The repository can be added using the following commands: wget https://dl.winehq.org/wine-builds/Release.key sudo apt-key add Release.key sudo apt-add-repository 'https://dl.winehq.org/wine-builds/ubuntu/' To make sure that all users will be informed about this change, I will push at least one additional update (Wine 2.5) to the PPA that displays a warning during the package upgrade containing the necessary instructions (I hope this also works on Ubuntu, I have only tested it on Debian so far). This means users will have at least two weeks to switch from the PPA to the new repository - maybe a bit more if we push additional builds. Old packages for Ubuntu / Debian -------------------------------- On the last build server we used reprepo to generate the Debian repositories. One disadvantage of the tool is that it does not support multiple versions of a package. We tried several other tools, but they did not fit our needs, so I ended up writing my own tool that does not have this limitation. This will make it easy to download and test old versions of Wine when using the new repository. There are some small packaging changes left, but in the future you will be able to tell apt-get which version you would like to install using: sudo apt-get install winehq-devel=2.4.0-1~stretch You can get a list of all available versions with: apt-cache policy winehq-devel Notes: * The "-1~stretch" part is used for the packaging. * The additional ".0" version component is added for technical reasons, to ensure package managers can determine which version is the latest one. Wine Stable is now available as package --------------------------------------- We will start providing builds for Wine Stable, which will be called "winehq-stable". This is actually a change we have planned for quite some time now, but all the manual steps involved in the old build system and the limited resources blocked us from doing this change earlier. Added / removed distros ----------------------- The following distros have been removed as they are no longer supported or reach their EOL within the next month: * Ubuntu Precise * Fedora 23 * Mageia 4 One new distro has been added: * Fedora 25 We had to temporarily disable the building of packages for Mageia 5. The problem is that the tool used for generating the repository files is not very compatible with other distros and I did not find a working combination of genhdlist2, URPM and librpm that works on Debian without any warnings or errors. We therefore decided to pause the builds until we made sure that we can provide a fully working repository. repos.wine-staging.com changes ------------------------------ This only affects users who are still getting their packages from repos.wine-staging.com. So far we were providing two repositories, the original one at repos.wine-staging.com and the new one at dl.winehq.org. We wanted to get rid of the original one for quite some time now, since both repositories basically contain the same packages. We decided that it is now the perfect time to make this step. In order to receive further updates, those users will have to switch to the dl.winehq.org repository by following the normal installation instructions. We will also post an announcement on the wine-staging.com website to make all users aware of this change. ====================================================================== As you can see there are plenty of changes, and there are even more developer related changes ahead. Although we would like to avoid any inconvenience, there is some manual work involved for some of our users. Ubuntu users will have to switch to the WineHQ repository, and repos.wine-staging.com users will have to update repository paths for all distributions. Nevertheless, we believe that these changes are very useful and will make things much easier in the long term. Regards, Michael

March 28, 2017

Re: [PATCH 3/9] xmllite: Merge reader_lookup_ns and reader_lookup_nsdef implementations.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/xmllite/reader.c | 53 > +++++++++++++++++++++------------------------------ > 1 file changed, 22 insertions(+), 31 deletions(-) This fails here: ../../../tools/runtest -q -P wine -T ../../.. -M taskschd.dll -p taskschd_test.exe.so scheduler && touch scheduler.ok wine: Unhandled page fault on read access to 0x00000014 at address 0x7e05d1a7 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000014 in 32-bit code (0x7e05d1a7). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7e05d1a7 ESP:0033f4e0 EBP:0033f518 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:00000005 ECX:0013dbf8 EDX:0013dc08 ESI:0013dba8 EDI:0033f4f8 Stack dump: 0x0033f4e0: 0013dba8 00000000 0033f4f8 0033f5ac 0x0033f4f0: 7e09dfe8 7e06d000 0033f518 00000005 0x0033f500: 0013d8b8 7e05d136 0033f530 7e0a7000 0x0033f510: 0013dba8 00008454 0033f5c8 7e08f52d 0x0033f520: 0013d8b8 00000001 7e085061 7e08f52d 0x0033f530: 0013dba8 0033f5ac 00000000 00000000 Backtrace: =>0 0x7e05d1a7 xmlreader_GetValue+0x87(iface=<couldn't compute location>, value=<couldn't compute location>, len=<couldn't compute location>) [/home/julliard/wine/wine/dlls/xmllite/reader.c:3301] in xmllite (0x0033f518) 1 0x7e08f52d TaskDefinition_put_XmlText+0x4fc(iface=<couldn't compute location>, xml=<couldn't compute location>) [/home/julliard/wine/wine/dlls/taskschd/../../include/xmllite.h:366] in taskschd (0x0033f5c8) 2 0x7e08655d TaskFolder_RegisterTask+0xdc(iface=<couldn't compute location>, name=<couldn't compute location>, xml=<couldn't compute location>, flags=<couldn't compute location>, user={n1={n2={vt=0x1, wReserved1=0x11, wReserved2=0xd7e6, wReserved3=0x7bc3, n3={cVal=-16, uiVal=0xf7f0, ulVal=0x33f7f0, intVal=0x33f7f0, uintVal=0x33f7f0, bVal=-16, iVal=0xfffff7f0, lVal=0x33f7f0, fltVal=0.000000, dblVal=1511150729130819689735093992150912839369984728108261507947203237810152168316886087549523621236115883856409333081269449041715263251744478647635819958016247928527492445059748209219694759120105362131911873167308517643014354124272586209814321930163516051621612695826549010655565890397283549184.000000, boolVal=0xfffff7f0, scode=0x33f7f0, date=1511150729130819689735093992150912839369984728108261507947203237810152168316886087549523621236115883856409333081269449041715263251744478647635819958016247928527492445059748209219694759120105362131911873167308517643014354124272586209814321930163516051621612695826549010655565890397283549184.000000, bstrVal="`?????`??3≥?", cyVal={={Lo=0x33f7f0, Hi=0x7bc3d926}, int64=0x7bc3d9260033f7f0}, punkVal=0x33f7f0, pdispVal=0x33f7f0, parray=0x33f7f0, llVal=0x7bc3d9260033f7f0, ullVal=0x7bc3d9260033f7f0, pcVal="`", puiVal="`?????`??3≥?", pulVal=0x33f7f0, pintVal=0x33f7f0, puintVal=0x33f7f0, pbVal="`", piVal=0x33f7f0, plVal=0x33f7f0, pfltVal=0x33f7f0, pdblVal=0x33f7f0, pboolVal=0x33f7f0, pscode=0x33f7f0, pdate=0x33f7f0, pbstrVal=0x33f7f0, pvarVal=0x33f7f0, byref=0x33f7f0, pcyVal=0x33f7f0, pdecVal=0x33f7f0, ppunkVal=0x33f7f0, ppdispVal=0x33f7f0, pparray=0x33f7f0, pllVal=0x33f7f0, pullVal=0x33f7f0, brecVal={pvRecord=0x33f7f0, pRecInfo=0x7bc3d926}}}, decVal={wReserved=0x1, ={={scale=17, sign=0}, signscale=0x11}, Hi32=0x7bc3d7e6, ={={Lo32=0x33f7f0, Mid32=0x7bc3d926}, Lo64=0x7bc3d9260033f7f0}}}}, password={n1={n2={vt=0x1, wReserved1=0x33, wReserved2=0xd7e6, wReserved3=0x7bc3, n3={cVal=0, uiVal=0xf800, ulVal=0x33f800, intVal=0x33f800, uintVal=0x33f800, bVal=0, iVal=0xfffff800, lVal=0x33f800, fltVal=0.000000, dblVal=1511150729130824017523893055520610957737502764212302110344498125717661440571014434062133365926164698282569564768952682214359048014142616051827027404016169084942804013460762242723410078969754872380504678452713624017530338190327992990462096150957280615769007395389364412955620604666965917696.000000, boolVal=0xfffff800, scode=0x33f800, date=1511150729130824017523893055520610957737502764212302110344498125717661440571014434062133365926164698282569564768952682214359048014142616051827027404016169084942804013460762242723410078969754872380504678452713624017530338190327992990462096150957280615769007395389364412955620604666965917696.000000, bstrVal="`??3≥?", cyVal={={Lo=0x33f800, Hi=0x7bc3d926}, int64=0x7bc3d9260033f800}, punkVal=0x33f800, pdispVal=0x33f800, parray=0x33f800, llVal=0x7bc3d9260033f800, ullVal=0x7bc3d9260033f800, pcVal="`", puiVal="`??3≥?", pulVal=0x33f800, pintVal=0x33f800, puintVal=0x33f800, pbVal="`", piVal=0x33f800, plVal=0x33f800, pfltVal=0x33f800, pdblVal=0x33f800, pboolVal=0x33f800, pscode=0x33f800, pdate=0x33f800, pbstrVal=0x33f800, pvarVal=0x33f800, byref=0x33f800, pcyVal=0x33f800, pdecVal=0x33f800, ppunkVal=0x33f800, ppdispVal=0x33f800, pparray=0x33f800, pllVal=0x33f800, pullVal=0x33f800, brecVal={pvRecord=0x33f800, pRecInfo=0x7bc3d926}}}, decVal={wReserved=0x1, ={={scale='3', sign=0}, signscale=0x33}, Hi32=0x7bc3d7e6, ={={Lo32=0x33f800, Mid32=0x7bc3d926}, Lo64=0x7bc3d9260033f800}}}}, logon=<couldn't compute location>, sddl={n1={n2={vt=0x1, wReserved1=0x33, wReserved2=0x9000, wReserved3=0x7bcd, n3={cVal='X', uiVal=0xf858, ulVal=0x33f858, intVal=0x33f858, uintVal=0x33f858, bVal='X', iVal=0xfffff858, lVal=0x33f858, fltVal=0.000000, dblVal=1599434225947997951839798187977314197247957319428824144722608502103490780437150503599313505255422560087677850314482444820949235532773538977575659441663949722412271782696123659963005719660434825558687050651416890927056302450102863675852450005771357260534626948999518468080309345769339486208.000000, boolVal=0xfffff858, scode=0x33f858, date=1599434225947997951839798187977314197247957319428824144722608502103490780437150503599313505255422560087677850314482444820949235532773538977575659441663949722412271782696123659963005719660434825558687050651416890927056302450102863675852450005771357260534626948999518468080309345769339486208.000000, bstrVal="?3????????", cyVal={={Lo=0x33f858, Hi=0x7bc501ff}, int64=0x7bc501ff0033f858}, punkVal=0x33f858, pdispVal=0x33f858, parray=0x33f858, llVal=0x7bc501ff0033f858, ullVal=0x7bc501ff0033f858, pcVal="ê°3", puiVal="?3????????", pulVal=0x33f858, pintVal=0x33f858, puintVal=0x33f858, pbVal="ê°3", piVal=0x33f858, plVal=0x33f858, pfltVal=0x33f858, pdblVal=0x33f858, pboolVal=0x33f858, pscode=0x33f858, pdate=0x33f858, pbstrVal=0x33f858, pvarVal=0x33f858, byref=0x33f858, pcyVal=0x33f858, pdecVal=0x33f858, ppunkVal=0x33f858, ppdispVal=0x33f858, pparray=0x33f858, pllVal=0x33f858, pullVal=0x33f858, brecVal={pvRecord=0x33f858, pRecInfo=0x7bc501ff}}}, decVal={wReserved=0x1, ={={scale='3', sign=0}, signscale=0x33}, Hi32=0x7bcd9000, ={={Lo32=0x33f858, Mid32=0x7bc501ff}, Lo64=0x7bc501ff0033f858}}}}, task=<couldn't compute location>) [/home/julliard/wine/wine/dlls/taskschd/../../include/taskschd.h:2719] in taskschd (0x0033f668) 3 0x7ed666c6 test_GetTask+0x385() [/home/julliard/wine/wine/dlls/taskschd/tests/../../../include/taskschd.h:2140] in taskschd_test (0x0033fd18) 4 0x7ed6bd20 func_scheduler+0x2f() [/home/julliard/wine/wine/dlls/taskschd/tests/scheduler.c:1488] in taskschd_test (0x0033fd28) 5 0x7ed6bf56 run_test+0x115(name=<is not available>) [/home/julliard/wine/wine/dlls/taskschd/tests/../../../include/wine/test.h:589] in taskschd_test (0x0033fd58) 6 0x7ed63c5b main+0x14a(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/taskschd/tests/../../../include/wine/test.h:673] in taskschd_test (0x0033fe08) 7 0x7ed6c95b __wine_spec_exe_entry+0x4a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in taskschd_test (0x0033fe48) 8 0x7b45e5cc call_process_entry+0xb() in kernel32 (0x0033fe68) 9 0x7b45f509 start_process+0x68(entry=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1116] in kernel32 (0x0033fea8) 10 0x7bc80aac call_thread_func_wrapper+0xb() in ntdll (0x0033fec8) 11 0x7bc83869 call_thread_func+0xa8(entry=0x7b45f4a0, arg=0x7ed6c910, frame=0x33ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2759] in ntdll (0x0033ffa8) 12 0x7bc80a8a call_thread_entry_point+0x11() in ntdll (0x0033ffc8) 13 0x7bc540f3 start_process+0x12(arg=0xffb0e178) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3054] in ntdll (0x0033ffe8) 14 0xf755a8dd __x86.get_pc_thunk.di+0x2a() in libwine.so.1 (0x00000000) 15 0xf755aa40 wine_switch_to_stack+0x1f(func=0x7bc540e0, arg=0xffb0e178, stack=0x340000) [/home/julliard/wine/wine/libs/wine/port.c:77] in libwine.so.1 (0xffb0e148) 16 0x7bc59ca6 LdrInitializeThunk+0x235(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:3115] in ntdll (0xffb0e198) 17 0x7b46540f __wine_kernel_init+0xa4e() [/home/julliard/wine/wine/dlls/kernel32/process.c:1310] in kernel32 (0xffb0f088) 18 0x7bc5ab03 __wine_process_init+0x152() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3324] in ntdll (0xffb0f0f8) 19 0xf7558b43 wine_init+0x2a2(argc=0x3, argv=0xffb0f644, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:956] in libwine.so.1 (0xffb0f148) 20 0x7c000b58 main+0x97(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:254] in <wine-loader> (0xffb0f598) 21 0xf7362276 __libc_start_main+0xf5() in libc.so.6 (0x00000000) 0x7e05d1a7 xmlreader_GetValue+0x87 [/home/julliard/wine/wine/dlls/xmllite/reader.c:3301] in xmllite: movl 0x14(%eax),%edx -- Alexandre Julliard julliard(a)winehq.org

March 28, 2017

Re: [PATCH 5/5] user32: Store the item rects as relative to the items_rect.

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> writes: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > dlls/user32/menu.c | 68 ++++++++++++++++++++++++++---------------------------- > 1 file changed, 33 insertions(+), 35 deletions(-) This fails here: ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so win && touch win.ok win.c:1104: Test failed: window rect does not match: style:exstyle=0x94000000:0x00000000, menu=1, win=(110,100)-(335,300), calc=(110,99)-(335,300) win.c:1111: Test failed: window rect does not match: style:exstyle=0x94000000:0x00000000, menu=1, win=(110,100)-(335,300), calc=(110,99)-(335,300) win.c:1140: Test failed: synthetic rect does not match: style:exstyle=0x94000000:0x00000000, menu=1, client=(0,0)-(250,150), calc=(0,-1)-(250,150) win.c:1104: Test failed: window rect does not match: style:exstyle=0x15c00000:0x00000100, menu=1, win=(-3,-3)-(1923,1203), calc=(-3,-4)-(1923,1203) win.c:1111: Test failed: window rect does not match: style:exstyle=0x15c00000:0x00000100, menu=1, win=(-3,-3)-(1923,1203), calc=(-3,-4)-(1923,1203) win.c:1140: Test failed: synthetic rect does not match: style:exstyle=0x15c00000:0x00000100, menu=1, client=(0,0)-(250,150), calc=(0,-1)-(250,150) win.c:1104: Test failed: window rect does not match: style:exstyle=0x14c00000:0x00000100, menu=1, win=(110,100)-(335,300), calc=(110,99)-(335,300) win.c:1111: Test failed: window rect does not match: style:exstyle=0x14c00000:0x00000100, menu=1, win=(110,100)-(335,300), calc=(110,99)-(335,300) win.c:1140: Test failed: synthetic rect does not match: style:exstyle=0x14c00000:0x00000100, menu=1, client=(0,0)-(250,150), calc=(0,-1)-(250,150) win.c:1104: Test failed: window rect does not match: style:exstyle=0x14c00000:0x00000100, menu=1, win=(110,100)-(335,300), calc=(110,99)-(335,300) win.c:1111: Test failed: window rect does not match: style:exstyle=0x14c00000:0x00000100, menu=1, win=(110,100)-(335,300), calc=(110,99)-(335,300) win.c:1140: Test failed: synthetic rect does not match: style:exstyle=0x14c00000:0x00000100, menu=1, client=(0,0)-(250,150), calc=(0,-1)-(250,150) ... -- Alexandre Julliard julliard(a)winehq.org

March 28, 2017

Re: [PATCH 4/9] xmllite: Return static namespace instances for default namespaces in reader_lookup_ns.

by Jacek Caban

On 28.03.2017 16:54, Nikolay Sivov wrote: > On 28.03.2017 17:44, Jacek Caban wrote: >> Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> >> --- >> dlls/xmllite/reader.c | 33 +++++++++++++++++++++++++++------ >> 1 file changed, 27 insertions(+), 6 deletions(-) >> > >> +static struct ns default_ns = { >> + { emptyW }, >> + { emptyW } >> }; >> > I think this could use a better name. Default namespace is something > defined with unprefixed "xmlns" attribute name. Maybe empty_ns? To match > empty strings naming. Sure, I will rename it. > Also everything static in this patch should be also const, no? Some of them, with additional changes, yes. I will send a new patch set. Strings themselves can't be const for the same reason they are not const in strval static variables. Thanks, Jacek

March 28, 2017

Re: [PATCH 4/9] xmllite: Return static namespace instances for default namespaces in reader_lookup_ns.

by Nikolay Sivov

On 28.03.2017 17:44, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/xmllite/reader.c | 33 +++++++++++++++++++++++++++------ > 1 file changed, 27 insertions(+), 6 deletions(-) > > > +static struct ns default_ns = { > + { emptyW }, > + { emptyW } > }; > I think this could use a better name. Default namespace is something defined with unprefixed "xmlns" attribute name. Maybe empty_ns? To match empty strings naming. Also everything static in this patch should be also const, no?

March 28, 2017

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Stas Sergeev

28.03.2017 02:46, Ricardo Neri пишет: > On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote: >> 11.03.2017 02:59, Ricardo Neri пишет: >>> On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: >>> >>>> Why would you need one? >>>> Or do you really want to allow these instructions >>>> in v86 by the means of emulation? If so - this wasn't >>>> clearly stated in the patch description, neither it was >>>> properly discussed, it seems. >>> It str and sldt can be emulated in vm86 but as Andy mention, the >>> behavior sould be the same with and without emulation. >> Why would you do that? >> I looked up the dosemu2 CPU simulator code that >> is used under x86-64. It says this: > Stas, I apologize for the delayed reply; I missed your e-mail. >> It only implements smsw. >> So maybe you can make your code much >> simpler and remove the unneeded emulation? >> Same is for prot mode. > Do you mean the unneeded emulation for SLDT and STR? Not quite, I meant also sgdt and sidt in vm86. Yes that it will be a somewhat "incompatible" change, but if there is nothing to stay compatible with, then why to worry? Probably you could also remove the sldt and str emulation for protected mode, because, as I understand from this thread, wine does not need those. Note that these days dosemu2 uses v86 mode set up under kvm rather than vm86(). Your patches affect that the same way as they do for vm86() syscall, or can there be some differences? Or should the UMIP be enabled under kvm by hands? >> You know the wine's >> requirements now - they are very small. And >> dosemu doesn't need anything at all but smsw. >> And even smsw is very rare. > But emulation is still needed for SMSW, right? Likely so. If you want, I can enable the logging of this command and see if it is used by some of the DOS programs I have. But at least dosemu implements it, so probably it is needed. Of course if it is used by one of 100 DOS progs, then there is an option to just add its support to dosemu2 and pretend the compatibility problems did not exist. :) So, if this can be an option, I can do the tests to estimate its usage.

March 28, 2017

Re: [v2 PATCH] ole32: Add CoRegisterSurrogate/Ex stubs

by Huw Davies

On Mon, Mar 27, 2017 at 10:12:11PM +0000, Alistair Leslie-Hughes wrote: > v2 - Removed CoRegisterSurrogateEx from header > - Minor formatting changes > - Return E_NOTIMPL > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/ole32/compobj.c | 20 ++++++++++++++++++++ > dlls/ole32/ole32.spec | 4 ++-- > 2 files changed, 22 insertions(+), 2 deletions(-) Looks good. I've sent in a new version having run make_specfiles. Huw.

March 28, 2017

Re: [3/3] windowscodecs: Fixed loading png from streams

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

March 28, 2017

Re: [2/3] windowscodecs: Test for png codec seeking too far

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

March 28, 2017

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Ricardo Neri

On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote: > 11.03.2017 02:59, Ricardo Neri пишет: > > On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: > > > >> Why would you need one? > >> Or do you really want to allow these instructions > >> in v86 by the means of emulation? If so - this wasn't > >> clearly stated in the patch description, neither it was > >> properly discussed, it seems. > > It str and sldt can be emulated in vm86 but as Andy mention, the > > behavior sould be the same with and without emulation. > Why would you do that? > I looked up the dosemu2 CPU simulator code that > is used under x86-64. It says this: Stas, I apologize for the delayed reply; I missed your e-mail. > --- > CODE_FLUSH(); > if (REALMODE()) goto illegal_op; > PC += ModRMSim(PC+1, mode) + 1; > error("SLDT not implemented\n"); > break; > case 1: /* STR */ > /* Store Task Register */ > CODE_FLUSH(); > if (REALMODE()) goto illegal_op; > PC += ModRMSim(PC+1, mode) + 1; > error("STR not implemented\n"); > break; > ... > case 0: /* SGDT */ > /* Store Global Descriptor Table > Register */ > PC++; PC += ModRM(opc, PC, > mode|DATA16|MSTORE); > error("SGDT not implemented\n"); > break; > case 1: /* SIDT */ > /* Store Interrupt Descriptor Table > Register */ > PC++; PC += ModRM(opc, PC, > mode|DATA16|MSTORE); > error("SIDT not implemented\n"); > break; > --- > > It only implements smsw. > So maybe you can make your code much > simpler and remove the unneeded emulation? > Same is for prot mode. Do you mean the unneeded emulation for SLDT and STR? > You know the wine's > requirements now - they are very small. And > dosemu doesn't need anything at all but smsw. > And even smsw is very rare. But emulation is still needed for SMSW, right? The majority of my patches deal with computing the effective based on the instruction operands and linear addresses based on the effective address and the segment descriptor. Only two or three patches deal with identifying particular UMIP-protected instructions. Not having to worry about STR and SLDT in vm86 could simplify things a bit, though. Thanks and BR, Ricardo

March 27, 2017

APPDB Intro email

by Bijie Zhu

Hi,My name is Bijie Zhu and I am currently a computer science student studying at City University of New York - Queens College. This is my first time participate in an open source project, and I hope I can get some guidance and feedback for the outreach project application process. I want to apply for improving APPDB website project. And I want to improve the app voting system. I would like to design an evaluation metric system for the app voting. So when people votes, we know why they vote for the app. People now can not only search for the most voted app, but also search for the app with the most desired attributes. Thank you,Bijie Zhu

March 27, 2017

Re: [PATCH v4 6/7] user32/tests: Workaround an intermittent failure.

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://testbot.winehq.org/JobDetails.pl?Key=29730 Your paranoid android. === w7pro64 (64 bit msg) === msg.c:12609: Test failed: 54: ShowWindow(SW_MINIMIZE): 4: in msg 0x0047 expecting wParam 0x8170 got 0x1803 msg.c:12609: Test failed: 54: ShowWindow(SW_MINIMIZE): 5: the msg 0x0003 was expected, but got msg 0x0047 instead msg.c:12609: Test failed: 54: ShowWindow(SW_MINIMIZE): 6: the msg 0x0005 was expected, but got msg 0x0003 instead msg.c:12609: Test failed: 54: ShowWindow(SW_MINIMIZE): 7: the msg sequence is not complete: expected 0000 - actual 0005

March 27, 2017

[3/3] windowscodecs: Fixed loading png from streams

by Viktor Semykin

Png decoder was making one extra seek after it met IEND chunk. This led to crashes of some software. Signed-off-by: Viktor Semykin <thesame.ml(a)gmail.com> --- dlls/windowscodecs/pngformat.c | 7 +++---- dlls/windowscodecs/tests/pngformat.c | 2 +- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/dlls/windowscodecs/pngformat.c b/dlls/windowscodecs/pngformat.c index 990dcf6..c98a6a7 100644 --- a/dlls/windowscodecs/pngformat.c +++ b/dlls/windowscodecs/pngformat.c @@ -774,11 +774,12 @@ static HRESULT WINAPI PngDecoder_Initialize(IWICBitmapDecoder *iface, IStream *p /* Find the metadata chunks in the file. */ seek.QuadPart = 8; - hr = IStream_Seek(pIStream, seek, STREAM_SEEK_SET, &chunk_start); - if (FAILED(hr)) goto end; do { + hr = IStream_Seek(pIStream, seek, STREAM_SEEK_SET, &chunk_start); + if (FAILED(hr)) goto end; + hr = read_png_chunk(pIStream, chunk_type, NULL, &chunk_size); if (FAILED(hr)) goto end; @@ -816,8 +817,6 @@ static HRESULT WINAPI PngDecoder_Initialize(IWICBitmapDecoder *iface, IStream *p } seek.QuadPart = chunk_start.QuadPart + chunk_size + 12; /* skip data and CRC */ - hr = IStream_Seek(pIStream, seek, STREAM_SEEK_SET, &chunk_start); - if (FAILED(hr)) goto end; } while (memcmp(chunk_type, "IEND", 4)); This->stream = pIStream; diff --git a/dlls/windowscodecs/tests/pngformat.c b/dlls/windowscodecs/tests/pngformat.c index 20b6e93..18304a5 100644 --- a/dlls/windowscodecs/tests/pngformat.c +++ b/dlls/windowscodecs/tests/pngformat.c @@ -300,7 +300,7 @@ static IWICBitmapDecoder *create_decoder(const void *image_data, UINT image_size zero.QuadPart = 0; IStream_Seek (stream, zero, STREAM_SEEK_CUR, &pos); - todo_wine ok(pos.QuadPart < image_size, "seek beyond the end of stream: %lu >= %u\n", + ok(pos.QuadPart < image_size, "seek beyond the end of stream: %lu >= %u\n", pos.QuadPart, image_size); refcount = IStream_Release(stream); -- 2.12.1

March 27, 2017

[2/3] windowscodecs: Test for png codec seeking too far

by Viktor Semykin

Signed-off-by: Viktor Semykin <thesame.ml(a)gmail.com> --- dlls/windowscodecs/tests/Makefile.in | 2 +- dlls/windowscodecs/tests/pngformat.c | 19 ++++++++++--------- 2 files changed, 11 insertions(+), 10 deletions(-) diff --git a/dlls/windowscodecs/tests/Makefile.in b/dlls/windowscodecs/tests/Makefile.in index e11d184..e006e3d 100644 --- a/dlls/windowscodecs/tests/Makefile.in +++ b/dlls/windowscodecs/tests/Makefile.in @@ -1,5 +1,5 @@ TESTDLL = windowscodecs.dll -IMPORTS = windowscodecs oleaut32 ole32 user32 gdi32 +IMPORTS = windowscodecs oleaut32 ole32 user32 gdi32 shlwapi C_SRCS = \ bitmap.c \ diff --git a/dlls/windowscodecs/tests/pngformat.c b/dlls/windowscodecs/tests/pngformat.c index 34cb533..20b6e93 100644 --- a/dlls/windowscodecs/tests/pngformat.c +++ b/dlls/windowscodecs/tests/pngformat.c @@ -25,6 +25,7 @@ #include "windef.h" #include "wincodec.h" #include "wine/test.h" +#include "shlwapi.h" /* 1x1 pixel PNG image */ static const char png_no_color_profile[] = { @@ -277,21 +278,16 @@ static IWICImagingFactory *factory; static IWICBitmapDecoder *create_decoder(const void *image_data, UINT image_size) { - HGLOBAL hmem; - BYTE *data; HRESULT hr; IWICBitmapDecoder *decoder = NULL; IStream *stream; GUID format; LONG refcount; + ULARGE_INTEGER pos; + LARGE_INTEGER zero; - hmem = GlobalAlloc(0, image_size); - data = GlobalLock(hmem); - memcpy(data, image_data, image_size); - GlobalUnlock(hmem); - - hr = CreateStreamOnHGlobal(hmem, TRUE, &stream); - ok(hr == S_OK, "CreateStreamOnHGlobal error %#x\n", hr); + stream = SHCreateMemStream (image_data, image_size); + ok(stream != NULL, "SHCreateMemStream error\n"); hr = IWICImagingFactory_CreateDecoderFromStream(factory, stream, NULL, 0, &decoder); ok(hr == S_OK, "CreateDecoderFromStream error %#x\n", hr); @@ -302,6 +298,11 @@ static IWICBitmapDecoder *create_decoder(const void *image_data, UINT image_size ok(IsEqualGUID(&format, &GUID_ContainerFormatPng), "wrong container format %s\n", wine_dbgstr_guid(&format)); + zero.QuadPart = 0; + IStream_Seek (stream, zero, STREAM_SEEK_CUR, &pos); + todo_wine ok(pos.QuadPart < image_size, "seek beyond the end of stream: %lu >= %u\n", + pos.QuadPart, image_size); + refcount = IStream_Release(stream); ok(refcount > 0, "expected stream refcount > 0\n"); -- 2.12.1

March 27, 2017

[1/3] shlwapi: SHCreateMemStream added to shlwapi.h

by Viktor Semykin

Where it belongs according to its documentation. Signed-off-by: Viktor Semykin <thesame.ml(a)gmail.com> --- include/shlwapi.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/shlwapi.h b/include/shlwapi.h index 2c68b7f..c19ca31 100644 --- a/include/shlwapi.h +++ b/include/shlwapi.h @@ -978,6 +978,7 @@ HRESULT WINAPI SHCreateStreamOnFileA(LPCSTR,DWORD,struct IStream**); HRESULT WINAPI SHCreateStreamOnFileW(LPCWSTR,DWORD,struct IStream**); #define SHCreateStreamOnFile WINELIB_NAME_AW(SHCreateStreamOnFile) +struct IStream * WINAPI SHCreateMemStream(const BYTE *lpbData, UINT dwDataLen); HRESULT WINAPI SHCreateStreamOnFileEx(LPCWSTR,DWORD,DWORD,BOOL,struct IStream*,struct IStream**); HRESULT WINAPI SHCreateStreamWrapper(LPBYTE,DWORD,DWORD,struct IStream**); -- 2.12.1

March 27, 2017

Re: [PATCH v4 4/7] user32: Always send WM_CANCELMODE when disabling a window.

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://testbot.winehq.org/JobDetails.pl?Key=29728 Your paranoid android. === w7u (32 bit msg) === msg.c:5084: Test failed: ShowWindow(SW_RESTORE):overlapped: 18: the msg sequence is not complete: expected 0000 - actual 0088

March 27, 2017

Re: [2/3] windowscodecs: Test for png codec seeking too far

by Viktor Semykin

Yes it does. I will resubmit the patches with todo_wine. On 27/03/17 13:35, Vincent Povirk wrote: > Does this test fail on Wine without patch 3? If it fails, you should > add a todo_wine to the failing test, and remove it when the test is > fixed. -- best, Viktor.

March 27, 2017

Re: [2/3] windowscodecs: Test for png codec seeking too far

by Vincent Povirk

Does this test fail on Wine without patch 3? If it fails, you should add a todo_wine to the failing test, and remove it when the test is fixed.

March 27, 2017

Re: [PATCH 2/2 v2] devenum: Implement IMoniker::IsEqual().

by Jactry Zeng

Thanks again! 2017-03-27 23:08 GMT+08:00 Andrew Eikum <aeikum(a)codeweavers.com>: > Thanks, just a couple more tweaks. > > On Mon, Mar 27, 2017 at 10:57:36PM +0800, Jactry Zeng wrote: > > diff --git a/dlls/devenum/tests/devenum.c b/dlls/devenum/tests/devenum.c > > index e3c0f47256..b6275be8d2 100644 > > --- a/dlls/devenum/tests/devenum.c > > +++ b/dlls/devenum/tests/devenum.c > > @@ -135,6 +135,94 @@ static void test_devenum(IBindCtx *bind_ctx) > > if(sizeof(void*) == 4) > > ok(have_mrle, "mrle codec not found\n"); > > } > > +static void test_moniker_isequal(void) > > +{ > > + HRESULT res; > > + ICreateDevEnum *create_devenum = NULL; > > + IEnumMoniker *enum_moniker0 = NULL, *enum_moniker1 = NULL; > > + IMoniker *moniker0 = NULL, *moniker1 = NULL; > > + > > + res = CoCreateInstance(&CLSID_SystemDeviceEnum, NULL, > CLSCTX_INPROC, > > + &IID_ICreateDevEnum, > (LPVOID*)&create_devenum); > > + if (res) > > Please use FAILED() here. > > > + if (SUCCEEDED(IEnumMoniker_Next(enum_moniker0, 1, &moniker0, > NULL)) && > > + SUCCEEDED(IEnumMoniker_Next(enum_moniker1, 1, &moniker1, > NULL))) > > + { > > + res = IMoniker_IsEqual(moniker0, moniker1); > > + ok(SUCCEEDED(res), "IMoniker_IsEqual failed (res = %x)\n", > res); > > + > > + res = IMoniker_IsEqual(moniker1, moniker0); > > + ok(SUCCEEDED(res), "IMoniker_IsEqual failed (res = %x)\n", > res); > > These should be compared against S_OK, otherwise S_FALSE will also > pass the test. > > Andrew > > > -- Regards, Jactry Zeng

March 27, 2017

Re: [PATCH 2/2 v2] devenum: Implement IMoniker::IsEqual().

by Andrew Eikum

Thanks, just a couple more tweaks. On Mon, Mar 27, 2017 at 10:57:36PM +0800, Jactry Zeng wrote: > diff --git a/dlls/devenum/tests/devenum.c b/dlls/devenum/tests/devenum.c > index e3c0f47256..b6275be8d2 100644 > --- a/dlls/devenum/tests/devenum.c > +++ b/dlls/devenum/tests/devenum.c > @@ -135,6 +135,94 @@ static void test_devenum(IBindCtx *bind_ctx) > if(sizeof(void*) == 4) > ok(have_mrle, "mrle codec not found\n"); > } > +static void test_moniker_isequal(void) > +{ > + HRESULT res; > + ICreateDevEnum *create_devenum = NULL; > + IEnumMoniker *enum_moniker0 = NULL, *enum_moniker1 = NULL; > + IMoniker *moniker0 = NULL, *moniker1 = NULL; > + > + res = CoCreateInstance(&CLSID_SystemDeviceEnum, NULL, CLSCTX_INPROC, > + &IID_ICreateDevEnum, (LPVOID*)&create_devenum); > + if (res) Please use FAILED() here. > + if (SUCCEEDED(IEnumMoniker_Next(enum_moniker0, 1, &moniker0, NULL)) && > + SUCCEEDED(IEnumMoniker_Next(enum_moniker1, 1, &moniker1, NULL))) > + { > + res = IMoniker_IsEqual(moniker0, moniker1); > + ok(SUCCEEDED(res), "IMoniker_IsEqual failed (res = %x)\n", res); > + > + res = IMoniker_IsEqual(moniker1, moniker0); > + ok(SUCCEEDED(res), "IMoniker_IsEqual failed (res = %x)\n", res); These should be compared against S_OK, otherwise S_FALSE will also pass the test. Andrew

March 27, 2017

Re: [PATCH 2/2] devenum: Implement IMoniker::IsEqual().

by Jactry Zeng

Hi Andrew, Thanks for review! I sent another try. 2017-03-27 21:49 GMT+08:00 Andrew Eikum <aeikum(a)codeweavers.com>: > On Sun, Mar 26, 2017 at 04:31:55PM +0800, Jactry Zeng wrote: > > + res = ICreateDevEnum_CreateClassEnumerator(create_devenum, > &CLSID_LegacyAmFilterCategory, &enum_moniker0, 0); > > + ok(SUCCEEDED(res), "Cannot create enum moniker (res = %x)\n", res); > > + res = ICreateDevEnum_CreateClassEnumerator(create_devenum, > &CLSID_LegacyAmFilterCategory, &enum_moniker1, 0); > > + ok(SUCCEEDED(res), "Cannot create enum moniker (res = %x)\n", res); > > + if (!res) > > + { > > + if (!IEnumMoniker_Next(enum_moniker0, 1, &moniker0, NULL) && > !IEnumMoniker_Next(enum_moniker1, 1, &moniker1, NULL)) > > + { > > + res = IMoniker_IsEqual(moniker0, moniker1); > > + ok(!res, "IMoniker_IsEqual should failed (res = %x)\n", > res); > > + > > + res = IMoniker_IsEqual(moniker1, moniker0); > > + ok(!res, "IMoniker_IsEqual should failed (res = %x)\n", > res); > > + > > + IMoniker_Release(moniker0); > > + IMoniker_Release(moniker1); > > + } > > These patches look fine to me except the ok() message is wrong on these > two. > > Also, I think it's easier to read code that explicitly compares against > S_OK or > uses SUCCEEDED() instead of using !. > > Andrew > > > -- Regards, Jactry Zeng

March 27, 2017

Re: iphlpapi: Implement GetUnicastIpAddressTable (try 2)

by Bruno Jesus

On Monday, March 27, 2017, Hans Leidekker <hans(a)codeweavers.com> wrote: > > +DWORD WINAPI GetUnicastIpAddressTable(ADDRESS_FAMILY family, > MIB_UNICASTIPADDRESS_TABLE **table) > > +{ > > + IP_ADAPTER_ADDRESSES *aa, *ptr; > > + MIB_UNICASTIPADDRESS_TABLE *data; > > + DWORD ret, count = 0; > > + ULONG size; > > + > > + TRACE("%u, %p\n", family, table); > > + > > + if (!table || (family != WS_AF_INET && family != WS_AF_INET6 && > family != WS_AF_UNSPEC)) > > + return ERROR_INVALID_PARAMETER; > > + > > + ret = GetAdaptersAddresses(family, 0, NULL, NULL, &size); > > You should pass GAA_FLAG_SKIP_* flags here to exclude any data that will > not be used. Thanks for the review, I'll leave that to André ;-)

March 27, 2017

Re: [PATCH 2/2] devenum: Implement IMoniker::IsEqual().

by Andrew Eikum

On Sun, Mar 26, 2017 at 04:31:55PM +0800, Jactry Zeng wrote: > + res = ICreateDevEnum_CreateClassEnumerator(create_devenum, &CLSID_LegacyAmFilterCategory, &enum_moniker0, 0); > + ok(SUCCEEDED(res), "Cannot create enum moniker (res = %x)\n", res); > + res = ICreateDevEnum_CreateClassEnumerator(create_devenum, &CLSID_LegacyAmFilterCategory, &enum_moniker1, 0); > + ok(SUCCEEDED(res), "Cannot create enum moniker (res = %x)\n", res); > + if (!res) > + { > + if (!IEnumMoniker_Next(enum_moniker0, 1, &moniker0, NULL) && !IEnumMoniker_Next(enum_moniker1, 1, &moniker1, NULL)) > + { > + res = IMoniker_IsEqual(moniker0, moniker1); > + ok(!res, "IMoniker_IsEqual should failed (res = %x)\n", res); > + > + res = IMoniker_IsEqual(moniker1, moniker0); > + ok(!res, "IMoniker_IsEqual should failed (res = %x)\n", res); > + > + IMoniker_Release(moniker0); > + IMoniker_Release(moniker1); > + } These patches look fine to me except the ok() message is wrong on these two. Also, I think it's easier to read code that explicitly compares against S_OK or uses SUCCEEDED() instead of using !. Andrew

March 27, 2017

Re: Wine | Bug Query

by Henri Verbeet

On 27 March 2017 at 12:48, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > François had posted an attachment in the comments containing a related > implementation which you could refer. Hope it helps! You can find it here > https://bugs.winehq.org/show_bug.cgi?id=39644#c1 > There's an issue with the implementation in that attachment though. Process32First() and Process32Next() will change the current position in the snapshot, so using them in a recursive function like that will potentially skip over some processes.

March 27, 2017

Re: Wine | Bug Query

by Aaryaman Vasishta

Hi, While I'm not an expert in this part of wine, I want to point out that while it's definitely one way to do it, it's not the best way. You're relying on System() here which in turn relies on the output of the ps command. There's many potential issues here: 1. You have to make sure the output of the command you're executing will be the same across all systems. This could be an issue for cross-platform compatibility. 2. System() spawns extra processes which introduces overhead, which could be a problem on systems with limited resources. 3. 'ps' itself could have been removed, or modified maliciously, or only executable as root, probably anything could happen. IMO, as much as possible, you should rely on using the existing API's provided within François had posted an attachment in the comments containing a related implementation which you could refer. Hope it helps! You can find it here https://bugs.winehq.org/show_bug.cgi?id=39644#c1 Feel free to ask any further questions you have. Make sure to CC wine-devel in your replies so other devs can see and help if need be. Cheers, Aaryaman On Sun, Mar 26, 2017 at 9:55 PM, Akarsha Sehwag <akarsha15010(a)iiitd.ac.in> wrote: > Hi > I started with the bug( https://bugs.winehq.org/show_bug.cgi?id=39640 ). > As of what I understood, I am writing it below. Kindly correct me > wherever I go wrong. > To implement ProcessPage_OnEndProcessTree() correctly we need to kill > all its children and grandchildren also. > So for that purpose, we need to iterate through all the active > processes and check if their parent process is same as the process we > wish to terminate. If yes, we kill them, if no, we continue our > iteration. > Now, for implementing this, can we use 'ps' or 'top' command. > An example code: > > char string[30] = "ps -o pid --ppid "; > char ppid[7]; > sprintf(ppid , "%d" , getpid() ) ; > strcat ( string , ppid ) ; > system ( string ) ; > > ps -o pid --ppid <parent_Id> will give us the pid of all the > child_processes whose parent has a PID. And now, get the parentProcess's > PID by getpid(). Next, convert the integer into string and concatenate > the result with string to get the final command which is then executed > by system(string). > > Kindly tell me if I am anywhere near the right solution and also guide > me how to proceed. > > Thanks :) > Regards > -- > Akarsha Sehwag > > >

March 27, 2017

Re: [PATCH v3 1/6] user32: Move internal message from EnableWindow() to WIN_SetStyle().

by Alexandre Julliard

Zebediah Figura <z.figura12(a)gmail.com> writes: > The capture is already killed by handling WM_CANCELMODE, as in Windows. This should be a separate change, with its own tests. -- Alexandre Julliard julliard(a)winehq.org

March 27, 2017

Re: [PATCH] ole32: Add CoRegisterSurrogate/Ex stubs

by Huw Davies

On Mon, Mar 27, 2017 at 09:10:08AM +0000, Alistair Leslie-Hughes wrote: > Hi Huw, > > >> +HRESULT WINAPI CoRegisterSurrogateEx(REFGUID guid, void *reserved); > > I don't see this in my Windows 10 SDK. Where does it come from? > > I used this reference from the Microsoft site. > https://msdn.microsoft.com/en-us/library/ms687209 Ok, then I think we should drop the prototype from ole32.h since it's not in the SDK. Also, does your app depend of CoRegisterSurrogate/Ex returning S_OK? I'd be happier if they returned E_NOTIMPL. A few other style points: LPSURROGATE -> ISurrogate * There's an extraneous space in CoRegisterSurrogateEx (REFGUID guid, void *reserved) Huw.

March 27, 2017

Re: [PATCH] ole32: Add CoRegisterSurrogate/Ex stubs

by Alistair Leslie-Hughes

Hi Huw, >> +HRESULT WINAPI CoRegisterSurrogateEx(REFGUID guid, void *reserved); > I don't see this in my Windows 10 SDK. Where does it come from? I used this reference from the Microsoft site. https://msdn.microsoft.com/en-us/library/ms687209 Best Regards Alistair Leslie-Hughes

March 27, 2017

Re: [PATCH] ole32: Add CoRegisterSurrogate/Ex stubs

by Huw Davies

On Mon, Mar 27, 2017 at 04:29:24AM +0000, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > diff --git a/include/objbase.h b/include/objbase.h > index 875f0e1..8f89389 100644 > --- a/include/objbase.h > +++ b/include/objbase.h > @@ -331,6 +331,7 @@ HRESULT WINAPI CoRevokeClassObject(DWORD dwRegister); > HRESULT WINAPI CoGetPSClsid(REFIID riid,CLSID *pclsid); > HRESULT WINAPI CoRegisterPSClsid(REFIID riid, REFCLSID rclsid); > HRESULT WINAPI CoRegisterSurrogate(LPSURROGATE pSurrogate); > +HRESULT WINAPI CoRegisterSurrogateEx(REFGUID guid, void *reserved); I don't see this in my Windows 10 SDK. Where does it come from? Huw.

March 27, 2017

Re: iphlpapi: Implement GetUnicastIpAddressTable (try 2)

by Hans Leidekker

> +DWORD WINAPI GetUnicastIpAddressTable(ADDRESS_FAMILY family, MIB_UNICASTIPADDRESS_TABLE **table) > +{ > + IP_ADAPTER_ADDRESSES *aa, *ptr; > + MIB_UNICASTIPADDRESS_TABLE *data; > + DWORD ret, count = 0; > + ULONG size; > + > + TRACE("%u, %p\n", family, table); > + > + if (!table || (family != WS_AF_INET && family != WS_AF_INET6 && family != WS_AF_UNSPEC)) > + return ERROR_INVALID_PARAMETER; > + > + ret = GetAdaptersAddresses(family, 0, NULL, NULL, &size); You should pass GAA_FLAG_SKIP_* flags here to exclude any data that will not be used.

March 27, 2017

Re: [v2 PATCH] oledb32/tests: Add convert to DBTYPE_NUMERIC tests

by Huw Davies

On Sun, Mar 26, 2017 at 10:14:00PM +0000, Alistair Leslie-Hughes wrote: > v2 > - Added VT_NULL test > - Use result variables for each test. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> convert.c:3349: Test succeeded inside todo block: got 00000000 convert.c:3350: Test succeeded inside todo block: got 00000003 I've fixed these, removed the unnecessary src array, and resent. Huw.

March 27, 2017

Re: ntdll: Use environment variable "WINESERVER" first on search for wineserver to start.

by Ralf Habacker

Am 07.03.2017 um 15:20 schrieb Sebastian Lackner: > Was it intentional that you did not CC the wine-devel mailing list? no, I Just replyed to all; fixed that > > On 07.03.2017 10:22, Ralf Habacker wrote: >> In the opposite having wineserver environment variable set in users >> environment will make it sure to always starts wineserver with the >> requested settings. > Well, you could also change $PATH globally to let "wine" point to your > special wrapper executable. This would not really be different from using > a global WINESERVER variable. Really ? Adding an additional path looks more invasive in terms of security and maintenance as using a dedicated environment variable affecting only one executable. > > I think there is a misunderstanding here, each wineprefix uses its own > wineserver instance. Wineservers started for other prefixes will never > inherit any timeout settings. Thanks for this pointer, I wasn't aware of that. >> [...] >> >> With the mentioned patch applied to a local wine build (or with a >> renamed wineserver) the site now runs about two weeks and one noticable >> change is that the initial >> mentioned communication issue did not happens. This let me think that >> there may be a long time running issue with wineserver, which affects >> the dde interface. > It is nice that you have found a workaround, however we would also like > to fix such issues of course. If you find any way to trigger this issue, > please file a bug report. I will do but unfortunally I'm not at this point yet. Observations from the last weeks shows that the error happened two times: 1. wineserver is running 12 days and not restarted because one application showed a message box, therefore did not quit and blocked wineserver restart, which let other wine applications dde communication fail 20170309-061102.523831920: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> last wineserver restart 20170321-150057.967117185: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> manual restarted because of application freeze 2. wineserver is running 3 days and applications dde communications fails because wineserver has been restarted immediatly 20170322-061003.064358739: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> last restart .... 20170325-220751 -> print job starts 20170325-220753.202518273: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> wineserver has been restarted by timeout 20170325-220805 applications dde communication fails and wine reports wine: chdir to /tmp/.wine-37002/server-fd0a-9602cwine: : No such file or directory chdir to /tmp/.wine-37002/server-fd0a-9602c : No such file or directoryThis is expected and not a bug. It can happen when multiple wine > instances try to start up wineserver at the same time. Only the first > wineserver instance will be able to acquire the lock, all others will > exit and then connect to the existing wineserver. Sound reasonable Best regards Ralf

March 27, 2017

Re: [PATCH v3 3/6] user32: Always send WM_CANCELMODE when disabling a window.

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://testbot.winehq.org/JobDetails.pl?Key=29708 Your paranoid android. === w7u (32 bit msg) === msg.c:12062: Test failed: WmMouseHoverSeq: 0: the msg sequence is not complete: expected 0118 - actual 0000 msg.c:12064: Test failed: wrong tme.dwFlags 00000001, expected 00000000 msg.c:12064: Test failed: wrong tme.hwndTrack 0012017C, expected 00000000 msg.c:12064: Test failed: wrong tme.dwHoverTime 400, expected 0

March 26, 2017

Re: [PATCH 4/7] wined3d: Save pixel and vertex shader resource views in stateblocks.

by Józef Kucia

On Sun, Mar 26, 2017 at 8:55 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 24 March 2017 at 17:14, Józef Kucia <jkucia(a)codeweavers.com> wrote: >> @@ -3132,6 +3132,8 @@ struct wined3d_saved_states >> WORD vertexShaderConstantsB; /* WINED3D_MAX_CONSTS_B, 16 */ >> WORD vertexShaderConstantsI; /* WINED3D_MAX_CONSTS_I, 16 */ >> BOOL vs_consts_f[WINED3D_MAX_VS_CONSTS_F]; >> + DWORD pixel_shader_resource_views : 16; /* MAX_FRAGMENT_SAMPLERS, 16 */ >> + DWORD vertex_shader_resource_views : 16; /* MAX_VERTEX_SAMPLERS, 4 */ > So why is it 16 bits wide? I used 16 bits to avoid adjusting padding back and forth. It doesn't really matter much, but yes, it would have been better to simply adjust padding.

March 26, 2017

Re: [PATCH 4/7] wined3d: Save pixel and vertex shader resource views in stateblocks.

by Henri Verbeet

On 24 March 2017 at 17:14, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -3132,6 +3132,8 @@ struct wined3d_saved_states > WORD vertexShaderConstantsB; /* WINED3D_MAX_CONSTS_B, 16 */ > WORD vertexShaderConstantsI; /* WINED3D_MAX_CONSTS_I, 16 */ > BOOL vs_consts_f[WINED3D_MAX_VS_CONSTS_F]; > + DWORD pixel_shader_resource_views : 16; /* MAX_FRAGMENT_SAMPLERS, 16 */ > + DWORD vertex_shader_resource_views : 16; /* MAX_VERTEX_SAMPLERS, 4 */ So why is it 16 bits wide?

March 26, 2017

Re: [PATCH 2/7] wined3d: Allow creating shader resource views with NULL description.

by Henri Verbeet

On 24 March 2017 at 17:14, Józef Kucia <jkucia(a)codeweavers.com> wrote: > For ddraw, d3d8 and d3d9. > I think we'd rather just create a wined3d_view_desc in those DLLs.

March 26, 2017

Wine | Bug Query

by Akarsha Sehwag

Hi I started with the bug( https://bugs.winehq.org/show_bug.cgi?id=39640 ). As of what I understood, I am writing it below. Kindly correct me wherever I go wrong. To implement ProcessPage_OnEndProcessTree() correctly we need to kill all its children and grandchildren also. So for that purpose, we need to iterate through all the active processes and check if their parent process is same as the process we wish to terminate. If yes, we kill them, if no, we continue our iteration. Now, for implementing this, can we use 'ps' or 'top' command. An example code: char string[30] = "ps -o pid --ppid "; char ppid[7]; sprintf(ppid , "%d" , getpid() ) ; strcat ( string , ppid ) ; system ( string ) ; ps -o pid --ppid <parent_Id> will give us the pid of all the child_processes whose parent has a PID. And now, get the parentProcess's PID by getpid(). Next, convert the integer into string and concatenate the result with string to get the final command which is then executed by system(string). Kindly tell me if I am anywhere near the right solution and also guide me how to proceed. Thanks :) Regards -- Akarsha Sehwag

March 26, 2017

Re: cmd: Adjust CMD_LIST to a tree-like structure and implement command chains

by Flávio J. Saraiva

The patches will always build, the tests are what will fail (will need the full patch set). To avoid the temporary failure of tests the patch set needs to be applied in one go (commit to a separate branch and then merge to master?), but that's out of my hands. I got "Needs splitting" so that's what i'll do, and this time I won't try to minimize changes to other code (and therefore avoid adding hacks). Flávio J. Saraiva 2017-03-25 10:58 GMT+00:00 Stefan Dösinger <stefandoesinger(a)gmail.com>: > > Am 24.03.2017 um 17:26 schrieb Flávio J. Saraiva <flaviojs2005(a)gmail.com>: > > If what winehq untimately cares about is not having regressions, then > the best approach here is to split it into logical bits (only passing > tests at the end of the patch set) and not try to minimize the changes > in the parts i'm being forced to change. > > This means that if one patch gets rejected then the whole set is also > rejected. > I guess this wouldn't be a problem? > > It is a potential problem for bisects. Let's assume I am bisecting a > direct3d regression in an app that also uses cmd.exe. Somewhere between the > good and bad revisions for the d3d problem there is a revision where the app > fails because of cmd. > > That said, this sometimes happens and it's solvable with some extra work > during bisects (e.g. manually applying the fix for cmd for revisions that > are broken in a way I don't care). But this is one of the reasons why e.g. > having a temporary build failure is a no-go. >

March 26, 2017

Re: [PATCH v2 1/5] user32: Fix handling of internal messages.

by Zebediah Figura

On 03/24/2017 04:23 PM, Alexandre Julliard wrote: > Zebediah Figura <z.figura12(a)gmail.com> writes: > >> This patch adds a new flag and a server reply, allowing GetQueueStatus >> to ignore internal messages, and MsgWaitForMultipleObjects to process >> internal messages until a real sent message is found. > > There's a lot of code duplication in there, and adding private flags to > public headers is discouraged. There has to be a better way of doing > this, or else it would need a stronger justification than a couple of > EnableWindow tests. > I'll get rid of this patch and resubmit the others, then. My main motivation was trying to fix an intermittent failure (bug #42568), but it is probably better to try to submit a workaround for that.

March 25, 2017

Re: [PATCH] oleaut32: Implement GetAltMonthNames()

by Nikolay Sivov

On 25.03.2017 23:20, Jacek Caban wrote: > Hi Nikolay, > > > On 3/24/17 7:32 PM, Nikolay Sivov wrote: >> diff --git a/dlls/oleaut32/oleaut.c b/dlls/oleaut32/oleaut.c >> index f9734e6d78..816b18ce35 100644 >> --- a/dlls/oleaut32/oleaut.c >> +++ b/dlls/oleaut32/oleaut.c >> @@ -935,3 +935,109 @@ HCURSOR WINAPI OleIconToCursor( HINSTANCE >> hinstExe, HICON hIcon) >> /* FIXME: make an extended conversation from HICON to HCURSOR */ >> return CopyCursor(hIcon); >> } >> + >> +BOOL WINAPI GetAltMonthNames(LCID lcid, LPOLESTR **str) > > Shouldn't it return HRESULT? It should, thanks. I guess I was confused by msdn page for it. > > Thanks, > Jacek > >

March 25, 2017

Re: [PATCH] oleaut32: Implement GetAltMonthNames()

by Jacek Caban

Hi Nikolay, On 3/24/17 7:32 PM, Nikolay Sivov wrote: > diff --git a/dlls/oleaut32/oleaut.c b/dlls/oleaut32/oleaut.c > index f9734e6d78..816b18ce35 100644 > --- a/dlls/oleaut32/oleaut.c > +++ b/dlls/oleaut32/oleaut.c > @@ -935,3 +935,109 @@ HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hIcon) > /* FIXME: make an extended conversation from HICON to HCURSOR */ > return CopyCursor(hIcon); > } > + > +BOOL WINAPI GetAltMonthNames(LCID lcid, LPOLESTR **str) Shouldn't it return HRESULT? Thanks, Jacek

March 25, 2017

Re: cmd: Adjust CMD_LIST to a tree-like structure and implement command chains

by Stefan Dösinger

> Am 24.03.2017 um 17:26 schrieb Flávio J. Saraiva <flaviojs2005(a)gmail.com>: > > If what winehq untimately cares about is not having regressions, then > the best approach here is to split it into logical bits (only passing > tests at the end of the patch set) and not try to minimize the changes > in the parts i'm being forced to change. > > This means that if one patch gets rejected then the whole set is also rejected. > I guess this wouldn't be a problem? > It is a potential problem for bisects. Let's assume I am bisecting a direct3d regression in an app that also uses cmd.exe. Somewhere between the good and bad revisions for the d3d problem there is a revision where the app fails because of cmd. That said, this sometimes happens and it's solvable with some extra work during bisects (e.g. manually applying the fix for cmd for revisions that are broken in a way I don't care). But this is one of the reasons why e.g. having a temporary build failure is a no-go.

March 25, 2017

Re: [PATCH v2 1/5] user32: Fix handling of internal messages.

by Alexandre Julliard

Zebediah Figura <z.figura12(a)gmail.com> writes: > This patch adds a new flag and a server reply, allowing GetQueueStatus > to ignore internal messages, and MsgWaitForMultipleObjects to process > internal messages until a real sent message is found. There's a lot of code duplication in there, and adding private flags to public headers is discouraged. There has to be a better way of doing this, or else it would need a stronger justification than a couple of EnableWindow tests. -- Alexandre Julliard julliard(a)winehq.org

March 24, 2017

Re: cmd: Adjust CMD_LIST to a tree-like structure and implement command chains

by Flávio J. Saraiva

2017-03-23 23:15 GMT+00:00 Henri Verbeet <hverbeet(a)gmail.com>: > You can, but that still potentially regresses functionality for > applications, which is what we ultimately care about. It may be > justified in some situations, but if at all possible it's still best > avoided. If what winehq untimately cares about is not having regressions, then the best approach here is to split it into logical bits (only passing tests at the end of the patch set) and not try to minimize the changes in the parts i'm being forced to change. This means that if one patch gets rejected then the whole set is also rejected. I guess this wouldn't be a problem? I'll proceed like this for now and review this slowly. In the current patch the only part that might contain an untested regression is the 'CALL FOR' part (that's why it has a FIXME). Flávio J. Saraiva

March 24, 2017

Re: [PATCH] comctl32/taskdialog: Implement buttons.

by Fabian Maurer

> > -static const UINT DIALOG_MIN_WIDTH = 180; > > +static const UINT DIALOG_MIN_WIDTH = 240; > > > > static const UINT DIALOG_SPACING = 5; > > > > -static const UINT DIALOG_BUTTON_WIDTH = 50; > > -static const UINT DIALOG_BUTTON_HEIGHT = 14; > > +static const UINT DIALOG_BUTTON_WIDTH_MIN = 45; > > +static const UINT DIALOG_BUTTON_HEIGHT = 13; > > This was taken from MSGBOX template, what's a point in making it different? I just tested it on my Win7 box and tried to get it to look as similar as possible. Where do the MSGBOX template values come from? I can remove that change, if those values are better. > Did you test that buttons are supposed to support multiple lines of text? Normal buttons don't allow multiple lines of text. But we only use the right side of the rectangle anyways, so it works as expected. Problem is, on windows and on wine the buttons clips the text when it gets too long, so I'm not fully it's the correct way to implement this. Should I change this? There's also the fact that buttons get larger in height on windows, even if the text is a single line only. Should I reproduce this? Moreover, wine displays newlines as boxes while this isn't the case on windows. Not sure how to deal with this though. > > static unsigned int taskdialog_add_control(struct > > taskdialog_template_desc *desc, WORD id, const WCHAR *class,> > > - HINSTANCE hInstance, const WCHAR *text, short x, short y, short > > cx, short cy) + DWORD style, HINSTANCE hInstance, const WCHAR > > *text, short x, short y, short cx, short cy)> > > { > > > > struct taskdialog_control *control = Alloc(sizeof(*control)); > > unsigned int size, class_size, text_size; > > > > @@ -117,7 +167,7 @@ static unsigned int taskdialog_add_control(struct > > taskdialog_template_desc *desc> > > control->template = template = Alloc(size); > > control->template_size = size; > > > > - template->style = WS_VISIBLE; > > + template->style = WS_VISIBLE | WS_CHILD | style; > > You don't use styles in this patch, this is unnecessary change. I'm using BS_PUSHBUTTON for the buttons, is this unnecessary? > > > template->dwExtendedStyle = 0; > > template->x = x; > > template->y = y; > > > > @@ -136,78 +186,126 @@ static unsigned int taskdialog_add_control(struct > > taskdialog_template_desc *desc> > > static unsigned int taskdialog_add_main_instruction(struct > > taskdialog_template_desc *desc) { > > > > - RECT rect = { 0, 0, desc->dialog_width - DIALOG_SPACING * 2, 0}; /* > > padding left and right of the control */ - const WCHAR *textW = NULL; > > - unsigned int size, length; > > - HFONT oldfont; > > - HDC hdc; > > + unsigned int size; > > + RECT rect; > > > > if (!desc->taskconfig->pszMainInstruction) > > > > return 0; > > > > - if (IS_INTRESOURCE(desc->taskconfig->pszMainInstruction)) > > - { > > - if (!(length = LoadStringW(desc->taskconfig->hInstance, > > (UINT_PTR)desc->taskconfig->pszMainInstruction, - (WCHAR > > *)&textW, 0))) > > - { > > - WARN("Failed to load main instruction text\n"); > > - return 0; > > - } > > - } > > - else > > - { > > - textW = desc->taskconfig->pszMainInstruction; > > - length = strlenW(textW); > > - } > > - > > - hdc = GetDC(0); > > - oldfont = SelectObject(hdc, desc->font); > > - > > - dialogunits_to_pixels(desc, &rect.right, NULL); > > - DrawTextW(hdc, textW, length, &rect, DT_LEFT | DT_EXPANDTABS | > > DT_CALCRECT | DT_WORDBREAK); - pixels_to_dialogunits(desc, > > &rect.right, &rect.bottom); > > - > > - SelectObject(hdc, oldfont); > > - ReleaseDC(0, hdc); > > + rect = text_get_rect(desc, desc->taskconfig->pszMainInstruction); > > > > - size = taskdialog_add_control(desc, ID_MAIN_INSTRUCTION, WC_STATICW, > > desc->taskconfig->hInstance, + size = taskdialog_add_control(desc, > > ID_MAIN_INSTRUCTION, WC_STATICW, 0, desc->taskconfig->hInstance,> > > desc->taskconfig->pszMainInstruction, DIALOG_SPACING, > > desc->dialog_height, > > rect.right, rect.bottom); > > > > - desc->dialog_height += rect.bottom; > > + desc->dialog_height += rect.bottom + DIALOG_SPACING; > > > > return size; > > > > } > > > > -static unsigned int taskdialog_add_common_buttons(struct > > taskdialog_template_desc *desc) +static button_info make_button(struct > > taskdialog_template_desc *desc, int id, const WCHAR *text) +{ > > + RECT rect; > > + button_info button; > > + > > + button.id = id; > > + button.text = text; > > + rect = text_get_rect(desc, text); > > + button.width = rect.right + 10; > > + if (button.width < DIALOG_BUTTON_WIDTH_MIN) > > + button.width = DIALOG_BUTTON_WIDTH_MIN; > > + > > + return button; > > +} > > This does not handle "text" correctly. Sorry, but I don't see the problem here. Do you mind explaining? In both text_get_rect and later on taskdialog_add_control both text or a resource-ID are allowed. > > +static unsigned int taskdialog_add_buttons(struct > > taskdialog_template_desc *desc)> > > { > > > > - short button_x = desc->dialog_width - DIALOG_BUTTON_WIDTH - > > DIALOG_SPACING;> > > DWORD flags = desc->taskconfig->dwCommonButtons; > > > > + const TASKDIALOGCONFIG *taskconfig = desc->taskconfig; > > + UINT alignment = DIALOG_SPACING_BUTTONS_LEFT; /* minimum distance > > from the left dialog border */ + UINT location_x; > > + BOOL first_row = TRUE; > > + button_info *buttons; > > + int count = 0; > > + int i; > > > > unsigned int size = 0; > > > > -#define TASKDIALOG_ADD_COMMON_BUTTON(id) \ > > - do { \ > > - size += taskdialog_add_control(desc, ID##id, WC_BUTTONW, > > COMCTL32_hModule, MAKEINTRESOURCEW(IDS_BUTTON_##id), \ - > > button_x, desc->dialog_height + DIALOG_SPACING, DIALOG_BUTTON_WIDTH, > > DIALOG_BUTTON_HEIGHT); \ - button_x -= DIALOG_BUTTON_WIDTH + > > DIALOG_SPACING; \ > > - } while(0) > > - if (flags & TDCBF_CLOSE_BUTTON) > > - TASKDIALOG_ADD_COMMON_BUTTON(CLOSE); > > - if (flags & TDCBF_CANCEL_BUTTON) > > - TASKDIALOG_ADD_COMMON_BUTTON(CANCEL); > > - if (flags & TDCBF_RETRY_BUTTON) > > - TASKDIALOG_ADD_COMMON_BUTTON(RETRY); > > - if (flags & TDCBF_NO_BUTTON) > > - TASKDIALOG_ADD_COMMON_BUTTON(NO); > > - if (flags & TDCBF_YES_BUTTON) > > - TASKDIALOG_ADD_COMMON_BUTTON(YES); > > + /* Allocate enough memory for the custom and the default buttons */ > > + if (taskconfig->cButtons && taskconfig->pButtons) > > + buttons = HeapAlloc(GetProcessHeap(), 0, (taskconfig->cButtons + > > 6) * sizeof(button_info)); + else > > + { > > + buttons = HeapAlloc(GetProcessHeap(), 0, 6 * > > sizeof(button_info)); > > + } > > + > > + /* Custom buttons */ > > + if (taskconfig->cButtons && taskconfig->pButtons) > > + { > > + for (i = 0; i < taskconfig->cButtons; i++) > > + { > > + buttons[count++] = make_button(desc, > > taskconfig->pButtons[i].nButtonID, > > taskconfig->pButtons[i].pszButtonText); + } > > + } > > + > > + /* Default buttons */ > > > > if (flags & TDCBF_OK_BUTTON) > > > > - TASKDIALOG_ADD_COMMON_BUTTON(OK); > > - /* Always add OK button */ > > - if (list_empty(&desc->controls)) > > - TASKDIALOG_ADD_COMMON_BUTTON(OK); > > -#undef TASKDIALOG_ADD_COMMON_BUTTON > > - > > - /* make room for common buttons row */ > > - desc->dialog_height += DIALOG_BUTTON_HEIGHT + 2 * DIALOG_SPACING; > > + buttons[count++] = make_button(desc, IDOK, > > MAKEINTRESOURCEW(IDS_BUTTON_OK)); + if (flags & TDCBF_YES_BUTTON) > > + buttons[count++] = make_button(desc, IDYES, > > MAKEINTRESOURCEW(IDS_BUTTON_YES)); + if (flags & TDCBF_NO_BUTTON) > > + buttons[count++] = make_button(desc, IDNO, > > MAKEINTRESOURCEW(IDS_BUTTON_NO)); + if (flags & TDCBF_RETRY_BUTTON) > > + buttons[count++] = make_button(desc, IDRETRY, > > MAKEINTRESOURCEW(IDS_BUTTON_RETRY)); + if (flags & > > TDCBF_CANCEL_BUTTON) > > + buttons[count++] = make_button(desc, IDCANCEL, > > MAKEINTRESOURCEW(IDS_BUTTON_CANCEL)); + if (flags & > > TDCBF_CLOSE_BUTTON) > > + buttons[count++] = make_button(desc, IDCLOSE, > > MAKEINTRESOURCEW(IDS_BUTTON_CLOSE)); + > > + /* There must be at least one button */ > > + if (count == 0) > > + buttons[count++] = make_button(desc, IDOK, > > MAKEINTRESOURCEW(IDS_BUTTON_OK)); + > > + /* Position buttons */ > > + location_x = alignment; > > + for (i = 0; i < count; i++) > > + { > > + /* When beginning new row, align the first */ > > + if (location_x + buttons[i].width + DIALOG_SPACING_BUTTON_W > > > desc->dialog_width) + { > > + if (first_row) > > + { > > + int diff = desc->dialog_width - location_x; > > + > > + first_row = FALSE; > > + for (int j = 0; j < i; j++) /* Align first row to the > > right */ + buttons[j].x += diff; > > + alignment = buttons[0].x; /* left-align all coming rows > > to the first row */ + } > > + location_x = alignment; > > + desc->dialog_height += DIALOG_BUTTON_HEIGHT + > > DIALOG_SPACING_BUTTON_H; + } > > + > > + buttons[i].x = location_x; > > + buttons[i].y = desc->dialog_height; > > + > > + location_x += buttons[i].width + DIALOG_SPACING_BUTTON_W; > > + } > > + if (first_row) /* Always align first row to the right */ > > + { > > + int diff = desc->dialog_width - (buttons[count - 1].x + > > buttons[count - 1].width + DIALOG_SPACING_BUTTON_W); + for (int i > > = 0; i < count; i++) > > + buttons[i].x += diff; > > + } > > I don't like this. Why do you need temporary array, and iterating twice > seems excessive. The problem is, a later button might influence the position of the first button. That's why I created them as temporary array and then change their position once I know how. I also could iterate the loop twice I guess, but that sounded a bit ugly, too. If you have a better idea to address this problem, I'd be happy to hear it. > > + for (i = 0; i < count; i++) > > + { > > + size += taskdialog_add_control(desc, buttons[i].id, WC_BUTTONW, > > BS_PUSHBUTTON, COMCTL32_hModule, + buttons[i].text, > > buttons[i].x, buttons[i].y, buttons[i].width, DIALOG_BUTTON_HEIGHT); + > > } > > This won't work for custom buttons. Right, I missed that, thanks for pointing it out. > > - size += taskdialog_add_common_buttons(&desc); > > + size += taskdialog_add_buttons(&desc); > > I'd rather have it separated if possible. I'll do some testing myself, > before commenting further. I see. Just figured it would make sense to handle all buttons in one function, since they are aligned together - if no command-links are used. Is there a reason you want it separated? Regards, Fabian Maurer

March 24, 2017

Re: [PATCH 2/3] d3dx9: Support relative addressing in preshader.

by Paul Gofman

On 03/24/2017 05:10 PM, Matteo Bruni wrote: > 2017-03-24 2:16 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: >> >> Sorry, I messed up things actually, base register actually can come from >> temporary (register) table also, which happens in the test. So I will >> introduce extra structure for registers. > So I had a look at my stuff. As you know it has got very little and > specific testing and is most likely missing some cases but I see that: > - for relative addressing I accept any register type as base but > expect only temporary registers as index (i.e. I look for "flags" == 1 > and then for the "base" fields only when parsing TEMP registers) > - for CONST registers the "flags" != 0 field has a different meaning. > In that case it is an offset in the IMMED table and there is no > additional "base" register type + index in the effect bytecode, so > it's indexed like imm["flags" + cidx]. > What is seen from my tests for relative addressing (all these cases below are present in the test currently there in the last patch I sent, though I will add another test in the updated patch which covers more cases, and also has a non-zero absolute offset, which helped me to discovered and fix the bug): 1. Temporary register or constant float (e. g. c0) register can be used as base register in relative addressing. Temporary register is used by compiler when it needs to do some precompute for the index value, like rounding, multiplying by stride for structure or any other arithmetic with indexes, otherwise cX registers are used directly. 2. If the value being indexed is 4x vectors aligned, the main register being indexed is cX, it is directly indexed by base register; 3. If the value we are indexing into is some vector, or matrix, or anything not 4x aligned, compiler generates a code doing the indexing through a 'dot' instructions with base register indexing immediate constants to dot with. This is basically present in the test I sent (doing a trace with +d3dx will show preshaders with these relative addressing types, the string to easily find the code in the output is 'imm['). in the next update I will include another test which is a bit more complicated in terms of this 'dot' arithmetic. So unless I am missing something I don't see yet how flags have a different meaning for const or immed registers, it looks very straightforward and matches the test.

March 24, 2017

Re: [PATCH 2/3] d3dx9: Support relative addressing in preshader.

by Matteo Bruni

2017-03-24 2:16 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > On 03/24/2017 03:31 AM, Matteo Bruni wrote: >> >> 2017-03-24 0:39 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: >>> >>> On 03/24/2017 01:57 AM, Matteo Bruni wrote: >>>> >>>> 2017-03-23 16:06 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: >>>>> >>>>> Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> >>>>> --- >>>>> dlls/d3dx9_36/preshader.c | 103 >>>>> ++++++++++++++++++++++++++++++++++++------- >>>>> dlls/d3dx9_36/tests/effect.c | 38 ++++++++-------- >>>>> 2 files changed, 106 insertions(+), 35 deletions(-) >>>>> >>>>> diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c >>>>> index 9aedc99..2974ffd 100644 >>>>> --- a/dlls/d3dx9_36/preshader.c >>>>> +++ b/dlls/d3dx9_36/preshader.c >>>>> @@ -191,6 +191,8 @@ struct d3dx_pres_operand >>>>> /* offset is component index, not register index, e. g. >>>>> offset for component c3.y is 13 (3 * 4 + 1) */ >>>>> unsigned int offset; >>>>> + enum pres_reg_tables base_reg_table; >>>>> + unsigned int base_reg_offset; >>>>> }; >>>> >>>> It would be nicer to create a struct for storing together table and >>>> offset and to pass it around to the various functions taking both >>>> arguments, like parse_pres_reg(). >>>> It should probably be a separate patch before this one. >>> >>> Actually I can't guess the case when base_reg_table would be not a >>> floating >>> constant preshader input. Maybe I just remove this variable and check >>> with >>> FIXME during parsing? >> >> Sure, that's fine. Still the struct seems useful for parameter >> passing, if not right there in struct d3dx_pres_operand. >> > Sorry, I messed up things actually, base register actually can come from > temporary (register) table also, which happens in the test. So I will > introduce extra structure for registers. So I had a look at my stuff. As you know it has got very little and specific testing and is most likely missing some cases but I see that: - for relative addressing I accept any register type as base but expect only temporary registers as index (i.e. I look for "flags" == 1 and then for the "base" fields only when parsing TEMP registers) - for CONST registers the "flags" != 0 field has a different meaning. In that case it is an offset in the IMMED table and there is no additional "base" register type + index in the effect bytecode, so it's indexed like imm["flags" + cidx]. Unfortunately I don't think I have any effect with the latter feature around. Supporting that should probably be a separate patch but try to see if you can replicate that. >>>>> static double exec_get_arg(struct d3dx_regstore *rs, const struct >>>>> d3dx_pres_operand *opr, unsigned int comp) >>>>> { >>>>> - if (!regstore_is_val_set_reg(rs, opr->table, (opr->offset + comp) >>>>> / >>>>> table_info[opr->table].reg_component_count)) >>>>> - WARN("Using uninitialized input, table %u, offset %u.\n", >>>>> opr->table, opr->offset + comp); >>>>> + unsigned int base_offset, index; >>>>> + >>>>> + if (opr->base_reg_table == PRES_REGTAB_COUNT) >>>>> + index = 0; >>>>> + else >>>>> + index = (int)exec_get_reg_value(rs, opr->base_reg_table, >>>>> opr->base_reg_offset); >>>> >>>> I think it's better with lrint() in place of the cast. >>> >>> I just want to note that whenever the input is from floating values FX >>> compiler generates preshader instructions which do the rounding, and >>> skips >>> that if the base register comes from integers. Do you think we need to do >>> extra rounding in this case? >> >> Ah, you're right, I somehow overlooked that. Actually I think >> doublechecking (e.g. with a FIXME) that the source is really integer >> would be useful. If it isn't too much of a mess it would be nice to >> avoid the roundtrip to doubles for the index entirely. > > Source of the base register value seems not so straightforward to check. > The input table always has float format. To do such check, we need to find > which parameter the register is initialized from, we don't have such a link > now. Right, that's hard to do in the current architecture. Also I confused this with the IMMED relative addressing I mentioned above, for those my code expects the input CONST register to be mapped to an INT parameter. That's only relevant in my architecture since I don't fill all the input registers before executing the preshader but go fetch them "on-the-fly" for each instruction. That is also clearly worse than your solution, of course. Long story short, just ignore this. > Besides, using float register as index seems totally ok in effect, > compiler generates rounding code for this case. Moreover, base register used > in instruction may come from temporary ("r") registers and be a result of > some operations, like rounding or multiplication when indexing anything with > stride other than 4xfloat. Right as well. I don't know, lrintf() seems like a good idea still. > Or could it be you had in mind not checking the source of register > value, but rather that the value is actually an integer (fractional part is > zero)? That might be a bit fragile (because of potential numerical accuracy troubles), although as you noticed the compiler seems to go to great lengths to make sure the value is exactly an integer. Maybe doing that kind of check only in a if (WARN_ON(d3dx)) might make sense as it would be somewhat surprising and it might reveal something else going on but it doesn't seem worth it to me in general.

March 24, 2017

Re: [PATCH v2] winex11: Use GLX_OML_sync_control to synchronise buffer swaps with X11DRV_FLUSH_GL_DRAWABLE requests.

by Henri Verbeet

On 24 March 2017 at 13:02, Jacek Caban <jacek(a)codeweavers.com> wrote: > On 23.03.2017 23:58, Henri Verbeet wrote: >> diff --git a/dlls/winex11.drv/init.c b/dlls/winex11.drv/init.c >> index af2fd92..7efd603 100644 >> --- a/dlls/winex11.drv/init.c >> +++ b/dlls/winex11.drv/init.c >> @@ -375,9 +375,6 @@ static INT X11DRV_ExtEscape( PHYSDEV dev, INT escape, INT in_count, LPCVOID in_d >> RECT rect = physDev->dc_rect; >> >> OffsetRect( &rect, -physDev->dc_rect.left, -physDev->dc_rect.top ); >> - /* The GL drawable may be lagged behind if we don't flush first, so >> - * flush the display make sure we copy up-to-date data */ >> - XFlush( gdi_display ); > > > Shouldn't this be called if GLX_OML_sync_control is not available? It > seems to me that it should either depend on extension availability or be > a separated patch. > It doesn't work (on any current driver), and as far as I'm aware it never did. In that regard it could be a separate commit, yes. I think the change is closely enough related to the other changes and the resulting patch is trivial enough to justify including it, but I don't feel particularly strongly about that.

March 24, 2017

Re: [PATCH v2] winex11: Use GLX_OML_sync_control to synchronise buffer swaps with X11DRV_FLUSH_GL_DRAWABLE requests.

by Jacek Caban

Hi Henri, On 23.03.2017 23:58, Henri Verbeet wrote: > diff --git a/dlls/winex11.drv/init.c b/dlls/winex11.drv/init.c > index af2fd92..7efd603 100644 > --- a/dlls/winex11.drv/init.c > +++ b/dlls/winex11.drv/init.c > @@ -375,9 +375,6 @@ static INT X11DRV_ExtEscape( PHYSDEV dev, INT escape, INT in_count, LPCVOID in_d > RECT rect = physDev->dc_rect; > > OffsetRect( &rect, -physDev->dc_rect.left, -physDev->dc_rect.top ); > - /* The GL drawable may be lagged behind if we don't flush first, so > - * flush the display make sure we copy up-to-date data */ > - XFlush( gdi_display ); Shouldn't this be called if GLX_OML_sync_control is not available? It seems to me that it should either depend on extension availability or be a separated patch. Thanks, Jacek

March 24, 2017

Re: [PATCH] oledb32/tests: Add convert to DBTYPE_NUMERIC tests

by Huw Davies

On Fri, Mar 24, 2017 at 01:11:17AM +0000, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/oledb32/tests/convert.c | 147 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 147 insertions(+) > > diff --git a/dlls/oledb32/tests/convert.c b/dlls/oledb32/tests/convert.c > index b8b3c6f..4e49058 100644 > --- a/dlls/oledb32/tests/convert.c > +++ b/dlls/oledb32/tests/convert.c > @@ -3264,6 +3264,152 @@ static void test_converttoiunknown(void) > ok(dst_len == 44, "got %ld\n", dst_len); > } > > +#define test_numberic_val(dst, array) _test_numberic_val(__LINE__, dst, array); > +static inline void _test_numberic_val(unsigned line, DB_NUMERIC *dst, BYTE *array) > +{ > + int same = !memcmp(dst->val, array, sizeof(dst->val)); > + ok_(__FILE__,line) (same, "Invalid byte array\n"); > + if(!same) > + { > + int i; > + for(i=0; i < sizeof(dst->val); i++) > + ok_(__FILE__,line) (dst->val[i] == array[i], " byte %d got 0x%02x\n", i, dst->val[i]); > + } > +} > + > +static inline void set_numberic_array(BYTE *dst, > + BYTE x0, BYTE x1, BYTE x2, BYTE x3, BYTE x4, BYTE x5, BYTE x6, > + BYTE x7, BYTE x8, BYTE x9, BYTE x10, BYTE x11, BYTE x12, BYTE x13, > + BYTE x14, BYTE x15) > +{ > + dst[0] = x0; dst[1] = x1; dst[2] = x2; dst[3] = x3; > + dst[4] = x4; dst[5] = x5; dst[6] = x6; dst[7] = x7; > + dst[8] = x8; dst[9] = x9; dst[10] = x10; dst[11] = x11; > + dst[12] = x12; dst[13] = x13; dst[14] = x14; dst[15] = x15; > +} > + > +static void test_converttonumeric(void) > +{ > + HRESULT hr; > + DBSTATUS dst_status; > + DBLENGTH dst_len; > + DB_NUMERIC dst; > + BYTE src[20]; > + static WCHAR strW[] = {'1','2','3','.','4','5',0}; > + static WCHAR largeW[] = {'1','2','3','4','5','6','7','8','9','0',0}; > + BSTR bstr; > + FLOAT fvalue = 543.21f; > + VARIANT_BOOL boolean = VARIANT_TRUE; > + LARGE_INTEGER i8; > + BYTE array[16]; > + > + *(INT *)src = 4098; > + dst_len = 0x1234; > + dst.scale = 30; > + memset(dst.val, 0xfe, sizeof(dst.val)); > + hr = IDataConvert_DataConvert(convert, DBTYPE_I4, DBTYPE_NUMERIC, 0, &dst_len, src, &dst, sizeof(dst), 0, &dst_status, 10, 0, 0); > + todo_wine ok(hr == S_OK, "got %08x\n", hr); > + todo_wine ok(dst_status == DBSTATUS_S_OK, "got %08x\n", dst_status); > + todo_wine ok(dst_len == sizeof(dst), "got %ld\n", dst_len); > + todo_wine ok(dst.precision == 10, "returned %d\n", dst.precision); > + todo_wine ok(dst.scale == 0, "returned %d\n", dst.scale); > + todo_wine ok(dst.sign == 1, "returned %d\n", dst.sign); > + set_numberic_array(array, 0x02, 0x10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ); > + todo_wine test_numberic_val(&dst, array); All this seems overly complicated. How about something like: DB_NUMERIC val1 = {10, 0, 1, {0x02, 0x10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }}; /* 4098 */ .... hr = IDataConvert_DataConvert(convert, DBTYPE_I4, DBTYPE_NUMERIC, 0, &dst_len, src, &dst, sizeof(dst), 0, &dst_status, 10, 0, 0); todo_wine ok(hr == S_OK, "got %08x\n", hr); todo_wine ok(dst_status == DBSTATUS_S_OK, "got %08x\n", dst_status); todo_wine ok(dst_len == sizeof(dst), "got %ld\n", dst_len); todo_wine ok(!memcmp(&dst, &val1, sizeof(dst), "mismatch\n"); It doesn't print out the retrieved value on failure, and you could add this if you want. However, once the conversion is actually implemented, you won't need that anyway. You should probably add a test for converting a variant of type VT_NULL too. Huw.

March 24, 2017