It was introduced in commit 1f9c4940d (r38270), but this flag isn't used
anymore in our source tree, and nowadays, we actively compile both UP
and MP support.
Re-trial of #7800. Deleting __WINESRC__
hacks.
JIRA issue: CORE-5743
- Add sdk/cmake/set_wine_module.cmake.
- Load set_wine_module.cmake at
top-level CMakeLists.txt.
- Use set_wine_module cmake function
and delete __WINESRC__ as possible.
- Delete many include_directories.
It's purpose was to create x64 unwind information from DWARF debug info, but it was never fully working and is pointless now anyway, because x64 GCC does this itself properly.
This setting can be overwritten by defining the CMake variable HOST_BUILD_TYPE.
The target build type is passed to the host build as TARGET_BUILD_TYPE CMake variable.
This improves time to build cab+iso:
MSVC x86: 37s -> 28s
GCC x86: 32s -> 16s
__throw_out_of_range_fmt is implemented in libstdc++, but it is needed by libsupc++ and that would mean we would have to link all C++ code to libstdc++.
Do the same in add_idl_reg_script() (currently unused helper) as well.
This is an addendum to commit b587e7b32, where the removal of the
IDL_FILE_FULL variable definition, broke dependency tracking with
the DEPENDS option. Now we use the correct variable.
The problem was caught after doing a partial (non-clean) build after
commit 0d10fb814. In this commit, two new interfaces, IExecuteCommand
and IObjectWithSelection, were added in the psdk/shobjidl.idl file
and used elsewhere. Recompilation correctly regenerated the corresponding
header, psdk/shobjidl.h, but did not trigger a regeneration of the uuid
static library (via the regeneration of sdk/lib/uuid/shobjidl_i.c),
due to broken dependency tracking on the shobjidl.idl file.
Because of this, the shobjidl_i.c did not contain the new GUID
definitions for these new interfaces, IID_IExecuteCommand and
IID_IObjectWithSelection, and triggered linking errors for the
com_apitest, actxprxy and shell32 modules:
```
error LNK2001: unresolved external symbol _IID_IExecuteCommand
error LNK2001: unresolved external symbol _IID_IObjectWithSelection
fatal error LNK1120: 2 unresolved externals
```
* [UDFS] Clang: Fix a #pragma
'warning: unknown warning group '-Wstringop-overflow', ignored [-Wunknown-warning-option]'
Follow-up to 612b1f2e6 (0.4.15-dev-1129).
* [CREATESPEC] Clang: Fix a target_compile_options()
'warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]'
Addendum to 00ed72d7e (0.4.15-dev-1169).
* [MSVCRT_WINETEST] Clang*: Fix a target_compile_options()
'warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]'
Addendum to commits 00ed72d7e (0.4.15-dev-1169) then f155b9377 (0.4.15-dev-4612).
* [TELNET] Clang*: Fix a target_compile_options()
'warning: unknown warning option '-Wno-restrict' [-Wunknown-warning-option]'
Addendum to 447ef2aa4 (0.4.15-dev-4613).
This removes all fake apiset forwarders,
and handles apisets inside ntdll.
This is not 100% compatible with how windows does it, but it should be good enough for us.
Follow-up to #6624 (fd96666). ReactOS got rekt in that PR
because kernel32.dll got so larger.
Fix base addresses of DLLs to boot successfully. Sorry.
(dll/ntdll/ldr/ldrutils.c:1423) Illegal DLL relocation!
C:\ReactOS\System32\ntdll.dll overlaps kernel32.dll
*** Fatal System Error: 0xc0000269
Proposed changes
After latest build:
python gen_baseaddress.py C:\Users\katahiromz\reactos-1\output-VS-i386
python gen_baseaddress.py C:\Users\katahiromz\reactos-1\output-MinGW-i386
They are renamed to 'msi_custom' and 'msi_selfreg', respectively.
This is to avoid any future build target name collisions with other
tests that would also use similarly-named targets. (For example, a
future setupapi wine-synced commit.)
Reason: VS solution builds pass the compiler options to the assembler. These are usually ignored and result in a warning only, but ML of the latest VS supports /Gy (function level linking), but that requires all functions to be declared with "PROC" and otherwise results in an error.
Ensure that CMAKE_ASM16_COMPILER is 32-bit MASM.
It is used only for compiling 16-bit x86 ASM code on non-x86 builds.
Original patch by serrox. CORE-10452, CORE-17604
Co-authored-by: Sergey Chernov <serrox@ya.ru>
* [SDK:TOOLS] Improve gen_baseaddress.py
Adds some kbd layout modules into the excludes-section:
that we do lack for todays master: e.g._ kbdeo, kbdsf, kbdrost
and also some that we lacked in the past
(for improving backwards compatibility of the script to older rls-branches):
kbdgm, kbdes, kbdgrist, kbdja, kbdko, kbdsk, kbdsk1
* [SDK:CMAKE] Highlight in the output files where the script does misbehave
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().
- 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>
