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.
This is a partial sync of the CRT library with wcsrtombs_l and _mbstowcs_l functions from WINE. The _wctomb_s_l implementation of WINE which is used by _wctomb_s, _wctomb_l and wctomb brings failed results of the wctomb unit testcase and at the same time it crashes the whole testcase after.
Therefore I will not address the wctomb function for the moment being.
The current _mbtowc_l code directly passes the string count size argument to cbMultiByte argument parameter to MultiByteToWideChar(). As the size of lpMultiByteStr expressed in bytes by cbMultiByte is dependent of the actual given string, the size of lpWideCharStr expressed in characters by cchWideChar is always 1.
The resulting parameters to MultiByteToWideChar() will lead to a failure as lpWideCharStr cannot accommodate the converted string if the size pointed by lpMultiByteStr is larger than the buffer wide string to receive the converted output, a Win32 error code of ERROR_INSUFFICIENT_BUFFER in other words. The fact that _mbtowc_l never fails without WINE Gecko package installed is because the codepage pointed by lc_codepage is CP_ACP and the converted output is directly given to the destination wide string parameter thus never calling MultiByteToWideChar(). Installing WINE Gecko merely unhides this problem.
As _mbtowc_l is imported from WINE and that they have updated their code (which at the same time this fixes the aforementioned problem), the following commit syncs the updated code from WINE.
CORE-16885
Incoming r4 contains the number of dwords to allocate, converting to bytes then return.
This makes ReactOS applications compiled for ARM running on true ARM Windows.
Reference: 2b095beace
Native CRT on ARM & ARM64 Windows doesn't have these functions.
For compatibility, it's mandatory to not have it at all. Otherwise,
ARM executables built for ReactOS do not run on true ARM Windows.
Consider doing full sync with mingw-w64 CRT in future.
The code is mostly unchanged. This includes the following changes:
* Move all wine code to crt/wine to keep it separated from our own code
* Add a minimal winternl.h
* Remove the asm macros from wine/config.h
* Include wine/asm.h where required
* Fix the names of the exported functions (GCC uses thiscall now and no wrappers are used anymore)
This adds an evil hack to persuade libstdc++, which tries to import __acrt_iob_func from a DLL.
This can only be solved cleanly by adding a GCC-compatible C++ standard library to our tree later.
Fixes GCC 8 warning:
sdk/lib/crt/misc/i10output.c:83:25: error: '%d' directive writing between 1 and 11 bytes into a region of size 6 [-Werror=format-overflow=]
sprintf(format, "%%.%dle", prec);
^~
sdk/lib/crt/misc/i10output.c:83:21: note: directive argument in the range [-2147483648, 2147483646]
sprintf(format, "%%.%dle", prec);
^~~~~~~~~
sdk/lib/crt/misc/i10output.c:83:5: note: 'sprintf' output between 6 and 16 bytes into a destination of size 8
sprintf(format, "%%.%dle", prec);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This fixes the following compiler errors:
../sdk/lib/crt/stdio/stat64.c:7:13: error: inline function 'release_ioinfo' declared but never defined [-Werror]
inline void release_ioinfo(ioinfo *info);
^~~~~~~~~~~~~~
../sdk/lib/crt/stdio/stat64.c:6:16: error: inline function 'get_ioinfo' declared but never defined [-Werror]
inline ioinfo* get_ioinfo(int fd);
^~~~~~~~~~
../sdk/lib/crt/stdio/file.c:186:5: error: 'init_ioinfo_cs' is static but used in inline function 'get_ioinfo' which is not static [-Werror]
init_ioinfo_cs(ret);
^~~~~~~~~~~~~~
../sdk/lib/crt/stdio/file.c:183:19: error: 'get_ioinfo_nolock' is static but used in inline function 'get_ioinfo' which is not static [-Werror]
ioinfo *ret = get_ioinfo_nolock(fd);
MSVC was previously given a "result" variable to copy the fscale result from st(0). This led to another "fld" FPU stack push at the very end without popping the source value from the FPU stack.
Moreover, this copy isn't even needed: A simple "fstp st(1)" at the end pops an element from the FPU stack while effectively storing the result in st(0), the register used for returning a double value.
This problem didn't affect GCC, as it is only given the "fscale" instruction and does all necessary stack operations itself.
However, looking into the CRT sources, I found many other i386 implementations with inline assembly suffering from the same problem.
Fortunately, they have been replaced by pure assembly implementations a while ago, so it's time to finally remove them.
ldexp would have also been a candidate for a pure assembly implementation, but the required check for NaN and setting errno (verified on Win2003) already outweighs the benefits.
And we cannot just do a NaN check with FUCOMI as this is an i686/pentiumpro instruction while we're still targeting i586/pentium.
I'm also using this opportunity to clean up the ldexp.c header and only put in the remaining contributors as returned by "git blame".
Thanks to NightWolve1975 for reporting the problem! (https://twitter.com/nightwolve1975/status/1099042477531643912)
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.
* [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
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.
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
