- Use SAL2 annotations.
- When terminating the process if the hard error did not already,
prefer using `Parameters[1]` that contains the actual failure code,
instead of what `NtRaiseHardError()` returned.
- Allow specifying the length of the output `pszName` buffer.
- Reduce the number of character buffers required.
- Simplify parsing the "Layout Display Name" value, of the form:
"@file_path,-resID" . Positive resource ID isn't handled.
- Use `LoadLibraryExW(..., LOAD_LIBRARY_AS_DATAFILE)` for loading
the specified DLL for retrieving its resources.
- Don't leak the loaded DLL when the `LoadStringW()` call succeeds.
- Don't leak the opened registry key when the "Layout Text" value
retrieval fails.
Use case-insensitive matching for comparing the current KLID with
the enumerated ones.
For example on my machine, `GetKeyboardLayoutNameW()` would return
"0000040C" (French AZERTY layout) in capital hex number, while the
registry `HKLM\System\CurrentControlSet\Control\Keyboard Layouts`
subkeys specify the layouts in lowercase hex, which is of course
perfectly valid: the French AZERTY layout would be "0000040c".
Without the fix, there wouldn't be any matching, and as a result,
the correct keyboard layout wouldn't be selected.
- `WCHAR szLayoutId[9]` --> `WCHAR szKLID[KL_NAMELENGTH]`
- Don't use the `LCID` type for unrelated things: namely,
keyboard layout IDs.
- Simplify `CreateKeyboardLayoutList()` a little.
- Just after initially caching the path to the ReactOS installer, check
whether an unattend.inf file can be found in its directory; otherwise,
fall back to an unattend file in the current ReactOS directory.
- If this unattend.inf file specifies to run an unattended setup
(`UnattendSetupEnabled` value set to `"yes"`), automatically start the
ReactOS installer -- instead of starting the live environment desktop.
- If the user presses Ctrl+Shift+F10 however, disable unattended setup
(suggestion to override the behaviour with a keypress from Whindmar Saksit).
NOTE: in the `WM_INITDIALOG` dialog handlers, use `SendMessageW`
to simulate the button presses. This also allows the invocation
of `EndDialog()` (from the button command handlers) while the
`WM_INITDIALOG` message is handled, so that the USER dialog manager
can then directly close the dialog without showing it first.
- Use `ValueBuffer` explicitly in the `NtQueryValueKey()` calls.
- When any of the `NtQueryValueKey()` calls fail and we print an error,
avoid debug-printing an uninitialized `PartialInfo->Type` value.
- Remove unused dead code that was invoked in `SmpInvokeAutoChk()`.
The "dots" that AUTOCHK may want to display instead of its usual
messages (depending on whether /SOS is given in the boot options),
is decided by AUTOCHK itself instead of SMSS.
When loading the Session Manager "BootExecute", "SetupExecute",
..., "Execute" REG_MULTI_SZ/REG_SZ registry values, verify that each
NUL-terminated command string contained in these values is valid and
non-empty. Only then, add the command string into the suitable Execute
list. If not (the string is empty), just skip it.
Introduce a specific `SmpConfigureExecute()` handler for this purpose,
while the existing `SmpConfigureMemoryMgmt()` is kept for dealing with
(unrelated) page files values.
By skipping empty command strings, we avoid invoking `SmpExecuteCommand()`
on empty commands, and having `SmpParseCommandLine()` failing and showing
the following debug print:
```
(base\system\smss\smss.c:231) SMSS: SmpParseCommandLine( ) failed - Status == c0000001
```
- Compile the extended diagnostics messages + breakpoint only
in DBG builds.
- Trigger the breakpoint only if SMSS is being debugged (the
`BeingDebugged` flag is set in the current PEB). This will
avoid any unhandled breakpoint exceptions when running
debug builds of ReactOS without any debugger attached.
- Use a `ExceptionRecord` local variable that captures the
`ExceptionInfo->ExceptionRecord` member, and use it in the
code to shorten lines a bit.
- Print the "Memory Address" and "Read/Write" values only for
specific exceptions (`STATUS_ACCESS_VIOLATION`, `STATUS_GUARD_PAGE_VIOLATION`,
`STATUS_STACK_OVERFLOW`, and `STATUS_IN_PAGE_ERROR`), whose
parameters actually specify these values.
Additionally, print the "I/O Error" code in case of the
`STATUS_IN_PAGE_ERROR` exception.
- In all of these specific exceptions, the `ExceptionInformation[0]`
specifies the "Read/Write" (or "Execute") value, while the
`ExceptionInformation[1]` specifies the virtual address of the
inaccessible data. And not the reverse, as we did previously.
- Move `ExpandInstallerPath()` from userinit.c to livecd.c, and update
its SAL2 annotations and Doxygen comment.
- Make `StartInstaller()` directly use the cached ReactOS installer path.
- This avoids invoking yet again `ExpandInstallerPath()` when trying to
locate the installer also for the aim of determining whether to disable
the "Install" button.
When the shell is assigned to cmd.exe, open to the logged in user's profile path. This appears to match the behavior of Windows Server 2003 userinit. It is also a prerequisite for ReactOS Server Core.
CORE-20573
Improve chkdsk output when failing to complete successfully by adding the returned error code.
Return status code from fmifs/chkdsk.c in the "modifier" parameter.
If the error returned is STATUS_DISK_CORRUPT_ERROR then display a message that running again may fix it.
Optimize for speed.
JIRA issue: N/A
Do not initialize the STARTUPINFO member, which is already
filled with zeros, with zeros, in StartLsass and
StartServicesManager functions.
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
Using `userenv!CreateEnvironmentBlock()` when starting the shell ensures
that, even if it's started as LocalSystem, its environment inherits the
"dynamical" environment variables created by SMSS at runtime (stored in
`HKLM\SYSTEM\CurrentControlSet\Session Manager\Environment`).
In ReactOS/Windows PE "MiniNT" mode, the Winlogon environment doesn't
contain these values, and doesn't start the Setup with this augmented
environment. (This is compatible with what Windows does, on WinPE or
during a clean installation.)
Winlogon creates an augmented environment only when a user logs in and
starts its shell (standard boot), which isn't the case in "MiniNT" mode.
It is thus the responsibility of the module that starts the shell instead
to do it: in ReactOS' case, userinit.exe in LiveCD mode.
As a result, we get access to the `COMPUTERNAME`, `NUMBER_OF_PROCESSORS`,
`OS`, and `PROCESSOR_*` environment variables, amongst others.
Addendum to commit c498d0930a.
`SmpTranslateSystemPartitionInformation()`: Reset the `DirInfo->Name.Buffer`
to use the `DirInfoBuffer` scratch area, before doing the OS boot drive letter
fallback. Otherwise, writing directly to `DirInfo->Name.Buffer` would
use its old value, that is going to be `NULL` when the calls to
`NtQueryDirectoryObject()` failed, and this would induce a memory access
crash.
Take also the opportunity to use structures embedding the
`KEY_VALUE_PARTIAL_INFORMATION` and `OBJECT_DIRECTORY_INFORMATION`
data headers, instead of straight `CHAR` arrays. This allows the
structures to use the correct memory alignments required by these
data headers.
In `SmpTranslateSystemPartitionInformation()`, fall back to using the
OS boot drive letter if none was found to be assigned to the SystemPartition.
Otherwise, just fail if any other error was encountered.
(This behaviour has been introduced in a post-SP1 Windows 7 update.)
Additionally, simplify very slightly the code.
Follow-up of #8678. Commonize the definition of
LANGID_... values.
JIRA issue: CORE-20243
- Define LANGID_... values for CJK in <cjkcode.h> and
use it.
Prepare for Console IME Input for East Asian.
JIRA issue: CORE-20243
- Modify .github/labeler.yml.
- Add base/system/conime/ .
- Modify boot/bootdata/hivesft.inf for Console
settings.
- Add imm32!ImmCallImeConsoleIME prototype
into <imm32_undoc.h>.
- Add IMS_CONSOLEIME_1A and IMS_CONSOLEIME_1B
values into <imm32_undoc.h>, for WM_IME_SYSTEM
message.
CORE-20279
PRELIMINARY REMARK: The described bug and code workaround only applies
for x86 32-bit builds.
----
While the Winlogon notification handlers[^1] actually use a `STDCALL`
calling convention, which can be trivially verified by debugging the
official Windows <= 2003 winlogon.exe and its notification extensions,
there exist 3rd-party Winlogon notification DLLs, like the `Ati2evxx.dll`
one from AMD/ATI XP video drivers, that use a `CDECL` calling convention,
or an invalid number (zero) of parameters.
I think the reason why this happens is as follows.
The official documentation[^1] indicates that the handlers have the
following prototype:
```c
void Event_Handler_Function_Name(
_In_ PWLX_NOTIFICATION_INFO pInfo
);
```
The documentation (and possibly the internal header Windows is using for
Winlogon) is sloppy, because it doesn't tell whether the convention is
`STDCALL` or `CDECL`. When compiling routines with such a signature, the
compiler will employ whatever default convention it is set to use.
Windows code is typically compiled with `STDCALL` convention as the default
(see e.g. how the Windows Development Kit is set up), thus, such a
function signature would default to `STDCALL`. Observation (with debugger)
shows that it is what Windows' winlogon.exe is indeed expecting.
However, 3rd-party code using a different development environment, could
set the compiler to use `CDECL` as the default calling convention. As a
result, the function signature from above would use `CDECL` instead.
The difference between the `STDCALL` and `CDECL` conventions is how the
function parameters are passed on the stack and how the stack is cleaned
at the end (`STDCALL`: the function unwinds the stack; `CDECL`: the caller
does it). A calling convention mismatch would therefore corrupt the stack,
and this is exactly what happens with the `Ati2evxx.dll` from the AMD/ATI
drivers, see CORE-20279.
The ReactOS Winlogon crashes from the `_RTC_Failure()` handler just after
the 3rd-party handler returns, since we compile our code with runtime checks
enabled. Windows' winlogon.exe doesn't apparently crash, because neither
in Release nor in Checked/Debug mode did they compile winlogon.exe with
RTC enabled. However, its stack would become more corrupt with time.
In order to alleviate this in ReactOS' winlogon.exe, I decided to use
a "generic" workaround, manually calling the handler with inline ASM
(which is OK since the problem and solution is x86-specific only).
It does something similar to what the RTC support does: it checks the
stack pointer after the call and restores it if needed.
An informative message is then emitted in the debugger telling which DLL
is buggy and needs to be fixed.
[^1]: https://learn.microsoft.com/en-us/windows/win32/secauthn/event-handler-function-prototype
