There is currently no benefit to dynamic allocation, and static
allocation allows us to simplify some aspects of initialization.

VPN interfaces often have ARPHRD_NONE in ifr_hwaddr.sa_data
but IFF_POINTOPOINT flag set.

It's less physically correct but closer to the native behavior.

We are not going to support multi-machine .so modules.

programs/explorer/desktop.c:104:16: warning: ‘hres’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  104 |         return hres;
      |                ^~~~

Using TransformMatrixPoints is not needed and all values could
be taken from transformation matrix:
 - ShearX from m11, m12
 - ShearY from m21, m22
 - Translation mdx, mdy

The result could be calculated by taking destination points values:
 {{0.0, 0.0}, {1.0, 0.0}, {0.0, 1.0}}

and calculating it with GdipTransformMatrixPoints function:
  dst_to_src_points[0].X = dst_to_src.matrix[4];
  dst_to_src_points[0].Y = dst_to_src.matrix[5];
  dst_to_src_points[1].X = dst_to_src.matrix[0] + dst_to_src.matrix[4];
  dst_to_src_points[1].Y = dst_to_src.matrix[1] + dst_to_src.matrix[5];
  dst_to_src_points[2].X = dst_to_src.matrix[2] + dst_to_src.matrix[4];
  dst_to_src_points[2].Y = dst_to_src.matrix[3] + dst_to_src.matrix[5];

Improves efficiency by using addition instead of float numbers
multiplication for destination points.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53947

With previous implementation, every iteration pointer value was
calculated by taking row and column of the image.
It needs multiply calculation. With current implementation,
pointer value calculation, is replaced with iterator, which takes
next pixel data.

It improves efficiency by using addition instead of multiplication
for iterating through points data.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53947

Calculating transformation points and not using it it is a waste
of CPU time. With this patch the code was moved where it is used.
It is improving performance of GdipDrawImagePointsRect when
resampling is not needed.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53947

The default size is too small for HiDPI, so set the same height as
the look-in combo box to it. And since in owner draw mode, the height
of combo box is calculated and updated when drawing items, this patch
set button height for toolbar from FILEDLG95_LOOKIN_DrawItem() too.

We test once above that the source does not use the existing allocator, but then
implicitly release the allocator we are testing against (when the source assigns
a new allocator to the sink). As a result, these ok() statements were testing
that newly allocated allocators had a different address than the original
allocator, which of course sometimes fails.

Since we don't need to perform this test more than once anyway, just get rid of
the offending ok() statements.

The tests show that input status is not affected by it.