This fixes the toolbar in FileZilla 3.8 being drawn wrong (grey)
It regressed by 0.4.15-dev-1603-g 232c45fcd7
And todays fix is a partial revert of that guilty rev.
The reverted part is not even necessarily needed for what we had in mind back then,
It was just a first tiny step with the aim to get rid of the comctl32.h changes of that commit.
But that goal was and even is far out of reach for many other reasons also.
Actually we should have reverted the toolbar.c change back then already,
before committing the "flipfix9".
CORE-18263
[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
- Implement the architecture-specific pagefile size limits.
In particular, verify that the selected volume on which to create
the page file can accomodate the theoretical maximum limit (e.g.
FAT32 cannot accomodate a 16 TB pagefile on x64, and the limit must
be lowered down to 4 GB).
- Change the IDS_WARNINITIALRANGE and IDS_WARNMAXIMUMRANGE strings
so that the maximum limit mentioned is the dynamic one.
- Review, improve and fix other aspects of the code.
Parts of this PR: addendum to commits 4d2d2dbb2 (#2597), 3bee3b92a (#2706).
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.
That way, we don't have anymore the VGA device together with primary device in device list.
Change also EngpUnlinkGraphicsDevice() function to add back VGA device to device list
when removing its parent from device list.
CORE-18522
As IOCTL_VIDEO_GET_CURRENT_MODE returns 2 as ModeIndex, wait for the same value
in IOCTL_VIDEO_SET_CURRENT_MODE.
Also change vgaddi to send this hardcoded value.
vga_new also uses 2 as index for 640x480x16
DFM_MERGECONTEXTMENU handler works better now. However there is difference
between ours and Windows' menu building systems, which has to be fixed.
Addendum to 64657051c3. CORE-13841 CORE-18577
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.
Classic Theme: disabled "checked" checkboxes should be grey CORE-18609
and not black, like they erroneously were.
This patch does not seem to have any impact on how they are rendered
for themed ros.
Ftr: We experimented also with COLOR_GRAYTEXT instead of COLOR_BTNSHADOW
but that did result in incorrect drawing of disabled "checked" checkboxes for
the 'High Contrast' Color Schemes.
Fixes 48 failing tests of user32:CharFuncs.
Only 12 minor failing tests are left!
Thanks to Simone Mario Lombardo for the problem analysis!
CORE-18415 CORE-18452
... 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.
In explorer filebrowser 'details' view
the column 'comments' had invalid length of zero, and therefore
was hidden under the 'attributes' column.
I guess even after this patch, it will not display any
sane contents in there yet.
Therefore I chose a small width of 10 only, to reduce the chance for
it to trigger an undesired horizontal scrollbar.
As far as I see we don't support manual showing and hiding of additional columns yet.
By default my Windows does not show this column. But when activated manually, it is always
shown on the right hand side of the 'attributes' column.
Sync the barebone fix from Wine (wine-7.19-557-g13cc08e32d6):
https://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=grep&s=ddraw_surface_update_frontbuffer%28
and
13cc08e32d:/dlls/ddraw/surface.c
- Added "swap_interval" argument to ddraw_surface_update_frontbuffer()
- Added ddraw_swap_interval_from_flags() function for dispatching
the integer type of required swap interval
- Updated ddraw_surface_update_frontbuffer() function for managing the
swap interval between backbuffer and frontbuffer (and relative flipping)
- Updated the ddraw_surface7_Flip() function for relaying the swap interval
to ddraw_surface_update_frontbuffer() function.
- Added 0 value (as Wine) when the swap interval is not required
This fixes empty white screen issue on rendering because of lacking
swap interval for the software / games that use ddraw.
CORE-18547
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.)
This is really ReactOS-specific, so I surround them with __REACTOS__
(even if this is our code) to differentiate these from Win2k3 behaviour,
even though they were strongly inspired by what was possible in the beta
versions of NT 3.1 (pre-3.10.404).
Interestingly, Windows 7+ partially re-introduced that functionality
(just in differencing "Windows=On" from "Off").
See https://reactos.org/wiki/User:Hbelusca/CSRSS for more information.
