CORE-9023, CORE-18033
- Reset the UI to a minimal one in SOS mode.
- In SOS mode, a trace of loaded files is displayed on the screen,
instead of the usual progress bar.
- Add a callback to the PE loader to notify when imported DLLs are
loaded for a main image. This allows getting an accurate SOS trace.
- If the started OS loader failed and we are back to the OS selection
menu, re-initialize the UI as the loader may have messed up the display
in the meantime.
- Tear down allocated off-screen back-buffer when uninitializing the TUI.
- Clear up the screen when initializing the direct-UI.
- Remove excessive UiDrawBackdrop() calls that caused too many
unnecessary redraws.
- ProgressBar: Clear only the portions that need to be cleared up.
This allows to not use DrawBackdrop anymore and the flickering.
- Remove duplicated code from directui.c and use the one from
TUI instead, with the latter properly #ifdef'ed for _M_ARM.
- Fix their title color.
- Add SAL annotations.
- TuiDrawCenteredText: Partly fix centering calculations (susceptible
to give negative coordinates).
- TuiDrawText2: Don't display anything if X or Y are out of the screen.
- Remove duplicated code from directui.c and use the one from
TUI instead, with the latter properly #ifdef'ed for _M_ARM.
- Provide the minimal implementations for NoUiDrawText*().
- TuiDrawText() is just a particular case of TuiDrawText2().
- Isolate the TuiPrintf() and TuiDraw*Text*() functions as separate
"Generic TUI utils".
- Fix "TAG_TAG" typo in TAG_TAG_TUI_PALETTE.
- Add SAL annotations.
- Add IntReAllocatePoolWithTag function in window.c.
- Define WINDOWLIST structure in "window.h".
- Add IntBuildHwndList and IntFreeHwndList helper functions in window.c.
- Add IntAssociateInputContext and IntAssociateInputContextEx helper functions in ime.c.
- Implement NtUserAssociateInputContext function.
CORE-11700
It popped up very reliably when performing git-clone of the ros sources
while having the taskmgr open in the processes-tab.
Or when building 'ninja bootcd -j1' while having the taskmgr open in the processes-tab.
It is always possible to ignore it and then continue using ros for days without
noticing any side effects.
James Tabor judged the assert to have a "questionable logic".
Giannis who once added it, was also ok with commenting it.
His words:
This assertion isn't something fatal,
the worst thing that can happen from continuing on it would be
to make the thread get awake more times than it should.
It was commented out already on 2020-04-21 via
0.4.14-dev-1519-g 87f6c82d85
Before purging the data cache of a certain section of a file from system cache, we have to unintialize the private cache maps of that section if a filesystem or any other component prompts the kernel to do so.
- Fix Undo/Redo mechanism.
- Finish drawing when the tool is to be chanaged and when the file is to be saved.
- Add ToolBase::OnFinishDraw to virtualize finishing drawing.
- Extend bClearRedo parameter to ImageModel::Undo.
- Add ImageModel::DrawSelectionBackground and ImageModel::DeleteSelection methods.
- Fix some WM_PAINT message handling.
CORE-17969
Suppose you copy a CPL file (e.g. console.dll renamed into console.cpl)
into a path containing spaces, for example into the Desktop:
C:\Documents and Settings\Administrator\Desktop\console.cpl
If the shell registry value for the "open" action of 'cplfile' does not
contain quotes around %1, then the Control_RunDLL function will attempt
to load "C:\Documents" as a file, which of course does not exist.
(NOTE: Missing in ReactOS: Doing a PathFindOnPath() or a PathFileExists()
call to verify that the file actually exists, instead of blindly trying
to run it and failing later in kernel32!LoadExecuteExW ...)
Adding quotes around the %1 fixes this and the correct file is being
loaded.
This behaviour has been confirmed to exist e.g. on Windows Server 2003
too (and is thus *NOT* a bug in ReactOS/Wine's Control_RunDLL
implementation).
----------------------
How to confirm this behaviour, in Win2k3 x86:
1. Start Win2k3 in debug mode under WinDbg. Ensure you have the debug
symbols available.
2. Once loaded, break into the debugger, attach context to explorer.exe,
and enter the magical :) single WinDbg command (all in one line, with
**NO inserted newlines!!**):
bp shell32!CPL_RunMeBaby ".echo \"CPL CmdLine:\"; ?? (wchar_t*)*(void**)(@esp+12);
bp SHLWAPI!PathIsFileSpecW \".echo \\\"CPL Path:\\\"; ?? (wchar_t*)*(void**)(@esp+4);
bc \\\"SHLWAPI!PathIsFileSpecW\\\"; g;\"; g"
(Explanation:
a breakpoint is placed in the internal shell32!CPL_RunMeBaby function.
When the bp is hit, it runs the large WinDbg command inside the quotes.
This command echoes an informative line, then dumps the 3rd parameter
of the function on the stack that contains the CPL command-line.
It then adds a new breakpoint in SHLWAPI!PathIsFileSpecW, which is the
function that is being called *just after* the internal parsing of the
CPL command-line, and will verify whether the extracted CPL path does
exist. That new breakpoint in turn will run a WinDbg command that will:
(i) Display the CPL file path (1st-param of that new function), then
(ii) Clear that breakpoint. Finally, automatic continuation ensues.)
3. On vanilla Win2k3, whose 'cplfile' "open" action does contain the
quotes around %1:
rundll32.exe shell32.dll,Control_RunDLL "%1",%*
you will observe the following:
CPL CmdLine:
wchar_t * 0x00094e30
""C:\Documents and Settings\Administrator\Desktop\console.cpl","
CPL Path:
wchar_t * 0x0007f898
"C:\Documents and Settings\Administrator\Desktop\console.cpl"
Notice the extra pair of quotes around the CPL filename in the CmdLine.
4. When modifying the 'cplfile' "open" action by *removing* the quotes
around %1, you will instead see the following, thereby confirming
the behaviour, which is now identical to what used to happen in ROS:
CPL CmdLine:
wchar_t * 0x00094e30
"C:\Documents and Settings\Administrator\Desktop\console.cpl,"
CPL Path:
wchar_t * 0x0007f898
"C:\Documents"
Due to the (now) absence of quotes around %1, the command-line gets
wrongly parsed and the extracted file path is incorrect.
- Rename <ddk/imm.h> as <ddk/immdev.h>.
- Delete sdk/include/reactos/wine/imm.h (this header is confusing and nonsense).
- Changes related to it.
CORE-11700
colors.c(129): warning C6287: Redundant code: the left and right sub-expressions are identical.
colors.c(159): warning C6001: Using uninitialized memory 'colorIndex'.
colors.c(180): warning C6385: Reading invalid data from 'ConInfo->ColorTable': the readable size is '64' bytes, but '259696' bytes may be read.
(I thank ThFabba for the suggestion fix.)
console.c(313): warning C6387: 'ConInfo->hWnd' could be '0': this does not adhere to the specification for the function 'SendMessageW'.
font.c(60): warning C6387: 'Preview->hFont' could be '0': this does not adhere to the specification for the function 'GetFontCellSize'.
font.c(230): warning C6001: Using uninitialized memory 'szFontSize'.
font.c(230): warning C6054: String 'szFontSize' might not be zero-terminated.
font.c(671): warning C6387: 'hFont' could be '0': this does not adhere to the specification for the function 'GetFontCellSize'.
layout.c(502): warning C6387: 'FontPreview.hFont' could be '0': this does not adhere to the specification for the function 'SelectObject'.
Any valid code page value name in System\CurrentControlSet\Control\Nls\CodePage
is a string representation of its corresponding decimal value, that
cannot be larger than MAXUSHORT == 65535, i.e. longer than 5+1
characters.
Noticed with the analyser warning
dll\cpl\console\options.c(74): warning C6262: Function uses '32808' bytes
of stack: exceeds /analyze:stacksize '16384'. Consider moving some data to heap.
Make the enumeration loop actually stop when ERROR_NO_MORE_ITEMS is
returned. If we got another error, e.g. because the value name was
too long (and thus, an invalid code page), just ignore and continue
looping.
- Add IMC_GETCONVERSIONMODE, IMC_GETSENTENCEMODE, IMC_GETOPENSTATUS, IMC_GETSOFTKBDPOS, and IMC_SETSOFTKBDPOS macros into <ddk/imm.h>.
- Implement WM_IME_CONTROL message handling of the IME window.
CORE-11700
