EndpointMoved == TRUE could never be true, because BOOL is a signed type,
and the only two values in a signed one-bit type are 0 and -1.
Courtesy of VS analysis warning C6299:
Explicitly comparing a bit field to a Boolean type will yield unexpected results.
This ensure we do not rely on usermode for always passing this flag in,
which is a ReactOS specific flag.
Thanks to Doug Lyons for finding the source of the problem.
CORE-17780
Import Wine Commit 0ba1bfb0624d5e95f15499d6cfc9af1910c7c5be by Marcus
Meissner: user32: DrawText gets a 32bit flag, not a 16bit flag.
Fixes CORE-17315 - spottted by I_Kill_Bugs
The source code is licensed under MIT license, taken from
"MSDN Code Gallery Microsoft Samples" repository
(https://github.com/microsoftarchive/msdn-code-gallery-microsoft)
The original license was MS-PL, but the driver was later relicensed
as MIT.
Adopted to ReactOS code base by Michael Stamper.
Co-authored-by: Michael Stamper <michaelstamper1@gmail.com>
- Add SkewDIB helper function in dib.cpp.
- Implement Stretch and Skew feature by SelectionModel::StretchSkew and ImageModel::StretchSkew.
- Move ColorKeyedMaskBlt function.
CORE-16634
- Add Rotate90DegreeBlt function to dib.cpp.
- Implement ImageModel::RotateNTimes90Degrees and SelectionModel::RotateNTimes90Degrees.
- Improve ToolsModel::SetBackgroundTransparent.
- Extend and improve SelectionModel::InsertFromHBITMAP.
CORE-16634
- inbv.c now only contains the Inbv-specific API and nothing else.
- It will make easier for people to write their own boot themes & animations,
by just copying/adapting the bootanim.c file (and the resources).
- Add SAL annotations.
- All INBV progress bar functions (except for InbvIndicateProgress())
should not be INIT-only functions, since they can be (not yet in ROS)
used at later times -- namely, for feedback during hibernation.
In particular, the progress percentage specified to InbvUpdateProgressBar(),
or the progress feedback made with InbvIndicateProgress() calls, is
**relative** to the progress sub-range specified with a previous call to
InbvSetProgressBarSubset() (by default, the range is 0...100%).
This functionality is used e.g. when the number of progress steps is
unknown prior, for example when loading drivers: in this case progress
is made within a given percentage range.
This bug has always been with us since 2010.
- Use newly-defined Imm32CurrentPti() instead of NtCurrentTeb()->Win32ThreadInfo.
- THREADSTATE_GETTHREADINFO is same as THREADSTATE_UNKNOWN18.
- Use the paged pool to allocate HIMC rather than heap.
- Fix and improve ImmDestroyContext function.
CORE-11700
- Establish the trampoline callback USER32_CALLBACK_IMMPROCESSKEY for imm32!ImmProcessKey function, between NTUSER and IMM32.
- Add IntGetImeCompatFlags helper function.
- Implement co_IntImmProcessKey and IntImmProcessKey functions.
CORE-11700
It regressed by 0.4.15-dev-3810-g e0fc48d6e2 (#4338)
No release was ever affected therefore.
The diff looks massive in tgit-diffview, strange,
but I actually replaced just a '\' with '\n' at line 168.
My local diff tool does properly display it as a one-line-change only.
This reverts 8479509 commit which pretty much does nothing at all (the captured pointer is NULL within the stack of the function has no effect outside of the function). My mistake, sorry.
Whenever a captured security property such as privilege or SID is released, we must not have such captured property point at random address in memory but rather we must assign it as NULL after it's been freed from pool memory. This avoids potential double-after-free situations where we might release a buffer twice.
This is exactly the case with token filtering.
- Modify NtUserGetImeHotKey and NtUserSetImeHotKey prototypes.
- Define enum SETIMEHOTKEY_ACTION in <undocuser.h>.
- Define IMEHOTKEY structure in ime.c.
- Add IntGetImeHotKeyLangId, IntAddImeHotKey, IntGetImeHotKeyById, IntGetImeHotKeyByKeyAndLang, IntDeleteImeHotKey, IntFreeImeHotKeys, and IntSetImeHotKey helper functions.
- Implement NtUserGetImeHotKey and NtUserSetImeHotKey functions.
- Cleanup the IME hotkeys at process exit.
CORE-11700
This special value tells the console to default to whichever font
is deemed most appropriate for the current code page.
Add Doxygen documentation for FindCachedTTFont().
CORE-12451, CORE-17601, CORE-17803
Replaces PR #4281.
When changing the console output code page, check whether the current
font can support it. If not, try to find a suitable font for the new
code page. If none can be found:
- if we are creating a new console, forcefully switch to codepage 437
(OEM USA) and retry finding a font, falling back to "Terminal" if
none could be found;
- if we were just changing the current CP, just fail and keep the old
code page and font.
Rework the console font selection/creation functions for this new job
(see CreateConsoleFontEx() and friends). Elements of implementation
based from https://github.com/microsoft/terminal ; see code for more
information.
Silence the noisy IsValidConsoleFont2() diagnostic messages.
Add Doxygen documentation.
[CONSOLE.CPL] Only add "Terminal" to the enumerated list of faces
+ add a TODO implementation comment.
CORE-17601, CORE-17803
Replaces PR #4281.
Implement SrvGetConsoleLangId() (server-side) and set the new current
thread's locale after connecting to a console, or changing its output
code page.
Based on API tracing on Windows 2003, as well as on comments and code
gathered from: https://github.com/microsoft/terminal
Tests results are listed in PR #4301.
This test shows how a console program's thread's language ID changes,
or not, when changing the console output code page (or indirectly
when starting on/connecting to a new console), depending on whether
or not the console is running on a CJK/on a non-CJK system, and the
selected code page is a CJK/a non-CJK one.
By that, the test indirectly tests the (non-exposed) consoles GetLangId
+ SetThreadLocale() calls being made under the hood.
