This is actually a Vista+ function, but we need it enable umpnpmgr.dll to notify services of device events. Up until WinXP it was possible to make direct calls to the service manager by umpnpmgr.dll because umpnpmgr.dll was loaded into the service manager process. From Vista onwards umpnpmgr.dll is run as a separate service host process. And since ReactOS always ran umpnpmgr.dll as a separate process, we have to use the Vista RPC functions to notify services.
NOTE: IDS_ADMINISTRATOR_NAME translation excluded for the time being.
It should be "Администратор", but bg-BG translation missing in samsrv.dll,
therefore don't translate it because otherwise this would introduce a mismatch
(samsrv falls back into english when translation is missing).
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
CORE-18958
Introduce an emergency log-off and restart feature, available when holding
down the control key and selecting "Log Off" or "Shut down" in the MSGINA
Ctrl-Alt-Del security dialog, similar to Windows Server 2003 and newer
Windows versions.
The minimized non-task windows were not usable due to the bugs. In some situations, the system will restore the minimized non-task windows.
- Add IsTaskWnd helper function.
- Add SendPulseToTray function to send a pulse to the tray window.
- At some shell hook handlings, send a pulse to the tray window.
- Add IgnorePulse flag to control the timing of restoring.
- Add a timer to reset IgnorePulse flag.
- If the pulse has come and IgnorePulse flag is false, then restore the minimized non-task windows.
- Modify the rundll32 window procedure.
- Use WINDOWPLACEMENT to restore the minimized windows.
CORE-13895, CORE-18350
Improve compatibility.
- Rename window class "rundll32_window" as "RunDLL".
- Delete some shell32 codes about this window class.
CORE-13895, CORE-18350
[SYSDM] Prevent my german-teacher from getting a heart-attack by that misplaced comma.
[SMSS] Prevent myself from getting a heart-attack by that superfluous dot.
Furthermore this addendum serves the purpose of actually linking both PRs
and their 4 previous commits to the actual JIRA ticket CORE-18754, which wasn't
the case before:
0.4.15-dev-5392-g 04b2d35f5b
0.4.15-dev-5391-g a8e06d92e8
0.4.15-dev-5390-g a4274ad548
0.4.15-dev-5389-g 5dc43c0f32
What we have:
- Maximum number of pagefiles: 16
- Minimum pagefile size: 256 pages (1 MB when page size = 4096 bytes)
- Maximum pagefile size:
* 32-bit platforms: (1024 * 1024 - 1) pages (~ 4095 MB)
* x86 with PAE support: same size as for AMD x64
* x64 platform: (4 * 1024 * 1024 * 1024 - 1) pages (~ 16 TB)
* IA64 platform: (8 * 1024 * 1024 * 1024 - 1) pages (~ 32 TB)
Those are the values as supported and verified by the NT kernel.
Now, user-mode programs (including SMSS.EXE) have different opinions
on these, namely, they consider estimates directly in MB, respectively:
4095 MB, (16 * 1024 * 1024) MB, and (32 * 1024 * 1024) MB
(verified on Win2k3 and Win7 32 and 64 bits).
Also here, the minimum pagefile size is set to 2 MB.
Starting Windows 8+ (and 10), those values change slightly, and are
still not fully synchronized between NTOS:MM and SMSS. Finally, while
(x86 PAE and) AMD64 and ARM64 seem to share the maximum pagefile
size limit, 32-bit ARMv7 appears to use different limits than regular
x86 (2 GB instead of 4).
Please keep those values as they are for NT compatibility!
See the following references:
https://www.geoffchappell.com/studies/windows/km/ntoskrnl/api/mm/modwrite/create.htmhttps://techcommunity.microsoft.com/t5/ask-the-performance-team/what-is-the-page-file-for-anyway/ba-p/372608
+ Manual extraction of the values from different NT 6.2,6.3,10 builds.
[SMSS] Fill out in particular the x86-specific case for PAE.
[NTOS:MM] Some cleanup in the NtCreatePagingFile() code, namely:
- Clarify some comments;
- Validate the lower and upper bounds of the Minimum and Maximum sizes
(based on Windows behaviour as explained by Geoff + manual tests).
- Open the pagefile in case-insensitive;
- Simplify the loop that finds an existing matching pagefile;
- Simplify some failure exit paths;
- Add a "Missing validation steps TODO" comment block explaining the
existing code-hole.
This fixes starting the Windows 2000 POSIX subsystem in ReactOS.
- The CreateSession pointer was initialized against the SbApiMsg variable, but
it was the other SbApiMsg2 that was being initialized and sent through LPC.
- Do not overwrite the MuSessionId (Terminal Services session ID) variable with
the generated environment subsystem session ID from SmpAllocateSessionId().
- Actually initialize the SbApiMsg ApiNumber for the CreateSession LPC call.
(dll\win32\kernel32\client\proc.c:3690) Retrying with: POSIX /P C:\ReactOS\system32\posix\ls.exe /C ls
Breakpoint 1 hit
csrsrv!CsrSbApiRequestThread+0x64:
001b:1000ac34 837dfc00 cmp dword ptr [ebp-4],0
kd> ??ReceiveMsg
struct _SB_API_MSG
+0x000 h : _PORT_MESSAGE
+0x018 ConnectionInfo : _SB_CONNECTION_INFO
+0x018 ApiNumber : 0xcccccccc (No matching name)
+0x01c ReturnValue : 0n0
+0x020 u : <unnamed-tag>
kd> p
...
(base\system\smss\smsubsys.c:393) SMSS: SmpLoadSubSystem - NtRequestWaitReplyPort Failed with Status c0000002 for sessionid 2
...
<Retrying>
...
(base\system\smss\smsubsys.c:393) SMSS: SmpLoadSubSystem - NtRequestWaitReplyPort Failed with Status c0000002 for sessionid 3
All those bugs could have been avoided *IF*, rather than (badly) duplicating
its code, the existing SmpSbCreateSession() function had been used instead.
- "Not sure these field mean what I think they do -- but clear them" ... ◔_◔
Those fields are related to the debug client interface (DbgUi) and session
in case the subsystem being started is going to be debugged. These have
nothing to do with the MuSessionId. Clarify this in the SB_CREATE_SESSION_MSG
structure and in the SmpSbCreateSession() function.
* [DISKPART] Fix help for multi-word command crashing.
When the HELP command is executed for a multi-word command,
for example "HELP CREATE PARTITION PRIMARY", diskpart crashes.
This happens because before the desired form of the command
is encountered, its single word form is found - since the first word
of the command matches the one HELP is looking for, it tries to
compare the second word of the input command with the second
(nonexistent) word of the encountered single word command,
which is NULL. This results in diskpart crashing.
The fix makes HELP check if the to-be-compared word is not NULL,
before calling wcsicmp.
The SubSystemNames array didn't correlate with the possible values of
SubSystemType (e.g. index 4 was "Posix" whereas Posix is type 7; Posix
and OS/2 entries were inverted; Windows CUI subsystem (type 3) was
mapped to "Posix"), and the array dereferencing was out of bounds if the
SubSystemType of the image happened to be larger than 8.
I know (strings extraction from debug build of Windows' SMSS.EXE) that
they use that same old'n'broken array. Perhaps a leftover from very old
times (NT 3.1 betas) where the PE format was under work and the
subsystem numbers didn't have their definitive values... (This has
already happened with the NT PDK v1.196 from September 1991.)
Loosely based on the deprecated ReactOS-specific SmExecuteProgram().
On server-side, we lookup into the list of deferred subsystems that
has been initialized at init time.
Dedicated to Justin Miller (The_DarkFire) work on reviving the
POSIX subsystem!
