It's possible for it to get detached while processing an external callback
notification, such as when navigation happens during it.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
It's possible for it (and the GeckoBrowser) to get detached and destroyed
while processing an external callback notification.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
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.
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=54537
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>
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>
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>
