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 by default, not on the release branches.
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
- avoids the crash in rls-branches in case the app was intentionally started in Vista-compat-mode
- and the fix also decreases the binary size of that apiset.
Fix picked from 0.4.15-dev-179-g 02825c20e4
dll\apisets\api-ms-win-crt-utility-l1-1-0_stubs.c(41) : error C2169: 'llabs' : intrinsic function, cannot be defined
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 4ad7b6d634
Fixes symptom "MSVCPP2017 setup crash due to missing export"
The issue very likely got introduced by
0.4.13-dev-986-g
029b8f2cf9
because our loader exports stuff from neweer Windows versions
since then in case an executables manifest states compatibility.
Original commit message from patches author William Kent:
Stub GetCurrentPackageId() (#1942)
* [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.
cherry picked from commit 0.4.14-dev-482-g
192926ee02
Symptom "Far Manager 3.0 Build 5200 can not load NetBox.dll"
due to uncaught exception when accessing GetSystemTimePreciseAsFileTime().
The symptom started to show with 0.4.13-dev-986-g
029b8f2cf9
as LDR exposes more Vista+ stuff since then.
The fix is a selective backmerge of master PR-1963
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.
cherry picked from commit 0.4.14-dev-654-g
6f93f2cf10
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.
cherry picked from commit 0.4.14-dev-653-g
cabf120833
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
