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

Re: wbemprox: Add a partial implementation of Win32_IP4RouteTable.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > --- > dlls/wbemprox/builtin.c | 75 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/wbemprox/tests/query.c | 63 +++++++++++++++++++++++++++++++++++++ > 2 files changed, 138 insertions(+) This doesn't build on Mingw: i686-w64-mingw32-gcc -c -o builtin.o ../../../wine/dlls/wbemprox/builtin.c -I. -I../../../wine/dlls/wbemprox \ -I../../include -I../../../wine/include -D__WINESRC__ -DUSE_WS_PREFIX -D_REENTRANT -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla \ -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer \ -g -O2 -fno-diagnostics-show-caret -D_WIN32 In file included from ../../../wine/dlls/wbemprox/builtin.c:38:0: ../../../wine/include/ws2tcpip.h:176:104: warning: ‘struct timeval’ declared inside parameter list will not be visible outside of this definition or declaration ../../../wine/include/ws2tcpip.h:178:107: warning: ‘struct timeval’ declared inside parameter list will not be visible outside of this definition or declaration ../../../wine/dlls/wbemprox/builtin.c: In function ‘fill_ip4routetable’: ../../../wine/dlls/wbemprox/builtin.c:2074:47: warning: implicit declaration of function ‘ntohl’ [-Wimplicit-function-declaration] ../.././../obj-elf64/tools/winegcc/winegcc -o wbemprox.dll -B../.././../obj-elf64/tools/winebuild \ --sysroot=../.. -b i686-w64-mingw32 -fasynchronous-unwind-tables -shared ../../../wine/dlls/wbemprox/wbemprox.spec \ builtin.o class.o main.o process.o qualifier.o query.o reg.o security.o service.o services.o \ table.o wbemlocator.o wql.tab.o wbemprox_r.res ../../dlls/winspool.drv/libwinspool.a \ ../../dlls/version/libversion.a ../../dlls/iphlpapi/libiphlpapi.a ../../dlls/dxgi/libdxgi.a \ ../../dlls/oleaut32/liboleaut32.a ../../dlls/ole32/libole32.a ../../dlls/advapi32/libadvapi32.a \ ../../dlls/user32/libuser32.a ../../dlls/gdi32/libgdi32.a ../../dlls/ws2_32/libws2_32.a \ ../../dlls/rpcrt4/librpcrt4.a ../../libs/port/libwine_port.a -lwine builtin.o: In function `fill_ip4routetable': /home/julliard/wine/build/obj-pe32/dlls/wbemprox/../../../wine/dlls/wbemprox/builtin.c:2074: undefined reference to `ntohl' /home/julliard/wine/build/obj-pe32/dlls/wbemprox/../../../wine/dlls/wbemprox/builtin.c:2076: undefined reference to `ntohl' collect2: error: ld returned 1 exit status winegcc: i686-w64-mingw32-gcc failed Makefile:638: recipe for target 'wbemprox.dll' failed -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2017

Re: [PATCH] user32:add SIZEALL_BIG cursor, reusing SIZEALL resource Fixes bug#42303

by Anton Romanov

On Thu, Jan 26, 2017 at 11:02 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Anton Romanov <theli.ua(a)gmail.com> writes: > >> @@ -2227,6 +2227,7 @@ typedef struct tagCBTACTIVATESTRUCT >> #define IDC_HAND MAKEINTRESOURCE(32649) >> #define IDC_APPSTARTING MAKEINTRESOURCE(32650) >> #define IDC_HELP MAKEINTRESOURCE(32651) >> +#define IDC_SIZEALL_BIG MAKEINTRESOURCE(32654) > > There's no such definition in Windows. > >> @@ -1011,6 +1011,7 @@ >> #define OCR_NO 32648 >> #define OCR_HAND 32649 >> #define OCR_APPSTARTING 32650 >> +#define OCR_SIZEALL_BIG 32654 > > This is already defined as OCR_RDR2DIM. Alright, I've now drawn all OCR_RDR* cursors and submitted updated patch with them to use already defined OCR_RDR* defines. Thanks!

Jan. 31, 2017

Re: [PATCH] wined3d: Implement buffer texture range.

by Guillaume Charifi

Thank you for your detailed answer :) Le 31/01/2017 à 00:19, Józef Kucia a écrit : > I'll explain in more details to encourage you ;-) > > On Sun, Jan 29, 2017 at 1:12 PM, Józef Kucia <joseph.kucia(a)gmail.com> wrote: >> Please add a test. > Adding a test should be very easy. In test_buffer_srv() everything is > ready to add a test with an offset. You can use "rgba16_buffer" as > data, set size to {2.0f, 2.0f} or {1.0f, 1.0f}, and test with > different values of "srv_first_element" and "srv_element_count". Try > to come up with interesting test cases and test edge cases. Looks easier than I thought, indeed. I'll be doing this. > >> On Sun, Jan 29, 2017 at 12:25 AM, Guillaume Charifi >> <guillaume.charifi(a)sfr.fr> wrote: >>> + GL_EXTCALL(glTexBufferRange(GL_TEXTURE_BUFFER, view_format->glInternal, buffer->buffer_object, >>> + desc->u.buffer.start_idx, desc->u.buffer.count)); >> This is wrong. > glTexBufferRange() accepts offsets and sizes in bytes, but in D3D11 > offsets and sizes for typed buffers are expressed as the number of > elements. You have to multiply "start_idx" and "count" by > "view_format->byte_count". A test would also help you to find this > mistake. Oh, I see, I'm fixing it. > > Another advice: start small. It's better to send a few well tested > patches and get them accepted first. > > I'll hope to see some patches from you committed soon. > > Cheers, > Józef >

Jan. 31, 2017

Re: wine/test.h: Identify test result lines printed by child processes.

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > On Mon, 30 Jan 2017, Alexandre Julliard wrote: > [...] >> I don't think the test framework should be modifying the environment in >> all the tests. It already breaks some things: >> >> ../../../tools/runtest -q -P wine -T ../../.. -M msvcrt.dll -p msvcrt_test.exe.so environ && touch environ.ok >> environ.c:198: Test failed: Expected environment block pointer element to be non-NULL >> wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed2a986 (thread 0074), starting debugger... > > Damn. > > I still think making the child process result lines different from > their parent's is necessary to fix bug 32354 but I'm open to > alternatives if someone has any idea. > https://bugs.winehq.org/show_bug.cgi?id=32354 Couldn't you simply print the pid, have winetest print it too on the 'done' line, and check that they match? -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2017

Re: wine/test.h: Identify test result lines printed by child processes.

by Francois Gouget

On Mon, 30 Jan 2017, Alexandre Julliard wrote: [...] > I don't think the test framework should be modifying the environment in > all the tests. It already breaks some things: > > ../../../tools/runtest -q -P wine -T ../../.. -M msvcrt.dll -p msvcrt_test.exe.so environ && touch environ.ok > environ.c:198: Test failed: Expected environment block pointer element to be non-NULL > wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed2a986 (thread 0074), starting debugger... Damn. I still think making the child process result lines different from their parent's is necessary to fix bug 32354 but I'm open to alternatives if someone has any idea. https://bugs.winehq.org/show_bug.cgi?id=32354 Maybe creating a named object would be less likely to break the tests and be acceptable? For instance this could be a mutex called something like "winetest${bitness}_${dll}_${test}" to avoid problems in case different tests are run in parallel, and the idea would be to check for GetLastError() == ERROR_ALREADY_EXISTS. The nice thing about named objects is they should just go away when the last process referencing them goes away. Creating a file instead would certainly avoid nasty side-effects but to avoid trouble with left-over files after crashes one would have to check for locks on it which seems much more complex. -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 31, 2017

Re: [PATCH] winealsa.drv: Fix handling of system real time MIDI messages

by Andrew Eikum

On Tue, Jan 31, 2017 at 04:16:17AM -0200, Bruno Jesus wrote: > MIDI spec at http://www.somascape.org/midi/tech/spec.html state that system real time messages "... are each single byte messages, with no following data bytes...", currently wine is prepending SYSEX header generating invalid messages. > Looking at this spec, should Tune Request be handled the same way as these system real time messages? I also noticed Reset is still handled as a SysEx after your patch. Should it be? Aside from that, I also noticed an old patch that unfortunately never got merged: https://www.winehq.org/pipermail/wine-patches/2013-January/121366.html If you understand this MIDI stuff a little bit, you might be a good person to review and re-submit that patch :) Thanks, Andrew

Jan. 31, 2017

Re: [PATCH 2/2] winspool/tests: Test for LastError also on success of AddMonitor

by Huw Davies

On Mon, Jan 30, 2017 at 07:43:35PM +0100, Detlef Riekenberg wrote: > dlls/winspool.drv/tests/info.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/dlls/winspool.drv/tests/info.c b/dlls/winspool.drv/tests/info.c > index f6527c5..602e935 100644 > --- a/dlls/winspool.drv/tests/info.c > +++ b/dlls/winspool.drv/tests/info.c > @@ -435,6 +435,12 @@ static void test_AddMonitor(void) > SetLastError(MAGIC_DEAD); > res = AddMonitorA(NULL, 2, (LPBYTE) &mi2a); > ok(res, "returned %d with %d (expected '!= 0')\n", res, GetLastError()); > + if (res) > + { > + /* Some apps depend on the result of GetLastError() */ > + res = GetLastError(); > + ok(res == ERROR_SUCCESS, "got 0x%x/%u (expected ERROR_SUCCESS)\n", res, res); > + } There's no need to have this test conditional on res. Also, don't reassign res to the error, just use GetLastError() directly. And just print the error in decimal. Huw.

Jan. 31, 2017

Re: [PATCH 1/2] localspl: Clear LastError on success in AddMonitor

by Huw Davies

On Mon, Jan 30, 2017 at 07:43:34PM +0100, Detlef Riekenberg wrote: > dlls/localspl/provider.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/localspl/provider.c b/dlls/localspl/provider.c > index f359b73..f370b9f 100644 > --- a/dlls/localspl/provider.c > +++ b/dlls/localspl/provider.c > @@ -1541,6 +1541,9 @@ static BOOL WINAPI fpAddMonitor(LPWSTR pName, DWORD Level, LPBYTE pMonitors) > RegCloseKey(hentry); > } > > + if (res) > + SetLastError(ERROR_SUCCESS); /* Monitor installer depend on this */ > + > RegCloseKey(hroot); > return (res); > } I think unconditionally resetting the error after monitor_unload() would be cleaner. Huw.

Jan. 31, 2017

Re: comctl32: Fix some more spec file entries

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.com> writes: > On 01/30/2017 11:07 PM, André Hentschel wrote: >> True, thx! >> The reason is that I'm currently ignoring handles as we don't have a clear rule for them, and as the first parameter type begins with an H, my script thought it is a handle and ignored it... > Most handles are pointer types. But of course there are exceptions. Even when the actual type is a pointer, most handles are conceptually ints, they don't point to anything. In any case, it doesn't matter which type we use for handles, and we definitely don't want to start "fixing" them. Maybe we should just get rid of the ptr type once and for all... -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2017

Re: comctl32: Fix some more spec file entries

by Michael Stefaniuc

On 01/30/2017 11:07 PM, André Hentschel wrote: > True, thx! > The reason is that I'm currently ignoring handles as we don't have a clear rule for them, and as the first parameter type begins with an H, my script thought it is a handle and ignored it... Most handles are pointer types. But of course there are exceptions. bye michael

Jan. 31, 2017

Re: [PATCH] winealsa.drv: Fix handling of system real time MIDI messages

by Bruno Jesus

On Tue, Jan 31, 2017 at 4:23 AM, Austin English <austinenglish(a)gmail.com> wrote: > On Tue, Jan 31, 2017 at 12:16 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: >> MIDI spec at http://www.somascape.org/midi/tech/spec.html state that system real time messages "... are each single byte messages, with no following data bytes...", currently wine is prepending SYSEX header generating invalid messages. >> >> A comparison before and after patch using gmidimonitor as ouput MIDI port: >> http://alexa.pro.br/~bruno/wine/midi.png >> >> I believe the patch to be correct, I don't own any MIDI hardware to test but gmidimonitor seems good enough. > > Do wineoss / winepulse need similar fixes? wineoss code at [1] in a quick look at [2] suggests it may be wrong because MAYBE system real time messages are supposed to be _TIMER_EVENT like SEQ_START_TIMER or SEQ_STOP_TIMER... Hard to tell beucase these messages values don't match the MIDI spec. winepulse seems to forward mid stuff to ALSA because the only time "mid" is found is in the spec file: winepulse.drv.spec:@ stdcall -private midMessage(long long long long long) winealsa.drv.midMessage [1] http://source.winehq.org/source/dlls/wineoss.drv/midi.c#1435 [2] https://github.com/torvalds/linux/blob/master/include/uapi/linux/soundcard.h Best wishes, Bruno

Jan. 31, 2017

Re: [PATCH] winealsa.drv: Fix handling of system real time MIDI messages

by Austin English

On Tue, Jan 31, 2017 at 12:16 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > MIDI spec at http://www.somascape.org/midi/tech/spec.html state that system real time messages "... are each single byte messages, with no following data bytes...", currently wine is prepending SYSEX header generating invalid messages. > > A comparison before and after patch using gmidimonitor as ouput MIDI port: > http://alexa.pro.br/~bruno/wine/midi.png > > I believe the patch to be correct, I don't own any MIDI hardware to test but gmidimonitor seems good enough. Do wineoss / winepulse need similar fixes? -- -Austin GPG: 14FB D7EA A041 937B

Jan. 31, 2017

Re: [PATCH] regedit: When processing 3.1 ignore any lines that don't begin with HKCR.

by Zebediah Figura

On 01/30/2017 09:46 PM, Nikolay Sivov wrote: > On 31.01.2017 5:51, Zebediah Figura wrote: >> Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> >> --- >> programs/regedit/regproc.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/programs/regedit/regproc.c b/programs/regedit/regproc.c >> index c055c10..b6de728 100644 >> --- a/programs/regedit/regproc.c >> +++ b/programs/regedit/regproc.c >> @@ -616,8 +616,9 @@ static void processRegEntry31(WCHAR *line) >> int res; >> >> static WCHAR empty[] = {0}; >> + static WCHAR hkcr[] = {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0}; >> >> - if (line[0] == '\0') return; >> + if (memcmp(line, hkcr, sizeof(hkcr) - sizeof(WCHAR))) return; >> >> /* get key name */ >> while (line[key_end] && !isspaceW(line[key_end])) key_end++; >> > > Is it guaranteed 'line' is a least that large? Also you can remove > terminating 0 from hkcr to avoid sizeof(WCHAR) subtraction. > > Sorry for my lack of C knowledge, but isn't this a valid use of memcmp? (And yes, I will fix that; thank you.)

Jan. 31, 2017

Re: xmllite: Add Unknown to map (Coverity)

by Nikolay Sivov

On 31.01.2017 1:11, André Hentschel wrote: > CID 1364307 > > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/xmllite/reader.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/dlls/xmllite/reader.c b/dlls/xmllite/reader.c > index 1e3c7aa..f99ea66 100644 > --- a/dlls/xmllite/reader.c > +++ b/dlls/xmllite/reader.c > @@ -85,6 +85,7 @@ typedef enum > > static const WCHAR utf16W[] = {'U','T','F','-','1','6',0}; > static const WCHAR utf8W[] = {'U','T','F','-','8',0}; > +static const WCHAR unknownW[] = {'U','n','k','n','o','w','n',0}; > > static const WCHAR dblquoteW[] = {'\"',0}; > static const WCHAR quoteW[] = {'\'',0}; > @@ -151,8 +152,9 @@ struct xml_encoding_data > }; > > static const struct xml_encoding_data xml_encoding_map[] = { > - { utf16W, XmlEncoding_UTF16, ~0 }, > - { utf8W, XmlEncoding_UTF8, CP_UTF8 } > + { utf16W, XmlEncoding_UTF16, ~0 }, > + { utf8W, XmlEncoding_UTF8, CP_UTF8 }, > + { unknownW, XmlEncoding_Unknown, ~0 }, > }; > > const WCHAR *get_encoding_name(xml_encoding encoding) > I don't think this fixes anything in a sense of making xmllite more compliant. We probably should just fail at CreateXmlWriterOutputWithEncodingName() and print encoding string that made it fail.

Jan. 31, 2017

Re: [PATCH] regedit: When processing 3.1 ignore any lines that don't begin with HKCR.

by Nikolay Sivov

On 31.01.2017 5:51, Zebediah Figura wrote: > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > programs/regedit/regproc.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/programs/regedit/regproc.c b/programs/regedit/regproc.c > index c055c10..b6de728 100644 > --- a/programs/regedit/regproc.c > +++ b/programs/regedit/regproc.c > @@ -616,8 +616,9 @@ static void processRegEntry31(WCHAR *line) > int res; > > static WCHAR empty[] = {0}; > + static WCHAR hkcr[] = {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0}; > > - if (line[0] == '\0') return; > + if (memcmp(line, hkcr, sizeof(hkcr) - sizeof(WCHAR))) return; > > /* get key name */ > while (line[key_end] && !isspaceW(line[key_end])) key_end++; > Is it guaranteed 'line' is a least that large? Also you can remove terminating 0 from hkcr to avoid sizeof(WCHAR) subtraction.

Jan. 31, 2017

Re: comctl32: Fix some more spec file entries

by André Hentschel

Am 30.01.2017 um 11:32 schrieb Huw Davies: > On Sun, Jan 29, 2017 at 09:58:36PM +0100, André Hentschel wrote: >> Signed-off-by: André Hentschel <nerv(a)dawncrow.de> >> --- >> dlls/comctl32/comctl32.spec | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/dlls/comctl32/comctl32.spec b/dlls/comctl32/comctl32.spec >> index c3e9167..dbfa123 100644 >> --- a/dlls/comctl32/comctl32.spec >> +++ b/dlls/comctl32/comctl32.spec >> @@ -93,7 +93,7 @@ >> 382 stdcall -noname SmoothScrollWindow(ptr) >> 383 stub -noname DoReaderMode >> 384 stdcall -noname SetPathWordBreakProc(ptr long) >> -385 stdcall -ordinal DPA_EnumCallback(long long ptr) >> +385 stdcall -ordinal DPA_EnumCallback(long ptr ptr) > > Should be: > 385 stdcall -ordinal DPA_EnumCallback(ptr ptr ptr) > > Huw. > True, thx! The reason is that I'm currently ignoring handles as we don't have a clear rule for them, and as the first parameter type begins with an H, my script thought it is a handle and ignored it...

Jan. 30, 2017

Re: wine/test.h: Identify test result lines printed by child processes.

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > Currently the child process result lines are indistinguishable from the > main process one. This makes it impossible to automatically detect > when a process exits abruptly, i.e. without printing a result line, > if it has run a subprocess. By making the subprocess result lines > different analysis tools will detect that the main result line is > missing and automatically consider that the main process crashed, > thus marking the test as failed. > > Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com> > --- > > This should fix bug 32354: > https://bugs.winehq.org/show_bug.cgi?id=32354 I don't think the test framework should be modifying the environment in all the tests. It already breaks some things: ../../../tools/runtest -q -P wine -T ../../.. -M msvcrt.dll -p msvcrt_test.exe.so environ && touch environ.ok environ.c:198: Test failed: Expected environment block pointer element to be non-NULL wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed2a986 (thread 0074), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

Jan. 30, 2017

Re: Re: [PATCH 05/10] wined3d: Add compute shaders cb/samplers state updates.

by Józef Kucia

