- Move call_copy_ctor and call_dtor asm functions into exception_ptr.s
- The code in exception_ptr.c isn't needed, only the asm functions, so remove the file from build and instead compile exception_ptr.s for both GCC and MSVC builds
Extracted from the pci.ids database at https://pci-ids.ucw.cz/ from 2026-01-31 03:15:01.
Maintained by Albert Pool, Martin Mares, and other volunteers from the PCI ID Project.
Its purpose is to offer an out-of-the-box generic framebuffer video
(a video miniport driver for win32k will be introduced in a future PR)
to ease ReactOS porting to other possibly non-PC-compatible systems,
where no VGA-compatible video is present and only linear framebuffers
are available; for example: XBOX, UEFI with GOP only, AppleTV, etc.
Of course, once ReactOS is ported, one can then (and should) write,
or use existing video drivers tailored to the system of interest.
Together with our FreeLoader, this driver could also be employed for
of porting/modding Windows 2000/XP/2003 attempts to other platforms,
as this has been done by external contributors.
Current limitations:
- Only supports 32 bits-per-pixel ARGB format. This limitation will be
removed in subsequent PR(s).
- May be slow during rendering (region color filling and scrolling);
I will try to improve this as time goes.
This driver's code is loosely based upon preliminary code by Justin Miller
and on the existing XBOX bootvid implementation.
Tested by Justin Miller (@TheDarkFire) for UEFI, and by Sylas Hollander
(@DistroHopper39B) with his AppleTV port.
It has also been tested with VESA linear modes on PC by myself.
Their purpose is to simplify the way a compatible boot video driver
and a generic framebuffer miniport driver can retrieve this information.
In this iteration, the data is retrieved only from the kernel loader-block
ARC tree, via the `KeFind(Next)ConfigurationEntry()` routines.
As such it can be used only by the boot video driver (loaded early in the
boot process).
Other methods, suitable for retrieving this information later in the
boot process, will be added in the future.
This information is set up by the bootloader hardware detector and stored
into the system configuration tree for consumption by the NT OS loader and
other OS subsystems. This method doesn't require modifying the NT kernel
loader parameter block or extension(s), thus also allowing for a backward-
compatible usage when loading Windows OSes like 2000, XP/2003, or Vista/7.
The framebuffer information can then be retrieved by a supported bootvid
and a generic framebuffer win32k video driver.
Prefer using the syntax:
`FIELD_OFFSET(CM_PARTIAL_RESOURCE_LIST, PartialDescriptors[k]) + ...;`
which is in general clearer and explicitly specifies the actual
number of resource descriptors used, over the other one:
`sizeof(CM_PARTIAL_RESOURCE_LIST) + (k-1) * sizeof(CM_PARTIAL_RESOURCE_DESCRIPTOR) + ...;`
Based on a suggestion by Dmitry Borisov.
CORE-13935
Improve "is_dib_monochrome" function in win32ss/user/user32/windows/cursoricon.c
so that it returns TRUE on a monochrome color table with WHITE first and BLACK second.
CORE-13935
* Make LoadImage1bpp.c a sub-test of LoadImage.c for apitest.
* Add broken() for Vista x64 Testbot regression test fix based on reviewer comments.
According to the kerestorefloatingpointstate msdn article shouldn't be on the kernel's responsibility to handle. for the life of me i couldn't figure out why this specific driver does this until finally I tried this on Windows and low and behold on checked builds of windows it actually tells you it does the exact same thing. Investigating deeper I realized win32k just has some extra handling for this dumb case.
Co-authored-by: Hermès BÉLUSCA - MAÏTO <[email protected]>
Co-authored-by: Timo Kreuzer <[email protected]>
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
Stop pointless target_sources(xxx PRIVATE $<TARGET_OBJECTS:gcc_ssp_nt>). The only effect it has is to force the object file into the target, which was already done by specifying the libraries as OBJECT libraries, which is also pointless, and only leads to problems.
This commit attempts to resolve two regressions and improve realhw behavior
A PNP_DETECTED_FATAL_ERROR bug check caused by the monitor device instance being duplicated.
https://jira.reactos.org/browse/CORE-20410
this is mostly due to ChildID being overwritten with the same bus/slot when 2 monitors are attached to one GPU
And video drivers failing to startup after calling VideoPortCreateSecondaryDisplay
Co-authored-by: Dmitry Borisov <[email protected]>
Co-authored-by: Hermès BÉLUSCA - MAÏTO <[email protected]>
- Fix ZeroBits test and remove some useless and confusing "tests"
- Add another ZeroBits test (use as a bitmask)
- Fix some status tests for Windows 10
- Fix DllLoadNotification test on Vista (which seems to be broken)
- Fix NtAcceptConnectPort test on 64 bit
- Fix NtAllocateVirtualMemory test on Vista+
- Fix NtMapViewOfSection test on 64 bit
- Fix NtSetDefaultLocale test on Vista+
- Fix RtlBitmapApi test on Vista
- Fix RtlCaptureContext test
JIRA issue: CORE-19020
- Add IDropTarget interface to
CZipFolder.
- Modify CZipFolder::CreateViewObject
and CZipFolder::GetUIObjectOf.
- Add CZipFolder.cpp and make
CZipFolder some methods out-of-line.
- Extend CZipCreator for append.
- Implement IPersistFile of CZipFolder.
- Add DropHandler to CZipFolder.
Unzip library has EF_UNIPATH field for UTF-8 path. Correctly
supporting EF_UNIPATH will fix the encoding problem.
JIRA issue: CORE-20443
JIRA issue: CORE-20444
- Check existence of EF_UNIPATH extra info for each path.
If it exists, then use it.
- Use StrCmpIW for sorting.
- Make CZipEnumerator functions out-of-line.
Support paste operation on Fonts folder.
JIRA issue: CORE-12861
- Add CFontBackgroundMenu.cpp and CFontBackgroundMenu.h
to support background menu.
- Modify CFontExt::CreateViewObject and
CFontExt::GetUIObjectOf methods.
- Re-implement foreground menu by using
CDefFolderMenu_Create2 and CFontExt::MenuCallBack.
- Delete needless CFontMenu.cpp.
- Add IDS_PROPERTIES resource string.
This commit reworks how the uefidisk code works so it's not longer... completely wrong.
This also allows GPT disks to now be used on uefildr.
It's not perfect (as the correct solution is having freeldr load full efi device paths instead of arc like bootmgr does)
but this will work perfectly fine now. Well should.
Add more improvements and fixes to volume control implementation.
- Don't allocate and don't use an array for storing volume level values. Also, get rid from some stuff, which is not used any more (some fields of MIXERVOLUME_DATA structure and MMixerGetVOlumeControlIndex() function).
- Use the following formulas to properly convert the volume level values from the logical units range (0 - 65535) to the hardware Decibel (DB) range (defined by audio miniport driver): <decibels> = <units> * <range_in_db> / <range_in_units> + <minimal_level> (for setting the new value) and <units> = (<decibels> - <mimimal_level> + 1) * <range_in_db> / <range_in_units> (for getting the previous value), where <decibels> is a DB hardware value, <units> is logical units value, <rang_in_db> is the hardware range (DB), <range_in_units> is range in the logical units and <minimal_level> is the most minimum volume level value defined by an audio miniport driver.
- I've created this formula myself basing on my calculations and investigations (with some help from Hermes Belusca-Maito), so it's tested and confirmed to be working for all possible values range (at least for our official Intel AC97 driver, and, as tested later, Realtek HD audio).
- Do this in both cases when setting the new and when getting the previous volume value as well.
- Fallback to default values range -96 - 0 DB in case either the volume level property is not supported by audio miniport driver, or the values range is empty (SignedMinimum is equal to SignedMaximum and both of them typically have a 0 (zero) value). Realtek HD audio codec is one of such a drivers, so this fixes the volume control on real hardware too (tested on Asus-F5R notebook with Realtek ALC660 audio controller). Moreover, the volume values set by user are even properly saved (aren't lost) after reboot (unlike with Intel AC97 in VirtualBox or SoundBlaster in VMware)! Realtek probably uses another mechanism to write/read the value(s) to/from Registry, which is handled by the miniport (codec) driver instead.
This fixes some remaining bugs when changing the volume level, so now 1) min/max position of the volume bar can be reached correctly and 2) left/right balance sliders are now behaving properly (they don't affect position of each other anymore when moving them manually).
CORE-19189, CORE-19190
This is actually a hack and isn't required anymore because I made a proper fix instead.
Doing -1 does not fix the problem correctly, but only makes a pseudo-effect that it's fixed by actually truncating each volume value, so then the volume sliders misbehaving does occur less (but it still does).
This reverts commit 206b52833f.
CORE-19190
Fix minor regression after commits f81c1910ee and e56911f66b (PR #7488).
The `PeLdrImportDllLoadCallback` variable was exported as a function,
instead of as data, which was incorrect since it is a data pointer,
that is set by winldr code (in rosload.exe) to tell the PE loader
(residing in freeldr.sys) to perform an action when an imported DLL
is being loaded.
Timo Kreuzer