addendum to 0.4.15-dev-1123-g 0089291751
Fix a compiler error on RosBE2.1.6 GCC4.7.2
that I got when I merged this test back to 0.4.14RC:
C:/0414rls/reactos/modules/rostests/apitests/shell32/ShellHook.cpp: In function
'LRESULT WindowProc(HWND, UINT, WPARAM, LPARAM)':
C:/0414rls/reactos/modules/rostests/apitests/shell32/ShellHook.cpp:339:26: error
: comparison between signed and unsigned integer expressions [-Werror=sign-compa
re]
cc1plus.exe: all warnings being treated as errors
ninja: build stopped: subcommand failed.
We decided to check a bit different than Wine currently does.
Wine checks for
if (GetVolumeInformationW(ptr, NULL, 0, NULL, 0, &flags, NULL, 0) && flags & FILE_READ_ONLY_VOLUME)
to exclude read-only-media while we (for now) check for
if (GetDriveTypeW(ptr) == DRIVE_CDROM)
For now this gives us the benefit of covering also CDROM drives, that do not have
a CD put into it.
That does not work properly for us with the Wine patch yet, but it does for Wine!
So this maybe points to some other bug in ros, maybe in our CDROM(FS)-drivers?
In the future we should also test this on other read-only-media in Windows e.g.
a read-only USB stick to decide whether we want to stick with our current solution
or whether we want to switch to Wines solution or whether we want to logically OR
both conditions!
Thanks to Doug Lyons for providing what *currently* does work best for us!
VBox https://reactos.org/testman/compare.php?ids=77537,77546 (no change)
KVM https://reactos.org/testman/compare.php?ids=77531,77541 (no change)
On Windows 10, when I copyed Notepad.exe to the desktop and double-clicked it, it won't start Notepad. This is probably because there is a security protection mechanism (or some mechanism) at work. Tests that assume this mechanism will not work properly on ReactOS. Thus, I had to delete some tests. CORE-17351
KiSetTrapContext is an asm wrapper around RtlSetUnwindContext, which first stores an exception frame to assure that all non-volatile registers were put on the stack, then calls RtlSetUnwindContext to update their first saving positions on the stack and finally restore the exception frame to potentially load any updated registers, that haven't been saved elsewhere on the stack.
RtlpCaptureNonVolatileContextPointers walks the stack and captures the addresses of all non-volatile registers on the stack, when they have been saved first. This is needed to be able to fix up the non-volatile on a system call, which doesn't capture non-volatiles, but relies on them to be restored by the callees.
Instead of only checking for the TargetFrame, also check for a mode change, i.e. RIP went from kernel to user, in which case the target frame was not reached yet, because it was too large, but processing can't continue here.
RtlSetUnwindContext uses RtlpCaptureNonVolatileContextPointers to set the non-volatile registers in the the stack. They will be picked up, when returning back or unwinding, e.g. to the system call handler.