April 2012 - Wine-devel - list.winehq.org

Re: GDI+ pageoffset
by Stepa Nick 11 Apr '12

11 Apr '12

> > Run with `WINEDEBUG=loaddll wine my.exe` and ensure that builtin gdiplus > is being used. I run `WINEDEBUG=loaddll wine my.exe` and get such output: > trace:loaddll:load_builtin_dll Loaded L"KERNEL32.dll" at 0x7b810000: builtin > trace:loaddll:load_native_dll Loaded L"Z:\\home\\user\\tmp\\test\\CalculateCPP.exe" at 0x400000: native > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\msvcrt.dll" at 0x72540000: builtin > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\advapi32.dll" at 0x68550000: builtin > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\gdi32.dll" at 0x684b0000: builtin > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\version.dll" at 0x6e960000: builtin > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\user32.dll" at 0x68380000: builtin > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\rpcrt4.dll" at 0x70d00000: builtin > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\ole32.dll" at 0x685c0000: builtin > trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\gdiplus.dll" at 0x4ec50000: native > trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\MSVCR100.dll" at 0x78aa0000: native > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\shlwapi.dll" at 0x686c0000: builtin > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\comctl32.dll" at 0x68720000: builtin > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\msimg32.dll" at 0x68810000: builtin > trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\mfc100u.dll" at 0x785f0000: native > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\imm32.dll" at 0x68bc0000: builtin > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winex11.drv" at 0x68980000: builtin > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\uxtheme.dll" at 0x68c10000: builtin > trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\dwmapi.dll" at 0x68c40000: builtin > trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\MFC100ENU.DLL" at 0x5d360000: native > fixme:heap:HeapSetInformation (nil) 1 (nil) 0 > fixme:win:EnumDisplayDevicesW ((null),0,0x32f744,0x00000000), stub! So, non-native gdiplus.dll used?! Hmm... Can I see into gdiplus.dll anyway? I really need to understand how pixeloffset works.

2 1

Re: ws2_32/tests: Update hostent struct tests
by Austin English 11 Apr '12

11 Apr '12

