--
v2: riched20/tests: Fix the EM_GETSELTEXT tests in Hindi on Windows.
riched20/tests: EM_GETSELTEXT's wparam is not used and should be 0.
riched32/tests: EM_GETSELTEXT's wparam is not used and should be 0.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2276
Signed-off-by: Fan WenJie <fanwj(a)mail.ustc.edu.cn>
calling unix funcions from PE must via unix_call, Because must switch fs register vaule and other context on wow64 mode. Currently calling some unix functions of win32u via function pointers. The patch modify the way of calling unix functions of win32u by unix_call
--
v4: win32u: replace calling unix functions by unix_call and remove callback unix_funcs
win32u: Use syscall interface for remaining functions.
win32u: Use syscall interface for user functions.
win32u: Use syscall interface for more GDI functions.
win32u: Use syscall interface for more clipping functions.
win32u: Use syscall interface for more font functions.
win32u: Use syscall interface for more font functions.
win32u: Use syscall interface for more GDI object functions.
win32u: Use syscall interface for more DC functions.
win32u: Use syscall interface for DIB functions.
win32u: Use syscall interface for D3DKMT functions.
win32u: Use syscall interface for more bitmap functions.
win32u: Use syscall interface for bitblt functions.
win32u: Use syscall interface for more path functions.
win32u: Use syscall interface for more printer functions.
win32u: Use syscall interface for more painting functions.
win32u: Use syscall interface for more painting functions.
win32u: Use syscall interface for NtGdiOpenDCW.
gdi HACK: Disable printer drivers.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2291
The idea I have is to use this module to declare class stubs until there is a good reason to split them to dedicated modules. WinRT modules aren't usually loaded directly, and instead the registry is queried to figure which module to load for which class.
This would help avoiding unnecessary proliferation of stub WinRT modules, while at the same time allowing to factor WinRT foundation code (such as vector / async, etc...) between the modules that seem to deserve to be implemented separately.
The relevant classes could then be split out to dedicated modules on a as-needed basis, when they get fleshed out.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2298