- 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>
If inserting the allocated VAD fails, MiMapViewOfDataSection will make no attempt to free the allocated VAD. Nor will it call MiDereferenceControlArea(ControlArea); like other failure return paths. This commit fixes this behavior.
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
One StringCbPrintf() call is sufficient, that can cover both
clearModifyAlert == TRUE or FALSE cases.
Also, only SendMessage(EM_GETMODIFY) when clearModifyAlert == FALSE
(during text edition).
- Extend the command table to support subcommands.
- Get rid of the existing subcommand code.
- Use the new subcommand suport for the help system.
- Start work on the create command.
@Translators: Please do not translate any changes yet, because I will improve help system in one of the next steps.
When typing text on NotePad, then NotePad title bar flickers.
- Save previous modification flag.
- If no change in modification flag, do not set the title bar text.
This can be configured in registry with DefaultSettings.XPanning and
DefaultSettings.YPanning, which describe the real screen resolution.
DefaultSettings.XResolution and DefaultSettings.YResolution describe
the resolution of the virtual screen.
When changing pointer cursor:
- use PDEV_HARDWARE_POINTER flag if using hardware pointer
- use PDEV_SOFTWARE_POINTER flag if using software pointer
- keep pfnMovePointer as an accelerator to driver function (if available) and never change it
- fix bug (2 pointers) when switching between hardware and software pointer
When moving pointer:
- check PDEV_HARDWARE_POINTER flag to know if we need to call the driver
- check PDEV_SOFTWARE_POINTER flag to know if we need to call EngMovePointer
- search a graphic mode corresponding to real screen resolution (not virtual panning one)
- when capturing the selected mode, copy from input the virtual panning resolution
- when searching the best mode, also try without panning
- Clarify driver version in 3rd Party Files.
- Fix some minor formatting problems.
- Also add missing OBJ_KERNEL_HANDLE to match Zw*() uses. (#4499)
CORE-10207 CORE-18180
Co-authored-by: Serge Gautherie <reactos-git_serge_171003@gautherie.fr>
- 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
- Check if the parent window of RunDLL is the desktop,
only in this case add the system control applet to the taskbar.
- Try loading small 16x16 icon for the taskbar button.
CORE-18175
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).
We are allocating blocks of pool memory for a security descriptor with its own specific tag, TAG_SEC_QUERY, so just use it when freeing when releasing the descriptor as well (aka freeing the said pool).
Fixes compilation because the Hal(Private)DispatchTable's, defined in
the bootloader's NTOS stub, are not external imports, as they would be
for a standard HAL.
- Also sort out non-localizeable lines
- Fix German translation encoding and add missing one
- Add Russian translation
Addendum to 9c79a798, 68e19a95 and 9ca32a2b.
This design, introduced in 418edcd2b, is fundamentally flawed as it
can also close windows unrelated to the running test (e.g. windows
of programs that the user can start, while the test is running).
But since we cannot do much better, mitigate instead the other main
problem of this design: Just use PostMessageW(WM_CLOSE), as it used
to be, instead of TerminateProcess().
Indeed, using TerminateProcess() otherwise could kill unrelated
processes the test hasn't created. In particular it could kill the
csrss.exe system process if, during the testing procedure, a hard-error
popup shows up.
And this is precisely the case when this test runs with limited memory,
and a hard-error
"Insufficient system resources exist to complete the requested service."
arises.
There are two fundamental problems when it comes to access checks in ReactOS. First, the internal function SepAccessCheck which is the heart and brain of the whole access checks logic of the kernel warrants access to the calling thread of a process to an object even though access could not be given.
This can potentially leave security issues as we literally leave objects to be touched indiscriminately by anyone regardless of their ACEs in the DACL of a security descriptor. Second, the current access check code doesn't take into account the fact that an access token can have restricted SIDs. In such scenario we must perform additional access checks by iterating over the restricted SIDs of the primary token by comparing the SID equality and see if the group can be granted certain rights based on the ACE policy that represents the same SID.
Part of SepAccessCheck's code logic will be split for a separate private kernel routine, SepAnalyzeAcesFromDacl. The reasons for this are primarily two -- such code is subject to grow eventually as we'll support different type ACEs and handle them accordingly -- and we avoid further code duplicates. On Windows Server 2003 there are 5 different type of ACEs that are supported for access checks:
- ACCESS_DENIED_ACE_TYPE (supported by ReactOS)
- ACCESS_ALLOWED_ACE_TYPE (supported by ReactOS)
- ACCESS_DENIED_OBJECT_ACE_TYPE
- ACCESS_ALLOWED_OBJECT_ACE_TYPE
- ACCESS_ALLOWED_COMPOUND_ACE_TYPE
This gives the opportunity for us to have a semi serious kernel where security of objects are are taken into account, rather than giving access to everyone.
CORE-9174
CORE-9175
CORE-9184
CORE-14520