On Tue, Apr 10, 2012 at 21:13, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > * Added a final required test for the h->h_addr_list[0] to show we > must put it in the right place. > * Removed the cached use of older gethostbyname result since the > memory is static and turned into garbage in windows if the current > call fails. > * Added a skip if we hit older OS allowing we to avoid using broken() > on each test. + if(h->h_addr_list == addr.mem) /* <= W2K */ + { + skip("Skipping hostent tests since this OS is unsupported\n"); + return; + } + You should use win_skip so that the tests will only be skipped on windows (we'd want the failure to be exposed on wine). -- -Austin

2 2

Re: gdi32/dibdrv: don't add_join if points are coincident in wide_line_segments
by Alexandre Julliard 11 Apr '12

11 Apr '12

Daniel Lehman <dlehman(a)esri.com> writes: > This fixes a crash in PolyPolyline if points are in the same spot > > There were timeouts in the Testbot but were unrelated to anything I changed > > From 23edf2c2b89b98ef18849806e74b5d77f7889160 Mon Sep 17 00:00:00 2001 > From: Daniel Lehman <dlehman(a)esri.com> > Date: Wed, 25 Jan 2012 13:47:31 -0800 > Subject: gdi32/dibdrv: don't add_join if points are coincident in wide_line_segments > > if 2 points coincide (dx == dy == 0), wide_line_segments returns immediately > in that case, face_1 is not changed. it is not initialized so junk values on the > stack are used. when passed to add_join they create a region that causes a huge > amount of memory to be allocated. depending on the values, all available/rlimit > memory is exhausted and the program crashes. reverting to 1.3.26 works fine > > the test case submitted is a drastically reduced, simplest possible form of what our > internal test does, based on real map data You should integrate the test with the other graphics tests, to reuse all the infrastructure and also verify the graphics results. Also there is probably the same problem with the first and last points. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3drm: Some includes are useless
by Alexandre Julliard 11 Apr '12

11 Apr '12

Nozomi Kodama <nozomi.kodama(a)yahoo.com> writes: > From 9772529c63a9c11bc169545b6d68722308591a2f Mon Sep 17 00:00:00 2001 > From: Nozomi Kodama <nozomi.kodama(a)yahoo.com> > Date: Tue, 10 Apr 2012 10:50:31 +0200 > Subject: Some includes are useless That sort of change is not useful, the headers will be included anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

GDI+ pageoffset
by Stepa Nick 11 Apr '12

11 Apr '12

Hello. I have following code: > Bitmap * bmp = new Bitmap(500, 500, PixelFormat32bppARGB); > { > Graphics gr(bmp); > > //FIRST LINE > PointF* local1PointF = new PointF(17.823631, 89.429169); > PointF* local2PointF = new PointF(17.823631, 87.577080); > > //SECOND LINE > PointF* local3PointF = new PointF(14.933444, 89.429169); > PointF* local4PointF = new PointF(14.933444, 87.577080); > Pen * pen = new Pen(Color(255, 0, 0), 0.1); > gr.SetPageUnit(UnitMillimeter); > > gr.SetPixelOffsetMode(PixelOffsetModeHalf); //PROBLEM! > > gr.DrawLine(pen,(*local1PointF),(*local2PointF)); > gr.DrawLine(pen,(*local3PointF),(*local4PointF)); > } When I run it without SetPixelOffsetMode i get equal line, but with it line are not identical(first line is longer). I explore "dlls/gdiplus/graphics.c" and i find this comment: "/* FIXME: Pixel offset mode is not used anywhere except the getter/setter. */". So, I what to understand why I have different images(how pixeloffset affect on drawing lines)? I try to run windbg, run `WINEDEBUG=gdiplus,gdi,ddraw,graphics wine ./my.exe`, but analyzing output didn`t give my any results. Thanks!

2 1

Re: [PATCH 3/3] comctl32: Truncate the info tip text when using ANSI version messages.
by Marvin 11 Apr '12

11 Apr '12

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 http://testbot.winehq.org/JobDetails.pl?Key=17802 Your paranoid android. === WNT4WSSP6 (32 bit tooltips) === tooltips.c:755: Test failed: lpszText has 0 chars

1 0

Re: [PATCH 2/3] comctl32/tests: Add tests for long info tip texts.
by Marvin 11 Apr '12

11 Apr '12

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 http://testbot.winehq.org/JobDetails.pl?Key=17801 Your paranoid android. === WNT4WSSP6 (32 bit tooltips) === tooltips.c:755: Test failed: lpszText has 0 chars

1 0

Re: [PATCH 1/2] server: Add mechanism to retrieve the connect time of a socket (try 2).
by Dmitry Timoshkov 11 Apr '12

11 Apr '12

"Erich E. Hoover" <ehoover(a)mines.edu> wrote: > +/* Get information about a socket */ > +DECL_HANDLER(get_socket_info) > +{ > + struct sock *sock; > + > + sock=(struct sock *)get_handle_obj( current->process, req->handle, FILE_WRITE_ATTRIBUTES, &sock_ops ); Shouldn't the required access be FILE_READ_ATTRIBUTES or FILE_READ_PROPERTIES? Why write access is requied in order to read the socket connect time? Also please avoid including auto generated code in the patch. -- Dmitry.

2 1

Re: [PATCH 1/6] msvcrt: Rewrite asctime function
by Alexandre Julliard 11 Apr '12

11 Apr '12

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -48,7 +49,7 @@ static const int MonthLengths[2][12] = > > static inline int IsLeapYear(int Year) > { > - return Year % 4 == 0 && (Year % 100 != 0 || Year % 400 == 0); > + return (Year % 4 == 0 && (Year % 100 != 0 || Year % 400 == 0)) ? 1 : 0; Maybe you should do something like: return (((Year % 4 == 0 && (Year % 100 != 0 || Year % 400 == 0)) ? 1 : 0) ? 1 : 0) ? 1 : 0; to make really sure you get 0 or 1, you never know what might happen ;-) -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: [1/2] comctl32/tests: Added tests for mouse events handling (try 5)
by Marvin 10 Apr '12

10 Apr '12

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 http://testbot.winehq.org/JobDetails.pl?Key=17777 Your paranoid android. === WNT4WSSP6 (32 bit treeview) === treeview.c:1894: Test failed: right click (parent): the msg sequence is not complete: expected 0000 - actual 0133 treeview.c:1895: Test failed: right click (tree): the msg sequence is not complete: expected 0000 - actual 000f treeview.c:1902: Test failed: right drag (parent): the msg sequence is not complete: expected 0000 - actual 0133 treeview.c:1903: Test failed: right drag (tree): the msg sequence is not complete: expected 0000 - actual 000f

1 0