https://reactos.org/wiki/index.php?title=Special:NewPages&feed=atom&hideredirs=1&limit=50&offset=&namespace=0&username=&tagfilter=ReactOS Wiki - New pages [en]2024-03-28T14:05:12ZFrom ReactOS WikiMediaWiki 1.31.7https://reactos.org/wiki/DirectUIDirectUI2024-03-11T21:52:20Z<p>Anonanon: Add publisher section</p>
<hr />
<div>{{stub}}<br />
DirectUI is a UI framework written in C++ for developing user interfaces for Microsoft Windows. This library is largely undocumented by Microsoft. It is used in Microsoft Office, Internet Explorer 8, and throughout the Windows shell. DirectUI is implemented in two libraries. In Windows XP, duser.dll was introduced. Windows 7 introduced a new DirectUI library, dui70.dll. The duser library is slowly being deprecated starting with Windows 10. The dui70 library implements many controls, or elements, that are used in DirectUI applications.<br />
<br />
==Applications that use DirectUI==<br />
<br />
Using dependency walker or [https://github.com/lucasg/Dependencies Dependencies], we can determine which executables link against the duser and dui70 libraries. Here are some applications that are known to link against the DirectUI libraries. <br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Application !! Publisher !! Versions !! duser.dll !! dui70.dll<br />
|-<br />
| Word || Microsoft || 2019+ || Yes || Yes<br />
|-<br />
| Task Manager|| Microsoft || 6.2+ || Yes || Yes<br />
|}</div>Anonanonhttps://reactos.org/wiki/XDDM/Video_RestoreXDDM/Video Restore2024-01-25T16:05:16Z<p>Reactosfanboy: fix a typo</p>
<hr />
<div>The following page attempts to explain the restoration flow for XDDM (XP Display driver model) drivers.<br />
<br />
Please note that this page just explains what Windows 2003 Server does, it should be used as a reference for ReactOS only.<br />
<br />
TODO: The reference is not 100% complete, I think there's extra code in win32k that handles the exception and swaps the gpu driver to the vga default.<br />
<br />
== 1. Creation and entring the monitored sections (WIN32K) ==<br />
Win32k during the driver creation, will create a deferred watchdog (one or more it seems), that points to the WdDdiWatchdogDpcCallback found in watchdog.sys (XP) or videoprt.sys (Win2003)<br />
<br />
Once we enter a monitor section (eg. we are trying to BltBit), we have to wait until the watchdog has timed out.<br />
<br />
If the watchdog hasn't timeout, we simply exit the monitored section, otherwise, the Dpc callback will be fired meaning that we might have an expired watchdog timer.<br />
<br />
== 2. The Watchdog driver DPC callback WdDdiWatchdogDpcCallback (videoprt.sys) ==<br />
This function simply queues a Dpc routine to the internal function WdpBugCheckStuckDriverWorkItem<br />
<br />
=== WdpBugCheckStuckDriverWorkItem ===<br />
# Bugcheck if the watchdog is not found<br />
# Create a thread (Access rights THREAD_ALL_ACCESS)<br />
# Sets the thread as the same priority as the current one<br />
<br />
The call will now be forwarded to thread start routine WdpBugCheckStuckDriver<br />
<br />
=== WdpBugCheckStuckDriver ===<br />
# If the watchdog has made any progress (aka we entered a new monitored section) then the driver is no longer stuck so we have to <br />
# Windows sets up in this case the informations about the crashed display adapter in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Watchdog\Display<br />
# Windows now would raise an exception to the debugger if we are in a debugging session (See [https://learn.microsoft.com/en-us/windows-hardware/drivers/display/disabling-the-watchdog-timer-while-testing-display-drivers here])<br />
# If we haven't disabled the Display recovery then we raise a kernel APC to the caller thread<br />
<br />
The raised APC kernel routine WdpKernelApc will be called.<br />
<br />
=== WdpKernelApc ===<br />
NOTE: we should be in the monitored thread now<br />
<br />
# We check if the watchdog has made any progress, if it did it means that the driver most likely unfreezed so we can stop the routine<br />
# We get the current thread information and check if the associated thread code is using a watched device driver (this seems<br />
to be done by checking if the EIP is in some range I belive the motitored section data chunk)<br />
# If we have found it, we raise an exception KMODE_EXCEPTION_NOT_HANDLED to the attached thread (this is done by moving the EIP to a function<br />
that raises the exception)<br />
# We then generate a minidump of the thread crash<br />
<br />
If we were not able to find the associated GPU driver with the associated thread, then we bugcheck with STATUS_HUNG_DISPLAY_DRIVER_THREAD<br />
<br />
There are some exception to this:<br />
* If https://learn.microsoft.com/en-us/windows-hardware/drivers/display/disabling-timeout-recovery-for-display-drivers is set to 0<br />
the kernel MUST bugcheck<br />
* If https://learn.microsoft.com/en-us/windows-hardware/drivers/display/disabling-the-watchdog-timer-while-testing-display-drivers is set to 1,<br />
then the kernel MUST NOT bugcheck</div>Cylurdhttps://reactos.org/wiki/Watchdog/WD_APIWatchdog/WD API2024-01-09T16:18:19Z<p>Cylurd: </p>
<hr />
<div>== Common watchdog functions ==<br />
<br />
=== WdCompleteEvent ===<br />
This function deferences the thread that is associated with the current event.<br />
<br />
On a deferred watchdog, it also resets the monitored section.<br />
<br />
=== WdDereferenceObject ===<br />
Decrements the reference count of the watchdog object.<br />
<br />
=== WdGetDeviceObject ===<br />
Gets the linked device object specified in the watchdog initialization<br />
<br />
=== WdGetLastEvent ===<br />
Gets the last event that happend in the watchdog. For example the interruption of the watchdog by the user via WdStopWatchdog.<br />
<br />
=== WdGetLowestDeviceObject ===<br />
Gets the lowest-level device object that is linked from the associated device object of the watchdog.<br />
<br />
=== WdMadeAnyProgress ===<br />
On a normal watchdog, ...<br />
<br />
On a deferred watchdog, we have made any progress if we have entered a monitored section that was not hitted by the internal watchdog DPC routine or it we haven't left a monitored section yet from the DPC routine.<br />
<br />
=== WdDdiWatchdogDpcCallback (NT5.1 only) ===<br />
This is the DPC callback for the XDDM video mode restore. For more information on this routine, please see [[XDDM/Video_Restore]]<br />
<br />
=== WdAttachContext (NT5.2+) ===<br />
Create and allocates a new user-data (known as context), this is done to keep a reference of allocated datas that are relative to the video restore in the Watchdog rather than inside win32k or videoprt.<br />
<br />
=== WdDettachContext (NT5.2+) ===<br />
Frees the preivously allocated context.<br />
<br />
=== WdIsDebuggerPresent (NT6+) ===<br />
Simply checks if the watchdog is currently debugged.<br />
<br />
=== WdQueryDebugFlag (NT6+) ===<br />
Simply checks if the watchdog stops on an assertion or an error.<br />
<br />
== Normal watchdog functions ==<br />
<br />
=== WdAllocateWatchdog ===<br />
This function allocates a normal watchdog based from the information provided in the parameters. The function returns null if the watchdog could not be allocated.<br />
<br />
=== WdFreeWatchdog ===<br />
This function decrements the reference counter of the object by 1. If the count is 0 then the object is freed.<br />
<br />
=== WdReferenceObject ===<br />
Increments the watchdog object reference counter by one.<br />
<br />
=== WdStartWatch ===<br />
This function attempts to start the watchdog.<br />
<br />
The start is done in the same way as the resume, it resets the watchdog timer to the current thread time.<br />
<br />
=== WdStopWatch ===<br />
This function attempts to stop the watchdog.<br />
<br />
This function will also clear any upcoming Dpc event and free it's associated thread object reference.<br />
<br />
The function can opotionally check for the started count by passing TRUE to CheckForStartCount, in this case<br />
the watchdog will be stopped only if the number of this calls matches the ones from WdStartWatch.<br />
<br />
=== WdSuspendWatch ===<br />
This function attemps to suspend the watchdog.<br />
<br />
The suspension is done by simply cancelling the watchdog timer.<br />
<br />
=== WdResetWatch ===<br />
Resets the watchdog state to the default state (cleans any leftover saved timing and so on).<br />
<br />
It will also restart the watch to it's initial due time (like WdResumeWatch) ONLY if the watchdog was not previously suspended.<br />
<br />
=== WdResumeWatch ===<br />
This function attempts to resume the suspended watchdog.<br />
<br />
The function can opotionally check for the suspend count by passing TRUE to CheckForResumeCount, in this case<br />
the watchdog will be resumed only if the number of this calls matches the ones from WdSuspendWatch.<br />
<br />
The resume is done by simply resetting the watchdog time to the initial Watchdog due time.<br />
<br />
== Deferred watchdog functions ==<br />
<br />
=== WdAllocateDeferredWatchdog ===<br />
This function allocated a deferred watchdog based from type and information provided in the parameters. The function returns null if the watchdog could not be allocated.<br />
<br />
=== WdFreeDeferredWatchdog ===<br />
This function decrements the reference counter of the object by 1. If the count is 0 then the object is freed.<br />
<br />
=== WdEnterMonitoredSection ===<br />
This function will start monitoring a code section, it will begin to monitor the caller thread (user or kernel time or both) until it has hit a timeout or the monitored section is exited.<br />
<br />
'''NOTE:''' A deferred watchdog can only monitor one thread at the time.<br />
<br />
'''NOTE:''' This function may be called more than once after an initial section has been monitored, in such cases the timer would enter a reentrant state.<br />
<br />
=== WdExitMonitoredSection ===<br />
Stop monitoring a thread section.<br />
<br />
'''NOTE:''' This function may remove the reentrant status if the number of this call matches the ones done by WdEnterMonitoredSection<br />
<br />
=== WdStartDeferredWatch ===<br />
Sets up the deferred watchdog info and starts a timer that will hit the passed DPC at the specified time.<br />
<br />
=== WdResetDeferredWatch ===<br />
Resets the watchdog state to it's creation state. (resets the monitor section, remove any reentrancy)<br />
<br />
=== WdResumeDeferredWatch ===<br />
Decrements the suspend count by 1.<br />
<br />
=== WdSuspendDeferredWatch ===<br />
Increments the suspend count by 1.<br />
<br />
=== WdStopDeferredWatch ===<br />
This function attempts to cancel the watchdog timer if it was previously astarted.<br />
<br />
It will also fire the event WATCHDOG_EVENT_DEATTACHED_THREAD if we were in an expired timer, so we can notify the dpc that we are no longer monitoring any thread.<br />
<br />
The function will also remove any pending event from the DPC, and free the associated monitored thread if any is found (this only happens when the timer was not expired).<br />
<br />
== Logging API (NT6+) ==<br />
<br />
=== WdInitLogging ===<br />
This function seems to initialize via Heap allocation a stack of events that the watchdog can log.<br />
<br />
The logging seems to simply be an array of last errors that you can fetch by error type.<br />
<br />
=== WdLogEvent5 ===<br />
This function tries to log a possible error inside the log events arrray.<br />
<br />
In case it's a critical error, the system will BugCheck allowing the watchdog to be debugged.<br />
<br />
'''NOTE:''' For a critical error Windows seems to also create a minidump/memory dump of some kind, a checked build can confirm this behavour as it's a stub in free versions but still referenced.<br />
<br />
=== WdLogGetRecentEvents ===<br />
<br />
=== WdLogGetEventOrder ===<br />
<br />
=== WdLogNewEntry5 ===</div>Cylurdhttps://reactos.org/wiki/Boot_processBoot process2023-12-31T16:49:12Z<p>Cylurd: adjust NLS meaning</p>
<hr />
<div>This page aims to explain a simplified (i386) bootloader of ReactOS by code, similar to the behavour the Windows does.<br />
<br />
'''NOTE:''' this page does not cover UEFI<br />
<br />
For more information about each of the module that are being discussed, check the following pages:<br />
<br />
- [[FreeLDR]]<br />
<br />
- [[Kernel]]<br />
<br />
- [[SMSS]]<br />
<br />
- [[CSRSS]]<br />
<br />
== FreeLDR startup ==<br />
<br />
# A real-mode (16-bit) binary (boot/freeldr/freeldr/arch/realmode/i386.S) sets up the protected mode (32-bit) in the current CPU and launcher the loads the actual freeldr binary (found inside loader/freeldr.sys).<br />
# RealEntryPoint (boot/freeldr/freeldr/arch/(cpu)/entry.S) sets up the environment (such as BootDrive and BootPartition) and jumps to BootMain, the C entrypoint, this is where the real FreeLDR initialization starts.<br />
# During the initialization, FreeLDR loads the command line, debugger, memory manager, UI. This part will also allocate the sections of the RAM reserved for the kernel boot parameters and the boot devices such as SCSI.<br />
# The code calls "RunLoader" (boot/freeldr/freeldr/bootmgr.c) which parses the INI and the main UI loop begins.<br />
# Once the user has selected the OS, "LoadAndBootWindows" (boot/freeldr/freeldr/ntldr/winldr.c) is selected and the computer can start loading ReactOS.<br />
<br />
== FreeLDR Phase0 Startup ==<br />
# FreeLDr will allocate everything we need that will be passed to the kernel, an important piece that's being allocated is the [https://github.com/reactos/reactos/blob/f5346cbc1b0c08559b77ded0ef76a27a484c20fa/sdk/include/reactos/arc/arc.h#L569 Loader Parameter Block] which contains all the informations the kernel needs to start<br />
# The SYSTEM hive (HKEY_LOCAL_MACHINE) is loaded<br />
# From the SYSTEM hive, we get the information of the NLS (ANSI/Unicode conversion tables) for the registred locale and loads it. This is done for displaying the text such as the part where all the drivers are written to the screen while loading in Debug/Safe mode.<br />
# errata inf files are loaded (todo)<br />
# The executable for the kernel (ntoskrnl.exe) and the specified HAL component (like halx86.dll) are now loaded. The kernel debugger DLL (such as KDCOM) are also loaded now if the /DEBUG flag is specified.<br />
# Boot drivers like ntfs.sys (which are specified inside the SYSTEM hive) are loaded. After this stage, FreeLDR can NO LONGER recover if any crash happens.<br />
<br />
== FreeLDR Phase1 Startup ==<br />
# Driver list and ARC devices are loaded to the kernel<br />
# The videomode is changed from FreeLDR to a ReactOS compatible one (this is done showing things like the logo)<br />
# After other initialization, the kernel entrypoint "KiSystemStartup" (ntoskrnl/ke/(cpu)/kinit.c or boot.s) is called and the control is now passed to the ReactOS kernel.<br />
<br />
== Kernel startup ==<br />
(note: Stage0 and Stage1 bootup of the kernel is omitted, this page needs to be finished)<br />
<br />
# "KiInitializeKernel" initializes the kernel for the executive execution (such as the SMSS thread)<br />
# "ExpInitializeExecutive" reads whatever it's stored in \\HKLM\\CurrentControlSet\\Control\\Session Manager\\kernel\\UserInit and creates the first user process by launching the specified executive (smss.exe)<br />
# The kernel will finally jump to KiIdleLoop, waiting for process to dispatch<br />
<br />
== SMSS ==<br />
# The entrypoint _main (base/system/smss/smss.c) starts by making the process critical and then calling SmpInit (base/system/smss/sminit.c)<br />
# The default SIDs/ACLs are created<br />
# Two LPC pipes (\\ApiPort and \\SmApiPort) are created. This pipes are used for allowing a communication with CSRSS and the subsystem servers<br />
# smss will load the remaining parts of the ReactOS registry and unlocks the writing access in disks<br />
# The code will then call "SmpLoadDataFromRegistry", which initializes the DOS devices (\DosDevices\COM1 for example) symbolik links<br />
# All the process from HKLU\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute are executed (SmpExecuteCommand). This processes are used for executing specific things like the disk scan (scandisk) which is ignored in LiveCD.<br />
# All the known caching DLLs from HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\KnownDLLs are mapped<br />
# Creates the pagefile (pagefile.sys) if we're not running a LiveCD<br />
# Unlocks the registry so data can now be written<br />
# All the environment variables (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment) are loaded and several environment variables (like %PROCESSOR_LEVEL%) are being created<br />
# The code will call SmpLoadSubSystemsForMuSession, which will try to execute any command specified in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SetupExecute, it will also setup HKEY_LOCAL_MACHINE\SYSTEM\Setup and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup<br />
# The kernel mode subsystem (from HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems) is now loaded if being found. (NOTE: The win32k.sys path is hardcoded.)<br />
# All the subsystems specified in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Required are loaded (by calling XmpExecuteCommand, the debug one is launched with a special SMP_DEBUG_FLAG)<br />
# If HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Execute is not empty, smss will launch that as the initial userland command, otherwise winlogon.exe will be started.</div>Cylurd