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

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