On Mon, Jan 30, 2017 at 5:26 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Thank you for your feedback. > WineD3D/D3D11/OpenGL are complex APIs with lots of tricky details. > I know my implementation is far from perfect, but it seems that you learn > better by working, trying, so I do. > I have a basic but (likely) working tessellation implementation and I'll > submit it soon. But it's quite dirty, so I expect feedbacks to improve it > (if you haven't done it locally yet). Sure, a tessellation shaders implementation would be welcome. I haven't done much work on tessellation shaders, just some hacks to run a very basic tessellation shaders. I think that it might be a good idea to implement stream output/transform feedback first. Stream output should make writing tests for tessellation shaders so much easier. Basic support for stream output should also be easier to implement than tessellation shaders. > > Btw, I think you should write down somewhere who is currently working on > what at Crossover, to avoid useless duplicated work. This could be improved, but the truth is that we do not have much contributions to wined3d besides the work of core wined3d team. You can always write to wine-devel that you are interested in implementing a particular feature.

Jan. 30, 2017

Re: comctl32: Correctly set the colour table for ILC_COLOR4 and ILC_COLOR8 imagelists.

by Huw Davies

On 30 Jan 2017, at 16:38, Marvin <testbot(a)winehq.org> wrote: > 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=28138 Yes, sorry about the noise. It seems that older versions of Windows don’t implicitly set the colour table from the added bitmap. I’ll work on another version. Huw.

Jan. 30, 2017

Re: [PATCH 05/10] wined3d: Add compute shaders cb/samplers state updates.

by Guillaume Charifi

I meant Codeweavers.

Jan. 30, 2017

Re: comctl32: Correctly set the colour table for ILC_COLOR4 and ILC_COLOR8 imagelists.

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=28138 Your paranoid android. === wxppro (32 bit imagelist) === imagelist.c:2057: Test failed: 4: remove all, add 8: got color[0] 00 00 00 expect ff 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[1] 80 00 00 expect 00 ff 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[2] 00 80 00 expect 00 00 ff imagelist.c:2057: Test failed: 4: remove all, add 8: got color[3] 80 80 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[4] 00 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[5] 80 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[6] 00 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[7] c0 c0 c0 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[8] 80 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[9] ff 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[10] 00 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[11] ff ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[12] 00 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[13] ff 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[14] 00 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[15] ff ff ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[0] 00 00 00 expect ff 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[1] 80 00 00 expect 00 ff 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[2] 00 80 00 expect 00 00 ff imagelist.c:2057: Test failed: 4: remove all, add 4: got color[3] 80 80 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[4] 00 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[5] 80 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[6] 00 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[7] c0 c0 c0 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[8] 80 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[9] ff 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[10] 00 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[11] ff ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[12] 00 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[13] ff 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[14] 00 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[15] ff ff ff expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[0] 00 00 00 expect ff 00 ff imagelist.c:2057: Test failed: 4: add 4: got color[1] 80 00 00 expect ff ff 00 imagelist.c:2057: Test failed: 4: add 4: got color[2] 00 80 00 expect 00 ff ff imagelist.c:2057: Test failed: 4: add 4: got color[3] 80 80 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[4] 00 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[5] 80 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[6] 00 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[7] c0 c0 c0 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[8] 80 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[9] ff 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[10] 00 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[11] ff ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[12] 00 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[13] ff 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[14] 00 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[15] ff ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[0] 00 00 00 expect ff 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[1] 80 00 00 expect 00 ff 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[2] 00 80 00 expect 00 00 ff imagelist.c:2057: Test failed: 8: remove all, add 8: got color[3] 80 80 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[4] 00 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[5] 80 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[6] 00 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[7] c0 c0 c0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[8] c0 dc c0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[9] a6 ca f0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[10] 00 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[11] 33 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[12] 33 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[13] 00 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[14] 16 16 16 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[15] 1c 1c 1c expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[16] 22 22 22 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[17] 29 29 29 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[18] 55 55 55 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[19] 4d 4d 4d expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[20] 42 42 42 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[21] 39 39 39 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[22] ff 7c 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[23] ff 50 50 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[24] d6 00 93 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[25] cc ec ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[26] ef d6 c6 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[27] e7 e7 d6 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[28] ad a9 90 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[29] 33 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[30] 66 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[31] 99 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[32] cc 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[33] 00 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[34] 33 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[35] 66 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[36] 99 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[37] cc 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[38] ff 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[39] 00 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[40] 33 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[41] 66 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[42] 99 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[43] cc 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[44] ff 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[45] 00 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[46] 33 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[47] 66 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[48] 99 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[49] cc 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[50] ff 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[51] 00 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[52] 33 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[53] 66 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[54] 99 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[55] cc cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[56] ff cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[57] 66 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[58] 99 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[59] cc ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[60] 00 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[61] 33 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[62] 66 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[63] 99 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[64] cc 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[65] ff 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[66] 00 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[67] 33 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[68] 66 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[69] 99 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[70] cc 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[71] ff 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[72] 00 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[73] 33 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[74] 66 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[75] 99 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[76] cc 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[77] ff 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[78] 00 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[79] 33 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[80] 66 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[81] 99 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[82] cc 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[83] ff 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[84] 00 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[85] 33 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[86] 66 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[87] 99 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[88] cc cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[89] ff cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[90] 33 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[91] 66 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[92] 99 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[93] cc ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[94] ff ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[95] 00 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[96] 33 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[97] 66 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[98] 99 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[99] cc 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[100] ff 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[101] 00 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[102] 33 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[103] 66 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[104] 99 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[105] cc 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[106] ff 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[107] 00 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[108] 33 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[109] 66 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[110] 99 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[111] cc 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[112] 00 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[113] 33 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[114] 66 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[115] 99 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[116] cc 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[117] ff 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[118] 00 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[119] 33 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[120] 99 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[121] cc cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[122] ff cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[123] 00 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[124] 33 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[125] 99 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[126] cc ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[127] ff 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[128] cc 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[129] 00 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[130] 99 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[131] 99 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[132] cc 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[133] 00 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[134] 33 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[135] 66 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[136] cc 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[137] ff 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[138] 00 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[139] 33 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[140] 66 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[141] 99 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[142] cc 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[143] ff 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[144] 33 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[145] 66 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[146] 99 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[147] cc 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[148] ff 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[149] 00 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[150] 33 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[151] 66 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[152] 99 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[153] cc cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[154] ff cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[155] 00 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[156] 33 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[157] 66 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[158] 99 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[159] cc ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[160] ff ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[161] 00 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[162] 33 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[163] 66 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[164] 99 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[165] cc 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[166] 00 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[167] 33 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[168] 66 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[169] 99 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[170] cc 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[171] ff 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[172] 00 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[173] 33 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[174] 66 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[175] 99 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[176] cc 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[177] ff 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[178] 00 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[179] 33 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[180] 66 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[181] 99 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[182] cc 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[183] ff 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[184] 00 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[185] 33 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[186] 66 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[187] 99 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[188] cc cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[189] ff cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[190] 00 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[191] 33 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[192] 66 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[193] 99 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[194] cc ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[195] ff ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[196] 33 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[197] 66 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[198] 99 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[199] 00 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[200] 33 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[201] 66 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[202] 99 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[203] cc 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[204] ff 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[205] 00 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[206] 33 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[207] 66 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[208] 99 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[209] cc 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[210] ff 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[211] 00 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[212] 33 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[213] 66 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[214] 99 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[215] cc 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[216] ff 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[217] 00 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[218] 33 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[219] 66 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[220] 99 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[221] cc cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[222] ff cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[223] 33 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[224] 66 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[225] 99 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[226] cc ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[227] ff 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[228] 66 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[229] ff ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[230] 66 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[231] ff 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[232] 66 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[233] a5 00 21 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[234] 5f 5f 5f expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[235] 77 77 77 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[236] 86 86 86 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[237] 96 96 96 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[238] cb cb cb expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[239] b2 b2 b2 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[240] d7 d7 d7 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[241] dd dd dd expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[242] e3 e3 e3 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[243] ea ea ea expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[244] f1 f1 f1 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[245] f8 f8 f8 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[246] ff fb f0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[247] a0 a0 a4 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[248] 80 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[249] ff 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[250] 00 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[251] ff ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[252] 00 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[253] ff 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[254] 00 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[255] ff ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[0] 00 00 00 expect ff 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[1] 80 00 00 expect 00 ff 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[2] 00 80 00 expect 00 00 ff imagelist.c:2057: Test failed: 8: remove all, add 4: got color[3] 80 80 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[4] 00 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[5] 80 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[6] 00 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[7] c0 c0 c0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[8] c0 dc c0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[9] a6 ca f0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[10] 00 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[11] 33 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[12] 33 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[13] 00 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[14] 16 16 16 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[15] 1c 1c 1c expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[16] 22 22 22 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[17] 29 29 29 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[18] 55 55 55 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[19] 4d 4d 4d expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[20] 42 42 42 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[21] 39 39 39 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[22] ff 7c 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[23] ff 50 50 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[24] d6 00 93 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[25] cc ec ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[26] ef d6 c6 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[27] e7 e7 d6 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[28] ad a9 90 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[29] 33 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[30] 66 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[31] 99 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[32] cc 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[33] 00 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[34] 33 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[35] 66 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[36] 99 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[37] cc 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[38] ff 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[39] 00 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[40] 33 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[41] 66 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[42] 99 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[43] cc 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[44] ff 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[45] 00 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[46] 33 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[47] 66 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[48] 99 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[49] cc 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[50] ff 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[51] 00 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[52] 33 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[53] 66 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[54] 99 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[55] cc cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[56] ff cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[57] 66 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[58] 99 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[59] cc ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[60] 00 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[61] 33 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[62] 66 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[63] 99 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[64] cc 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[65] ff 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[66] 00 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[67] 33 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[68] 66 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[69] 99 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[70] cc 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[71] ff 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[72] 00 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[73] 33 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[74] 66 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[75] 99 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[76] cc 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[77] ff 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[78] 00 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[79] 33 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[80] 66 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[81] 99 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[82] cc 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[83] ff 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[84] 00 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[85] 33 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[86] 66 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[87] 99 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[88] cc cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[89] ff cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[90] 33 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[91] 66 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[92] 99 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[93] cc ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[94] ff ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[95] 00 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[96] 33 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[97] 66 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[98] 99 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[99] cc 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[100] ff 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[101] 00 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[102] 33 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[103] 66 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[104] 99 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[105] cc 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[106] ff 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[107] 00 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[108] 33 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[109] 66 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[110] 99 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[111] cc 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[112] 00 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[113] 33 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[114] 66 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[115] 99 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[116] cc 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[117] ff 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[118] 00 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[119] 33 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[120] 99 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[121] cc cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[122] ff cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[123] 00 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[124] 33 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[125] 99 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[126] cc ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[127] ff 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[128] cc 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[129] 00 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[130] 99 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[131] 99 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[132] cc 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[133] 00 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[134] 33 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[135] 66 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[136] cc 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[137] ff 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[138] 00 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[139] 33 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[140] 66 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[141] 99 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[142] cc 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[143] ff 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[144] 33 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[145] 66 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[146] 99 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[147] cc 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[148] ff 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[149] 00 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[150] 33 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[151] 66 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[152] 99 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[153] cc cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[154] ff cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[155] 00 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[156] 33 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[157] 66 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[158] 99 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[159] cc ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[160] ff ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[161] 00 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[162] 33 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[163] 66 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[164] 99 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[165] cc 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[166] 00 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[167] 33 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[168] 66 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[169] 99 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[170] cc 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[171] ff 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[172] 00 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[173] 33 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[174] 66 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[175] 99 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[176] cc 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[177] ff 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[178] 00 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[179] 33 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[180] 66 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[181] 99 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[182] cc 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[183] ff 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[184] 00 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[185] 33 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[186] 66 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[187] 99 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[188] cc cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[189] ff cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[190] 00 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[191] 33 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[192] 66 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[193] 99 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[194] cc ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[195] ff ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[196] 33 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[197] 66 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[198] 99 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[199] 00 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[200] 33 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[201] 66 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[202] 99 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[203] cc 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[204] ff 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[205] 00 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[206] 33 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[207] 66 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[208] 99 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[209] cc 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[210] ff 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[211] 00 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[212] 33 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[213] 66 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[214] 99 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[215] cc 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[216] ff 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[217] 00 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[218] 33 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[219] 66 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[220] 99 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[221] cc cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[222] ff cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[223] 33 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[224] 66 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[225] 99 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[226] cc ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[227] ff 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[228] 66 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[229] ff ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[230] 66 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[231] ff 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[232] 66 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[233] a5 00 21 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[234] 5f 5f 5f expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[235] 77 77 77 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[236] 86 86 86 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[237] 96 96 96 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[238] cb cb cb expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[239] b2 b2 b2 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[240] d7 d7 d7 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[241] dd dd dd expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[242] e3 e3 e3 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[243] ea ea ea expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[244] f1 f1 f1 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[245] f8 f8 f8 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[246] ff fb f0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[247] a0 a0 a4 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[248] 80 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[249] ff 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[250] 00 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[251] ff ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[252] 00 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[253] ff 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[254] 00 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[255] ff ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[0] 00 00 00 expect ff 00 ff imagelist.c:2057: Test failed: 8: add 4: got color[1] 80 00 00 expect ff ff 00 imagelist.c:2057: Test failed: 8: add 4: got color[2] 00 80 00 expect 00 ff ff imagelist.c:2057: Test failed: 8: add 4: got color[3] 80 80 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[4] 00 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[5] 80 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[6] 00 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[7] c0 c0 c0 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[8] c0 dc c0 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[9] a6 ca f0 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[10] 00 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[11] 33 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[12] 33 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[13] 00 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[14] 16 16 16 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[15] 1c 1c 1c expect 00 00 00 === w2003std (32 bit imagelist) === imagelist.c:2057: Test failed: 4: remove all, add 8: got color[0] 00 00 00 expect ff 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[1] 80 00 00 expect 00 ff 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[2] 00 80 00 expect 00 00 ff imagelist.c:2057: Test failed: 4: remove all, add 8: got color[3] 80 80 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[4] 00 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[5] 80 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[6] 00 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[7] c0 c0 c0 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[8] 80 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[9] ff 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[10] 00 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[11] ff ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[12] 00 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[13] ff 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[14] 00 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 8: got color[15] ff ff ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[0] 00 00 00 expect ff 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[1] 80 00 00 expect 00 ff 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[2] 00 80 00 expect 00 00 ff imagelist.c:2057: Test failed: 4: remove all, add 4: got color[3] 80 80 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[4] 00 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[5] 80 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[6] 00 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[7] c0 c0 c0 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[8] 80 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[9] ff 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[10] 00 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[11] ff ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[12] 00 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[13] ff 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[14] 00 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 4: remove all, add 4: got color[15] ff ff ff expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[0] 00 00 00 expect ff 00 ff imagelist.c:2057: Test failed: 4: add 4: got color[1] 80 00 00 expect ff ff 00 imagelist.c:2057: Test failed: 4: add 4: got color[2] 00 80 00 expect 00 ff ff imagelist.c:2057: Test failed: 4: add 4: got color[3] 80 80 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[4] 00 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[5] 80 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[6] 00 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[7] c0 c0 c0 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[8] 80 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[9] ff 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[10] 00 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[11] ff ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[12] 00 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[13] ff 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[14] 00 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 4: add 4: got color[15] ff ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[0] 00 00 00 expect ff 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[1] 80 00 00 expect 00 ff 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[2] 00 80 00 expect 00 00 ff imagelist.c:2057: Test failed: 8: remove all, add 8: got color[3] 80 80 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[4] 00 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[5] 80 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[6] 00 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[7] c0 c0 c0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[8] c0 dc c0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[9] a6 ca f0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[10] 00 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[11] 33 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[12] 33 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[13] 00 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[14] 16 16 16 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[15] 1c 1c 1c expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[16] 22 22 22 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[17] 29 29 29 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[18] 55 55 55 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[19] 4d 4d 4d expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[20] 42 42 42 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[21] 39 39 39 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[22] ff 7c 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[23] ff 50 50 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[24] d6 00 93 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[25] cc ec ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[26] ef d6 c6 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[27] e7 e7 d6 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[28] ad a9 90 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[29] 33 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[30] 66 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[31] 99 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[32] cc 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[33] 00 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[34] 33 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[35] 66 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[36] 99 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[37] cc 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[38] ff 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[39] 00 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[40] 33 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[41] 66 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[42] 99 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[43] cc 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[44] ff 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[45] 00 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[46] 33 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[47] 66 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[48] 99 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[49] cc 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[50] ff 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[51] 00 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[52] 33 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[53] 66 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[54] 99 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[55] cc cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[56] ff cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[57] 66 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[58] 99 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[59] cc ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[60] 00 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[61] 33 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[62] 66 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[63] 99 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[64] cc 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[65] ff 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[66] 00 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[67] 33 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[68] 66 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[69] 99 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[70] cc 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[71] ff 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[72] 00 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[73] 33 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[74] 66 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[75] 99 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[76] cc 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[77] ff 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[78] 00 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[79] 33 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[80] 66 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[81] 99 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[82] cc 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[83] ff 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[84] 00 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[85] 33 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[86] 66 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[87] 99 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[88] cc cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[89] ff cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[90] 33 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[91] 66 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[92] 99 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[93] cc ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[94] ff ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[95] 00 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[96] 33 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[97] 66 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[98] 99 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[99] cc 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[100] ff 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[101] 00 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[102] 33 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[103] 66 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[104] 99 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[105] cc 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[106] ff 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[107] 00 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[108] 33 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[109] 66 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[110] 99 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[111] cc 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[112] 00 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[113] 33 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[114] 66 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[115] 99 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[116] cc 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[117] ff 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[118] 00 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[119] 33 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[120] 99 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[121] cc cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[122] ff cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[123] 00 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[124] 33 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[125] 99 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[126] cc ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[127] ff 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[128] cc 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[129] 00 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[130] 99 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[131] 99 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[132] cc 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[133] 00 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[134] 33 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[135] 66 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[136] cc 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[137] ff 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[138] 00 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[139] 33 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[140] 66 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[141] 99 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[142] cc 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[143] ff 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[144] 33 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[145] 66 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[146] 99 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[147] cc 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[148] ff 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[149] 00 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[150] 33 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[151] 66 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[152] 99 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[153] cc cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[154] ff cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[155] 00 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[156] 33 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[157] 66 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[158] 99 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[159] cc ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[160] ff ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[161] 00 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[162] 33 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[163] 66 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[164] 99 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[165] cc 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[166] 00 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[167] 33 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[168] 66 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[169] 99 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[170] cc 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[171] ff 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[172] 00 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[173] 33 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[174] 66 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[175] 99 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[176] cc 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[177] ff 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[178] 00 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[179] 33 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[180] 66 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[181] 99 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[182] cc 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[183] ff 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[184] 00 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[185] 33 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[186] 66 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[187] 99 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[188] cc cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[189] ff cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[190] 00 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[191] 33 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[192] 66 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[193] 99 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[194] cc ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[195] ff ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[196] 33 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[197] 66 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[198] 99 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[199] 00 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[200] 33 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[201] 66 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[202] 99 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[203] cc 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[204] ff 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[205] 00 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[206] 33 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[207] 66 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[208] 99 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[209] cc 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[210] ff 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[211] 00 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[212] 33 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[213] 66 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[214] 99 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[215] cc 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[216] ff 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[217] 00 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[218] 33 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[219] 66 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[220] 99 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[221] cc cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[222] ff cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[223] 33 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[224] 66 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[225] 99 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[226] cc ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[227] ff 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[228] 66 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[229] ff ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[230] 66 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[231] ff 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[232] 66 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[233] a5 00 21 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[234] 5f 5f 5f expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[235] 77 77 77 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[236] 86 86 86 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[237] 96 96 96 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[238] cb cb cb expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[239] b2 b2 b2 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[240] d7 d7 d7 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[241] dd dd dd expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[242] e3 e3 e3 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[243] ea ea ea expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[244] f1 f1 f1 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[245] f8 f8 f8 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[246] ff fb f0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[247] a0 a0 a4 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[248] 80 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[249] ff 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[250] 00 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[251] ff ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[252] 00 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[253] ff 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[254] 00 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 8: got color[255] ff ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[0] 00 00 00 expect ff 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[1] 80 00 00 expect 00 ff 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[2] 00 80 00 expect 00 00 ff imagelist.c:2057: Test failed: 8: remove all, add 4: got color[3] 80 80 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[4] 00 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[5] 80 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[6] 00 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[7] c0 c0 c0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[8] c0 dc c0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[9] a6 ca f0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[10] 00 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[11] 33 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[12] 33 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[13] 00 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[14] 16 16 16 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[15] 1c 1c 1c expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[16] 22 22 22 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[17] 29 29 29 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[18] 55 55 55 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[19] 4d 4d 4d expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[20] 42 42 42 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[21] 39 39 39 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[22] ff 7c 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[23] ff 50 50 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[24] d6 00 93 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[25] cc ec ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[26] ef d6 c6 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[27] e7 e7 d6 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[28] ad a9 90 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[29] 33 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[30] 66 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[31] 99 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[32] cc 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[33] 00 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[34] 33 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[35] 66 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[36] 99 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[37] cc 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[38] ff 33 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[39] 00 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[40] 33 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[41] 66 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[42] 99 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[43] cc 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[44] ff 66 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[45] 00 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[46] 33 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[47] 66 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[48] 99 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[49] cc 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[50] ff 99 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[51] 00 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[52] 33 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[53] 66 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[54] 99 cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[55] cc cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[56] ff cc 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[57] 66 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[58] 99 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[59] cc ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[60] 00 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[61] 33 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[62] 66 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[63] 99 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[64] cc 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[65] ff 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[66] 00 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[67] 33 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[68] 66 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[69] 99 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[70] cc 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[71] ff 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[72] 00 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[73] 33 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[74] 66 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[75] 99 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[76] cc 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[77] ff 66 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[78] 00 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[79] 33 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[80] 66 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[81] 99 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[82] cc 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[83] ff 99 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[84] 00 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[85] 33 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[86] 66 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[87] 99 cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[88] cc cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[89] ff cc 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[90] 33 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[91] 66 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[92] 99 ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[93] cc ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[94] ff ff 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[95] 00 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[96] 33 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[97] 66 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[98] 99 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[99] cc 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[100] ff 00 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[101] 00 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[102] 33 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[103] 66 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[104] 99 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[105] cc 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[106] ff 33 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[107] 00 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[108] 33 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[109] 66 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[110] 99 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[111] cc 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[112] 00 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[113] 33 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[114] 66 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[115] 99 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[116] cc 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[117] ff 99 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[118] 00 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[119] 33 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[120] 99 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[121] cc cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[122] ff cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[123] 00 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[124] 33 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[125] 99 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[126] cc ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[127] ff 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[128] cc 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[129] 00 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[130] 99 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[131] 99 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[132] cc 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[133] 00 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[134] 33 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[135] 66 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[136] cc 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[137] ff 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[138] 00 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[139] 33 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[140] 66 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[141] 99 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[142] cc 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[143] ff 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[144] 33 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[145] 66 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[146] 99 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[147] cc 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[148] ff 99 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[149] 00 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[150] 33 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[151] 66 cc 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[152] 99 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[153] cc cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[154] ff cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[155] 00 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[156] 33 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[157] 66 cc 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[158] 99 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[159] cc ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[160] ff ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[161] 00 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[162] 33 00 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[163] 66 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[164] 99 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[165] cc 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[166] 00 33 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[167] 33 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[168] 66 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[169] 99 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[170] cc 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[171] ff 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[172] 00 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[173] 33 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[174] 66 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[175] 99 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[176] cc 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[177] ff 66 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[178] 00 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[179] 33 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[180] 66 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[181] 99 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[182] cc 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[183] ff 99 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[184] 00 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[185] 33 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[186] 66 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[187] 99 cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[188] cc cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[189] ff cc cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[190] 00 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[191] 33 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[192] 66 ff 99 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[193] 99 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[194] cc ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[195] ff ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[196] 33 00 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[197] 66 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[198] 99 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[199] 00 33 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[200] 33 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[201] 66 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[202] 99 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[203] cc 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[204] ff 33 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[205] 00 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[206] 33 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[207] 66 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[208] 99 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[209] cc 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[210] ff 66 cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[211] 00 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[212] 33 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[213] 66 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[214] 99 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[215] cc 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[216] ff 99 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[217] 00 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[218] 33 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[219] 66 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[220] 99 cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[221] cc cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[222] ff cc ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[223] 33 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[224] 66 ff cc expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[225] 99 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[226] cc ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[227] ff 66 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[228] 66 ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[229] ff ff 66 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[230] 66 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[231] ff 66 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[232] 66 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[233] a5 00 21 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[234] 5f 5f 5f expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[235] 77 77 77 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[236] 86 86 86 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[237] 96 96 96 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[238] cb cb cb expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[239] b2 b2 b2 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[240] d7 d7 d7 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[241] dd dd dd expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[242] e3 e3 e3 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[243] ea ea ea expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[244] f1 f1 f1 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[245] f8 f8 f8 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[246] ff fb f0 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[247] a0 a0 a4 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[248] 80 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[249] ff 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[250] 00 ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[251] ff ff 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[252] 00 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[253] ff 00 ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[254] 00 ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: remove all, add 4: got color[255] ff ff ff expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[0] 00 00 00 expect ff 00 ff imagelist.c:2057: Test failed: 8: add 4: got color[1] 80 00 00 expect ff ff 00 imagelist.c:2057: Test failed: 8: add 4: got color[2] 00 80 00 expect 00 ff ff imagelist.c:2057: Test failed: 8: add 4: got color[3] 80 80 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[4] 00 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[5] 80 00 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[6] 00 80 80 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[7] c0 c0 c0 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[8] c0 dc c0 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[9] a6 ca f0 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[10] 00 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[11] 33 00 00 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[12] 33 00 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[13] 00 33 33 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[14] 16 16 16 expect 00 00 00 imagelist.c:2057: Test failed: 8: add 4: got color[15] 1c 1c 1c expect 00 00 00

Jan. 30, 2017

Re: [PATCH 05/10] wined3d: Add compute shaders cb/samplers state updates.

by Guillaume Charifi

Thank you for your feedback. WineD3D/D3D11/OpenGL are complex APIs with lots of tricky details. I know my implementation is far from perfect, but it seems that you learn better by working, trying, so I do. I have a basic but (likely) working tessellation implementation and I'll submit it soon. But it's quite dirty, so I expect feedbacks to improve it (if you haven't done it locally yet). Btw, I think you should write down somewhere who is currently working on what at Crossover, to avoid useless duplicated work. <div>-------- Message d'origine --------</div><div>De : Józef Kucia <joseph.kucia(a)gmail.com> </div><div>Date :30/01/2017 14:13 (GMT+01:00) </div><div>À : wine-devel <wine-devel(a)winehq.org> </div><div>Cc : Guillaume Charifi <guillaume.charifi(a)sfr.fr> </div><div>Objet : Re: [PATCH 05/10] wined3d: Add compute shaders cb/samplers state updates. </div><div> </div>FWIW, I have a patch series adding basic support for compute shaders in my patch queue. I should start submitting the series when my SM5 shader instructions series from wine-patches is committed. I've skimmed over your patches though. I'll share some high-level comments. On Sun, Jan 29, 2017 at 2:43 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/context.c | 1 + > dlls/wined3d/state.c | 3 +++ > 2 files changed, 4 insertions(+) > > diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c > index ca73bcc..eaae0b8 100644 > --- a/dlls/wined3d/context.c > +++ b/dlls/wined3d/context.c > @@ -3382,6 +3382,7 @@ static void context_bind_shader_resources(struct wined3d_context *context, const > { > {WINED3D_SHADER_TYPE_PIXEL, 0, MAX_FRAGMENT_SAMPLERS}, > {WINED3D_SHADER_TYPE_VERTEX, MAX_FRAGMENT_SAMPLERS, MAX_VERTEX_SAMPLERS}, > + {WINED3D_SHADER_TYPE_COMPUTE, 0, MAX_COMPUTE_SAMPLERS}, > }; I don't think that adding a proper support for binding compute shader resources is that simple.

Jan. 30, 2017

Re: [PATCH v2] user32: Also remove WM_CHAR from queue when a menu gets VK_ESCAPE and add tests

by Fabian Maurer

> TranslateMessage will put a WM_CHAR in the queue, but there may be > another one already in there, which would then get removed. Right, I missed that. Thanks, I sent a corrected version. Regards, Fabian Maurer

Jan. 30, 2017

Re: [PATCH resend 1/2] user32: Fix WM_NCPAINT for windows crossing screen boarders and add tests

by Fabian Maurer

> This won't be correct for multi-monitor setups. That sort of thing > should probably be handled on the server side. You're right, we should take care of that, too. Sadly, I don't have a multi monitor setup to run tests with. An idea how to still work on this? Regards, Fabian Maurer

Jan. 30, 2017

Re: [PATCH v2] user32: Also remove WM_CHAR from queue when a menu gets VK_ESCAPE and add tests

by Alexandre Julliard

Fabian Maurer <dark.shadow4(a)web.de> writes: >> It would be cleaner to avoid TranslateMessage instead of removing the >> message (possibly getting the wrong one). > > Sorry, I don't really see the problem. TranslateMessage should always generate > a WM_CHAR, how could we get a wrong message? Shouldn't be possible, except for > a bug in TranslateMessage, or I'm missing something. TranslateMessage will put a WM_CHAR in the queue, but there may be another one already in there, which would then get removed. -- Alexandre Julliard julliard(a)winehq.org

Jan. 30, 2017

Re: [PATCH v2] user32: Also remove WM_CHAR from queue when a menu gets VK_ESCAPE and add tests

by Fabian Maurer

> It would be cleaner to avoid TranslateMessage instead of removing the > message (possibly getting the wrong one). Sorry, I don't really see the problem. TranslateMessage should always generate a WM_CHAR, how could we get a wrong message? Shouldn't be possible, except for a bug in TranslateMessage, or I'm missing something. I could check for message/wParam to skip TranslateMessage, but I found it cleaner to put it into the handler for VK_ESCAPE. Regards, Fabian Maurer

Jan. 30, 2017

Re: [PATCH 06/10] wined3d: Add compute shaders initial support in GLSL backend.

by Józef Kucia

On Sun, Jan 29, 2017 at 2:43 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > - if (!(context->shader_update_mask & (1u << WINED3D_SHADER_TYPE_VERTEX)) && ctx_data->glsl_program) > + cshader = state->shader[WINED3D_SHADER_TYPE_COMPUTE]; > + if (!(context->shader_update_mask & (1u << WINED3D_SHADER_TYPE_COMPUTE)) > + && ctx_data->glsl_program->cs.id) > { > - vs_id = ctx_data->glsl_program->vs.id; > - vs_list = &ctx_data->glsl_program->vs.shader_entry; > + cs_id = ctx_data->glsl_program->cs.id; > + } > + else if (cshader) > + { > + struct cs_compile_args args; > > - if (use_vs(state)) > + find_cs_compile_args(state, cshader, &args); > + cs_id = find_glsl_compute_shader(context, priv, cshader, &args); > + } > + > + if(!cs_id) > + { > + if (!(context->shader_update_mask & (1u << WINED3D_SHADER_TYPE_VERTEX)) && ctx_data->glsl_program) > + { > + vs_id = ctx_data->glsl_program->vs.id; > + vs_list = &ctx_data->glsl_program->vs.shader_entry; > + > + if (use_vs(state)) > + vshader = state->shader[WINED3D_SHADER_TYPE_VERTEX]; > + } > + else if (use_vs(state)) > { > + struct vs_compile_args vs_compile_args; > + > vshader = state->shader[WINED3D_SHADER_TYPE_VERTEX]; > + > + find_vs_compile_args(state, vshader, context->stream_info.swizzle_map, &vs_compile_args, d3d_info); > + vs_id = find_glsl_vshader(context, priv, vshader, &vs_compile_args); > + vs_list = &vshader->linked_programs; > + } > + else if (priv->vertex_pipe == &glsl_vertex_pipe) > + { > + struct glsl_ffp_vertex_shader *ffp_shader; > + struct wined3d_ffp_vs_settings settings; > + > + wined3d_ffp_get_vs_settings(context, state, &settings); > + ffp_shader = shader_glsl_find_ffp_vertex_shader(priv, gl_info, &settings); > + vs_id = ffp_shader->id; > + vs_list = &ffp_shader->linked_programs; > + } > + > + if (use_vs(state)) > + { It doesn't seem reasonable to create a GL program for each combination of graphics pipeline and compute pipeline shaders. A single GL program for each compute shader is enough.

Jan. 30, 2017

Re: [PATCH 07/10] wined3d: Add dispatch_compute() draw primitive.

by Józef Kucia

On Sun, Jan 29, 2017 at 2:43 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > + if (!context_apply_draw_state(context, device, state)) > + { > + context_release(context); > + WARN("Unable to apply draw state, skipping draw.\n"); > + return; > + } I don't think it makes sense to apply all states for compute pipeline. Note that graphics pipeline and compute pipeline have separate UAV bindings.

Jan. 30, 2017

Re: [PATCH 08/10] wined3d: Dispatch compute through the command stream.

by Józef Kucia

On Sun, Jan 29, 2017 at 2:43 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > + for (i = 0; i < ARRAY_SIZE(state->streams); ++i) > + { > + if (state->streams[i].buffer) > + wined3d_resource_acquire(&state->streams[i].buffer->resource); > + } > + for (i = 0; i < ARRAY_SIZE(state->textures); ++i) > + { > + if (state->textures[i]) > + wined3d_resource_acquire(&state->textures[i]->resource); > + } Streams and textures are not supposed to be used by compute pipeline.

Jan. 30, 2017

Re: [PATCH 05/10] wined3d: Add compute shaders cb/samplers state updates.

by Józef Kucia

FWIW, I have a patch series adding basic support for compute shaders in my patch queue. I should start submitting the series when my SM5 shader instructions series from wine-patches is committed. I've skimmed over your patches though. I'll share some high-level comments. On Sun, Jan 29, 2017 at 2:43 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/context.c | 1 + > dlls/wined3d/state.c | 3 +++ > 2 files changed, 4 insertions(+) > > diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c > index ca73bcc..eaae0b8 100644 > --- a/dlls/wined3d/context.c > +++ b/dlls/wined3d/context.c > @@ -3382,6 +3382,7 @@ static void context_bind_shader_resources(struct wined3d_context *context, const > { > {WINED3D_SHADER_TYPE_PIXEL, 0, MAX_FRAGMENT_SAMPLERS}, > {WINED3D_SHADER_TYPE_VERTEX, MAX_FRAGMENT_SAMPLERS, MAX_VERTEX_SAMPLERS}, > + {WINED3D_SHADER_TYPE_COMPUTE, 0, MAX_COMPUTE_SAMPLERS}, > }; I don't think that adding a proper support for binding compute shader resources is that simple.

Jan. 30, 2017

Re: [PATCH 1/3] wined3d: Add some missing state updates for buffer textures.

by Henri Verbeet

On 29 January 2017 at 03:32, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > > --- > dlls/wined3d/context.c | 12 ++++++++++++ > dlls/wined3d/state.c | 5 +++++ > dlls/wined3d/view.c | 6 ------ > 3 files changed, 17 insertions(+), 6 deletions(-) > These patches are incredibly unappealing to review. There are multiple versions of multiple interleaved series, with html and other errors mixed in. (See e.g. https://source.winehq.org/patches/data/129296.) Please only send a reasonable number of patches at once, I'd suggest sticking with 5, and please use git send-email for sending patches.

Jan. 30, 2017

Re: [PATCH resend 1/2] user32: Fix WM_NCPAINT for windows crossing screen boarders and add tests

by Alexandre Julliard

Fabian Maurer <dark.shadow4(a)web.de> writes: > @@ -662,7 +662,17 @@ static HRGN send_ncpaint( HWND hwnd, HWND *child, UINT *flags ) > if (type == SIMPLEREGION) > { > RECT window; > + LONG screenx = GetSystemMetrics(SM_CXSCREEN); > + LONG screeny = GetSystemMetrics(SM_CYSCREEN); > + > GetWindowRect( hwnd, &window ); > + > + /* Clamp the window region to screen bounds */ > + if(window.right > screenx) window.right = screenx; > + if(window.bottom > screeny) window.bottom = screeny; > + if(window.left < 0) window.left = 0; > + if(window.top < 0) window.top = 0; This won't be correct for multi-monitor setups. That sort of thing should probably be handled on the server side. -- Alexandre Julliard julliard(a)winehq.org

Jan. 30, 2017

Re: [PATCH v2] user32: Also remove WM_CHAR from queue when a menu gets VK_ESCAPE and add tests

by Alexandre Julliard

Fabian Maurer <dark.shadow4(a)web.de> writes: > @@ -3186,8 +3186,12 @@ static BOOL MENU_TrackMenu( HMENU hmenu, UINT wFlags, INT x, INT y, > break; > > case VK_ESCAPE: > + { > + MSG msg_dummy; > fEndMenu = MENU_KeyEscape(&mt, wFlags); > - break; > + PeekMessageW(&msg_dummy, 0, WM_CHAR, WM_CHAR, PM_REMOVE); > + break; > + } It would be cleaner to avoid TranslateMessage instead of removing the message (possibly getting the wrong one). -- Alexandre Julliard julliard(a)winehq.org

Jan. 30, 2017

Re: comctl32: Fix some more spec file entries

by Huw Davies

On Sun, Jan 29, 2017 at 09:58:36PM +0100, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/comctl32/comctl32.spec | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/comctl32/comctl32.spec b/dlls/comctl32/comctl32.spec > index c3e9167..dbfa123 100644 > --- a/dlls/comctl32/comctl32.spec > +++ b/dlls/comctl32/comctl32.spec > @@ -93,7 +93,7 @@ > 382 stdcall -noname SmoothScrollWindow(ptr) > 383 stub -noname DoReaderMode > 384 stdcall -noname SetPathWordBreakProc(ptr long) > -385 stdcall -ordinal DPA_EnumCallback(long long ptr) > +385 stdcall -ordinal DPA_EnumCallback(long ptr ptr) Should be: 385 stdcall -ordinal DPA_EnumCallback(ptr ptr ptr) Huw.

Jan. 30, 2017

Re: patches: Display multiple check marks for multiple signoffs.

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > On Sun, Jan 29, 2017 at 6:51 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: >>> The patch is definitly an improvement, but the problem with the patch is, that right now I can't see that my patch has been signed-off by Aric when looking at it in the patch list >>> ... >>> 129264 New Aric Stewart Re: usp10: Fix ScriptRecordDigitSubstitution spec file entry ✓ >>> ... >>> 129183 Assigned André Hentschel usp10: Fix ScriptRecordDigitSubstitution spec file entry Aric Stewart ✓ >>> ... >>> >>> I think something like that was what Bruno is looking for >> >> It is half-working then, because my patch 129061 is double checked >> because of Andrew's sign 129073. So it is missing some update after >> receiving new sign-offs, I don't know. > > Judging by the current contents of the list I infer that the other > signs are only added after the email is marked as Sign-off type. Yes, the list is not updated in real time. The patch status is pushed out together with the commits. -- Alexandre Julliard julliard(a)winehq.org

Jan. 30, 2017

Re: [PATCH] winbase.h: Add UnlockResource prototype

by Alistair Leslie-Hughes

On 30/01/17 18:55, Dmitry Timoshkov wrote: > Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > >> This function is obsolete and was only used in win16. However when trying >> to compile a project with winelib found this function was called. > > Then you need to add it to an appropriate win16 header, or better remove it > from your project since it won't compile with PSDK either. > This is incorrect. It is part of the current SDK, however its just a defined to nothing. Best Regards Alistair Leslie-Hughes.

Jan. 30, 2017

Re: [PATCH] winbase.h: Add UnlockResource prototype

by Dmitry Timoshkov

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > This function is obsolete and was only used in win16. However when trying > to compile a project with winelib found this function was called. Then you need to add it to an appropriate win16 header, or better remove it from your project since it won't compile with PSDK either. -- Dmitry.

Jan. 30, 2017

Re: [PATCH 1/7] regedit: Use a helper for LoadString() and add debug information

by Dmitry Timoshkov

Hugh McMaster <hugh.mcmaster(a)outlook.com> wrote: > > Probably using a flavour of lstrcpy that checks the target buffer length > > would be more appropriate. Although simply returning an empty buffer and > > an error indicator to the caller could be slightly better. Under which > > conditions LoadString may fail here? > > The buffer size must be at least six WCHARs to allow for errorW, so we could > just do something like if (!buf || count < 6) return; > > In this code, LoadString() could fail if the resource ID doesn't exist > or if count is 0 or 1. But since we are controlling all of the code, none of this > is likely. > > For MessageBox captions, if we pass in NULL, the default string "Error" > is loaded by user32. So, apart from a few instances, we wouldn't have to > handle captions at all. But we would have to do something if LoadString() > failed for the body text, otherwise the user would see a blank message box. > > The original code was: > if (!LoadStringW(hInst, titleId, title, COUNT_OF(title))) lstrcpyW(title, errorW); > if (!LoadStringW(hInst, resId, errfmt, COUNT_OF(errfmt))) lstrcpyW(errfmt, unknownW); > > Do you think it is worth replacing? My main reason for adding load_string() was to avoid > duplicating the FIXME line and to avoid "Unknown error string". If LoadString should never fail under normal circumstances then perhaps simple assert(0) is enough, and there is no need to invent new code to handle errors that should never happen. -- Dmitry.

Jan. 30, 2017

Re: [PATCH 1/7] regedit: Use a helper for LoadString() and add debug information

by Hugh McMaster

On Sunday, 29 January 2017 11:23 PM, Dmitry Timoshkov wrote: >Hugh McMaster wrote: >> -static INT vmessagebox(HWND hwnd, INT buttons, INT titleId, INT resId, va_list ap) >> +static void load_string(unsigned int msg_id, WCHAR *buf, unsigned int count) >> { >> static const WCHAR errorW[] = {'E','r','r','o','r',0}; >> - static const WCHAR unknownW[] = {'U','n','k','n','o','w','n',' ','e','r','r','o','r',' ','s','t','r','i','n','g','!',0}; >> >> + if (!buf) return; >> + >> + if (!LoadStringW(hInst, msg_id, buf, count)) >> + { >> + WINE_FIXME("LoadString failed with %u\n", GetLastError()); >> + lstrcpyW(buf, errorW); >> + } >> +} > > Probably using a flavour of lstrcpy that checks the target buffer length > would be more appropriate. Although simply returning an empty buffer and > an error indicator to the caller could be slightly better. Under which > conditions LoadString may fail here? The buffer size must be at least six WCHARs to allow for errorW, so we could just do something like if (!buf || count < 6) return; In this code, LoadString() could fail if the resource ID doesn't exist or if count is 0 or 1. But since we are controlling all of the code, none of this is likely. For MessageBox captions, if we pass in NULL, the default string "Error" is loaded by user32. So, apart from a few instances, we wouldn't have to handle captions at all. But we would have to do something if LoadString() failed for the body text, otherwise the user would see a blank message box. The original code was: if (!LoadStringW(hInst, titleId, title, COUNT_OF(title))) lstrcpyW(title, errorW); if (!LoadStringW(hInst, resId, errfmt, COUNT_OF(errfmt))) lstrcpyW(errfmt, unknownW); Do you think it is worth replacing? My main reason for adding load_string() was to avoid duplicating the FIXME line and to avoid "Unknown error string". -- Hugh

Jan. 29, 2017

Re: [PATCH] MAINTAINERS: Add myself for printing

by Bruno Jesus

On Sun, Jan 29, 2017 at 8:15 PM, Detlef Riekenberg <wine.dev(a)web.de> wrote: > -- > bye bye Detlef > > Signed-off-by: Detlef Riekenberg <wine.dev(a)web.de> > --- > MAINTAINERS | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index e5224ff..d53af50 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -206,10 +206,15 @@ F: dlls/vcomp*/ > > Printing > M: Huw Davies <huw(a)codeweavers.com> > +P: Detlef Riekenberg <wine.dev(a)web.de> > F: dlls/localspl/ > -F: dlls/wineps.drv/ > +F: dlls/spoolss/ > F: dlls/winspool.drv/ > > +Postscript Driver > +M: Huw Davies <huw(a)codeweavers.com> > +F: dlls/wineps.drv/ > + I believe we are trying to keep the areas in alphabetical order.

Jan. 29, 2017

Re: patches: Display multiple check marks for multiple signoffs.

by André Hentschel

Am 29.01.2017 um 21:56 schrieb Bruno Jesus: > On Sun, Jan 29, 2017 at 6:51 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: >>> The patch is definitly an improvement, but the problem with the patch is, that right now I can't see that my patch has been signed-off by Aric when looking at it in the patch list >>> ... >>> 129264 New Aric Stewart Re: usp10: Fix ScriptRecordDigitSubstitution spec file entry ✓ >>> ... >>> 129183 Assigned André Hentschel usp10: Fix ScriptRecordDigitSubstitution spec file entry Aric Stewart ✓ >>> ... >>> >>> I think something like that was what Bruno is looking for >> >> It is half-working then, because my patch 129061 is double checked >> because of Andrew's sign 129073. So it is missing some update after >> receiving new sign-offs, I don't know. > > Judging by the current contents of the list I infer that the other > signs are only added after the email is marked as Sign-off type. > Yeah, think so too

Jan. 29, 2017

Re: patches: Display multiple check marks for multiple signoffs.

by Bruno Jesus

On Sun, Jan 29, 2017 at 6:51 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: >> The patch is definitly an improvement, but the problem with the patch is, that right now I can't see that my patch has been signed-off by Aric when looking at it in the patch list >> ... >> 129264 New Aric Stewart Re: usp10: Fix ScriptRecordDigitSubstitution spec file entry ✓ >> ... >> 129183 Assigned André Hentschel usp10: Fix ScriptRecordDigitSubstitution spec file entry Aric Stewart ✓ >> ... >> >> I think something like that was what Bruno is looking for > > It is half-working then, because my patch 129061 is double checked > because of Andrew's sign 129073. So it is missing some update after > receiving new sign-offs, I don't know. Judging by the current contents of the list I infer that the other signs are only added after the email is marked as Sign-off type.

Jan. 29, 2017

Re: patches: Display multiple check marks for multiple signoffs.

by Bruno Jesus

On Sun, Jan 29, 2017 at 6:24 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > Hi, Hi, German friend. > > ... > > > The patch is definitly an improvement, but the problem with the patch is, that right now I can't see that my patch has been signed-off by Aric when looking at it in the patch list > ... > 129264 New Aric Stewart Re: usp10: Fix ScriptRecordDigitSubstitution spec file entry ✓ > ... > 129183 Assigned André Hentschel usp10: Fix ScriptRecordDigitSubstitution spec file entry Aric Stewart ✓ > ... > > I think something like that was what Bruno is looking for It is half-working then, because my patch 129061 is double checked because of Andrew's sign 129073. So it is missing some update after receiving new sign-offs, I don't know. Best wishes, Bruno

Jan. 29, 2017

Re: patches: Display multiple check marks for multiple signoffs.

by André Hentschel

Hi, > --- a/patches/update > +++ b/patches/update > @@ -229,7 +229,7 @@ foreach my $file (sort { $patches{$b}->{"order"} <=> $patches{$a}->{"order"} } k > } > if (defined($patch->{"signoff"})) > { > - printf INDEX "<td class=\"checkmark\" onclick=\"toggle_display('$file.signoff')\">✓</td>"; > + printf INDEX "<td class=\"checkmark\" onclick=\"toggle_display('$file.signoff')\">%s</td>", "✓" x @{$patch->{"signoff"}}; > } The patch is definitly an improvement, but the problem with the patch is, that right now I can't see that my patch has been signed-off by Aric when looking at it in the patch list ... 129264 New Aric Stewart Re: usp10: Fix ScriptRecordDigitSubstitution spec file entry ✓ ... 129183 Assigned André Hentschel usp10: Fix ScriptRecordDigitSubstitution spec file entry Aric Stewart ✓ ... I think something like that was what Bruno is looking for

Jan. 29, 2017

Re: [v2 PATCH 3/3] windowscodecs: Add support for palette image formats to PNG encoder.

by Dmitry Timoshkov

Sebastian Lackner <sebastian(a)fds-team.de> wrote: > On 27.01.2017 22:28, Vincent Povirk wrote: > >> + else > >> + { > >> + png_palette[i].red = 0; > >> + png_palette[i].green = 0; > >> + png_palette[i].blue = 0; > >> + } > > > > Why is it necessary to pad the palette in this way? Couldn't you just > > pass the appropriate number of colors? > > > > > > Clamping to 1 << This->format->bit_depth is necessary (see the comment > about newer libpng versions), but padding the palette probably isn't, > at least I'm not aware of any test for it. It still would be a good idea to test this, a standalone application should be fine. Although I'd guess this basically depends on libpng (old vs. new) behaviour, as far as I can see from my own tests WIC in Windows doesn't impose limitations to a PNG palette size. > It should be fine to replace > > colors = 1 << This->format->bit_depth; > > with > > colors = min(This->colors, 1 << This->format->bit_depth); > > and to remove the else branch. That should work, if newer libpng versions accept such palette sizes. -- Dmitry.

Jan. 29, 2017

Re: [PATCH] wined3d: Recognize SM5 dcl_resource_raw instruction.

by guillaume.charifi＠sfr.fr

Yes, you're right, I forgot to commit the declaration of raw_resource in wined3d_private.<br> And yes, it can be replaced by dst instead. <div class="gl_quote" style="margin-top: 20px; padding-top: 5px;"> <div class="gl_quoted">On Sun, Jan 29, 2017 at 11:52 AM, Guillaume Charifi<br> wrote:<br> > Signed-off-by: Guillaume Charifi<br> > ---<br> > dlls/wined3d/arb_program_shader.c | 1 +<br> > dlls/wined3d/glsl_shader.c | 1 +<br> > dlls/wined3d/shader.c | 6 ++++++<br> > dlls/wined3d/shader_sm4.c | 10 ++++++++++<br> > dlls/wined3d/wined3d_private.h | 1 +<br> > 5 files changed, 19 insertions(+)<br> <br> This patch doesn't even compile. Please test your patches before<br> sending them to wine-patches.<br> <br> > +static void shader_sm5_read_dcl_resource_raw(struct wined3d_shader_instruction *ins,<br> > + DWORD opcode, DWORD opcode_token, const DWORD *tokens, unsigned int token_count,<br> > + struct wined3d_sm4_data *priv)<br> > +{<br> > + shader_sm4_read_dst_param(priv, &tokens, WINED3D_DATA_RESOURCE, &ins->declaration.raw_resource.reg);<br> > +}<br> <br> You should just use "ins->declaration.dst".</div> </div>

Jan. 29, 2017

Re: [PATCH 1/7] regedit: Use a helper for LoadString() and add debug information

by Dmitry Timoshkov

Hugh McMaster <hugh.mcmaster(a)outlook.com> wrote: > -static INT vmessagebox(HWND hwnd, INT buttons, INT titleId, INT resId, va_list ap) > +static void load_string(unsigned int msg_id, WCHAR *buf, unsigned int count) > { > static const WCHAR errorW[] = {'E','r','r','o','r',0}; > - static const WCHAR unknownW[] = {'U','n','k','n','o','w','n',' ','e','r','r','o','r',' ','s','t','r','i','n','g','!',0}; > > + if (!buf) return; > + > + if (!LoadStringW(hInst, msg_id, buf, count)) > + { > + WINE_FIXME("LoadString failed with %u\n", GetLastError()); > + lstrcpyW(buf, errorW); > + } > +} Probably using a flavour of lstrcpy that checks the target buffer length would be more appropriate. Although simply returning an empty buffer and an error indicator to the caller could be slightly better. Under which conditions LoadString may fail here? -- Dmitry.

Jan. 29, 2017

Re: [PATCH] wined3d: Recognize SM5 dcl_resource_raw instruction.

by Józef Kucia

On Sun, Jan 29, 2017 at 11:52 AM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/arb_program_shader.c | 1 + > dlls/wined3d/glsl_shader.c | 1 + > dlls/wined3d/shader.c | 6 ++++++ > dlls/wined3d/shader_sm4.c | 10 ++++++++++ > dlls/wined3d/wined3d_private.h | 1 + > 5 files changed, 19 insertions(+) This patch doesn't even compile. Please test your patches before sending them to wine-patches. > +static void shader_sm5_read_dcl_resource_raw(struct wined3d_shader_instruction *ins, > + DWORD opcode, DWORD opcode_token, const DWORD *tokens, unsigned int token_count, > + struct wined3d_sm4_data *priv) > +{ > + shader_sm4_read_dst_param(priv, &tokens, WINED3D_DATA_RESOURCE, &ins->declaration.raw_resource.reg); > +} You should just use "ins->declaration.dst".

Jan. 29, 2017

Re: [PATCH] wined3d: Implement buffer texture range.

by Józef Kucia

Please add a test. On Sun, Jan 29, 2017 at 12:25 AM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > + GL_EXTCALL(glTexBufferRange(GL_TEXTURE_BUFFER, view_format->glInternal, buffer->buffer_object, > + desc->u.buffer.start_idx, desc->u.buffer.count)); This is wrong.

Jan. 29, 2017

RE : [PATCH] wined3d: Implement buffer texture range.

by Guillaume Charifi

Woops, I forgot the patch adding the required extension, I'll send it later.

Jan. 29, 2017

RE : Re: [PATCH 1/3] wined3d: Add some missing state updates for buffer textures.

by Guillaume Charifi

Right, thank you... -------- Message d'origine -------- De : Bruno Jesus <00cpxxx(a)gmail.com> Date :29/01/2017 03:13 (GMT+01:00) À : Guillaume Charifi Cc : Wine Develop Objet : Re: [PATCH 1/3] wined3d: Add some missing state updates for buffer textures. On Sat, Jan 28, 2017 at 8:46 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > --- > dlls/wined3d/context.c | 12 ++++++++++++ > dlls/wined3d/state.c | 5 +++++ > dlls/wined3d/view.c | 6 ------ > 3 files changed, 17 insertions(+), 6 deletions(-) You missed the Signed-off-by, see the red marks at http://source.winehq.org/patches/

Jan. 29, 2017

Re: [PATCH 1/3] wined3d: Add some missing state updates for buffer textures.

by Bruno Jesus

On Sat, Jan 28, 2017 at 8:46 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > --- > dlls/wined3d/context.c | 12 ++++++++++++ > dlls/wined3d/state.c | 5 +++++ > dlls/wined3d/view.c | 6 ------ > 3 files changed, 17 insertions(+), 6 deletions(-) You missed the Signed-off-by, see the red marks at http://source.winehq.org/patches/

Jan. 29, 2017

Re: [PATCH v3 1/4] ddraw: Don't crash if writing out a new ddraw1 surface segfaults.

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=28113 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:1662: Test failed: Got unexpected color 0x000000ff.

Jan. 28, 2017

Re: [PATCH v3 1/4] ddraw: Don't crash if writing out a new ddraw1 surface segfaults.

by Sebastian Lackner

On 28.01.2017 22:59, Alex Henrie wrote: > + __TRY > { > - *surface = NULL; > - return hr; > + if (FAILED(hr)) > + { > + *surface = NULL; > + return hr; > + } Its not possible to use return in a __TRY block.

Jan. 28, 2017

Re: [v2 PATCH 3/3] windowscodecs: Add support for palette image formats to PNG encoder.

by Sebastian Lackner

On 27.01.2017 22:28, Vincent Povirk wrote: >> + else >> + { >> + png_palette[i].red = 0; >> + png_palette[i].green = 0; >> + png_palette[i].blue = 0; >> + } > > Why is it necessary to pad the palette in this way? Couldn't you just > pass the appropriate number of colors? > > Clamping to 1 << This->format->bit_depth is necessary (see the comment about newer libpng versions), but padding the palette probably isn't, at least I'm not aware of any test for it. It should be fine to replace colors = 1 << This->format->bit_depth; with colors = min(This->colors, 1 << This->format->bit_depth); and to remove the else branch.

Jan. 28, 2017

Re: [PATCH 1/5] wined3d: Fix sRGB clears with no support for ARB_framebuffer_sRGB.

by Matteo Bruni

2017-01-27 22:29 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 27 January 2017 at 22:22, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> Yes, the idea is to do the "manual" sRGB correction of the clear color >> when ARB_framebuffer_sRGB is not supported even if the format doesn't >> advertise WINED3DFMT_FLAG_SRGB_WRITE. >> The story behind this goes like "oh, the test always expects the sRGB >> corrected color, which seems weird for formats / GPUs not supporting >> sRGB. Let me fix the test. Oh, wait, the test now fails on the GF4 Go >> (which doesn't advertise WINED3DFMT_FLAG_SRGB_WRITE for the relevant >> texture format) and actually it was passing before. I guess wined3d is >> wrong then..." >> >> So, this is the fix spurred from that test result, in that we do the >> manual clear color sRGB correction if ARB_framebuffer_sRGB is not >> supported AND we're on d3d9, regardless of the format flags. If >> ARB_framebuffer_sRGB is supported we enable GL_FRAMEBUFFER_SRGB in >> context_apply_clear_state() instead and the condition there should >> still be fine (I think?). > Yes, but now (in d3d9) you'd get sRGB clears on e.g. > WINED3DFMT_B5G6R5_UNORM when ARB_framebuffer_sRGB is not supported, > while you wouldn't (necessarily) when it is. Ahhh, you're right, I didn't think of that. Hmm, not sure how to fix it properly then without introducing more flags... I guess first of all I should check what happens when clearing those never-supposed-to-be-sRGB formats.

Jan. 27, 2017

Re: [PATCH 1/5] wined3d: Fix sRGB clears with no support for ARB_framebuffer_sRGB.

by Henri Verbeet

On 27 January 2017 at 22:22, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Yes, the idea is to do the "manual" sRGB correction of the clear color > when ARB_framebuffer_sRGB is not supported even if the format doesn't > advertise WINED3DFMT_FLAG_SRGB_WRITE. > The story behind this goes like "oh, the test always expects the sRGB > corrected color, which seems weird for formats / GPUs not supporting > sRGB. Let me fix the test. Oh, wait, the test now fails on the GF4 Go > (which doesn't advertise WINED3DFMT_FLAG_SRGB_WRITE for the relevant > texture format) and actually it was passing before. I guess wined3d is > wrong then..." > > So, this is the fix spurred from that test result, in that we do the > manual clear color sRGB correction if ARB_framebuffer_sRGB is not > supported AND we're on d3d9, regardless of the format flags. If > ARB_framebuffer_sRGB is supported we enable GL_FRAMEBUFFER_SRGB in > context_apply_clear_state() instead and the condition there should > still be fine (I think?). Yes, but now (in d3d9) you'd get sRGB clears on e.g. WINED3DFMT_B5G6R5_UNORM when ARB_framebuffer_sRGB is not supported, while you wouldn't (necessarily) when it is.

Jan. 27, 2017

Re: [v2 PATCH 3/3] windowscodecs: Add support for palette image formats to PNG encoder.

by Vincent Povirk

> + else > + { > + png_palette[i].red = 0; > + png_palette[i].green = 0; > + png_palette[i].blue = 0; > + } Why is it necessary to pad the palette in this way? Couldn't you just pass the appropriate number of colors?

Jan. 27, 2017

Re: [PATCH 1/5] wined3d: Fix sRGB clears with no support for ARB_framebuffer_sRGB.

by Matteo Bruni

2017-01-27 22:00 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 27 January 2017 at 19:52, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> - if (!gl_info->supported[ARB_FRAMEBUFFER_SRGB] && needs_srgb_write(context, state, fb)) >> + if (!gl_info->supported[ARB_FRAMEBUFFER_SRGB] >> + && ((!(context->d3d_info->wined3d_creation_flags & WINED3D_SRGB_READ_WRITE_CONTROL) >> + && fb->render_targets[0] && fb->render_targets[0]->format_flags & WINED3DFMT_FLAG_SRGB_WRITE) >> + || state->render_states[WINED3D_RS_SRGBWRITEENABLE])) > I think this looks suspicious, why is this more correct? > In particular, wouldn't this enable sRGB clears on formats without > WINED3DFMT_FLAG_SRGB_WRITE? Patch 2/5 hints that that may be > intentional, but in that case, shouldn't this be independent of > ARB_framebuffer_sRGB support? Yes, the idea is to do the "manual" sRGB correction of the clear color when ARB_framebuffer_sRGB is not supported even if the format doesn't advertise WINED3DFMT_FLAG_SRGB_WRITE. The story behind this goes like "oh, the test always expects the sRGB corrected color, which seems weird for formats / GPUs not supporting sRGB. Let me fix the test. Oh, wait, the test now fails on the GF4 Go (which doesn't advertise WINED3DFMT_FLAG_SRGB_WRITE for the relevant texture format) and actually it was passing before. I guess wined3d is wrong then..." So, this is the fix spurred from that test result, in that we do the manual clear color sRGB correction if ARB_framebuffer_sRGB is not supported AND we're on d3d9, regardless of the format flags. If ARB_framebuffer_sRGB is supported we enable GL_FRAMEBUFFER_SRGB in context_apply_clear_state() instead and the condition there should still be fine (I think?).

Jan. 27, 2017

Re: [PATCH 1/5] wined3d: Fix sRGB clears with no support for ARB_framebuffer_sRGB.

by Henri Verbeet

On 27 January 2017 at 19:52, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > - if (!gl_info->supported[ARB_FRAMEBUFFER_SRGB] && needs_srgb_write(context, state, fb)) > + if (!gl_info->supported[ARB_FRAMEBUFFER_SRGB] > + && ((!(context->d3d_info->wined3d_creation_flags & WINED3D_SRGB_READ_WRITE_CONTROL) > + && fb->render_targets[0] && fb->render_targets[0]->format_flags & WINED3DFMT_FLAG_SRGB_WRITE) > + || state->render_states[WINED3D_RS_SRGBWRITEENABLE])) I think this looks suspicious, why is this more correct? In particular, wouldn't this enable sRGB clears on formats without WINED3DFMT_FLAG_SRGB_WRITE? Patch 2/5 hints that that may be intentional, but in that case, shouldn't this be independent of ARB_framebuffer_sRGB support?

Jan. 27, 2017

Re: [PATCH v2 1/4] ddraw: Don't write out if a ddraw1 surface of size 0 is requested.

by Henri Verbeet

On 27 January 2017 at 19:21, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > 2017-01-27 5:43 GMT-07:00 Henri Verbeet <hverbeet(a)gmail.com>: >> Where does this pass without the broken()? It writes NULL to surface >> for me on Windows 7, and appears to handle the exception when an >> invalid pointer is passed in. > > http://testbot.winehq.org/JobDetails.pl?Key=28086 > > The following testbot VMs are the only ones that zero out the surface pointer: > > w8 (32 bit ddraw1) > w864 (32 bit ddraw1) > w1064 (32 bit ddraw1) > > Maybe the behavior of newer versions of Windows depends on the video > card driver? > Those are the only testbot VMs where the test gets run. test_surface_qi() requires D3D, and that's only supported on the Windows 8 and higher VMs. 64-bit ddraw doesn't support D3D at all.

Jan. 27, 2017

Re: [PATCH v2 1/4] ddraw: Don't write out if a ddraw1 surface of size 0 is requested.

by Alex Henrie

2017-01-27 5:43 GMT-07:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 26 January 2017 at 06:20, Alex Henrie <alexhenrie24(a)gmail.com> wrote: >> + hr = IDirectDraw_CreateSurface(ddraw, &surface_desc, &surface, NULL); >> + ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr); >> + ok(surface == (IDirectDrawSurface *)0xdeadbeef || broken(!surface) /* 32-bit on Win8/10 */, >> + "Got unexpected surface %p.\n", surface); > Where does this pass without the broken()? It writes NULL to surface > for me on Windows 7, and appears to handle the exception when an > invalid pointer is passed in. http://testbot.winehq.org/JobDetails.pl?Key=28086 The following testbot VMs are the only ones that zero out the surface pointer: w8 (32 bit ddraw1) w864 (32 bit ddraw1) w1064 (32 bit ddraw1) Maybe the behavior of newer versions of Windows depends on the video card driver? -Alex ---------- Forwarded message ---------- From: Marvin <testbot(a)winehq.org> Date: 2017-01-27 10:00 GMT-07:00 Subject: TestBot job 28086 results: ddraw: Don't write out if a ddraw1 surface of size 0 is requested. To: Alex Henrie <alexhenrie24(a)gmail.com> VM Status Number of test failures build completed wxppro completed 0 w2003std completed 0 wvistau64 completed 0 w2008s64 completed 0 w7u completed 0 w7pro64 completed 0 w8 completed 1 w864 completed 1 w1064 completed 2 wvistau64 completed 0 w2008s64 completed 0 w7pro64 completed 0 w864 completed 0 w1064 completed 1 === build (build) === No build failures found === wxppro (32 bit ddraw1) === No test failures found === w2003std (32 bit ddraw1) === No test failures found === wvistau64 (32 bit ddraw1) === No test failures found === w2008s64 (32 bit ddraw1) === No test failures found === w7u (32 bit ddraw1) === No test failures found === w7pro64 (32 bit ddraw1) === No test failures found === w8 (32 bit ddraw1) === ddraw: ddraw1.c:1971: Test failed: Got unexpected surface 00000000. === w864 (32 bit ddraw1) === ddraw: ddraw1.c:1971: Test failed: Got unexpected surface 00000000. === w1064 (32 bit ddraw1) === ddraw: ddraw1.c:1971: Test failed: Got unexpected surface 00000000. ddraw1.c:2299: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === wvistau64 (64 bit ddraw1) === No test failures found === w2008s64 (64 bit ddraw1) === No test failures found === w7pro64 (64 bit ddraw1) === No test failures found === w864 (64 bit ddraw1) === No test failures found === w1064 (64 bit ddraw1) === ddraw: ddraw1.c:2299: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

Jan. 27, 2017

Re: [PATCH] d3dx11: Add D3DX11CreateShaderResourceViewFromMemory stub. (resend)

by Matteo Bruni

2017-01-25 12:19 GMT+01:00 Andrey Gusev <andrey.goosev(a)gmail.com>: > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > --- > dlls/d3dx11_42/Makefile.in | 1 + > dlls/d3dx11_42/d3dx11_42.spec | 2 +- > dlls/d3dx11_43/Makefile.in | 1 + > dlls/d3dx11_43/d3dx11_43.spec | 2 +- > dlls/d3dx11_43/shader.c | 36 ++++++++++++++++++++++++++++++++++++ > 5 files changed, 40 insertions(+), 2 deletions(-) > create mode 100644 dlls/d3dx11_43/shader.c I had a better look at the patch and unfortunately I don't think this is okay as is. Sorry that I missed it the first time around. The D3DX11CreateShaderResourceViewFrom* functions are probably supposed to be very thin wrappers over the corresponding D3DX11CreateTextureFrom* functions. So e.g. for D3DX11CreateShaderResourceViewFromMemory() an implementation calling D3DX11CreateTextureFromMemory() and then ID3D11Device_CreateShaderResourceView(device, ...) on the returned resource is probably all there is to it. Except that, for the pump != NULL case, you want to do the work on the thread pump so e.g. create the the SRV in a ID3DX11DataProcessor. Anyway, it's still okay to me to go with just a stub or with an implementation only taking into account the !pump case. You need to add the function definition to d3dx11tex.h though. Also, given that this is really a texture function, it doesn't make sense to put it in a new shader.c file. Just adding it to texture.c seems fine.

Jan. 27, 2017

Re: opengl32: add OpenGL 3.3/4.0 extensions

by Vito Paradiso

i quite didn’t understand > Il giorno 16 gen 2017, alle ore 22:49, Marvin <testbot(a)winehq.org> ha scritto: > > Thank you for your contribution to Wine! > > This is an automated notification to let you know that your patch has > been reviewed and its status set to "No patch". > > This means that no patch was found in your mail. > > If you do not understand the reason for this status, disagree with our > assessment, or are simply not sure how to proceed next, please ask for > clarification by replying to this email.

Jan. 27, 2017

Re: [PATCH] d3d8/tests: Fix copy&paste issue in compare_mode (cppcheck)

by Henri Verbeet

On 27 January 2017 at 05:58, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > - unsigned int h = mode_b->h - mode_b->h; > + unsigned int h = mode_a->h - mode_b->h; This is correct of course, but I'd hesitate to call copy/paste on it.

Jan. 27, 2017

Re: [PATCH v2 1/4] ddraw: Don't write out if a ddraw1 surface of size 0 is requested.

by Henri Verbeet

On 26 January 2017 at 06:20, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > + hr = IDirectDraw_CreateSurface(ddraw, &surface_desc, &surface, NULL); > + ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr); > + ok(surface == (IDirectDrawSurface *)0xdeadbeef || broken(!surface) /* 32-bit on Win8/10 */, > + "Got unexpected surface %p.\n", surface); Where does this pass without the broken()? It writes NULL to surface for me on Windows 7, and appears to handle the exception when an invalid pointer is passed in.

Jan. 27, 2017

Re: ntprint: Fix PSetupCreateMonitorInfo spec file entry

by Huw Davies

On Thu, Jan 26, 2017 at 11:46:57PM +0100, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/ntprint/ntprint.spec | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > diff --git a/dlls/ntprint/ntprint.spec b/dlls/ntprint/ntprint.spec > index 8869776..3687979 100644 > --- a/dlls/ntprint/ntprint.spec > +++ b/dlls/ntprint/ntprint.spec > @@ -2,7 +2,7 @@ > @ stub PSetupAssociateICMProfiles > @ stub PSetupBuildDriversFromPath > @ stub PSetupCreateDrvSetupPage > -@ stdcall PSetupCreateMonitorInfo(long ptr ptr) > +@ stdcall PSetupCreateMonitorInfo(ptr ptr ptr) > @ stub PSetupCreatePrinterDeviceInfoList > @ stub PSetupDestroyDriverInfo3 > @ stdcall PSetupDestroyMonitorInfo(long) > I get exceptions running the tests on 32-bit Windows (with or without this patch) which go away when I call the function with just two arguments - I suspect we should lose the third argument. Huw.

Jan. 27, 2017

Re: ntdll: add a stub for NtLoadKey2/ZwLoadKey2

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > +NTSTATUS WINAPI NtLoadKey2(OBJECT_ATTRIBUTES *attr, OBJECT_ATTRIBUTES *file, ULONG flags) > +{ > + NTSTATUS ret; > + > + FIXME("(%p,%p,0x%08x) semi-stub: ignoring flags\n", attr, file, flags); > + ret = NtLoadKey(attr, file); > + > + return ret; > +} There is no need for an intermediate variable. -- Dmitry.

Jan. 27, 2017

Re: [v3 PATCH 04/10] x86/insn-kernel: Add a function to obtain register offset in ModRM

by Masami Hiramatsu

On Wed, 25 Jan 2017 22:07:16 -0800 Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> wrote: > Hi Masami, > > On Thu, 2017-01-26 at 11:11 +0900, Masami Hiramatsu wrote: > > On Wed, 25 Jan 2017 12:23:47 -0800 > > Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> wrote: > > > > > The function insn_get_reg_offset requires a type to indicate whether > > > the returned offset is that given by by the ModRM or the SIB byte. > > > Callers of this function would need the definition of the type struct. > > > This is not needed. Instead, auxiliary functions can be defined for > > > this purpose. > > > > > > When the operand is a register, the emulation code for User-Mode > > > Instruction Prevention needs to know the offset of the register indicated > > > in the r/m part of the ModRM byte. Thus, start by adding an auxiliary > > > function for this purpose. > > > > Hmm, why wouldn't you just rename it to insn_get_reg_offset() and export it? > > Do you mean exporting the structure that I mention above? The problem > that I am trying to solve is that callers sometimes want to know the > offset of the register encoded in the SiB or the ModRM bytes. I could > use something > > insn_get_reg_offset(insn, regs, INSN_TYPE_MODRM) > insn_get_reg_offset(insn, regs, INSN_TYPE_SIB) > > Instead, I opted for > > insn_get_reg_offset_rm(insn, regs) > insn_get_reg_offset_sib(insn, regs) > > to avoid exposing an enum with the INSN_TYPE_MODRM, INSN_TYPE_SIB. OK, if so, I think you should export both of them at once, not only insn_get_reg_offset_rm(). Thank you, > > If you feel that the former makes more sense, I can change the > implementation. > > Thanks and BR, > Ricardo > > > > Thank you, > > > > > > > > Cc: Dave Hansen <dave.hansen(a)linux.intel.com> > > > Cc: Adam Buchbinder <adam.buchbinder(a)gmail.com> > > > Cc: Colin Ian King <colin.king(a)canonical.com> > > > Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> > > > Cc: Qiaowei Ren <qiaowei.ren(a)intel.com> > > > Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> > > > Cc: Masami Hiramatsu <mhiramat(a)kernel.org> > > > Cc: Adrian Hunter <adrian.hunter(a)intel.com> > > > Cc: Kees Cook <keescook(a)chromium.org> > > > Cc: Thomas Garnier <thgarnie(a)google.com> > > > Cc: Peter Zijlstra <peterz(a)infradead.org> > > > Cc: Borislav Petkov <bp(a)suse.de> > > > Cc: Dmitry Vyukov <dvyukov(a)google.com> > > > Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> > > > Cc: x86(a)kernel.org > > > Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> > > > --- > > > arch/x86/include/asm/insn-kernel.h | 1 + > > > arch/x86/lib/insn-kernel.c | 5 +++++ > > > 2 files changed, 6 insertions(+) > > > > > > diff --git a/arch/x86/include/asm/insn-kernel.h b/arch/x86/include/asm/insn-kernel.h > > > index aef416a..3f34649 100644 > > > --- a/arch/x86/include/asm/insn-kernel.h > > > +++ b/arch/x86/include/asm/insn-kernel.h > > > @@ -12,5 +12,6 @@ > > > #include <asm/ptrace.h> > > > > > > void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs); > > > +int insn_get_reg_offset_rm(struct insn *insn, struct pt_regs *regs); > > > > > > #endif /* _ASM_X86_INSN_KERNEL_H */ > > > diff --git a/arch/x86/lib/insn-kernel.c b/arch/x86/lib/insn-kernel.c > > > index 8072abe..267cab4 100644 > > > --- a/arch/x86/lib/insn-kernel.c > > > +++ b/arch/x86/lib/insn-kernel.c > > > @@ -95,6 +95,11 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs, > > > return regoff[regno]; > > > } > > > > > > +int insn_get_reg_offset_rm(struct insn *insn, struct pt_regs *regs) > > > +{ > > > + return get_reg_offset(insn, regs, REG_TYPE_RM); > > > +} > > > + > > > /* > > > * return the address being referenced be instruction > > > * for rm=3 returning the content of the rm reg > > > -- > > > 2.9.3 > > > > > > > > > -- Masami Hiramatsu <mhiramat(a)kernel.org>

Jan. 27, 2017

Re: [PATCH 3/3] windowscodecs: Use source palette if it wasn't specified earlier for PNG frame

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > @@ -1765,6 +1765,18 @@ static HRESULT WINAPI PngFrameEncode_WriteSource(IWICBitmapFrameEncode *iface, > > if (SUCCEEDED(hr)) > { > + if (This->colors == 0) > + { > + IWICPalette *palette; > + > + if (SUCCEEDED(PaletteImpl_Create(&palette))) > + { > + if (SUCCEEDED(IWICBitmapSource_CopyPalette(pIBitmapSource, palette))) > + IWICBitmapFrameEncode_SetPalette(iface, palette); > + IWICPalette_Release(palette); > + } > + } > + > hr = write_source(iface, pIBitmapSource, prc, > This->format->guid, This->format->bpp, This->width, This->height); > } What is this for? It looks like a workaround for a WIC converter bug. I'd like to see a test case for this behaviour. -- Dmitry.

Jan. 27, 2017

Re: [PATCH 1/3] windowscodecs: Implement IWICBitmapFrameEncode::SetPalette in PNG encoder.

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > From: Dmitry Timoshkov <dmitry(a)baikal.ru> ... > diff --git a/dlls/windowscodecs/tests/converter.c b/dlls/windowscodecs/tests/converter.c > index 2af985785c..9da82f1665 100644 > --- a/dlls/windowscodecs/tests/converter.c > +++ b/dlls/windowscodecs/tests/converter.c > @@ -25,6 +25,7 @@ > #include "windef.h" > #include "objbase.h" > #include "wincodec.h" > +#include "wincodecsdk.h" > #include "wine/test.h" > > typedef struct bitmap_data { > @@ -577,6 +578,50 @@ struct setting { > void *value; > }; > > +#define EXPECT_REF(obj,ref) _expect_ref((IUnknown*)obj, ref, __LINE__) > +static void _expect_ref(IUnknown* obj, ULONG ref, int line) I'd prefer to avoid getting a credit for the code I never had written. -- Dmitry.

Jan. 27, 2017

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings

by Ricardo Neri

On Thu, 2017-01-26 at 09:05 -0800, Andy Lutomirski wrote: > On Wed, Jan 25, 2017 at 9:50 PM, Ricardo Neri > <ricardo.neri-calderon(a)linux.intel.com> wrote: > > On Wed, 2017-01-25 at 13:58 -0800, Andy Lutomirski wrote: > >> On Wed, Jan 25, 2017 at 12:23 PM, Ricardo Neri > >> <ricardo.neri-calderon(a)linux.intel.com> wrote: > >> > Tasks running in virtual-8086 mode will use 16-bit addressing form > >> > encodings as described in the Intel 64 and IA-32 Architecture Software > >> > Developer's Manual Volume 2A Section 2.1.5. 16-bit addressing encodings > >> > differ in several ways from the 32-bit/64-bit addressing form encodings: > >> > the r/m part of the ModRM byte points to different registers and, in some > >> > cases, addresses can be indicated by the addition of the value of two > >> > registers. Also, there is no support for SiB bytes. Thus, a separate > >> > function is needed to parse this form of addressing. > >> > > >> > Furthermore, virtual-8086 mode tasks will use real-mode addressing. This > >> > implies that the segment selectors do not point to a segment descriptor > >> > but are used to compute logical addresses. Hence, there is a need to > >> > add support to compute addresses using the segment selectors. If segment- > >> > override prefixes are present in the instructions, they take precedence. > >> > > >> > Lastly, it is important to note that when a tasks is running in virtual- > >> > 8086 mode and an interrupt/exception occurs, the CPU pushes to the stack > >> > the segment selectors for ds, es, fs and gs. These are accesible via the > >> > struct kernel_vm86_regs rather than pt_regs. > >> > > >> > Code for 16-bit addressing encodings is likely to be used only by virtual- > >> > 8086 mode tasks. Thus, this code is wrapped to be built only if the > >> > option CONFIG_VM86 is selected. > >> > >> That's not true. It's used in 16-bit protected mode, too. And there > >> are (ugh!) six possibilities: > > > > Thanks for the clarification. I will enable the decoding of addresses > > for 16-bit as well... and test the emulation code. > >> > >> - Normal 32-bit protected mode. This should already work. > >> - Normal 64-bit protected mode. This should also already work. (I > >> forget whether a 16-bit SS is either illegal or has no effect in this > >> case.) > > > > For these two cases I am just taking the effective address that the user > > space application provides, given that the segment selectors were set > > beforehand (and with a base of 0). > > What do you mean by the base being zero? User code can set a nonzero > DS base if it wants. In 64-bit mode (user_64bit_mode(regs)), the base > is ignored unless there's an fs or gs prefix, and in 32-bit mode the > base is never ignored. Yes, I take this back. At the time of writing I was thinking about the __USER_CS and _USER_DS descriptors. You ar right, the base is not ignored. > > > > >> - Virtual 8086 mode > > > > In this case I calculate the linear address as: > > (segment_select << 4) + effective address. > > > >> - Normal 16-bit protected mode, used by DOSEMU and Wine. (16-bit CS, > >> 16-bit address segment) > >> - 16-bit CS, 32-bit address segment. IIRC this might be used by some > >> 32-bit DOS programs to call BIOS. > >> - 32-bit CS, 16-bit address segment. I don't know whether anything uses this. > > > > In all these protected modes, are you referring to the size in bits of > > the base address of in the descriptor selected in the CS register? In > > such a case I would need to get the base address and add it to the > > effective address given in the operands of the instructions, right? > > No, I'm referring to the D/B bit. I'm a bit fuzzy on exactly how the > instruction encoding works, but I think that 16-bit x86 code is > encoded just like real mode code except that the selectors are used > for real. I see. I have the logic to differentiate between 16-bit and 32-bit addresses. What I am missing is code to look at the value of this bit and any potential operand overrides. I will work on adding this. > > >> size, but I suspect you'll need to handle 16-bit CS. > > > > Unless I am missing what is special with the 16-bit base address, I only > > would need to add that base address to whatever effective address (aka, > > offset) is encoded in the ModRM and displacement bytes. > > Exactly. (And make sure the instruction decoder can decode 16-bit > instructions correctly.) Will do. I have tested my 16-bit decoding extensively. I think it will work. Thanks and BR, Ricardo

Jan. 27, 2017

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings (fwd)

by Ricardo Neri

On Wed, 2017-01-25 at 22:49 +0100, Julia Lawall wrote: > Check the type of seg on line 267. Ah! I missed that. It makes sense. I will fix this issue. Thanks and BR, Ricardo > > julia > > ---------- Forwarded message ---------- > Date: Thu, 26 Jan 2017 05:24:40 +0800 > From: kbuild test robot <fengguang.wu(a)intel.com> > To: kbuild(a)01.org > Cc: Julia Lawall <julia.lawall(a)lip6.fr> > Subject: Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit > addressing encodings > > In-Reply-To: <20170125202353.101059-6-ricardo.neri-calderon(a)linux.intel.com> > > Hi Ricardo, > > [auto build test WARNING on tip/auto-latest] > [also build test WARNING on v4.10-rc5 next-20170125] > [cannot apply to tip/x86/core] > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] > > url: https://github.com/0day-ci/linux/commits/Ricardo-Neri/x86-Enable-User-Mode-… > :::::: branch date: 51 minutes ago > :::::: commit date: 51 minutes ago > > >> arch/x86/lib/insn-kernel.c:267:6-9: WARNING: Unsigned expression compared with zero: seg < 0 > > git remote add linux-review https://github.com/0day-ci/linux > git remote update linux-review > git checkout 574de0de238ef30c816985006f02f7a1dbba92aa > vim +267 arch/x86/lib/insn-kernel.c > > 574de0de Ricardo Neri 2017-01-25 251 addr = (seg << 4) + regs_get_register(regs, addr_offset1); > 574de0de Ricardo Neri 2017-01-25 252 } else { > 574de0de Ricardo Neri 2017-01-25 253 ret = get_reg_offset_16(insn, regs, &addr_offset1, > 574de0de Ricardo Neri 2017-01-25 254 &addr_offset2); > 574de0de Ricardo Neri 2017-01-25 255 if (ret < 0) > 574de0de Ricardo Neri 2017-01-25 256 goto out_err; > 574de0de Ricardo Neri 2017-01-25 257 /* > 574de0de Ricardo Neri 2017-01-25 258 * Don't fail on invalid offset values. They might be invalid > 574de0de Ricardo Neri 2017-01-25 259 * because they are not supported. Instead, use them in the > 574de0de Ricardo Neri 2017-01-25 260 * calculation only if they contain a valid value. > 574de0de Ricardo Neri 2017-01-25 261 */ > 574de0de Ricardo Neri 2017-01-25 262 if (addr_offset1 >= 0) > 574de0de Ricardo Neri 2017-01-25 263 addr1 = regs_get_register(regs, addr_offset1); > 574de0de Ricardo Neri 2017-01-25 264 if (addr_offset2 >= 0) > 574de0de Ricardo Neri 2017-01-25 265 addr2 = regs_get_register(regs, addr_offset2); > 574de0de Ricardo Neri 2017-01-25 266 seg = __get_segment_selector_16(regs, insn, addr_offset1); > 574de0de Ricardo Neri 2017-01-25 @267 if (seg < 0) > 574de0de Ricardo Neri 2017-01-25 268 goto out_err; > 574de0de Ricardo Neri 2017-01-25 269 addr = (seg << 4) + addr1 + addr2; > 574de0de Ricardo Neri 2017-01-25 270 } > 574de0de Ricardo Neri 2017-01-25 271 addr += insn->displacement.value; > 574de0de Ricardo Neri 2017-01-25 272 > 574de0de Ricardo Neri 2017-01-25 273 return (void __user *)addr; > 574de0de Ricardo Neri 2017-01-25 274 out_err: > 574de0de Ricardo Neri 2017-01-25 275 return (void __user *)-1; > > --- > 0-DAY kernel test infrastructure Open Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation

Jan. 27, 2017

Re: comctl32: Move prototype to header

by Nikolay Sivov

On 27.01.2017 2:28, Sebastian Lackner wrote: > On 27.01.2017 00:26, André Hentschel wrote: >> Signed-off-by: André Hentschel <nerv(a)dawncrow.de> >> --- >> dlls/comctl32/comctl32.h | 1 + >> dlls/comctl32/syslink.c | 2 -- >> 2 files changed, 1 insertion(+), 2 deletions(-) >> > > Any specific reason that you don't use include/shlwapi.h ? > > > It's internal to comctl32.dll, and is not exported by name. Using unrelated header would be confusing. For this specific case it's better to use CompareString directly in syslink.c and maybe get rid of SYSLINK_StrCmpNIW() of possible.

Jan. 26, 2017

Re: comctl32: Move prototype to header

by Sebastian Lackner

On 27.01.2017 00:26, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/comctl32/comctl32.h | 1 + > dlls/comctl32/syslink.c | 2 -- > 2 files changed, 1 insertion(+), 2 deletions(-) > Any specific reason that you don't use include/shlwapi.h ?

Jan. 26, 2017

Re: msvideo.dll16: Implement DrawDibProfileDisplay

by Bruno Jesus

On Thu, Jan 26, 2017 at 8:52 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > On 26.01.2017 23:47, Bruno Jesus wrote: >> On Thu, Jan 26, 2017 at 8:56 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >>> Bruno Jesus <00cpxxx(a)gmail.com> writes: >>> >>>> @@ -35,7 +35,7 @@ >>>> 111 stub DRAWDIBCHANGEPALETTE >>>> 112 pascal -ret16 DrawDibRealize(word word word) DrawDibRealize16 >>>> 113 stub DRAWDIBTIME >>>> -114 stub DRAWDIBPROFILEDISPLAY >>>> +114 pascal -ret16 DrawDibProfileDisplay(segptr) DrawDibProfileDisplay16 >>> >>> segptr is not correct if you pass the pointer to 32-bit code. >> >> Thanks for the reply, I wrote a 16-bit app that calls >> DrawDibProfileDisplay [1][2] and indeed when I try to access any data >> in the struct inside Wine it crashes. It worked for the bug and games >> because the function is a stub and does nothing with the struct in >> msvfw32. >> >> What should be done then? > > Use "ptr" instead in the specfile. It works, now I can read the struct data from inside msvfw32 correctly. Thanks =)

Jan. 26, 2017

Re: msvideo.dll16: Implement DrawDibProfileDisplay

by Sebastian Lackner

On 26.01.2017 23:47, Bruno Jesus wrote: > On Thu, Jan 26, 2017 at 8:56 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Bruno Jesus <00cpxxx(a)gmail.com> writes: >> >>> @@ -35,7 +35,7 @@ >>> 111 stub DRAWDIBCHANGEPALETTE >>> 112 pascal -ret16 DrawDibRealize(word word word) DrawDibRealize16 >>> 113 stub DRAWDIBTIME >>> -114 stub DRAWDIBPROFILEDISPLAY >>> +114 pascal -ret16 DrawDibProfileDisplay(segptr) DrawDibProfileDisplay16 >> >> segptr is not correct if you pass the pointer to 32-bit code. > > Thanks for the reply, I wrote a 16-bit app that calls > DrawDibProfileDisplay [1][2] and indeed when I try to access any data > in the struct inside Wine it crashes. It worked for the bug and games > because the function is a stub and does nothing with the struct in > msvfw32. > > What should be done then? Use "ptr" instead in the specfile. > > [1] http://alexa.pro.br/~bruno/wine/msvideo.exe > [2] http://alexa.pro.br/~bruno/wine/file.txt > > Thanks in advance, > Bruno > >

Jan. 26, 2017

Re: msvideo.dll16: Implement DrawDibProfileDisplay

by Bruno Jesus

On Thu, Jan 26, 2017 at 8:56 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Bruno Jesus <00cpxxx(a)gmail.com> writes: > >> @@ -35,7 +35,7 @@ >> 111 stub DRAWDIBCHANGEPALETTE >> 112 pascal -ret16 DrawDibRealize(word word word) DrawDibRealize16 >> 113 stub DRAWDIBTIME >> -114 stub DRAWDIBPROFILEDISPLAY >> +114 pascal -ret16 DrawDibProfileDisplay(segptr) DrawDibProfileDisplay16 > > segptr is not correct if you pass the pointer to 32-bit code. Thanks for the reply, I wrote a 16-bit app that calls DrawDibProfileDisplay [1][2] and indeed when I try to access any data in the struct inside Wine it crashes. It worked for the bug and games because the function is a stub and does nothing with the struct in msvfw32. What should be done then? [1] http://alexa.pro.br/~bruno/wine/msvideo.exe [2] http://alexa.pro.br/~bruno/wine/file.txt Thanks in advance, Bruno

Jan. 26, 2017

Re: [PATCH] user32:add SIZEALL_BIG cursor, reusing SIZEALL resource Fixes bug#42303

by Anton Romanov

On Thu, Jan 26, 2017 at 11:02 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Anton Romanov <theli.ua(a)gmail.com> writes: >> +#define IDC_SIZEALL_BIG MAKEINTRESOURCE(32654) > > There's no such definition in Windows. Well, there is definitely cursor with ID 32654 in native user32.dll http://imgur.com/a/egVkt but I couldn't find it being referenced in documentation. And there is at least 1 app that crashes with it absent. If this is not the right way to add it to user32.dll, please advice on a better one.

Jan. 26, 2017

Re: Performance Testing Wine-1.2-rc4 vs Wine-1.8

by Stefan Dösinger

Am 2017-01-17 um 22:55 schrieb Stefan Dösinger: > The one game that jumps out is Trackmania Nations. It apparently > regressed from approx. 32 fps to 24. I will run a bisect in the next > days to pinpoint the patch that caused this. The game itself wasn't updated. I bisected this regression on the iMac itself, and the "bad" patch is 70889d68664c1211caf5a845014953dfee66c8f4. However, the patch is working as it is supposed to. The game has a setting "GPU Synchro" that defaults to "Immediate". With this setting the game uses event queries to achieve the equivalent of glFinish(). Before 70889d68 an unsignalled event query would return S_OK and *data was set to FALSE. Now it returns S_FALSE and *data is left unset. This change in behavior makes the game's wait work as intended and the performance goes down. Setting the synchronization to 1 frame (so the game waits for a query from one frame ago) restores the original performance.

Jan. 26, 2017

Re: [PATCH] user32:add SIZEALL_BIG cursor, reusing SIZEALL resource Fixes bug#42303

by Alexandre Julliard

Anton Romanov <theli.ua(a)gmail.com> writes: > @@ -2227,6 +2227,7 @@ typedef struct tagCBTACTIVATESTRUCT > #define IDC_HAND MAKEINTRESOURCE(32649) > #define IDC_APPSTARTING MAKEINTRESOURCE(32650) > #define IDC_HELP MAKEINTRESOURCE(32651) > +#define IDC_SIZEALL_BIG MAKEINTRESOURCE(32654) There's no such definition in Windows. > @@ -1011,6 +1011,7 @@ > #define OCR_NO 32648 > #define OCR_HAND 32649 > #define OCR_APPSTARTING 32650 > +#define OCR_SIZEALL_BIG 32654 This is already defined as OCR_RDR2DIM. -- Alexandre Julliard julliard(a)winehq.org

Jan. 26, 2017

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings

by Andy Lutomirski

On Wed, Jan 25, 2017 at 9:50 PM, Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> wrote: > On Wed, 2017-01-25 at 13:58 -0800, Andy Lutomirski wrote: >> On Wed, Jan 25, 2017 at 12:23 PM, Ricardo Neri >> <ricardo.neri-calderon(a)linux.intel.com> wrote: >> > Tasks running in virtual-8086 mode will use 16-bit addressing form >> > encodings as described in the Intel 64 and IA-32 Architecture Software >> > Developer's Manual Volume 2A Section 2.1.5. 16-bit addressing encodings >> > differ in several ways from the 32-bit/64-bit addressing form encodings: >> > the r/m part of the ModRM byte points to different registers and, in some >> > cases, addresses can be indicated by the addition of the value of two >> > registers. Also, there is no support for SiB bytes. Thus, a separate >> > function is needed to parse this form of addressing. >> > >> > Furthermore, virtual-8086 mode tasks will use real-mode addressing. This >> > implies that the segment selectors do not point to a segment descriptor >> > but are used to compute logical addresses. Hence, there is a need to >> > add support to compute addresses using the segment selectors. If segment- >> > override prefixes are present in the instructions, they take precedence. >> > >> > Lastly, it is important to note that when a tasks is running in virtual- >> > 8086 mode and an interrupt/exception occurs, the CPU pushes to the stack >> > the segment selectors for ds, es, fs and gs. These are accesible via the >> > struct kernel_vm86_regs rather than pt_regs. >> > >> > Code for 16-bit addressing encodings is likely to be used only by virtual- >> > 8086 mode tasks. Thus, this code is wrapped to be built only if the >> > option CONFIG_VM86 is selected. >> >> That's not true. It's used in 16-bit protected mode, too. And there >> are (ugh!) six possibilities: > > Thanks for the clarification. I will enable the decoding of addresses > for 16-bit as well... and test the emulation code. >> >> - Normal 32-bit protected mode. This should already work. >> - Normal 64-bit protected mode. This should also already work. (I >> forget whether a 16-bit SS is either illegal or has no effect in this >> case.) > > For these two cases I am just taking the effective address that the user > space application provides, given that the segment selectors were set > beforehand (and with a base of 0). What do you mean by the base being zero? User code can set a nonzero DS base if it wants. In 64-bit mode (user_64bit_mode(regs)), the base is ignored unless there's an fs or gs prefix, and in 32-bit mode the base is never ignored. > >> - Virtual 8086 mode > > In this case I calculate the linear address as: > (segment_select << 4) + effective address. > >> - Normal 16-bit protected mode, used by DOSEMU and Wine. (16-bit CS, >> 16-bit address segment) >> - 16-bit CS, 32-bit address segment. IIRC this might be used by some >> 32-bit DOS programs to call BIOS. >> - 32-bit CS, 16-bit address segment. I don't know whether anything uses this. > > In all these protected modes, are you referring to the size in bits of > the base address of in the descriptor selected in the CS register? In > such a case I would need to get the base address and add it to the > effective address given in the operands of the instructions, right? No, I'm referring to the D/B bit. I'm a bit fuzzy on exactly how the instruction encoding works, but I think that 16-bit x86 code is encoded just like real mode code except that the selectors are used for real. >> size, but I suspect you'll need to handle 16-bit CS. > > Unless I am missing what is special with the 16-bit base address, I only > would need to add that base address to whatever effective address (aka, > offset) is encoded in the ModRM and displacement bytes. Exactly. (And make sure the instruction decoder can decode 16-bit instructions correctly.)

Jan. 26, 2017

Re: [PATCH] hidclass.sys: When processing reads fill all the buffers

by Aric Stewart

Hi Sebastian, On 1/26/17 8:03 AM, Sebastian Lackner wrote: > On 26.01.2017 13:57, Aric Stewart wrote: >> This is a follow-up fix for continuing work on bug 42225 >> >> Signed-off-by: Aric Stewart <aric(a)codeweavers.com> >> --- >> dlls/hidclass.sys/buffer.c | 34 +++++++++++++++++++++++++++++++++- >> dlls/hidclass.sys/device.c | 2 +- >> dlls/hidclass.sys/hid.h | 3 ++- >> 3 files changed, 36 insertions(+), 3 deletions(-) >> >> >> >> 0001-hidclass.sys-When-processing-reads-fill-all-the-buffer.txt >> >> >> diff --git a/dlls/hidclass.sys/buffer.c b/dlls/hidclass.sys/buffer.c >> index 0b29f97b69..41bbb8e241 100644 >> --- a/dlls/hidclass.sys/buffer.c >> +++ b/dlls/hidclass.sys/buffer.c >> @@ -127,7 +127,7 @@ NTSTATUS RingBuffer_SetSize(struct ReportRingBuffer *ring, UINT size) >> return STATUS_SUCCESS; >> } >> >> -void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) >> +void RingBuffer_ReadNew(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) >> { >> void *ret = NULL; >> >> @@ -155,6 +155,38 @@ void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UI >> } >> } >> >> +void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) >> +{ >> + int pointer = ring->pointers[index]; >> + void *ret = NULL; >> + >> + EnterCriticalSection(&ring->lock); >> + if (index >= ring->pointer_alloc || ring->pointers[index] == POINTER_UNUSED >> + || ring->end == ring->start) >> + { >> + LeaveCriticalSection(&ring->lock); >> + *size = 0; >> + return; >> + } >> + >> + if (pointer == ring->end) >> + pointer--; >> + >> + if (pointer < 0) >> + pointer = ring->size - 1; >> + >> + ret = &ring->buffer[pointer * ring->buffer_size]; >> + memcpy(output, ret, ring->buffer_size); >> + if (pointer == ring->pointers[index]) >> + { >> + ring->pointers[index]++; >> + if (ring->pointers[index] == ring->size) >> + ring->pointers[index] = 0; >> + } >> + LeaveCriticalSection(&ring->lock); >> + *size = ring->buffer_size; > > Have you been able to reproduce a similar behavior on Windows? The new code Yes, I have a test case that produces behavior similar to bug 42225, But I have not been successful at getting even the start of the testing framework in place to be able to put in more tests. > looks very suspicious and I'm not sure if this is the right approach to fix Ok, suggestions? > it. Also please note that this will effectively disable any asynchronous > Read requests - HID_Device_read() will always use the first code path when > there is at least one package in the ring buffer and never return > STATUS_PENDING. > Nope, it will not. HID_Device_read uses RingBuffer_ReadNew. So the behavior there will be unchanged. This only affects HID_Device_processQueue, which is only called when the device has received a report and has pending IRP requests. The trick is that if a single FileOpen makes multiple asynchronous FileRead requests all of them should be fulfilled not just the first one. -aric >> +} >> + >> UINT RingBuffer_AddPointer(struct ReportRingBuffer *ring) >> { >> UINT idx; >> diff --git a/dlls/hidclass.sys/device.c b/dlls/hidclass.sys/device.c >> index b241016e72..d6a0a358e3 100644 >> --- a/dlls/hidclass.sys/device.c >> +++ b/dlls/hidclass.sys/device.c >> @@ -662,7 +662,7 @@ NTSTATUS WINAPI HID_Device_read(DEVICE_OBJECT *device, IRP *irp) >> ptr = PtrToUlong( irp->Tail.Overlay.OriginalFileObject->FsContext ); >> >> irp->IoStatus.Information = 0; >> - RingBuffer_Read(ext->ring_buffer, ptr, packet, &buffer_size); >> + RingBuffer_ReadNew(ext->ring_buffer, ptr, packet, &buffer_size); >> >> if (buffer_size) >> { >> diff --git a/dlls/hidclass.sys/hid.h b/dlls/hidclass.sys/hid.h >> index adc547cc43..1829319ccf 100644 >> --- a/dlls/hidclass.sys/hid.h >> +++ b/dlls/hidclass.sys/hid.h >> @@ -62,7 +62,8 @@ typedef struct _BASE_DEVICE_EXTENSION { >> void RingBuffer_Write(struct ReportRingBuffer *buffer, void *data) DECLSPEC_HIDDEN; >> UINT RingBuffer_AddPointer(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; >> void RingBuffer_RemovePointer(struct ReportRingBuffer *ring, UINT index) DECLSPEC_HIDDEN; >> -void RingBuffer_Read(struct ReportRingBuffer *buffer, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; >> +void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; >> +void RingBuffer_ReadNew(struct ReportRingBuffer *buffer, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; >> UINT RingBuffer_GetBufferSize(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; >> UINT RingBuffer_GetSize(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; >> void RingBuffer_Destroy(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; >> >> >> >

Jan. 26, 2017

Re: [PATCH] hidclass.sys: When processing reads fill all the buffers

by Sebastian Lackner

On 26.01.2017 13:57, Aric Stewart wrote: > This is a follow-up fix for continuing work on bug 42225 > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/hidclass.sys/buffer.c | 34 +++++++++++++++++++++++++++++++++- > dlls/hidclass.sys/device.c | 2 +- > dlls/hidclass.sys/hid.h | 3 ++- > 3 files changed, 36 insertions(+), 3 deletions(-) > > > > 0001-hidclass.sys-When-processing-reads-fill-all-the-buffer.txt > > > diff --git a/dlls/hidclass.sys/buffer.c b/dlls/hidclass.sys/buffer.c > index 0b29f97b69..41bbb8e241 100644 > --- a/dlls/hidclass.sys/buffer.c > +++ b/dlls/hidclass.sys/buffer.c > @@ -127,7 +127,7 @@ NTSTATUS RingBuffer_SetSize(struct ReportRingBuffer *ring, UINT size) > return STATUS_SUCCESS; > } > > -void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) > +void RingBuffer_ReadNew(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) > { > void *ret = NULL; > > @@ -155,6 +155,38 @@ void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UI > } > } > > +void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) > +{ > + int pointer = ring->pointers[index]; > + void *ret = NULL; > + > + EnterCriticalSection(&ring->lock); > + if (index >= ring->pointer_alloc || ring->pointers[index] == POINTER_UNUSED > + || ring->end == ring->start) > + { > + LeaveCriticalSection(&ring->lock); > + *size = 0; > + return; > + } > + > + if (pointer == ring->end) > + pointer--; > + > + if (pointer < 0) > + pointer = ring->size - 1; > + > + ret = &ring->buffer[pointer * ring->buffer_size]; > + memcpy(output, ret, ring->buffer_size); > + if (pointer == ring->pointers[index]) > + { > + ring->pointers[index]++; > + if (ring->pointers[index] == ring->size) > + ring->pointers[index] = 0; > + } > + LeaveCriticalSection(&ring->lock); > + *size = ring->buffer_size; Have you been able to reproduce a similar behavior on Windows? The new code looks very suspicious and I'm not sure if this is the right approach to fix it. Also please note that this will effectively disable any asynchronous Read requests - HID_Device_read() will always use the first code path when there is at least one package in the ring buffer and never return STATUS_PENDING. > +} > + > UINT RingBuffer_AddPointer(struct ReportRingBuffer *ring) > { > UINT idx; > diff --git a/dlls/hidclass.sys/device.c b/dlls/hidclass.sys/device.c > index b241016e72..d6a0a358e3 100644 > --- a/dlls/hidclass.sys/device.c > +++ b/dlls/hidclass.sys/device.c > @@ -662,7 +662,7 @@ NTSTATUS WINAPI HID_Device_read(DEVICE_OBJECT *device, IRP *irp) > ptr = PtrToUlong( irp->Tail.Overlay.OriginalFileObject->FsContext ); > > irp->IoStatus.Information = 0; > - RingBuffer_Read(ext->ring_buffer, ptr, packet, &buffer_size); > + RingBuffer_ReadNew(ext->ring_buffer, ptr, packet, &buffer_size); > > if (buffer_size) > { > diff --git a/dlls/hidclass.sys/hid.h b/dlls/hidclass.sys/hid.h > index adc547cc43..1829319ccf 100644 > --- a/dlls/hidclass.sys/hid.h > +++ b/dlls/hidclass.sys/hid.h > @@ -62,7 +62,8 @@ typedef struct _BASE_DEVICE_EXTENSION { > void RingBuffer_Write(struct ReportRingBuffer *buffer, void *data) DECLSPEC_HIDDEN; > UINT RingBuffer_AddPointer(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > void RingBuffer_RemovePointer(struct ReportRingBuffer *ring, UINT index) DECLSPEC_HIDDEN; > -void RingBuffer_Read(struct ReportRingBuffer *buffer, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; > +void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; > +void RingBuffer_ReadNew(struct ReportRingBuffer *buffer, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; > UINT RingBuffer_GetBufferSize(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > UINT RingBuffer_GetSize(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > void RingBuffer_Destroy(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > > >

Jan. 26, 2017

Re: msvideo.dll16: Implement DrawDibProfileDisplay

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > @@ -35,7 +35,7 @@ > 111 stub DRAWDIBCHANGEPALETTE > 112 pascal -ret16 DrawDibRealize(word word word) DrawDibRealize16 > 113 stub DRAWDIBTIME > -114 stub DRAWDIBPROFILEDISPLAY > +114 pascal -ret16 DrawDibProfileDisplay(segptr) DrawDibProfileDisplay16 segptr is not correct if you pass the pointer to 32-bit code. -- Alexandre Julliard julliard(a)winehq.org

Jan. 26, 2017

Re: [v3 PATCH 04/10] x86/insn-kernel: Add a function to obtain register offset in ModRM

by Ricardo Neri

Hi Masami, On Thu, 2017-01-26 at 11:11 +0900, Masami Hiramatsu wrote: > On Wed, 25 Jan 2017 12:23:47 -0800 > Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> wrote: > > > The function insn_get_reg_offset requires a type to indicate whether > > the returned offset is that given by by the ModRM or the SIB byte. > > Callers of this function would need the definition of the type struct. > > This is not needed. Instead, auxiliary functions can be defined for > > this purpose. > > > > When the operand is a register, the emulation code for User-Mode > > Instruction Prevention needs to know the offset of the register indicated > > in the r/m part of the ModRM byte. Thus, start by adding an auxiliary > > function for this purpose. > > Hmm, why wouldn't you just rename it to insn_get_reg_offset() and export it? Do you mean exporting the structure that I mention above? The problem that I am trying to solve is that callers sometimes want to know the offset of the register encoded in the SiB or the ModRM bytes. I could use something insn_get_reg_offset(insn, regs, INSN_TYPE_MODRM) insn_get_reg_offset(insn, regs, INSN_TYPE_SIB) Instead, I opted for insn_get_reg_offset_rm(insn, regs) insn_get_reg_offset_sib(insn, regs) to avoid exposing an enum with the INSN_TYPE_MODRM, INSN_TYPE_SIB. If you feel that the former makes more sense, I can change the implementation. Thanks and BR, Ricardo > > Thank you, > > > > > Cc: Dave Hansen <dave.hansen(a)linux.intel.com> > > Cc: Adam Buchbinder <adam.buchbinder(a)gmail.com> > > Cc: Colin Ian King <colin.king(a)canonical.com> > > Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> > > Cc: Qiaowei Ren <qiaowei.ren(a)intel.com> > > Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> > > Cc: Masami Hiramatsu <mhiramat(a)kernel.org> > > Cc: Adrian Hunter <adrian.hunter(a)intel.com> > > Cc: Kees Cook <keescook(a)chromium.org> > > Cc: Thomas Garnier <thgarnie(a)google.com> > > Cc: Peter Zijlstra <peterz(a)infradead.org> > > Cc: Borislav Petkov <bp(a)suse.de> > > Cc: Dmitry Vyukov <dvyukov(a)google.com> > > Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> > > Cc: x86(a)kernel.org > > Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> > > --- > > arch/x86/include/asm/insn-kernel.h | 1 + > > arch/x86/lib/insn-kernel.c | 5 +++++ > > 2 files changed, 6 insertions(+) > > > > diff --git a/arch/x86/include/asm/insn-kernel.h b/arch/x86/include/asm/insn-kernel.h > > index aef416a..3f34649 100644 > > --- a/arch/x86/include/asm/insn-kernel.h > > +++ b/arch/x86/include/asm/insn-kernel.h > > @@ -12,5 +12,6 @@ > > #include <asm/ptrace.h> > > > > void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs); > > +int insn_get_reg_offset_rm(struct insn *insn, struct pt_regs *regs); > > > > #endif /* _ASM_X86_INSN_KERNEL_H */ > > diff --git a/arch/x86/lib/insn-kernel.c b/arch/x86/lib/insn-kernel.c > > index 8072abe..267cab4 100644 > > --- a/arch/x86/lib/insn-kernel.c > > +++ b/arch/x86/lib/insn-kernel.c > > @@ -95,6 +95,11 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs, > > return regoff[regno]; > > } > > > > +int insn_get_reg_offset_rm(struct insn *insn, struct pt_regs *regs) > > +{ > > + return get_reg_offset(insn, regs, REG_TYPE_RM); > > +} > > + > > /* > > * return the address being referenced be instruction > > * for rm=3 returning the content of the rm reg > > -- > > 2.9.3 > > > >

Jan. 26, 2017

Re: [v3 PATCH 07/10] x86: Add emulation code for UMIP instructions

by Ricardo Neri

On Wed, 2017-01-25 at 12:38 -0800, H. Peter Anvin wrote: > On 01/25/17 12:23, Ricardo Neri wrote: > > + case UMIP_SMSW: > > + dummy_value = CR0_STATE; > > Unless the user space process is running in 64-bit mode this value > should be & 0xffff. But wouldn't that prevent the bits CR0[63:16] or CR0[31:16] from being copied when a register operand is used? According to the Intel Software Development manual, SMSW returns SMSW r16 operand size 16, store CR0[15:0] in r16 SMSW r32 operand size 32, zero-extend CR0[31:0], and store in r32 SMSW r64 operand size 64, zero-extend CR0[63:0], and store in r64 The number of bytes returned by the emulated results is controlled by the data_size variable. If it finds that the result will be saved in a memory location, it will only copy CR0[15:0], which is the expected behavior of SMSW if the result is to be copied in memory. > I'm not sure if we should even support fixing up > UMIP instructions in 64-bit mode. Probably not. The whole point of the emulation was to support virtual-8086 mode and 32-bit mode. > > Also, please put an explicit /* fall through */ here. Will do. > > > + /* > > + * These two instructions return a 16-bit value. We return > > + * all zeros. This is equivalent to a null descriptor for > > + * str and sldt. > > + */ > > + case UMIP_SLDT: > > + case UMIP_STR: > > + /* if operand is a register, it is zero-extended*/ > > + if (X86_MODRM_MOD(insn->modrm.value) == 3) { > > + memset(data, 0, insn->opnd_bytes); > > + *data_size = insn->opnd_bytes; > > + /* if not, only the two least significant bytes are copied */ > > + } else { > > + *data_size = 2; > > + } > > + memcpy(data, &dummy_value, sizeof(dummy_value)); > > + break; The code above controls how many bytes are copied as the result of SMSW. > > + default: > > + return -EINVAL; > > + } > > + return 0; > > > > +bool fixup_umip_exception(struct pt_regs *regs) > > +{ > > + struct insn insn; > > + unsigned char buf[MAX_INSN_SIZE]; > > + /* 10 bytes is the maximum size of the result of UMIP instructions */ > > + unsigned char dummy_data[10] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}; > > +#ifdef CONFIG_X86_64 > > + int x86_64 = user_64bit_mode(regs); > > +#else > > + int x86_64 = 0; > > +#endif > > Again, could we simply do: > > if (user_64bit_mode(regs)) > return false; > > or are there known users of these instructions *in 64-bit mode*? I am not aware of any. In that case, I will make this code return in this case. Thanks and BR, Ricardo > > -hpa > >

