First part with the typo in the assert was introduced by 5579428b4f
which was merged into ros by a merge-task during 0.4.8-dev'ing.
releases/0.4.7 didn't have that code yet.
fix picked from 0.4.15-dev-5035-g f308c6a2bc
----------
[NTFS] Do not print debug message for every function call by default
That 2nd part was picked from 0.4.13-dev-450-g 1552434940
This part is not relevant for the backport to releases/0.4.13 and 0.4.14, because it is
already inside them.
----------
And for all the files that I had to touch for the 2nd part in the older branches,
I ported back also some EOL-whitespace-fixes within like they were done during 0.4.15-dev'ing.
I am not sure why this line in id_queue.cpp was added.
I don't know how I could improve that case.
Then, disable it, for the time being.
It regressed by 4b9cf2e339 (r71252). CORE-12441 CORE-17371
fix picked from 0.4.15-dev-2740-g ba77a09c04
While touching uniata do also PARTIALLY port back some bm_devs.h changes:
0.4.15-dev-1522-g 88d36c93a2 (Properly mark ReactOS diff from upstream)
Changes to specific files and their effects are as follows:
create.cpp - Allows booting past second stage with UDFS media inserted without BSOD
close.cpp - Allows shutdown without hang
dircntrl.cpp - Allows New Hardware Wizard not to hang on initial third phase install
It began to crash with the introduction of the UDFS driver in SVN r74901 == git 3a104c8f20
Fix picked from 0.4.15-dev-3326-g a91f5e8e4d
The DbgBreakPoint() was reported to be continuable without
obvious side-effects by Doug Lyons.
Thank you for your tests Doug.
To prevent what end-users may otherwise perceive as a
freeze-regression caused by enabling the new driver in
0.4.13-dev-1048-g
6392c5a78c
not cherry-picked
(as in master USBHUB_NEW has been moved to USBHUB since 0.4.13RC)
but fixed 100% equal to a squash of
0.4.14-dev-881-g
f32e1acd3c
(thanks to author Thomas Faber)
and
0.4.14-dev-1164-g
23f6b36174
CORE-16375 #1914
Thanks to patches author ThFabba.
According to JIRA user 'Zero3k' this allows to format a
BTRFS drive again without INVALID_KERNEL_HANDLE BSOD.
Master remains affected,
our devs wait for upstream integration
JIRA-user "Illen" reported booting from his Z170 controller worked up to
0.4.12-dev-936-g89aaf0e
and would refuse booting - beginning with uniata commit
0.4.12-dev-937-g
b546130731
For sure this workaround is just a temporary and no proper solution,
but was confirmed to be working by "Illen".
We have no clear understanding of the real bug yet.
Can be replaced by something better at any time.
It was just committed into the RC, master remains affected.
cherry picked from previous release
commit a57363f363
They were wrongly pointing to the original target once rewritten
instead of pointing to the proper target: the device.
This notably fixes opening the MountMgr device from user
mode (to perform IOCTL calls, for instance), and might
also fix various bugs dealing with global namespaces.
This might have some various effects in ReactOS~.
- Added SAL annotation
- Simplified local variables
- Replace counterintuitive `do {} while ()` loops with nice `for` loops
- Get rid of goto and its label, it can be simply avoided