In file included from ../sdk/lib/3rdparty/libwine/debug_ros.c:9:
../sdk/lib/3rdparty/libwine/debug.c: In function 'get_temp_buffer':
../sdk/lib/3rdparty/libwine/debug.c:343:33: warning: passing argument 1 of '_InterlockedExchangeAdd' from incompatible pointer type [-Wincompatible-pointer-types]
idx = interlocked_xchg_add( &pos, 1 ) % (sizeof(list)/sizeof(list[0]));
^~~~
In file included from ../sdk/include/crt/mingw32/intrin.h:98,
from ../sdk/include/crt/intrin.h:1017,
from sdk/include/psdk/winnt.h:48,
from ../sdk/include/psdk/windef.h:202,
from ../sdk/include/reactos/wine/debug.h:26,
from ../sdk/lib/3rdparty/libwine/debug.c:32,
from ../sdk/lib/3rdparty/libwine/debug_ros.c:9:
../sdk/include/crt/mingw32/intrin_x86.h:215:70: note: expected 'volatile long int *' but argument is of type 'int *'
__INTRIN_INLINE long __cdecl _InterlockedExchangeAdd(volatile long * Addend, long Value)
~~~~~~~~~~~~~~~~^~~~~~
HvpCreateHiveFreeCellList returns a NTSTATUS code yet the way the code path checks
checks for failure is just wrong. This was spotted whilst working on #4571 PR.
Whenever ReactOS finishes its operations onto the registry and unlocks it, a lazy flush is invoked to do an eventual flushing of the registry to the backing storage of the system. Except that... lazy flushing never comes into place.
This is because whenever CmpLazyFlush is called that sets up a timer which needs to expire in order to trigger the lazy flusher engine worker. However, registry locking/unlocking is a frequent occurrence, mainly when on desktop. Therefore as a matter of fact, CmpLazyFlush keeps removing and inserting the timer and the lazy flusher will never kick in that way.
Ironically the lazy flusher actually does the flushing when on USETUP installation phase because during text-mode setup installation in ReactOS the frequency of registry operations is actually less so the timer has the opportunity to expire and fire up the flusher.
In addition to that, we must queue a lazy flush when marking cells as dirty because such dirty data has to be flushed down to the media storage of the system. Of course, the real place where lazy flushing operation is done should be in a subset helper like HvMarkDirty that marks parts of a hive as dirty but since we do not have that, we'll be lazy flushing the registry during cells dirty marking instead for now.
CORE-18303
Loosely based on the deprecated ReactOS-specific SmExecuteProgram().
On server-side, we lookup into the list of deferred subsystems that
has been initialized at init time.
Dedicated to Justin Miller (The_DarkFire) work on reviving the
POSIX subsystem!
This DLL was exporting legacy NT-incompatible or ROS-specific SM client
functions, that have been since 10 years now (2012) replaced by the new
NT-compatible SM:
- SmConnectApiPort(): was just SmConnectToSm().
- SmCompleteSession():
The legacy SMSS used it for when a subsystem initialization was finished.
Now (NT-compatible) this function is called by subsystems **only** when a
subsystem session **terminates**: SmSessionComplete().
- SmExecuteProgram(): was just the client side of SmLoadDeferedSubSystem()
(whose server side is not implemented yet). The legacy SM "old" SmExecPgm
implementation actually was "SmLoadDeferedSubSystem"...
- SmLookupSubsystem(): is a utility-only function to read any registry value
inside "Session Manager\SubSystems".
Move SMDLL's readme into SMLIB and update its contents.
Collect some residual useful functions into smutils.c (and moved in SMLIB,
though not compiled yet):
- SmExecuteProgram(), now implemented as a wrapper around SmExecPgm();
- SmLookupSubsystem(), described above;
- SmQueryInformation(), that retrieves a list of currently-running subsystems.
[SMLIB] Validate SbApiPortName's length in SmConnectToSm().
Fix CommandLine length validation in SmStartCsr().
Add documentation (+ SAL annotations) to the NT-compatible SMSS client functions.
smmsg.h: Add both Win32 and Win64 struct sizes C_ASSERTs for those whose size
change between these two processor architecture sizes.
[SMLIB] Introduce SmSendMsgToSm() as helper to send data into the SM LPC port.
+ Make the other API functions use it.
It should be observed that in Vista+, both functions SmConnectToSm() and this
new SmSendMsgToSm() are exported by NTDLL under the names RtlConnectToSm()
and RtlSendMsgToSm() (and use the same signature).
See: https://www.geoffchappell.com/studies/windows/win32/ntdll/history/names60.htm
[NTDLL] Correctly stub RtlConnectToSm() and RtlSendMsgToSm().
[NTDLL_VISTA] Link to SMLIB and simply export RtlConnectToSm() and RtlSendMsgToSm().
Clicking "Edit compatibility modes" button in the "Compatibility" tab
opens a window centered on the parent window. If we move the parent
window to one of the screen edges and then click this button again,
the new window will appear off screen.
Adjust position of created window, so now it would be completely visible.
CORE-17089
Reviewed-by: Mark Jansen <mark.jansen@reactos.org>
Reviewed-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
This header is included by ntoskrnl which effectively disabled all PAGED_CODE checks since 2015. Thanks Alex.
Instead define _BLDR_ when building cmlib, which will avoid trying to import KeGetCurrentIrql()
- Add some missing ARM64 exports to ntdll, kernel32 and user32
- Create mmtypes header file based on WoA debug symbols
- Get the remaining headers in order, so we can build ARM64 apps
- Adjust subsystem version for binaries so they can run on WoA host
- Get calc, notepad and more base apps to build for ARM64 platform
CORE-17518
Reviewed-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
v1.7.8.1 (2021-06-13):
- Fixed bug preventing new directories from appearing in listings
- Fixed Release version of driver still not working on XP
v1.7.8 (2021-06-09):
- ~~Upgraded zstd to version 1.5.0~~ Not in ReactOS as it introduces deprecated code
- Fixed regression stopping driver from working under XP
- Fixed compilation on clang
- Fixed corruption issue when Linux mount option inode_cache had been used
- Fixed recursion issue involving virtual directory \$Root
v1.7.6 (2021-01-14):
- Fixed race condition when booting with Quibble
- No longer need to restart Windows after initial installation
- Forced maximum file name to 255 UTF-8 characters, to match Linux driver
- Fixed issue where directories could be created with trailing backslash
- Fixed potential deadlock when Windows calls NtCreateSection during flush
- Miscellaneous bug fixes
v1.7.4 (2020-08-23):
- Fixed issue when running compressed EXEs
- Changed build system to cmake
- Upgraded zstd to version 1.4.5
- Added support for FSCTL_GET_RETRIEVAL_POINTERS
- Miscellaneous bug fixes
Correct fix was to fix the HCELL_INDEX <-> HKEY conversions, much like
is being done with UlongToHandle / HandleToUlong.
The on-disk/in-memory hive file structures are platform-independent:
their layout must not depend on whether code is compiled in 32 or 64
bits.
... as it should have always been done (and must be done for NTDLL
and NTOS kernel as well). This allows using the RTL with the correct
definitions and the reduced functionality available at boot-time.
+ Make the RTL main header compatible.
In addition, this will permit re-using existing code that already
uses the RTL (mostly string conversions).
See commits 427c90af3 (r36761) and b46e8cc18 (r36980) for some
background.
Instead of adding the rtl_vista library to the target, manually add
the related source files to compilation. That's not the best, but
this should definitively fix the linking problem.
The reason is that both RtlUTF8ToUnicodeN() and RtlUnicodeToUTF8N() are
exported in both kernel and user-mode (ntdll) in Windows 7+.
Conversion from and to UTF8 are fundamental enough that they indeed
deserve to be in a separate file.
In principle there should be different get-cell routines, depending
on the type of the hive (given by the OperationType parameter of
HvInitialize): for flat hives, memory-mapped hives, etc.
For now in ReactOS we only support a restricted subset of these,
therefore we are still happy with a single get-cell callback...
This may change in the future.
* [FORMATTING][CRT] stdio/file.c: Reduce diff with Wine.
* [CRT] _wfreopen(): Fix TRACE() format modifier
Import wine-1.4-rc3 f8b29a0 by Eric Pouech.
* [CRT] msvcrt_init_io(): Ignore inherited FDs with invalid handles
Import wine-6.2-32-g611742d by Paul Gofman,
except test part, which shall be WineSync separately.
* [CRT] _dup2(): Fix clearing NOINHERIT flag
Import wine-6.20-44-g1420d28 by Piotr Caban.
- Add some of the missing CMake adjustments to continue the configure and compile process with ARM64 MSVC
- Created quick stubs for the functions in SDK needed to finish the configuration process
- Put in an ARM64 option for spec2def
CORE-17518 CORE-17615
Remove mingw-w64 version of _fmode. _fmode should not be linked directly into the executable. Instead, the export from msvcrt should be used. On Windows 10 it's defined to *__p__fmode(), which is exported from ucrtbase.dll
Also _fmode in msvcrt.dll is initialized with 0.
* Fix initialization of _commode. In msvcrt it is allocated from .bss, i.e. initialized with 0.
* _fileinfo is initialized with -1
* _aexit_rtn is a pointer, not a function
* Fix _sys_nerr
This "initialization" copies the value of the local variable to the one exported from msvcrt, which is the same. Also there shouldn't be a local version of the variable in the first place.
- Make __fto64 function more readable
- Call worker function directly for __rt_sdiv/udiv
- Adapt __rt_sdiv64/udiv64 asm shims accordingly
- Add header files to CMake source list
CORE-17607 CORE-17614 CORE-17703 CORE-17604
Addendum to f2bc1f0e, e448094e and 54406bf4.
The upstream driver is not maintained and the file system itself
is in a semi-abandoned state.
Originally imported at 3a3ef631d1
The driver is written by Lee Jae-Hong, updated by Bo Brantén.
ReactOS porting made by Peter Hater and Pierre Schweitzer.
Follow updates at http://www.acc.umu.se/~bosse/
FS Recognizer code is left to keep the FS support as an
installable driver.
CORE-11040
The upstream driver is not maintained and the file system itself
is in a semi-abandoned state.
Originally imported at e308102f4a
The driver is written by Mark W Piper, updated by Bo Brantén.
ReactOS porting made by Peter Hater and Pierre Schweitzer.
Follow updates at http://www.acc.umu.se/~bosse/
FS Recognizer code is left to keep the FS support as an
installable driver.
CORE-11005
We previously used 2 different versions: one from wine and one from mingw-w64.
The former was used in msvcrt, the latter was statically compiled into the executable. When using MS libs, there is only one _matherr, which is statically linked into the executable and does nothing (it's not really a function for users to be called).
_setusermatherror should only exist in msvcrt and not statically, which wouldn't work at all.
KD64: Raise to HIGH_LEVEL when entering trap
KDBG: lower to DISPATCH_LEVEL when applying IRQL hack & use a worker thread to load symbols
KD&KDBG: Actually unload symbols when required
- Implement caching of individual (newline-separated) text lines; this
behaviour can be enabled with a flag (enabled by MORE):
CON_PAGER_CACHE_INCOMPLETE_LINE.
This feature is necessary when reading a text file, whose text lines
may span across two or more successive temporary read buffers, and is
required for correctly determining whether the lines being read are
blank and may be squeezed.
- When squeezing blank lines, the blank-line check must be done for each
line segment corresponding to the screen line (and following) that
need to be displayed. This matches the behaviour of MS MORE.COM.
- Fix the IsBlankLine() check to not consider FORM-FEEDs as being blank
characters: This is necessary for correctly handling FORM-FEED
expansion. Also note that MS MORE.COM only checks for spaces and TABs,
so we are slightly overdoing these checks (considering other types of
whitespace).
- Get rid of ConCallPagerLine() and the intermediate CON_PAGER_DONT_OUTPUT
state flag that were used repeatedly for each and every small line
chunks. Instead, call directly the user-specified 'PagerLine' callback
when we are about to start treating the next line segment to be
displayed (see comment above).
- Fix the exit return condition of ConPagerWorker(): it should return
TRUE whenever we displayed all the required lines, and FALSE otherwise.
Otherwise, the previous (buggy) condition on the data being read from
the text file, may lead to the prompt not showing when a screenful of
text has been displayed, if it happened that the current text buffer
becomes empty at the same time (even if, overall, the text file hasn't
been fully displayed).
- In MorePagerLine(), when we encounter for the first time a blank line
that will be squeezed with other successive ones, display a single
blank line. But for that, just display one space and a newline: this
single space is especially needed in order to force line wrapping when
the ENABLE_VIRTUAL_TERMINAL_PROCESSING or DISABLE_NEWLINE_AUTO_RETURN
console modes are enabled. Otherwise the cursor remains at the
previous line (without wrapping), and just outputting one newline will
not make it move past 2 lines as one would naively expect.
- The column extent should cover the whole width of the console screenbuffer.
On the contrary, the line extent covers only the number of lines that
cover the current displayed console window.
- Since the console can be resized while the pager is prompting, we need
to actually recalculate in the prompt routine the default number of
lines for a screen.
- Reset s_nNextLineNo when paging a new file.
- Shorten the names of the flags: CON_PAGER_FLAG_*** --> CON_PAGER_***.
- Reorder few members in the CON_PAGER pager structure where they make sense.
- ScreenColumns, ScreenRows --> PageColumns, PageRows: keeping the open
possibility for having a pager controlling a region of different size
than the screen.
- Add doxygen documentation for ConWritePaging().
GCC has some functions, variables & type attributes which can be used as aliases
for some of the SAL annotations. Although it's not as rich & precise, it's still useful
since we actually enable -Werror on GCC builds whereas we don't use such an option
on MSVC builds.
For now, _Must_inspect_result_ is aliased to warn_result_unused attribute.
Spinlocks are not reentrant (and this is done a lot), using them forces us to have
an horrible hack in the kernel, which unschedules threads which are at DISPATCH_LEVEL
thus allowing another thread to take ownership of the spinlock while the unscheduled
thread should already hold it.
CORE-6473
NEVER DO THIS! It is guaranteed to be wrong. Instead always individually pack single structures that need packing.
This fixes USB mouse on 64 bit builds.
RtlpCaptureNonVolatileContextPointers walks the stack and captures the addresses of all non-volatile registers on the stack, when they have been saved first. This is needed to be able to fix up the non-volatile on a system call, which doesn't capture non-volatiles, but relies on them to be restored by the callees.
Instead of only checking for the TargetFrame, also check for a mode change, i.e. RIP went from kernel to user, in which case the target frame was not reached yet, because it was too large, but processing can't continue here.
RtlSetUnwindContext uses RtlpCaptureNonVolatileContextPointers to set the non-volatile registers in the the stack. They will be picked up, when returning back or unwinding, e.g. to the system call handler.
CORE-17601
Dynamically load SetThreadUILanguage(), so as to support systems where this API is not present.
Hopefully implemented in a thread-safe manner.
Also, put include directory next to the library and use
target_include_directories(.. INTERFACE ..) to get this right.
This is because :
- Having includes & implementation in two different places buggers me
- This makes sure that there is no "if it compiles everything is fine" behaviour from anyone
because now even static libraries need it for GCC amd64 build
Also add __USE_PSEH2__ define for the non SEH-aware compilers out there and use it in a few headers
where we define macros involving __try
The array is there for the entries smaller than the decommit threshold, the rationale
being that entries which are larger will likely be split for honoring other allocations
or be coalesced and eventually decommitted.
This with the previous commits make a huge perf boost to memory-intensive applications like cmake
CORE-15793
We are not ready for enabling ATLASSERT. Enabling ATL assertions takes time to realize. CORE-17505
- Disable ATLASSERT by undefining _DEBUG.
- Revert currently non-fixable codes.
- Fix generic text mapping for GetWindowText and GetWindowTextLength functions.
- Fix the position.
- Fix the length.
- Fail elegantly if necessary.
CORE-9281
Addendum to 0.4.15-dev-1453-g 4ad7b6d
Looks like CMake on master does not longer understand the syntax of
replace_compile_flags().
Will investigate that later again, when other issues have been
solved that do currently prevent me from testing that locally at all.
Most likely remove_target_compile_option() has to be used instead now.
[AUTOCHK] Add also support for scanning FATX volumes.
The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the
U*.DLL user-mode FS library dlls are different (and have different
prototypes) than the similarly-named functions exported by FMIFS.DLL .
In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()"
in our U*.DLL libraries actually correspond more, from their arguments,
to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their
*Ex() counterparts instead take most of the parameters through a
structure passed by pointer.
On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and
FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these
*Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx()
call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls
U*.DLL!FormatEx() (that we do not implement yet either) !!
To improve that, refactor the calls to these U*.DLL functions so as to
respect the more compatible prototypes: They contain the correct number
of parameters in a compatible order. However, some of the parameters do
not have the same types yet: the strings are kept here in PUNICODE_STRINGS,
while on Windows they are passed via an undocumented DSTRING struct, and
the FMIFS callback is instead a MESSAGE struct/class on Windows.
Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet
not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used
in the corresponding FMIFS.DLL functions.
One thing to notice is that the U*.DLL!Format() (and the Ex) functions
support a BOOLEAN (a flag resp.) for telling that a backwards-compatible
FS version should be used instead of the (default) latest FS version.
This is used e.g. by the FAT FS, where by default FAT32 is selected
(depending also on other constraints like, the disk and the partition
sizes), unless that bit is set in which case, FAT16 (or 12) is used.
- Reduce the diff with upstream by aliasing malloc() and free()
with RtlAllocateHeap() and RtlFreeHeap() respectively.
- Fix a memory leak in the failure code path of the do-while
memory reallocation loop for IOCTL_BTRFS_QUERY_FILESYSTEMS
in is_mounted_multi_device().
Not all files are included, but these are necessary to compile cdrom driver.
So far it can only be statically linked with drivers, a proper
implementation requires wdfldr helper driver
This removes the broken wine version of atexit and onexit. It keeps only dllonexit, which is implemented properly. The previous __call_atexit is moved to where the mingw onexit/atexit code is and adjusts it to work with the existing code. A call to __call_atexit is added in __tmainCRTStartup after the main function was called.
Instead of messing with global variables and the like, we introduce two target properties:
- WITH_CXX_EXCEPTIONS: if you want to use C++ exceptions
- WITH_CXX_RTTI: if you need RTTI in your module
You can use the newly introduced set_target_cpp_properties function, with WITH_EXCEPTIONS and WITH_RTTI arguments
We also introduce two libraries :
- cpprt: for C++ runtime routines
- cppstl: for the C++ standard template library
NB: On GCC, this requires to create imported libraries with the related built-in libraries:libsupc++, limingwex, libstdc++
Finally, we manage the relevant flags with the ad-hoc generator expressions
So, if you don't need exceptions, nor RTTI, nor use any runtime at all: you simply have nothing else to do than add your C++ file to your module
for vista+ APIs implemented in ntoskrnl_vista.
Now if you statically link ntoskrnl_vista into a driver,
NTKERNELAPI will automatically be removed from an API definition