Jan. 26, 2017

Re: [v3 PATCH 00/10] x86: Enable User-Mode Instruction Prevention

by Ricardo Neri

Hi Peter, On Wed, 2017-01-25 at 12:34 -0800, H. Peter Anvin wrote: > On 01/25/17 12:23, Ricardo Neri wrote: > > * SMSW returns the value with which the CR0 register is programmed in > > head_32/64.S at boot time. This is, the following bits are enabed: > > CR0.0 for Protection Enable, CR.1 for Monitor Coprocessor, CR.4 for > > Extension Type, which will always be 1 in recent processors with UMIP; > > CR.5 for Numeric Error, CR0.16 for Write Protect, CR0.18 for Alignment > > Mask. Additionally, in x86_64, CR0.31 for Paging is set. > > SMSW only returns CR0[15:0], so the reference here to CR0[31:16] seems odd. I checked again the latest version (from Dec 2016) of the Intel Software Development Manual. The documentation for SMSW states the following: SMSW r16 operand size 16, store CR0[15:0] in r16 SMSW r32 operand size 32, zero-extend CR0[31:0], and store in r32 SMSW r64 operand size 64, zero-extend CR0[63:0], and store in r64 When the operand is a memory location, yes, it only returns CR0[15:0] Also, in the tests that I ran I wrote the result of SMSW to a 64-bit register. I get 0x80050033. It seems to me that it does write as many bits as the register operand can hold. Am I missing something? Thanks and BR, Ricardo > > -hpa > >

