- Implement caching of individual (newline-separated) text lines; this
behaviour can be enabled with a flag (enabled by MORE):
CON_PAGER_CACHE_INCOMPLETE_LINE.
This feature is necessary when reading a text file, whose text lines
may span across two or more successive temporary read buffers, and is
required for correctly determining whether the lines being read are
blank and may be squeezed.
- When squeezing blank lines, the blank-line check must be done for each
line segment corresponding to the screen line (and following) that
need to be displayed. This matches the behaviour of MS MORE.COM.
- Fix the IsBlankLine() check to not consider FORM-FEEDs as being blank
characters: This is necessary for correctly handling FORM-FEED
expansion. Also note that MS MORE.COM only checks for spaces and TABs,
so we are slightly overdoing these checks (considering other types of
whitespace).
- Get rid of ConCallPagerLine() and the intermediate CON_PAGER_DONT_OUTPUT
state flag that were used repeatedly for each and every small line
chunks. Instead, call directly the user-specified 'PagerLine' callback
when we are about to start treating the next line segment to be
displayed (see comment above).
- Fix the exit return condition of ConPagerWorker(): it should return
TRUE whenever we displayed all the required lines, and FALSE otherwise.
Otherwise, the previous (buggy) condition on the data being read from
the text file, may lead to the prompt not showing when a screenful of
text has been displayed, if it happened that the current text buffer
becomes empty at the same time (even if, overall, the text file hasn't
been fully displayed).
- In MorePagerLine(), when we encounter for the first time a blank line
that will be squeezed with other successive ones, display a single
blank line. But for that, just display one space and a newline: this
single space is especially needed in order to force line wrapping when
the ENABLE_VIRTUAL_TERMINAL_PROCESSING or DISABLE_NEWLINE_AUTO_RETURN
console modes are enabled. Otherwise the cursor remains at the
previous line (without wrapping), and just outputting one newline will
not make it move past 2 lines as one would naively expect.
- The column extent should cover the whole width of the console screenbuffer.
On the contrary, the line extent covers only the number of lines that
cover the current displayed console window.
- Since the console can be resized while the pager is prompting, we need
to actually recalculate in the prompt routine the default number of
lines for a screen.
- Reset s_nNextLineNo when paging a new file.
- Shorten the names of the flags: CON_PAGER_FLAG_*** --> CON_PAGER_***.
- Reorder few members in the CON_PAGER pager structure where they make sense.
- ScreenColumns, ScreenRows --> PageColumns, PageRows: keeping the open
possibility for having a pager controlling a region of different size
than the screen.
- Add doxygen documentation for ConWritePaging().
GCC has some functions, variables & type attributes which can be used as aliases
for some of the SAL annotations. Although it's not as rich & precise, it's still useful
since we actually enable -Werror on GCC builds whereas we don't use such an option
on MSVC builds.
For now, _Must_inspect_result_ is aliased to warn_result_unused attribute.
Suppose dwFlags == 1 | 4 (i.e. skipping the flag 2).
Then the while-loop would only run once, because at the second iteration
(after dwWhich >>= 1; has been executed once), dwWhich value == 2, but
dwWhich & 0x1 == 0, which makes the while-loop condition false.
Instead the loop should run, but the handling of the extension should be
skipped.
- Add as well the undocumented 0x40 dwFlags value from shlwapi!PathFileExistsDefExtW()
to the list.
- Fix a bug (also present in Win2k3) in PathResolveW() where, specifying
the PRF_DONTFINDLNK flag, would also erroneously exclude checking for
the .cmd extension as well (which was obviously NOT the original
intention, from the name of the flag and the documentation as well:
https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-pathresolve
).
Addendum to 3a822e4f.
With introduction of 74e527b, a330b56 and subsequently 2791ecd ReactOS can now properly set IOPL (I/O privilege level) for user mode trusted processes. With that said, enable the compilation of raise hard error function call code back.
ProcessUserModeIOPL is strictly implemented for 32-bit architecture so it doesn't make any sense for CSRSS to gather user mode I/O privilege when that won't work anyway.
ProcessUserModeIOPL, ProcessWow64Information and ThreadZeroTlsCell classes fail on AMD64 build because of wrong IQS values assigned to them. Also explicitly tell the compiler that ProcessUserModeIOPL is strictly for x86 as user mode I/O privilege level is 32-bit stuff.
In addition to that, implement IQS_NO_TYPE_LENGTH macro which it'll be used for classes such as ProcessUserModeIOPL where type length is not required and that it should be 0. With that said, we indirectly fix a size length mismatch issue with ProcessUserModeIOPL on 32-bit of ReactOS as well.
