__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>
* [CMAKE] msvc.cmake: Remove redundant '/Gy'
Function-level-Linking '/Gy' is already enabled unconditionally
at line 26. So no need to enable it here another time.
Makes the differences between the multiple OPTIMIZE-levels more obvious.
* [CMAKE] msvc.cmake: Fix typo in comment
This became a requirement, following a previous CMake update.
Otherwise the built EXEs would not export their intended functions.
Addendum to commit d8e92b5a (see PR #1335)
CORE-15406
[LOADCONFIG] The GCC rant had nothing to do with GCC, but everything with CMake...
[SPOOLSV] Add the missing exported stubs.
- Add some of the missing CMake adjustments to continue the configure and compile process with ARM64 MSVC
- Created quick stubs for the functions in SDK needed to finish the configuration process
- Put in an ARM64 option for spec2def
CORE-17518 CORE-17615
This option is only useful for the i386 architecture and breaks ARM builds.
Reviewed-by: Victor Perevertkin <victor.perevertkin@reactos.org>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Some compilers call it 'arm64', while others prefer 'aarch64'. It's a big mess,
thanks Arm Ltd...
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
Reviewed-by: Serge Gautherie <reactos-git_serge_171003@gautherie.fr>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
list() functions expects numerical indices for modification operations
and silently converts everything else to a number (old behaviour).
CMake 3.21 now checks this and throws a warning