Jan. 26, 2017

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings

by Ricardo Neri

On Wed, 2017-01-25 at 13:58 -0800, Andy Lutomirski wrote: > On Wed, Jan 25, 2017 at 12:23 PM, Ricardo Neri > <ricardo.neri-calderon(a)linux.intel.com> wrote: > > Tasks running in virtual-8086 mode will use 16-bit addressing form > > encodings as described in the Intel 64 and IA-32 Architecture Software > > Developer's Manual Volume 2A Section 2.1.5. 16-bit addressing encodings > > differ in several ways from the 32-bit/64-bit addressing form encodings: > > the r/m part of the ModRM byte points to different registers and, in some > > cases, addresses can be indicated by the addition of the value of two > > registers. Also, there is no support for SiB bytes. Thus, a separate > > function is needed to parse this form of addressing. > > > > Furthermore, virtual-8086 mode tasks will use real-mode addressing. This > > implies that the segment selectors do not point to a segment descriptor > > but are used to compute logical addresses. Hence, there is a need to > > add support to compute addresses using the segment selectors. If segment- > > override prefixes are present in the instructions, they take precedence. > > > > Lastly, it is important to note that when a tasks is running in virtual- > > 8086 mode and an interrupt/exception occurs, the CPU pushes to the stack > > the segment selectors for ds, es, fs and gs. These are accesible via the > > struct kernel_vm86_regs rather than pt_regs. > > > > Code for 16-bit addressing encodings is likely to be used only by virtual- > > 8086 mode tasks. Thus, this code is wrapped to be built only if the > > option CONFIG_VM86 is selected. > > That's not true. It's used in 16-bit protected mode, too. And there > are (ugh!) six possibilities: Thanks for the clarification. I will enable the decoding of addresses for 16-bit as well... and test the emulation code. > > - Normal 32-bit protected mode. This should already work. > - Normal 64-bit protected mode. This should also already work. (I > forget whether a 16-bit SS is either illegal or has no effect in this > case.) For these two cases I am just taking the effective address that the user space application provides, given that the segment selectors were set beforehand (and with a base of 0). copy_to/from_user(kernel_buf, effective_address, sizeof(kernel_buf)); > - Virtual 8086 mode In this case I calculate the linear address as: (segment_select << 4) + effective address. > - Normal 16-bit protected mode, used by DOSEMU and Wine. (16-bit CS, > 16-bit address segment) > - 16-bit CS, 32-bit address segment. IIRC this might be used by some > 32-bit DOS programs to call BIOS. > - 32-bit CS, 16-bit address segment. I don't know whether anything uses this. In all these protected modes, are you referring to the size in bits of the base address of in the descriptor selected in the CS register? In such a case I would need to get the base address and add it to the effective address given in the operands of the instructions, right? > > I don't know if anything you're doing cares about SS's, DS's, etc. For 16-bit addressing encodings, I use DS for the BX, DI and SI registers, and no register at all. I use SS for BP and SP. This can be overridden by the segment selector prefixes. For 32/64-bit, I need to implement segment selector awareness. > size, but I suspect you'll need to handle 16-bit CS. Unless I am missing what is special with the 16-bit base address, I only would need to add that base address to whatever effective address (aka, offset) is encoded in the ModRM and displacement bytes. At this moment my implementation is able to decode the ModRM, SiB and displacement bytes for 16-bit and 32/64-bit address encodings. Thanks and BR, Ricardo

