Previously the debug macros printed file/line, class and message separately, which resulted in possible intermingling with other debug messages, e.g. from rosautotest. This caused random parse errors for testman.
This is fixed by using a temp buffer for the prefix in rosfmt_default_dbg_vlog and then calling vDbgPrintExWithPrefix. Also make the __WINE_DPRINTF macro identical between GCC and MSVC.
See ROSTESTS-178
CORE-20539
Move an "assert" added by Pierre Schweitzer in [b0b7df](https://github.com/reactos/reactos/commit/b0bf7df).
Relocate his added "assert" inside an "if (FsCheckFlags & FSCHECK_IMMEDIATE_WRITE)".
This avoids some asserts when running in read-only mode.
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
CORE-20539
Before calling "fs_write" test if we are in a read-write mode by checking "rw".
I intend to re-evaluate this to try and reduce the difference to dosfschk in the future.
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
The point of kernel32_vista was to provide a dll that can be used for winesyncs to still have NT6 APIs.
We're now switching to an architecture where we'll have kernelbase OR a kernel32_win7 depending on NT target compile
but this means that for an ANSI exe such as this, we need an alternative solution.
Thankfully it's pretty much only for this but just in case i made it a library.
conutils\pager.c(658):
warning C4267: '=': conversion from 'size_t' to 'DWORD', possible loss of data
conutils\outstream.c(179),(263):
warning C4267: '=': conversion from 'size_t' to 'DWORD', possible loss of data
conutils\outstream.c(433):
warning C4267: '=': conversion from 'size_t' to 'INT', possible loss of data
The structure is packed in the original dosfstools code, too.
Fixes GCC 13 warning:
C:/ReactOS/reactos/sdk/lib/fslib/vfatlib/check/lfn.c: In function 'lfn_add_slot':
C:/ReactOS/reactos/sdk/lib/fslib/vfatlib/check/lfn.c:208:5: warning: converting a packed 'DIR_ENT' pointer (alignment 1) to a 'LFN_ENT' pointer (alignment 2) may result in an unaligned pointer value [-Waddress-of-packed-member]
208 | LFN_ENT *lfn = (LFN_ENT *) de;
| ^~~~~~~
In file included from C:/ReactOS/reactos/sdk/lib/fslib/vfatlib/check/dosfsck.h:8,
from C:/ReactOS/reactos/sdk/lib/fslib/vfatlib/vfatlib.h:25,
from C:/ReactOS/reactos/sdk/lib/fslib/vfatlib/check/lfn.c:24:
C:/ReactOS/reactos/sdk/lib/fslib/vfatlib/check/fsck.fat.h:165:9: note: defined here
165 | typedef struct {
| ^~~~~~
C:/ReactOS/reactos/sdk/lib/fslib/vfatlib/check/lfn.c:29:9: note: defined here
29 | typedef struct {
| ^~~~~~
pseh2_64 relied on inline-asm clobbers across a C/asm funclet jump, which is not a reliable ABI boundary.
On AMD64 gcc path, this can corrupt non-volatile state during exception filtering/unwind.
This change makes the trampoline ABI-safe by explicitly preserving and restoring non-volatile registers and keeping unwind metadata/prologue consistent.
Changes:
- Save/restore rbx, rdi, rsi, r12-r15 in `__seh2_global_filter_func`.
- Adjust stack allocation/unwind annotation to match the new prologue/epilogue.
- Keep filter return in eax and jump back through `__seh2_global_filter_func_exit`.
Note: This is exception-only path: extra stack usage is acceptable for correctness.
How to test: Build and run ReactOS with gcc 13/15; you should no longer see stack exhaustion.
CORE-17977
- Fix a bug when subsequent port detection attempts fail because of
broken FIFO management. If FIFO logic is enabled the hardware will
not decode the legacy 0x30 and 0x32 I/O ports.
Therefore care should be taken when accessing these ports.
- Fix hang on boot when a serial device was not connected to the COM1 port.
Unlike 16550, a call to `CpDoesPortExist()` for the 8251 will succeed
even when if the user has not plug the serial port into PC-98 machine.
(I do not know how to put the 8251 into loopback mode.)
Fix this by checking for CTS prior to the LSR loop.
- Fix hang on boot when the chosen baud rate becomes too large due to
`DEFAULT_DEBUG_BAUD_RATE` being set to 115200.
- Some NP21/W workarounds were being incorrectly applied,
fix them and consolidate them into one check.
- Reuse exsisting code from the NS16550 driver to avoid code duplication.
- Rename HW definitions for better naming.
Co-authored-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
[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
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.
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
Resource names are sorted with '_' being higher than any alphabetic characters. This means _wcsicmp cannot be used to search, because it lowercases the characters before comparison, which would make '_' lower than lowercase alphabetic characters. Implement a custom compare function instead.
See CORE-20401, CORE-20408
