win32u: Allow separately storing the internal pixel format set by WGL_WINE_pixel_format_passthrough.

wined3d: Do not set the pixel format if wglGetPixelFormat() returns zero and we already set the internal pixel format.

Currently this does nothing, because wglGetPixelFormat() returns the pixel
format set by wglSetPixelFormatWINE(). However, with the following changes to
WGL_WINE_pixel_format_passthrough, wglGetPixelFormat() will only return the
pixel format set by wglSetPixelFormat(). Hence we should avoid trying to set
the "internal" pixel format more than once.

This is simpler in general, given that this function is no longer used
from user-space. In this particular case, the secondary purpose is to
allow easily adding arguments to the function.

Fixes a regression introduced by 42afb693.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Fixes a regression introduced by b6bf69ef.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Under Windows 11, notepad.exe has been migrated into the UWP framework,
and can no longer be launched as a 32bit process:
- even if c:\windows\syswow64\notepad.exe is still a 32 bit PE file
- the process created from c:\windows\syswow64\notepad.exe is not a
  wow64 process.

So use msinfo32.exe instead. Like notepad.exe, it's a gui application,
present on Wine and all test-bot:ed windows platforms. But unlike
notepad.exe, it's not an UWP app on Windows 11.

(May not fully fix all the bugs below, but will get rid of a bunch
 of errors).

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

Under Windows 11, notepad.exe has been migrated into the UWP framework,
and can no longer be launched as a 32bit process:
- even if c:\windows\syswow64\notepad.exe is still a 32 bit PE file
- the process created from c:\windows\syswow64\notepad.exe is not a
  wow64 process.

So use msinfo32.exe instead. Like notepad.exe, it's a gui application,
present on Wine and all test-bot:ed windows platforms. But unlike
notepad.exe, it's not an UWP app on Windows 11.

(May not fix all the issues in the following bug list, but will remove
 a lot of errors).

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54504
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54505
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54506
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54507
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54508
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54509Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Under Windows 11, notepad.exe has been migrated into the UWP framework,
and can no longer be launched as a 32bit process:
- even if c:\windows\syswow64\notepad.exe is still a 32 bit PE file
- the process created from c:\windows\syswow64\notepad.exe is not a
  wow64 process.

So use msinfo32.exe instead. Like notepad.exe, it's a gui application,
present on Wine and all test-bot:ed windows platforms. But unlike
notepad.exe, it's not an UWP app on Windows 11.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Under Windows 11, notepad.exe has been migrated into the UWP framework,
and can no longer be launched as a 32bit process:
- even if c:\windows\syswow64\notepad.exe is still a 32 bit PE file
- the process created from c:\windows\syswow64\notepad.exe is not a
  wow64 process.

So use msinfo32.exe instead. Like notepad.exe, it's a gui application,
present on Wine and all test-bot:ed windows platforms. But unlike
notepad.exe, it's not an UWP app on Windows 11.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

And, more saliently, to allow moving more common code to the end of the
function.

It makes use of the wined3d_format, and we want to move wined3d desc creation to
ddraw_surface_create_wined3d_texture() so that we can use it to recreate the
wined3d texture in SetSurfaceDesc().

- should have been fixed when libwine.so has been removed
- code was broken anyway
- enhanced protect against error when reading debuggee's memory

Introducing helper to correctly read pointer's from debuggee
(and other integral values).

vdso is now listed in ELF's module list (except if Wine's preloader
removes it from auxilary vector)
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

For dbghelp in 32-bit, when accessing a live debuggee in multi-arch
configuration, Wine's ELF loader is likely mapped above 4G, hence
not accessible with 32bit Windows APIs.
So don't try to expose the ELF libraries in that case.
Introducing a new loader operation class to support live targets, for
which system operations are not accessible, but pretending they are
successful.

Note:
- when Wine's loader ELF module isn't registered by dbghelp,
  any other ELF module will not be registered by dbghelp.
- further work may be needed for winedbg in auto mode (launched with
  AeDebug key on process exception) as in that mode winedbg
  doesn't relaunch itself in 64bit, so won't be able to access
  (64bit) ELF information (in multi-arch configuration).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

For easier testing and to wokaround some Windows IME caching mechanism
that prevent the IME module from reloading.