Jan. 26, 2017

Re: [v3 PATCH 03/10] x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel

by Masami Hiramatsu

On Wed, 25 Jan 2017 12:23:46 -0800 Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> wrote: > Other kernel submodules can benefit from using the utility functions > defined in mpx.c to obtain the addresses and values of operands contained > in the general purpose registers. An instance of this is the emulation code > used for instructions protected by the Intel User-Mode Instruction > Prevention feature. > > Thus, these functions are relocated to a new insn-kernel.c file. The reason > to not relocate these utilities into insn.c is that the latter solely > analyses instructions given by a struct insn without any knowledge of the > kernel context. This new utilities insn-kernel.c aims to be used within the > context of the kernel. For instance, it can be used to determine memory > addresses as encoded in the contents of the general purpose registers. What would you mean the "kernel context" here? Extracting the register offset or an address by decoding instruction seems not depending on where the context (pt_regs) in kernel or user... Of course, this is a kind of "evaluation" of instruction, so it might be better to split it to other file, but I think insn-eval.c is better. Thank you, > > These utilities come with a separate header. This is to avoid taking insn.c > out of sync from the instructions decoders under tools/obj and tools/perf. > This also avoids adding cumbersome #ifdef's for the #include'd files > required to decode instructions in a kernel context. > > Functions are simply relocated. There are not functional or indentation > changes. > > Cc: Dave Hansen <dave.hansen(a)linux.intel.com> > Cc: Adam Buchbinder <adam.buchbinder(a)gmail.com> > Cc: Colin Ian King <colin.king(a)canonical.com> > Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> > Cc: Qiaowei Ren <qiaowei.ren(a)intel.com> > Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> > Cc: Masami Hiramatsu <mhiramat(a)kernel.org> > Cc: Adrian Hunter <adrian.hunter(a)intel.com> > Cc: Kees Cook <keescook(a)chromium.org> > Cc: Thomas Garnier <thgarnie(a)google.com> > Cc: Peter Zijlstra <peterz(a)infradead.org> > Cc: Borislav Petkov <bp(a)suse.de> > Cc: Dmitry Vyukov <dvyukov(a)google.com> > Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> > Cc: x86(a)kernel.org > Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> > --- > arch/x86/include/asm/insn-kernel.h | 16 ++++ > arch/x86/lib/Makefile | 2 +- > arch/x86/lib/insn-kernel.c | 147 +++++++++++++++++++++++++++++++++++++ > arch/x86/mm/mpx.c | 140 +---------------------------------- > 4 files changed, 166 insertions(+), 139 deletions(-) > create mode 100644 arch/x86/include/asm/insn-kernel.h > create mode 100644 arch/x86/lib/insn-kernel.c > > diff --git a/arch/x86/include/asm/insn-kernel.h b/arch/x86/include/asm/insn-kernel.h > new file mode 100644 > index 0000000..aef416a > --- /dev/null > +++ b/arch/x86/include/asm/insn-kernel.h > @@ -0,0 +1,16 @@ > +#ifndef _ASM_X86_INSN_KERNEL_H > +#define _ASM_X86_INSN_KERNEL_H > +/* > + * A collection of utility functions for x86 instruction analysis to be > + * used in a kernel context. Useful when, for instance, making sense > + * of the registers indicated by operands. > + */ > + > +#include <linux/compiler.h> > +#include <linux/bug.h> > +#include <linux/err.h> > +#include <asm/ptrace.h> > + > +void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs); > + > +#endif /* _ASM_X86_INSN_KERNEL_H */ > diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile > index 34a7413..d33eff1 100644 > --- a/arch/x86/lib/Makefile > +++ b/arch/x86/lib/Makefile > @@ -23,7 +23,7 @@ lib-y := delay.o misc.o cmdline.o cpu.o > lib-y += usercopy_$(BITS).o usercopy.o getuser.o putuser.o > lib-y += memcpy_$(BITS).o > lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o > -lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o > +lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o insn-kernel.o > lib-$(CONFIG_RANDOMIZE_BASE) += kaslr.o > > obj-y += msr.o msr-reg.o msr-reg-export.o hweight.o > diff --git a/arch/x86/lib/insn-kernel.c b/arch/x86/lib/insn-kernel.c > new file mode 100644 > index 0000000..8072abe > --- /dev/null > +++ b/arch/x86/lib/insn-kernel.c > @@ -0,0 +1,147 @@ > +/* > + * Utility functions for x86 operand and address decoding > + * > + * Copyright (C) Intel Corporation 2016 > + */ > +#include <linux/kernel.h> > +#include <linux/string.h> > +#include <asm/inat.h> > +#include <asm/insn.h> > +#include <asm/insn-kernel.h> > + > +enum reg_type { > + REG_TYPE_RM = 0, > + REG_TYPE_INDEX, > + REG_TYPE_BASE, > +}; > + > +static int get_reg_offset(struct insn *insn, struct pt_regs *regs, > + enum reg_type type) > +{ > + int regno = 0; > + > + static const int regoff[] = { > + offsetof(struct pt_regs, ax), > + offsetof(struct pt_regs, cx), > + offsetof(struct pt_regs, dx), > + offsetof(struct pt_regs, bx), > + offsetof(struct pt_regs, sp), > + offsetof(struct pt_regs, bp), > + offsetof(struct pt_regs, si), > + offsetof(struct pt_regs, di), > +#ifdef CONFIG_X86_64 > + offsetof(struct pt_regs, r8), > + offsetof(struct pt_regs, r9), > + offsetof(struct pt_regs, r10), > + offsetof(struct pt_regs, r11), > + offsetof(struct pt_regs, r12), > + offsetof(struct pt_regs, r13), > + offsetof(struct pt_regs, r14), > + offsetof(struct pt_regs, r15), > +#endif > + }; > + int nr_registers = ARRAY_SIZE(regoff); > + /* > + * Don't possibly decode a 32-bit instructions as > + * reading a 64-bit-only register. > + */ > + if (IS_ENABLED(CONFIG_X86_64) && !insn->x86_64) > + nr_registers -= 8; > + > + switch (type) { > + case REG_TYPE_RM: > + regno = X86_MODRM_RM(insn->modrm.value); > + if (X86_REX_B(insn->rex_prefix.value)) > + regno += 8; > + break; > + > + case REG_TYPE_INDEX: > + regno = X86_SIB_INDEX(insn->sib.value); > + if (X86_REX_X(insn->rex_prefix.value)) > + regno += 8; > + /* > + * If mod !=3, register R/ESP (regno=4) is not used as index in > + * the address computation. Check is done after looking at REX.X > + * This is because R12 (regno=12) can be used as an index. > + */ > + if (regno == 4 && X86_MODRM_MOD(insn->modrm.value) != 3) > + return -EINVAL; > + break; > + > + case REG_TYPE_BASE: > + regno = X86_SIB_BASE(insn->sib.value); > + /* > + * If R/EBP (regno = 5) is indicated in the base part of the SIB > + * byte, an explicit displacement must be specified. In other > + * words, the mod part of the ModRM byte cannot be zero. > + */ > + if (regno == 5 && X86_MODRM_MOD(insn->modrm.value) == 0) > + return -EINVAL; > + > + if (X86_REX_B(insn->rex_prefix.value)) > + regno += 8; > + break; > + > + default: > + pr_err("invalid register type"); > + BUG(); > + break; > + } > + > + if (regno >= nr_registers) { > + WARN_ONCE(1, "decoded an instruction with an invalid register"); > + return -EINVAL; > + } > + return regoff[regno]; > +} > + > +/* > + * return the address being referenced be instruction > + * for rm=3 returning the content of the rm reg > + * for rm!=3 calculates the address using SIB and Disp > + */ > +void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs) > +{ > + unsigned long addr, base, indx; > + int addr_offset, base_offset, indx_offset; > + insn_byte_t sib; > + > + insn_get_modrm(insn); > + insn_get_sib(insn); > + sib = insn->sib.value; > + > + if (X86_MODRM_MOD(insn->modrm.value) == 3) { > + addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM); > + if (addr_offset < 0) > + goto out_err; > + addr = regs_get_register(regs, addr_offset); > + } else { > + if (insn->sib.nbytes) { > + base_offset = get_reg_offset(insn, regs, REG_TYPE_BASE); > + if (base_offset < 0) > + goto out_err; > + > + indx_offset = get_reg_offset(insn, regs, REG_TYPE_INDEX); > + /* > + * A negative offset means that the register cannot be > + * be used as an index. > + */ > + if (indx_offset < 0) > + indx = 0; > + else > + indx = regs_get_register(regs, indx_offset); > + > + base = regs_get_register(regs, base_offset); > + addr = base + indx * (1 << X86_SIB_SCALE(sib)); > + } else { > + addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM); > + if (addr_offset < 0) > + goto out_err; > + addr = regs_get_register(regs, addr_offset); > + } > + addr += insn->displacement.value; > + } > + return (void __user *)addr; > +out_err: > + return (void __user *)-1; > +} > diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c > index c59a851..ca6fe13 100644 > --- a/arch/x86/mm/mpx.c > +++ b/arch/x86/mm/mpx.c > @@ -11,6 +11,7 @@ > #include <linux/sched/sysctl.h> > > #include <asm/insn.h> > +#include <asm/insn-kernel.h> > #include <asm/mman.h> > #include <asm/mmu_context.h> > #include <asm/mpx.h> > @@ -59,143 +60,6 @@ static unsigned long mpx_mmap(unsigned long len) > return addr; > } > > -enum reg_type { > - REG_TYPE_RM = 0, > - REG_TYPE_INDEX, > - REG_TYPE_BASE, > -}; > - > -static int get_reg_offset(struct insn *insn, struct pt_regs *regs, > - enum reg_type type) > -{ > - int regno = 0; > - > - static const int regoff[] = { > - offsetof(struct pt_regs, ax), > - offsetof(struct pt_regs, cx), > - offsetof(struct pt_regs, dx), > - offsetof(struct pt_regs, bx), > - offsetof(struct pt_regs, sp), > - offsetof(struct pt_regs, bp), > - offsetof(struct pt_regs, si), > - offsetof(struct pt_regs, di), > -#ifdef CONFIG_X86_64 > - offsetof(struct pt_regs, r8), > - offsetof(struct pt_regs, r9), > - offsetof(struct pt_regs, r10), > - offsetof(struct pt_regs, r11), > - offsetof(struct pt_regs, r12), > - offsetof(struct pt_regs, r13), > - offsetof(struct pt_regs, r14), > - offsetof(struct pt_regs, r15), > -#endif > - }; > - int nr_registers = ARRAY_SIZE(regoff); > - /* > - * Don't possibly decode a 32-bit instructions as > - * reading a 64-bit-only register. > - */ > - if (IS_ENABLED(CONFIG_X86_64) && !insn->x86_64) > - nr_registers -= 8; > - > - switch (type) { > - case REG_TYPE_RM: > - regno = X86_MODRM_RM(insn->modrm.value); > - if (X86_REX_B(insn->rex_prefix.value)) > - regno += 8; > - break; > - > - case REG_TYPE_INDEX: > - regno = X86_SIB_INDEX(insn->sib.value); > - if (X86_REX_X(insn->rex_prefix.value)) > - regno += 8; > - /* > - * If mod !=3, register R/ESP (regno=4) is not used as index in > - * the address computation. Check is done after looking at REX.X > - * This is because R12 (regno=12) can be used as an index. > - */ > - if (regno == 4 && X86_MODRM_MOD(insn->modrm.value) != 3) > - return -EINVAL; > - break; > - > - case REG_TYPE_BASE: > - regno = X86_SIB_BASE(insn->sib.value); > - /* > - * If R/EBP (regno = 5) is indicated in the base part of the SIB > - * byte, an explicit displacement must be specified. In other > - * words, the mod part of the ModRM byte cannot be zero. > - */ > - if (regno == 5 && X86_MODRM_MOD(insn->modrm.value) == 0) > - return -EINVAL; > - > - if (X86_REX_B(insn->rex_prefix.value)) > - regno += 8; > - break; > - > - default: > - pr_err("invalid register type"); > - BUG(); > - break; > - } > - > - if (regno >= nr_registers) { > - WARN_ONCE(1, "decoded an instruction with an invalid register"); > - return -EINVAL; > - } > - return regoff[regno]; > -} > - > -/* > - * return the address being referenced be instruction > - * for rm=3 returning the content of the rm reg > - * for rm!=3 calculates the address using SIB and Disp > - */ > -static void __user *mpx_get_addr_ref(struct insn *insn, struct pt_regs *regs) > -{ > - unsigned long addr, base, indx; > - int addr_offset, base_offset, indx_offset; > - insn_byte_t sib; > - > - insn_get_modrm(insn); > - insn_get_sib(insn); > - sib = insn->sib.value; > - > - if (X86_MODRM_MOD(insn->modrm.value) == 3) { > - addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM); > - if (addr_offset < 0) > - goto out_err; > - addr = regs_get_register(regs, addr_offset); > - } else { > - if (insn->sib.nbytes) { > - base_offset = get_reg_offset(insn, regs, REG_TYPE_BASE); > - if (base_offset < 0) > - goto out_err; > - > - indx_offset = get_reg_offset(insn, regs, REG_TYPE_INDEX); > - /* > - * A negative offset means that the register cannot be > - * be used as an index. > - */ > - if (indx_offset < 0) > - indx = 0; > - else > - indx = regs_get_register(regs, indx_offset); > - > - base = regs_get_register(regs, base_offset); > - addr = base + indx * (1 << X86_SIB_SCALE(sib)); > - } else { > - addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM); > - if (addr_offset < 0) > - goto out_err; > - addr = regs_get_register(regs, addr_offset); > - } > - addr += insn->displacement.value; > - } > - return (void __user *)addr; > -out_err: > - return (void __user *)-1; > -} > - > static int mpx_insn_decode(struct insn *insn, > struct pt_regs *regs) > { > @@ -308,7 +172,7 @@ siginfo_t *mpx_generate_siginfo(struct pt_regs *regs) > info->si_signo = SIGSEGV; > info->si_errno = 0; > info->si_code = SEGV_BNDERR; > - info->si_addr = mpx_get_addr_ref(&insn, regs); > + info->si_addr = insn_get_addr_ref(&insn, regs); > /* > * We were not able to extract an address from the instruction, > * probably because there was something invalid in it. > -- > 2.9.3 > -- Masami Hiramatsu <mhiramat(a)kernel.org>

