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