The "broken" function was applied to the wrong condition in the "ok"
statement (RtlIpv6StringToAddress is supposed to set the terminator to
the first character after the address, not the second-to-last character
of the address). However, since this test is already being skipped on XP
and Vista and we really don't need a test for how exactly XP and Vista
are broken, we can just delete it.
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The search was initiated with base == 0, which returns NULL immediately
if MEM_TOP_DOWN is not used. Use address_space_start instead.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47974
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This introduces map_free_area function which tries mapping the expected
free areas until it finds one that succeeds. It now also works for
memory regions outside of the reserved region, but could probably be
improved.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We used this function to find free areas outside of the reserved range,
and it's obviously incorrect as there can be some system or external
memory mapping we don't know about.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
On Windows 10 version 1607, a process called "Memory Compression" violates this
invariant.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This helps to keep compatibility with old prefixes being reused for wine-5.0.
Old prefixes in their registry have
[System\\CurrentControlSet\\Control\\Nls\\Codepage]
"37"=""
[System\\CurrentControlSet\\Control\\Nls\\Language]
"0409"=""
and this leads to LCMapString(LCMAP_LOWERCASE/LCMAP_UPPERCASE) return garbage.
This is a regression caused by 94a3add0ea.
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Takes care of one more use of "long double".
Signed-off-by: Erich E. Hoover <erich.e.hoover@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If 0 is returned, the caller has no way of determining this. This fixes a
test failure in kernel32:change introduced by f46fa9c92.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Also calculate all_cpus_mask on first pass.
Signed-off-by: Anastasios Simeonidis <symeonidis@csd.auth.gr>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Inspired by a patch by Andrew Eikum.
macOS's mach_absolute_time() stops counting when the computer goes to
sleep/suspend/hibernate/etc. However, Windows's GetTickCount() does not
stop counting. mach_continuous_time() matches Windows's behavior.
BSD's CLOCK_MONOTONIC already counts asleep time.
Unfortunately, there is no clock source on Linux which does exactly what
we want. CLOCK_MONOTONIC_RAW is unaffected by NTP adjustment, but like
mach_absolute_time() doesn't keep ticking when the computer is asleep.
CLOCK_BOOTTIME does keep ticking, but it is affected by NTP adjustments.
CLOCK_MONOTONIC has both problems. What's needed is a
CLOCK_BOOTTIME_RAW, which would not be slewed by adjtimex(2) and would
count time spent asleep.
To avoid issues with skew and performance, this patch falls back to
mach_absolute_time() on macOS if mach_continuous_time() is unavailable.
Note that mach_continuous_time() was introduced in macOS 10.12, meaning
that if the minimum version required is less than that, it will be
linked weakly. Therefore we must check that it is nonnull before
attempting to call it.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Alex Henrie