Jan. 26, 2017

Re: [v3 PATCH 04/10] x86/insn-kernel: Add a function to obtain register offset in ModRM

by Masami Hiramatsu

On Wed, 25 Jan 2017 12:23:47 -0800 Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> wrote: > The function insn_get_reg_offset requires a type to indicate whether > the returned offset is that given by by the ModRM or the SIB byte. > Callers of this function would need the definition of the type struct. > This is not needed. Instead, auxiliary functions can be defined for > this purpose. > > When the operand is a register, the emulation code for User-Mode > Instruction Prevention needs to know the offset of the register indicated > in the r/m part of the ModRM byte. Thus, start by adding an auxiliary > function for this purpose. Hmm, why wouldn't you just rename it to insn_get_reg_offset() and export it? Thank you, > > Cc: Dave Hansen <dave.hansen(a)linux.intel.com> > Cc: Adam Buchbinder <adam.buchbinder(a)gmail.com> > Cc: Colin Ian King <colin.king(a)canonical.com> > Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> > Cc: Qiaowei Ren <qiaowei.ren(a)intel.com> > Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> > Cc: Masami Hiramatsu <mhiramat(a)kernel.org> > Cc: Adrian Hunter <adrian.hunter(a)intel.com> > Cc: Kees Cook <keescook(a)chromium.org> > Cc: Thomas Garnier <thgarnie(a)google.com> > Cc: Peter Zijlstra <peterz(a)infradead.org> > Cc: Borislav Petkov <bp(a)suse.de> > Cc: Dmitry Vyukov <dvyukov(a)google.com> > Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> > Cc: x86(a)kernel.org > Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> > --- > arch/x86/include/asm/insn-kernel.h | 1 + > arch/x86/lib/insn-kernel.c | 5 +++++ > 2 files changed, 6 insertions(+) > > diff --git a/arch/x86/include/asm/insn-kernel.h b/arch/x86/include/asm/insn-kernel.h > index aef416a..3f34649 100644 > --- a/arch/x86/include/asm/insn-kernel.h > +++ b/arch/x86/include/asm/insn-kernel.h > @@ -12,5 +12,6 @@ > #include <asm/ptrace.h> > > void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs); > +int insn_get_reg_offset_rm(struct insn *insn, struct pt_regs *regs); > > #endif /* _ASM_X86_INSN_KERNEL_H */ > diff --git a/arch/x86/lib/insn-kernel.c b/arch/x86/lib/insn-kernel.c > index 8072abe..267cab4 100644 > --- a/arch/x86/lib/insn-kernel.c > +++ b/arch/x86/lib/insn-kernel.c > @@ -95,6 +95,11 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs, > return regoff[regno]; > } > > +int insn_get_reg_offset_rm(struct insn *insn, struct pt_regs *regs) > +{ > + return get_reg_offset(insn, regs, REG_TYPE_RM); > +} > + > /* > * return the address being referenced be instruction > * for rm=3 returning the content of the rm reg > -- > 2.9.3 > -- Masami Hiramatsu <mhiramat(a)kernel.org>

