Partially revert some aspects of commits 5696e4ba4 and bf40c7a31.
(See PR #4340.)
In order for Win2k3 kernel32.dll to operate with our basesrv.dll (or our
kernel32.dll to operate with Win2k3 basesrv.dll), we need in particular
to have the CreateNlsSecurityDescriptor() helper to exactly take the
expected parameters. Namely, a pointer to a **user-allocated**
SECURITY_DESCRIPTOR buffer, its size (and an access mask).
The function expects its caller to provide all this, and the caller expects
the function to initialize the security descriptor buffer. Note that the
function does *NOT* allocate a new descriptor buffer to be returned!
Indeed, with the way it currently is in master, using Win2k3 kernel32
with our basesrv is now failing with the errors:
```
NLSAPI: Could NOT Create ACL - c0000023.
(subsystems/win/basesrv/nls.c:279) NLS: CreateNlsSecurityDescriptor FAILED!: c0000023
NLSAPI: Could NOT initialize Server - c0000023.
(dll/ntdll/ldr/ldrinit.c:867) LDR: DLL_PROCESS_ATTACH for dll "kernel32.dll" (InitRoutine: 77E40D95) failed
```
(and, if we ever attempted to increase the so-claimed "dummy parameter"
descriptor size in the basesrv call, we would end up with its stack
corrupted and a crash).
Conversely, using our kernel32 with Win2k3 basesrv, would end up with
basesrv receiving a wrongly-initialized descriptor that would not work
(the buffer not being initialized with the contents of a descriptor, but
instead receiving some address to a descriptor allocated somewhere else).
Implement code that deals with the security side of NLS, more specifically, create two security descriptors for NLS directory and NLS section names and let the server use such code.
Addendum to commit 0a392b18.
The actual problem that existed all along was that the buffers being
validated with CsrValidateMessageBuffer() were not the correct ones!
What had to be checked is the string buffer **INSIDE** the UNICODE_STRING
structures! Indeed, it is these buffers that we are allocating on client side,
see https://github.com/reactos/reactos/blob/9b421af1/dll/win32/kernel32/client/dosdev.c#L324-L336
Dedicated to Pierre Schweitzer.
This will notably bring support for DOS mapping with LUID devices
(not yet supported in the kernel, though).
This also reduces complexity (and thus memory usage) with the "history"
thing. Multiple targets are stored in the link target as MULTI_SZ string.
This fixes regressions introduced with kernel32 fixes/rewrites.
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.
