It's necessary to make this clamping there so that returned values are
always used consistently in taskmgr, including in places where the
values are directly fetched into other functions.
This is a free adaptation from
Wine commit
a9742b3210c4cec67aca3c0012f3b9504a4368cf
From: Gerald Pfeifer <gerald@pfeifer.com>
taskmgr: Move out-of-domain checking into
PerfDataGetProcessorUsage() and PerfDataGetProcessorSystemUsage().
Use the power of CRT debug to detect memory leaks.
- Define _CRTDBG_MAP_ALLOC and include <crtdbg.h> after <stdlib.h>.
- Call _CrtSetDbgFlag at prologue of wWinMain.
CORE-18014
Contrary to what is (badly) written on MSDN, this parameter is
*mandatory* when the ranges looked for are on a PCI adapter.
Detected when testing with MS Windows' videoprt.sys on XBOX emulator;
thanks to Simone Lombardo for assistance!
- Remove ContextValue variable. This variable erroneously truncated
*Context value (that can contain a pointer value) to 32 bits.
- Gracefully fail instead of asserting.
- Add missing ExAllocatePool NULL checks.
- Fix order of KeBugCheckEx parameters for PNP_DETECTED_FATAL_ERROR.
- The Controller and Peripheral numbers are zero-based, so if the caller
wants to inspect controller (or peripheral) zero, let it be so!
The original code was treating controller number zero for enumerating
controllers of a given class within the different buses, which is
wrong. See the diff'ed trace below.
Tested with Windows' videoprt.sys VideoPortGetDeviceData().
```diff
IoQueryDeviceDescription()
BusType: 0xB093C224 (0)
BusNumber: 0xB093C228 (0)
ControllerType: 0xF9D01030 (19)
ControllerNumber: 0xF9D01038 (0)
PeripheralType: 0x00000000 (4294967295)
PeripheralNumber: 0x00000000 (4294967295)
CalloutRoutine: 0xF9CF74E4
Context: 0xF9D5A340
--> Query: 0xF9D5A22C
IopQueryBusDescription(Query: 0xF9D5A22C)
RootKey: '\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM'
RootKeyHandle: 0x00000598
KeyIsRoot: TRUE
Bus: 0xF9D5A290 (4294967295)
Seen: 'CentralProcessor'
Seen: 'FloatingPointProcessor'
Seen: 'MultifunctionAdapter'
SubRootRegName: '\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM\MultifunctionAdapter'
IopQueryBusDescription(Query: 0xF9D5A22C)
RootKey: '\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM\MultifunctionAdapter'
RootKeyHandle: 0x00000590
KeyIsRoot: FALSE
Bus: 0xF9D5A290 (4294967295)
Seen: '0'
SubRootRegName: '\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM\MultifunctionAdapter\0'
Getting bus value: 'Identifier'
Getting bus value: 'Configuration Data'
Getting bus value: 'Component Information'
--> Getting device on Bus #0 : '\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM\MultifunctionAdapter\0'
IopQueryDeviceDescription(Query: 0xF9D5A22C)
RootKey: '\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM\MultifunctionAdapter\0'
RootKeyHandle: 0x00000590
Bus: 0
- Enumerating controllers in '\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM\MultifunctionAdapter\0\DisplayController'...
+ Getting controller #0
+ Retrieving controller '\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM\MultifunctionAdapter\0\DisplayController\0'
```
- Move messages from OnInstall procedure to en-US resource file.
- Applied the same changes to all language files, now it's available
for translation into other languages.
CORE-18952
Signed-off-by: Nikita Piatygorskiy <generalhammond16@gmail.com>
Improve keyboard usability.
- Add CCanvasWindow::MoveSelection.
- Modify CMainWindow::OnKeyDown.
- If Esc key is pressed, then the selection will land to canvas.
- If any arrow key is pressed, then the selection will move a bit.
CORE-18867
When the window size is smaller than the image size in both directions, the wrong cursor is displayed when hovering the mouse over the scrollbars.
Readjust position for file date and file size objects, to fit all text.
CORE-18867
In 0.4.14-dev-955-g 1cf564c25f
Katayama experimented with populating explorers file-menu when no object is selected.
Later we found out, that none of the new entries introduced by that commit really
made sense and even created duplicates. So the commit was reverted by
0.4.15-dev-6039-g 0fa4edebd9 'Revert CDefView::FillFileMenu (#5278)' CORE-18429
But it seems that not all parts were properly reverted back then,
maybe because 6 lines of new code were written between the two lines in the meantime.
And remove the "!NT_SUCCESS(Status)" check which is excessive, the expected
status will always be STATUS_BUFFER_TOO_SMALL anyway. This should fix
some compilation warnings spotted by GCC. Courtesy goes to Hermes for letting
me know of these warnings.
Based on a commit by Vadim Galyant:
5ef5c11e7f
Also fix a minor type conversion warning. CORE-18963 CORE-17977
Co-authored-by: Vadim Galyant <vgal@rambler.ru>
CORE-18221
Load the DirectX graphics kernel driver (dxg.sys) by win32k at WINSRV
initialization time, in NtUserInitialize(). Keep it always loaded in
memory, as on Windows, instead of loading it only by DirectX dlls.
This fixes the problem of acessing this driver: we need only to call
DxDdEnableDirectDraw() and do other stuff when DirectDraw/Direct3D is
required by anything. In other cases, it is called from win32k PDEV
functions when changing display mode (as in Windows). Since it's used
by other things too, it needs to be always loaded.
Otherwise, if it's not loaded, its APIs are not accessible when needed,
and execution fails.
For example, it fixes display mode change problem in VMWare, when a
new mode fails to be applied. Indeed, when it manages DirectDraw stuff,
it calls DXG routines, and therefore fails if dxg.sys isn't loaded
in memory at this moment.
- Implement InitializeGreCSRSS() initialization routine, that initializes
supplemental NTGDI/GRE data once CSRSS and WINSRV are loaded:
* Call DxDdStartupDxGraphics() inside it, which loads dxg.sys.
* Additionally, move fonts and language ID initialization there, from
win32k!DriverEntry. Confirmed by analysis on Windows.
- Call InitializeGreCSRSS() in NtUserInitialize() main initialization routine
(called by WINSRV initialization).
Moved to NTGDI from previously NTUSER place:
Co-authored-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
We should compare against DeviceObject as DeviceInstance is never NULL.
Fix a resource leak as well. The bug CORE-18983 seems to lay somewhere
else though, I just stumbled upon this one while researching it.
Note there is a BSOD in the PnP manager on reboot after the driver
installation failure, but it seems it was uncovered by the fix
as opposed to caused by it.
- Refactor most of the code, since there's quite some stuff that don't make much sense.
For instance ImpersonationLevel is basically the requested impersonation level a
server asks for. PsImpersonateClient doesn't explicitly say that SecurityAnonymous
and SecurityIdentification are not allowed. If the server was to give such levels
it simply means it doesn't want to impersonate the client.
Another thing that doesn't make much sense is that we check if the client is
associated with an anonymous token, then avoid impersonating regular anonymous
tokens that weren't created by the system. Only system can create such tokens
and an anonymous token basically means a token with hidden security info.
- Check that the server is within the same client logon session.
- If the server is granted the SeImpersonatePrivilege privilege, allow impersonation
regardless of the conditions we want to check for.
- Update the documentation and code comments.
As it currently stands the PsImpersonateClient routine does the following approach.
If impersonation couldn't be granted to a client the routine will make a copy
of the client's access token. As it makes a copy of the said token PsImpersonateClient
will reference the copied token after impersonation info have been filled out.
In the same code path we are assigning the desired level for impersonation to thread
impersonation info.
This is wrong for two reasons:
- On a copy situation the SeCopyClientToken routine holds a reference as the object
has been created. Referencing it at the bottom of the PsImpersonateClient routine
will make it that the token is referenced twice and whenever a server stops
impersonation the token still has an extra reference count which keeps the token
still alive in object database and memory space.
- If client impersonation is not possible the thread impersonation info should
have been assigned SecurityIdentification level to further indicate that the
actual impersonation of the thread is not currently in force but instead we
are assigning the impersonation level that is supplied by the caller. For instance
if the requested level is SecurityDelegation but impersonation is not possible
the level will be assigned that of SecurityDelegation yet the token has an
impersonation level of SecurityIdentification. This could lead to erratic behaviors
as well as potential impersonation escalation.
Fix the aforementioned issues by avoiding a double reference and properly assign
the impersonation level to SecurityIdentification if the server is not able to
impersonate the target client.
- Add the missing privileges to the SYSTEM privileges which might be needed,
notably SeUndockPrivilege, SeManageVolumePrivilege, SeCreateGlobalPrivilege and
SeImpersonatePrivilege.
Specifically SeImpersonatePrivilege is important here because with it we
allow system components of the core OS to perform certain system tasks.
- Declare the Groups array with a maximum of 3 elements in SepCreateSystemProcessToken
and 1 element in SepCreateSystemAnonymousLogonToken respectively, because previously
this array was oversized with most of free space left as a waste.
- Avoid hardcoding the size value of the Privilege array, instead initialize it
by hand and compute the exact number of elements with RTL_NUMBER_OF.