Jan. 26, 2017

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings

by H. Peter Anvin

Buchbinder <adam.buchbinder(a)gmail.com>,Colin Ian King <colin.king(a)canonical.com>,Lorenzo Stoakes <lstoakes(a)gmail.com>,Qiaowei Ren <qiaowei.ren(a)intel.com>,Arnaldo Carvalho de Melo <acme(a)redhat.com>,Adrian Hunter <adrian.hunter(a)intel.com>,Kees Cook <keescook(a)chromium.org>,Thomas Garnier <thgarnie(a)google.com>,Dmitry Vyukov <dvyukov(a)google.com> From: hpa(a)zytor.com Message-ID: <18E8698F-6C60-4B98-AE73-C371184C5135(a)zytor.com> On January 25, 2017 1:58:27 PM PST, Andy Lutomirski <luto(a)amacapital.net> wrote: >On Wed, Jan 25, 2017 at 12:23 PM, Ricardo Neri ><ricardo.neri-calderon(a)linux.intel.com> wrote: >> Tasks running in virtual-8086 mode will use 16-bit addressing form >> encodings as described in the Intel 64 and IA-32 Architecture >Software >> Developer's Manual Volume 2A Section 2.1.5. 16-bit addressing >encodings >> differ in several ways from the 32-bit/64-bit addressing form >encodings: >> the r/m part of the ModRM byte points to different registers and, in >some >> cases, addresses can be indicated by the addition of the value of two >> registers. Also, there is no support for SiB bytes. Thus, a separate >> function is needed to parse this form of addressing. >> >> Furthermore, virtual-8086 mode tasks will use real-mode addressing. >This >> implies that the segment selectors do not point to a segment >descriptor >> but are used to compute logical addresses. Hence, there is a need to >> add support to compute addresses using the segment selectors. If >segment- >> override prefixes are present in the instructions, they take >precedence. >> >> Lastly, it is important to note that when a tasks is running in >virtual- >> 8086 mode and an interrupt/exception occurs, the CPU pushes to the >stack >> the segment selectors for ds, es, fs and gs. These are accesible via >the >> struct kernel_vm86_regs rather than pt_regs. >> >> Code for 16-bit addressing encodings is likely to be used only by >virtual- >> 8086 mode tasks. Thus, this code is wrapped to be built only if the >> option CONFIG_VM86 is selected. > >That's not true. It's used in 16-bit protected mode, too. And there >are (ugh!) six possibilities: > > - Normal 32-bit protected mode. This should already work. > - Normal 64-bit protected mode. This should also already work. (I >forget whether a 16-bit SS is either illegal or has no effect in this >case.) > - Virtual 8086 mode > - Normal 16-bit protected mode, used by DOSEMU and Wine. (16-bit CS, >16-bit address segment) > - 16-bit CS, 32-bit address segment. IIRC this might be used by some >32-bit DOS programs to call BIOS. >- 32-bit CS, 16-bit address segment. I don't know whether anything >uses this. > >I don't know if anything you're doing cares about SS's, DS's, etc. >size, but I suspect you'll need to handle 16-bit CS. Only the CS bitness matters for the purpose of addressing modes; the SS bitness (which has no effect in 64-bit mode) only matters for implicit stack references unless I'm completely out to sea. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Jan. 25, 2017

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings

by Andy Lutomirski

On Wed, Jan 25, 2017 at 12:23 PM, Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> wrote: > Tasks running in virtual-8086 mode will use 16-bit addressing form > encodings as described in the Intel 64 and IA-32 Architecture Software > Developer's Manual Volume 2A Section 2.1.5. 16-bit addressing encodings > differ in several ways from the 32-bit/64-bit addressing form encodings: > the r/m part of the ModRM byte points to different registers and, in some > cases, addresses can be indicated by the addition of the value of two > registers. Also, there is no support for SiB bytes. Thus, a separate > function is needed to parse this form of addressing. > > Furthermore, virtual-8086 mode tasks will use real-mode addressing. This > implies that the segment selectors do not point to a segment descriptor > but are used to compute logical addresses. Hence, there is a need to > add support to compute addresses using the segment selectors. If segment- > override prefixes are present in the instructions, they take precedence. > > Lastly, it is important to note that when a tasks is running in virtual- > 8086 mode and an interrupt/exception occurs, the CPU pushes to the stack > the segment selectors for ds, es, fs and gs. These are accesible via the > struct kernel_vm86_regs rather than pt_regs. > > Code for 16-bit addressing encodings is likely to be used only by virtual- > 8086 mode tasks. Thus, this code is wrapped to be built only if the > option CONFIG_VM86 is selected. That's not true. It's used in 16-bit protected mode, too. And there are (ugh!) six possibilities: - Normal 32-bit protected mode. This should already work. - Normal 64-bit protected mode. This should also already work. (I forget whether a 16-bit SS is either illegal or has no effect in this case.) - Virtual 8086 mode - Normal 16-bit protected mode, used by DOSEMU and Wine. (16-bit CS, 16-bit address segment) - 16-bit CS, 32-bit address segment. IIRC this might be used by some 32-bit DOS programs to call BIOS. - 32-bit CS, 16-bit address segment. I don't know whether anything uses this. I don't know if anything you're doing cares about SS's, DS's, etc. size, but I suspect you'll need to handle 16-bit CS.

Jan. 25, 2017

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings (fwd)

by Julia Lawall

Check the type of seg on line 267. julia ---------- Forwarded message ---------- Date: Thu, 26 Jan 2017 05:24:40 +0800 From: kbuild test robot <fengguang.wu(a)intel.com> To: kbuild(a)01.org Cc: Julia Lawall <julia.lawall(a)lip6.fr> Subject: Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings In-Reply-To: <20170125202353.101059-6-ricardo.neri-calderon(a)linux.intel.com> Hi Ricardo, [auto build test WARNING on tip/auto-latest] [also build test WARNING on v4.10-rc5 next-20170125] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ricardo-Neri/x86-Enable-User-Mode-… :::::: branch date: 51 minutes ago :::::: commit date: 51 minutes ago >> arch/x86/lib/insn-kernel.c:267:6-9: WARNING: Unsigned expression compared with zero: seg < 0 git remote add linux-review https://github.com/0day-ci/linux git remote update linux-review git checkout 574de0de238ef30c816985006f02f7a1dbba92aa vim +267 arch/x86/lib/insn-kernel.c 574de0de Ricardo Neri 2017-01-25 251 addr = (seg << 4) + regs_get_register(regs, addr_offset1); 574de0de Ricardo Neri 2017-01-25 252 } else { 574de0de Ricardo Neri 2017-01-25 253 ret = get_reg_offset_16(insn, regs, &addr_offset1, 574de0de Ricardo Neri 2017-01-25 254 &addr_offset2); 574de0de Ricardo Neri 2017-01-25 255 if (ret < 0) 574de0de Ricardo Neri 2017-01-25 256 goto out_err; 574de0de Ricardo Neri 2017-01-25 257 /* 574de0de Ricardo Neri 2017-01-25 258 * Don't fail on invalid offset values. They might be invalid 574de0de Ricardo Neri 2017-01-25 259 * because they are not supported. Instead, use them in the 574de0de Ricardo Neri 2017-01-25 260 * calculation only if they contain a valid value. 574de0de Ricardo Neri 2017-01-25 261 */ 574de0de Ricardo Neri 2017-01-25 262 if (addr_offset1 >= 0) 574de0de Ricardo Neri 2017-01-25 263 addr1 = regs_get_register(regs, addr_offset1); 574de0de Ricardo Neri 2017-01-25 264 if (addr_offset2 >= 0) 574de0de Ricardo Neri 2017-01-25 265 addr2 = regs_get_register(regs, addr_offset2); 574de0de Ricardo Neri 2017-01-25 266 seg = __get_segment_selector_16(regs, insn, addr_offset1); 574de0de Ricardo Neri 2017-01-25 @267 if (seg < 0) 574de0de Ricardo Neri 2017-01-25 268 goto out_err; 574de0de Ricardo Neri 2017-01-25 269 addr = (seg << 4) + addr1 + addr2; 574de0de Ricardo Neri 2017-01-25 270 } 574de0de Ricardo Neri 2017-01-25 271 addr += insn->displacement.value; 574de0de Ricardo Neri 2017-01-25 272 574de0de Ricardo Neri 2017-01-25 273 return (void __user *)addr; 574de0de Ricardo Neri 2017-01-25 274 out_err: 574de0de Ricardo Neri 2017-01-25 275 return (void __user *)-1; --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

