Instead of the imc pointer.

Today, NtCreateThreadEx() passes to pthread_attr_setstack() an address
range that spans both the user (PE) stack and the kernel (Unix) stack.

pthread_attr_setstack() accepts an address range that will be used as
the initial stack area for the thread created by pthread_create().  It
is often assumed that the initial stack will be available for the entire
duration of the thread's lifetime.

This assumption, however, conflicts with how Win32 fibers operate.
Fiber APIs allow the thread's initial stack to be freed before the
thread exits, or kept alive beyond the point of thread's termination.
This allows the lifetime of the thread's initial stack to be shorter or
longer than the originating thread's lifetime.  This is possible because
each fiber has its own stack and context, and ConvertThreadToFiber()
transfers the current thread's stack to a new fiber.

This specifically causes problems in Glibc v2.31 and earlier.  These
Glibc versions have a bug where madvise(2) with the MADV_DONTNEED flag
is called on the initial stack area on thread exit, even when the stack
was user-supplied (via pthread_attr_setstack).  Therefore, the kernel
may zero out any portion of the initial stack at any time after the
originating thread terminates, even if the stack no longer belongs to
the current thread (either freed and reallocated, or owned by a fiber).
This may ultimately lead to memory corruption.

Fix this by only passing the syscall (kernel) portion of the stack to
pthread_attr_setstack().

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

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

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

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

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

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

Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>

I.e. get rid of nested namespaces and forward declares,
separate attributes with commas and right align pointer declarations.
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>

* Disable lighting, which affects rendering tests in non-obvious ways.

* Show that the texture is explicitly never set in ddraw7.

* Show that the diffuse color is rendered in ddraw4 and ddraw7, which is
  consistent with the texture being unset in ddraw7 and suggests that the same
  applies to ddraw4.

This may or may not help with bug 54069, but if it does not, it hopefully will
at least make the reason for failure clearer.

Signed-off-by: Torge Matthies <tmatthies@codeweavers.com>

Signed-off-by: Torge Matthies <tmatthies@codeweavers.com>

Signed-off-by: Torge Matthies <tmatthies@codeweavers.com>