Since indeeed the memcpy/move type of functions usually don't operate on
pointers to 'volatile' data, don't make ClientCaptureBuffer volatile.
Instead when retrieving the values of its 'Size' and 'PointerCount'
members (see the SEH block), use the so-called technique of "volatile
glasses" [1], where the pointer will be explicitly casted to "volatile TYPE*"
where needed.
[1]: https://docs.microsoft.com/archive/blogs/itgoestoeleven/why-your-user-mode-pointer-captures-are-probably-broken
- Improve capture buffer validation in CsrCaptureArguments(), by
implementing the checks done by Windows 2003 (NT 5.2) described
in section "Server-Side Validation and Capture" of the article
https://www.geoffchappell.com/studies/windows/win32/csrsrv/api/apireqst/capture_header.htm
- In CsrReleaseCapturedArguments(), protect the data copy back into
the client buffer within a SEH block.
Rename inaccurate names 'LocalCaptureBuffer' and 'RemoteCaptureBuffer'
into 'ClientCaptureBuffer' and 'ServerCaptureBuffer' respectively.
(Recall: CSRSRV is the 'Server', and any app doing LPC calls to it is
the 'Client'.)
Also, trigger the less fatal breakpoints only if CSRSS/CSRSRV is being
debugged (the 'BeingDebugged' flag is set in the current PEB). This will
avoid any unhandled breakpoint exceptions when testing/fuzzing running
debug builds of ReactOS without any debugger attached.
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.
