Fixes GCC 8 warning:
sdk/lib/3rdparty/zlib/contrib/minizip/zip.c:521:5: error: this 'for' clause does not guard... [-Werror=misleading-indentation]
for (i=(int)uReadSize-3; (i--)>0;)
^~~
sdk/lib/3rdparty/zlib/contrib/minizip/zip.c:529:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'for'
if (uPosFound!=0)
^~
These are required by latest mingw-w64 stl and we are mixing this with our crt headers.
Define _CRT_NO_POSIX_ERROR_CODES in all modules that define their own constants.
This prevents some errors like this one:
In file included from ../dll/win32/wldap32/ber.c:27:0:
../sdk/include/reactos/wine/debug.h:378:48: error: '__wine_dbch___default' defined but not used [-Werror=unused-const-variable=]
static struct __wine_debug_channel * const __wine_dbch___default = &__wine_dbch_##ch
^
../dll/win32/wldap32/ber.c:29:1: note: in expansion of macro 'WINE_DEFAULT_DEBUG_CHANNEL'
WINE_DEFAULT_DEBUG_CHANNEL(wldap32);
^~~~~~~~~~~~~~~~~~~~~~~~~~
hid.dll and hidparse.sys must understand the same HID preparsed data,
so use the same code in hid.dll and in hidparse.sys
At the same time, this permis implementation of some HidP_* functions.
Interface between both is not anymore the HidParser_* functions, but
the HidP_* functions and the AllocFunction/FreeFunction/DebugFunctions/
ZeroFunction/CopyFunction.
This finally fixes our duplicated getopt functions from different sources and gives us an up to date and the most compatible implementation.
isohybrid actually relies on a glibc-specific getopt behavior that we previously hacked into the reactos_support_code.c implementation derived from BSD/mingw-w64.
widl also needs getopt and previously used an even older BSD-derived code.
It retrieves the handle to the desktop assigned to the specified
thread belonging to a console application, which is going to be
where the input thread of this console is.
Up to CMake 3.3 LINK_DEPENDS was ignored in non-Makefile generators. See also http://www.cmake.org/pipermail/cmake/2010-May/037206.html. Since CMake 3.4 it is no longer ignored, but requires CMP0005 policy to be set to NEW and it requires a full path which was already correctly used on GCC, but not on MSVC builds.
* [CMAKE] Fix for CMP0018
The new behaviour lets us explicitly disabling position independent code, avoiding the need to change undocumented variables
* LINK_DEPENDS is semicolon separated
* [CMAKE] Fix for CMP0005
it seems impossible to have cmake correct escape PROXY_CLSID_IS so move it to the header
- Modify atldef.h for non-ReactOS environments.
- Update ATL testcase project files (from v120_xp to v140_xp).
- #define HAVE_APITEST and use it.
- s/NULL/0/
- C4311: pointer truncation from '<pointer>' to '<integer>'
- C4312: conversion from '<integer>' to '<pointer>' of greater size
- C4133: incompatible types - from '<x> *' to '<y> *'
- C4028: formal parameter different from declaration
_IMPLICIT_LINK_DIRECTORIES
Othrewise, if you link a RC module with a static C library (as done for
fusion DLLs), you get the standard C libraries from GCC. This is not
what we want.
This might have to be done for MSVC builds. Check build.ninja to verify
this.
There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
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);
../sdk/include/reactos/rosctrls.h:283:59: error: no matching function for call to 'CToolbar<TItemData>::SendMessageW(int, HWND__*&, int)'
return SendMessageW(TB_SETTOOLTIPS, hWndTooltip, 0);
../sdk/include/psdk/winuser.h:5543:21: note: candidate: LRESULT ATL::CWindow::SendMessageW(UINT, WPARAM, LPARAM) <near match>
../sdk/include/psdk/winuser.h:5543:21: note: conversion of argument 2 would be ill-formed
ReactOS/Windows headers contain lots of structures whose last field is
fieldName[ANYSIZE] or fieldName[1].
Starting with GCC 4.8, gcc considers that accessing items [2], [3], ...
are undefined operation, and may optimize those accesses by removing them!
Add flag -fno-aggressive-loop-optimizations to prevent this unwanted behaviour.
- Assume that GetTextExtentExPointWPri() uses the same kind of
arguments as GetTextExtentExPointW().
- Add GetTextExtentExPointWPri() declaration to undocgdi.h.
Since ReactOS doesn't actually support non-local WinSTA/WTS capabilities, this seems to be a good way to reduce spam in the log while providing correct behaviour.
Also call Unicode version from ANSI one to reduce code duplication.
This is done by marking everything that is already loaded but not 'processed'.
After the shim engine is done initializing, the original state is restored,
with the exception of the shim engine itself.
CORE-15846
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.
MSBuild, via the VS IDE, uses response files when calling CL or LINK.
We cannot specify a custom response file on the linker command-line,
since specifying response files from within response files is forbidden.
We therefore have to pre-process, at configuration time, the linker
script so as to retrieve the custom linker options to be appended
to the linker command-line.
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.
Modify the .code16 macro so that the 16-bit code segment can get a
chance to be correctly merged with other (possibly 32-bit) code
segments, without keeping generating multiple .text segments with
different attributes and generating the corresponding LNK4078 warning.
This fixes the warning when compiling NTOSKRNL on MSVC:
"v86.S.obj : warning LNK4078: multiple '.text' sections found with different attributes (C0520040)".
- Always use string pooling when building: this helps reducing the
size of the binaries due to string redundancy coming from the usage
of __FILE__ / __RELFILE__ in the debugging helper macros. Note also
that GCC builds use string pooling by default.
- Use suitable add_compile_flags() command.
- Add some explanative comments for some settings.
Some numbers (obtained with my local builds):
Before / After => Reduction
===========================
freeldr.sys : 443 KB ( 453.632 bytes) / 364 KB ( 372.736 bytes) => ~ 18%
win32k.sys : 1877 KB (1.922.048 bytes) / 1562 KB (1.599.488 bytes) => ~ 17%
ntoskrnl.exe : 2253 KB (2.307.072 bytes) / 1902 KB (1.947.136 bytes) => ~ 15.6%
kernel32.dll : 3008 KB (3.080.192 bytes) / 2906 KB (2.975.744 bytes) => ~ 3.4%
* [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
* Add an NDK header to define INIT_FUNCTION/INIT_SECTION globally
* Use _declspec(allocate(x)) and _declspec(code_seg(x)) on MSVC versions that support it
* Use INIT_FUNCTION on functions only and INIT_SECTION on data only (required by MSVC)
* Place INIT_FUNCTION before the return type (required by MSVC)
* Make sure declarations and implementations share the same modifiers (required by MSVC)
* Add a global linker option to suppress warnings about defined but unused INIT section
* Merge INIT section into .text in freeldr
