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
This lead to a crash of winmm:mixer
during "GCCLin_x86 on Test VBox".
The crash was exposed when new code paths
were activated by 0.4.15-dev-791-g
6d7ebc2048
I do intend to port this commit back into 0.4.14RC.
