To recognize IME, we have to initialize pKL->piiex.
- Add co_ClientImmLoadLayout and User32CallImmLoadLayoutFromKernel functions to call imm32!ImmLoadLayout on user mode from kernel.
- Use co_ClientImmLoadLayout in NtUserLoadKeyboardLayoutEx.
- Improve Imm32LoadIME to sanitize the IME table.
CORE-11700
- Move struct _TL and TL definitions from win32.h to ntuser.h.
- Modify the type of TL.pfnFree as newly-defined TL_FN_FREE function pointer.
CORE-11700
The current Shift+Alt handling is buggy. The keyboard won't work frequently.
It dislikes system-side Alt (VK_MENU) key handling.
It seems like Shift+Alt handling should be in kernel.
CORE-10667
- Assignment and locking are managed by UserAssignmentLock/UserAssignmentUnlock.
- Synchronize ClientInfo->hKL to pti->KeyboardLayout->hkl.
CORE-11700, CORE-18317
- Add WM_IME_SYSTEM message handling on RealDefWindowProcA and RealDefWindowProcW functions.
- Improve WM_IME_... messages handling.
- s/IMMGWL_IMC/IMMGWLP_IMC/
- Don't set IMMGWLP_IMC value to the default IME window.
CORE-11700
- Add IntLoadKeyboardLayout (Win: LoadKeyboardLayoutWorker) helper function.
- Use it in LoadKeyboardLayoutW and LoadKeyboardLayoutEx functions.
CORE-11700
MFC42 applications only expect an IME window when on a DBCS system,
so they will capture this IME window as their 'main' window on non-DBCS systems.
CORE-18212
- [VIDEOPRT] Return the real PhysicalDeviceObject in Win32k callbacks.
- [WIN32SS:ENG] Pass PhysDeviceObject into the GraphicsDevice structure
and rename the destination field accordingly.
- [WIN32SS:NTUSER] Request hardware identifiers from device PDO and
fill DISPLAY_DEVICE's DeviceID field with the first identifier.
Now it's correctly passed to the usermode, and Desktop Propertes applet
can open the video adapter device properties.
Thanks to Hervé Poussineau for the help.
CORE-18197 CORE-11715
- Add some missing ARM64 exports to ntdll, kernel32 and user32
- Create mmtypes header file based on WoA debug symbols
- Get the remaining headers in order, so we can build ARM64 apps
- Adjust subsystem version for binaries so they can run on WoA host
- Get calc, notepad and more base apps to build for ARM64 platform
CORE-17518
Reviewed-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
This reverts commit c243133b2c.
Without the revert, VirtualBox auto-resize doesn't work on first attempt,
but only on next ones.
However, according to documentation, we must only initialize device and
cache information when iModeNum = 0.
CORE-18189
- Changed some wording according to the translation requirements.
- Fixed some mistakes.
- Changed my name.
Reviewed-by: He Yang <1160386205@qq.com>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
- Fix Japanese keyboard about [Shift]+[0] and [半/全] (VK_PROCESSKEY).
- Add user32!CliSaveImeHotKey helper function.
- Implement user32!CliImmSetHotKey function. This function is forwarded from imm32!ImmSetHotKey.
- Fix user32!TranslateMessage by using imm32!ImmTranslateMessage.
CORE-11700, CORE-18183, CORE-18182
The problem ReactOS currently faces is this -- whenever the desktop is being parsed we aren't assigning a security descriptor to it. As a matter of fact when Winlogon tries to assign new security information to the application desktop when a user logs in, Winlogon fails because no prior descriptor has been created for it even though we already do this when initializing security buffers in Winlogon.
With that said, we must assign a descriptor when parsing the desktop as well. This fixes a hack in Winlogon where security assigning of application desktop during a log in is disabled (which we can now enable such code path back).
When creating a window station with CreateWindowStationW, the function ignores the security descriptor provided by the caller and instead it uses whatever descriptor the system can find.
Implement a base security infrastructure with code that sets up a security descriptor for the service that we're going to connect through it. Such service is based upon a desktop and a window station.
=== DOCUMENTATION REMARKS ===
The authenticated user, represented by an access token that describes its security context, is the main holder and has ultimate power against the default created desktop and window station objects in USER. The authenticated user in question
is the actual logged in user, this is the case when the server is impersonating a client. Administrators on the other hand have some share of power against default desktop but their power in question is extremely limited against the default
window station as admins can only just enumerate the available and valid handle stations within a desktop.
