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

Packaging related changes

by Michael Müller

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

March 28, 2017

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

by Alexandre Julliard

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

March 28, 2017

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

by Alexandre Julliard

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

March 28, 2017

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

by Jacek Caban

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

March 28, 2017

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

by Nikolay Sivov

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

March 28, 2017

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

by Stas Sergeev

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

March 28, 2017

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

by Huw Davies

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

March 28, 2017

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

by Marvin

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

March 28, 2017

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

by Marvin

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

March 28, 2017

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

by Ricardo Neri

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

March 27, 2017