Improve usability of Fonts folder.
JIRA issue: CORE-17311
- Modify PIDL design to contain
name and filename.
- Implement CFontExt::
ParseDisplayName to parsing
name as PIDL.
- Modify CDefaultContextMenu::
GetCommandString and
CDefaultContextMenu::
DoCopyOrCut for DFM_GETVERBA,
DFM_GETVERBW, DFM_CMD_COPY,
and DFM_CMD_MOVE.
- Add IDS_CONFIRM_DELETE_FONT,
IDS_CANTDELETEFONT, and
IDS_PROPERTIES resource strings.
- Add SHMultiFileProperties
prototype to <shlobj.h>.
Follow-up of #8632. Improve usability of ZIP Folder.
JIRA issue: CORE-20464
- Add IDS_CONFIRMDELETE_TEXT and
IDS_CANTDELETEFILE resource strings.
- When deleting files in Zip Folder, create a
temporary file.
- CZipFolder::CopyZipEntry adds files to the
temporary file without adding files to delete.
- Replacing the target ZIP file with the temporary
file implements deleting files in Zip Folder.
- Add SFGAO_CANDELETE attribute.
- Add DFM_CMD_DELETE action.
- Modify CDefaultContextMenu in shell32 to invoke DFM_CMD_DELETE etc.
- Modify CNewMenu::LoadItem in shell32.
* [OPENGL32] Use NDK definitions for list functions
* [OPENGL32] wglCreateLayerContext: Insert an entry into context list
Fixes a crash when wglDeleteContext is called on layer context.
Follow-up of #8641. Reduce freetype.c lines.
JIRA issue: CORE-19898
- Follow @HBelusca's review in #8641.
- Move some codes in freetype.c into utils.c.
Ensure we dereference the same parent window object after a user-mode callback. We cache spwndParent in a local before sending messages so a parent change during the callback no longer trips the LIFO reference check.
- Capture the parent window in a local in IntDefWindowProc (WM_APPCOMMAND) and IntSendParentNotify.
- Use the local for UserRefObjectCo, co_IntSendMessage, and UserDerefObjectCo to prevent object mismatches when the parent changes mid-callback.
CORE-17331
[FREETYPE] HACK: Verify the cmap format 4 is used in the function
"tt_cmap4_char_map_binary" in ttcmap.c before proceeding.
Otherwise issue debug message.
CORE-12549
Text rendering speed is justice! Font
search is heavy operation. Adding
cache to it is rational.
JIRA issue: CORE-19898
- Define FONT_LOOKUP_CACHE
structure.
- Add s_FontLookupCacheList
global variable to save cache.
- Use cache in FontLink_PrepareFontInfo
and TextIntRealizeFont.
Prepare to support CTF IMEs.
The IS_IME_HKL macro cannot
detect CTF IME.
JIRA issue: CORE-1926
- Use ImmIsIME instead of
IS_IME_HKL to check whether
the keyboard is IME.
- 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 <hermes.belusca-maito@reactos.org>
Co-authored-by: Timo Kreuzer <timo.kreuzer@reactos.org>
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 <di.sean@protonmail.com>
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
- 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
