I double-checked and although the crash in Motorbike does *not* happen by default in all of those builds:
0.4.14-RC-54-g6a6672d (hidden by opt-in apisets-default in release branch)
0.4.13-release-1-g2ac9d98 (hidden by opt-in apisets-default in release branch)
0.4.12-release-17-g79780cd (hidden also, I don't understand why)
0.4.11-release-28-gc4d930d (hidden also, I don't understand why)
0.4.10-release-35-g94b4a3e (hidden also, I don't understand why)
0.4.9-release-41-gd3a79fe (hidden also, I don't understand why)
0.4.8-release-46-gd4d58d7 (hidden, does not have apisets yet)
0.4.7-release-56-g835b508 (hidden, does not have apisets yet)
It was really only crashing in master.
I decided to port the proper fix back nevertheless, because:
- the exports are wrong for our target
- I can not guarantee otherwise that it would not pop up all of a sudden later
- and the fix also decreases the binary size of that apiset.
Fix picked from 0.4.15-dev-179-g 02825c20e4
Allows to complete the whole 'ninja bootcd' after 'configure -DCMAKE_BUILD_TYPE=Release'
for compiler MSVC 2010SP1 16.0.40219.1 with RosBE 2.1.6
Similar to the fix committed in 0.4.15-dev-1453-g 4ad7b6d
- [MSVCRT] __DestructExceptionObject(): Remove '-version=0x600+'
- [APISETS] __DestructExceptionObject(): Forward it to msvcrt
CORE-15135
I cherry-picked this, because we did export a stub for that historically at least
"commented". :-)
Exporting it 0x600+ only is regression of
0.4.13-dev-1032-g
99fe069ce6
Sure unobservable, because was a change within a comment only.
cherry picked from commit 0.4.15-dev-87-g
a9161650ad
Symptom: "Far Manager main app unhandled exception when exiting"
The issue started to show with 0.4.13-dev-986-g
029b8f2cf9
Thanks to Mark Jansen for providing this 2nd patch.
I intend to port this back into 0.4.13RC.
Symptom: "Far Manager main app does not longer start up"
The issue started to show with 0.4.13-dev-986-g
029b8f2cf9
Thanks to Mark Jansen for providing this first patch.
I intend to port this back into 0.4.13RC,
but we are not completely done with this ticket.
* [KERNEL32] Add stub implementation for GetCurrentPackageId() function
This Windows 8+ function is called by WiX bundles (EXE-based installers) upon exit, if the export is present. If it is a stub in the spec, they will crash, even if they are coded to be compatible with Windows XP/ReactOS.
Also add GetCurrentPackageId() forwarder to apiset.
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.
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
