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