This function was introduced in commit
59055c4d but never used.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53954Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

They are byte offsets in the buffers data.

This is a bit tricky because the strings are supposed to be static, but
we also cannot return the unix strings directly either.

So instead we keep track, on the unix side, of known unix / wow64 string
associations, and return the known wow64 string if the unix string was
already requested before.

If the string wasn't found, the syscall returns STATUS_BUFFER_TOO_SMALL,
and the PE side allocates the required memory, calling the syscall once
again with the wow64 string pointer to copy the string to.

On concurrent calls, the syscall may return a different wow64 string, in
which case the PE side uses it instead and frees the one it allocated.

Lastly, the PE side also keeps record of wow64 strings it had allocated,
so that we can free them on process detach. The unix side also does some
cleanup of its mapping buffer, as there's no guarantee that it will be
completely unloaded.

This avoids the following warning by GCC 13:
dlls/msado15/recordset.c:790:32: warning: 'i' may be used uninitialized

Needed by Chromium-based browsers.

Changed MCHITTESTINFO.cbSize to fall back to V1:
  From the rest of the tests, it looks like the extended size
  of MCHITTESTINFO requires loading common controls V6, which is
  only done afterwards in the tests.

Improved lookup of an unselected day.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50097Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Rather than hardcoding them individually, so that it's all in one place
when adding new ones.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

The window itself is not a DOM node, so this is perfectly normal to fail
here. In fact, we weren't dispatching any gecko events sent to the window.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>