[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.
... and let the latter one substitute to whatever we want.
Hindi however had "Helv" -> "Tahoma", but "MS Sans Serif" -> "FreeSans".
Now its "Helv" will go to "FreeSans".
* [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.
An addendum to 0.4.14-dev-20-g 2f4fb903b4
because since then we don't have the Ubuntu font anymore.
The substitutes are also not needed any longer.
We can use Tahoma here without causing any change in the current rendering,
because for all languages the former
Ubuntu substitutions did point either to Tahoma,
or to the same thing, that Tahoma atm points to
(for those language that do require additional glyphs).
This way we do not only get the substitutions closer to 2k3sp2, but will also
simplify our maintenance and testing, because the same font is guaranteed to be used then
for all themes: Classic, Blackshade and Lautus: The font which has the needed glyphs for
that specific language.
E.g.
"FreeSans" for Hindi,
"Tahoma" for most Western languages, and
"Droid Sans Fallback" for Chinese and Japanese language.
Things are cleaner and simpler this way.
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!
- Delete "DejaVu Sans Mono" font files (DejaVuSansMono.ttf etc.).
- Re-map "Terminal" font substitute to "Lucida Console" except for HebrewFonts and UnicodeFonts.
- Re-map HebrewFonts "Terminal" font substitute to "Courier New".
- Re-map UnicodeFonts "Terminal" font substitute to "Courier New". And then, re-map UnicodeFonts "Courier" font substitute to "Courier New". Delete UnicodeFonts "Courier New" font substitute.
CORE-18605
- Use IsDialogMessage function in message loop to enable Tab.
- Add WS_TABSTOP style to IDC_FONTCOMBO control.
- Set focus on create.
- Handle WM_KEYDOWN and WM_GETDLGCODE messages.
- Add UpdateCells, LimitCaretXY SetCaretXY, MoveUpDown, and MoveLeftRight helper functions.
- Delete DrawGrid, and DrawActiveCell functions for simplicity.
- Add and delete some members in MAP structure.
CORE-13806
I manually applied the final state of the reviewed (#4829) by hand.
The commit relies on (#4837) which added the Greek Tahoma glyphs, and the result now
does finally draw fine with unbold Tahoma also for the Greek ros installation.
See the final screenshot that I added today within (#4829).
Since 0.4.14-dev-6-g f45dd65 we do have a proper "Verdana" font,
so there is no need for substitution with "DejaVu Sans" any longer. That is the proper MS name for such a font.
And with 0.4.14-dev-20-g 2f4fb90 we even deleted the "DejaVu Sans" font,
so it makes no sense to keep it as a substitution target.
So adapt fonts.inf and muifonts.h, and also a test where it was still referenced.
MS 2k3sp2 does neither have such a font substitute, nor such a font.
* [REGEDIT] Partially Sync to Wine 7.17
- regproc.c and regedit.c are now in sync.
- some other mostly depending fixes for the remaining files
* [REGEDIT_WINETEST] Sync to Wine-7.0
[INF] These 2 lines are nonsense now for 2 different reasons even:
Since 0.4.13-dev-764-g dbb4432b25
we do have a proper "Times New Roman" font, so there is no need for
substitution any longer.
And since 0.4.14-dev-20-g 2f4fb903b4
we don't even have the substitution-target "DejaVu Serif" anymore.
[SETUP] Similar glitch in muifonts.h
[ROSTESTS] Thin out gdi32:GetTextMetrics test
Deletes tests for 3 fonts that we do not longer have
Fix keyboard layout icon in taskbar notification area. JIRA issue: CORE-11700, CORE-2699, CORE-18546
- Call ActivateKeyboardLayout to select the keyboard layout correctly.
- Modify WM_INPUTLANGCHANGEREQUEST parameter.
- Modify BroadcastSystemMessageW parameter.
- Revert Taskbar Notification Area MA_NOACTIVATE HACK 8344291 . This fixes Context Menu display.
- Load the "IME File" value and set the IME icon if necessary.
- Correctly implement global hooks.
- Fix truncated dialogs
- Fix element positions
- Fix element misc flags
- Also uniform resource file headers per Coding Style
Addendum to e3fdbe5806, 1866b89100, and 9186a358da.
CORE-18497
