Clang-CL does not support #pragma function like CL. The alternative to this approach is to disable all intrinsics for this single source file, but that is not trivial to do, as it can only be done by removing a compiler switch, which we have no CMake support for. Therefore this solution is simpler and as good.
Running out of pool is likely at least during kmtest:ExPools.
There is a chance of crashing when dereferencing these null pointers -- but
worse, there's also a chance of overwriting the IVT or BDA if a VDM BIOS
call is in progress, which can lead to crashes in non-obvious places later.
* [WIN32K] Fix handle calculation in DbgGdiHTIntegrityCheck
* [NOTEPAD] Fix MSVC warnings
* [PSDK] Simplify *PROC definitions in windef.h
* [VIDEOPRT] Don't try to use NtVdmControl on x64
* [FREELDR] Fix some macros
* [CRT] Make qsort 64 bit compatible
* [NTOS] Use #ifndef _WIN64 instead of #ifdef _M_IX86 around C_ASSERTs
* [FAST486] Fix 64 bit warnings and change DWORD to ULONG, so it can be used in kernel mode
* [APPHELP_APITEST] Fix 64 bit issue
CORE-12671
- The default format is used when no format name is specified: this is
the one we use so far in ReactOS:
<debug_class>:(<file>:<line>) <message>
with "debug_class" being "trace", "warn", "err".
- The "wine" format is the one used by Wine. It can be used when trying
to diff-compare traces for a module with the corresponding one
obtained from a Wine run. It can also be useful because the logging of
Wine-synced code assumes that the function names are automatically
added by the helper macros "FIXME()", "TRACE()", "WARN()" or "ERR()",
and not manually inside the logging string given to these macros:
for example:
FIXME("(%params) message\n", params);
displays:
fixme:<module>:SomeFunc(params) message
- The "extended" (or "ext") format is very noisy and tries to output a
lot of information; it is a hybrid of the previous two formats:
<debug_class>:(<file>:<line>):<channel>:SomeFunc <message>
Support for displaying the current process ID is added in
addition to the already existing support for thread ID.
And, don't emit \r\n when an \r alone is encountered.
This fixes the problem of extra newlines appearing when redirecting
"more" output to a file.
CORE-14592
GAS uses ".double" symbol for declaring floating-point constants and
".quad" symbol for declaring 64-bit numbers.
This is not compatible with our macro for MASM and introduces bugs.
Now 64-bit constants are supposed to be declared using ".quad" macro.
This is required, since newer versions of MSVC demand that non-member operator new/delete are in the global namespace and neither static nor inline. See https://msdn.microsoft.com/en-us/library/mt723604.aspx ("Overloaded operator new and operator delete")
Otherwise fall back to the computed argv[0].
This is expected by some applications, for example Git.
Code is adapted from Wine.
Many thanks to Stanislav Motylkov for having investigated this bug!
CORE-12931 CORE-13892 CORE-13898 CORE-14066
Our implementation had a bug that could be triggered while
building our USBD library on ReactOS: the compare function
could be called with a NULL pointer instead of a valid value.
With this bug fixed (and the cmd hack in CORE-14648), ReactOS
can totally selfhost :-)! I was able to build LiveCD and BootCD
without any trouble, crash, deadlock or whatever.
(Next step: having a buildbot slave hosted on ReactOS ;-)).
Enjoy: https://twitter.com/HeisSpiter/status/1002880397103988737
CORE-14680
In working on some problems with Time Zone adjustments in ReactOS I found that the RtlQueryTimeZoneInformation function is partially broken and wrote an apitest to capture the failures.
Patch by Doug Lyons.
CORE-14658
Instead of loading systemcompatible.manifest as the implicit activation context, load forwardcompatible.manifest
Add a new assembly containing all apisets called ReactOS.Apisets and make it a dependency to forwardcompatible.manifest
Import the following Wine commits:
* ea2798f1ce9 Iván Matellanes: msvcrt: _setmode should check if file descriptor is valid.
* 9b495caacfd Carlo Bramini: msvcrt: Call SetFilePointer() with correct parameters.
* 13f34481b26 Carlo Bramini: msvcrt: Use MSVCRT_xxx macros instead of the same ones from GLIBC.
* 781b069ed81 Piotr Caban: msvcrt: Don't close HANDLE if stdout or stderr is sharing it.
Import Wine commits by Piotr Caban:
* 6ed69c107f8 msvcrt: Avoid using global critical section while allocating new file descriptors.
* 725e4733cf8 msvcrt: Remove no longer needed global lock from functions using fd critical sections.
Import Wine commits by Piotr Caban:
* 417b6056877 msvcrt: Fix possible deadlock in dup2 function.
* e7fc2370885 msvcrt: Don't use fdend in create_io_inherit_block.
Import Wine commits by Piotr Caban:
* c7b0fb51543 msvcrt: Use fd critical section in _dup2.
* b052afd4afa msvcrt: Use fd critical section in msvcrt_free_fd.
* 16285f5700f msvcrt: Use fd critical section in read.
* 9ce2a8a60c1 msvcrt: Use fd critical section in create_io_inherit_block.
* f00b7f40584 msvcrt: Use fd critical section in _setmode.
* ba757eaec74 msvcrt: Use fd critical section in _write.
* eec7a565bec msvcrt: Don't lock __badioinfo.
Import Wine commits by Piotr Caban:
* 6c2d4f1092d msvcrt: Use fd critical section in _fstat64.
* 9278190d468 msvcrt: Use fd critical section in _futime64.
Import Wine commits by Piotr Caban:
* 4508e665c07 msvcrt: Use fd critical section in _commit.
* afc6962a24a msvcrt: Use fd critical section in _close.
* 9a4cfbc3edc msvcrt: Use fd critical section in _eof.
* ffdd16cc0d7 msvcrt: Use fd critical section in _locking.
* fa6de597700 msvcrt: Use fd critical section in _lseeki64.
* f2f45d5fe67 msvcrt: Use fd critical section in _chsize_s.
- Make sure the DWLP_* values are correct on _WIN64
- Don't use the DWL_* constants, they are not portable. Enforce this by removing them entirely from winuser.h
- Make sure Get/SetWindowLong*Ptr* is used and pointers are not truncated to LONG
(So the fun begins)
In spite of what VFATLIB headers pretend, there's not magic in FAT boot sector.
The 3 first bytes are just the jump instruction (to the boot code). No jump, no boot.
Also, some (many?) FAT implementations rely on the jump code to help detecting that
a FAT volume is really a FAT volume. Like MS FastFAT. Or our own FAT recognizer in FS_REC.
The story is that, up to that commit, we zeroed the 3 first bytes; leading to broken
FAT volumes.
This got hidden in most cases by the fact that during setup, when we install boot
loader, we erase parts of the boot sector, including the jump instruction, making the
volume valid again. But that wouldn't fix secondary volumes where the boot loader isn't
installed.
And, also, imagine a scenario where you want to install ReactOS on a newly formatted volume
with MS FastFAT instead of our own implementation... That would simply not work to
the fact that the driver wouldn't recognize the fresh formatted volume!
(So the non fashion begins)
Fix this by putting a not that valid jump into the boot sector when formatting our
partitions. That way, our volume is always regarding a FAT view point. But, instead of
putting values that mean (nearly) nothing. We should also put a dummy bootloader
displaying the user and error message, as done by dosfstools.
(So the hope begins)
This opens the way for trying to install ReactOS with MS FastFAT (doesn't work yet).
CORE-11819
CORE-14362