Jan. 25, 2017

Re: [v3 PATCH 07/10] x86: Add emulation code for UMIP instructions

by H. Peter Anvin

On 01/25/17 12:23, Ricardo Neri wrote: > + case UMIP_SMSW: > + dummy_value = CR0_STATE; Unless the user space process is running in 64-bit mode this value should be & 0xffff. I'm not sure if we should even support fixing up UMIP instructions in 64-bit mode. Also, please put an explicit /* fall through */ here. > + /* > + * These two instructions return a 16-bit value. We return > + * all zeros. This is equivalent to a null descriptor for > + * str and sldt. > + */ > + case UMIP_SLDT: > + case UMIP_STR: > + /* if operand is a register, it is zero-extended*/ > + if (X86_MODRM_MOD(insn->modrm.value) == 3) { > + memset(data, 0, insn->opnd_bytes); > + *data_size = insn->opnd_bytes; > + /* if not, only the two least significant bytes are copied */ > + } else { > + *data_size = 2; > + } > + memcpy(data, &dummy_value, sizeof(dummy_value)); > + break; > + default: > + return -EINVAL; > + } > + return 0; > +bool fixup_umip_exception(struct pt_regs *regs) > +{ > + struct insn insn; > + unsigned char buf[MAX_INSN_SIZE]; > + /* 10 bytes is the maximum size of the result of UMIP instructions */ > + unsigned char dummy_data[10] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}; > +#ifdef CONFIG_X86_64 > + int x86_64 = user_64bit_mode(regs); > +#else > + int x86_64 = 0; > +#endif Again, could we simply do: if (user_64bit_mode(regs)) return false; or are there known users of these instructions *in 64-bit mode*? -hpa

Jan. 25, 2017

Re: [v3 PATCH 00/10] x86: Enable User-Mode Instruction Prevention

by H. Peter Anvin

On 01/25/17 12:23, Ricardo Neri wrote: > * SMSW returns the value with which the CR0 register is programmed in > head_32/64.S at boot time. This is, the following bits are enabed: > CR0.0 for Protection Enable, CR.1 for Monitor Coprocessor, CR.4 for > Extension Type, which will always be 1 in recent processors with UMIP; > CR.5 for Numeric Error, CR0.16 for Write Protect, CR0.18 for Alignment > Mask. Additionally, in x86_64, CR0.31 for Paging is set. SMSW only returns CR0[15:0], so the reference here to CR0[31:16] seems odd. -hpa

Jan. 25, 2017

[v3 PATCH 10/10] selftests/x86: Add tests for User-Mode Instruction Prevention

by Ricardo Neri

Certain user space programs that run on virtual-8086 mode may utilize instructions protected by the User-Mode Instruction Prevention (UMIP) security feature present in new Intel processors: SGDT, SIDT and SMSW. In such a case, a general protection fault is issued if UMIP is enabled. When such a fault happens, the kernel catches it and emulates the results of these instructions with dummy values. The purpose of this new test is to verify whether the impacted instructions can be executed without causing such #GP. If no #GP exceptions occur, we expect to exit virtual- 8086 mode from INT 0x80. The instructions protected by UMIP are executed in representative use cases: a) the memory address of the result is given in the form of a displacement from the base of the data segment b) the memory address of the result is given in a general purpose register c) the result is stored directly in a general purpose register. Unfortunately, it is not possible to check the results against a set of expected values because no emulation will occur in systems that do not have the UMIP feature. Instead, results are printed for verification. Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Chen Yucong <slaoub(a)gmail.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> --- tools/testing/selftests/x86/entry_from_vm86.c | 39 ++++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/x86/entry_from_vm86.c b/tools/testing/selftests/x86/entry_from_vm86.c index d075ea0..377b773 100644 --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -95,6 +95,22 @@ asm ( "int3\n\t" "vmcode_int80:\n\t" "int $0x80\n\t" + "umip:\n\t" + /* addressing via displacements */ + "smsw (2052)\n\t" + "sidt (2054)\n\t" + "sgdt (2060)\n\t" + /* addressing via registers */ + "mov $2066, %bx\n\t" + "smsw (%bx)\n\t" + "mov $2068, %bx\n\t" + "sidt (%bx)\n\t" + "mov $2074, %bx\n\t" + "sgdt (%bx)\n\t" + /* register operands, only for smsw */ + "smsw %ax\n\t" + "mov %ax, (2080)\n\t" + "int $0x80\n\t" ".size vmcode, . - vmcode\n\t" "end_vmcode:\n\t" ".code32\n\t" @@ -103,7 +119,7 @@ asm ( extern unsigned char vmcode[], end_vmcode[]; extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], umip[]; /* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip, @@ -218,6 +234,27 @@ int main(void) v86.regs.eax = (unsigned int)-1; do_test(&v86, vmcode_int80 - vmcode, VM86_INTx, 0x80, "int80"); + /* UMIP -- should exit with INTx 0x80 unless UMIP was not disabled */ + do_test(&v86, umip - vmcode, VM86_INTx, 0x80, "UMIP tests"); + printf("[INFO]\tResults of UMIP-protected instructions via displacements:\n"); + printf("[INFO]\tSMSW:[0x%04x]\n", *(unsigned short *)(addr + 2052)); + printf("[INFO]\tSIDT: limit[0x%04x]base[0x%08lx]\n", + *(unsigned short *)(addr + 2054), + *(unsigned long *)(addr + 2056)); + printf("[INFO]\tSGDT: limit[0x%04x]base[0x%08lx]\n", + *(unsigned short *)(addr + 2060), + *(unsigned long *)(addr + 2062)); + printf("[INFO]\tResults of UMIP-protected instructions via addressing in registers:\n"); + printf("[INFO]\tSMSW:[0x%04x]\n", *(unsigned short *)(addr + 2066)); + printf("[INFO]\tSIDT: limit[0x%04x]base[0x%08lx]\n", + *(unsigned short *)(addr + 2068), + *(unsigned long *)(addr + 2070)); + printf("[INFO]\tSGDT: limit[0x%04x]base[0x%08lx]\n", + *(unsigned short *)(addr + 2074), + *(unsigned long *)(addr + 2076)); + printf("[INFO]\tResults of SMSW via register operands:\n"); + printf("[INFO]\tSMSW:[0x%04x]\n", *(unsigned short *)(addr + 2080)); + /* Execute a null pointer */ v86.regs.cs = 0; v86.regs.ss = 0; -- 2.9.3

Jan. 25, 2017

[v3 PATCH 09/10] x86: Enable User-Mode Instruction Prevention

by Ricardo Neri

User_mode Instruction Prevention (UMIP) is enabled by setting/clearing a bit in %cr4. It makes sense to enable UMIP at some point while booting, before user spaces come up. Like SMAP and SMEP, is not critical to have it enabled very early during boot. This is because UMIP is relevant only when there is a userspace to be protected from. Given the similarities in relevance, it makes sense to enable UMIP along with SMAP and SMEP. UMIP is enabled by default. It can be disabled by adding clearcpuid=514 to the kernel parameters. Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Chen Yucong <slaoub(a)gmail.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Liang Z. Li <liang.z.li(a)intel.com> Cc: Alexandre Julliard <julliard(a)winehq.org> Cc: Stas Sergeev <stsp(a)list.ru> Cc: x86(a)kernel.org Cc: linux-msdos(a)vger.kernel.org Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> --- arch/x86/Kconfig | 10 ++++++++++ arch/x86/kernel/cpu/common.c | 16 +++++++++++++++- 2 files changed, 25 insertions(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 7b6fd68..824c6de 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1733,6 +1733,16 @@ config X86_SMAP If unsure, say Y. +config X86_INTEL_UMIP + def_bool y + depends on CPU_SUP_INTEL + prompt "User Mode Instruction Prevention" if EXPERT + ---help--- + The User Mode Instruction Prevention (UMIP) is a security + feature in newer Intel processors. If enabled, a general + protection fault is issued if the instructions SGDT, SLDT, + SIDT, SMSW and STR are executed in user mode. + config X86_INTEL_MPX prompt "Intel MPX (Memory Protection Extensions)" def_bool n diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index f74e84e..f5f31c2 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -307,6 +307,19 @@ static __always_inline void setup_smap(struct cpuinfo_x86 *c) } } +static __always_inline void setup_umip(struct cpuinfo_x86 *c) +{ + if (cpu_feature_enabled(X86_FEATURE_UMIP) && + cpu_has(c, X86_FEATURE_UMIP)) + cr4_set_bits(X86_CR4_UMIP); + else + /* + * Make sure UMIP is disabled in case it was enabled in a + * previous boot (e.g., via kexec). + */ + cr4_clear_bits(X86_CR4_UMIP); +} + /* * Protection Keys are not available in 32-bit mode. */ @@ -1077,9 +1090,10 @@ static void identify_cpu(struct cpuinfo_x86 *c) /* Disable the PN if appropriate */ squash_the_stupid_serial_number(c); - /* Set up SMEP/SMAP */ + /* Set up SMEP/SMAP/UMIP */ setup_smep(c); setup_smap(c); + setup_umip(c); /* * The vendor-specific functions might have changed features. -- 2.9.3

Jan. 25, 2017

[v3 PATCH 08/10] x86/traps: Fixup general protection faults caused by UMIP

by Ricardo Neri

If the User-Mode Instruction Prevention CPU feature is available and enabled, a general protection fault will be issued if the instructions sgdt, sldt, sidt, str or smsw are executed from user-mode context (CPL > 0). If the fault was caused by any of the instructions protected by UMIP, fixup_umip_exception will emulate dummy results for these instructions. If emulation is successful, the result is passed to the user space program and no SIGSEGV signal is emitted. Please note that fixup_umip_exception also caters for the case when the fault originated while running in virtual-8086 mode. Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Chen Yucong <slaoub(a)gmail.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Liang Z. Li <liang.z.li(a)intel.com> Cc: Alexandre Julliard <julliard(a)winehq.org> Cc: Stas Sergeev <stsp(a)list.ru> Cc: x86(a)kernel.org Cc: linux-msdos(a)vger.kernel.org Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> --- arch/x86/kernel/traps.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index bf0c6d0..1da2f8d 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -64,6 +64,7 @@ #include <asm/trace/mpx.h> #include <asm/mpx.h> #include <asm/vm86.h> +#include <asm/umip.h> #ifdef CONFIG_X86_64 #include <asm/x86_init.h> @@ -491,6 +492,9 @@ do_general_protection(struct pt_regs *regs, long error_code) RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU"); cond_local_irq_enable(regs); + if (user_mode(regs) && (fixup_umip_exception(regs) == true)) + return; + if (v8086_mode(regs)) { local_irq_enable(); handle_vm86_fault((struct kernel_vm86_regs *) regs, error_code); -- 2.9.3

Jan. 25, 2017

[v3 PATCH 07/10] x86: Add emulation code for UMIP instructions

by Ricardo Neri

The feature User-Mode Instruction Prevention present in recent Intel processor prevents a group of instructions from being executed with CPL > 0. Otherwise, a general protection fault is issued. Rather than relaying this fault to the user space (in the form of a SIGSEGV signal), the instructions protected by UMIP can be emulated to provide dummy results. This allows to conserve the current kernel behavior and not reveal the system resources that UMIP intends to protect (the global descriptor and interrupt descriptor tables, the segment selectors of the local descriptor table and the task state and the machine status word). This emulation is needed because certain applications (e.g., WineHQ) rely on this subset of instructions to function. The instructions protected by UMIP can be split in two groups. Those who return a kernel memory address (sgdt and sidt) and those who return a value (sldt, str and smsw). For the instructions that return a kernel memory address. This is needed as applications such as WineHQ rely on the result being located in the kernel memory space function. The result is emulated as a hard-coded value that, in x86_64, lies in one of the memory holes in the kernel memory map. For i386, the same values are used but truncated to 4 bytes. the location of a dummy variable in the kernel memory space. The limit for the GDT and the IDT are set to zero. The instructions sldt and str return a segment selector relative to the base address of the global descriptor table. Since the actual address of such table is not revealed, it makes sense to emulate the result as zero. The instruction smsw is emulated to return the value that the register CR0 has at boot time as set in the head_32/64.S files. Given that these particular instructions are especially important for virtual-8086 tasks, care is taken to appropriately emulate the results in this particular case: utilize segment selectors to form addresses and parse the contents of the general purpose results in 16-bit addressing encodings. Lastly, it might be possible that the memory address to which the results must be written is not accessible. In such a case a SIGSEGV signal is generated with error code equal to SEGV_MAPERR. Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Chen Yucong <slaoub(a)gmail.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Liang Z. Li <liang.z.li(a)intel.com> Cc: Alexandre Julliard <julliard(a)winehq.org> Cc: Stas Sergeev <stsp(a)list.ru> Cc: x86(a)kernel.org Cc: linux-msdos(a)vger.kernel.org Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> --- arch/x86/include/asm/umip.h | 15 +++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/umip.c | 251 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 267 insertions(+) create mode 100644 arch/x86/include/asm/umip.h create mode 100644 arch/x86/kernel/umip.c diff --git a/arch/x86/include/asm/umip.h b/arch/x86/include/asm/umip.h new file mode 100644 index 0000000..077b236 --- /dev/null +++ b/arch/x86/include/asm/umip.h @@ -0,0 +1,15 @@ +#ifndef _ASM_X86_UMIP_H +#define _ASM_X86_UMIP_H + +#include <linux/types.h> +#include <asm/ptrace.h> + +#ifdef CONFIG_X86_INTEL_UMIP +bool fixup_umip_exception(struct pt_regs *regs); +#else +static inline bool fixup_umip_exception(struct pt_regs *regs) +{ + return false; +} +#endif /* CONFIG_X86_INTEL_UMIP */ +#endif /* _ASM_X86_UMIP_H */ diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 581386c..c4aec02 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -124,6 +124,7 @@ obj-$(CONFIG_EFI) += sysfb_efi.o obj-$(CONFIG_PERF_EVENTS) += perf_regs.o obj-$(CONFIG_TRACING) += tracepoint.o obj-$(CONFIG_SCHED_MC_PRIO) += itmt.o +obj-$(CONFIG_X86_INTEL_UMIP) += umip.o ifdef CONFIG_FRAME_POINTER obj-y += unwind_frame.o diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c new file mode 100644 index 0000000..229f7a0 --- /dev/null +++ b/arch/x86/kernel/umip.c @@ -0,0 +1,251 @@ +/* + * umip.c Emulation for instruction protected by the Intel User-Mode + * Instruction Prevention. The instructions are: + * sgdt + * sldt + * sidt + * str + * smsw + * + * Copyright (c) 2016, Intel Corporation. + * Ricardo Neri <ricardo.neri(a)linux.intel.com> + */ + +#include <linux/uaccess.h> +#include <asm/umip.h> +#include <asm/traps.h> +#include <asm/insn.h> +#include <asm/insn-kernel.h> +#include <linux/ratelimit.h> + +/* + * == Base addresses of GDT and IDT + * Some applications to function rely finding the global descriptor table (GDT) + * and the interrupt descriptor table (IDT) in kernel memory. For x86_64 this + * matches a memory hole as detailed in Documentation/x86/x86_64/mm.txt. + * For x86_32, it does not match any particular hole, but it suffices + * to provide a memory location within kernel memory. + * + * == CRO flags for SMSW + * Use the flags given when booting, as found in head_64/32.S + */ + +#define CR0_FLAGS (X86_CR0_PE | X86_CR0_MP | X86_CR0_ET | X86_CR0_NE | \ + X86_CR0_WP | X86_CR0_AM) +#ifdef CONFIG_X86_64 +#define UMIP_DUMMY_GDT_BASE 0xfffffffffffe0000 +#define UMIP_DUMMY_IDT_BASE 0xffffffffffff0000 +#define CR0_STATE (CR0_FLAGS | X86_CR0_PG) +#else +#define UMIP_DUMMY_GDT_BASE 0xfffe0000 +#define UMIP_DUMMY_IDT_BASE 0xffff0000 +#define CR0_STATE CR0_FLAGS +#endif + +/* + * Definitions for x86 page fault error code bits. Only a simple + * pagefault during a write in user context is supported. + */ +#define UMIP_PF_USER BIT(2) +#define UMIP_PF_WRITE BIT(1) + +enum umip_insn { + UMIP_SGDT = 0, /* opcode 0f 01 ModR/M reg 0 */ + UMIP_SIDT, /* opcode 0f 01 ModR/M reg 1 */ + UMIP_SLDT, /* opcode 0f 00 ModR/M reg 0 */ + UMIP_SMSW, /* opcode 0f 01 ModR/M reg 4 */ + UMIP_STR, /* opcode 0f 00 ModR/M reg 1 */ +}; + +static int __identify_insn(struct insn *insn) +{ + /* By getting modrm we also get the opcode. */ + insn_get_modrm(insn); + + /* All the instructions of interest start with 0x0f. */ + if (insn->opcode.bytes[0] != 0xf) + return -EINVAL; + + if (insn->opcode.bytes[1] == 0x1) { + switch (X86_MODRM_REG(insn->modrm.value)) { + case 0: + return UMIP_SGDT; + case 1: + return UMIP_SIDT; + case 4: + return UMIP_SMSW; + default: + return -EINVAL; + } + } else if (insn->opcode.bytes[1] == 0x0) { + if (X86_MODRM_REG(insn->modrm.value) == 0) + return UMIP_SLDT; + else if (X86_MODRM_REG(insn->modrm.value) == 1) + return UMIP_STR; + else + return -EINVAL; + } else { + return -EINVAL; + } +} + +static int __emulate_umip_insn(struct insn *insn, enum umip_insn umip_inst, + unsigned char *data, int *data_size) +{ + unsigned long dummy_base_addr; + unsigned short dummy_limit = 0; + unsigned int dummy_value = 0; + + switch (umip_inst) { + /* + * These two instructions return the base address and limit of the + * global and interrupt descriptor table. The base address can be + * 32-bit or 64-bit. Limit is always 16-bit. + */ + case UMIP_SGDT: + case UMIP_SIDT: + if (umip_inst == UMIP_SGDT) + dummy_base_addr = UMIP_DUMMY_GDT_BASE; + else + dummy_base_addr = UMIP_DUMMY_IDT_BASE; + if (X86_MODRM_MOD(insn->modrm.value) == 3) { + /* SGDT and SIDT do not take register as argument. */ + return -EINVAL; + } + /* Fill most significant byte with zeros if 16-bit addressing*/ + if (insn->addr_bytes == 2) + dummy_base_addr &= 0xffffff; + memcpy(data + 2, &dummy_base_addr, sizeof(dummy_base_addr)); + memcpy(data, &dummy_limit, sizeof(dummy_limit)); + *data_size = sizeof(dummy_base_addr) + sizeof(dummy_limit); + break; + case UMIP_SMSW: + dummy_value = CR0_STATE; + /* + * These two instructions return a 16-bit value. We return + * all zeros. This is equivalent to a null descriptor for + * str and sldt. + */ + case UMIP_SLDT: + case UMIP_STR: + /* if operand is a register, it is zero-extended*/ + if (X86_MODRM_MOD(insn->modrm.value) == 3) { + memset(data, 0, insn->opnd_bytes); + *data_size = insn->opnd_bytes; + /* if not, only the two least significant bytes are copied */ + } else { + *data_size = 2; + } + memcpy(data, &dummy_value, sizeof(dummy_value)); + break; + default: + return -EINVAL; + } + return 0; +} + +static void __force_sig_info_umip_fault(void __user *address, + struct pt_regs *regs) +{ + siginfo_t info; + struct task_struct *tsk = current; + + if (show_unhandled_signals && unhandled_signal(tsk, SIGSEGV)) { + printk_ratelimited("%s[%d] umip emulation segfault ip:%lx sp:%lx error:%lx in %lx\n", + tsk->comm, task_pid_nr(tsk), regs->ip, + regs->sp, UMIP_PF_USER | UMIP_PF_WRITE, regs->ip); + } + + tsk->thread.cr2 = (unsigned long)address; + tsk->thread.error_code = UMIP_PF_USER | UMIP_PF_WRITE; + tsk->thread.trap_nr = X86_TRAP_PF; + + info.si_signo = SIGSEGV; + info.si_errno = 0; + info.si_code = SEGV_MAPERR; + info.si_addr = address; + force_sig_info(SIGSEGV, &info, tsk); +} + +bool fixup_umip_exception(struct pt_regs *regs) +{ + struct insn insn; + unsigned char buf[MAX_INSN_SIZE]; + /* 10 bytes is the maximum size of the result of UMIP instructions */ + unsigned char dummy_data[10] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}; +#ifdef CONFIG_X86_64 + int x86_64 = user_64bit_mode(regs); +#else + int x86_64 = 0; +#endif + int not_copied, nr_copied, reg_offset, dummy_data_size; + void __user *uaddr; + unsigned long *reg_addr; + enum umip_insn umip_inst; + + if (v8086_mode(regs)) + /* + * In virtual-8086 mode the segment selector cs does not point + * to a segment descriptor but is used directly to compute the + * address. This is done after shifting it 4 bytes to the left. + * The result is added to the instruction pointer. + */ + not_copied = copy_from_user(buf, + (void __user *)((regs->cs << 4) + + regs->ip), + sizeof(buf)); + else + not_copied = copy_from_user(buf, (void __user *)regs->ip, + sizeof(buf)); + nr_copied = sizeof(buf) - not_copied; + /* + * The copy_from_user above could have failed if user code is protected + * by a memory protection key. Give up on emulation in such a case. + * Should we issue a page fault? + */ + if (!nr_copied) + return false; + insn_init(&insn, buf, nr_copied, x86_64); + /* + * Set address and operand sizes to the default of 16 bits. If + * overrides are found, sizes will be fixed when parsing the instruction + * prefixes. + */ + if (v8086_mode(regs)) { + insn.addr_bytes = 2; + insn.opnd_bytes = 2; + } + insn_get_length(&insn); + if (nr_copied < insn.length) + return false; + + umip_inst = __identify_insn(&insn); + /* Check if we found an instruction protected by UMIP */ + if (umip_inst < 0) + return false; + + if (__emulate_umip_insn(&insn, umip_inst, dummy_data, &dummy_data_size)) + return false; + + /* If operand is a register, write directly to it */ + if (X86_MODRM_MOD(insn.modrm.value) == 3) { + reg_offset = insn_get_reg_offset_rm(&insn, regs); + reg_addr = (unsigned long *)((unsigned long)regs + reg_offset); + memcpy(reg_addr, dummy_data, dummy_data_size); + } else { + uaddr = insn_get_addr_ref(&insn, regs); + nr_copied = copy_to_user(uaddr, dummy_data, dummy_data_size); + if (nr_copied > 0) { + /* + * If copy fails, send a signal and tell caller that + * fault was fixed up. + */ + __force_sig_info_umip_fault(uaddr, regs); + return true; + } + } + + /* increase IP to let the program keep going */ + regs->ip += insn.length; + return true; +} -- 2.9.3

Jan. 25, 2017